SpartaDOS X 4.48

[+Nezgar]

Just upgraded my SIDE2 from SDX 4.48 to 4.49c beta. The 4.48 image I last used was missing FDISK, so I've just lived without it for a while Now that I had FDISK again, I deleted the last of 4 partitions I had assigned to D5, D6, D7, D8, and renamed the first partition in FDisk (D5) and set it as a boot drive.

 

First, it seems this fubar'd D6 and D7, as now SDX reports them as unknown file system. I didn't modify the sizes of the partitions, but I did change the name of the first. Is that enough to throw off the successive partitions? I should have backed up first, but didn't lose anything irreplaceable... D6 doesn't have metadata for a name, but D7 does. Not sure how I missed that originally. Probably unrelated, but I noticed my original CF has metadata default OFF, whereas a new CF has metadata default ON.

 

Secondly, now that I could set D5: as the boot drive, I was hoping it would pick up a custom CONFIG.SYS placed on that drive, but it does not seem to see it. It will only process a CONFIG.SYS if it is on D1:. The AUTOEXEC.BAT on D5: does get processed as expected however, so my workaround is to load some DEVICE drivers via AUTOEXEC.BAT instead of CONFIG.SYS. (ie INDUS.SYS, RAMDISK.SYS). This is on a system with no U1MB, so no PBI BIOS for SIDE2.

 

Any thoughts about what I might have done that borked the 2nd/3rd partitions appreciated.

 

Thanks

[flashjazzcat]

This isn't really related to SDX, but certainly enabling and disabling metadata sectors on the fly is likely to cause issues. Best to set the global flag ON before partitioning the disk.

 

As for CONFIG.SYS: the reason it isn't picked up is that the operating system has no idea how to read the HDD until SDX loads the driver, and the driver is loaded when SDX processes CONFIG.SYS (from the CAR: device).

[Kyle22]

If you always going to use the same CONFIG.SYS, then edit the copy in CAR:

[+Nezgar]

Thanks fjc/kyle22.

 

I was scouring the config.sys section of the 4.48 manual last night, and have considered a custom car: fileset. That would indeed be a solution, plus let me put in some other tools I commonly use.

 

Speaking of the 4.48 manual, the default CONFIG.SYS is shown as still containing

DEVICE INDUS 4

DEVICE RTIME8

DEVICE JIFFY

DEVICE RAMDISK

 

All of these are not present in the default side2 build at least. I remember the reason being discussed why INDUS.SYS was not included. USE BANKED is specified in the side2 default CONFIG.SYS - manual says this is not specified on purpose as it will auto pick a setting depending on detected system.

 

Not critical, just a discrepancy in the documentation...

[+Nezgar]

In other news I'm happy to report I recovered my 2 'bad' partitions by re-applying the metadata flag on partition 2. I don't recall turning it off previously, but I'm happy!

[_The Doctor__]

@drac030

Please see this link

https://atariage.com/forums/topic/296202-spartados-x-and-fatfs-issues/#comments

it presents as a continuation of the issue in discussion we were having about 2 years back...

 

anyone else having similar issue might post it in this thread with steps taken to find out what is happening and/or emailing...

the above is an image to avoid spam, you will have to type it in by hand to get the message to the crew...

Edited October 4, 2019 by _The Doctor__

[Jeffrey Worley]

On 2/18/2019 at 10:46 PM, Nezgar said:

Thanks fjc/kyle22.

 

I was scouring the config.sys section of the 4.48 manual last night, and have considered a custom car: fileset. That would indeed be a solution, plus let me put in some other tools I commonly use.

 

Speaking of the 4.48 manual, the default CONFIG.SYS is shown as still containing

DEVICE INDUS 4

DEVICE RTIME8

DEVICE JIFFY

DEVICE RAMDISK

 

All of these are not present in the default side2 build at least. I remember the reason being discussed why INDUS.SYS was not included. USE BANKED is specified in the side2 default CONFIG.SYS - manual says this is not specified on purpose as it will auto pick a setting depending on detected system.

 

