Fullscreen HTML5Med Res (??MB)HTML4

Upgraded software for the Windows-based Eprom Programmer The Windows-based EPROM Programmer design published in the November 2002 February 2003 issues has been very popular but since then a small number of bugs have been discovered in the software. These have been fixed and the upgraded software is available on our website. By JIM ROWE W HEN I PRESENTED the software for the EPROM Programmer back in the February 2003 issue of SILICON CHIP, I had spent quite a bit of time writing and debugging it. So when we published it, we thought it was pretty free of bugs. Well, it’s probably not surprising that once people began to use the software, the first version turned out to have a few minor bugs. I discovered one myself, when I went to program a bunch of 512KB EPROMs recently. So there was nothing for it but to fire up Visual Basic 6.0, track those bugs down and fix ’em. While I was at it, I also took the opportunity to make a few small improvements to the program. So we have now been able to put an updated and revised Version 1.3 of the software on the SILICON CHIP website, ready to be downloaded and installed by anyone who has built the EPROM Programmer. You’ll find it in a single 1.7MB zippedup file called EPROMProgV13.zip but if you’d like to look at a copy of the VB6 source code, this is also available as a 82  Silicon Chip PDF file (EPROMProgV13.pdf). What’s changed Probably the most irritating bug in the first version was one in the EPROM verify routine. It was a missing variable type conversion in the statement which works out the original address of a data byte read back from the EPROM in the program’s storage array, so it can compare the two. Because one of the array address variables was in integer form, the statement produced an overflow error as soon as the verify routine reached the first EPROM address beyond 32,767. So the bug didn’t show up if you were programming and verifying EPROMs of 256Kb (32KB) or smaller, but the program would crash with an “Overflow Error 6” when you tried to verify larger EPROMs. The annoying thing is that this same overflow error had originally shown up in the program’s main EPROM reading and programming routines, for the same reason, and I had fixed them by adding a variable type conversion (integer to long) in the appropriate statements. I thought I had fixed the verify routine at the same time but apparently not. The type conversion is definitely in that routine now, so you can now verify the larger EPROMs without an overflow problem. By the way, you could still read and program larger EPROMs with the first version; the error occurred only during verifying. The other main bug was that the program would often get “confused” about where its configuration file had been stored by the last session and would not be able to find the config file when it started up – forcing you to feed in things like the Programmer’s port address all over again. This turned out to be due to not specifying the full path for the config file in the program’s config file save and load routines – just the file’s name. So in version 1.3, the full path is specified in both routines, to ensure that the program always saves the config file where it can find it again next time. Improvements As well as fixing these bugs, an “About” item has been added to the main menu of the program. This allows you to easily check at any time which version of the software you’re running. When you click on this menu item, the program displays a small dialog box with the version details and so on. A couple of small changes have also been made to the main programming routine, so if you’ve indicated at the start of programming that you want it to verify after programming, it doesn’t siliconchip.com.au Fig.1: the latest version of the EPROM Programmer software includes an “About” item, which allows you to check which version you have running. give you a “Programming Completed” dialog at the end of programming – it just proceeds automatically with verifying. This is a little more convenient than with the first version, where you had to click the “OK” button in the dialog each time before it started to verify. It also speeds up the combined operation. Still one problem So the new version 1.3 fixes the known bugs in the EPROM programming software and is also easier to use. But note that there’s still one problem remaining: with some newer PCs, it seems to be almost impossible to get the software to communicate correctly with the EPROM Programmer hardware. In the February 2003 article, we mentioned that with some of the newer PCs fitted with “integrated” on-board EPP or ECP printer ports, you would very likely have to experiment with different port configurations in the machine’s BIOS before you’d get correct operation. This was based on my experience, where I had great trouble getting correct software-hardware communication on some machines until I tried changing the printer port’s BIOS configuration. However, even this doesn’t seem siliconchip.com.au to solve the problem with some machines. In fact, some of them seem to be extremely unwilling to allow any direct communication between the EPROM Programmer software and hardware – so you can’t even get the software to light the hardware’s LED3 in the Test dialog. I still haven’t been able to find out whether this is due to Windows simply not allowing direct communication with the printer port or if there’s some other cause like an extra “security feature” in the BIOS or chipset firmware of these machines. So at present, all I can suggest is that to use the programmer with these machines, you might have to add an extra printer port via a PCI card and use this instead of the integrated port. Hopefully, an add-on port won’t be quite so firmly in the iron grip of the BIOS and Windows and will allow the programmer software and hardware to talk to each other more readily. But if this still doesn’t happen, you might have to use the programmer with a different PC. It’s possible that the final solution will be to come up with new hardware for the programmer, using a USB interface instead of the printer port. That is a project which will have to wait for SC another time. Want really bright LEDs? We have the best value, brightest LEDs available in Australia! Check these out: Luxeon 1 and 5 watt LEDs All colours available, with or without attached optics, as low as $10 each Lumileds Superflux LEDs These are 7.6mm square and can be driven at up to 50mA continuously. •Red and amber: $2 each •Blue, green and cyan: $3 each Asian Superflux LEDs Same size and current as the Lumileds units, almost the same light output, but a fraction of the price. •Red and amber: Just 50 cents each! •Blue, green, aqua and white: $1 each. Go to www.ata.org.au and check out our webshop or call us on (03)9388 9311. June 2004  83