This is a problem we see every now and then.
Someone buys an SD2PET, plugs it into their PET and tries it and they get the dreaded ?Device Not Preset Error.
(I should apologise now as all the screen photos in this post are going to be rubbish as they are taken from an 8032 CRT and I am clearly incapable of doing that)
Now the first thought is probably "the SD2PET is faulty", but honestly, that is probably the least likely scenario.
They way I try to think of it is you are attaching a brand new bit of recently built and tested kit to a vintage computer in unknown condition.
Imagine you have a 1980 Ford Cortina. It might work fine for everything you use it for. Then one day, you need to carry more stuff around, so you attach a brand new trailer. That should go OK, but you might find it can't make it up hills any more, the tail light hookup might not work (it may never have been used before, or not this century anyway). Someone might have fitted a non-standard connector that the trailer designed to attached to a 1980 Cortina might not fit onto. The towbar mountings might be rusty and snap off as soon as you try to pull anything with it it.
None of which would be the trailers fault, but you wouldn't have known about those issues until you tried to attach one.
It may have been "fully refurbished" when you bought it, but did they try it with a trailer?
So what can you do?
Well, various things, check it's plugged into the correct connectors, the correct way up.
Check the edge connectors are clean and shinny, with no dust or corrosion or lumps of solder where someone tried to attach something sometime in the past.
Another thing to try early on is to remove the SD card.
With no SD card installed, it should return a listing of "EEPROMFS".
Until you see that, don't put the SD card back in, it just helps to narrow things down, keep it simple.
If that works without the SD card installed, check the SD card contacts or try another card.
If you don't have the TFW8b preloaded SD card, then you should get the oldest, slowest, lowest capacity card you can as that has the best chance of working. And go for an SD card, rather than microSD card in an adapter. They are not the same.
It should be formatted FAT32, although if it is formatted incorrectly (i.e. VFAT or NTFS or if it been near a Mac that has helpfully repartioned it to be unreadable), that it will more likely return "?file not found error"
If you have another PET, you can test the SD2PET on there and make sure it works (as we suspect it will).
If you have a known working IEEE-488 disk drive, you can test that out and you would expect to also see ?Device Not Preset Error.
Self Testing
The design of the PET uses two IO pins for every pin on the IEEE-488 bus (well, almost every pin, one is output only, one is input only, one is hard wired to ground).
For each of the main pins, there is an "out" and an "in", the former sets what appears on the bus, the later reads the state of the bus.
That means that the PET can actually test itself by writing to the bus and then reading back to see if that matches what was written.
I won't go into the full details here, it is described in the second half of this blog post:
If what is read back does not match, then it could be down to a few things:
- The output pin not sending the output
- The input pin not reading the input
- The buffer IC that sits between those and the bus
- Some conflicting device (bad ROM or RAM or IO chip or decoding logic - yes I know that's pretty much everything)
On the PET, the inputs and outputs are generated mostly by the 6520 nearest the IEEE-488 port, but also by the other 6520 nearest the keyboard connector and also the 6522.
The bus interface is by three MC3446 chips which connect the inputs and outputs to the bus.
If the 6520 and 6522 chips are socketed, try reseating those first, if that makes no difference, you can rule those out by swapping in known working 6520 and 6522 chips.
If that does not help, you could try something like my PET IEEE-488 Diag board (https://www.tindie.com/products/tynemouth/pet-ieee-488-diagnostics-tester/)
This shows what is happening on the bus, so it you set a signal, you can see if the LED changes. If it does, then the output side is working, but if the PEEK doesn't change, then the problem is on the input side.
If the LED does not change, you can test the input side by bridging the signal pin to ground.
Don't panic, that isn't going to damage anything. The bus should only ever be in two states. Either floating high because nothing is driving it, or driven low by the PET or the disk drive (or a bit of wire). Nothing should ever drive the bus lines high.
Note the REN LED is always on as that is hard wired to 0V inside the PET, so it's sort of a power LED, it will always be on.
Fixing the problem
On the bench today, I have an 8032 board.
The owner has gone through all the POKEs and PEEKs described in the blog post above and has found the ATN line is not reading back.
Checking that with the PET IEEE-488 Diag board, the REN LED is lit, but nothing from ATN. Everything else seems to be OK.
I tried the wire link and it did not read that back correctly, so the MC3446 is likely bad.
I thought it would be interesting to check this on the logic analyser.
I used the leads I made up recently to clip onto the suspect IC. (http://blog.tynemouthsoftware.co.uk/2025/09/logic-analyser-replacement-clip-leads.html)
I also added one on the bus, from the PET IEEE-488 Diagnostics board on the LED side so it would be 5V logic, and one on the IO chip select line, just so I could see when that was active in case both IO pins did nothing.
The results were clear, ATN out was toggling correctly, but nothing was making it to the bus.
I wrote a little test program to toggle the pin, to check.
And again, you can see ATN toggling, but nothing else.
The suspect chip is the MC3446N at UA20.
Time to get the desoldering gun out.
The desoldering gods were on my side today, that came out nice and cleanly.
A new old stock MC3446AP replaces it.
Time to retest.
Oh.
I repeated the POKE and PEEK test and it was still bad.
I repeated the wire link test and it was now reading that pin correctly. So that 3446 was bad, but there must be another problem.
I poked around with the scope and found the drive signal from the 6522 was very weak, it was only going between about 2V and about 3.5V. That's not right (but unfortunately it was good enough for the logic analyser).
The 6522 is socketed, so it was easy to try a replacement.
Ah, that looks better.
That is now swinging between 0V and 5V as it should.
And there it is on the logic analyser, Out is driving the Bus is that is being read back to In. Perfect.
But does it work?
Yes it certainly does, let's try with an SD card
Looking good
I tried a few more things, and everything seems to be working nicely.
Only the lack of dust on the new chips gives away any work has been done.
So, two bad chips, I would normally have suspected one or the other, but both have tested bad on another board.
I suspect the 3446 failed and damaged the output of the 6522, but it could have been the other way around.
Adverts
The PET IEEE-488 Diagnostics LED board is available form my Tindie store:
I can still ship worldwide.
Currently it looks like Royal Mail to the US is working without having to pay tariffs (computer parts are excluded from the 10% so there is just a handling fee, which I pre-pay). There still may be delays or charges. We're all pawns in a petulant child's political games, but we've got to just keep going and try to make this stuff work.
The SD2PET is available from The Future Was 8 bit, with optional pre-loaded SD card:
Patreon
You can support me via Patreon, and get access to advance previews of development logs on new projects like the Mini PET II and Mini VIC and other behind the scenes updates. This also includes access to my Patreon only Discord server for even more regular updates.
