Dumping an old parallel rom using an atmega328p

Last post
19 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey folks,

I'm just tinkering around with some old hardware. I have some old PROM chips from the Commodore 64 (info available here http://symlink.dk/nostalgia/c64/rom/ ). I got the idea that it would be a fun project to try to read them just for the practice and fun of it.

So I'm going to use a couple of shift registers for the address lines, and I will wire up the digital output directly to the avr.

I have a few questions:

1. Does anyone know if I need to worry about voltage on these old chips? I think 5v should be fine but I don't want to fry anything!

2. In terms of sending out the address I want to read, I know that A0-A4 are column and A5-A12 are row, but I'm not sure how to determine what addresses I should send to each. Do I just start at 0x00 and increment?

3. /CS do I hold CS high or low? Or does the chip do that to tell me when to read?

Thanks guys

Mark

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

2) Starting from 0 and incrementing should be correct, but the C64 may have done something strange with the hook-up of the address lines.

3) Hold it low.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Row and column addressing is something from the DRAM world, not simple parallel ROMs ;)

From the description on the symlink.dk site I don't think Commodore did anything strange with the address lines, just plain sequential hookup; e.g. A0..A11 are really connected to A0..A11 of the CPU.

I would not bother with shiftregisters. It's just 21 lines so you need an AVR with 21 spare GPIOs. Where does the read data end up? Sent to a PC via a serial link?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jayjay1974 wrote:
Row and column addressing is something from the DRAM world, not simple parallel ROMs ;)

From the description on the symlink.dk site I don't think Commodore did anything strange with the address lines, just plain sequential hookup; e.g. A0..A11 are really connected to A0..A11 of the CPU.

I would not bother with shiftregisters. It's just 21 lines so you need an AVR with 21 spare GPIOs. Where does the read data end up? Sent to a PC via a serial link?

Yeah I was going to send it over via serial.

The datasheet shows Row and Column (http://www.zimmers.net/anonftp/pub/cbm/documents/chipdata/2364.zip) on the last page. "Column Decoder" and "Row Decoder"

Thanks for all the help guys, you're great!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The datasheet shows Row and Column

That's just showing how the device is organised internally. From an external perspective you simply count A12..A0 from 0x0000 to 0x1FFF and you get each byte in turn output on D0..D7. Simple as that.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A simpler way of creating the address is to use a 74hc4040 counter. You only need two ports bits- reset and clock.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Read the 8 bit data byte at each location and look up the 6502 mnemonic and how many bytes of operand address for that opcode and you can just print out the disassembled dump.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

The datasheet shows Row and Column

That's just showing how the device is organised internally. From an external perspective you simply count A12..A0 from 0x0000 to 0x1FFF and you get each byte in turn output on D0..D7. Simple as that.

Wow. That is just way too simple ;)

Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

That is just way too simple

1970's..1980's computer technology WAS that simple ;-)

In fact ROMs were often used as state machine/pattern generators. Without a micro you could have the D0.D7 behave differently according to the input A0..An. For example you could simply have a counter that ran through the addresses and the 8 outputs were effectively completely programmable at each step - no need for a micro in this.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My homebrew processor (avrfreaks passim) used eeproms as the arithmetic logic unit; four bits in from each of two operands, plus a carry in, and three (four?) bits to define the operation; four bits plus carry and zero out. Two of those used together gave me the eight bit ALU in two chips instead of a whole eurocard full of 74 logic. It ate current, though, and was nowhere near as quick...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I used to repair those things years ago.
I do not know if I have any old chips left over.
However this article is useful for other old tech.

:)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or use an AVR with external memory access and talk to the ROM using an 8-bit bus structure with an address latch. I know the Mega8515 will do this, not sure if any newer AVR's still support external memory.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dksmall wrote:
not sure if any newer AVR's still support external memory.

Any of you AVR part gurus feel like filling in the blanks on this?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried finding out using the parametric table on the Atmel site. It's useless!

But what is the definition of newer? ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The 8515, mega162, nega64, mega128 all have external memory interfaces to my certain knowledge. Not sure of others though a grep of the .h files for the right control registers should weedle them out.

Needless to say that most of the "large pinout" Xmega all have an EBI which I guess is the modern way to do it.

EDIT: A look at a few datasheets seems to suggest the XMEM devices are likely to have SRW01 (to do with wait state select) so...

E:\WinAVR-20100110\avr\include\avr>grep SRW01 *.h
iocanxx.h:#define    SRW01       1
iom128.h:#define    SRW01        3
iom161.h:#define SRW01  3
iom162.h:#define SRW01  3
iom32u6.h:#define SRW01 1
iom64.h:#define    SRW01        3
iom8515.h:#define    SRW01        3
iomxx0_1.h:#define SRW01   1
iousbxx6_7.h:#define SRW01   1

That would seem to confirm I listed most of them above.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jayjay1974 wrote:

But what is the definition of newer? ;)

Newer then a Mega8515. 8)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The 64's 6510 used banked switching, as it had 64k of RAM and just 16 address lines. The ROM was found in the second bank.

For you reference the reset vector for the 64 is $FFFC-$FFFD, that should point you to the start of the 64's Kernal (kernel) at $E000 if you are interested in investigating it.

I would use a 7400 series parallel latch for addressing but remember the prom's would be very slow, even by the standards of todays slowest EEPROM's. Make sure this timing issue is taken into account.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Forgot about a bug I had reported about devices that have external ram, the keyword was XRAM. Thanks to Cliff's example above I came up with this list of devices with XRAM that are listed in the Studio 6.0/devices folder. Seems to be missing a couple of the devices that were indicated in Cliff's list above.

C:\Program Files (x86)\Atmel\Atmel Studio 6.0\devices>grep XRAM *.xml
AT90CAN128.xml:   
AT90CAN32.xml:    
AT90CAN64.xml:    
AT90USB1286.xml:  
AT90USB1287.xml:  
AT90USB646.xml:   
AT90USB647.xml:   
ATmega128.xml:    
ATmega1280.xml:   
ATmega1281.xml:   
ATmega128A.xml:   
ATmega162.xml:    
ATmega2560.xml:   
ATmega2561.xml:   
ATmega64.xml:     
ATmega640.xml:    
ATmega64A.xml:    
ATmega8515.xml:   
=====================================================================================================

OT: I liked it better when I was in the UTC+1 time zone.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys,

I did it :) In case anyone cares, the chip I am dumping contains the 901227-2 kernel - the program just spits out the hex values of each memory location. Maybe I'll write something in Python to save a .bin file for me now :)

Here's a screen shot of the terminal:

I didn't have an avr with enough pins to spare so I cheated and used a PIC18F4520 that I had on the bench. Fun stuff - thanks for your help!