Jump to content
drac030

SpartaDOS X 4.48

Recommended Posts

The binary files I was trying to use are on the CAR: portion of the SDX449 rom file. And hiding the OVL files fixed the problem.

Ah. The only build I typically use is the Maxflash8 one. FDISK hasn't been included in this build to date. I didn't know it existed in other builds.

 

However, I'm glad my suggestion worked. :P

 

-SteveS

Edited by a8isa1

Share this post


Link to post
Share on other sites

The screen clear after issuing any command (except TYPE) from the CLI has been cleared up in SDX 4.49c beta.

 

Thanks for the quick fix, Drac030!

 

-SteveS

  • Like 1

Share this post


Link to post
Share on other sites

"Quick" is a bit overstated. But we do what we can. :]

well, I generally have plenty of patience when it comes to hobby related projects.

  • Like 2

Share this post


Link to post
Share on other sites

Currently still stuck using 4.47 ... as 4.48 and 4.49 refuse to perform copy operations with drives of different format with files of any substantive size

 

NTSC 130XE stock MIO, drive swapped with ram disk on the mio.... atarimax sio2pcusb... copy from slot 2 (suprsparta flasher disk) to D1:(MIO ramdisk) ends with sdx449_1.rom 72%

 

139 Device NAK

 

NTSC 130XE memory upgraded (320k), black box, nothing swapped.... atarimax sio2pc rs232... copy slot 2 (suprsparta flasher disk) to D1:(Black Box Hd#1) ends with sdx449_1.rom some random percent

 

139 Device NAK

 

Dell with ape windows vista USB attached...

 

HP with ape windows XP rs232 attached....

 

Both work perfectly with 4.47 ..... I will get told it has been changed for a long time... but that is why I am stuck back there forever.... as is the case for a number of people I hang out with.... instead of saying this long time change.... how about this is the way to make it work...

You know, for the vast number of users who just want to enjoy things like it used to be... just sit down and enjoy how wonderful the Atari is and not wrestle with it for simple copy functions... I want to do disk operations not surgery... I am sure there are reasons for the changes.... I use REAL hardware... everything is probably just fine on a PAL setup or in Emulation... those are not for me.....

 

Having been using OSS products and SpartaDos as well as SpartaDos X as an early adopter since the 80's, I always knew what to expect and each time it almost always improved... I wish the trend to continue....

Share this post


Link to post
Share on other sites

Something for people who like to test new (beta) stuff.

 

As everyone knows, the SDX CAR: device contains a program called LESS.COM, which does what its name suggests (= mimics to an extent the behaviour of the Unix program called "less"). That program is commonly used (among those who read the documentation ;)) as the pager for the manual reader MAN.COM

 

The standard LESS.COM has one shortcoming, namely it only uses the main memory for the text buffer, so its use is limited to files not exceeding 32 KB very much.

 

So here is another program like this (a text file viewer, that is), which overcomes this limitation: it uses the ext RAM for the text buffer.

 

The other operation should be less or more as in the old LESS.COM, with one exception: the XLESS.COM cannot (for the time being) serve as a text converter. It does not understand PC text files either (you should convert them before, using a separate program, e.g. the AAC).

 

The new program can replace the old one as the MAN pager. To accomplish that, do this:

 

1) copy XLESS.COM to your HDD. Let us assume that you keep it as D3:>SDX>XLESS.COM.

 

2) add this line to your CONFIG.SYS: SET PAGER=C:>SDX>XLESS.COM;/C;

 

3) reboot (COLD from the CP)

 

The new viewer's operation differs slightly from the operation of the old one. Notably, it first does the "formatting" of the text loaded to the memory. Note that for very long files this operation may take considerable amount of time, for example, an 84k file will be getting formatted for about 7 seconds. And any longer files will occupy proportionally more time. So if you fed it with a 500k file, do not assume easily that it has hanged in the process :)

 

The program is rather fresh (the attached version compiled today, 4:31am), so please report any spotted misbehaviour.

xless.zip

Edited by drac030
  • Like 7

Share this post


Link to post
Share on other sites

