This is only a preview of the June 2004 issue of Silicon Chip. You can view 17 of the 96 pages in the full issue, including the advertisments. For full access, purchase the issue for $10.00 or subscribe for access to the latest issues. Items relevant to "Dr Video Mk.2: An Even Better Video Stabiliser":
Items relevant to "An RFID Security Module":
Items relevant to "Fridge-Door Open Alarm":
Items relevant to "Courtesy Light Delay For Cars":
Items relevant to "Upgraded Software For The EPROM Programmer":
Purchase a printed copy of this issue for $10.00. |
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
|