SD2PET ?Device Not Preset Error

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:

• http://blog.tynemouthsoftware.co.uk/2023/10/pet-ieee-488-diagnostics-updated-version.html

If what is read back does not match, then it could be down to a few things:

1. The output pin not sending the output
2. The input pin not reading the input
3. The buffer IC that sits between those and the bus
4. 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:

• https://www.tindie.com/products/tynemouth/pet-ieee-488-diagnostics-tester/

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:

• https://www.tfw8b.com/product/sd2pet-commodore-pet/

---

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.

• https://www.patreon.com/tynemouthsoftware

Testing PET ROM/RAM Boards

This is a reworking of two Patreon exclusive posts from last year. I was building a large batch of PET ROM/RAM boards for The Future Was 8 bit, and I wanted to update my test kit. I am currently building another large batch of boards, so it seemed fitting to revisit these posts.

The current design of the PET ROM/RAM board has evolved quite a bit since the first ones I produced back in 2014, but the concept is the same. Plug into the CPU socket of a PET to bypass and/or upgrade the onboard ROM and RAM.

Since this was also acting as a piece of test equipment, it was important to me that I tested each of the boards I built to make sure they were working correctly. So that the buyer can just plug the PET ROM/RAM board in and be confident it will work.

In the early days, I would test these in my 4032, although that complicated things slightly as this generation of boards drive the display with a CRT controller chip which needed to be initialised by the ROM before it would generate sync signals, so I had to remember to boot up to a 4032 or 8032 ROM image or the onboard ROM set first.

This meant the CRT had to be run all the time the board was being tested, which is not ideal, I try not to overuse nice tube based monitors for trivial tasks when a disposable LCD display would be sufficient.

I used various other boards, including a 2001N board from a 3016. That had the advantage that an adapter could be used to generate a composite video signal from it, so it didn't need the CRTC to be initialised or the CRT to be run during testing. It did however still need the big PET power supply to power the 4116 RAM chips.

When I got hold of a broken 2001 board, that became an ideal test harness.

The board originally ran from a centre tapped AC transformer, and only used the 9VDC that generated to power the datasette motor drive circuitry, everything else on the board being 5V. With a suitable cable, this could be run from a 9V DC bench supply. It did run at over 1A due to all the LS TTL logic on there. (A Mini PET for reference runs at about 100mA due to the use of HC logic).

This had several failed 6540 ROM chips (no surprise there), unfortunately including the character ROM, which is in a different circuit and cannot be replaced by the ROM/RAM board. It was also low on working 6550 RAM chips, so I put the remaining working ROM and RAM safely away and made replacements.

With the 6520 and 6522 chips replaced with WDC ones, this became a nice stable board with no MOS parts to worry about wearing out.

This could also drive a composite signal with no programming, in fact the PET's party trick is that it will still drive the display if there is no CPU installed due to the completely separate video circuitry.

Add to that an SD2PET to load test software and it's pretty much sorted.

The final element was a replacement keyboard, one of the first ones I mad, which had the nice white switches (before TFW8b insisted on those less than ideal blue ones).

The was supported on a second PCB to prevent it scratching the bench.

Most of the time, I was using a BASIC RAM test program I had adapted from one in a book or a magazine many years ago, adding bit wise testing and address bus testing.

This was  deliberately slow and deliberately written in BASIC as it means lots of ROM and RAM accesses, but did take about an hour to complete. That meant that whilst a board was on test, I could get on with labelling and packing the previous board and then cleaning, checking and programming the next one ready for test.