Not critical, just a discrepancy in the documentation...

How do I do that? -- Create a custom sdx cart?  I have a Side2 and all the gear and software I'm likely to need to do it, but I don't know how.  The Car: is a file structure, so I presume it could be written somehow.  Is there an editor out there that would enable me to burn my own config.sys, and include some files from the SDCSX I use on a regular basis?

 

Best,

 

Jeff

[Roydea6]

http://sdx.atari8.info/index.php?show=download&file=sdx_files/SDXImageUser.zip

[Jeffrey Worley]

While looking into how to build a custom cart image, I was reading the changes for release 448 and came across this, which might be germane to our topic, certainly seems likely:

 

* In case of accessing file systems larger than 32 MB (like these handled
  by FATFS) now the IDE+2.0/U1MB PBI XDCB protocol will be used instead of
  the old IDEa extended SIO addressing protocol. In either case this only
  applies to the PBI devices, serial drives are unaffected.

This change may explain our faults.  In every case I've tested with, I've used the SIDE2 cart for the source, where the Fat16 partitions are hosted.  I don't know how to do it otherwise, but now it occurs to me I should find out how to mount a Fat16 partition in AtariSIO/APE/Aspeqt/Respeqt to validate if the change to the XDBC protocol is our bug.  Anyone know how to do this?

 

Best,

 

Jeff

[+Nezgar]

1 hour ago, Technoid Mutant said:

How do I do that? -- Create a custom sdx cart?  I have a Side2 and all the gear and software I'm likely to need to do it, but I don't know how.  The Car: is a file structure, so I presume it could be written somehow.  Is there an editor out there that would enable me to burn my own config.sys, and include some files from the SDCSX I use on a regular basis?

There is a tool called SDX Imager here:

http://sdx.atari8.info/index.php?show=en_addons

 

I have not tried it yet myself, but I look forward to also doing exactly as you describe.

[_The Doctor__]

