SpartaDOS X 4.49 (release version)

[BillC]

31 minutes ago, Kyle22 said:

Unless memory is failing me, I thought COLD /C is cold start with SDX off and cart enabled.

 

Yes it is, INIDOS.SYS is the utility that can be booted to turn SDX back on.

[Roydea6]

Getting Altirra [Emu] set up with all the new rom and tool kit items with VBXE support I noticed that v_bxe.sys causes any further screen activity to jump to line 1 of the display over writing previous INFO.

            Is this intended .

I don't have a working VBXE hardware in any of my real hardware to verify .

 

[drac030]

Here it does not (neither on real hw nor on the emulator). So I need further info to reproduce the problem.

 

[+Stephen]

I can confirm everything is working on real hardware with the latest 4.49 code.

[Roydea6]

https://www.dropbox.com/s/yrsqre1o1go5w3g/vbxe.mp4?dl=0

 

For those that want to see what I am talking about..  I added a couple of echo statements so the effect is more noticeable.

 

 

[+Stephen]

Can you please post your config.sys (and autoexec.bat if you're using it).

[Roydea6]

Config.sys

 

DEVICE ENV
DEVICE SPARTA OSRAM
DEVICE SIO
DEVICE ATARIDOS
DEVICE COMEXE
DEVICE ULTIME
DEVICE JIFFY
;DEVICE RAMDISK
ECHO SDX449 U1M 4-28-20

 

Autoexec.bat

 

SET ED=20
SET DAYTIME=1
SET MAXDRV=O:
SET LWSDXDEV=1
SET PROMPT=$L$P\
SET LWPATH=C:TLW
SET PAGER=XLESS;/C;%
SET BASIC=J:BASIC.SAV
SET MANPATH=CAR:;D:MAN
SET PATH=CAR:;H:;:;C:SYS;C:SDOS
PCLINK.SYS
S_VBXE.SYS
ECHO JUMP TO TOP.
ECHO JUMP TO TOP.
CAD.SYS $CC 2 ON
POKE $41 $00
CON.SYS
SDXTIME

 

[+Stephen]

The only thing I notice that is different in my setup, is I have the CON.SYS (the latest fixed one, which was initially named VCON.SYS) directly below the S_VBXE.SYS driver.  Maybe try moving that up before you issue any ECHO commands.  Purely speculation at this point.

[Roydea6]

1 minute ago, Stephen said:

directly below the S_VBXE.SYS driver.

i had it just below the s_vbxe.sys driver but moved it down to prove that it was not at fault.

 

[ebiguy]

Not related specifically to SDX 4.49 but I am wondering if SDX keeps page 6 free (no driver or I/O buffer or whatever) so that Basic programs using this area could still work reliably.

I remember that this area was very often used to put data or small asm routine.

[flashjazzcat]

Just now, ebiguy said:

I am wondering if SDX keeps page 6 free

Certainly it does; rather a lot of software would fail otherwise.

[Faicuai]

9 minutes ago, ebiguy said:

Not related specifically to SDX 4.49 but I am wondering if SDX keeps page 6 free (no driver or I/O buffer or whatever) so that Basic programs using this area could still work reliably.

I remember that this area was very often used to put data or small asm routine.

Well, not sure, because I just booted SDX (forcing CONFIG.SYS boot, but excluding Autoxec.bat) and I can see parts of page 5 and page 6 in use... by what it looks to be ULTIME.SYS

 

Better check with SDX-team on this one...

[drac030]

CON probably does "cursor home" when it gets installed, it should be fixed (it should only do that when being both installed and *enabled*).

 

Page 6: it will get overwritten in two situations:

 

1) at startup. Programs such as SPARTA.SYS, SIO.SYS, clock drivers, RAMDISK.SYS, whatever that is going to install residently will use pages 4,5,6 as a transitional area to store the init code. That is why one can see garbage on page 6 after loading a (larger) resident driver.

 

2) CAR.COM (invoked when you use CAR or BASIC commands at the CP prompt) will reload the contents of pages 4,5,6 from CAR.SAV or BAS.SAV files, if it finds them, before entering the cartridge.

 

Apart of that, page 6 is unused.

Edited April 27, 2020 by drac030

[ebiguy]

Maybe I asked for something that already exists but I am not aware of.

In the History resident tools that is used in my SDX packaging for MyIDE II, I redirect VKEYBD ($0208) to handle one particular key combination (Shift-Control-Up) but I jump to the old handler if it is another key combination.

Maybe there is a better way to do that.

A couple of days ago, I played with KEY.COM (never used it before) and found that it prevents my History resident handler to detect Shift-Control-Up.

So my conclusion is that KEY.COM is not really fair as it 'steals' the vector for its own use, consuming all key events.

Of course I can load HISTORY after KEY so that my resident handler is the last one to redirect the kbd vector.

So 2 questions:

- Should I used another way to detect my key combination (something different than redirecting VKEYBD) ?

- If not, would it be smart to have something offered by SDX to chain keyboard handlers in an official way ?

[drac030]

15 hours ago, ebiguy said:

KEY.COM is not really fair as it 'steals' the vector for its own use, consuming all key events

KEY.COM is a keyboard buffer driver, it has to buffer key events, then feed programs with them, when they are ready to receive them. So I guess it cannot pass the processing on to the original keyboard handler, because there will be a conflict.

As about the service to chain the keyboard handlers, I do not think it would solve much, but it certainly would occupy memory (and keeping the MEMLO as low as possible is one of our goals).

