SDX SIO routine interfering with DLIs

[flashjazzcat]

I've run into a potential deal-breaker here while testing The Last Word with SpartaDOS X on real hardware. The new "SIO-proof" DLIs (which keep the status area intact during disk I/O) don't seem to like SDX's custom SIO routine (or vice-versa). The DLIs work fine with the OS's SIO routines, but flash badly when running LW from SIO2SD on a real 130XE under SDX 4.42. The DLI code is nothing spectacular: it just updates (and atracts) two colour registers, and does one store to WSYNC in the process. It's all over the place with SDX, though. This never showed up until I tried it on a real machine, and I've got two days' work under my belt since I made the changes to the DLIs.

 

Does SDX disable DLIs during I/O for the sake of speed? I'm wondering if I can "force" them back on by resetting the interrupt enable bit during the VBLANK. That seems the only possible fix. If that doesn't work, I'll have to go back to the previous version of the program. I can't really use PMGs for colour change since the program is compatible with TDLINE and I can't see recovery after system reset looking too pretty when using PMGs for colour change. Also, PMGs take memory I can't spare.

 

I knew there'd be a spanner thrown in the works somewhere!

Edited September 16, 2009 by flashjazzcat

[Rybags]

Is it in normal speed or a Turbo mode?

 

I'd try the VBlank re-enable DLI trick.

 

One thing... you might encounter the case of some DLIs being missed when SIO starts if it is the case that SpartaDOS disables them, so you might get occasional glitches.

 

That's a pain... when dealing with DOS, you can't really "predict" if a GET or PUT characters operation initiates I/O.

If you did your I/O in exact blocks of 125 bytes, you might be able to guarantee that a SIO operation takes place. Then you could do timing tweaks, e.g. always initiate the CIO call somewhere lower down the screen.

 

But then you have the added problem that the sector size might be bigger.

[flashjazzcat]

Is it in normal speed or a Turbo mode?

 

I'd try the VBlank re-enable DLI trick.

 

One thing... you might encounter the case of some DLIs being missed when SIO starts if it is the case that SpartaDOS disables them, so you might get occasional glitches.

 

That's a pain... when dealing with DOS, you can't really "predict" if a GET or PUT characters operation initiates I/O.

If you did your I/O in exact blocks of 125 bytes, you might be able to guarantee that a SIO operation takes place. Then you could do timing tweaks, e.g. always initiate the CIO call somewhere lower down the screen.

 

But then you have the added problem that the sector size might be bigger.

I think the SIO2SD baud rate is on the ragged edge: not sure if the high transfer rate is to blame.

 

There's no way I'm going to start tweaking things at the SIO level: the point of LW is that it works with any DOS that keeps clear of $C000-$FFFF. It seems to me that the DLI is being repeatedly disabled then re-enabled during SIO operations. I'll try the VBLANK trick and see what happens. In any case, I'm hoping draco will be able to shed some light on this problem.

[drac030]

SDX SIO.SYS disables NMI for high baudrates (POKEY index 6 and lower), and does that for a good reason. Trying to force it back will obviously cause SIO overruns.

 

If you did your I/O in exact blocks of 125 bytes, you might be able to guarantee that a SIO operation takes place.

 

You can never guarantee that, as at the file I/O level you have no clue, what is the amount of data the particular DOS stores in a sector, or if it doesn't require reading anything else from time to time.

[flashjazzcat]

OK, VBI trick doesn't work anyway: at least not with the speeds I'm running. It's unacceptable to have this glitch anyway, not least for reasons of potential data loss.

 

I kind of liked the progress indicator during the copy operation, though, and the whole program ran more smoothly without hiding the bottom two lines during disk activity. I'll investigate whether I can use a PMG, but I seriously doubt I have the available RAM (and in the appropriate spot). Syncing a PMG with the TD line is going to be bundles of fun, too...

 

Any ideas?

[flashjazzcat]

Urgh... to Hell with it. I'm gonna leave it as it is. I just conducted some tests and with a very slight drop from the edge-of-the-seat SIO2SD baud rate I was using, everything's steady again. My SIO2SD is set to 52640.37 ($0A) and the display looks steady during disk I/O.

 

If this is going to cause major inconvenience, I'll rethink it.

