Atari 400 SIO peripherals not working

[ApM]

I recently picked up my first 8-bit Atari, a dusty old Atari 400. I've put a 48k RAM upgrade in it and it boots to Memo Pad and runs cartridge software fine. (I only have a few carts - BASIC, Pilot, and Atari Music Composer.)

 

It came with a tape drive with a belt so worn out that the tape won't turn. I built an SDrive MAX, but it just spits out errors when I turn the Atari on, and it just boots to Memo Pad as if nothing was plugged in. I figured I must've messed up on the construction somewhere and bought a FujiNet - but that does the same thing, boots straight to Memo Pad. It has more interesting debug output - it spits out the SIO command it receives when the computer turns on. Turns out it's getting semi-random garbage instead of usable SIO messages? Half the time the checksum doesn't add up, and the other half it's trying to send random messages to device 0.

 

These are the FujiNet serial logs from switching the machine on and off six times (the appropriate LOC producing the "CF:" debug output appears to be here in the FujiNet firmware source - device, command, aux1, aux2, checksum).

[10:20:01]CF: 00 4c 2a 00 84
[10:24:29]CHECKSUM_ERROR
[10:24:36]
[10:24:36]CF: 00 31 53 00 00
[10:24:36]CHECKSUM_ERROR
[10:24:36]Toggling baudrate from 19200 to 67431
[10:24:36]set_baudrate change from 19200 to 67431
[10:24:42]
[10:24:42]CF: 00 00 00 c0 f8
[10:24:42]CHECKSUM_ERROR
[10:24:47]
[10:24:47]CF: 00 00 00 c0 f8
[10:24:47]CHECKSUM_ERROR
[10:24:47]Toggling baudrate from 67431 to 19200
[10:24:47]set_baudrate change from 67432 to 19200
[10:24:53]
[10:24:53]CF: 00 31 53 00 00
[10:24:53]CHECKSUM_ERROR
[10:25:00]
[10:25:00]CF: 00 00 4c 2a 00
[10:25:00]CHECKSUM_ERROR
[10:25:00]Toggling baudrate from 19200 to 67431
[10:25:00]set_baudrate change from 19200 to 67431

Anyone have any advice for how to debug this at the hardware level? What parts might be causing problems on the SIO interface like this?

[TGB1718]

From the code it looks like there has been no response on the SIO bus, the CHECKSUM_ERROR isjust

the followup to the timeout and the system then trying to see if different baud rates help.

 

The first thing I would do is on the 400 is check the solder connections to the SIO port, it's not unknown

for the solder (which can look ok) to have cracked and just needs a solder re-flow, also I don't know

if your chips are socketed, but if they are, just pries them out and re-seat, may just be a bit of corrosion

on the chip legs/sockets.

 

It does sound as if POKEY is ok if the music is fine on the games though.

[+DrVenkman]

5 minutes ago, TGB1718 said:

From the code it looks like there has been no response on the SIO bus, the CHECKSUM_ERROR isjust

the followup to the timeout and the system then trying to see if different baud rates help.

 

The first thing I would do is on the 400 is check the solder connections to the SIO port, it's not unknown

for the solder (which can look ok) to have cracked and just needs a solder re-flow, also I don't know

if your chips are socketed, but if they are, just pries them out and re-seat, may just be a bit of corrosion

on the chip legs/sockets.

 

It does sound as if POKEY is ok if the music is fine on the games though.

All the chips on 400/800 and 1200XL machines are socketed, even the support logic. However, I know from first hand experience that POKEY can produce sound while failing in other ways, such as serial I/O. I had that happen to one of my 1200XL rescues. But by the same token, it could be oxidation on the chip legs or sockets, or a socket with a bad wipe or two making poor connection. 

[BillC]

8 hours ago, TGB1718 said:

The first thing I would do is on the 400 is check the solder connections to the SIO port, it's not unknown

for the solder (which can look ok) to have cracked and just needs a solder re-flow, also I don't know

if your chips are socketed, but if they are, just pries them out and re-seat, may just be a bit of corrosion

on the chip legs/sockets.

Another possibility, since the SIO socket is on the power board, is corrosion/bad connection on the header connecting the 2 boards.

[Rybags]

Those command frames - I don't think there should be a leading 00.  Possibly there's a start bit being assumed when the level should be at 1?

 

Could you volt-test Data Out on the serial port?  Normally it should be +5V.

Also you can issue a Basic command to set it to zero:

 

POKE 562 ,131 : POKE 53775,131

 

Set things back to normal, just press Reset or change the 131 to 3.

Edited December 19, 2020 by Rybags

[Gavin1968]

Are you using external power? If not, you must, for both a FujiNet and the SDrive-MAX. The 400 and 800 boot to fast for these devices to finish their boot before the computer needs them. 

