Weird SIO problem, 600XL, Aspeqt

[dmlloyd]

I've been having a weird SIO problem that I'm hoping someone might have some insight into.

 

The symptom of the problem is this. The Atari will attempt to read a sector (or some other SIO operation). There is about a 70% chance that it will succeed, but the other 30% it will sit for the timeout period (a few seconds) and then retry the sector read. I've seen a sector fail to read 3-4 times in a row before it succeeds and then a bunch will succeed in a row.

 

The aspeqt log looks like this:

 

[Disk 1] Get status.
[Disk 1] Read sector 1 (128 bytes).
[Disk 1] Read sector 2 (128 bytes).
[Disk 1] Read sector 3 (128 bytes).
[Disk 1] Read sector 4 (128 bytes).
[Disk 1] Read sector 5 (128 bytes).
[Disk 1] Read sector 6 (128 bytes).
[Disk 1] Read sector 7 (128 bytes).
[Disk 1] Read sector 8 (128 bytes).
[Disk 1] Read sector 9 (128 bytes).
[Disk 1] Read sector 10 (128 bytes).
[Disk 1] Read sector 11 (128 bytes).
[Disk 1] Read sector 12 (128 bytes).
[Disk 1] Read sector 13 (128 bytes).
[Disk 1] Read sector 14 (128 bytes). <-- this is the failed command
[Disk 1] Read sector 14 (128 bytes).
[Disk 1] Read sector 15 (128 bytes).
...etc...

 

So aspeqt isn't noticing a problem; rather the system just isn't seeing the sector come in for some reason.

 

Here's the history of the problem. It all started when I dropped in a PAL ANTIC for playing some PAL games. At the time I figured the occasional glitch might be due to timing differences so I didn't think anything of it. After a few weeks of not using my system, I received and installed one of mega-hz's stereo boards (in the process I moved my OS ROM IC to the BASIC spot and removed BASIC, because in a 600XL the board doesn't quite fit). I booted up and everything seemed to work great on the first try, *except* that this SIO problem was still there and in fact was quite a bit worse than it was before! Figuring I had banjaxed something (SIO = POKEY = seems like it might have been related to the stereo board install), I tried reverting the upgrade and there was no change - the SIO problem was definitely still there.

 

I swapped my ANTIC out for the original NTSC one again hoping that this would resolve the issue but it did not. I checked and rechecked the board for broken traces along every path I could find, even tried different POKEYs to no avail. Then I made a quite interesting discovery. If I boot in Aspeqt using the "boot XEX" feature, it consistently works fine (after it loads the initial few sectors containing the boot loader). This is interesting to me because the OS loads sectors at 19200 bps, but the Aspeqt XEX booter uses 57600 bps (I believe) to transmit the XEX data. So maybe the problem is actually in the OS ROM somehow, though I don't see how since it passes self-test which I think does a checksum test. My other thought is that maybe IRQs are not being handled right somehow since (I think) the OS SIO routine is IRQ-driven, whereas high-speed boot loaders aren't?

 

