Why is SpartaDOS X Cartridge Only?

[pixelmischief]

...and why is there not an equal appetite for parallel/merging development on a disk-based SpartaDOS?

[Paul Westphal]

http://atarionline.pl/v01/index.php?ct=utils&sub=8. DOS-y

[pixelmischief]

2 hours ago, Paul Westphal said:

http://atarionline.pl/v01/index.php?ct=utils&sub=8. DOS-y

Uhhh...ok.  Was that supposed to be an answer to the question?

[+Stephen]

Because there is so much code which is paged in and out.  It would never be as nice if there was constant loading over the slow SIO port.

 

There is Real DOS and I do not mean to put it down, but again I see it as pointless trying to do something like that disk based when we have these mega carts that load everything seamlessly and instantly.  I'm pretty much never not using SDX without a HDD, I am used to everything loading between 60 and 80kB/sec.

[Stormtrooper of Death]

Stephen, but what about using floppy based SDX with 128K (or more memory) Atari computers ? Lots of SDX code can be stored in the ramdisk of the 128K+ machines, so not much code page swapping from floppy.....

 

And there are still much more Atarians that do not have cart based HDD gear (SDX/AVG/etc) in 2022, but like to use SDX floppy instead of the old Spartados versions..

Edited September 15, 2022 by Stormtrooper of Death

[flashjazzcat]

The main problem I see - even on systems with lots of RAM and fast mass storage - is contention for the RAM banking window. With a bank-switched cartridge, ROM-based code has free and unfettered access to all RAM on the system (except the RAM in the cartridge ROM address space), but when you have data - such as the SDX symbol table - stored entirely in banked RAM, with the code accessing it (and fixing up relocatable binaries) also in banked RAM, and all the drivers in banked RAM, and the SDX library and kernel also in banked RAM - I imagine it can become exponentially complex (and possibly slow), since pretty much everything exists in multiple RAM banks in the exact same address space.

 

In addition - for those determined to boot the system from floppy disk - the amount of data which would need to be read from disk and installed in RAM to create a working SDX system will all resources held in RAM would be quite considerable (remembering that current SDX versions have a base requirement of 128K of bank-switched ROM).

 

BeweDOS is pretty nice, anyway: boots from disk and doesn't even use the RAM under the OS.

 

[pixelmischief]

Thank you for the answers!

 

I think that fast mass storage makes disk loading of external commands a wholly excellent experience.  And it comes with the benefit of easier and more intuitive OS upgrading.  The continued proliferation of games and solutions that require 128K+ to run has already signaled an acceptance for software that squeezes out 800/400/XL machines without upgrades.  The move away from ROM-based operating systems was an architectural change fundamental to the emergence of the PC architecture as ubiquitous.  It just makes everything so much faster and more fluid.  I would love to see the Atari support that same paradigm.

 

I have a number of motives for my pleas.  First, I would love to boot my Atari from my MIO with the latest SpartaDOS and be able to upgrade it on-the fly with disk-based patches.  Next, my upgraded 3.5" XF has 720K, which is plenty large and fast enough to make this work.  My several IDE solutions, 16MB image on SIO2SD...you get the point.  I hate flashing carts and writing cards on PC to get to my Atari.  The FujiNET makes this so much more appetizing by keeping the whole ecosystem at the Atari.  I know that reflashing from ATRs is a thing, but it just seems to break the immersion.  But most of all, I just love floppies and dynamic media in general, and I am a bit concerned that by ignoring disk devices as part of the supported stack for the newest software on the A8 that those devices will become less and less relevant...in relative terms, of course.

Edited September 15, 2022 by pixelmischief

[ivop]

Would it be possible to create a custom cartridge version where CAR: is empty and everything resides on Dx: ?

 

Edited September 15, 2022 by ivop

[flashjazzcat]

1 hour ago, pixelmischief said:

The move away from ROM-based operating systems was an architectural change fundamental to the emergence of the PC architecture as ubiquitous.  It just makes everything so much faster and more fluid.  I would love to see the Atari support that same paradigm.

