Jump to content
IGNORED

Sparta DOS 4.47


w1k

Recommended Posts

Anyone on emulators:

 

there is some weird interference between the regular RAM extension and Axlon RAM extension under Altirra 2.50-release (and test-38). This may result in odd problems like longer files being currupted during copying. So if you have the emulator configured so that the regular 130XE-like extension is used (especially 576k and 1088k), please keep Axlon off and vice versa.

 

@fujidude: if you use Altirra, I think you can use it to create new ATR images as well.

 

Of course, if you succeed in writing a version of unpack.bat, which could recursively scan the subdirs, you are welcome. And we will be glad to put it onto the next version of the Toolkit disk.

Edited by drac030
  • Like 1
Link to comment
Share on other sites

Anyone on emulators:

 

there is some weird interference between the regular RAM extension and Axlon RAM extension under Altirra 2.50-release (and test-38). This may result in odd problems like longer files being currupted during copying. So if you have the emulator configured so that the regular 130XE-like extension is used (especially 576k and 1088k), please keep Axlon off and vice versa.

 

@fujidude: if you use Altirra, I think you can use it to create new ATR images as well.

 

Of course, if you succeed in writing a version of unpack.bat, which could recursively scan the subdirs, you are welcome. And we will be glad to put it onto the next version of the Toolkit disk.

 

Yes Altirra can create images. There are lots of tools that can. I will experiment a bit and see what I can learn. As to the script, that will be longer to do than getting the image correct. I'm not even sure the script is something I can make happen, but I hope to.

Link to comment
Share on other sites

I think Konrad suggested Altirra as the most opportune tool since you mentioned you were using that emulator while attempting to build the ATR anyway.

 

Yes I did gather that meaning from him. Perhaps it was my meaning which was more unclear. I wanted to try and figure out at what point the image was not quite right. It may not be the fault of the image file maker... it could have come later using the format command or something, or using that in a way that resulted in less than perfect results. I was stating I wanted to experiment to try and learn what works and what doesn't.

 

Trying Altirra as the image file maker is most certainly good advice, and is definately one of the things I will try (among others).

Link to comment
Share on other sites

there is some weird interference between the regular RAM extension and Axlon RAM extension under Altirra 2.50-release (and test-38). This may result in odd problems like longer files being currupted during copying. So if you have the emulator configured so that the regular 130XE-like extension is used (especially 576k and 1088k), please keep Axlon off and vice versa.

 

I'll try to reproduce this. Note that Altirra currently emulates the original Axlon behavior of triggering on writes to $0FF0-0FFF, so that may be a factor here.

 

For those just using the toolkit disk in Altirra, though, there's no need to extract the disk inside the emulation. Explore the toolkit disk, drag out the .ARC files, and remount them as disk images. The emulator will create virtual SDFS disks with the contents of the ARC files.

  • Like 2
Link to comment
Share on other sites

For those just using the toolkit disk in Altirra, though, there's no need to extract the disk inside the emulation. Explore the toolkit disk, drag out the .ARC files, and remount them as disk images. The emulator will create virtual SDFS disks with the contents of the ARC files.

 

Very nice! Great to learn that. Still though, it can be most convenient sometimes to just browse everything via a single Sparta Commander session and not have to fuss any more than that.

Link to comment
Share on other sites

I wanted to try and figure out at what point the image was not quite right. It may not be the fault of the image file maker... it could have come later using the format command or something, or using that in a way that resulted in less than perfect results.

The ATR header is not quite right, so I guess that is the fault of the ATR file maker you used. The header says that the size of the image is 425984 bytes (= 26624 = $6800 paragraphs), while in reality it is 1474560 bytes (= 92160 = $016800 paragraphs). It seems that the image file maker is not able to create bigger images than 65535 paragraphs, i.e. 1048560 bytes.

 

Another problem is that sectors 1-3 in that image are full size instead of being 128 bytes each. But that is (or: should be) a minor problem.

 

Note that Altirra currently emulates the original Axlon behavior of triggering on writes to $0FF0-0FFF, so that may be a factor here

I see. That explains much. I thought that on XL/XE hardware only the Simius' version of Axlon RAM was emulated (i.e. the controlling register, write-only, but fully decoded and only present at $CFFF, and only active if PB0=1). That is what SDX 4.47 assumes, when XL/XE hardware is detected.

 

If the registers are not fully decoded, the Axlon RAM should only be enabled with 800 hardware type.

Edited by drac030
Link to comment
Share on other sites

Rather than a batch file which is miraculously able to recurse when it encounters a folder in the current directory, how about a very short SDX COM file which traverses the entire directory tree and executes its first argument for every file found, passing the current filename as an argument to the called program in the specified position:

 

TREECALL ARC X $NAME *.*

 

Such a program could probably be written in twenty lines of assembler with recourse to the newly translated Programming Guide, which everyone is hopefully busy reading at the moment.

 

