SpartaDOS X 4.49 (release version)

[Brad Nelson]

DEVICE C:>BIN>DOSKEY C:>ALIASES.INI

 

Ahh. Now aliases are working for me. Many thanks, drac030. I appreciate it. And I think part of my problem was not having that first path delineated after the DEVICE declaration. I had only the path for the ALIASES.INI. I'm new to much of this and it takes time to get it, for sure.

[_The Doctor__]

@drac030 , I am looking for the very final 4.49f images et al. as the archive on the project page does not contain it.

 

4.49g has a nasty problem with KEY being off, it won't key repeat and you can't delete backspace more than once in a row nor any other key repeated in a row. If you type KEY ON then it's business as usual and all is working. I normally turn KEY OFF for various reasons, and KEY OFF is the default in any event. As I muddle through 'g' it's kind of hit or miss. I'd like the very last 4.49f and then will continue testing and trying g.

On 1/2/2022 at 2:06 PM, drac030 said:

There is a new beta version of SpartaDOS X available on the relevant website: 4.49f, dated 31 December 2021. It can be downloaded from here: http://sdx.atari8.info/index.php?show=en_download_beta

 

The list of changes relative to the previous beta, 4.49e, is available in the file whatsnew-4.49f.txt

 

Perhaps the most important change in this release is that the CAR: device is no longer limited to 8176 bytes per file. The new limit is 7*8176=57232 bytes per file. To take advantage of that, you have to use the new SDXImager, which handles both formats (the new and the old one). The new imager program can be downloaded from here: http://sdx.atari8.info/index.php?show=en_addons

 

Sorting the directories should now be much improved, as SORTDIR.COM now uses a new, much faster sorting routine. By "much" I mean 40-50 times faster than the old ICD code. The same sorting routine is used by Sparta Commander to sort directories in real-time for display.

 

The ED text editor can now run on VBXE 80-column text console as well as on the software-driven 80-column text console (provided by RC_GR8.SYS).

 

Besides, there were bugfixes and minor improvements all around.

 

65C816 support

==========

Also, this version comes with improved 65C816 support, which is now centralized in a form of unified driver, 65816.SYS (this one is for Rapidus OS, and there is another instance for AltirraOS/816, named 65816A.SYS). Owners of Rapidus and Antonia machines may want to put that driver onto the CAR: device before flashing the SDX ROM, along with the SIO816.SYS - these are available on the Toolkit disk, among few others which can be loaded from the HDD. The immediate effect of configuring the system to use these is that much more conventional RAM would be free - as the new drivers load to the RAM past the first 64k. All this is also usable on Altirra.

 

The 65816.SYS driver, among other things, contains the binary loader able to load relocatable binaries in SpartaDOS X format to the RAM past the first 64k. Such binaries can be built using the assembler ELSA http://drac030.krap.pl/pl-elsa-pliki.php

 

Below I am attaching some small demo program which may help to test, if the 65816 support stuff is properly configured. It requires VBXE. The source code is included.

 

Have fun.

 

stars3dr.arc 17.29 kB · 53 downloads

 

[drac030]

3 hours ago, _The Doctor__ said:

4.49g has a nasty problem with KEY being off, it won't key repeat and you can't delete backspace more than once in a row nor any other key repeated in a row. If you type KEY ON then it's business as usual and all is working. I normally turn KEY OFF for various reasons, and KEY OFF is the default in any event. As I muddle through 'g' it's kind of hit or miss. I'd like the very last 4.49f and then will continue testing and trying g.

4.49g is literally 4.49f with one fix related to TAB handling in DOSKEY. Everything else is identical. Also, there have been no substantial changes in KEY.COM since 2014. I cannot reproduce the problem here either, so more information may be needed.

 

If you have more random problems with 4.49g - as I understand "hit or miss", though I am not really sure what this means - then it can be a case of a bad flash. If the problems persist after reflashing, report them here.

[_The Doctor__]

130XE with MIO and Fujinet SpartaDOS Super Cart with real time clock (aka ultimate time clock) fresh down load from SDX site.

Flash the cartridge, Broken Command line input system, won't repeat won't accept same key twice, KEY ON... oh look it works, KEY OFF key repeat is gone and pressing the same key twice results in no further input on the duplicate key press.

4.49f is not in the archive.

g is not working as outlined, and as a result, depending on what you launch the key input is the same as CP

Probably best to try it using a standard 130XE no bells or whistles, same response on different 130XE and black box etc.

Only way it's a bad flash is if the source is corrupt.

They all flash back down to plain 4.49 without issues 4.49f was pretty good during it's last iteration, so I thought I'd flash back to it, and couldn't find it.

I have 4 Super Carts, all the same response, two different XE's with two different PBI devices and one Fujinet, again same results.

Edited April 3 by _The Doctor__

[TGB1718]

@_The Doctor__ your post reminded me I meant to upgrade mine from from 449e, so I just downloaded

