| Author |
Message |
shmike
Joined: 20 Dec 2004
Posts: 31
Location: Melbourne, Australia
|
| SMSReader Schematic |
 |
Posted: Sun Jan 02, 2005 1:20 pm |
 |
|
Hi everyone,
I've taken some time to draw up the SMSReader schematic using Cadsoft's EAGLE. For those who are unfamiliar with it, the program can be found at http://www.cadsoft.de/. The schematic is nearly finished, but I'm just stuck on one part. I'm not sure where the extra 2 troubleshooting ceramic capacitors and the 2 pull-up resistors actually go and I'm having a bit of a hard time trying to figure it out from the veroboard hole references given in the troubleshooting FAQ from the SMSReader site. Can anyone here point out as to where they go in terms of what IC pins they connect to?
**UPDATED** smsreader_schema_rev02.sch (04 Jan 2005)
See latest postings for details.
The links below have been updated as well.
I have now attached the files to this thread as the site on which they were hosted no longer exists.
The EAGLE schematic file can be found here. Now in a ZIP file.
A PNG image of the schematic can be found here.
PS: Ignore the extra details I've added to the component values - they're just catalogue numbers for the parts from Jaycar. Also, I'm confident but I can't gaurantee that this schematic is error free.
shmike
Last edited by shmike on Tue Jan 22, 2008 7:52 am; edited 3 times in total |
|
| Back to top |
|
 |
