Jump to content
drac030

SpartaDOS X 4.48

Recommended Posts

I meant that a file can be as big as the size of the storage.

 

Again I am reaching back to distant memory, but I think the 8K limit comes from the size of a standard Atari cartridge... I think... Apologies again if I am recalling this incorrectly.

 

On a different topic; is there a compressed *.RAR/*.ZIP archive of the uncompressed contents from the SDX toolkit disk? Currently most of these drivers and utilities are stored on a *.ATR disk image and compressed using the ARC format. It can be very tedious to unearth the programme you need in this setting. As mentioned above - I frequently modify and add things to the SDX user space on the SIDE2 and U1MB, often from the toolkit and always spend longer actually getting to the utility I want than editing the SDX ROM itself.

  • Like 1

Share this post


Link to post
Share on other sites

 

Again I am reaching back to distant memory, but I think the 8K limit comes from the size of a standard Atari cartridge... I think... Apologies again if I am recalling this incorrectly.

 

On a different topic; is there a compressed *.RAR/*.ZIP archive of the uncompressed contents from the SDX toolkit disk? Currently most of these drivers and utilities are stored on a *.ATR disk image and compressed using the ARC format. It can be very tedious to unearth the programme you need in this setting. As mentioned above - I frequently modify and add things to the SDX user space on the SIDE2 and U1MB, often from the toolkit and always spend longer actually getting to the utility I want than editing the SDX ROM itself.

 

Since you can use UFLASH to modify that space, you can do this task all from within the Atari. The TK disk is published as an .ATR which contains several subdirectories and .ARC files buried within. I wrote a batch script which can unpack all of that automatically. See this posting for details. Since you are dealing with U1MB and or SIDE, I will assume you have plenty of space to unpack everything to, be it RAM disk, a compact flash card, or what have you. Once you get the batch script in your Atari and in a folder that's in your path you would do this:

  1. Make your current working drive and directory where you wish the root of where everything unpacks to.
  2. Enter this command: -RUNPACK A: (this assumes A is where the TK disk is)
  3. Go grab some coffee, come back, and enjoy relaxing while your Atari takes care of the tedium for you.
  • Like 3

Share this post


Link to post
Share on other sites

 

 

Since you can use UFLASH to modify that space, you can do this task all from within the Atari. The TK disk is published as an .ATR which contains several subdirectories and .ARC files buried within. I wrote a batch script which can unpack all of that automatically. See this posting for details. Since you are dealing with U1MB and or SIDE, I will assume you have plenty of space to unpack everything to, be it RAM disk, a compact flash card, or what have you. Once you get the batch script in your Atari and in a folder that's in your path you would do this:

  1. Make your current working drive and directory where you wish the root of where everything unpacks to.
  2. Enter this command: -RUNPACK A: (this assumes A is where the TK disk is)
  3. Go grab some coffee, come back, and enjoy relaxing while your Atari takes care of the tedium for you.

 

 

Very cool that you wrote a batch file for that fujidude!!! I was thinking along those lines myself, but am not yet proficient enough with SDX to writes scripts for it.

 

I have actually done just the same thing manually in the past for the SDX 4.47 toolkit within an Altirra session; copied the whole image's contents to a folder on an APT partition and then laboriously created sub-folders for each *.ARC in its proper hierarchy and then de-ARC'ed them one by one by hand... Groan... Not a fun Sunday afternoon!!!

 

Maybe it would be the best of both worlds if the SDX chaps created the toolkit disk as a maximum size 16MB *.ATR and then kept the same folder layout, but just didn't ARC-up the large files? I think most people who use SDX have at least one method at their disposal to mount a large *.ATR on their machine - and the smaller, toolkit disk image with compressed contents could still be distributed for those that don't.

  • Like 1

Share this post


Link to post
Share on other sites

 

Very cool that you wrote a batch file for that fujidude!!! I was thinking along those lines myself, but am not yet proficient enough with SDX to writes scripts for it.

 

I have actually done just the same thing manually in the past for the SDX 4.47 toolkit within an Altirra session; copied the whole image's contents to a folder on an APT partition and then laboriously created sub-folders for each *.ARC in its proper hierarchy and then de-ARC'ed them one by one by hand... Groan... Not a fun Sunday afternoon!!!

 

Maybe it would be the best of both worlds if the SDX chaps created the toolkit disk as a maximum size 16MB *.ATR and then kept the same folder layout, but just didn't ARC-up the large files? I think most people who use SDX have at least one method at their disposal to mount a large *.ATR on their machine - and the smaller, toolkit disk image with compressed contents could still be distributed for those that don't.

 

I'm glad yet another person is saved effort. The technique I used was laborious enough, but not as much as what you put yourself through! I would manually walk the directory but use the DLT provided batch script UNPACK.BAT in each directory that I went into.

 

As to the way they publish the TK currently, I have a few thoughts on that. Of course it's DLT's thoughts, goals, and priorities which will rightfully govern, but anyway here are some of my thoughts:

  • Publishing the TK on a "large" medium would rule out use by those who are unwilling/unable to involve modern computer, and who don't have the specialty hardware for their Atari to make it work either.
  • Their is a philosophy that tuning things to the least common denominator results in the most inclusiveness and opportunity for participation. I think there is merit to that, but is far from any kind of universal truth.
  • The TK is distributed on a 720K floppy image, so we're already past the true least common denominator of a SSSD (90KiB) disk anyway.
  • I would imagine that most of the people who can use 720K floppies on a real Atari, also have access to a large RAMdisk or possibly even a mass storage device. So, perhaps it may as well be published in an expanded form to begin with?
  • In support of leaving things as the status quo; there exists a script to make it easy to expand it by those with the means and desire to do so.

So I dunno what to think really. Either way it comes is no problem for me.

Edited by fujidude
  • Like 3

Share this post


Link to post
Share on other sites

Love the batch file!

 

I'm wondering if the TK should be decompress as to FJC's GUI when it is finished. I guess that can be fixed by config/auto.

or maybe an option to expand to 90k/?? floppies.

 

Fuji-Man

Share this post


Link to post
Share on other sites

I love that script as well. It is absolutely brillant.

 

And notice, that it probably would not get created, if the TK disk had not been distributed in this format[1].

 

Also, I would not stumble upon the broken GOSUB in SDX 4.47, if I had not decided to create the flashing ATRs under SpartaDOS X on my Atari, using a batch script as well.

 

At the same occasion I found out what functions are missing in the FORMAT.COM and in MKATR.COM.

 

So, these are IMHO excellent examples of how actually using the available utility software causes its improvements and further development.

 

--

[1] And the reason why the TK is distributed in this form is very simple: the TK image contents is put together on my Atari, it is actually a copy of what I keep on my HDD. The binaries come (mostly) from the CVS (a PC, unfortunately, but I fancy that one day at least part of the work could be brought back to the native platform), but e.g. the doc files and the archives themselves are mostly created on the Atari (the MAN files for the SDX commands and CAR: utilities are generated on a PC, Walter exports them from the manual which is so large that it certainly could not be edited on Atari; but the rest of the doc files on the TK is written using FJC's The Last Word). Only one ARC file in the SDX TK was packed on a PC and you would easily guess which one it is :)

Edited by drac030
  • Like 4

Share this post


Link to post
Share on other sites

I meant that a file can be as big as the size of the storage.

Yes, as you certainly guess from my response to morelenmir, we know that it is a problem, just have not yet got around to fix it.

 

The limitation has of course something to do with the size of one bank of the cartridge, but in reality the reason is just such that the CAR: device I/O driver is really very simple (and therefore, at the other hand, short and fast).

  • Like 2

Share this post


Link to post
Share on other sites

I love that script as well. It is absolutely brillant.

 

And notice, that it probably would not get created, if the TK disk had not been distributed in this format[1].

 

Also, I would not stumble upon the broken GOSUB in SDX 4.47, if I had not decided to create the flashing ATRs under SpartaDOS X on my Atari, using a batch script as well.

 

At the same occasion I found out what functions are missing in the FORMAT.COM and in MKATR.COM.

 

So, these are IMHO excellent examples of how actually using the available utility software causes its improvements and further development.

 

--

[1] And the reason why the TK is distributed in this form is very simple: the TK image contents is put together on my Atari, it is actually a copy of what I keep on my HDD. The binaries come (mostly) from the CVS (a PC, unfortunately, but I fancy that one day at least part of the work could be brought back to the native platform), but e.g. the doc files and the archives themselves are mostly created on the Atari (the MAN files for the SDX commands and CAR: utilities are generated on a PC, Walter exports them from the manual which is so large that it certainly could not be edited on Atari; but the rest of the doc files on the TK is written using FJC's The Last Word). Only one ARC file in the SDX TK was packed on a PC and you would easily guess which one it is :)

 

Sometimes I try to do all of a task on the real hardware just for... the nostalgia, the charm of it - I don't know really but it does feel very pleasing somehow if you can do everything on an Atari. I take my hat off to you drac030!!!

 

I wonder if it might be worth explicitly using the super-lean 'vbxe.sys' driver only when the SIDE2 is not attached - and then write the config.sys file I keep in the U1MB SDX user space to load that specific version from the cart. Whereas when the SIDE2 - and its harddrive - is attached the config.sys in the boot-drive root folder will take precedence and load the full version s_vbxe.sys' from there. Will the minimal driver support 80-col mode?

Share this post


Link to post
Share on other sites

I would say use the paired down version of the driver if you are running into memory resource problems.

 

Its not a resource problem so much as the paired down one will fit in the CAR: user space and the full one won't. However, if i'm reading the user guide right then I think in order to get 80-col I will need as a minimum the 'raw con' driver - which luckily does just fit inside 8k!

Share this post


Link to post
Share on other sites

Yes, as you certainly guess from my response to morelenmir, we know that it is a problem, just have not yet got around to fix it.

 

The limitation has of course something to do with the size of one bank of the cartridge, but in reality the reason is just such that the CAR: device I/O driver is really very simple (and therefore, at the other hand, short and fast).

Yes, I know. FJC already explained it to me. But that would be my wish (if I would have one for free ;-)), that I could put Last Word on a SDX cart, for example, not needing any additional drives. Or the full VBXE driver, that won't fit on CAR:

Share this post


Link to post
Share on other sites

That can happen and probably not much can be done about it apart from loading the ATARIDOS.SYS as the very last FS driver.

 

The DOS 2.0 (and clones') FS has almost no characteristic features, so that it only gets detected by the VTOC[0] containing a value greater than $01 and lesser than $23 or so.

 

So drivers for all other file systems, which can be more reliably determined, should be loaded first.

  • Like 2

Share this post


Link to post
Share on other sites

Maybe I'm missing something, but how would you even get a case where FAT16 and DOS 2.x could be confused? I thought FAT16 was only defined for 512b+ sectors and DOS 2.x / MyDOS for 128b/256b.

Share this post


Link to post
Share on other sites

That is due to the PBI drivers treating $0308/$0309 liberally. ATARIDOS.SYS sets 128 or 256 bytes per sector before requesting VTOC to be loaded, on a 512-bps disk the PBI driver should probably throw an error.

Share this post


Link to post
Share on other sites

Is there any particular error code the driver should throw (if DBYTLO/HI doesn't match the size of the requested sector) without the whole transfer crapping out before the appropriate file system driver gets its hands on the sector? I just tried implementing a sanity check (returning a NAK error for convenience on a mismatch), and SDX 4.48 doesn't try any file systems further up the table - it just aborts with the error (which is a reasonable reaction, since the implication is that the drive doesn't respond at all).

 

Loading FATFS.SYS before ATARIDOS.SYS is a perfectly reasonable workaround, though.

Edited by flashjazzcat

Share this post


Link to post
Share on other sites

Loading FATFS.SYS before ATARIDOS.SYS is a perfectly reasonable workaround, though.

Well, unless you only load FATFS.sys with an IDE device enabled, e.g. an inserted SIDE2 via autoexec.bat

Edited by JoSch

Share this post


Link to post
Share on other sites

Hmm, yes, the "error" does not solve the problem. I can of course try to add a check on the sector size to ATARIDOS.SYS and reject 512-bps disks, which probably will fix this particular issue.

 

But in general the problem remains, because in fact any 128- and 256-bps file system can still be mistaken for the DOS 2.0/MyDOS FS in less fortunate circumstances. This does not happen only because there are not many file systems / file system drivers in use.

Edited by drac030

Share this post


Link to post
Share on other sites

 

Thanks for the heads up. I appreciate you making the beta generally available like this. Unfortunately in my case, just as you first decided to do that I have had less time to tinker with Atari related things. I will be digging in and trying things out when I get a bit more time to do so though.

Share this post


Link to post
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.

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