[Alan Willford]

On 12/18/2020 at 10:45 AM, ApM said:

I recently picked up my first 8-bit Atari, a dusty old Atari 400. I've put a 48k RAM upgrade in it and it boots to Memo Pad and runs cartridge software fine. (I only have a few carts - BASIC, Pilot, and Atari Music Composer.)

 

It came with a tape drive with a belt so worn out that the tape won't turn. I built an SDrive MAX, but it just spits out errors when I turn the Atari on, and it just boots to Memo Pad as if nothing was plugged in. I figured I must've messed up on the construction somewhere and bought a FujiNet - but that does the same thing, boots straight to Memo Pad. It has more interesting debug output - it spits out the SIO command it receives when the computer turns on. Turns out it's getting semi-random garbage instead of usable SIO messages? Half the time the checksum doesn't add up, and the other half it's trying to send random messages to device 0.

 

These are the FujiNet serial logs from switching the machine on and off six times (the appropriate LOC producing the "CF:" debug output appears to be here in the FujiNet firmware source - device, command, aux1, aux2, checksum).

Anyone have any advice for how to debug this at the hardware level? What parts might be causing problems on the SIO interface like this?

I just got a fujinet and am having similar issues, did you ever find a fix?  And who did you buy yours through?  I'm trying to determine if there is a issue with my 800 or if the fujinet is defective.  

[ApM]

Thanks for all the suggestions.

I've traced each pin on the SIO port to the matching pin on the POKEY and PIA with a multimeter measuring resistance, following the motherboard schematics I found here:

SIO 1 - POKEY 26 (Clock in / BCLK)

SIO 2 - POKEY 27 (Clock out / ACLK)

SIO 3 - POKEY 24 (Data in)

SIO 5 - POKEY 28 (Data Out)

SIO 7 - PIA 19 (Command)

SIO 8 - PIA 39 (Motor Control)

SIO 9 - PIA 40 (Proceed)

SIO 13 - PIA 18 (Interrupt)

 

SIO 8 shows infinite resistance when compared to PIA 39 but a second look at the schematic shows there is a transistor in the way - it's powering the motor from a 5V power source, not the chip. So that makes sense. All the other pins show near zero resistance.

 

I noticed there is about a 9-10kohm resistance between most of the pins, ie. data in / out, is this expected? Checking the schematic it looks like all of the inputs are tied to ground with capacitors to clean out the signal - my guess is that in operation they should be appropriately isolated. But my electronics knowledge is pretty basic, so I really don't know.

 

Regardless, this test should rule out solder / connection issues at the SIO port and at the connection between the power supply and the motherboard.

 

Pulling the POKEY chip is _very_ difficult; it does NOT want to come out of the socket. Given that my testing is showing that the connection is solid, I don't think reseating it would help; I am leaving it be for now. POKEY looks fine; a couple of the ROMs look like they might have a little corrosion on their pins though. Any way of doing a checksum? My RAM expansion card also has the ability to override the system ROMs, I could try fiddling with that.

 

I am getting +4.96V on the data out pin on power up, and +0.14V after performing the two pokes. Also getting +4.96V on the data _in_ pin, before and after the pokes. That's a little surprising to me.

 

I am using external power on both the FujiNet and SDrive MAX. I did accidentally have the SDrive plugged into both external power and the Atari's 5V for a while before eventually pulling that pin, but it doesn't seem to have damaged it.

 

I bought my FujiNet from The Brewing Academy; I don't have any reason to suspect a problem with it given the problems I'm having with everything else.

 

Since I have no access to games, I haven't tested the joysticks at all - is there a good way to check the PIA from BASIC? Given that the COMMAND pin is wired to it, and the FujiNet seems to be reading data before it's ready, and sound is definitely still working, I'm starting to get suspicious...

[ApM]

Wrote a little BASIC program to test the joysticks and they are indeed heavily messed up:

10 FOR I=0 TO 3
20 ? STICK(I);" ";
30 NEXT I
40 ? ""
50 GOTO 10

This prints out "0 0 13 5" repeatedly, even with nothing plugged in. With a joystick plugged into jack 3 or 4 I can get the third or fourth numbers to change in response to some joystick movement, but otherwise it appears that a bunch of inputs are stuck on.

 

From the schematic it looks like POKEY handles only the analogue inputs, which wouldn't show up in this test - not sure how to verify those from BASIC yet. Seems to me like this points the finger at the PIA as the problem though.

[+DrVenkman]

