Jump to content

Photo

SpartaDOS X 4.48


268 replies to this topic

#251 a8isa1 OFFLINE  

a8isa1

    Stargunner

  • 1,339 posts

Posted Mon May 22, 2017 11:41 AM

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, Mon May 22, 2017 11:42 AM.


#252 a8isa1 OFFLINE  

a8isa1

    Stargunner

  • 1,339 posts

Posted Mon May 22, 2017 11:45 AM

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



#253 drac030 OFFLINE  

drac030

    Stargunner

  • Topic Starter
  • 1,819 posts
  • Location:Warszawa, Poland

Posted Mon May 22, 2017 1:04 PM

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

#254 a8isa1 OFFLINE  

a8isa1

    Stargunner

  • 1,339 posts

Posted Mon May 22, 2017 6:07 PM

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



#255 _The Doctor__ OFFLINE  

_The Doctor__

    River Patroller

  • 2,354 posts
  • Location:10-0-11-00:02

Posted Thu May 25, 2017 8:27 PM

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



#256 drac030 OFFLINE  

drac030

    Stargunner

  • Topic Starter
  • 1,819 posts
  • Location:Warszawa, Poland

Posted Wed Aug 9, 2017 8:08 AM

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.

Attached Files


Edited by drac030, Wed Aug 9, 2017 8:11 AM.


#257 drac030 OFFLINE  

drac030

    Stargunner

  • Topic Starter
  • 1,819 posts
  • Location:Warszawa, Poland

Posted Wed Aug 9, 2017 8:21 AM

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.

#258 fujidude OFFLINE  

fujidude

    River Patroller

  • 4,680 posts
  • Location:United States of America

Posted Thu Aug 10, 2017 1:21 PM

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.



#259 Faicuai OFFLINE  

Faicuai

    Dragonstomper

  • 701 posts
  • Location:Florida, U.S.A.

Posted Thu Aug 10, 2017 1:53 PM

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!



#260 Nezgar OFFLINE  

Nezgar

    Chopper Commander

  • 225 posts
  • Location:Regina SK Canada

Posted Thu Aug 10, 2017 10:33 PM

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, Thu Aug 10, 2017 10:36 PM.


#261 Stephen OFFLINE  

Stephen

    Quadrunner

  • 6,453 posts
  • A8 Gear Head
  • Location:No longer in Crakron, Ohio

Posted Fri Aug 11, 2017 2:08 PM

 

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.



#262 drac030 OFFLINE  

drac030

    Stargunner

  • Topic Starter
  • 1,819 posts
  • Location:Warszawa, Poland

Posted Wed Aug 16, 2017 7:32 AM

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, Wed Aug 16, 2017 7:33 AM.


#263 drac030 OFFLINE  

drac030

    Stargunner

  • Topic Starter
  • 1,819 posts
  • Location:Warszawa, Poland

Posted Wed Aug 16, 2017 8:26 AM

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.

#264 lemiel OFFLINE  

lemiel

    Chopper Commander

  • 230 posts
  • Location:Tychy, Poland

Posted Wed Aug 16, 2017 1:14 PM

Draco - do you have SuperSynchromesh code for CA2001?

#265 drac030 OFFLINE  

drac030

    Stargunner

  • Topic Starter
  • 1,819 posts
  • Location:Warszawa, Poland

Posted Thu Aug 17, 2017 7:18 AM

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.

#266 drac030 OFFLINE  

drac030

    Stargunner

  • Topic Starter
  • 1,819 posts
  • Location:Warszawa, Poland

Posted Thu Aug 17, 2017 8:04 AM

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

Attached Files



#267 DrVenkman OFFLINE  

DrVenkman

    River Patroller

  • 2,333 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Thu Aug 17, 2017 8:22 AM

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?

#268 drac030 OFFLINE  

drac030

    Stargunner

  • Topic Starter
  • 1,819 posts
  • Location:Warszawa, Poland

Posted Thu Aug 17, 2017 9:50 AM

Yes.

#269 drac030 OFFLINE  

drac030

    Stargunner

  • Topic Starter
  • 1,819 posts
  • Location:Warszawa, Poland

Posted Thu Aug 31, 2017 6:58 AM

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.

Attached Files


Edited by drac030, Thu Aug 31, 2017 6:58 AM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users