EPROM emulator boards

[Bruce Plecan]

-----Original Message-----
From: Andrew K. Mattei <amattei at mindspring.com>
To: gmecm at esl.eng.ohio-state.edu <gmecm at esl.eng.ohio-state.edu>
Date: Tuesday, March 30, 1999 3:24 PM
Subject: Re: EPROM emulator boards

Personally since you have to stop, to do the program change what is the
issue with restarting the engine??????.
  Lets not go for all the glitter and just get something reliable, and
useable.
My thoughts are build two of them.
Have someone(s) test drive them, on a bench or inna car, and then make the
info available for all.  Opening this up to a GP before one is even made is
a formula for disaster in my book.
Bruce

>I just looked at the board a little closer, and have a couple of comments /
>concerns that I'd like to present / discuss... (oh Jeez, here he goes...
>;-D)
>
>The basic premise of operation is very similar to the emulator I had in my
>mind. It uses a serial port (with UART) instead of a parallel. However...
>
>It also relies on the 4040-IC for address information. This is done with a
>clock pulse causing an increment in the binary counter. I built an EPROM
>programmer from a design using this technique (see
>http://www.zws.com/products/epromr2/index.html ). I was rather disappointed
>with the results. The problem with this design (which operated at a higher
>speed than the 9600 baud unit), was that the clock would not run at a
>consistent rate - so, I'd do five reads of an EPROM and they'd all be
>different. Perhaps the 9600 baud unit, along with the fixed on board clock,
>helps resolve this problem. Still, the unit does not provide any feedback
>that your hardware and software are on the same address when programming
the
>emulator. I had put the low 4 address bits from my counter coming back
>through the parallel port - so I'd at least know that my hardware and
>software were in sync (remember, I did not build this thing, just designed
>it in my brain...).
>
>Steve's email just popped in to my box. "Edit while you drive" is a feature
>we (as a group, I think) had hoped for. That is why I was thinking of a
>dual-bank design - you have a flash on one side that contains code, and ram
>on the other - and it would use this sort of design. Yes, you have to push
a
>button to reset the counter IC to 0, but you can let the motor keep
>running... ;)
>
>A PIC would still be the "best" design (could program via non-sequential
>addresses (don't have to run up through the counters and press the reset
>button at the end), could provide very accurate feedback, etc...)... Albeit
>more expensive... Any thoughts?
>
>-Andrew
>