I haven’t messed around reading joysticks in BASIC for a few decades, but assuming your programming is correct, the joystick ports and a few other I/O matters like cassette motor control are run by the 6520 PIA chip, not POKEY. But having said that, you should still remove and reseat POKEY. It doesn’t matter how difficult it is to remove or how tightly it sits in the socket, you can still get surface corrosion on the pins and the socket wipes. Use a small, flat-blade jeweler’s or precision screwdriver to lift up one side of the chip just enough to break contact, then repeat on the other side. Repeat until the chip is free of the socket, Clean the pins of the chip with 90%+ iso or Deoxit and a nylon toothbrush. Repeat with the socket wipes, blow out any excess with compressed air or simply wait a couple minutes for it to evaporate, then reinsert the chip. Now, assuming the chip is good, you’re set for a few more decades. However, even if the chip looks physically fine, it can still have an internal fault - as I said earlier, it’s perfectly possible for POKEY to work fine reading keyboards and producing sound but still fail in the serial I/O functions. 

[Gavin1968]

On 12/23/2020 at 5:40 PM, Alan Willford said:

I'm trying to determine if there is a issue with my 800 or if the fujinet is defective.

Are you using external power for the FujiNet? If not, you must in order for it work correctly with the Atari 400/800 or 1200XL machines.  

Best,

Gavin

 

[ApM]