449g from the SDX site, installed on Altirra and it works.

 

Key repeat on boot is the slower repeat, KEY ON and repeat is faster, I flashed using the SDX449g_ultimate.atr

which came as part of the download.

[drac030]

28 minutes ago, _The Doctor__ said:

130XE with MIO and Fujinet SpartaDOS Super Cart with real time clock (aka ultimate time clock) fresh down load from SDX site.

Flash the cartridge, Broken Command line input system, won't repeat won't accept same key twice, KEY ON... oh look it works, KEY OFF key repeat is gone and pressing the same key twice results in no further input on the duplicate key press.

Cannot reproduce:

 

https://youtu.be/0Im5t6f32-s

 

28 minutes ago, _The Doctor__ said:

4.49f is not in the archive.

Yes, as explained above.

 

28 minutes ago, _The Doctor__ said:

Only way it's a bad flash is if the source is corrupt.

The clip above was recorded with a freshly downloaded ROM image.

 

31 minutes ago, _The Doctor__ said:

4.49f was pretty good during it's last iteration, so I thought I'd flash back to it, and couldn't find it.

Attached. Although, as I said, 4.49g is the same as f minus the DOSKEY crashing in the latter.

SDX449f_supercart.rom

[_The Doctor__]

TGB1718

I should also have stated NTSC, I did not use ultimate build I used the supercart build.

 

Thanks @drac030, I'll flash it and give results this night EST USA time.

 

 

[_The Doctor__]

whatever you changed in the very last 4.49f and 4.49g, you've made it unhappy with the ICD MIO

4.49 plain and it's flasher work fine. When using the latest 4.49f and g the flasher and the actual ultimate cart sdx 4.49f and 4.49g will have problems.

Remove MIO and all works well.

I will need to be able to test all previous SDX's to see where it goes wrong, since I only remember having this issue once before during testing and you fixed whatever it was at that time. I had mentioned a problem with both of these areas in the past but they were never present together at the same time. You fixed the flasher back then. And the entry problem before. Might want to go back and check your notes. I did not know the connection with the MIO at that time, but I wanted to be thorough and tore my systems down to the ground and back up adding each piece one at a time.

The flasher used to tell people to remove carts, if the flasher is going to be this way, it will have to ask to remove MIO or other PBI devices.

This will not solve the actual incompatibility of using the later versions of SDX though as they won't play nice with the MIO 1Meg ROM of old.

I am willing to test each variant from 4.49 stable on up as last I knew it works fine. But I won't simply test just what is on the Project site since all variants are out there and come to haunt us. I will need to test any one since then that made it into the wild.

I am very surprised that no one is using the real hardware and such that often, as I've been the only one to look into this.

I have 4 MIO's, 2 Black boxes, and well a crap ton of gear, the results were the same.

Edited April 4 by _The Doctor__

[flashjazzcat]

Isn't the state of the machine to just use nothing but the OS keyboard interrupt handler until KEY ON is executed?

[drac030]

1 hour ago, _The Doctor__ said:

Remove MIO and all works well.

If someone provides me with MIO firmware ROM images, I will be then able to setup it under emulation and see what is going on there.

 

EDIT: NVM, found one.

 

1 hour ago, _The Doctor__ said:

You fixed the flasher back then. And the entry problem before.

I have no idea what you are talking about. What is "the entry problem"? Is there also any problem with the DLT flasher? You need to be a bit more specific.

 

1 hour ago, _The Doctor__ said:

I am very surprised that no one is using the real hardware and such that often, as I've been the only one to look into this.

I use the real hardware, just do not have a MIO (they are rare in Europe, as far as I know). And otherwise everything works fine.

 

1 hour ago, flashjazzcat said:

Isn't the state of the machine to just use nothing but the OS keyboard interrupt handler until KEY ON is executed?

Basically. When not using DOSKEY, the plain E: handler is being used for console input and output. When using DOSKEY the input is handled by the OS's K: handler via a wrapper provided by the library (U_GETKEY).

 

Edited April 4 by drac030

[_The Doctor__]

The problems began with 4.49e as far as I can recall.

Check your October 2017 and November 2017 notes.

I do know you fixed some issues with the flasher.

2 issues were fixed at that time and you were working on some other idea.

I do know you were aware of the other sections crash (which you fixed in g presumably).

I know you were pondering I/O and considering using IDE+ items in SDX

something currently can confuse APE when using various combinations of SDX versions and e or g bootable flasher disks.

I thought some of these were handled and rolled into f at some point, but I flashed over my f with g... something seemed familiar about it, dejavu... so it was serious thinking and luckily some recall for a change that helped me to outline vaguely the time frame and what was going on. The provided f is similar in problems to e and g.

 

 

Edited April 4 by _The Doctor__

[drac030]

34 minutes ago, _The Doctor__ said:

The problems began with 4.49e as far as I can recall.

And 4.49e is dated 1 Feb. 2021 - over three years ago. And no report. Oh well.

 

