• Please review our updated Terms and Rules here

PET ROM/RAM replacement board

tezza said:
Great pictures Riza, thanks for posting.

Mike (gubbish), what happens with those boards where the RAM is soldered in. Does the PETVet bypass that RAM somehow?

Tez
Click to expand...

Tez,
I can answer that. From looking at the schematic, there is a LS245 bus transceiver that will isolate the PET mainboard when the PETVet wants access to memory. Therefore it does not matter if the RAM or ROM is left installed in the mainboard. This makes things very convenient.
-Dave
 
Hi,

As per Dave, if the ROM/RAMS are left in their socket, I wonder if there is a way for the PETVet to test the bank of roms (H1-H7) and pinpoint where a bad one is.
This is probably a stupid question...but then after all, the name is PETVet. I am willing to put the old ROM/RAMs for tests. However, i am cautious at the moment since my PET just got repaired.

Riz
 
The memory-mapping capabilities of the PETvet should eventually make it possible to load the board with custom diagnostic programs that can test the motherboard RAM and ROM. (I'm looking forward to seeing the documentation for setting up custom ROM loads and mapping settings so I can try banging together a PETvet-version of PETTESTER that takes advantage of the board's abilities.) It's just a matter of software development.
 
dave_m said:
Tez,
I can answer that. From looking at the schematic, there is a LS245 bus transceiver that will isolate the PET mainboard when the PETVet wants access to memory. Therefore it does not matter if the RAM or ROM is left installed in the mainboard. This makes things very convenient.
-Dave
Click to expand...

Cool. Hmm...both my PET boards are working, but it might be worth having one of these for insurance. It's always good to have a vet around when you have a PET (notwithstanding the stirling vet work you guys do on here!).

Tez
 
Eudimorphodon said:
The memory-mapping capabilities of the PETvet should eventually make it possible to load the board with custom diagnostic programs that can test the motherboard RAM and ROM. (I'm looking forward to seeing the documentation for setting up custom ROM loads and mapping settings so I can try banging together a PETvet-version of PETTESTER that takes advantage of the board's abilities.) It's just a matter of software development.
Click to expand...

As Dave said, it does not matter if ROM or RAM is left on the main board, since the 245 transceiver isolates or connects the data bus to the PETvet's SRAM depending on the memory mapping specified. At the moment I have one hard-coded memory map, but with a software revision the memory mapping will be user-programmable. For any given 1k segment of the memory map you can:
passthrough - SRAM is completely disabled and both reads and writes go to the main board
writethrough - writes go to both the SRAM and to the Main board, but reads only come from the main board, isolating the SRAM
replace - reads and writes go to the SRAM
readonly - reads from SRAM, writes disabled (used for ROM segments)

The current revision of the PETvet cannot directly read from ROMs connected to the mainboard while the CPU is halted - but you can isolate faulty ROMs by making a passthrough segment in the memory segment corresponding to that ROM. This way you can effectively test one ROM at a time, replacing the others with the PETvet.
 
gubbish said:
The current revision of the PETvet cannot directly read from ROMs connected to the mainboard while the CPU is halted - but you can isolate faulty ROMs by making a passthrough segment in the memory segment corresponding to that ROM. This way you can effectively test one ROM at a time, replacing the others with the PETvet.
Click to expand...

