Why is SpartaDOS X Cartridge Only?

[kenames99]

4 hours ago, SoulBuster said:

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.

hi,

  you don't need permission to use it, SJC just asks for an email to let him know you use, not a big deal. like sdx it is done for the fun and community support.

 

it can not do quite everything sdx can, but some/most. 256 byte sectors only for the time being. the new MIO/Rom can do 512 byte sectors. I have not tested that extensively but have played with it some.

 

Ken

 

[+Larry]

5 hours ago, SoulBuster said:

(snip...)

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.

That brings up an interesting question -- does anyone use SDX with a BB (taking advantage of the 512-byte sectors)? 

 

BITD, I used disk-based Sparta 3.2d with an MIO, but my drive kept getting corrupted, so I switched back to MyDos.  I have no idea why the drive kept getting corrupted, but it happened several times.  Shortly after, I got a BB (maybe '92?), so I never used 3.2g or 3.3x with the MIO. 

[kenames99]

SpartaDOS X32D had a bug which did corrupt the hard disk, that was a known by most problem. X33A.DOS and newer had that fixed.

[pixelmischief]

I have a  SpartaDOS 3.2X ATR floating around here.  Is that successor of some kind to 3.2G?

[flashjazzcat]

14 hours ago, kenames99 said:

it can not do quite everything sdx can, but some/most.

Since RealDOS is Sparta 3.2 in different clothes and with an arbitrarily different set of external tools, if RealDOS could do everything SDX can do, there would have been no need to create SDX since Sparta 3.2 would have already been sufficient.

 

[kenp]

On 9/14/2022 at 1:37 PM, Paul Westphal said:

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

Merci Beaucoup.  I've searched for a site with copies of different DOSes that can simply be downloaded like this.  I've run into bad sector reads trying to copy DOSes through the FujiNET and was never quite sure whether they had been retried or simply passed on into the image.  

[_The Doctor__]

On 9/16/2022 at 5:07 PM, pixelmischief said:

I have a  SpartaDOS 3.2X ATR floating around here.  Is that successor of some kind to 3.2G?

Probably the patched XF551 version.

[kenp]

On 9/16/2022 at 12:22 PM, kenames99 said:

SpartaDOS X32D had a bug which did corrupt the hard disk, that was a known by most problem. X33A.DOS and newer had that fixed.

SD 3.2d had a hard drive corrupting bug?  I wonder if that might react with the N: device handler.  I've only found one version of SpartaDOS with the N: handler and it was 3.2d and I've had trouble getting it to work.

Most of the old floppies I'm trying to recover were SpartaDOS formats so I've been kinda locked in for which DOS to use.

[kenames99]

the N: handler is not built in to any version of DOS be it spartados, realdos, SDX, etc. afaik it is a handler that is loaded at boot or when the driver com file is loaded.

 

Ken

 

[+bf2k+]

On 4/3/2023 at 12:09 PM, _The Doctor__ said:

Probably the patched XF551 version.

3.2x came on the Carina 2.7 disks I have here.  But I don't know how original they are...

[Ricky Spanish]

A 'lite' version of SDX on .atr would be awesome ! The time/date feature is my favorite part! I have that on SD 3.x atr but it does weird things sometimes.

So right now I'm using DOS 2.5 w/ matt~rats rom to ram.

[kenp]

19 hours ago, kenames99 said:

the N: handler is not built in to any version of DOS be it spartados, realdos, SDX, etc. afaik it is a handler that is loaded at boot or when the driver com file is loaded.

 

Ken

 

Irata has a set of DOS .ATRs where the N: handler has been preinstalled, as it were.  The SpartaDOS version, 3.2d, includes the F and N commands.  They've been really finicky when I've tried to write to a space on a local TNFS server.  Mine is an Ubuntu 20.04 Linux system running on a Ryzen 7 5700G processor with 64G of memory, enough HDD space to digitize a battleship and running a server called tnfsd.linux64.

I did get a COPY command to work once writing a file to the server but it was never repeated.  I'm going back to basics with the FujiNET and just working with an SD card on my end for now and restricting the amount of time each day so I don't get tired and lost in too many mistakes in one session.

I'm still finding my way around as if I'd never owned an Atari before.  Combining how long I've been away from the machine with so many changes and updates that it's like working in a totally new environment.  Nothing like the old days when my ATR8000 was about the height of the Atari accessories.  (That's what I'm still using to talk to my disk drives.  One still worked from the old days and I found a spare.)

[hueyjones70]

My SpartaDOS X cart has stopped working. Where can I get another one?

[_The Doctor__]

You can use any number of cartridge emulators these days. SIDE 2 SIDE 3 AVG SubAVG Ultimate. The AVG's allow stacking images internally quite nicely as well.

 

[Faicuai]

On 9/14/2022 at 4:10 PM, pixelmischief said:

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

SDX in its current multi-bank cart, and ROM-disk organization, is a close proxy of what a DMA-like operation in the $A000-$BFFF address space looks like (in 8K boundaries), and the I/O speed and efficiency gained (in spite of A8's limited base ram) are unmatched (even faster than reading a CF/SD from SIDE2, Incognito, etc.).

 

Let's not even talk about almost-instant boot-time.

 

As far as I can see, SDX in its current state of development is HEAVY for the A8, and every bit of speed and efficiency is more than welcome.

 

 

[flashjazzcat]

11 hours ago, Faicuai said:

and the I/O speed and efficiency gained (in spite of A8's limited base ram) are unmatched (even faster than reading a CF/SD from SIDE2, Incognito, etc.).

Specific example? If you mean loading an executable from CAR:, this is essentually a block copy operation, so I would be surprised if this was faster or even as fast as repeatedly reading from a data register and storing the values in memory.

 

ANTIC DMA runs at 500-600KB/s, and SIDE3 DMA at 1.7MB/s, so what is 'DMA-like' about SDX?

[Faicuai]

4 hours ago, flashjazzcat said:

Specific example?

Example? Basically EVERYTHING.

 

To have access to any specific consecutive block of 8KB on SDX, all the A8 host has to do is write required bank# in cart-control register ONCE and (almost instantly), the cart will bank-switch and expose the new bank in the $A000-$BFFF address space at bus-speed / timing. ALL of the 8KB at once, no further intervention from CPU, etc. The cart (while active on-bus) owns that window and "places" data directly in there. With this in mind, anyone can calculare the speed at which those 8KB are made available to the CPU.

 

Side-2 / Incognito (as I mentioned them), can fetch data via PBI code at a MAXIMUM of 105 KB/sec (if setting Antic DMA=OFF and letting 6502 work at full steam). Raw-transfers through SDX are about 96 KB/sec, and with storage-handling overhead, effective reads are about 87-89 KB/sec, again with Antic DMA=OFF. And as far as I recall, each and every byte has to be fetched by the CPU, and then placed (stored) somewhere else in ram, for after-IO execution.

 

You mentioned SIDE/3 (which I did not), but it is not difficult to see why accessing 8KB chunks worth of SDX rom-disk data would be faster than accessing that same 8KB block from SIDE2 / Incognito and then storing them in RAM before final execution. Not needed with SDX rom-disk, though.

 

That/s why I referred to SDX as the closest proxy of a storage-driven DMA-operation we could get on the $A000-$BFFF window. And all of this BEFORE the invention of SIDE, Incognito, etc. and wide-spread availability of cheap, abundant RAM and high-speed HD storage for A8.

Edited June 24, 2023 by Faicuai
Completeness, clarity...

[flashjazzcat]

18 minutes ago, Faicuai said:

To have access to any specific consecutive block of 8KB on SDX, all the A8 host has to do is write required bank# in cart-control register ONCE and (almost instantly), the cart will bank-switch and expose the new bank in the $A000-$BFFF address space at bus-speed / timing. ALL of the 8KB at once, no further intervention from CPU, etc. The cart (while active on-bus) owns that window and "places" data directly in there. With this in mind, anyone can calculare the speed at which those 8KB are made available to the CPU.

Yes, but the CPU still has to access it in order to do anything with it. I'm asking you what in particular about SDX's cartridge banking scheme is 'faster than reading a CF/SD from SIDE2, Incognito, etc'.

 

I mentioned SIDE3 because you brought up the subject of DMA, which SIDE3 happens to use in order to read large quantities of data off the SD card, and it does so at 1.7MB/s (per cluster, notwithstanding FAT chain overheads). SIDE3 aside, I think you'll find that a loop containing an absolute un-indexed read from a single register followed by an indexed store (i.e. a CPU-driven read from the mass storage device) is faster than an indexed read followed an indexed store (copying data from ROM to RAM or RAM to RAM).

 

There is, with SDX, the additional consideration of whether driver code occupies the same address space as the destination buffer (often the case with RAM-disks, necessitating copious amounts of bank-switching as the data is copied, although not an issue if the CAR driver happens to be wholly outside of the extended RAM access window, as is the source data).

 

In any case - as said - I very much doubt that the sustained transfer speed from the CAR volume or PORTB RAMdisk matches or exceeds that of a SIDE or Incognito HDD, for the reasons described above.

Edited June 24, 2023 by flashjazzcat

[Faicuai]

1 hour ago, flashjazzcat said:

Yes, but the CPU still has to access it in order to do anything with it.

Ok, Jon, let's put everything to the test here, and run the math (feel free to bring Konrad here, if you wish):

 

Consider the following simple SDX command (which I frequently use ALL the time because I hardly remember anything):

 

"MAN COPY'

 

Assume we have 192KB image flashed on Incognito or Ultimate-1MB loads (192K) flashed on ROM. (NOTE: for the sake of the exercise, let's assume a generally random data-access pattern in which some of it MAY or MAY NOT involve accessing longer consecutive blocks of data).

 

Tell me how that I/O cycle looks like, where data is located and what the CPU needs to do or go to access it.

 

Then, let's consider the complete I/O cycle chain, but assuming that all involved code and data are out on CF card. If you want to assume an APT partition, ok then.

 

😀

Edited June 24, 2023 by Faicuai

[flashjazzcat]

It will be rather difficult to measure the sustained burst read rate from a ROM drive which cannot host a file of more than 8K in size, but if you want to waste time trying to prove that code something like this:

 

Loop
	lda (source),y
	sta (dest),y
	iny
	bne Loop

 

executes using fewer machine cycles than this:

 

Loop
	lda DATA_REG
	sta (dest),y
	iny
	bne Loop

 

...please go ahead. The first code snippet (if run from RAM) could alternatively be self-modifying and use abs,y or abs,x addressing, but this is still canonically slower than an unindexed absolute read. I assume by 'code' you mean drivers, but since they are either loaded from CAR (SIDE2.SYS), copied from ROM to RAM (the SDX CAR kernel driver), or hosted on a bank-switched ROM (the U1MB/Incognito PBI BIOS), this seems to me unlikely to affect the result to any noticeable degree.

Edited June 24, 2023 by flashjazzcat

[Faicuai]

53 minutes ago, flashjazzcat said:

but if you want to waste time trying to prove that code something like this:

It would definitely be a waste of time if we don't consider the entire I/O chain or cycle involved here (in other words, the actual application or use).

 

The manual for "COPY' command is a 4K file that most likely fits and is aligned in a 8KB boundary, and needs not to be copied anywhere else to be accessed, other than exposed in $A000-$BFFF. 

 

Assuming SDX is not moving around that man-file before displaying it, you just can't beat the resulting (media) access speed, there.

Edited June 24, 2023 by Faicuai

[flashjazzcat]

Yes, it accesses entries in the CAR: device's directory very quickly, as one might expect. I assume what you're marvelling at is the fact banked cartridges can instantaneously present large amounts of code and data in the same address space, which of course yes: they can.

 

[Faicuai]

8 minutes ago, flashjazzcat said:

I assume what you're marvelling at is the fact banked cartridges can instantaneously present large amounts of code and data in the same address space

Well, it is not "marvelling at", but rather trying to illustrate what I meant by the closest DMA-operation proxy we can think of with SDX (still pretty basic, though).

 

However, and in all fairness (to your point) there is a BIG potential downside there: even if random media-access time (in 8KB blocks) maybe unbeatable with SDX rom, it could all be washed out by the computational requirements when decoding the implied organization and structure of data on that very same address.

 

In other words, I CANNOT perform a straight "TYPE CAR:COPY.MAN" or a simple "COPY CAR:COPY.MAN D:" like I could 'TYPE \SDXTOOLK\COPY.MAN" from HD storage, for instance (there is another way around involving TYPE and redirection). That suggests there is additional overhead when going after plain data stored in SDX rom.

 

It is all a balance between [available RAM + storage capacity + RAW media access-speed + implied data-structure].

 

 

[flashjazzcat]

33 minutes ago, Faicuai said:

Well, it is not "marvelling at", but rather trying to illustrate what I meant by the closest DMA-operation proxy we can think of with SDX (still pretty basic, though).

Just to be clear: I'm not criticising anything about SDX or the decision to host it on a banked ROM and put the support files on a ROM-disk. I'm a staunch SDX advocate and I understand why it was designed the way it is. What may have gotten us off the beaten track here is the comparison between banked cartridges and hard disks, and a lack of clarity regarding whether we're talking about enlarging the address space (by presenting many 8K banks to the CPU in single address range), or 'reading' data into memory. I agree that it's impossible to read 8K of code or data into RAM from a HDD as quickly as one can change the contents of 8K of ROM address space by writing to a banking register, but if we're actually comparing the speed of a ROM or RAM disk with transfers to or from a hard disk, the hard disk is always faster for the canonical reasons I have outlined in previous posts.

 

On balance, certainly the HDD presents an additional overhead in terms of issuing a read command to the HDD controller, waiting for the controller to fetch the data, etc, and the CAR: driver (probably) has the distinct advantage of performing a string comparison on the directory in ROM (since the CAR: volume is not implemented as a block device, but in a proprietary manner). That advantage goes away, however, when reading the contents of the file once found, since the driver then transfers the file (or part thereof at a time) from ROM to RAM, via a CPU-driven copy operation, necessarily using indexed addressing for both the load and store operation (as per my prior posts).

33 minutes ago, Faicuai said:

In other words, I CANNOT perform a straight "TYPE CAR:COPY.MAN" or a simple "COPY CAR:COPY.MAN D:" like I could 'TYPE \SDXTOOLK\COPY.MAN" from HD storage, for instance (there is another way around involving TYPE and redirection). That suggests there is additional overhead when going after plain data stored in SDX rom.

The reason for this is described in the SDX manual: it's the fact the CAR driver only has one channel, and the COPY command requires two or three (one for the directory, and another for the destination file, for example, as well as one for the source file). Were CAR: implemented as a block-IO device at the LSIO level (i.e. with 8K banks sub-divided into 256 or 512-byte clusters) and the driver supported multiple simultaneous file handles, the inability to use 'COPY' and the 8K file size limit would go away. But along with it would go the (assumed) access speed advantage when seeking files in the root directory, since the driver would then almost certainly copy clusters from ROM to a buffer in RAM before performing string comparisons on the directory entries.

33 minutes ago, Faicuai said:

It is all a balance between [available RAM + storage capacity + RAW media access-speed + implied data-structure].

Certainly, although as I understand it, the parts of SDX which would be especially difficult to implement without a banked ROM are the library and symbol table, which represent a rather large amount of code and data which would otherwise have to live in RAM (and probably mandate the presence of extended memory). We could get an half-hearted impression of how SDX would run from a hard disk, however, by placing all the files normally in the CAR: volume onto a HDD partition and directing the system PATH variable there. I doubt one would notice any difference in terms of performance when displaying MAN files, copying files, loading the command processor, etc, nor when installing any but the core filesystem and SIO driver from a HDD instead of the CAR volume.

Edited June 24, 2023 by flashjazzcat

[drac030]

Just as some form of side notes to the discussion:

 

1) CAR: since SDX 4.49f has not been limited to 8k (8176 bytes to be exact) per file anymore. We were repeatedly receiving complaints about that, so now it is finally 7*8176 = 57232 bytes per file. I can see in the changelog that it was done in May 2021 - more than two years ago.

2) This per se means that a file residing on CAR: is not necessarily contained in one cartridge bank anymore.

3) The files on CAR: are not (and have never been) executed in-place. They are copied to RAM. The system sees them as normal file streams, thus a "read" means copying data from the media (cartridge banks) to the operating memory (per usual rules).

4) The limit of files open simultaneously on CAR: has nothing to do with the internal organization of the media. This limitation just saves memory. An open file requires a descriptor, which in case of the CAR: device takes up 23 bytes of the main RAM. If CAR: handled more files open simultaneously, it would probably be files_open*23+23, plus a lot more complicated handler code. There is no point to do that, if the only operation, which cannot be done because of that, is COPY.

5) MAN files stored on the CAR: are probably compressed, this is why one cannot display them directly. MAN COPY opens the COPY.MAN file and, when it detects that it was compressed, it hands it to ARC, which uncompresses it to a temporary directory ($TEMP$ - by default it points to the ramdisk). When done, it hands the uncompressed file to the program defined as $PAGER$.

 

Edited June 24, 2023 by drac030