That has been working well for a many years, building these in small batches for my store (now at https://www.sellmyretro.com/store/tynemouth-software) but since TFW8b is now ordering these in larger quantities, I think it is time to retire the 2001 board and look for something new.

I set out a few requirements:

• Single 9V DC supply
• Composite video output
• Long term reliability
• SD card loading
• Compact size

You might think the obvious solution would be a Mini PET. After all, they meet all the above requirements, and I might have one or two of them lying around here.

And yes, that would be an obvious choice, particularly one of the development builds that would not be saleable, such as the Mini PET Stealth created from one of the batch of PCBs with no silkscreen.

However, there is one problem. As the marking indicates, the socket on the Mini PET is not suitable for a 6502 CPU. 

The W65C02S used there has a slightly different pinout and different timing requirements to the original 6502. A couple of pins need extra pullup resistors, and one input is now an input/output pin which means it should have an inline resistor if used (which it isn't). The most notable changes though are one of the ground pins on the 6502 that has to be connected to ground is now an output on the W65C02S. Secondly, I found during development that the clock out on the W65C02S was not suitable for driving the rest of the system as it is on the PET. Instead, it has to be driven based on the input clock rather than phi1/phi2 output as on standard 6502 systems.

Before I knew the clock out was unsuitable, and how different the timing had to be, I tried on the first Mini PET to make it suitable for either type of CPU.

That is PCB V1.00, the very first Mini PET. I did get that working in the end, and it was mostly right.

As with many early prototypes, I used GAL chips for things like address decoding to allow me to change that without needing to change the PCB.

Inevitably, there are changes, as you can see, the Mini PET once had a 555 timer based reset circuit, but that function was taken on by the CRTC microcontroller to save space on the next board....

This was the second board produced, V1.21 (I was clocking through revision numbers for each change made to the design).

This one still had a few features which were eventually dropped, including selectable CPU clock. This seems like a neat idea, but in the end not. Datasette loading didn't work over 1MHz as it was asynchronous and had to match the clock timing. IEEE-488 failed over 2MHz (also due to timing based on cycle counts). Changing the speed after loading often failed due to contact bounce on the jumpers, which could have been resolved with a 157 or a 4066 or something like that, but the feature was dropped to avoid causing problems. (I did go for this on the Minstrel 4D, which now has a turbo button to switch clock speed - http://blog.tynemouthsoftware.co.uk/2022/08/minstrel-4d-overview.html)

This board had the GAL replaced by logic chips but still needed some extra mods trying to get the timing right.

This version of the board did have one important difference, I had added a jumper to select the clock source between a WDC chip or a MOS (or Rockwell etc.) standard 6502. This did not address the pin 1 ground / output pin issue, and left that pin unconnected, which some 6502 chips were not happy with, they do seem to need both pins connected.

It almost worked, but memory access timing to fit both chips was right on the edge, and would occasionally fail. I could never get it properly reliable with both CPU types, and to support both would have needed two different memory timing circuits selected based on CPU type. That would need a block of four jumpers to change CPU type. I decided that since this was going to be a kit, and going to be supplied with a W65C02S, it was best to just tune it perfectly for that and remove 6502 support - hence the warning on later boards.

I did look into building up another V1.21 PCB to use for testing, thinking I could miss out the parts I didn't need, but when I looked into it, all I could leave off were the datasette motor power circuits. Pretty much everything else was required if I was going to access the IEEE-488 bus.

There didn't seem much point in duplicating the whole thing, so this board will become the test rig. This one was already modified to 6502 timing, and with a ground wire attached to pin 1 (underneath) it was ready for use. It just needed a few extra sockets to rise above the 'vertical modifications'

It does need a keyboard. I could have used the one from the previous rig, or build another of that type, but I decided it would be better mounted to a solid board. I had a look through the scrap PCB pile, and found some boards from the Mini PET 40/80 development.

This was the first design with the build in keyboard. I had spaced the keys out wider and added the extra keys for power / reset / menu in a vertical row above the keypad. I didn't like this, so on later revisions, I went back to the closer spaced keys and had the four function keys down the right hand side instead.

With nothing populated on that board, I can use only the keyboard, via a plug and socket arrangement. I also added pillars through the boards for support, including an extra one directly under the 6502 socket for extra support.

The nice white light touch key switches I use on these are expensive, so I didn't want to allocate a full set to this. Instead, I used up some of the yellow hard touch keys we received in error one time. They aren't as nice to type on, but I am not expecting to type on this keyboard much.

In fact, the only keys I really need are Shift and Run/Stop.

The testing software is carried across from the old rig. I alternate between the old hour long BASIC test program and a shorter test using a modified version of the Mini PET self test ROM.

These are the only programs on these SD cards, so can be loaded with Shift + Run/Stop.

The display is a little bit wavy there as the CRT controller on the V1.21 Mini PET board was an early development version, and by the looks of it had a few extra instructions on the 8th line that were not being offset in the other 7 correctly. This was all fixed in later versions, but I think some of the pin allocations are different on this board, so I have just left the microcontroller on there with whatever version of code it last had as it works well enough for the RAM tests.

Add an SD2PET and the new PET ROM/RAM board test rig is ready.

I was going to wire up the soft power on circuitry on the V1.76 board, but that was an early version and it was improved in the later boards. The inline power switch works fine, so I will just stick with that.

The test procedure I normally follow is to have the onboard RAM disabled, and the onboard ROM set to something different (in this case, there is a development version of Mini PET BASIC on there. Just needs to show if it is using the onboard ROM or the replacement ROM.

I start with the PET Tester ROM which does the B/G test on the first 1K of RAM, then shows the character set and repeats. The screen of 'B' characters when no RAM is enabled really shows up the development video controller timing.

Following that, I enable the replacement RAM and it should go to G's. Then go through the ROM images, quickly checking it will boot to BASIC 1 and BASIC 2 and finally I select the CRTC BASIC 4 ROM which should boot up on any PET, I leave them set like that. Once booted, I use SHIFT+RUN/STOP to load one of the test programs and leave that running for a bit.

If I am packing a batch of these, I will run the modified Mini PET System Test and let that loop 10-20 times whilst I pack the previous board and prepare the next one.

I occasionally switch to the slower BASIC memory test if I am taking a break, and let that run through it's hour long test.

I could probably dispense with all of these tests, since every single board in the last batch passed, (full disclosure, one was rejected before testing as I noticed one pin had not been soldered, but when soldered it tested fine). I still test them all I regard these as test instruments, and want to be confident that each and every one of them is tested and working well.

Since starting to sell these via TFW8b, I have upped the game a bit, and these now come in their own little boxes, complete with their individual serial numbers.

These stack quite neatly in the larger boxes, ready to ship down to the Pink Windmill for distribution:

Advertisments

PET ROM/RAM boards are available from The Future Was 8 bit:

https://www.thefuturewas8bit.com/shop/commodore/pet/petromram.html

As is the SD2PET

https://www.thefuturewas8bit.com/sd2pet-future.html

I am a bit surprised the PET ROM/RAM boards are still very popular, I sort of expected that when we launched the Mini PET 40/80D that would have been the end for the PET ROM/RAM. The Mini PET 40/80D is a drop in replacement for any PET board, so not only fixes any problems, adds 40/80 column mode, upgrades the ROM and RAM, and adds a built in SD2PET.

https://www.thefuturewas8bit.com/shop/tynemouth-products/minipet4080d.html

Patreon

You can support me via Patreon, and get access to advance previews of posts like this and behind the scenes updates. This now also includes access to my new Patreon only Discord server for even more regular updates.

https://www.patreon.com/tynemouthsoftware