Or alternatively you could write diagnostic software that runs on the 6502 (booted from the top 1K of ROM-overridden-with-SRAM) and takes checksums of all the ROM sockets other than the space it needs to override... (The trick is said program has to be executed by the 6502, as limitation of not being able to read from the motherboard memory applies to the PETvet's MCU.)

Anyway. The "play-dough"-esque nature of the board should allow for a lot of interesting possibilities depending on how people want to exploit them. I really need to find more time to fiddle with my test unit. :^/

As an aside, Gubbish, I'm wondering if any of the comments about halting the 6502 in this thread here:

http://forum.6502.org/viewtopic.php?t=895

might have any bearing on the issues you were seeing with crashes on some of the CPUs you were using? There's also some comments about a hardware design that depends on halting the 6502 here:

http://www.6502.org/users/andre/icaphw/rdy.html

that are interesting. (The solution they settled on was to only use CMOS version of the 6502 to get around some timing difficulties with the NMOS ones.)

EDIT: And this is interesting too:

http://www.1000bit.it/support/manuali/apple/technotes/aiie/tn.aiie.04.html

(In particular I'm wondering about the time constraints mentioned in the "Releasing the RDY Line" section. I'm wondering if it's possible that those crashes I've seen when doing the RAM contents dumps could have something to do with the SRAM not being ready to answer the CPU for some reason after the MCU has been doing read cycles on it? Of course, the fact that it usually doesn't crash if I just use the screen memory dump function probably pokes a hole in that, unless it's a *write* that's consistently failing when the CPU resumes. The screen memory is in write-through mode so a garbled write probably wouldn't matter, but if it fouls up a zero page or stack write... but it's the same block of memory, so a stuck chip should be a stuck chip. Bleah. No idea.)
 
Last edited:
tezza said:
Cool. Hmm...both my PET boards are working, but it might be worth having one of these for insurance. It's always good to have a vet around when you have a PET.

Tez
Click to expand...
Yes, when I get mine, I will check it out using PETVet's memory. But after that is done I will probably leave the PETVet in place and change the mapping file to use all the RAM/ROM memory on the PET mainboard. If the day comes when the PET does not work, I can simply remap to use the PETVet memory to get things working again. Later I can run troubleshooting code to find the bad memory on the mainboard.
-Dave
 
dave_m said:
Yes, when I get mine, I will check it out using PETVet's memory. But after that is done I will probably leave the PETVet in place and change the mapping file to use all the RAM/ROM memory on the PET mainboard. If the day comes when the PET does not work, I can simply remap to use the PETVet memory to get things working again. Later I can run troubleshooting code to find the bad memory on the mainboard.
-Dave
Click to expand...
Good idea. It's like having a backup system in place.

Tez
 
One question about the board, did you include a header for a reset switch? This is something that I've have found VERY useful on my Ram/Rom board from Welte.
It's just handy to have an easy to connect 2 pin header to get a working reset switch on a pet.

Later,
dabone
 
Hey dabone,

Unfortunately I didn't think to include that in the current version of the PETvet board, but that's a great addition to the next version.
However, I do have a currently unused 2-pin header on the board which I could adapt to be a 6502 reset switch with a single wire jumper. If you like I can make this modification to your PETvet before sending it out to you. And I will definitely include this on the next run of boards.
I looked at the schematic for the welte board, and it looks like just a jumper header where you can connect /RST to ground. Thanks for pointing this out.
- Mike
 
Will do. I tried it out and it resets my PET 2001 just fine.
One thing to note is that if you want to change jumper settings to select a different ROM, you would still need to turn off the PET before changing jumpers so the MCU can reset and reload RAM with the new ROM contents. You could also reset the MCU with a second reset switch or by connecting both to the same switch - but the MCU needs a few milliseconds on startup to load the select ROM contents. I haven't experimented with that yet but something could be rigged up.
Also wanted to let you know that the PETvet source is online now at http://bitfixer.com/PETvet. This includes the full source for the PETvet program, as well as a separate script which builds a binary file for updating the PETvet with new ROM images and/or memory maps.
 
Well I got home earlier than expected tonight, and decided to try the petvet that came in today. I've got a Pet 2001 with a 320008 Motherboard.
The normal config that I'm running is no system ram or roms installed, but a Ram/rom board from Nicolas Welte. (It runs ALOT cooler without all those power hungry chips in there.)

I removed my welte board, and grabbed a spare 6502 (3382 Datecode, MOS) and started a quick test.

The first issue I experienced with the pet vet, is a double edged sword. The cpu socket was incredibly tight, and I couldn't get one side on the cpu to sit. I ended up having to remove the cpu and reseat about 3 times to get it, but I do know that that socket should have a GREAT connection to the cpu.

After installing, everything works great, I prefer basic 2, because of the screen snow that 4 causes on original pets.
Loaded and ran a few games, using disk and tape.

The serial header has me a little worried being a straight up and down connector on my board, Most serial cables I have would
be very tall and I would scare me to close the case on them. But a sideways mount also puts alot of weight on one side, that may cause the entire board to become misseated. This requires a bit of thought, but I'm thinking a small extension cable built with idc connectors.

Just my first, quick thoughts on the board, I'll be trying the serial port diags later this weekend.


Later,
dabone

2012-02-17_21-25-00_860.jpg
 
Hey dabone,

Thanks for the report. Glad it's working for you, good observation with the serial header. I mounted it vertically to avoid running into a situation where it would be pointing into the side of the computer. I believe with the 8032 the 6502 points in such a way as to move the serial header toward the wall, but I'm not sure. In any case I also wonder about the weight on the side issue that you mention.

Eudimorphodon had some issues with the memory dump causing some crashes, so I'll be interested in seeing how the diags work for you. Serial params are 38400 baud, N81. You can also experiment with new ROM images/memory maps if you like, I posted the source and instructions about reprogramming up on the bitfixer site.

In any case hope you enjoy playing with the PETvet. I'm in the process of fixing the errors on this board before ordering some more, so any suggestions for improvements would certainly be welcome. Thanks
 
Hi all,

I made an order for a second batch of PETvet PCBs, which will be coming in this Friday. On this revision the reversed wires on the serial port are fixed, and I now have a pin header to reset the 6502. Thanks to dabone for suggesting this.
So some additional PETvets are available if others are interested, just let me know. Thanks
- Mike
 
Ok, the serial portion works, but I would like to know a few things..

Is this seperate from the pets operation? Can we add more features?
I would love to be able to hit a key, enable read thru to the motherboard for all the roms, and have a basic checksum for most roms stored in the petvet.
Just hit the key, select rom test, and select which rom set you have. and the pet vet reads the rom, and performs a basic checksum on the contents.
A ram test like this would be great also. I guess these things hinge on being able to remap the ram/rom after powerup and how much space is left in the MCU.

Later,
dabone
 
Hey dabone,
It is possible to use the PETvet to do a RAM/ROM test on the mainboard, but it requires writing a program in 6502 assembler to read the ROMs and copy them into a segment of RAM on the PETvet's ram chip. I haven't done this yet but something like eudimorphodon's PETTESTER program would do the job. After the 6502 dumps the ROM contents into an SRAM segment then the MCU can read the contents from there and compare with the stored version to check for faults. Also you could similarly do a RAM test with another test program. Both of these test programs can fit in the PETvet flash memory.
With the PETvet's current design, the MCU can't directly drive the address lines on the mainboard to read out the RAMs and ROMs, so you need the 6502 to drive the lines and read the contents.
I attempted this at first but had issues using the MCU to drive the address lines on the motherboard directly - not sure exactly why but perhaps the MCU couldn't drive the address lines..
It is possible to remap memory and to even rewrite memory contents on the fly after halting the CPU.
Basically the firmware is in an early state but many things are possible, I'll certainly work on adding features when I get the chance and anyone interested is welcome to try their hand. I'll provide assistance with the source code if anyone is interested. Thanks..
- Mike
 
FYI with BASIC 2.0 (40 col) and BASIC 4.0 for 40 and 80 col in the PETvet's flash, about half (32k) of the flash in the MCU is used, so plenty left over for other code. Also of course you can reprogram the PETvet over serial so there's not much limitation there. The bootloader takes up 2k, and the PETvet code takes up another 4k, so you have 58k remaining for ROM images and memory maps. Each memory map is just 128 bytes.
 
Made a first attempt at a mini-program to do ROM/RAM testing using the PETvet. I loaded it into the top 1024 bytes of ROM (FC00-FFFF) - on startup it just jumps to FC00 (loaded into the reset vector) and then writes a few bytes into RAM, and then waits in a loop. After this point I can halt the CPU with the PETvet and read the contents of RAM that I wrote. This was just a test, but what I hope to do is use the 6502 to copy the contents of the ROMs on the main board into the PETvet memory, then read them out after halting the CPU. This way you can test exactly which ROMs are bad on your mainboard by doing a checksum against the known contents. Of course the top 1024 bytes are used by the mini-program which does the reading, so I'll have to come up with a way of rewriting the memory map after halting to allow you to read that segment of ROM also.
Similarly I hope to make a little memory test program which just writes values to mainboard RAM and reads back to check if it matches.
Stay tuned for more.. thanks
 
You must log in or register to reply here.
Back
Top