[Shawn Jefferson]

If you only want PMG to do some color blocks in a certain area of the screen, you might be able to use the GRAFn registers instead of doing PMG DMA. No extra memory required in that case. Anyway, it might be an option for you.

[Rybags]

The problem there is you still need a DLI.

And in many cases, missed DLIs will make things look worse than if it was only a simple colour change taking place.

[Shawn Jefferson]

yes, I see your point!

[flashjazzcat]

GRAFP would have been ideal, but as you say, we'd still need a DLI to start the shape off part way down the screen.

 

I'm still in two minds about this. I might put a version out to test again to get an idea of what percentage of the time this is going to cause a problem. Plainly, it works well with all but the very highest SIO baudrates. What about PBI connected hard disks, etc? I'm uncomfortable building in a potential bug like this; pity there's no easy way around it. I'm keeping two versions of the program in wait depending on the outcome.

[flashjazzcat]

Been doing further testing this morning, and the problem has disappeared, even with very high baud rates. More testing is required...

[drac030]

What about PBI connected hard disks, etc?

 

PBI hard disks have no reason to disable any interrupts during I/O (though the OS disables the VBL phase two having entered the main sector I/O routine).

Edited September 17, 2009 by drac030

[flashjazzcat]

Good, well that narrows down the field a bit. Gonna test this for a couple of days with different baud rates and chart the results.

[flashjazzcat]

Restricted test copy posted out...

[+Stephen]

Restricted test copy posted out...

I need a spare Atari hooked up here at work. I wonder if anyone would notice?

 

Stephen Anderson

[flashjazzcat]

LOL! I can't even get near the forum, let alone an emulator, let a alone a real Atari when I'm at work. Imagine that pain!

[atariksi]

The problem there is you still need a DLI.

And in many cases, missed DLIs will make things look worse than if it was only a simple colour change taking place.

 

It depends on how many PMs he needs-- he can overlap the PM memory area and use only 256 bytes if he needs just one player. Then he won't need a DLI.

[flashjazzcat]

It depends on how many PMs he needs-- he can overlap the PM memory area and use only 256 bytes if he needs just one player. Then he won't need a DLI.

That was the approach I tried when just thinking about plain old PM graphics. I figured I'd need a few players to cover the entire width of the screen, even at quad width, though, so the memory demands rapidly got out of hand. Then there was the problem of the TDLINE jumping back in after a system RESET or DL change. The program would have to inspect the modified DL (TDLINE points VDSLST to its own DL, which in turn jumps to the original DL) and figure out how many lines to drop the PM graphics, preferably while DMA is turned off. Mainly because of memory requirements, it was a non-starter.

[atariksi]

It depends on how many PMs he needs-- he can overlap the PM memory area and use only 256 bytes if he needs just one player. Then he won't need a DLI.

That was the approach I tried when just thinking about plain old PM graphics. I figured I'd need a few players to cover the entire width of the screen, even at quad width, though, so the memory demands rapidly got out of hand. Then there was the problem of the TDLINE jumping back in after a system RESET or DL change. The program would have to inspect the modified DL (TDLINE points VDSLST to its own DL, which in turn jumps to the original DL) and figure out how many lines to drop the PM graphics, preferably while DMA is turned off. Mainly because of memory requirements, it was a non-starter.

 

You can enable double line resolution and move a few bytes within the PM memory area. So even with 4 players, you only use up 512 bytes of memory.

[Rybags]

Idea:

 

Don't support TDLine. It's too much hassle.

 

IMO, you'd be way better off just putting in support for Real-Time Clocks and dealing with displaying the time yourself, if you choose to do so.

[flashjazzcat]

Idea:

 

Don't support TDLine. It's too much hassle.

 

IMO, you'd be way better off just putting in support for Real-Time Clocks and dealing with displaying the time yourself, if you choose to do so.

Well, TDLINE works very well with the DLI approach, but I wouldn't support it if I went for the PMG solution. I'm waiting on test results for the DLI version: PMGs are impossible with this version of the program (believe it or not, even 512 bytes is out of the question), so if the DLI has to go during I/O, I'll just revert back to the prior system which employs a dynamic display list during disk access.

Edited September 18, 2009 by flashjazzcat