drac030 Posted October 15, 2012 Share Posted October 15, 2012 (edited) Great work, Jon. Finally someone fixed it at least so that it basically works. As for SIO2BSD, I don't know how to port it into Windows, I am no Windows programmer. As you know, I tried Cygwin, and the program compiled and worked, but the transmission was very unstable, so I gave it up. Also, Cygwin does not look like it knew how to setup "non-standard" serial baudrates for a serial port, it only allowed 19200, 38400, 57600, which anyway wouldn't be bad, except that it didn't work reliably. Anyway, I am sure only the basic routines which are doing the actual SIO communication are to be ported, the rest may remain intact. The other solution would be to implement PC-Link into AspeQt, which might be easier to do. SIO2BSD is available in source code, it is written in straight C, it is GPL-licensed and it should not be difficult to cut the PC-Link part (which occupies a continuous section of sio2bsd.c) and paste it into AspeQt. If you (or anyone) want to do that, I'll certainly have nothing against. Edited October 15, 2012 by drac030 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 15, 2012 Share Posted October 15, 2012 Thanks Konrad. The other solution would be to implement PC-Link into AspeQt, which might be easier to do. SIO2BSD is available in source code, it is written in straight C, it is GPL-licensed and it should not be difficult to cut the PC-Link part (which occupies a continuous section of sio2bsd.c) and paste it into AspeQt. If you (or anyone) want to do that, I'll certainly have nothing against. I'm no Windows coder either (not yet, but I hope to be eventually), but I do know straight C and I should be able to implement anything which isn't too GUI or OOP centric. Really, I had intended to fix this basic flaw in Aspeqt for some time, but since I previously had APE, there was little motivation until now. Although I'm not sure I'm yet up to the bigger task of incorporating PC-Link, I'd be happy to evaluate the possibility. It should be an excellent educational exercise, for a start. Quote Link to comment Share on other sites More sharing options...
atari8warez Posted October 15, 2012 Share Posted October 15, 2012 (edited) @FJC I haven't tried your fix but thank you for taking the time doing it John. I had a totally different approach in mind for fixing the folder mounting and be compatible with both Atari DOS and SDX. Although I am not really ready to discuss it yet as it is in the very first stages of planning/tinkering and I need to improve my SDX knowledge a bit more before I can intelligently discuss it anyway . I am also hoping that it will be both READ and WRITE capable folder mount. Edited October 15, 2012 by atari8warez Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 15, 2012 Share Posted October 15, 2012 (edited) I haven't tried your fix but thank you for taking the time doing it John. I had a totally different approach in mind for fixing the folder mounting and be compatible with both Atari DOS and SDX. Although I am not really ready to discuss it yet as it is in the very first stages of planning/tinkering and I need to improve my SDX knowledge a bit more before I can intelligently discuss it anyway . I am also hoping that it will be both READ and WRITE capable folder mount. No problem - as I say, I did it in a hurry because I needed something that worked at short notice. Note the new code should remain compatible with Atari DOS (although I haven't tested it yet). R/W capability will indeed require a completely different approach, although if we can get PC-Link support added as well, it'll definitely be worth having, since I think that's a more elegant approach, especially since the client-side SDX driver already exists (not to mention hopefully drop-in server code). Native R/W support for Atari DOS would remain a valuable addition, however. Edited October 15, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
atari8warez Posted October 19, 2012 Share Posted October 19, 2012 (edited) Jon, I finally had the opportunity to test your modification. The mod seems to have somewhat fixed the SDX problem but created 2 new ones: The first one is with AtariDos: Copying a file from a folder image to another disk now fails after copying sector# 321 with an error message 164 (file Number Mismatch). This happens with files larger than 320 sectors, anything smaller is OK. Looks like Fatih had a reason why he implemented the sector numbers as he did. I can't really comment why, as I haven't really examined his code carefully yet. The second one is with SDX: New code seems to have introduced a new kind of loop where SDX just keeps copying a file until copy is aborted with Break key. This again seems to happen with files over a certain # of sectors. I tried to copy an enhanced density .atr to a HD image and the results can be seen on the attached screen captures. Take a look at the original file size and the size of the copied file after i ended the copy with Break key. SDX copy command also seem to have gone berzerk showing strange completion percentages. One other thing i noticed is the size of the AspeQt executable in your zip archive. It is 8 times larger than v0.8.3 executable I have here. Do you have any idea what might have happened? Edited October 19, 2012 by atari8warez Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 19, 2012 Share Posted October 19, 2012 (edited) I said on Monday that using two mirrored folders was unlikely to work, but it looks like this extends to copying between a mirrored folder and an ATR. Muliple folder image support should be an easy fix, and I can code it up at the weekend if it's important. The reason for the failure is (most likely) that there's only one global AtariFileNo index, so sectors from D1: will be delivered for D2: and vice versa, causing the file number mismatch errors. What's needed is an array of file number indexes. Other than this I don't see any particular reason for the peculiarities of the original implementation, other than that it was quite simple (at least, once one has puzzled it out). ...the AspeQt executable in your zip archive. It is 8 times larger than v0.8.3 executable I have here. Do you have any idea what might have happened? None at all. The QT build I installed was enormous, and I'm a complete noob at using it. Edited October 19, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 23, 2012 Share Posted October 23, 2012 (edited) Just tested this with a similar scenario to the one Ray tried, and smaller files seemed to copy fine. As for the larger "problem" files: It suddenly occurs to me (in fact it's rather obvious) that you can't have a file larger than 90KB on a 90KB disk image if you're going to make all the file's sector numbers unique (which I have). Moreover, if you read the description of my folder mounting implementation carefully, you'll notice that files are assigned sector numbers from 400 up, so under Atari DOS, naturally a file with more than 320 sectors is gonna fail (since it'll hit sector 720 at that point). In any case, I wouldn't expect users to care about the technical reasons for such limitations, so there are a few very easy things which can be done: Use the first 64 data sectors of the disk - rather than the 64 sectors immediately below the VTOC - as the first sectors of each of the 64 possible files. This will leave more sectors in front of the VTOC and directory to use as file content sectors. If we're using a non-contiguous set of sectors for file content (i.e. the file's second sector onwards), naturally when we hit the VTOC/directory (i.e. sector 294 of a file), we'll have to "jump" to sector 369. We could emulate an enhanced density disk to cater for file sizes approaching 130KB. We could push the envelope further (perhaps by presenting the folder as a MyDOS volume), but given that you can have 64 files EACH of 90 / 130KB, the solution as is seems reasonably flexible. SDFS caters for larger files efficiently, but I think the PC-Link solution is better for SDX, as I've said before. I'll hopefully have time to action these fixes today. Edited October 23, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 23, 2012 Share Posted October 23, 2012 (edited) OK, please test this: http://www.atari8.co...0.8.4-test1.zip File start sectors are now 4 through 67, and the second and subsequent data sectors for each file run from 68 through 719 (skipping VTOC and directory area; not sure why Fatih disallowed 720, but I've left that alone for the moment. Not using sector 720 was probably simply a result of it lying outside the 64 files * 5 sector range). This should allow for files of around 85KB. Sources here: http://www.atari8.co...4-test1-src.zip The only tests I've done (since I don't have many 45KB+ binary files to hand) involved copying some large ASCII source files on the mirrored folder (D3:) across to an SDFS formatted 180KB ATR on D2:. The main objective was to ensure the continuation from sector 359 to 369 works correctly. A 55KB text file copied to the ATR at least had the exact same file size as the original in the mirrored folder, but I won't rule out the possibility of some bit of sector math being out by one. Ideas for write support suddenly present themselves, but it's a much trickier job so I'll leave it for now. New code is somewhat verbose, but I'll collapse some common "IF" clauses once I'm sure everything works. NB: Executable file size anomaly also seems to have magically righted itself. Edited October 23, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
atari8warez Posted October 23, 2012 Share Posted October 23, 2012 Thanks Jon, will do.. Quote Link to comment Share on other sites More sharing options...
w1k Posted October 23, 2012 Share Posted October 23, 2012 what about cz/sk translations? - or only czech, its 90% same as slovak Quote Link to comment Share on other sites More sharing options...
atari8warez Posted October 23, 2012 Share Posted October 23, 2012 Victor, Czech translation is added, just waiting for the next release and if/when FJC finishes his fix for the folder images, I will release version 0.8.4 with Czech translation + Folder Image fix. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 23, 2012 Share Posted October 23, 2012 (edited) According to Bill Wilkinson's Inside Atari DOS, sector 720 is outside of the addressable range of a single density disk's VTOC, because the whole map is erroneously shifted one bit right (i.e bit 7 of VTOC byte $0A represents the unaddressable sector 0, while bit 0 of byte $63 represents sector 719. So that explains that. Edited October 23, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
atari8warez Posted October 23, 2012 Share Posted October 23, 2012 (edited) Yup, that's the reason. In DOS, actual sector #1 is referred to as sector 0, so total number of sectors on a DOS disk goes from 0-719, however an Atari 810 apparently will not accept use of sector #0, so effectively there are only 719 usable sectors. Apparently there is some software that took advantage of the "bug" and used sector 720 for their own purposes, so Atari did not fix it for the sake of compatibility. Edited October 23, 2012 by atari8warez Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 23, 2012 Share Posted October 23, 2012 Yup... that is the reason :-) Bill will be delighted to hear he was correct! Quote Link to comment Share on other sites More sharing options...
atari8warez Posted October 23, 2012 Share Posted October 23, 2012 Bill will be delighted to hear he was correct! I never suspected him Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 23, 2012 Share Posted October 23, 2012 (edited) You're holding out on me here: you could have saved me the trouble of reading the VTOC chapter. In DOS, actual sector #1 is referred to as sector 0, so total number of sectors on a DOS disk goes from 0-719, however an Atari 810 apparently will not accept use of sector #0, so effectively there are only 719 usable sectors. Apparently there is some software that took advantage of the "bug" and used sector 720 for their own purposes, so Atari did not fix it for the sake of compatibility. AFAIK, few drives will acknowledge a request for sector 0. I think it's regarded as good practice to return an error when sector 0 is requested (even in hard disk handlers), although there's no special reason why it can't be provided for. I'd expected (wrongly), though, that bit 7 of byte $0A of AtariDOS's VTOC referred to sector 1, not 0. This has no impact on the folder imaging as far as reads are concerned, but I'm trying to establish the exact sequence of sector requests which occur when - for example - opening a file for write, and from which we might intuit that a file on the host machine needs to be created, and all subsequent sector writes directed into it (until the next VTOC write, or when the file sector length is finally written to the directory sectors, at which point the file may be closed). Edited October 23, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
drac030 Posted October 23, 2012 Share Posted October 23, 2012 According to Bill Wilkinson's Inside Atari DOS, sector 720 is outside of the addressable range of a single density disk's VTOC, because the whole map is erroneously shifted one bit right (i.e bit 7 of VTOC byte $0A represents the unaddressable sector 0, while bit 0 of byte $63 represents sector 719. So that explains that. This is only partially true. The bitmap is shifted, right, but this per se does not make the sector 720 to be "outside of the addressable range of a single density disk's VTOC". The VTOC sector has 128 bytes, the bitmap inside it has 118 bytes, and 118*8 is 944. And this, less 1, is the real number of sectors addressable with a DOS 2.0 VTOC. So it should be enough to set the relevant bit in the VTOC (bit 7 of sector $64) to make the sector usable. Of course only if DOS 2.0 does not contain a hardcoded limit that outs the sector 720, but if it does, the whole VTOC-stuff is irrelevant to the problem. Quote Link to comment Share on other sites More sharing options...
atari8warez Posted October 23, 2012 Share Posted October 23, 2012 (edited) You're holding out on me here: you could have saved me the trouble of reading the VTOC chapter. AFAIK, few drives will acknowledge a request for sector 0. I think it's regarded as good practice to return an error when sector 0 is requested (even in hard disk handlers), although there's no special reason why it can't be provided for. I'd expected (wrongly), though, that bit 7 of byte $0A of AtariDOS's VTOC referred to sector 1, not 0. This has no impact on the folder imaging as far as reads are concerned, but I'm trying to establish the exact sequence of sector requests which occur when - for example - opening a file for write, and from which we might intuit that a file on the host machine needs to be created, and all subsequent sector writes directed into it (until the next VTOC write, or when the file sector length is finally written to the directory sectors, at which point the file may be closed). Well Jon, I thought you already knew whatever needs to be known about Atari DOS and SDX before you volunteered to fix the Folder Imaging. Personally that is the reason why I haven't gone ahead and try my luck with the folder imaging yet, because I can't comfortably say that I know everything about those two DOSes and I personally wouldn't try a fix before I get that knowledge 100%. Edited October 23, 2012 by atari8warez Quote Link to comment Share on other sites More sharing options...
atari8warez Posted October 23, 2012 Share Posted October 23, 2012 AFAIK, few drives will acknowledge a request for sector 0. Well newer drives like 1050 may, but I have never tried it myself so I can't really comment on that. The problem apparently was with Atari 810, and later DOS inherited this behaviour to remain compatible with 810 and software that used the bug to their advantage. Quote Link to comment Share on other sites More sharing options...
drac030 Posted October 23, 2012 Share Posted October 23, 2012 (edited) I don't think sector 0 was ever considered valid in Atari disk storage. The OS, at least, attempts to boot reading sector 1 as the first one. The bitmap shift is rather due to some oblivion, namely the original code seems to have forgotten to decrease the sector number before calculating the VTOC offsets from it. Funnily enough, SpartaDOS (where there is no question of DOS 2.0 backward compatibility) does the same, so maybe this is an intended simplification. Edited October 23, 2012 by drac030 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 23, 2012 Share Posted October 23, 2012 Well Jon, I thought you already knew whatever needs to be known about Atari DOS and SDX before you volunteered to fix the Folder Imaging. Personally that is the reason why I haven't gone ahead and try my luck with the folder imaging yet, because I can't comfortably say that I know everything about those two DOSes and I personally wouldn't try a fix before I get that knowledge 100%. It's OK - Put the tape measure away Ray. Earlier today I mentioned that I wasn't certain why Fatih had left out sector 720, and I even ventured a theory (which was apparently wrong). I didn't mean to make a big deal about reading a short chapter of Bill's book to obtain the facts (and I routinely refer to reference material all the time when working on any project, not carrying encyclopedic and infallible knowledge around in my brain), but if you knew why sector 720 was left out of the folder imaging, you were more than welcome to contribute and put me right on the matter earlier today. In any case, Drac030's remarks remind us that few things are written in stone, so you might spend six months or a year (or however long the folder imaging has needed fixing) learning everything there is to know about Atari DOS, only to discover the information was incomplete, flawed or open to interpretation. The bitmap shift is rather due to some oblivion, namely the original code seems to have forgotten to decrease the sector number before calculating the VTOC offsets from it. Funnily enough, SpartaDOS (where there is no question of DOS 2.0 backward compatibility) does the same, so maybe this is an intended simplification. That sounds like a rational explanation. Quote Link to comment Share on other sites More sharing options...
atari8warez Posted October 23, 2012 Share Posted October 23, 2012 (edited) but if you knew why sector 720 was left out of the folder imaging, you were more than welcome to contribute and put me right on the matter earlier today. I knew why sector 720 is not used but didn't know what Fatih did in his code and didn't know you had an issue with sector 720 until I read your later message in the thread. I don't have a habit of holding on the information (or code for that matter as you can see I release every code i write to public - unless of course I am doing a paid for work ) OK, while I am on the subject, i would like to comment on your latest fix: Basically the fix is doing what it says its doing. Smaller files work fine for copying from the folder image (although I must admit I haven't yet tested file contents with one exception). Files over 80K (80,500 bytes) however still do not work, the copy will simply ignore (skip) the rest of the file (see attached photos). So for example if I copied a single density ATR file from a Folder Image, that ATR will not load into AspeQt as its size will be shorter than a valid SD ATR (won't be a valid ATR in any case even if AspeQt loaded it) The fix also broke the ATARI DOS functionality of the Fatih's original code, and the largest file size problem now also affects Atari DOS. So, with the way the fix is right now, I can not include it in the next release of AspeQt. Sure it will do whatever you wanted to do with it, but I can not release it for public consumption if the resulting files from a Folder Image copy are not usable/valid. Edited October 23, 2012 by atari8warez Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 25, 2012 Share Posted October 25, 2012 (edited) I knew why sector 720 is not used but didn't know what Fatih did in his code and didn't know you had an issue with sector 720 until I read your later message in the thread. I don't have a habit of holding on the information (or code for that matter as you can see I release every code i write to public - unless of course I am doing a paid for work ) No problem. OK, while I am on the subject, i would like to comment on your latest fix: Basically the fix is doing what it says its doing. Smaller files work fine for copying from the folder image (although I must admit I haven't yet tested file contents with one exception). Files over 80K (80,500 bytes) however still do not work, the copy will simply ignore (skip) the rest of the file (see attached photos). So for example if I copied a single density ATR file from a Folder Image, that ATR will not load into AspeQt as its size will be shorter than a valid SD ATR (won't be a valid ATR in any case even if AspeQt loaded it) I have difficulty accepting that the inability to access files of over 80KB in length is a bug, since the program is attempting to present a folder on the PC as an AtariDOS disk image of 90KB, and, as well as doing "what it says it is doing", it is also subject to the file size limtation I already explained when presenting the fix. I'm one hundred per cent certain that unlimited file size was not a design criteria of the original implementation, but was a side-effect (which you happen to have found useful) of the circular sector numbering. Fatih's design will allow files of almost infinite length to be read from the host, simply because the sector links never exceed 719, but repeat in a loop of four ad-infinitum. That's the behaviour which breaks SDX compatibility. Now, while I have never yet felt the need to copy ATR files inside the Atari file system, I'm aware of at least one situation in which one might want to do this - namely when mounting ATR files using the IDE Plus. However, since that functionality requires SDX, and the original folder imaging doesn't work with SDX, there must be some other purpose for this activity. So the question remains, if folder imaging is incompatible with SDX, and Atari DOS 2.x can access files of - at most - c. 130KB (assuming we were emulating an enhanced density disk) - what use are files of unlimited size? Ah - unless they work with MyDOS? Who knows? The fix also broke the ATARI DOS functionality of the Fatih's original code, and the largest file size problem now also affects Atari DOS. I'm afraid this is simply repeating for the second time what I've already explained: namely that the maximum file size is now limited by the size of a single-density AtariDOS disk (minus 64 internal sectors allocated as the first sector of each file). Enjoyable as repeated use of the word "broke" must be, you're again regurgitating what I wrote when I presented the fix: namely that file sizes are now limited to the physical size of the disk, minus overhead. The reason Fatih's original code allowed unlimited file sizes is the same reason his implementation "broke" SDX ATARIDOS.SYS compatibility. For that reason - and without criticising Fatih's coding skills, which in QT are astronomically superior to my own - I always considered the folder mounting implementation to be inherently f**ked up and in need of correction. Of course, it's possible to conveniently take the opposing view and accuse SDX's AtariDOS driver of being incompatible with Fatih's implementation. Now, if you choose to favour the support of incongruously large file sizes over SDX compatibility, when said large files cannot (as far as I can see) be used with a client file system which supports the circular sector links, you're entirely within your rights to do so. I certainly won't take this as an inherent bias towards the original implementation, since you obviously need to copy large ATR files on a regular basis using some DOS other than SDX (since, were it not for the fix I've implemented, you'd be unable to read any files - large or small - under SpartaDOS X). You pays your money and takes your choice, I'm afraid. So, with the way the fix is right now, I can not include it in the next release of AspeQt. Sure it will do whatever you wanted to do with it, but I can not release it for public consumption if the resulting files from a Folder Image copy are not usable/valid. This is the outcome I expected, and the reason I was right to be tripidatious about sharing what was a fix for personal use (but which, nevertheless, I assumed would be useful to others, as it apparently was to Drac030). The fact is, the fix works as designed (to my surprise, since I'm no C++ programmer), subject to some further improvements (which it's pointless discussing here), but sharing the work here has proved such a tremenous headache and a fruitless exercise in frustration that - should I choose to do more work on this - I'll share the results elsewhere or privately with whomever is interested. Meanwhile, I'll hope to see SDX comaptibility coupled with unlimited file sizes and full read/write compatibility in a forthcoming "official" release. I'll leave it up to the discerning public to adjudge the reasons for this outcome. Edited October 25, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
ivop Posted October 25, 2012 Share Posted October 25, 2012 None at all. The QT build I installed was enormous, and I'm a complete noob at using it. You probably installed a version with debug symbols, et cetera, and/or are compiling with debug information. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 25, 2012 Share Posted October 25, 2012 You probably installed a version with debug symbols, et cetera, and/or are compiling with debug information. Thanks - yeah, I think it was the latter noob error. 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.