Along with ubiquitous and fast mass storage, having a large linear address space in RAM (which the Atari doesn't) also helped greatly.

1 hour ago, pixelmischief said:

I hate flashing carts and writing cards on PC to get to my Atari.

You can't please everyone, it seems. For those looking for a new DOS, I recently wrote one (currently supplied as part of the SIDE3 firmware) which uses FAT16/32 and allows media compatibility between the Atari and the PC with no need for disk images (so you can ferry content back and forth on SD cards).

 

Flashing has also become rather convenient these days (it couldn't be much easier, in fact), and given the fact SDX is usually updated once a year, it's not a massive burden to apply updates to a couple of flash-based devices every time a new version comes out (assuming there is even a pressing reason to update at all).

57 minutes ago, ivop said:

Would it be possible to create a custom cartridge version where CAR: is empty and everything resides on Dx: ?

To some extent, but if you think about how SDX loads drivers fundamental to serial input/output, etc: it needs to load drivers from the CAR: storage device (whose driver is built into the kernel, so the CAR: device and filesystem can be accessed before any drivers are loaded) before it can perform IO and understand the SDFS file system. So there would be little point in attempting to load - say - the SDFS filesystem driver from a SDFS-formatted floppy disk.

 

Edited September 15, 2022 by flashjazzcat

[ivop]

12 minutes ago, flashjazzcat said:

To some extent, but if you think about how SDX loads drivers fundamental to serial input/output, etc: it needs to load drivers from the CAR: storage device (whose driver is built into the kernel, so the CAR: device and filesystem can be accessed before any drivers are loaded) before it can perform IO and understand the SDFS file system. So there would be little point in attempting to load - say - the SDFS filesystem driver from a SDFS-formatted floppy disk.

Thanks for explaining. That sounds logical. So basically one would need a kernel that has SDFS builtin instead of CAR:. Boot that from D1: with the Atari OS boot sector mechanism. After that, it should be able to load drivers from disk, right? Perhaps the developers could be persuaded to assemble such a kernel.

Edited September 15, 2022 by ivop

[pixelmischief]

13 minutes ago, flashjazzcat said:

You can't please everyone, it seems.

Pleased?  I am freaking OVER THE MOON about the stuff you guys have done with the system and I am a buyer/user of nearly everything that gets released.  I only mean to aspire to that tiny bit of real estate between astonishing and perfect. 😃

[pixelmischief]

17 minutes ago, flashjazzcat said:

having a large linear address space in RAM (which the Atari doesn't) also helped greatly.

At the risk of inviting a stern reminder that I don't know wtf I am talking about...could hardware on the PBI be combined with a link library that allows software to be retargetable and work against a virtual memory space?  I know.  I don't know wtf I am talking about.

[flashjazzcat]

1 minute ago, ivop said:

So basically one would need a kernel that has SDFS builtin instead of CAR:.

Or just have the essential drivers (filesystem driver for boot volumes, low-level IO drivers, etc) on the CAR: device, and everything else on disk. That would be your lowest ROM footprint setup at the moment, and would require no changes to the kernel.

 

The CAR: driver is relatively simple (and I believe in line for changes to overcome 8K file size limits), so the kernel remains lean without having complex drivers bundled into the code. Old versions of Sparta of course had the base filesystem drivers built into DOS, but SDX is highly modular (and more elegant as a result).

1 minute ago, pixelmischief said:

I only mean to aspire to that tiny bit of real estate between astonishing and perfect.

Problem is, perfect is unattainable. There's always a 'tiny bit of real estate' between what exists and the ideal.

 

It's interesting, and I remarked on this to someone the other day. Twenty or thirty years ago, we were typing in cylinder, head and sector numbers in order to partition hard disks and having to delve inside the machine or flip switches on the back of the case every time we wanted to run a different OS. Now the patterns of usage and levels of convenience we became accustomed to on PCs many hundreds or thousdands of times more powerful than the A8 are proliferating on the 8-bit, and I was asked the other day why the SIDE3 loader's context menu shows 'Open' as the RETURN key action for a disk image, when the user would have preferred it to say 'mount' or 'mount and reboot'. First world problems, man.

3 minutes ago, pixelmischief said:

could hardware on the PBI be combined with a link library that allows software to be retargetable and work against a virtual memory space?

Sounds like an enromous amount of work for barely any tangible gain other than bringing that ideal of perfection closer for a single user. The trouble with virtual memory space on the Atari is that it enforces an extra level of abstraction (which is the exact reason my word processor doesn't implement a virtual memory space in order to edit files larger than 16K; it would be slow).

[pixelmischief]

20 minutes ago, flashjazzcat said:

Sounds like an enromous amount of work

Hey man, if you're not up to it...MUAHAHAHA!

 

EDIT:  Scratch that.  I bet you're doing 100 things that most people will appreciate more.  GOS is high on my list of dream releases.

Edited September 15, 2022 by pixelmischief

[gozar]

@pixelmischief Have you looked at SD 3.2 or RealDOS? 

[Beeblebrox]

36 minutes ago, pixelmischief said:

Hey man, if you're not up to it...MUAHAHAHA!

 

EDIT:  Scratch that.  I bet you're doing 100 things that most people will appreciate more.  GOS is high on my list of dream releases.

.... And then some!!

[pixelmischief]

8 minutes ago, gozar said:

Have you looked at SD 3.2 or RealDOS?

Yeah.  I'm using SpartaDOS 3.2g right now.  I - here it comes - assume that support for modern mass storage is simply not a thing for that version of the OS.  I can write it to, and boot from, my MIO with it.  But due to my previous assumption, I haven't tried it with IDEPlus 2.0, SIDE2, MyIDE II, or any of the other mass storage things I have for the system.

[pixelmischief]

12 minutes ago, Beeblebrox said:

.... And then some!!

I've seen the insanely entitled vitriol that devs suffer when they talk about what they're doing and then run into delays.  That said...please, do tell...

Edited September 15, 2022 by pixelmischief

[flashjazzcat]

4 minutes ago, pixelmischief said:

I - here it comes - assume that support for modern mass storage is simply not a thing for that version of the OS.

3.2g should work fine with every APT-supporting adapter (Incognito, SIDE/U1MB, IDE Plus, etc), as does BW-DOS (and RealDOS should, since it's Sparta 3.2 in different clothes). The only limitation compared to SDX is that 3.2 can't access 512 byte sectors (only 256-byters), but then again, I'm not sure MIO has 512-byte sector support yet (perhaps Warerat added this; unsure).

Edited September 15, 2022 by flashjazzcat

[Paul Westphal]

21 hours ago, pixelmischief said:

Uhhh...ok.  Was that supposed to be an answer to the question?

I thought for sure I had downloaded an .atr of it from Atarionline, so I just dropped the link ... apologies.

[Gunstar]

6 hours ago, pixelmischief said:

Yeah.  I'm using SpartaDOS 3.2g right now.  I - here it comes - assume that support for modern mass storage is simply not a thing for that version of the OS.  I can write it to, and boot from, my MIO with it.  But due to my previous assumption, I haven't tried it with IDEPlus 2.0, SIDE2, MyIDE II, or any of the other mass storage things I have for the system.

FJC answered this above, but I just wanted to tell you that I have been using a MyIDE cart piggy-backed my Super SDX cart (from dropcheck-there's a switch to shut off SDX on it's cart and I have a floppy D1: bootdisk of 3.2g and FJC's driver to get the ball rolling) for a number of years, and thanks to FJC's APT firmware. I have a partition on my MyIDE II CF card for SpartaDOS 3.2g and ATOS desktop GUI system (only works with SD 3.2) for when I want to use it instead of SDX command line partition.

 

Of course my unorthodox setup (compared to U1MB/Side & Incognito) requires a D1: bootdisk even for SDX, if I want to use any of my other OS's (32-in-1, Syscheck) besides MyBIOS built into the MyIDE cart.

 

I am about to set up another partition to use with Diamond GOS 3 I now have on piggy-back cart too. I don't know if I'll be able to use SDX with Diamond 3 or if I'll have to set up SD 3.2g for using it as well. I do know the Diamond manual says it's compatible with SDX, but the newer versions in the 30+ years since may have broken that compatibility. But I think I recall seeing it listed in the compatible hardware of the newer (as of 4.8 for me currently, I still need to update to 4.9) SDX PDF manual.

 

But I totally don't mind writing files and .ATR's to a CF card or SD card on my PC and then loading them from the same card on my Atari. That's no different to me than making a disk copy on one Atari that will be used on another, or whatever. And with Fujinet and MyIDE II I've been able to get rid of the umbilical cord  of the SIO2PC, even with the advantage of Remote Control OS for it on the 32-in-1 OS upgrade while using A.P.E software (all Atarimax products). SIO2PC was finally completely obsoleted for me personally, though, with Fujinet. No PC needed. Even to download new Atari software since now I only wait until someone has uploaded it to their TNFS host site.

Edited September 16, 2022 by Gunstar

[+bf2k+]

7 hours ago, pixelmischief said:

But due to my previous assumption, I haven't tried it with IDEPlus 2.0, SIDE2, MyIDE II, or any of the other mass storage things I have for the system.

You know what they say about assumptions...

 

I used SD 3 most of the time in the past... still do.

 

I have been using SD 3.2 with most of the options you list above for years... maybe not SIDE 2 because why would I? (but I bet I still have) because my most-used ATRs boot to SD 3.x.  I've used it with IDE2PLus Rev C a whole lot... I'm guessing about 10 years as well as the new IDE2PLus Rev H I just got earlier this year.  It works great with Rev H.  I used it with the MIOs, MyIDE (2), SIO2PC, SDrive Max, SDrive Nuxx etc.

[+SoulBuster]

I have been using RealDOS in place of SDX when needed.  I even wrote an email like the site said to ask permission to use it, still waiting for an answer (over a year).

 

It can do everything SDX can do.  I do not recall if it was limited to 256 byte sectors or not, but an MIO can only use 256 bytes sectors anyway.  BITD, only the BB used 512 byte sectors.

[+bf2k+]

RealDOS is limited to 256byte sectors.

[ivop]

deleted

Edited September 16, 2022 by ivop