SDX TDLINE / SETVBV problems

[flashjazzcat]

This afternoon I realized the title screen of my program, since it includes a redefined non-alpha character set, does not work well with the SpartaDOS X Time/Date Line. Shame, since the rest of the program does. Moreover, I didn't like the look of the TDLINE above the loading screen: I thought it would look better temporarily disabled anyway.

 

My first port of call was the SDX Manual: "Vectors Under the OS ROM". This seemed to have just what I needed. In the absence of any other information, I figured the best way to test for the presence of the time/date line was to check if VDSLST pointed somewhere in low RAM. The next task was to turn off (and later re-enable, once the loading screen had cleared) the TD line itself. I tried using the vector VTDON which lives under the OS ROM; however, I couldn't get this to work, and in any case by the time the application had loaded, it would have obliterated all the SDX vectors which live under the OS.

 

I thought about it for a while longer, and then decided the best thing to do was simply point VVBLKD back to the OS VBI exit point XITVBV at $E462 (only XL/XE machines can use the app, although I'm aware that using this technique will create problems with custom operating system ROMs). I thought I'd be good and use SETVBV. Surely this should have worked:

 

	LDA #7
LDY #$62
LDX #$E4
JSR SETVBV

However, the TD line would tend not to disappear completely, causing the program to crash catastrophically when I later used SETVBV to restore the saved vector (and thus re-enable the TD line).

 

The only thing I've found to work is to riskily alter the vector at $224 directly. I also inserted a loop which waits one jiffy after turning the TD line off before any more disk I/O can occur. It works well, but it would have been nice to do things more cleanly. I couldn't even find anything in the SDX Programming Manual about turning the TD line on and off. A simple flag on page seven would have been great; I'm unsure if there's a KERNEL call which turns the TD line on and off.

Edited August 27, 2009 by flashjazzcat

[drac030]

My first port of call was the SDX Manual: "Vectors Under the OS ROM". This seemed to have just what I needed. In the absence of any other information, I figured the best way to test for the presence of the time/date line was to check if VDSLST pointed somewhere in low RAM.

 

Actually, if TD.COM was not loaded, the VTDON vector contains RTS. But that's true, that there is no way for a program to check, whether the TD is on or off. However, trying to turn it off when it is already off, should be harmless.

 

The next task was to turn off (and later re-enable, once the loading screen had cleared) the TD line itself. I tried using the vector VTDON which lives under the OS ROM; however, I couldn't get this to work, and in any case by the time the application had loaded, it would have obliterated all the SDX vectors which live under the OS.

 

VTDON accepts the argument in Y register: $00 = off, $01 = on. It should work. That's true that any program loaded underneath the ROM destroys the vectors - they're provided only for backward compatibility with SpartaDOS 3.x.

 

I thought about it for a while longer, and then decided the best thing to do was simply point VVBLKD back to the OS VBI exit point XITVBV at $E462 (only XL/XE machines can use the app, although I'm aware that using this technique will create problems with custom operating system ROMs).

 

Why?

 

I thought I'd be good and use SETVBV. Surely this should have worked:

 

	LDA #7
LDY #$62
LDX #$E4
JSR SETVBV

However, the TD line would tend not to disappear completely, causing the program to crash catastrophically when I later used SETVBV to restore the saved vector (and thus re-enable the TD line).

 

That's odd, if this doesn't work, because TD.COM uses exactly this call to turn itself off, when asked to.

 

A simple flag on page seven would have been great; I'm unsure if there's a KERNEL call which turns the TD line on and off.

 

The flag's disadvantage would be that it would need to be monitored every VBL. As written in the manual, the TD line can be enabled and disabled by calling the on/off routine, either via VTDON, or via the symbol I_TDON. Their use is indentical, you just have to make a symbol lookup first (via jfsymbol routine, available as of 4.40).

[flashjazzcat]

I thought about it for a while longer, and then decided the best thing to do was simply point VVBLKD back to the OS VBI exit point XITVBV at $E462 (only XL/XE machines can use the app, although I'm aware that using this technique will create problems with custom operating system ROMs).

 

Why?

Just in case an OS had moved XITVBV somewhere other than $E462. Unlikely, I suppose!

 

The flag's disadvantage would be that it would need to be monitored every VBL. As written in the manual, the TD line can be enabled and disabled by calling the on/off routine, either via VTDON, or via the symbol I_TDON. Their use is indentical, you just have to make a symbol lookup first (via jfsymbol routine, available as of 4.40).

I think, on balance, the quick and dirty method I've used will do fine. I'm fighting for space in all areas of the program, but I certainly wanted to maintain TD compatibility. The behaviour of SETVBV was certainly very strange: the TD line seemed to persist and only disappear after the VDSLST had been changed. However, when it had been disabled in this shaky fashion, re-enabling the TD line deferred VBI would always cause a total system lock-up.

Edited August 27, 2009 by flashjazzcat

[drac030]

Just in case an OS had moved XITVBV somewhere other than $E462. Unlikely, I suppose!

 

Highly unlikely, because $E462 is a jumptable entry to the routine

 

The behaviour of SETVBV was certainly very strange: the TD line seemed to persist and only disappear after the VDSLST had been changed.

 

Nothing strange in it. TD line adds one line to the actual display list, so when you unhook its VBL routine, it stops, but it wouldn't disappear. Calling TD OFF (manually, via VTDON or I_TDON) is the only proper way of disabling TD line and cleaning everything up.

 

Imagine that it is not done via DL and ANTIC, but via XDL and VBXE. In this case, no DL manipulations would do. Only TD.COM knows, how to do that properly.

 

It certainly can be done cleanly, just as you can do by a XIO call via Z.SYS. Internally this is performed exactly in the way I am speaking about, i.e. by making a jsr to I_TDON with Y=$00.

Edited August 27, 2009 by drac030

[flashjazzcat]

Nothing strange in it. TD line adds one line to the actual display list, so when you unhook its VBL routine, it stops, but it wouldn't disappear. Calling TD OFF (manually, via VTDON or I_TDON) is the only proper way of disabling TD line and cleaning everything up.

 

It certainly can be done cleanly, just as you can do by a XIO call via Z.SYS. Internally this is performed exactly in the way I am speaking about, i.e. by making a jsr to I_TDON with Y=$00.

Of course; I'd probably lost sight of the fact that since abandoning proper SDX calls it was only the change of DL address which would actually remove the TD line. The glitches were presumably due to disk activity happening before the shadow registers had fully updated.

 

Other bugs to trample now...

[dwhyte]

I've noticed this one for a while now but I never really considered it a bug though. I have a TD ON command in my AUTOEXEC.BAT file and to workaround the garbled TD display on loading I just created a LW.BAT file that turns off TD before loading LW (TLW?) and then switch it back on after the program is done executing, before the command line comes back up...

 

However, I must admit that I wouldn't object to having the TD line up when I'm writing...

 

On a side note: I have to say that I'm using LW (TLW?) more than Word 2007 as of late for text entry. I've just been using Word mainly for typesetting since the advent of LW (TLW?). Keep up the awesome work!

Edited August 27, 2009 by dwhyte

[flashjazzcat]

I've noticed this one for a while now but I never really considered it a bug though. I have a TD ON command in my AUTOEXEC.BAT file and to workaround the garbled TD display on loading I just created a LW.BAT file that turns off TD before loading LW (TLW?) and then switch it back on after the program is done executing, before the command line comes back up...

 

However, I must admit that I wouldn't object to having the TD line up when I'm writing...

Well, now you can. I'll shoot an updated copy across before the weekend (the copy I sent out today doesn't include this fix). LW was developed for a long time with SpartaDOS X and the old loading screen worked fine with the TD line so I do consider this one a bug. However, many changes occured since I moved over to WUDSN and now I'm testing with SDX again (it's a little more convenient to use DOS 2.5 when doing cross-compiler development because with SDX there's no easy way to load an executable from H: via the command line) I find that several things have broken. You'll be glad to hear you can just leave TD on when you load up the word processor now: it just disappears temporarily while the loading screen displays. Don't forget you can include the "/Q" switch on the command line which suppresses the loading screen (a couple of screen glitches with that feature have been fixed today, too ).

 

On a side note: I have to say that I'm using LW (TLW?) more than Word 2007 as of late for text entry. I've just been using Word mainly for typesetting since the advent of LW (TLW?). Keep up the awesome work!

That's good to hear! I kind of miss writing source code and compiling on the Atari (in emulation), so I'm using LW to work on a couple of small assembler projects at the moment. It's about the best way to test the program: I loaded up a 25K source file the other day, translated over a thousand ASCII carriage returns in a few seconds, then split the file in two using the segmentation features.

 

Thanks for the encouragement.

Edited August 27, 2009 by flashjazzcat

[Rybags]

Might be a long-shot here, but check what the Sparta VB routines do.

 

It might be that they point the DList to their own one, then have a Jump DList that goes back to the start of the user's one.

 

That seems the logical way to do things, but it's theoretical that the whole thing might break down if you don't have the usual looking DList that has 3x8 Blank Lines followed by the initial LMS Mode 2 instruction.

[flashjazzcat]

Might be a long-shot here, but check what the Sparta VB routines do.

 

It might be that they point the DList to their own one, then have a Jump DList that goes back to the start of the user's one.

 

That seems the logical way to do things, but it's theoretical that the whole thing might break down if you don't have the usual looking DList that has 3x8 Blank Lines followed by the initial LMS Mode 2 instruction.

That's absolutely what the TD line routine does. It has its own DL with a jump instruction to the start of the user's DL. I think some of the blank lines at the start of the user's DL are skipped; can't remember offhand but it must be the case since the display isn't dropped by a full eight lines. LW already had code in the editor loop to check for changes to the DL (for example, if the E: device is inadvertently re-opened), and this code checks for the presence of the TD line (otherwise LW would constantly think that VDSLST was pointing to the wrong location).

 

The new loading screen clearly presents to TD line problems other than a redefined character set. Not sure why, but it's fixed now anyway.

Edited August 28, 2009 by flashjazzcat

[flashjazzcat]

Just for some closure on this problem: I realized I was calling SETVBV the second time with the OS ROM switched out. A simple inc/dec PORTB around the code fixed it.