Anyway, the diagnosis:

 

The MIO firmware ROM does something it IMHO should not, namely, while executing its code it has hooked onto the SIO the usual PBI way, it writes to the CRITIC variable ($42). I did not trace whether it does it always or only sometimes, but it does. Especially, it can clear it out. This is most probably just a bug, because CRITIC belongs to the overlaying OS and PBI drivers should not touch it, leaving its management to the said OS.

 

Anyways, the SDX did not expect that a call to the PBI may return with CRITIC=0. The code used a pair of INC/DEC to set and unset the CRITIC, so when MIO cleared the variable, the subsequent DEC set it to $FF. This blocks the second phase of the VBL, including the keyboard auto-repetition.

 

The cure:

 

Please get the SDX Imager from the SDX website (the most recent version), or use the web-based version, to replace the relevant files in 4.49g with the revisions attached below. When replaced, set +h attribute for both. Save the new image. Reflash.

 

Then please report back, if it helped.

sio0.ovl sio1.ovl

[Ricky Spanish]

Can you buy this CART ? Google has failed me 🙄

[_The Doctor__]

You can make your own or if you want a specific made for you cart I am told the needed files and parts are possibly now in corei64's hands, but I'm not 100 percent on that

I prefer the versions with a cart reset switch and cart on off switch. Never need to take the cart out of the slot that way.

[Ricky Spanish]

40 minutes ago, _The Doctor__ said:

I prefer the versions with a cart reset switch and cart on off switch. Never need to take the cart out of the slot that way.

Yes, that would be preferable. 

[_The Doctor__]

Fresh download of SpartaDOS X 4.49g re-imaged with the two SIO overlays. Quick check shows KEYS working and APE appears okay. Further testing will be tomorrow.

 

Does SpartaDOS X know when the CSS BlackBox is using XE BANKed RAM for spooling? I see no difference in size with it on or off. Using an additional 64K or 192K of XE banks only yields the same expected sizes. This leads me to wondering which way the BlackBox or SpartaDos X will clobber each other if they are un aware of who's in the XE banks. I am not sure if the usual reservation of RAMDisk banks will alleviate this if SpartaDOS X -using banks- fills the empty spots in. Is there a way to tell SpartaDOS X to USE extended memory after the first 4 banks and of course then we can already tell RAMDisk to use memory after 8 banks if we wish.

Edited April 5 by _The Doctor__

[drac030]

5 hours ago, _The Doctor__ said:

Does SpartaDOS X know when the CSS BlackBox is using XE BANKed RAM for spooling? I see no difference in size with it on or off. Using an additional 64K or 192K of XE banks only yields the same expected sizes. This leads me to wondering which way the BlackBox or SpartaDos X will clobber each other if they are un aware of who's in the XE banks. I am not sure if the usual reservation of RAMDisk banks will alleviate this if SpartaDOS X -using banks- fills the empty spots in. Is there a way to tell SpartaDOS X to USE extended memory after the first 4 banks and of course then we can already tell RAMDisk to use memory after 8 banks if we wish.

SpartaDOS X allocates the ext banks starting at the other end, i.e. the most remote bank first, and 130XE banks last. So, as long as there are at least 4 banks free, you can be sure that 130XE banks are among them. This of course assuming that the BlackBox is really using the four 130XE banks only and not whatever it finds there.

 

Yuo can use the MEMINFO utility to see which banks are allocated and which are free. Banks 4,5,6,7 are the 130XE banks.

Edited April 5 by drac030

[_The Doctor__]

Sounds like reserving 8 from ramdisk was the answer then as it will do the first 4 for spooler, the next 4 for sparta, and the rest for ramdisk. In a decent world. I'll have to see if BB will look higher, and reserve 12, hoping 4 for XE apps, 4 for spooler, 4 for sparta, the rest for ramdisk.

 

Edited April 5 by _The Doctor__

[_The Doctor__]

Did the fixes get rolled into the BETA on the SDX Project site?

It's been smooth sailing so I hope so. I flashed everything I had with the SIO overlays and things have been better. I've been recommending 4.49G to others and want to be sure they're getting those and other fixes

[drac030]

On 8/6/2024 at 3:58 AM, _The Doctor__ said:

Did the fixes get rolled into the BETA on the SDX Project site?

No. We gave up the public betas, because hardly anybody was betatesting them. The betas are now distributed by some other channel, much less public. And, interestingly, it is much more effective concerning bug reports.

[_The Doctor__]

Okay,

Anyone downloading 4.49G needs to do this by hand I gather?

I had at least 4 years where I couldn't dedicate any time to working through all the projects with any tenacity, just made mentions here or there. 4.49G Beta on the site plus the above ovl files certainly made a huge difference across the board. Hopefully both avenues lead to such things being nailed down. Pleasant times when things are working consistently. Thanks for revisiting the issue and making the fixes. Real life being what it is, has decided to be a pita in so many ways.