Charles MacDonald
Joined: 28 Sep 1999
Posts: 779
|
| Re: SMSReader Schematic |
|
Posted: Sun Jan 02, 2005 7:08 pm |
|
|
| Quote:
|
stuck on one part. I'm not sure where the extra 2 troubleshooting ceramic capacitors and the 2 pull-up resistors actually go and I'm having a bit of a hard time trying to figure it out from the veroboard hole references given in the troubleshooting FAQ from the SMSReader site. Can anyone here point out as to where they go in terms of what IC pins they connect to?
|
I haven't built this, but Mike's description in the troubleshooting section makes it sound like the 4.7nF capacitors are placed in series with the reset and clock lines from the parallel port, going to the two counters; likewise the two pull-up resistors would go from the reset and clock lines to +5V.
Another solution would be to use two gates of a 74HC14 in series on the clock and reset lines, you could omit the capacitors and pull-up resistors that way.
| Quote:
|
The EAGLE schematic file can be found here.
|
This is very cool, nice work! I have some suggestions:
- You can name individual wires (nets) and view them by typing 'show <name>' For example you could name the net for AUTOLF and tyen type 'show autolf' and you'd see the connection between the parallel port and reset input of both counters. (if you try this, /AUTOLF is named N$12 in the schematic)
This helps verifying the design because you can quickly check connections visually by entering different wire names.
- When you have a schematic with a lot of different wires, such as the data and address busses in this one (between the parallel port / counters and SMS cartridge connector) it is more convenient to group them into a bus. You can type this command to define a bus:
bus data[0..7],addr[0..15]
The blue line that is drawn contains all 24 wires (data0..data7 and addr0..addr15) without you having to draw each one. This example merged the address and data busses into one bus, most people like to split the wires (nets) into a bus based on their functional group, e.g.:
- Data bus (data0..data7)
- Address bus (addr0..addr15)
- Maybe another bus for the parallel port signals (data,status,ctrl)
- Clicking on the 'Erc' button (side toolbar, lower-leftmost icon) shows errors in the schematic, such as unconnected wires or wires that only connect to one (and not two or more) pins. There were a few items in your schematic it warned about.
- It's a good practice to keep the power and ground traces wider as a narrow trace limits the amount of current that can pass through it. If you go to Edit -> Net classes you can add two more (VCC and GND) to the list, keeping 'default' intact, and set their parameters to 20mil each which is a good general figure. When you are placing a wire (net) just select the appropriate class (default, VCC or GND) in advance.
- The schematic shows the 7400 part used, it should be a 74HC00 instead - not a big deal to people familiar with the SMS Reader, but if somebody was building one based on the schematics and without Mike's part's list, it could be confusing.
Can't wait to see the finished version - now I have no excuses for not making a SMS Reader yet! :)
|
|
| Back to top |
|
|
Mike G
Joined: 21 Apr 2000
Posts: 598
Location: Newcastle upon Tyne, England
|
|
|
Posted: Sun Jan 02, 2005 8:50 pm |
|
|
Hello there! Long time no post...
The 4.7nF caps go from the reset and clock lines to Ground. Sorry for any confusion - it's simply down to me being lazy and not updating my original schematic.
I agree with Charles, that is an excellent piece of work. If you need any more help with SMSReader-related matters, just let me know - I'll be more than happy to assist!
Later,
Mike
|
|
| Back to top |
|
|
shmike
Joined: 20 Dec 2004
Posts: 31
Location: Melbourne, Australia
|
|
|
Posted: Mon Jan 03, 2005 10:13 am |
|
|
Wow, I didn't think that this would get a lot of interest. I guess that's why the schematic is rather messy and hasn't been drawn as cleanly as it could have been, like using busses as Charles MacDonald mentioned. I just thought that maybe someone would have found it helpful, and hence posted it as is. But since there's some greater interest in it I'd be willing to put the effort in to improve it.
For now, the schematic has been mildly updated. The link in the first post of this thread will be modified to point to the updated version, and I'll also include the link at the bottom end of this thread just to complicate things. I'll also update the PNG version too.
smsreader_schema_rev01.sch (03 Jan 2005)
Things that have been updated:
- The schematic has been completed. All components have been inserted and connected.
- Troubleshooting caps and resistors have been added. (Mike G - are they in their correct positions?)
- No ERC errors and most warnings have been elimated. There are still some present regarding the connection of the ICs' VDD pins to VCC and VSS to GND but it can be ignored.
- The component name "7400N" has been changed to "74HC00". Even though the items have the same pinout, the 74HC00 is the device that's required in this case. This is to help avoid confusion.
Things to add:
- Redraw parts of the schematic to use busses instead of leaving it looking like a bowl of right-angled spaghetti. (Data lines, address lines, etc. to have individual busses)
- Rename the Nets to have meaningful names (as Charles suggested)
- Maybe add some descriptive labels.
- Remove those silly Jaycar component catalogue numbers that I put in for personal reference as they obviously don't apply to everyone.
- Design a PCB layout. (Yes it would be silly for me to stop at just a schematic now.)
Download:
Schematic for EAGLE is here
Schematic as a PNG image: here
So there is still some stuff to do. But basically, the updated schematic is complete. I still can't say that it's error free, but everything's there and those of you want to go ahead and get straight into designing a PCB layout or whatever, you can.
Thanks to Charles and Mike for your feedback and help.
shmike
|
|
| Back to top |
|
|
Mike G
Joined: 21 Apr 2000
Posts: 598
Location: Newcastle upon Tyne, England
|
|
|
Posted: Mon Jan 03, 2005 1:54 pm |
|
|
| shmike wrote:
|
|
- Troubleshooting caps and resistors have been added. (Mike G - are they in their correct positions?)
|
Yep, that's fine!
I don't think there are any other issues with the schematic, but I'll check over it again and will let you know if I find anything.
If you're thinking of designing a PCB, it may be a good idea to have a broader discussion about how the SMSReader design could be improved, before the whole thing gets "ossified" into a PCB layout. I've been looking through earlier threads (I've been out of the loop for so long, I have about two years' worth of posts to check through!) and quite a few worthwhile improvements have been suggested.
It may even be worth looking at creating a dual-purpose PCB, encompassing both the SMSReader and Paul Baker's MegaReader design... but I'm getting ahead of myself here. (Considering I was too lazy even to create a proper schematic, let alone a PCB layout, I'm a fine one to talk about such matters!)
Mike
|
|
| Back to top |
|
|
shmike
Joined: 20 Dec 2004
Posts: 31
Location: Melbourne, Australia
|
|
|
Posted: Tue Jan 04, 2005 7:54 am |
|
|
And another update to the schematic.
smsreader_schema_rev02.sch (04 Jan 2005)
Things that have been updated:
- It's Mike G's device, so his name definately deserves to be in the schematic too. My apologies for not putting it in earlier.
- Redrawn data and address lines the schematic using busses (Data bus: DATA0..DATA7, Address bus: A0..A15) so things should be more visually clearer
- Nets have been named (eg: /RD, /AUTOLF, VCC, etc)
- Labeled most nets and busses
- Jaycar catalogue numbers have been removed from component value fields
Things to do:
- Design PCB layout
- Anything else I've left out
Hopefully the changes I've made by using busses hasn't introduced new errors or left any connections out. I have made an effort to check things myself, but there still may be something overlooked.
Dowload:
Schematic for EAGLE is here (now in a ZIP file)
Schematic as a PNG image: here
First post will be edited as well.
Suggestions for improvements? I think a few simple ones could be implemented, such as a status LED that would light up when there's activity on the CLOCK line ("Read" status) and /WR line ("Write" status). It'd be as simple as adding some transistors, LEDs and resistors.
I'd also like to see this device support Charles MacDonald's 512kb flash cart. Also, from the top of my head I'm not sure if flash EEPROMs support In-Circuit Programming (ICP), but if it did, adding some headers to the SMSReader and a ribbon cable to slightly tweaked version of the devcart could mean we could have a devcart that wouldn't even need to be unplugged from SMS to be reprogrammed. But I have doubts with this ICP idea. Perhaps I've been hanging around PICs too much.
Anyone else have any ideas?
shmike
|
|
| Back to top |
|
|
Charles MacDonald
Joined: 28 Sep 1999
Posts: 779
|
|
|
Posted: Tue Jan 04, 2005 5:20 pm |
|
|
| Quote:
|
I'd also like to see this device support Charles MacDonald's 512kb flash cart. Also, from the top of my head I'm not sure if flash EEPROMs support In-Circuit Programming (ICP), but if it did, adding some headers to the SMSReader and a ribbon cable to slightly tweaked version of the devcart could mean we could have a devcart that wouldn't even need to be unplugged from SMS to be reprogrammed. But I have doubts with this ICP idea. Perhaps I've been hanging around PICs too much.
|
To support flash you need to be able to quickly write to different addresses for *each* byte programmed, e.g. something like:
02AA = 55
0522 = AA
addr = data
This isn't the real command sequence used, but it's something like that. The difficulty of supporting this is that using two counters means you'd have to reset and increment to each address which would take a lot of time.
One method would be to use two shift registers tied together and two loadable counters instead of the 4040's so you could shift in an 16-bit address, then load that into the counters which is in turn presented to the cartridge address bus.
You'd still want to keep the counting feature for writing SRAM or dumping ROM (all sequential accesses) but you'd use the shift registers mainly to set the address for a flash memory command.
Even then I don't know if this would be fast enough, but I'm trying to think of what would be a cheap addition that wouldn't require too many modifications.
Some flash memory is in-circuit / in-system programmable but they end to come in less user friendly packages (PLCC, not DIP) and would be difficult to add to a SMS cart, unless you had one of those PLCC to DIP prototyping adapters (which aren't cheap).
|
|
| Back to top |
|
|
Bart T.
Guest
|
|
|
Posted: Sat Jan 08, 2005 7:15 pm |
|
|
| Charles MacDonald wrote:
|
One method would be to use two shift registers tied together and two loadable counters instead of the 4040's so you could shift in an 16-bit address, then load that into the counters which is in turn presented to the cartridge address bus.
|
I'm trying to build a circuit just like this for programming a 29EE512 (an AT29C512 compatible part, I believe -- 64KBx8 flash.) The circuit is complete and there are 4 shift registers: 2 74HC164s to load the 16-bit address, a 74HC164 to load the 8-bit data, and a 74HC165 to retrieve data.
Unfortunately, I haven't been able to get the flash to respond properly. I'm trying to read the software ID code from the flash which is obtained with a series of 3-byte codes but no luck. I think one problem may be that I have the data write and read shift registers both connected to the flash I/O pins. I figured if I loaded the data write register with 0 before issuing a read command to the flash, the flash I/O pins would be able to drive this bus and the '165 would be able to read out the data.
Is something like a multiplexer absolutely required when trying to read/write the same set of pins with different devices?
|
|
| Back to top |
|
|
Charles MacDonald
Joined: 28 Sep 1999
Posts: 779
|
|
|
Posted: Sat Jan 08, 2005 11:38 pm |
|
|
| Quote:
|
Unfortunately, I haven't been able to get the flash to respond properly. I'm trying to read the software ID code from the flash which is obtained with a series of 3-byte codes but no luck. I think one problem may be that I have the data write and read shift registers both connected to the flash I/O pins. I figured if I loaded the data write register with 0 before issuing a read command to the flash, the flash I/O pins would be able to drive this bus and the '165 would be able to read out the data.
|
This will cause a bus conflict, the write register will be pulling the data bus low if it's loaded with zero, and the flash will attempt to pull it high (depending on the data) , so you'll probably just get garbage (or damage either the memory or shift registers)
Because the '165 doesn't have an output enable, you should put a buffer between the two like a 74HC244 to disable the write register's outputs so the flash can freely set up the data bus for the read register. The 74HC245 does the same thing but has a nicer pin layout for working with 8-bit busses.
You could use a multiplexer too, but it would be simpler to wire in one buffer chip rather than two '157 ICs.
This probably isn't too important, but one thing I noticed with flash memory is that any access to it outside of the listed sequence of commands will 'reset' the command status, and you have to start over again. If you still can't get correct data after the hardware change I mentioned, you may want to ensure that there is no spurious or unintended activity on the /WR or /OE pins.
|
|
| Back to top |
|
|
Bart T.
Guest
|
|
|
Posted: Sun Jan 09, 2005 12:48 am |
|
|
| Charles MacDonald wrote:
|
Because the '165 doesn't have an output enable, you should put a buffer between the two like a 74HC244 to disable the write register's outputs so the flash can freely set up the data bus for the read register. The 74HC245 does the same thing but has a nicer pin layout for working with 8-bit busses.
|
The '164 has a /MR signal which functions somewhat like a /CE -- but it's just intended for resetting the outputs to 0 quickly as far as I can tell. I'll try looking into ordering a 74HC244 -- it's going to be a pain to wire it up as my breadboard has no room left on it. I'm also afraid that more chips might mean more interference. Not all of my signals are passed through an HC14 as they should be to reduce noise -- just the ones that absolutely need to be. I hope I don't have to rebuild the whole circuit on 2 boards :/
Right now I'm snowed in so I can't make it to town to pick up a '244 but I'll probably have it by next weekend and I'll post here if I can get this project working.
BTW, do you know if there is a maximum time that the flash can wait between signals before it resets? You mentioned using shift registers might not be fast enough to program the flash. The parallel port in standard mode is slow enough (I don't actually know what speed it's operating at but I don't think signals can be generated much faster than in the 10's of KHz range) as it is...
|
|
| Back to top |
|
|
Charles MacDonald
Joined: 28 Sep 1999
Posts: 779
|
|
|
Posted: Sun Jan 09, 2005 1:30 am |
|
|
| Quote:
|
The '164 has a /MR signal which functions somewhat like a /CE -- but it's just intended for resetting the outputs to 0 quickly as far as I can tell. I'll try looking into ordering a 74HC244 -- it's going to be a pain to wire it up as my breadboard has no room left on it. I'm also afraid that more chips might mean more interference. Not all of my signals are passed through an HC14 as they should be to reduce noise -- just the ones that absolutely need to be. I hope I don't have to rebuild the whole circuit on 2 boards :/
|
Yeah, setting the outputs to zero isn't quite the same thing as tristating it's outputs which is what the buffer will do. I'm sure somebody (Phillips perhaps: http://www.standardproducts.philips.com/products/shiftregisters/parametric/) has a similar part with an output enable feature.
I know what you mean about problems with not enough room on the breadboard, my last project took up all the space so I couldn't add any bus drivers, and the long wire lengths caused some problems as a result. I guess that's the point when you move the design over to a PCB. :)
| Quote:
|
BTW, do you know if there is a maximum time that the flash can wait between signals before it resets? You mentioned using shift registers might not be fast enough to program the flash. The parallel port in standard mode is slow enough (I don't actually know what speed it's operating at but I don't think signals can be generated much faster than in the 10's of KHz range) as it is...
|
I think it can wait indefinitely; which is why one of the commands is a reset command for that purpose. My reference to speed was more about programming it in a reasonable amount of time (for the end user to notice) rather than what the chip's requirements, though in retrospect I'd bet shift registers would be more than fast enough (you'd only need 32 I/O port writes to clock in 16 bits of data to set the address, rather than incrementing a counter from 0 to $5AA or something like that)
|
|
| Back to top |
|
|
Bart T.
Guest
|
|
|
Posted: Sun Jan 09, 2005 1:48 am |
|
|
Indeed they do: The 74HC595 seems to be exactly what I need. I'm not entirely clear on how the storage register relates to the shift register but it should be simple to figure out.
| Quote:
|
|
I guess that's the point when you move the design over to a PCB. :)
|
If I get this thing working, I plan on learning how to make PCBs because I'll need one. Right now, wires are wrapped over the flash itself which means it's not easily removable.
I'm also going to need a different power supply. I'm using the 5V and GND leads from a normal PC power supply but that's rather unweildy ;) I've had problems with batteries in the past but I think a battery + voltage regulator should work fine. I can't imagine this thing drawing very much power.
|
|
| Back to top |
|
|
Bart T.
Joined: 09 Jan 2005
Posts: 7
Location: Reno, Nevada, USA
|
|
|
Posted: Wed Jan 19, 2005 6:27 am |
|
|
| Bart T. wrote:
|
Right now I'm snowed in so I can't make it to town to pick up a '244 but I'll probably have it by next weekend and I'll post here if I can get this project working.
|
I added in a '595 and it appears to be working. I only had time to test the device ID read-out but I'm hoping that this confirms the hardware is complete and working properly and the rest should be a matter of finishing the interface software. If there's any interest, I'll post schematics and source code online when I'm finished.
|
|
| Back to top |
|
|
Charles MacDonald
Joined: 28 Sep 1999
Posts: 779
|
|
|
Posted: Wed Jan 19, 2005 6:52 pm |
|
|
| Quote:
|
I added in a '595 and it appears to be working. I only had time to test the device ID read-out but I'm hoping that this confirms the hardware is complete and working properly and the rest should be a matter of finishing the interface software. If there's any interest, I'll post schematics and source code online when I'm finished.
|
I'm interested, especially as I haven't seen any other projects for cheap flash programmers.
When you've had more time to test, can you mention what the programming/erase speeds are? Curious about it's actual performance.
|
|
| Back to top |
|
|
Bart T.
Joined: 09 Jan 2005
Posts: 7
Location: Reno, Nevada, USA
|
|
|
Posted: Wed Jan 19, 2005 11:37 pm |
|
|
| Charles MacDonald wrote:
|
When you've had more time to test, can you mention what the programming/erase speeds are? Curious about it's actual performance.
|
I will but keep in mind that my design only works for the 64KB flashes (AT29C512 and compatibles.) Extending it to support similar but higher density chips should just be a matter of chaining another shift register to the existing ones.
I haven't yet written the code to program the flash so we'll see how that goes tonight or tomorrow when I've got some time :)
BTW, does anyone know what speed the parallel port operates at in standard mode? Is it tied to the 8MHz ISA bus? I've heard that, realistically, it's good for KHz-range signals but not much higher unless you use the extended modes. I've never been able to find any useful data on the speed.
|
|
| Back to top |
|
|
TheAssassin
Joined: 06 Jan 2005
Posts: 36
|
|
|
Posted: Thu Jan 20, 2005 12:30 am |
|
|
Sorry to sound stupid, but...
What is SMSReader?
What is a Schematic?
|
|
| Back to top |
|
|
Maxim
Site Admin
Joined: 19 Oct 1999
Posts: 7546
Location: London, UK
|
|
|
Posted: Thu Jan 20, 2005 9:46 am |
|
|
| Bart T. wrote:
|
|
BTW, does anyone know what speed the parallel port operates at in standard mode? Is it tied to the 8MHz ISA bus?
|
That sounds about right. A single port access takes a few us, and SMSReader usage doesn't speed up in line with CPU speed (the software parts speed up, the parallel port accessing is constant speed). This gives you some simplification on the software side because as long as the hardware can handle that speed, you don't need any software speed checks.
A little Googling finds:
| some guy wrote:
|
|
A simple parallel-port read or write does take one ISA-bus cycle, and on most systems, the bus speed is around 1.3 Mhz, so one cycle is a little under 1 microsecond. A complete data transfer on the original parallel port usually takes at least 4 cycles, however: check the Busy status, write the data, bring Strobe low, then high. On ports that support EPP and ECP modes, in these modes the port hardware does the handshake, and a complete transfer can take place in 1 bus cycle.
|
This is assuming "standard" port usage in 1996 using BIOS calls; the SMSRedaer is doing it all manually (controlling the pins directly) so that 4-cycle transfer is not applicable.
One thing to note is that port accesses under NT OSes require using a support driver to do the accesses in kernel mode. The context switch into kernel mode slows things down noticeably, perhaps up to 50%.
| TheAssassin wrote:
|
What is SMSReader?
What is a Schematic?
|
http://www.smspower.org/smsreader/
A schematic is like a circuit diagram and it is useful for organising layouts, especially when wanting to make a PCB (printed circuit board).
|
|
| Back to top |
|
|
Bart T.
Joined: 09 Jan 2005
Posts: 7
Location: Reno, Nevada, USA
|
|
|
Posted: Fri Jan 21, 2005 5:16 am |
|
|
| Maxim wrote:
|
A little Googling finds:
| some guy wrote:
|
|
A simple parallel-port read or write does take one ISA-bus cycle, and on most systems, the bus speed is around 1.3 Mhz, so one cycle is a little under 1 microsecond. A complete data transfer on the original parallel port usually takes at least 4 cycles, however: check the Busy status, write the data, bring Strobe low, then high. On ports that support EPP and ECP modes, in these modes the port hardware does the handshake, and a complete transfer can take place in 1 bus cycle.
|
This is assuming "standard" port usage in 1996 using BIOS calls; the SMSRedaer is doing it all manually (controlling the pins directly) so that 4-cycle transfer is not applicable.
|
I found that site right after I posted and emailed the author. He said that achieving a 1MHz signal rate on the parallel port in Windows is indeed not possible because you have to go through a driver (requiring a permission-level switch by the processor as you stated.)
| Quote:
|
One thing to note is that port accesses under NT OSes require using a support driver to do the accesses in kernel mode. The context switch into kernel mode slows things down noticeably, perhaps up to 50%.
|
Apparently it's not just NT. I test my hardware with my old PC which is still running Win9X. I was having some bizarre problems writing to the flash and I think the reason is that even Win9X may be trapping port writes or, if not, it's interfering with the timing in some other way (multi-tasking?) It's a 180MHz machine so it's conceivable that even task switches might be screwing things up.
The flash actually has a timeout period of 150 microseconds in the programming mode. If a byte transfer for the current sector does not occur within this period, the flash enters programming mode (the 128 byte sector buffer is committed to flash as-is) and no more data is accepted until this is complete. I was seeing some strange behavior: I wrote 64 bytes of data and then tried reading it back -- it seemed to work pretty well (with the occasional erroneous 0xFF here and there), but if I tried reading it again, it wouldn't be there. I'm assuming the flash was just spitting out what was in its buffer and was refusing to program it because of timing violations.
When I rebooted in DOS mode, it appeared to work fine.
Given that it takes over 24 cycles to load an address and the corresponding data in my circuit, timing is of the essense. Each parallel port access is actually 2 cycles in my code because I flush both the data port and the control port. If the OS delays this by a factor of 4, it'll take 24 x 8 = 192us to send the next byte which exceeds the timeout period. I can reduce it by 8 cycles if I parallelize the data and address loading.
So my plan is this: I'll finish the software and release the schematics and code in case anyone still wants it, despite the limitations. This is actually enough for my purposes. I can probably use this simple programmer circuit to develop a more sophisticated one using an MCU to perform the actual programming and interfacing to the PC.
I still need to do some more testing, however. The programming and read-back aren't consistent -- some of the data is corrupted (0xFF) but it's difficult to determine whether it happened during the programming phase or when I'm reading it (some of it is definitely happening during the latter.) I think the culprit is interference on some of the signal lines. I'm supposed to be passing everything from the port through 74HC14s but I only do so for a few signals. I've had problems with interference in the past that the '14 has solved.
I might be able to cram another one on the board but I'm really running low on real-estate so I might just stick it in the schematic and hope it works for anyone else trying to build it ;)
|
|
| Back to top |
|
|
Maxim
Site Admin
Joined: 19 Oct 1999
Posts: 7546
Location: London, UK
|
|
|
Posted: Fri Jan 21, 2005 9:49 am |
|
|
| Task switching will introduce large enough delays in your code for bad things to happen if you're under such strict timing constraints. The "Time Critical" process priority level is designed for such situations, but may not be enough and should be used only when necessary to avoid killing your system. You might also need to put up a "don't move the mouse or keyboard" message and advise users to close all non-necessary programs, which is a bit of a nightmare (but less so that trying to run in DOS on a Windows XP machine).
|
|
| Back to top |
|
|
unfnknblvbl
Joined: 12 Jul 1999
Posts: 814
|
|
|
Posted: Sat Jan 22, 2005 8:13 pm |
|
|
how feasable is it to adapt the design to be (native) USB instead of LPT?
Five years from now, we probably won't have LPT ports on our computers - although I guess Intel was planning on that happening "in five years" eight years ago...
|
|
| Back to top |
|
|
|
smsreader_schema_rev02.png