Currently still stuck using 4.47 ... as 4.48 and 4.49 refuse to perform copy operations with drives of different format with files of any substantive size

 

NTSC 130XE stock MIO, drive swapped with ram disk on the mio.... atarimax sio2pcusb... copy from slot 2 (suprsparta flasher disk) to D1:(MIO ramdisk) ends with sdx449_1.rom 72%

 

139 Device NAK

 

NTSC 130XE memory upgraded (320k), black box, nothing swapped.... atarimax sio2pc rs232... copy slot 2 (suprsparta flasher disk) to D1:(Black Box Hd#1) ends with sdx449_1.rom some random percent

 

139 Device NAK

 

Dell with ape windows vista USB attached...

 

HP with ape windows XP rs232 attached....

 

Both work perfectly with 4.47 ..... I will get told it has been changed for a long time... but that is why I am stuck back there forever.... as is the case for a number of people I hang out with.... instead of saying this long time change.... how about this is the way to make it work...

You know, for the vast number of users who just want to enjoy things like it used to be... just sit down and enjoy how wonderful the Atari is and not wrestle with it for simple copy functions... I want to do disk operations not surgery... I am sure there are reasons for the changes.... I use REAL hardware... everything is probably just fine on a PAL setup or in Emulation... those are not for me.....

 

Having been using OSS products and SpartaDos as well as SpartaDos X as an early adopter since the 80's, I always knew what to expect and each time it almost always improved... I wish the trend to continue....

Sorry, I can see your post just now. Could you prepare a setup of ATR files so that the problem could be reproduced? The SIO routines in the SDX have not been changed for ages, by the way.

Share this post


Link to post
Share on other sites

Less is so has been. Most is where it's at. :) But seriously, thank you very much for this. I don't have time to play much on it right now but look forward to trying it later.

Share this post


Link to post
Share on other sites

Currently still stuck using 4.47 ... as 4.48 and 4.49 refuse to perform copy operations with drives of different format with files of any substantive size

 

(...)

 

INTERESTING! (and I thought I was the only one...)

 

This problem shows up quickly (on my side) when copying LARGE files from SIDE I/II to SD / Nuxx or Indus drives, for instance.

 

Anyhow, after studying this issue for quite a while (which I "desperately" needed to get working for moving large ROM files from Incognito and Ultimate), I came to the conclusion that executing "Copy /s" (or the Blank-screen switch, possibly turning OFF Antic) allows the copy cycle to execute fully, with no problems.

 

This may also give some clues to SDX development team, as to what may be wrong... and eventually fix it. Sounds like on-the-fly copy-buffer / memory corruption, along the way.

 

Cheers!

  • Like 1

Share this post


Link to post
Share on other sites

The standard LESS.COM has one shortcoming, namely it only uses the main memory for the text buffer, so its use is limited to files not exceeding 32 KB very much.

 

With Sparta's ability to random access locations within a file, why does it need to load the whole file into RAM? (or extended RAM in the case of xless) Could it not just stream from file to the screen? Maybe for other features I'm ignorant of at the moment...

Edited by Nezgar

Share this post


Link to post
Share on other sites

 

With Sparta's ability to random access locations within a file, why does it need to load the whole file into RAM? (or extended RAM in the case of xless) Could it not just stream from file to the screen? Maybe for other features I'm ignorant of at the moment...

I'm guessing it is because of how it handles formatting (paging, word wrap, etc.) Just a guess though.

Share this post


Link to post
Share on other sites

With Sparta's ability to random access locations within a file, why does it need to load the whole file into RAM? (or extended RAM in the case of xless) Could it not just stream from file to the screen? Maybe for other features I'm ignorant of at the moment...

It can be done this way, yes. It is just not so simple as it sounds, also the speed would not be the greatest (imagine a jump to line 13745 on a disk file, when you do not really know where in the file this line is: at least for the first time, before the file offsets are cached, you have to count it line by line).

 

The xless.com is, besides, a proof-of-concept of an application program (not a TSR), which uses the Ext RAM as the data buffer, with the use of the SDX memory management system.

 

And to clarify things, xless.com does not really require the ext RAM. It just uses it as additional memory when it is available. But the main memory is used as well: just load a bigger file and press "M"...

Edited by drac030
  • Like 2

Share this post


Link to post
Share on other sites

INTERESTING! (and I thought I was the only one...)

 

This problem shows up quickly (on my side) when copying LARGE files from SIDE I/II to SD / Nuxx or Indus drives, for instance.

 

Anyhow, after studying this issue for quite a while (which I "desperately" needed to get working for moving large ROM files from Incognito and Ultimate), I came to the conclusion that executing "Copy /s" (or the Blank-screen switch, possibly turning OFF Antic) allows the copy cycle to execute fully, with no problems.

 

This may also give some clues to SDX development team, as to what may be wrong... and eventually fix it. Sounds like on-the-fly copy-buffer / memory corruption, along the way.

 

Cheers!

I have an Indus drive (CA-2001 to be specific, but it is a clone, so with Supersynchromesh engaged it should be the same) so I can try that out. Just I am in the PAL land, so it may make some difference.

 

On other devices it may be a problem with too high Pokey index selected, the SIO routines may be too slow to cope with the particular one. Experiment with various values and see which one works the best.

 

IDE+ owners can try if using the IDE+ serial routines (instead of the SDX native drivers) cures the problem. If so - the problem is that the SDX SIO driver is too slow for the selected transfer speed.

  • Like 1

Share this post


Link to post
Share on other sites

SpartaDOS X INDUS.SYS, IIRC, contains the SuperSynchromesh for the CA-2001. The only difference is that on the CA-2001 with the RAM Charger the SuperSynchromesh does not use the track buffer. As to why, I have no idea, you have to ask trub for details.

  • Like 2

Share this post


Link to post
Share on other sites

SDX FATFS driver fixed to cooperate well with the v.4.48 and later revisions.

Will this be incorporated into the release version of 4.49?

  • Like 1

Share this post


Link to post
Share on other sites

Newer version of xless.com.

 

1) faster the "go to line" function.

 

