JoSch Posted August 27, 2016 Share Posted August 27, 2016 I meant that a file can be as big as the size of the storage. Quote Link to comment Share on other sites More sharing options...
morelenmir Posted August 28, 2016 Share Posted August 28, 2016 I meant that a file can be as big as the size of the storage. Again I am reaching back to distant memory, but I think the 8K limit comes from the size of a standard Atari cartridge... I think... Apologies again if I am recalling this incorrectly. On a different topic; is there a compressed *.RAR/*.ZIP archive of the uncompressed contents from the SDX toolkit disk? Currently most of these drivers and utilities are stored on a *.ATR disk image and compressed using the ARC format. It can be very tedious to unearth the programme you need in this setting. As mentioned above - I frequently modify and add things to the SDX user space on the SIDE2 and U1MB, often from the toolkit and always spend longer actually getting to the utility I want than editing the SDX ROM itself. 1 Quote Link to comment Share on other sites More sharing options...
fujidude Posted August 28, 2016 Share Posted August 28, 2016 Again I am reaching back to distant memory, but I think the 8K limit comes from the size of a standard Atari cartridge... I think... Apologies again if I am recalling this incorrectly. On a different topic; is there a compressed *.RAR/*.ZIP archive of the uncompressed contents from the SDX toolkit disk? Currently most of these drivers and utilities are stored on a *.ATR disk image and compressed using the ARC format. It can be very tedious to unearth the programme you need in this setting. As mentioned above - I frequently modify and add things to the SDX user space on the SIDE2 and U1MB, often from the toolkit and always spend longer actually getting to the utility I want than editing the SDX ROM itself. Since you can use UFLASH to modify that space, you can do this task all from within the Atari. The TK disk is published as an .ATR which contains several subdirectories and .ARC files buried within. I wrote a batch script which can unpack all of that automatically. See this posting for details. Since you are dealing with U1MB and or SIDE, I will assume you have plenty of space to unpack everything to, be it RAM disk, a compact flash card, or what have you. Once you get the batch script in your Atari and in a folder that's in your path you would do this: Make your current working drive and directory where you wish the root of where everything unpacks to. Enter this command: -RUNPACK A: (this assumes A is where the TK disk is) Go grab some coffee, come back, and enjoy relaxing while your Atari takes care of the tedium for you. 3 Quote Link to comment Share on other sites More sharing options...
morelenmir Posted August 28, 2016 Share Posted August 28, 2016 Since you can use UFLASH to modify that space, you can do this task all from within the Atari. The TK disk is published as an .ATR which contains several subdirectories and .ARC files buried within. I wrote a batch script which can unpack all of that automatically. See this posting for details. Since you are dealing with U1MB and or SIDE, I will assume you have plenty of space to unpack everything to, be it RAM disk, a compact flash card, or what have you. Once you get the batch script in your Atari and in a folder that's in your path you would do this: Make your current working drive and directory where you wish the root of where everything unpacks to. Enter this command: -RUNPACK A: (this assumes A is where the TK disk is) Go grab some coffee, come back, and enjoy relaxing while your Atari takes care of the tedium for you. Very cool that you wrote a batch file for that fujidude!!! I was thinking along those lines myself, but am not yet proficient enough with SDX to writes scripts for it. I have actually done just the same thing manually in the past for the SDX 4.47 toolkit within an Altirra session; copied the whole image's contents to a folder on an APT partition and then laboriously created sub-folders for each *.ARC in its proper hierarchy and then de-ARC'ed them one by one by hand... Groan... Not a fun Sunday afternoon!!! Maybe it would be the best of both worlds if the SDX chaps created the toolkit disk as a maximum size 16MB *.ATR and then kept the same folder layout, but just didn't ARC-up the large files? I think most people who use SDX have at least one method at their disposal to mount a large *.ATR on their machine - and the smaller, toolkit disk image with compressed contents could still be distributed for those that don't. 1 Quote Link to comment Share on other sites More sharing options...
fujidude Posted August 28, 2016 Share Posted August 28, 2016 (edited) Very cool that you wrote a batch file for that fujidude!!! I was thinking along those lines myself, but am not yet proficient enough with SDX to writes scripts for it. I have actually done just the same thing manually in the past for the SDX 4.47 toolkit within an Altirra session; copied the whole image's contents to a folder on an APT partition and then laboriously created sub-folders for each *.ARC in its proper hierarchy and then de-ARC'ed them one by one by hand... Groan... Not a fun Sunday afternoon!!! Maybe it would be the best of both worlds if the SDX chaps created the toolkit disk as a maximum size 16MB *.ATR and then kept the same folder layout, but just didn't ARC-up the large files? I think most people who use SDX have at least one method at their disposal to mount a large *.ATR on their machine - and the smaller, toolkit disk image with compressed contents could still be distributed for those that don't. I'm glad yet another person is saved effort. The technique I used was laborious enough, but not as much as what you put yourself through! I would manually walk the directory but use the DLT provided batch script UNPACK.BAT in each directory that I went into. As to the way they publish the TK currently, I have a few thoughts on that. Of course it's DLT's thoughts, goals, and priorities which will rightfully govern, but anyway here are some of my thoughts: Publishing the TK on a "large" medium would rule out use by those who are unwilling/unable to involve modern computer, and who don't have the specialty hardware for their Atari to make it work either. Their is a philosophy that tuning things to the least common denominator results in the most inclusiveness and opportunity for participation. I think there is merit to that, but is far from any kind of universal truth. The TK is distributed on a 720K floppy image, so we're already past the true least common denominator of a SSSD (90KiB) disk anyway. I would imagine that most of the people who can use 720K floppies on a real Atari, also have access to a large RAMdisk or possibly even a mass storage device. So, perhaps it may as well be published in an expanded form to begin with? In support of leaving things as the status quo; there exists a script to make it easy to expand it by those with the means and desire to do so. So I dunno what to think really. Either way it comes is no problem for me. Edited August 28, 2016 by fujidude 3 Quote Link to comment Share on other sites More sharing options...
Fuji-Man Posted August 28, 2016 Share Posted August 28, 2016 Love the batch file! I'm wondering if the TK should be decompress as to FJC's GUI when it is finished. I guess that can be fixed by config/auto. or maybe an option to expand to 90k/?? floppies. Fuji-Man Quote Link to comment Share on other sites More sharing options...
drac030 Posted August 28, 2016 Author Share Posted August 28, 2016 (edited) I love that script as well. It is absolutely brillant. And notice, that it probably would not get created, if the TK disk had not been distributed in this format[1]. Also, I would not stumble upon the broken GOSUB in SDX 4.47, if I had not decided to create the flashing ATRs under SpartaDOS X on my Atari, using a batch script as well. At the same occasion I found out what functions are missing in the FORMAT.COM and in MKATR.COM. So, these are IMHO excellent examples of how actually using the available utility software causes its improvements and further development. -- [1] And the reason why the TK is distributed in this form is very simple: the TK image contents is put together on my Atari, it is actually a copy of what I keep on my HDD. The binaries come (mostly) from the CVS (a PC, unfortunately, but I fancy that one day at least part of the work could be brought back to the native platform), but e.g. the doc files and the archives themselves are mostly created on the Atari (the MAN files for the SDX commands and CAR: utilities are generated on a PC, Walter exports them from the manual which is so large that it certainly could not be edited on Atari; but the rest of the doc files on the TK is written using FJC's The Last Word). Only one ARC file in the SDX TK was packed on a PC and you would easily guess which one it is Edited August 28, 2016 by drac030 4 Quote Link to comment Share on other sites More sharing options...
drac030 Posted August 28, 2016 Author Share Posted August 28, 2016 I meant that a file can be as big as the size of the storage. Yes, as you certainly guess from my response to morelenmir, we know that it is a problem, just have not yet got around to fix it. The limitation has of course something to do with the size of one bank of the cartridge, but in reality the reason is just such that the CAR: device I/O driver is really very simple (and therefore, at the other hand, short and fast). 2 Quote Link to comment Share on other sites More sharing options...
morelenmir Posted August 28, 2016 Share Posted August 28, 2016 I love that script as well. It is absolutely brillant. And notice, that it probably would not get created, if the TK disk had not been distributed in this format[1]. Also, I would not stumble upon the broken GOSUB in SDX 4.47, if I had not decided to create the flashing ATRs under SpartaDOS X on my Atari, using a batch script as well. At the same occasion I found out what functions are missing in the FORMAT.COM and in MKATR.COM. So, these are IMHO excellent examples of how actually using the available utility software causes its improvements and further development. -- [1] And the reason why the TK is distributed in this form is very simple: the TK image contents is put together on my Atari, it is actually a copy of what I keep on my HDD. The binaries come (mostly) from the CVS (a PC, unfortunately, but I fancy that one day at least part of the work could be brought back to the native platform), but e.g. the doc files and the archives themselves are mostly created on the Atari (the MAN files for the SDX commands and CAR: utilities are generated on a PC, Walter exports them from the manual which is so large that it certainly could not be edited on Atari; but the rest of the doc files on the TK is written using FJC's The Last Word). Only one ARC file in the SDX TK was packed on a PC and you would easily guess which one it is Sometimes I try to do all of a task on the real hardware just for... the nostalgia, the charm of it - I don't know really but it does feel very pleasing somehow if you can do everything on an Atari. I take my hat off to you drac030!!! I wonder if it might be worth explicitly using the super-lean 'vbxe.sys' driver only when the SIDE2 is not attached - and then write the config.sys file I keep in the U1MB SDX user space to load that specific version from the cart. Whereas when the SIDE2 - and its harddrive - is attached the config.sys in the boot-drive root folder will take precedence and load the full version s_vbxe.sys' from there. Will the minimal driver support 80-col mode? Quote Link to comment Share on other sites More sharing options...
fujidude Posted August 29, 2016 Share Posted August 29, 2016 I would say use the paired down version of the driver if you are running into memory resource problems. Quote Link to comment Share on other sites More sharing options...
morelenmir Posted August 29, 2016 Share Posted August 29, 2016 I would say use the paired down version of the driver if you are running into memory resource problems. Its not a resource problem so much as the paired down one will fit in the CAR: user space and the full one won't. However, if i'm reading the user guide right then I think in order to get 80-col I will need as a minimum the 'raw con' driver - which luckily does just fit inside 8k! Quote Link to comment Share on other sites More sharing options...
fujidude Posted August 29, 2016 Share Posted August 29, 2016 What's wrong with disk based drivers? Quote Link to comment Share on other sites More sharing options...
JoSch Posted August 29, 2016 Share Posted August 29, 2016 Yes, as you certainly guess from my response to morelenmir, we know that it is a problem, just have not yet got around to fix it. The limitation has of course something to do with the size of one bank of the cartridge, but in reality the reason is just such that the CAR: device I/O driver is really very simple (and therefore, at the other hand, short and fast). Yes, I know. FJC already explained it to me. But that would be my wish (if I would have one for free ), that I could put Last Word on a SDX cart, for example, not needing any additional drives. Or the full VBXE driver, that won't fit on CAR: Quote Link to comment Share on other sites More sharing options...
drac030 Posted August 29, 2016 Author Share Posted August 29, 2016 Well, why? Additional drives - especially fast ones - are good 2 Quote Link to comment Share on other sites More sharing options...
JoSch Posted August 29, 2016 Share Posted August 29, 2016 Well, why? Additional drives - especially fast ones - are good Well, first of all, you have to them in your system Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 28, 2016 Share Posted September 28, 2016 FAT16 partition in the disk image in this post (drive F:) is misdetected as DOS 2.x format in SDX 4.48 (15-09-2016) unless DEVICE FATFS appears before DEVICE ATARIDOS in CONFIG.SYS. Quote Link to comment Share on other sites More sharing options...
drac030 Posted September 28, 2016 Author Share Posted September 28, 2016 That can happen and probably not much can be done about it apart from loading the ATARIDOS.SYS as the very last FS driver. The DOS 2.0 (and clones') FS has almost no characteristic features, so that it only gets detected by the VTOC[0] containing a value greater than $01 and lesser than $23 or so. So drivers for all other file systems, which can be more reliably determined, should be loaded first. 2 Quote Link to comment Share on other sites More sharing options...
phaeron Posted September 29, 2016 Share Posted September 29, 2016 Maybe I'm missing something, but how would you even get a case where FAT16 and DOS 2.x could be confused? I thought FAT16 was only defined for 512b+ sectors and DOS 2.x / MyDOS for 128b/256b. Quote Link to comment Share on other sites More sharing options...
drac030 Posted September 29, 2016 Author Share Posted September 29, 2016 That is due to the PBI drivers treating $0308/$0309 liberally. ATARIDOS.SYS sets 128 or 256 bytes per sector before requesting VTOC to be loaded, on a 512-bps disk the PBI driver should probably throw an error. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 29, 2016 Share Posted September 29, 2016 (edited) Is there any particular error code the driver should throw (if DBYTLO/HI doesn't match the size of the requested sector) without the whole transfer crapping out before the appropriate file system driver gets its hands on the sector? I just tried implementing a sanity check (returning a NAK error for convenience on a mismatch), and SDX 4.48 doesn't try any file systems further up the table - it just aborts with the error (which is a reasonable reaction, since the implication is that the drive doesn't respond at all). Loading FATFS.SYS before ATARIDOS.SYS is a perfectly reasonable workaround, though. Edited September 29, 2016 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
JoSch Posted September 29, 2016 Share Posted September 29, 2016 (edited) Loading FATFS.SYS before ATARIDOS.SYS is a perfectly reasonable workaround, though. Well, unless you only load FATFS.sys with an IDE device enabled, e.g. an inserted SIDE2 via autoexec.bat Edited September 29, 2016 by JoSch Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 29, 2016 Share Posted September 29, 2016 True. You'd have to put FATFS.SYS on CAR: and change CONFIG.SYS to load it first, or load both file system drivers from AUTOEXEC.BAT, which is easy enough with the help of the SDX Imaging tool. Quote Link to comment Share on other sites More sharing options...
drac030 Posted September 29, 2016 Author Share Posted September 29, 2016 (edited) Hmm, yes, the "error" does not solve the problem. I can of course try to add a check on the sector size to ATARIDOS.SYS and reject 512-bps disks, which probably will fix this particular issue. But in general the problem remains, because in fact any 128- and 256-bps file system can still be mistaken for the DOS 2.0/MyDOS FS in less fortunate circumstances. This does not happen only because there are not many file systems / file system drivers in use. Edited September 29, 2016 by drac030 Quote Link to comment Share on other sites More sharing options...
drac030 Posted October 7, 2016 Author Share Posted October 7, 2016 New beta version available: http://sdx.atari8.info/index.php?show=en_download_beta 5 Quote Link to comment Share on other sites More sharing options...
fujidude Posted October 7, 2016 Share Posted October 7, 2016 New beta version available: http://sdx.atari8.info/index.php?show=en_download_beta Thanks for the heads up. I appreciate you making the beta generally available like this. Unfortunately in my case, just as you first decided to do that I have had less time to tinker with Atari related things. I will be digging in and trying things out when I get a bit more time to do so though. Quote Link to comment Share on other sites More sharing options...
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.