Alright, I pulled both the POKEY and the PIA, applied deoxit on the chips and the sockets with a toothbrush, and reseated them. No change in the machine's behaviour; my joystick program is doing the same thing, FujiNet still won't boot. (The orange LED on the FujiNet stays on indefinitely once the Atari has been powered on, even after the Atari is shut off. Not sure if that helps anyone understand what's going on.) Definitely something wrong with the PIA, but it looks like compatible replacement parts are still being made and aren't too expensive. Am going to try replacing that first, then picking up a replacement POKEY if I'm still having SIO problems.

 

Thanks for all your help!

[ApM]

So for the benefit of anyone who might stumble onto this thread in the future and get curious: Replacing the PIA with a W65C21N6TPG-14 chip from Mouser appears to have solved my SIO problems. I'm now able to boot with the FujiNet, connect it to Wifi, download disk images, and boot them. Thanks again, everyone.

[_The Doctor__]

Yup
CO14795
CO12298
sometimes no Atari number, Hitachi HD68B21, GTEu G65SC21P, W65C21N6TPG-14

 

Glad you replaced it and all is well

[The V-Man]

I want to continue this older thread as I'm having a similar issue on my Atari 800 Incognito.  I tried to install a FujiNet 1.6 on this computer and it does not boot at all.  it goes to Note Pad/XL test, depending if I'm Colleen or XL mode. 

 

Incognito works perfectly.  I tested the FujiNet 1.6 on another 800 with 48k and it works perfectly.  I took the FujiNet 1.5 I had on that device and tested it on the Incognito 800 and it also does not boot. 

 

I know there is power as if I tap the "A" button on the FujiNet the second LED blinks blue, both on 1.5 and 1.6 FujiNets with no external power connected to the FujiNets.  I can run both FujiNets with or without power on the 48k 800, but on the Incognito 800 it will not boot with or without external power connected to the FujiNet.

 

As noted above I ran the Basic joystick test and everything worked perfectly.  I tested the connectivity to the SIO/Pokey-PIA Pins and noted above and all the pins showed low resistance except for SIO8/PIA39 as noted above, so I believe the board is okay.

 

I cleaned and re-seated both the PIA and the POKEY chips with the same results. I am starting to suspect I have a bad Pokey.  Music plays fine.  I have not been able to test the paddle controls yet. 

 

Does the Incognito use SIO for loading when using the CF card, or does it bypass pokey? I'm running out of ideas and thinking about buying a new pokey or pokey Max.  Anything else I should look at before I make a purchase?

 

Thanks.

[scelbi8h]

2 hours ago, The V-Man said:

Does the Incognito use SIO for loading when using the CF card, or does it bypass pokey? I'm running out of ideas and thinking about buying a new pokey or pokey Max.  Anything else I should look at before I make a purchase?

 

Thanks.

 

It happened to me few days ago when I installed the Incognito inside my 800 too.

 

It was a question of having the right settings on the Incognito configuration. Make sure the SIO ports are enabled in the options - in my case they were disabled by default.

 

I hope that's your case too!

Edited January 7, 2022 by scelbi8h

[The V-Man]

21 hours ago, scelbi8h said:

 

It happened to me few days ago when I installed the Incognito inside my 800 too.

 

It was a question of having the right settings on the Incognito configuration. Make sure the SIO ports are enabled in the options - in my case they were disabled by default.

 

I hope that's your case too!

Thanks for your suggestion.  But it did not seem to help. It was already set to HSIO.  I tried HSIO+SIO2BT, SIO2BT, and disabled.  All behaved the same way, goes right to XL test or Memo Pad depending on my profile set. 

 

I ran tests on the PADDLES and it seems to work fine.  So Pokey can generate sounds and handle POTS. PIA is handling the joysticks just fine. All the lines show low resistance except PIA39/SIO8.

 

I'm running out of options.

[scelbi8h]

4 hours ago, The V-Man said:

Thanks for your suggestion.  But it did not seem to help. It was already set to HSIO.  I tried HSIO+SIO2BT, SIO2BT, and disabled.  All behaved the same way, goes right to XL test or Memo Pad depending on my profile set. 

 

I ran tests on the PADDLES and it seems to work fine.  So Pokey can generate sounds and handle POTS. PIA is handling the joysticks just fine. All the lines show low resistance except PIA39/SIO8.

 

I'm running out of options.

I'll take pictures later of my configuration settings and post them, because I am (and I was before) talking from memory.

 

If it still does not work with the same settings, maybe there's something wrong with the SIO port, with the Incognito installation, or something else.

 

Do you have any other SIO device to try with this 800?

[+DrVenkman]

On 1/7/2022 at 1:37 AM, The V-Man said:

Incognito works perfectly.  I tested the FujiNet 1.6 on another 800 with 48k and it works perfectly.  I took the FujiNet 1.5 I had on that device and tested it on the Incognito 800 and it also does not boot. 

Swap the POKEY from your questionable Incognito 800 into your known-working 48K 800 and then test the FujiNet again in the 48K machine. If it works, the issue is the serial I/O function of that POKEY.

[_The Doctor__]

no sio2bt, it is not supported in fujinet any longer. It may return one day but who knows...

Edited January 8, 2022 by _The Doctor__

[a8isa1]

As already mentioned 400/800 boots too quickly for FujiNet or SDrive-MAX to be ready.  

 

Not elegant but this usually works for me.

 

- Hold down START when you power up the 400, as if you were going to boot a cassette.  This will prevent the Atari from entering Memo Pad before either device is ready for use.

 

for SDrive-MAX 16K minimum is required

- Wait for it to initialize.  If the touch screen looks scrambled press the SDrive-MAX's RESET button (assuming you have one).  Select an ATR or XEX which you wish mapped as D1:

- Now press the 400's RESET.  Logical drive D1: should now be available to the 400 and it will boot the mapped ATR/XEX

 

for FujiNet 48K minumum is required (to run the Config utility)

- On first use of FujiNet all you will see is the amber LED on the right side blink a few times then all LEDs will be blank.  Wait a few moments.

- Now press the 400's RESET.  FujiNet's CONFIG should run (see FujiNet documentation)

 

-SteveS

 

Edited January 11, 2022 by a8isa1

[+DrVenkman]

18 hours ago, a8isa1 said:

As already mentioned 400/800 boots too quickly for FujiNet or SDrive-MAX to be ready

That’s not universally true - some machines (my daily drivers included) boot up in time just fine. 

That said, an external power supply is not a bad idea to try as an easy first step if someone is having trouble getting machines to boot reliably from the device.

[a8isa1]

1 hour ago, DrVenkman said:

That’s not universally true - some machines (my daily drivers included) boot up in time just fine. 

That said, an external power supply is not a bad idea to try as an easy first step if someone is having trouble getting machines to boot reliably from the device.

your daily drivers are stock 400 or 800?  very retro.  nice!

 

-SteveS

[+DrVenkman]

Just now, a8isa1 said:

your daily drivers are stock 400 or 800?  very retro.  nice!

 

-SteveS

My dailies include stock 400s (well, one is 48K, modded decades ago before I got it), stock 800s and stock 64K 1200XL. 

The point is, various hardware/firmware revisions of these modern devices, plus various age-related conditions which can affect any old system randomly, means you can’t just make a generalization about the system will boot too fast or slow enough to use with them. Some will, some won’t. If the user’s systems boot too quickly for use with a FujiNet or SDrive-Max, the easiest solution is just use an external microUSB power supply and don’t worry about it.

[a8isa1]

2 minutes ago, DrVenkman said:

My dailies include stock 400s (well, one is 48K, modded decades ago before I got it), stock 800s and stock 64K 1200XL. 

The point is, various hardware/firmware revisions of these modern devices, plus various age-related conditions which can affect any old system randomly, means you can’t just make a generalization about the system will boot too fast or slow enough to use with them. Some will, some won’t. If the user’s systems boot too quickly for use with a FujiNet or SDrive-Max, the easiest solution is just use an external microUSB power supply and don’t worry about it.

This may be true but my test is easy and quick and requires no changes and will confirm Fujinet and/or SDrive-MAX as working or not

 

I know FujiNet has safeguards allowing the connection of both SIO power and external power.   I'm not so sure about all SDrive-MAXes, especially homebrewed ones.

 

-SteveS