USB-connected ROM emulation?

[BigEd]

Elsewhere, a question:

Druzyek wrote:

Just out of curiosity, does anything exist that plugs into the ROM socket and connects to a PC over USB so that it can quickly be reprogrammed without removing it?

I'm not aware of anything for the hobbyist. (For €300 you can get something.)

But this seems like a good project. Something like an Arduino Mega might do it - you need 5v interface, some 26 I/Os, and enough speed to obey the bus timing.
http://arduino.cc/en/Main/ArduinoBoardMega2560
At 16MHz clock speed, it should be possible to interface at 1MHz and maybe even up to 4MHz.

Possibly you could hook up a dual-port RAM for a faster solution.

One of OHO's FPGA modules might be useful, but I don't think they offer USB and would be significantly more expensive.

Any ideas?

[Dr Jefyll]

Quote:

But this seems like a good project.

I had the same thought myself. I'm surprised the market hasn't provided a reasonably-priced solution. BTW thanks for checking availability and for starting the thread. This idea deserves to be nurtured.

Dual-port RAM sounds promising, although capacity might be a problem if it's a high-density ROM you're emulating.

-- Jeff

[BigEd]

Looks like a 40-pin PIC16 might have enough I/Os and CPU speed to do the trick - and therefore probably some higher-end PICs too. I would expect to find a mini dev board in DIL format, but haven't yet found one. Maybe something like this
http://proto-pic.co.uk/dl40-module-daisylink/

The Teensy 3.1 is a small ARM-based board, about $20, 5V tolerant and with enough I/Os.
https://www.pjrc.com/teensy/teensy31.html

[GARTHWILSON]

ROM emulators were common back when software development was commonly done in EPROMs, to get a quicker cycle than removing the EPROM and putting it in the eraser, taking another one, putting it in the programmer, sending your software to the programmer, programming the EPROM, and then moving it to your board. Instead, the PC would just send the software to the ROM emulator, eliminating the plugging and unplugging, erasing, and programming parts of the cycle.

[Druzyek]

This would be a neat project which is why I was asking! In my opinion, it would be better to use a parallel SRAM so that it can work close to top speed and only use the microcontroller for programming. I seriously doubt you could get 4MHz out of a 16MHz chip and 1MHz might even be pushing it. You could also add a backup battery to the SRAM. The problem with doing it like this would be isolating the RAM from the bus while the microcontroller was programming it (assuming the system itself is halted but still powered on). Something like a 74AC244 would work but adds about 7ns to propogation delay. I don't know how fast the SRAM would need to be to accomodate the extra delay. Physical switches like dip switches could also work to isolate everything but that might add a lot of bulk to it. In any case, it would be a neat project.

EDIT: Why the dual-port RAM? Those tend to be very expensive. One port for the system and one for programming?
http://www.mouser.com/ProductDetail/IDT ... lbIVCXI%3d
http://www.mouser.com/ProductDetail/Cyp ... OXdnpnw%3d

[BigEd]

Yes, two ports so you don't need to isolate. 16kx8 should be big enough - that's £5.40

Edit: oops, looks like that's only 16kbit. See corrections below.

[HansO]

I have such an EPROM emulator, a design by the dutch magazine Elektor in the 80ties. Attached to the parallel port of the PC.
Works fine upto 1 or 2 MHz clock speeds.
It is the usual design with TTL and 6116 SRAM.

With EEPROM and ZIF sockets I do not use it often.

[BigEd]