Loading the history program after key probably will not solve much either, because KEY will grab the interrupt vector again after one does KEY OFF, then KEY ON.

I have no clear thoughts on it at the moment, but maybe using the interrupt service is an overkill and the thing could be solved by hooking your history program onto the CIO keyboard vectors? I mean, by reallocating the vector set and correcting the entry in HATABS. I did not check this but you could then probably catch whatever is in KBCODES before the regular keyboard handler kicks in, and the keyboard buffer would not be a problem anymore.

[drac030]

On 4/27/2020 at 8:20 PM, Roydea6 said:

i had it just below the s_vbxe.sys driver but moved it down to prove that it was not at fault

I found something. It first of all appears that the *_VBXE.SYS drivers' revisions which have been released on the Toolkit disk are not the latest ones. I am not sure how this could have happened, but it did. So please first of all see if using this makes difference:

 

svbxe107.arc

 

Second, I noticed that the function responsible for drawing text in VBXE pixel modes (XIO 105) is busted: it hangs when the proportional mode is invoked. I will have to trace it down, for now just do not call that

Edited April 30, 2020 by drac030

[+Stephen]

1 hour ago, drac030 said:

I found something. It first of all appears that the *_VBXE.SYS drivers' revisions which have been released on the Tolkit disk are not the latest ones. I am not sure how this could have happened, but it did. So please first of all see if using this makes difference:

 

svbxe107.arc 38.94 kB · 0 downloads

 

Second, I noticed that the function responsible for drawing text in VBXE pixel modes (XIO 105) is busted: it hangs when the proportional mode is invoked. I will have to trace it down, for now just do not call that

I have a question regarding the S_VBXE driver.  I am using SDX and Turbo-BASIC XL for easier code prototyping.  I open a standard resolution 256 colour mode via:
OPEN #6,12,3,"S2:":REM 320x192 in 256 colors

I am "drawing" to the screen via BPUT#6

 

Is there an example of using the driver, but extending the build in graphics mode 3 so that I can use all 240 lines rather than just 192?  Also, if I were to do this from within Turbo-BASIC, would the graphics commands such as BPUT, PLOT, DRAWTO work with all 240 lines or would they be constrained to the OS limit of 192?

[drac030]

4 hours ago, Stephen said:

s there an example of using the driver, but extending the build in graphics mode 3 so that I can use all 240 lines rather than just 192?

Unfortunately, not. I even tried to define such a mode today, but there are some principal problems with it:

 

1) the routine building the XDL is assuming that there is at least one scanline of upper border. So it could not be 320x240 currently, at most 320x239.

2) 320x192 is 60 KB, 320x240 is 75 KB. Which means that we can address 320x192 with 16-bit offset, but for 320x240 the routine doing the calculation will overflow. And it does

3) I was writing all this like 12 years ago and I simply forgot how the code works. So this needs a deeper study before applying any changes.

 

The "open" routine probably needs a big rewrite so that it could build more customized display modes. If there is need, I could sit at that, why not.

 

4 hours ago, Stephen said:

Also, if I were to do this from within Turbo-BASIC, would the graphics commands such as BPUT, PLOT, DRAWTO work with all 240 lines or would they be constrained to the OS limit of 192

They most probably would not be constrained: mode 4 (hires) is 640x192 and still PLOT/DRAWTO/CIRCLE work with it without being constrained to the OS limit of 320 pixels of width. So I guess the screen height similarly only depends on what the actual screen driver considers valid.

[Jacques]

On 4/30/2020 at 7:50 PM, drac030 said:

I found something. It first of all appears that the *_VBXE.SYS drivers' revisions which have been released on the Toolkit disk are not the latest ones. I am not sure how this could have happened, but it did. So please first of all see if using this makes difference:

 

svbxe107.arc 38.94 kB · 4 downloads

 

Oh, good to know, so this 1.07 is supposed to be stable/release version, so the one from tha latest toolkit can be safely replaced?

[drac030]

This is the revision which sits in the CVS and was supposed to be released on the Toolkit disk, but by some mistake we have released binaries which had been compiled two weeks earlier. I am to blame, probably (probably to blame, that is).

[_The Doctor__]

With all the fix ups and what not just call it 4.49e or   4.49f      (for final)  after all the substitutions and fix up are done. Maybe include all the latest that everyone suddenly came out with and had to fix up as well... 4.49f  the final fix-ups edition especial!

[drac030]

In fact we already have 4.49e, but as no critical bugs have emerged so far there is no reason to publish it. The SDX Toolkit is another matter, we will probably publish an updated revision in, er, due time

[ebiguy]

Is there a list of addresses at $07xx with their official names and usage?

[drac030]

There is no comprehensive list, but many of the locations - at least these which are of use for application programs - are described in the SDX Programming Guide, in the sections containing the descriptions of the library functions which use them.

 

Putting such a list together, along with the usage, is not a quick task, as there are f.e. various vector tables for FMS drivers, device drivers, SIO drivers, entries to kernel, misc, block_io (all of them have a handful of subfunctions each) and such stuff. So it may be perhaps easier if you tell now what you need out of those.

[ebiguy]

Arg, I don't need one particular location. I need the full list.

To be fully transparent, this is for DIS6502.

I just finished, 5 years later, the support of SDX executable disassembly in DIS6502.

But my list of locations is (you guessed it) 5 years old (the one I collected for version 4.46 - I don't remember how).

That's why I was asking for an updated one.

But maybe you have some kind of include file that you use for compiling SDX code or toolkit that you would be willing to share.

Would be cool to have the official list.