Reading ROM chip with QuickStart
justjoey
Posts: 5
I recently bought a QuickStart board. I'm following along with this wonderful post on how you can read a ROM chip with an arduino (https://www.nycresistor.com/2012/07/07/stick-a-straw-in-its-brain-and-suck-how-to-read-a-rom/)
I connected my chip (TS27C64A) with all of the pins on the right side into the even-numbered pins on the Prop. And all of the pins on the left side of my chip into the odd-numbered pins of my Prop. Now, I just need to figure out how to translate the arduino code(https://github.com/phooky/PROM/blob/master/tools/eeprom_read/eeprom_read.pde) into C code for my propeller. I was wondering if anyone could help me?
I connected my chip (TS27C64A) with all of the pins on the right side into the even-numbered pins on the Prop. And all of the pins on the left side of my chip into the odd-numbered pins of my Prop. Now, I just need to figure out how to translate the arduino code(https://github.com/phooky/PROM/blob/master/tools/eeprom_read/eeprom_read.pde) into C code for my propeller. I was wondering if anyone could help me?
Comments
You would have a 16-bit address variable which would be shifted out to the 74HC595s while the resulting data byte was read in from the 74HC165.
The 5V that Arduinos operate on is a real throwback which means it can interface with all the old 80's and 90's tech like 5V EPROMs directly, not that I could see any real use for that but they must have a terrible time interfacing to modern 3.3V devices.
Understandable, and I also tend to conserve pins, cogs, and memory when I design something. OTOH if the board is to be dedicated to one task or is an interface that plugs in to the 40 pin quickstart/project board connector it makes sense to use as many pins as required to minimize external hardware.
That is true...I recently worked with a guy who designed a piece of hardware to do something (can't be more specific). And I questions why he set things up the way he did. He didn't really have an answer, but later wanted to expand his idea and had he thought ahead a bit he'd have been able to do that easily.
But when it comes to conserving I/O pins in a design I am all for it, I could never understand why some designs use up so many I/O pins without any thought to design flexibility, being able to adapt for changing needs or simply expansion. The I2C bus (using the same pins as the EEPROM since it's a bus) are always brought out to a standard connector with ground and +5V and always I have these lines available as another 4 pin row as part of the Prop plug header. This becomes my direct connection to the EEPROM for cloning or as an expansion connector in runtime use. The I2C SCL and SDA also serve as SPI CLK and MOSI data in many designs as there is no conflict either. I have never had any need to run separate I/O for another I2C bus except once where I had I/O left over and the pcb layout was very tight.
For RS485 I only need 2 I/O, one for transmit/receive data and one for transmit/receive enable. For audio out stereo is really redundant (isn't it?) so I just run mono to a stereo jack. Parallel LCDs I run in write only mode since read mode is redundant and problematic and although I have a tendency to run 8-bit vs 4-bit data it's because I frequently use the same lines for a 4x4 keypad (the LCD data bus has its own pullups too). If I/O is scarce then LEDs always belong on a shift register or I2C expander, you can put as many as you like on your board and not use up any I/O or maybe one as the latch for a shift register running from I2C CLK&DAT.
For A/D many discrete A/D converters are limited and relatively expensive whereas a $1 PIC/AVR/8051 style chip is easily programmed and can interface via I2C or even just automatically stream out conversions in single pin asynch serial as I do over isolation barriers.
Not only can you optimize I/O but you can also rationalize connectors. Why for instance do you really need a big VGA connector or even PS/2? These are easily handled off board via a short pin header to "a whatever you need" cable while the otherwise small pcb stays clean and simple. In fact many PS/2 compatible keyboards these days are USB with PS/2 protocol availble, the "adaptor" does nothing and is bulky, so just connect the USB plug to a USB socket and talk to it in PS/2 protocol. Now talking about optimizations I see that many designs still use ancient and bulky HC49 style crystals when there are so many tiny SMD or cylindrical products available that are even cheaper too, including MEMS oscillators. The HC49 blocks so may I/O pins yet a small SMD crystal/TXO can sit right up against the Prop and you still have plenty of room to route I/O cleanly. I think I said enough for now
I appreciate everyone's magnificent input. I am learning so much on this topic and am excited to learn more. If you have any ideas of projects I could do to learn more about the Prop, please let me know. I am always willing to learn.
That's great joey, btw, welcome to the Parallax forum! But even us experienced guys wouldn't bother trying to find out about old instruments by reading binary code from EPROMs. You really need the source code, not even a good disassembly listing is of much use either unless you were really determined and had lots of time. Error codes are horrible things, who really knows what they mean? This is a lesson that you can take to heart and if you ever design something that others have to use, then put in helpful diagnostic messages, even if they are only reported via an optional serial terminal or logged on an SD card, it is always better than those dreaded "error codes".
Once you hook up those shift registers and start reading EPROMS, which takes a few seconds at most per EPROM, what do you do with your reader, it's got nothing left to do as you spend weeks disassembling and reconstructing the source from those binary images
I have many interests. Right now, I have all of these old circuit boards that have a lot of classic chips on them (like the 6800 mcu). I want to see if I can interface with them and use them with the prop. There are several RAM chips, I got a whole bunch of flash chips, and a bunch of other generic stuff. It's not so much what I can use the chips with in larger projects, as much as it is learning about interfacing with them. But that's for now.
I really like working with code close to the hardware level, as opposed to what I usually do at the higher levels. That's why I asked for input (and I may be drifting off the original topic) as to what I should do next. While I'm waiting for my parts to come in, I'm trying to come up with other things to do with my Prop.
I have a bunch of "Octal Buffer/Line Drivers" that I have no clue what they are. Maybe I can figure out those and what I could use them for lol.
If you want "junk" I can ship it over by the crate load but why waste your time with chips that were designed for 5V and data and address buses when modern MCUs have no need for these chips and trying to use them is so clunky and redundant. I have a lot of fun with the Prop as it is, interacting live with the hardware at the hardware level using my Tachyon Forth and getting instant results. If you really like playing with hardware you should try it, it is a lot of fun and very productive.
Not very useful unless you are trying to put whatever machinery it was connected to back into use, but definitely very educational. The propeller can emulate most of the older minicomputers/microprocessors at or close to their original speeds.
@justjoey
I think i can help you,
I like these old EPROMS with the magic Window
I created this Schematic:
Tested with 2764 (8K), 27128 (16K), 27256 (32K) and 27512 (64K).
It works good for me.
Have Fun
Werner
How about a limited anniversary edition Propeller D40 with a moon roof, and an RGB LED to showcase it.