Anyone have any thoughts about what I should try next? I was thinking about writing a test program pair for the atari and linux which transmits a data stream and checks for problems, and maybe just swapping ICs (SALLY gets a little warm but I think that's her normal behavior).

[Rybags]

Does APE do the same thing?

 

I don't think Antic type should matter. PAL/NTSC shouldn't affect disk I/O, it affects the selection tables for tape and supposedly not as bad as you'd think.

 

Also, is this standard SIO speed or turbo? I think Aspeqt has some issues, it's worth grabbing a later version and I believe Hias has been working with the code lately and ironed out a few problems with it.

[dmlloyd]

Does APE do the same thing?

 

I don't think Antic type should matter. PAL/NTSC shouldn't affect disk I/O, it affects the selection tables for tape and supposedly not as bad as you'd think.

 

Also, is this standard SIO speed or turbo? I think Aspeqt has some issues, it's worth grabbing a later version and I believe Hias has been working with the code lately and ironed out a few problems with it.

 

It's standard SIO speed. I suppose it's possible that Aspeqt is causing this, though the problems have only started recently and it sure seems like the data is getting back to the Atari (though maybe a byte is being dropped here or there?). I don't have any way to try anything else right now, but when I get a chance I'll unearth the Indus GT to see if that has the same problem. I am using the latest Aspeqt.

 

When using the XEX loader though everything works great. I'm not sure what that means, but if I had to guess, I'd say that it means my POKEY is healthy and the problem is relating to something that only happens at normal speed.

[dmlloyd]

Just to be sure, I've now swapped each of the main ICs as well as the OS ROM with substitutes and nothing has changed.

[dmlloyd]

My test subject ATR image for this is ultima 4 because it's pretty large. Well I booted it up, and it finally finished after about 10 minutes, but the graphics are totally corrupted and the screen seems scrambled. So I'm definitely looking at data corruption too. Given that POKEY seems OK, my next test would be to verify with a real disk drive to rule out the sio2pc end of things, and then I guess try replacing the caps on the SIO lines (maybe I boiled one on accident when I installed my sio2pc USB board in the case).

[Gunstar]

You might want to try a different Ultima 4 ATR downloaded/cracked by someone else, as I had the same thing happen to me with Ultima 4 on a perfectly working stock Atari. I got a different ATR image and it works fine.

 

But I've been using AspeQT ever since I upgraded to a PC with XP and my 95/98 APE won't work right. I've noticed that some things get corrupted or don't load correctly when loaded at high-speed with my APE WARP+ OS and if I switch to a standard SIO speed OS the programs load fine. This is an issue. I believe, with AspQT as I don't recall similiar problems with APE. I'm pretty sure I'm using the latest update of AspeQT as I asked in another thread and was given a link to the "latest" just a week or so ago.

Edited February 20, 2012 by Gunstar

[Rybags]

If a sector read has bad data due to corrupt transmission, then it should fail due to the checksum not matching, or an input data framing error.

 

I'd not trust a game not working as such to indicate data corruption. A single unexpected read error can cause plenty of games to still load but not work properly.

 

A better test might be to just use Dos to copy a full disk with few free sectors. Dos will give you proper feedback of any error that occurs.

Edited February 20, 2012 by Rybags

[russg]

I agree with Gunstar, try slowing down to 19,200 instead of the 57,600.

Edited February 20, 2012 by russg

[dmlloyd]

As I've said, I'm loading at 19200 (normal speed) and I see errors. When I use the XEX loader which runs at 57600, it seems to work perfectly every time. The disk image is known good as I've used it in emulators and on real hardware without problem before. I'll post when I have a result from my real disk drive (I'll dig it out after lunch).

[phaeron]

I'm inclined to believe timing problems, as the high-speed XEX loader is able to switch between sending to receiving faster than the stock OS routine. If you're getting pauses in seconds it means that you're hitting the data frame timeout as the command frame timeout is much shorter (1-2 frames). SIO retries immediately on a checksum, framing, or device error.

[dmlloyd]

Ah an SIO master speaks up. OK so if it's a data frame timeout but I know the data frame is coming across, maybe there's some glitch that causes a byte to be lost here or there which makes the 600XL think that the frame isn't complete. I don't think I've ever seen an immediate retry but I'll keep an eye out for it.

 

Interestingly I found that the Karateka ATR is one which boots right away without any problems. That image seems to have a one-sector boot program, and the remaining sectors are read with "noisy I/O" turned off (not that that probably makes a difference), but I've also noticed that it reads a tiny bit more slowly, sector to sector, than the images that tend to fail. So maybe it's something about requests coming in too fast?

[phaeron]

Strange... I checked Karateka, and it loads most of the game through SIOV. Noise problem, maybe?

[dmlloyd]

Well I thought maybe it would be a SIOV versus DSKINV thing but DOS XL 2.2 also hangs randomly and not just during the initial boot phase. A noise problem is as good a guess as any, I suppose...

[dmlloyd]

I guess it is just Aspeqt. Or my SIO2PC. I wonder why it only just started now though (and only for certain disk images no less!). My Indus GT still works like a champ, fortunately.

[dmlloyd]

I modified Aspeqt and added a 10ms delay between the command frame receive and data send. It has fixed the problem *nearly* 100%. I'm going to tune it up a bit higher though. I'm in the midst of a full duplicate of a DOS XL SD disk image and out of 607 sectors it has only paused twice.

[dmlloyd]

Using 20ms and the problem is worse again (not to mention that the slowdown is starting to get noticeable with this value). So I guess that theory is pretty much shot. Back to guessing.

[dmlloyd]

Okay I think I have this problem fixed for the most part. It does seem to be a timing issue, but not simple. I made the following changes to my setup:

1. I changed the baud rate from 19200 to exactly 19040 to match my NTSC Atari. This did not seem to make a measurable difference.
   
2. I hid the Aspeqt window behind other windows. This improved the situation significantly.
   
3. I moved my USB connection to a root port on the system. This improved things even more.
   

So I think this is completely usable now. My advice to anyone who has a similar problem is to first try a different USB port. I believe that my mouse receiver was interfering with the timing. By moving to a different root port I've eliminated that contention.

[+Nezgar]

I came across this thread while troubleshooting a very similar issue today, using RespeQt and a Lotharek SIO2PC-USB. The hang-then double sector read looks like this in the log view:

[Disk 1] Read sector 24 (256 bytes)."
[Disk 1] Read sector 25 (256 bytes)."
[Disk 1] Read sector 26 (256 bytes)." [x2]
[Disk 1] Read sector 27 (256 bytes)."
[Disk 1] Read sector 28 (256 bytes)."

After going through steps of updating the USB serial port driver, modifying the FTDI EEPROM to disable wake timers, etc, the solution was simply to increase the response delay within RespeQt itself:

 

I had the setting down to 300μs, but the issue still occurred at the default is 800μs. At 1000μs the issue appeared to clear up with no recurrences after multiple load attempts afterwards. This is even with the SIO2PC-USB connected through an external powered USB HUB.

 

Cheers!