PET ROM/RAM replacement board

[peterkrola]

It would be a nice trick if it worked..
Just trying to make sure I understand the memory map used in the PET.

 

[Maverick1978]

I'm very late to the discussion, but if the object is just to replace the rom in a PET, wouldn't an adapter to replace the MOS 6540 with a 2716 EPROM be all that's necessary for replacement/debugging/fun as the OP originally stated?

There are schematics for such a board at www.6540rom.com

Note: I know little about PETs in general, and nothing about their hardware/addressing at all. I found this site in a quick search in looking for information to repair a blue-trimmed PET 2001-8 I recently pulled out of the electronics recycling bin at the local dump, and thought I'd post it here in case this was something similar to what was being looked for so that no one's recreating the wheel. Hope no one minds.

 

[MikeS]

I'm very late to the discussion, but if the object is just to replace the rom in a PET, wouldn't an adapter to replace the MOS 6540 with a 2716 EPROM be all that's necessary for replacement/debugging/fun as the OP originally stated?

There are schematics for such a board at www.6540rom.com

Note: I know little about PETs in general, and nothing about their hardware/addressing at all. I found this site in a quick search in looking for information to repair a blue-trimmed PET 2001-8 I recently pulled out of the electronics recycling bin at the local dump, and thought I'd post it here in case this was something similar to what was being looked for so that no one's recreating the wheel. Hope no one minds.

Don't mind at all.

Jim Brain sells a similar 6540 replacement adapter; apparently he was working on a revised version but I'm not sure what the current status is and am waiting to hear from him.

It didn't come with the EPROM, but was cheaper ($1.50 bare board, $5.00 assembled) and much more flexible. The main advantage over the one mentioned above is that Jim's had provision for using sections of larger EPROMs, so that by setting different jumpers you could either just use a 2716 EPROM to replace one ROM as the one mentioned above, or use a 128 or 256Kb chip and select whichever ROM image you wanted to replace; if you didn't mind running a few address jumpers to the main board you could even replace all the ROMs (two versions, even) with one adapter and one chip.

All in all, a useful little gizmo; I hope he still sells them and will report when I hear back (unless he jumps in here himself).

 

[Maverick1978]

Wow. Totally mind-blown here.. at my own stupidity I can't believe that I forgot to check Jim's site to see what he had for PET hardware. I guess in my mind, I still associate him exclusively with C64/128 stuff, as back about 12 years ago when I first ran across his site while in college, that's what I remember his focus being on!

Thanks for jogging my memory.. One more place to keep in mind. I'm hopeful that I've only a bad ram chip or two, however.... That would be amazingly lucky

 

[MikeS]

...I guess in my mind, I still associate him exclusively with C64/128 stuff, as back about 12 years ago when I first ran across his site while in college, that's what I remember his focus being on!

Well, C64 etc. is of course his main focus, considering how many of them are still out there and how active the various user groups etc. still are.

I'm hopeful that I've only a bad ram chip or two, however.... That would be amazingly lucky

Bad RAM? You do only need the lower 4 chips to run, so why not swap a few? What are the symptoms?

 

[dave_m]

if the object is just to replace the rom in a PET, wouldn't an adapter to replace the MOS 6540 with a 2716 EPROM be all that's necessary for replacement/debugging/fun as the OP originally stated?

Initially one might think so, but take the common situation where the PET does not come up at all. What ROM do you replace? The bad one will turn out to be the very last one you try (corollary to Murphy’s Law). Unsoldering several 24/28 pin ROMs is a daunting task. This new board will not require any mods on the PET main board. Simply pull the 6502 CPU from its socket and insert the board into the socket.

After the PET comes up, all is fine, but what if you want to restore the PET to its original condition and a ROM or RAM is bad? Assuming the screen comes up, simply configure the new board for Diagnostic Mode and run routines to check the main board ROM, RAM and I/O. Perhaps the new board will be fitted with LEDs so blink codes will report problems even if the CRT is not working.

What if there is a fault in the complex addressing logic and nothing will work even with the new board installed? No worries! Just configure the new board for NOP Generator mode and the CPU will cycle through all 64K address space. This will allow you to scope all the address lines and follow their paths with easy to see perfect square waves. When a square wave is not seen, you have found the problem.
-Dave

 

[MikeS]

Indeed.

If you have an old PET with socketed chips and know that it has a bad ROM and which one it is, then Matt dAsaro's 6540<>2716 adapter fits the bill; if you have access to an EPROM programmer then Jim's version is a little cheaper and more flexible.