2) the text will now be formatted to 40 columns in GR.0 and 80 columns on the 80-column display (not 39 and 79 as it was before). This should make the documents preformatted for 80 columns (like TOP DOS documentation files) to look better on 80-column displays. Everything else also should take some advantage.

xless.zip

Edited by drac030
  • Like 7

Share this post


Link to post
Share on other sites

after some shananigans I am at divisor 3 though I was told the 4 might be a good idea... Much insight having been gained.

Share this post


Link to post
Share on other sites

Hello. I ran into something unexpected (by me anyway). I wanted to copy all the .COM files located in all directories and sub-directories from drive B: to a folder on I: called BIN. I used the following command to try this:

COPY /R B:\*.COM I:\BIN\

There are plenty of come files on B: (it's the toolkit with all ARCs expanded). There is no error. The command just finishes quickly but nothing is done. Ideas?

 

Using SDX 4.49c.

Edited by fujidude

Share this post


Link to post
Share on other sites

The switch '/R' causes COPY to recursively copy directories with their contents or the contents of a specified directory. It will not grab a specified file type from all subdirectories, as far as I know. If you put some COM-Files to your directory 'B:\' it will copy them but won't go deeper.

 

It would be a nice feature tough. :)

  • Like 1

Share this post


Link to post
Share on other sites

Strange that the wildcard is not observed here. It picks up matching files from the root and completely ignores the /R switch when a filespec is supplied.

  • Confused 1

Share this post


Link to post
Share on other sites

At least it exactly behaves as described in the manual:

The root in that example from Level42 is considered to be the specified directory from which the COM files, if any, will be copied. So it works. Please look up the examples in the manual on page 51.

 

Nevertheless it would be nice to have such a tool at hand to fetch the desired file types from the structure of a drive.

 

But I guess it will get difficult depending on the size of the drive, the directory tree (as the path is limited to 63 chars) and, last but not least, the number of files.

 

For example see the capacities of the MENU command to understand.

Edited by GoodByteXL

Share this post


Link to post
Share on other sites

Yes indeed: I'd forgotten that I'd observed the behaviour of the '/R' switch some time ago and it does correspond to the functionality described in the manual (key words being "all the contents").

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