On the other hand, even when setting up a brand new SDX hard disk partition, I have never felt the need to extract every ARC file on the toolkit disk en masse. Rather, what one tends to do is selectively unarc only the tools and drivers of interest into the proper place in the directory structure. Because of this (and bolstered by Altirra's ability to mount ARC files, for those using emulation), distributing the tools ARCed seems like a practical measure.

Link to comment
Share on other sites

Rather than a batch file which is miraculously able to recurse when it encounters a folder in the current directory, how about a very short SDX COM file which traverses the entire directory tree and executes its first argument for every file found, passing the current filename as an argument to the called program in the specified position:

 

TREECALL ARC X $NAME *.*

 

 

 

This is a VERY good idea, and actually having a general purpose treescanner you call with a directory mask, file mask and a function is extremely handy. At work, I usually write one for every major system I code on. It iterates across the current directory...if a file matches the file mask the function gets called with it as an argument, if the directory matches the directory mask it gets CD'd into. When an entire directory has been scanned it pops back up 1 dir and continues. It's done when it completes the directory you ran it against to start with.

Edited by danwinslow
Link to comment
Share on other sites

Explore the toolkit disk, drag out the .ARC files, and remount them as disk images. The emulator will create virtual SDFS disks with the contents of the ARC files.

Just been trying this excellent feature and was pleasantly surprised to stumble on the right-click file viewer now present in the disk manager. So you can now read the TXT files in the ARCs without using the emulated machine at all. Superb.

Link to comment
Share on other sites

Attached is the updated expanded edition of the SDX 4.47 Toolkit disk, for those who do like that method. Note the image is a 720KB one (yes, minus the 384 bytes lost in the 1st 3 sectors). Because it still all fit on a 720KB even expanded, I went with that. No need to be wasteful.

 

Everyone, I think part of the issue might have been me as I used the SDX format utility and might have screwed with the settings the wrong way. The other thing though, is it seems the ATR creator in that old program did not remember to force the 1st 3 sectors to 128 byte no matter if the rest is 256 bytes per sector or not. I have come to this conclusion by a lot of experimenting, researching .ATR format specs, and paying heed to some of the valuable insight brought forth right here.

 

In my research I found conflicting information on the structure of an .ATR, specifically the 16 byte header. The three sources I found and used were Nick Kennedy's (the creator of the format) web site, Steve Tucker's info at www.atarimax.com, and the archived pages of someone like jindroush, also on atarimax.com. I put all the info together into a comparsion chart. I was going to post that chart here, but found there is a more relevant topic already started here on AA. You can get to that right here.

 

I encourage all of us here, developers and users, that take an interest in the .ATR format to please take a look at what I post there and weigh in. I think the .ATR format is very important to the A8 world these days, and if we are going to have a "standard" it probably should actually be clear and unconflicted.

 

I want to say the idea of a machine language utility to recurse is welcome. It is not a project for my skillset though, so I may still muck about with trying to get it done in batch processing. It would be for my own edification as much as anything else.

SDX447TK.atr

Edited by fujidude
  • Like 2
Link to comment
Share on other sites

I want to say the idea of a machine language utility to recurse is welcome. It is not a project for my skillset though, so I may still muck about with trying to get it done in batch processing. It would be for my own edification as much as anything else.

 

Well, for people who'd rather not spend time fiddling around with large arc files on an Atari, there's IZArc for PC. Makes the whole task of unarcing the toolkit a breeze, then you can move files/utilities of interest to an ATR file or a PC Folder you can mount to either to AspeQt or another SIO/PBI device for use with your Atari. I am one of those people who prefer to get the toolkit archive in ZIP or RAR format, but we atarians like to torture ourselves more than anybody else, so it's unlikely that we will have that any time soon ;)

  • Like 1
Link to comment
Share on other sites

 

Well, for people who'd rather not spend time fiddling around with large arc files on an Atari, there's IZArc for PC. Makes the whole task of unarcing the toolkit a breeze, then you can move files/utilities of interest to an ATR file or a PC Folder you can mount to either to AspeQt or another SIO/PBI device for use with your Atari. I am one of those people who prefer to get the toolkit archive in ZIP or RAR format, but we atarians like to torture ourselves more than anybody else, so it's unlikely that we will have that any time soon ;)

 

I use 7Zip, and although it supposedly can handle .arc format, it oddly has trouble with Atari style .arc files. I have not yet tested it on .arc files from the "PC realm" to see if it also has trouble with those. PeaZip also has trouble. That's not surprizing as it is based of 7Zip. Universal Extractor handles them just fine though, so I'm good. I can use 7Z almost all the time, and I just break out UE for the toughies.

Link to comment
Share on other sites

  • 2 weeks later...

A 19KB binary is still taking a long time to load via a mirrored (AtariDOS format) PC folder using AspeQT with the library enabled. I remember there was some discussion a while ago regarding file seeks when the "X" command is not used (which - in the case of the ATARIDOS.SYS driver - provokes repeated reads from the beginning of the file). Was this ever looked into further (although I appreciate it's a slightly niche issue, since standard binaries are usually loaded with "X"; however, the utility in question requires the cart enabled)?

Edited by flashjazzcat
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...