(Hopefully such a parallel-port connected device doesn't demand much of the parallel port, and will work with a USB-printer adapter, for those of us who no longer have a parallel port.)

But you remind me, richarde had constructed an I2C-connected emulator called ROMBO:

which we used in the beeb816 project.

Also, I see BitWise has found a couple of pointers to contemporary industrial-strength devices:

BitWise wrote:

Yes. USB connected EPROM emulators exist.

https://www.eetools.com/index.cfm/produ ... ulator.cfm
http://www.batronix.com/shop/epromemula ... lator.html

But are a little pricey

[BigEd]

HansO wrote:

I have such an EPROM emulator, a design by the dutch magazine Elektor in the 80ties. Attached to the parallel port of the PC.
Works fine upto 1 or 2 MHz clock speeds.
It is the usual design with TTL and 6116 SRAM.

With EEPROM and ZIF sockets I do not use it often.

Here's the article, from December 1989:
http://techdoc.kvindesland.no/radio/yms ... 510828.pdf

Here's some info on a successor device, from Elector of September 1992:



And another one from 2001 (serial-connected).

Cheers
Ed

[BitWise]

Shouldn't need much to build one.

A RAM chip to hold the data
3x tristate line drivers/buffers to all allow the targets address and data lines to be isolated when changing the RAM contents
A GAL chip to arbitrate target and host access control signals
A micro-controller to load the RAM chip via USB or UART

Definely less than $300. Probably less than $30 on strip board.

[BigEd]

Do you think a bare PIC could do it? It needs only to pay attention to OE (and CS) and perform a lookup.

[BitWise]

BigEd wrote:

Do you think a bare PIC could do it? It needs only to pay attention to OE (and CS) and perform a lookup.

Potentially something like ..

Code: Select all

Inactive:
 setf TRISD  ; Tristate data bus
InactiveWait:
 btfsc PORTE,CS  ; Wait for /CS
 bra InactiveWait
 btfsc PORTE,OE  ; And /OE
 bra InactiveWait

Active:
 movf PORTA,W  ; Map address to ROM image
 movwf TBLPTRL
 movf PORTB,W
 andlw h'1f'  ; Mask on ROM size
 addlw high(ROM_BASE)
 movwf TBLPTRH
 tblrd *  ; Fetch data byte
 movf TBLDAT,W
 clrf TRISD  ; Set output
 movwf LATD
ActiveWait:
 btfsc PORTE,CS  ; Wait for /CS or /OE to change
 bra Inactive
 btfsc PORTE,OE
 bra Inactive
 bra ActiveWait

You could do the address mapping while waiting for CS and OE to go LO if the address is stable before these signals change.

Might work at 1Mhz.

It would be easier with a dsPIC 30F but you'd need to use a TQFP package with 64 pins or more. The port bit arrangement on the 40pin DIP 30Fs is not very convenient for mapping the data and address lines. The bigger packages, like 30F6012A, have a better port arrangement and using PSV memory makes the ROM lookup quicker.

[Klaus2m5]

In an ATMega it could look like this:

Code: Select all

wait_cs:                ;#.# = cyles in this section, 62.5ns @ 16MHz
   sbic  cs_port,cs_bit ;5.5 wait for cs loop, 3 latency + 2.5 if cs 
   rjmp  wait_cs
   out   dbusddr,allon  ;1 output enable
   in    zl,abuslo      ;2 get address
   in    zh,abushi
   sbi   zh,-offset     ;1 add page offset to ROM/flash address
   lpm   temp,z         ;3 load data from flash
;  ld    temp,z         ;  (2) alternativly load from RAM (limited)
   out   dbus,temp      ;1 data valid at the end of this cycle
;  nop...               ;x add fixed data valid cyles or wait for cs off
;     ...nop
   out   dbusddr,zero   ;1 output enable off
   rjmp  wait_cs

It would take a maximum of 13.5 cycles (almost 850ns@16MHz) for data to become valid after chip select was applied. You could do it only, if you run the target processor at reduced speed.

[BigEd]

Thanks for the proofs of concept. A pity it takes so many cycles!

[Druzyek]

Wow, you guys are really on the ball. Too bad just a microcontroller is not fast enough.

BigEd wrote:

Yes, two ports so you don't need to isolate. 16kx8 should be big enough - that's £5.40

Can you give us a link?

I think with SMD parts you could almost fit the RAM, microcontroller, and UART chip (like FT232) onto a DIP 40 breakout.