(He does still sell them, although they can be a little hard to find and he only lists the bare board; AFAIK they're also still available assembled for around $5.00):
http://store.go4retro.com/categories/Commodore/Hardware/

Jim's adapter can also be very useful for diagnosing ROM problems in an old PET, but for diagnosing newer PETs with soldered ROMs and RAMs and/or other problems you really need what we're discussing here, something that can be selectively isolated from the data and address buses. Of course like Nicolas' board it can also just be a replacement for the hard-to-find 6540s & 6550s.

 

[bitfixer]

I took the first few steps today toward this new ROM/RAM board.. Made up a cable that plugs into the 6502 socket on the pet, and plugs into a breadboard on the other side. After fixing a couple of bad connections, my test PET is running properly with the CPU thus outboarded onto a breadboard. Now I can get to the task of wiring up the rest of the design to see how things work.
I have a basic design ready to test that uses an ATMega16 MCU, and a 628128 SRAM. I'm not completely sure, but after looking over 6502 timing diagrams, I believe I can use the MCU itself as the programmable logic device. With the MCU running at 16MHz, it should be just fast enough to read in the address bits, look up the appropriate chip selects from a table, and output the values to enable/disable the RAM during CPU reads/writes. Will keep you posted on progress..

 

[dave_m]

I'm not completely sure, but after looking over 6502 timing diagrams, I believe I can use the MCU itself as the programmable logic device. With the MCU running at 16MHz, it should be just fast enough to read in the address bits, look up the appropriate chip selects from a table, and output the values to enable/disable the RAM during CPU reads/writes. Will keep you posted on progress..

This would be quite a feat and save some parts. Assuming a 500 nS access time, using a 16 MHz clock (62.5 nS period) will allow only 8 clock cycles to perform the above tasks. Less if the 16MHz is asynchronous to the PET clock. Don't forget you have to wait until the address lines settle (rise of Phase 2 clock) before sampling them on the input port of the MCU. I see that the MCU you picked is a RISC type with mostly single clock instructions so that really helps. But you will need a jump instruction in there somewhere which will be multiple clock cycles.
-Dave

 

[bitfixer]

Well, I'm thinking that the method I would use for fitting this into 8 instructions would be to have a lookup table with the appropriate outputs for all possible inputs. It looks to me like this would fit into 4 or 5 instructions - read the high byte of the address bus (1 cycle), read the output value from the lookup table (2 cycles), then output the right value (1 cycle), then wait the right number of cycles and jump back to the start. I was thinking about clocking the MCU directly from the 16MHz signal on the motherboard. This would require a wire jumper, but that would not be too inconvenient.
If necessary these MCUs can be clocked at 20Mhz as well to get a few more instructions.

 

[dave_m]

I was thinking about clocking the MCU directly from the 16MHz signal on the motherboard. This would require a wire jumper, but that would not be too inconvenient. If necessary these MCUs can be clocked at 20Mhz as well to get a few more instructions.

gubbish,
OK, then you were thinking you would be synchronous with the PET so you only have to test for Phase 2 once to start the loop and then stay in sync without always testing for Phase 2 clock going high which would save a couple of cycles in the loop. It seems like a lot of 'busy work' for a MPU with all that horsepower, but I guess what else is it doing after the initial setup? However you could not service an interrupt or handle a serial port, etc during the time the PET is running which might limit the diagnostic reporting, etc.

Also note that the original PET only had an 8 MHz clock source. So perhaps you will need a clock on your board anyway. If so, a 20 MHz clock would give more timing margin.
-Dave

 

[bitfixer]

I had originally thought of using the highest frequency clock available on the PET board so the MCU could be clocked synchronously. But with an 8Mhz clock on the original PET, that would not be fast enough to keep up with doing the decoding. With a 20Mhz oscillator on the RAM/ROM board, that should be good enough to keep up with things. But as you mention, it is a lot of busy work and would make it difficult to do other useful things.

Another thought on address decoding is to use a second small SRAM. The MCU would load up the SRAM with the appropriate chip enables and such corresponding to the different addresses (the top 5 address lines) such that when these addresses showed up during the functioning of the computer, the SRAM would enable/disable the main RAM chip accordingly. The memory/IO addressing pattern would be controllable by a file on the SD card. Basically the SRAM would take the place of a PAL.. any problems with this technique?

One question about doing diagnostic reporting - basically it sounds like we want to be able to dump out the contents of RAM if needed for debugging purposes. The easiest way would probably be via a serial port, as the MCU has a built-in UART. In order to read out the RAM contents, I imagine we would need to halt the CPU so the MCU can access the bus lines and read out the RAM when requested. I've worked more with Z80s and know the halt procedure for those. Basically you assert a signal, wait for the CPU to acknowledge, then do what you want with the busses while the CPU is idle. Is the 6502 procedure similar?

 

[Eudimorphodon]

Another thought on address decoding is to use a second small SRAM. The MCU would load up the SRAM with the appropriate chip enables and such corresponding to the different addresses (the top 5 address lines) such that when these addresses showed up during the functioning of the computer, the SRAM would enable/disable the main RAM chip accordingly. The memory/IO addressing pattern would be controllable by a file on the SD card. Basically the SRAM would take the place of a PAL.. any problems with this technique?

That's the same idea I had back at post #14:

http://www.vintage-computer.com/vcf...ROM-RAM-replacement-board&p=193613#post193613

I frankly just don't have the experience to know if it's doable. From looking at datasheets it seems that the propagation time of most 74xx logic is in the "under 10ns" ballpark, so a memory mapper based on a typical 60ns-ish SRAM chip would probably be slower than hard decode logic. But whether the delay would be enough to cause problems or not I have no idea. SRAM should be at least as fast as an EPROM, and I've heard of using EPROMs to replace PALs, so it seems like it *should* work. But again, I have no idea. It seems like it would be easy enough to test using a small breadboarded circuit.

(To actually test it against the PET's bus speed I'd suggest hanging a breadboard off the internal expansion connector and testing some "mapped RAM" in one of the unused 4k windows, like 0xa000. I have a vague spitball of an idea that would only take... five or six chips, I'm sure you could think of something better.)

 

[dave_m]

SRAM should be at least as fast as an EPROM, and I've heard of using EPROMs to replace PALs, so it seems like it *should* work. But again, I have no idea.

The PET design has about a 500 nS read cycle so using an old EPROM as an address mapper may be marginal, but a bipolar PROM or fast RAM should work well to replace a PAL address decoder. Remember the mapper is not effecting the access time of the internal PETs devices, it is controlling the transceiver that enables/disables the data source to/from the CPU. It also chip selects the outboard RAM, but that device should be quite fast.
-Dave

 

[MikeS]

Boy, this sure is getting complicated; how are you going to program the mapping?

I think I'd just go with an oldskool 16 bit demux, a transceiver, and some DIP switches (and 32KB RAM and 128KB EPROM/Flash)...

And you'd still need something for the video RAM...

 

[dave_m]

I think I'd just go with an oldskool 16 bit demux, a transceiver, and some DIP switches (and 32KB RAM and 128KB EPROM/Flash)...

Mike,
We will need a 32 bit demux because of the requirement to decode a 2K I/O space so that is why Nickolas used a GAL16V8 and a DIP switch to do the job to save room/parts. The guys are trying to come up with a scheme that does not require much user setup other than a simple config file residing on an SD card along with all possible ROM images and let the MCU handle the details but now with a possible need for a 'mapping RAM' to do the high speed decode, I agree that it is getting a bit complicated. Except for the fact that the "Nickolas board" relies on obsolete DIP parts (GAL, 32K RAM and 128KB Flash), it is a simple solution.

And you'd still need something for the video RAM...

No, I think the video RAM stays on the main PET board because it needs to time share its bus with the CRT video driver logic. Or are you talking about some kind of shadow RAM of the video on the new board?

 

[eeguru]

Mike,
Except for the fact that the "Nickolas board" relies on obsolete DIP parts (GAL, 32K RAM and 128KB Flash), it is a simple solution.

Since when are PALs, SRAM, and Flash obsolete? There's thousands of each in stock in DIP form factors at just about every major component supplier; and all still in active production.

Edit: Well I did find thousands of each but spread out.. though most places have hundreds at least. Some examples:

512 KByte 8-bit wide SRAM in 32-pin 600 mil DIP
256 KByte 8-bit wide Flash in 32-pin 600 mil DIP
16V8 PAL in 20 pin 300 mil DIP (GAL is just Lattice's brand name after they acquired the IP)

 

[dave_m]

Good point.

 

[bitfixer]

I'm still hoping to do the address decoding just using the MCU, removing the need for the mapping RAM.. I'll just need to wire it up and see if the timing will work out.
For this design I would not include video RAM. I like the idea of messing with the VRAM and character generator to so some graphic hacks but I think that would be a separate thing.
I agree that the Nickolas board is a simple solution, with relatively few downsides. I think the motivation behind a new design is to add some new flexibility and debug features to it.
What I would see as the strengths of the new design -
- complete control over mapping of RAM/ROM/IO space, with ROM code and mapping loaded from an SD card
- ability to do diagnostics on the running machine, including a dump of RAM over a serial port

Currently, assuming the MCU is fast enough to keep up with the decoding, then I believe the board would have:
6502
74LS265 (bus transceiver)
ATMega644 (20Mhz MCU)
20 MHz oscillator
628128 (128k SRAM)
SD card
MAX232 (RS232 driver)

I read through some 6502 documentation, and it looks like the 6502 can be single-stepped by lowering the RDY line at a certain time during a read cycle. For the diagnostic mode, I would think you would want to halt the CPU by lowering RDY when a request was detected from the user. Then the MCU would read from memory and send the contents out via the UART, after which RDY would be released. Does this sound about right?

Another idea for lowering chip count would be instead of sending RAM dumps over the serial port, they could be written as files to the SD card.

 

[for()]

I read through some 6502 documentation, and it looks like the 6502 can be single-stepped by lowering the RDY line at a certain time during a read cycle. For the diagnostic mode, I would think you would want to halt the CPU by lowering RDY when a request was detected from the user. Then the MCU would read from memory and send the contents out via the UART, after which RDY would be released. Does this sound about right?

You can stop the 6502, but what about the CRTC? IHMO he'd like to access the bus when the 6502 doesn't in order to refresh the screen. So you'd have to synchronize the AVR with the CRTC / PHI 2. Maybe I'm wrong, but please think about it.