using the imager has been the best way to handle it. Sometimes in the course of moving around partitions you may want different outcomes, but normally you have a core group of configs you almost always want, putting that in the user area with your go to drivers (that aren't already in the cart image) is exactly what the tool is for.

[flashjazzcat]

On 2/19/2019 at 3:46 AM, Nezgar said:

USE BANKED is specified in the side2 default CONFIG.SYS - manual says this is not specified on purpose as it will auto pick a setting depending on detected system.

 

Not critical, just a discrepancy in the documentation...

I think the SDX manual is referring to stock images. The SIDE SDX ROM is rather peculiar in that it's next to useless with anything but 'USE BANKED' since SIDE.SYS will otherwise push MEMLO beyond usable levels. IIRC, SDX won't use extended RAM automatically on a 130XE unless told to do so, hence 'USE BANKED' is a sensible default, since it's the only usable configuration.

 

As for the SDX Imaging tool: I would think this is the only, let alone the best, method of adding user content to the CAR: device, unless one for some reason prefers to hand-edit the directory structure using a hex editor.  Of course there may be other tools the rest of us don't know about... I can't rule that out.

[Jeffrey Worley]

IIRC, from the documentation, which memory is 25 years old, the default is USE Banked|Osram|None

 

The logic will trip through if Banked is unavailable to Osram, which, if an 800 there is none, and so it will trip to using base memory.

 

Best,

 

Jeff

[flashjazzcat]

Indeed, but unless things changed, I think OSRAM is the default on a 130XE unless USE BANKED is specified. If this is the case, anything but USE BANKED would render the SIDE's SDX ROM unusable on a 128K machine, since OSRAM would be used and SIDE.SYS would wholly reside in main memory.

[Jeffrey Worley]

1 hour ago, flashjazzcat said:

I think the SDX manual is referring to stock images. The SIDE SDX ROM is rather peculiar in that it's next to useless with anything but 'USE BANKED' since SIDE.SYS will otherwise push MEMLO beyond usable levels. IIRC, SDX won't use extended RAM automatically on a 130XE unless told to do so, hence 'USE BANKED' is a sensible default, since it's the only usable configuration.

 

As for the SDX Imaging tool: I would think this is the only, let alone the best, method of adding user content to the CAR: device, unless one for some reason prefers to hand-edit the directory structure using a hex editor.  Of course there may be other tools the rest of us don't know about... I can't rule that out.

The Side2 DOES work on a stock 800.  I got five of them (800's), and, since SDX is the only version of Sparta that works on the 800 other than the original 1.1 version, I wanted to see.  You have to modify the cart case a little, file the sides a thickness of a business card on each side, but then it fits and the cart is usable.  Memlo is over $4000 IIRC, but it does work.  You also have to jimmy the cart slot hatch interlock as the cart is too tall to close it. One thing that is cool is that your code to read fat32 and fat16 partitions, the Side Loader program, runs flawlessly on the unmodified 800.

 

Best,

 

Jeff

Edited October 4, 2019 by Technoid Mutant

[flashjazzcat]

10 minutes ago, Technoid Mutant said:

Memlo is over $4000 IIRC, but it does work.

Yes: it technically works but it's impossible to run most applications with MEMLO this high. Hence I consider SDX totally unusable in this configuration. YMMV.

 

The loader is a different subject entirely. It's an 8K banked ROM and requires only 48K of RAM.

[Kyle22]

2 hours ago, flashjazzcat said:

. . . unless one for some reason prefers to hand-edit the directory structure using a hex editor.  Of course there may be other tools the rest of us don't know about... I can't rule that out.

That's how I put the prototype MYIDE.SYS in the cart. So nice to have this fine image tool, so much easier now.

:)

 

[+Nezgar]

8 hours ago, flashjazzcat said:

Indeed, but unless things changed, I think OSRAM is the default on a 130XE unless USE BANKED is specified. If this is the case, anything but USE BANKED would render the SIDE's SDX ROM unusable on a 128K machine, since OSRAM would be used and SIDE.SYS would wholly reside in main memory.

You are correct. I just made a CONFIG.SYS that has NO "USE" line, and it chooses OSRAM on a stock 130XE, leaving 4 extended banks free, and banked with a RAMBO or higher.

 

However, memlo with OSRAM is $253E.

With USE BANKED its $16E9.

With USE NONE its $3630 and the SIDE.SYS returned "Config error (179): DEVICE SIDE" so I guess thats where the "useless" part comes in, as without U1MB PBI, you have no access to the hard disks on the side.

 

Edit: I just read in the manual about the "SPARTA.SYS OSRAM" trick to use the 4KB of OSRAM from $C000-CFFF for buffers. With this in place, MEMLO is now $2087 with no ATARIDOS.SYS, but with ULTIME, SIDE, Ramdisk, td on, and quicked.

 

Edit2: and $1F3E with no RAMDisk on a Stock 130XE, since ramdisk.sys doesnt load since it will always leave 4 banks free by default.

[_The Doctor__]

you can try some creative arrangement...

 

USE OSRAM

DEVICE SPARTA USE BANKED                                     or shortened      DEVICE SPARTA BANKED

 

try some combinations....

USE OSRAM

DEVICE SPARTA USE OSRAM                                      or shortened      DEVICE SPARTA OSRAM

 

in this way you can choose where to put things...

you can shorten the DEVICE lines by dropping USE and just put BANKED or OSRAM

often it is forgotten that you can change both lines and this gives you different arrangement and outcome

 

*edit* I see you went back and did your homework... cool beans... I put a like on the post for that. :)

Edited October 5, 2019 by _The Doctor__

[tschak909]

If there is something I would ask, it would be that the high-speed SIO code in the U1MB be ported to SDX so that Pokey divisor 0 can be used.

 

-Thom

[drac030]

This is planned. Specifically, porting the IDE+ serial routines.

[tschak909]

