Jump to content
IGNORED

SpartaDOS X 4.49 (release version)


drac030

Recommended Posts

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 .

 

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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 by drac030
  • Like 5
  • Thanks 1
Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

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 by drac030
  • Like 2
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 :D

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.

  • Thanks 2
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...