a8isa1 Posted May 22, 2017 Share Posted May 22, 2017 (edited) 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. -SteveS Edited May 22, 2017 by a8isa1 Quote Link to comment Share on other sites More sharing options...
a8isa1 Posted May 22, 2017 Share Posted May 22, 2017 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 1 Quote Link to comment Share on other sites More sharing options...
drac030 Posted May 22, 2017 Author Share Posted May 22, 2017 "Quick" is a bit overstated. But we do what we can. :] 2 Quote Link to comment Share on other sites More sharing options...
a8isa1 Posted May 23, 2017 Share Posted May 23, 2017 "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. 2 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted May 26, 2017 Share Posted May 26, 2017 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.... Quote Link to comment Share on other sites More sharing options...
drac030 Posted August 9, 2017 Author Share Posted August 9, 2017 (edited) 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 August 9, 2017 by drac030 7 Quote Link to comment Share on other sites More sharing options...
drac030 Posted August 9, 2017 Author Share Posted August 9, 2017 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. Quote Link to comment Share on other sites More sharing options...
fujidude Posted August 10, 2017 Share Posted August 10, 2017 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. Quote Link to comment Share on other sites More sharing options...
Faicuai Posted August 10, 2017 Share Posted August 10, 2017 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! 1 Quote Link to comment Share on other sites More sharing options...
+Nezgar Posted August 11, 2017 Share Posted August 11, 2017 (edited) 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 August 11, 2017 by Nezgar Quote Link to comment Share on other sites More sharing options...
+Stephen Posted August 11, 2017 Share Posted August 11, 2017 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. Quote Link to comment Share on other sites More sharing options...
drac030 Posted August 16, 2017 Author Share Posted August 16, 2017 (edited) 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 August 16, 2017 by drac030 2 Quote Link to comment Share on other sites More sharing options...
drac030 Posted August 16, 2017 Author Share Posted August 16, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
lemiel Posted August 16, 2017 Share Posted August 16, 2017 Draco - do you have SuperSynchromesh code for CA2001? 1 Quote Link to comment Share on other sites More sharing options...
drac030 Posted August 17, 2017 Author Share Posted August 17, 2017 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. 2 Quote Link to comment Share on other sites More sharing options...
drac030 Posted August 17, 2017 Author Share Posted August 17, 2017 SDX FATFS driver fixed to cooperate well with the v.4.48 and later revisions. fatfs.zip 6 1 Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted August 17, 2017 Share Posted August 17, 2017 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? 1 Quote Link to comment Share on other sites More sharing options...
drac030 Posted August 17, 2017 Author Share Posted August 17, 2017 Yes. 2 Quote Link to comment Share on other sites More sharing options...
drac030 Posted August 31, 2017 Author Share Posted August 31, 2017 (edited) 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 August 31, 2017 by drac030 7 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted October 27, 2017 Share Posted October 27, 2017 after some shananigans I am at divisor 3 though I was told the 4 might be a good idea... Much insight having been gained. Quote Link to comment Share on other sites More sharing options...
fujidude Posted February 19, 2018 Share Posted February 19, 2018 (edited) 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 February 19, 2018 by fujidude Quote Link to comment Share on other sites More sharing options...
GoodByteXL Posted February 19, 2018 Share Posted February 19, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 19, 2018 Share Posted February 19, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
GoodByteXL Posted February 19, 2018 Share Posted February 19, 2018 (edited) 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 February 19, 2018 by GoodByteXL Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 19, 2018 Share Posted February 19, 2018 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"). Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.