@drac030 I could hug you. Thank you for continuing to work on SDX

[Kyle22]

On 2/18/2020 at 9:21 AM, drac030 said:

This is planned. Specifically, porting the IDE+ serial routines.

This is the Hias driver? Also, how about Indus SuperSynchromesh? Same protocol as XF-551, but faster. 72K Baud IIRC.

I did this before, but lost it. The Z-80 code sent to the Indus by GTSYNC needs to avoid a timing error lock up.

This DOES work. I don't remember anymore. It was timing before complete and the data frame, or something. I forget now.

It was only a few bytes change to the code.

 

 

[Jeffrey Worley]

ALL in SDX 4.49c

 

Bug report:

 

0) The FORMAT utility resets all parameters of the Percom block to defaults before adjusting to the desired density/heads/skew settings.  This is obnoxious because I want to set my drives' seek rate to 0 and do so via the MYDUP utility as there's not command-line utility I can find that will do this.  When I do, it is fine until I need to format a floppy, at which time, I have to re-enter MYDUP and do it all over again.  Leave the step rate parameter alone please!

 

Bug report:

 

1) The CLX utility does not understand floppy's too well.  Unless the FORMAT utility has been recently used, or the Percom control block has been adjusted some other way, the CLX utility will usually complain that a double-density disk SHOULD be reporting 128 bytes per sector and will prompt you to change this parameter, destroying your disk.

 

2) The CLX utility does not understand floppy's too well.  Unless the FORMAT utility has been recently used to produce a double-sided disk, the CLX program will insist that the number of sectors is wrong and prompt you to fix it, destroying your disk.

 

3) The CLX utility does not understand floppy's too well.  Unless you have recently formatted a disk in enhanced density, the CLX utility will report that the number of sectors is unlikely and prompt you to change it to 720 from 1030, destroying your disk.

 

CLX is really, really useful for hard disks, it 'gets' high-capacity drives well, but floppys not so well, and double-sided floppy's twice as badly.  It would not be so bad if it were not for the fact that it insists on 'fixing' your disk and it is easy to make the mistake of letting it, destroying your disk.

 

Double-sided floppy drives are always interesting with the Atari, as you need to tell the system that it is a double-sided medium or it will not see the second side, will see a directory and will barf when it gets to a call past sector 720.  This is normal, but fixable, I think, using some logic, checking if the disk is indeed double-sided is not too tough, but probably too tough to stick in rom.  Still, CLX could do a heck of a lot better than trashing your floppy data.  I've tested the enhanced density glitch with several 1050's, the double-sided glitch with a Percom AT88-SPD, a Percom AT88 with doubler board, and an XF551.  All display the same behavior.

 

Else, CLX is a wonderful utility and I trust it as much as I did Cleanup.  CLX has not steered me wrong with a hard drive either in 256 or 512 byte modes.  Thanks for developing and thanks for listening.

 

Best,

 

Jeff

[drac030]

@Kyle22 It is a "Hias-like" code. The SIO drivers are a bit complicated matter, anyways.

 

@Jeffrey Worley

 

0) True. The formatter reads the PERCOM block from the drive, but does not remember the step rate parameter. I think it is easily fixable, I found 1 free byte where it can be remembered, so if nothing else prevents the fix...

 

1) - 3) As you notice yourself, these are rather reports about the bugs in the firmware of respective drives, as the CLX behaves so because  s o m e  drives are notoriously lying in the PERCOM block returned about the geometry of the inserted floppy. Especially the XF551 looks as if the author of the firmware thought that the PERCOM data is some kind of ornament, therefore the drive notoriously returns false data.

 

Now CLX is a program to verify if the file system on the disk is correct. So this information is actually crucial if the program has to correctly reconstruct a damaged file system and especially the boot sector.

 

The only thing I think I could do it is to make CLX display the parameters it read from the PERCOM block and ask the user if these are correct. But what if the user does not know what is correct?

Edited April 5, 2020 by drac030