Ricky Spanish Posted May 21 Share Posted May 21 Just an FYI: loads BASICXE.OSS (w/ BASIC XE cart) no problem. Also; [DOS] D:TIME D:DATE D:CLOCK ON Works very well. Quote Link to comment Share on other sites More sharing options...
+mytek Posted May 21 Share Posted May 21 Yeah I like this DOS as well, and use it for various projects 👍 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted May 21 Share Posted May 21 U1MB users may avoid the 'TIME' and 'DATE' steps by installing the ULTD.SYS driver provided here: https://atari8.co.uk/apt/toolkit/ 2 Quote Link to comment Share on other sites More sharing options...
dmsc Posted May 21 Share Posted May 21 Hi! You can also test a modified version by @janzh, named "BW-DOS 1.4", available on github https://github.com/HolgerJanz/BW-DOS: He modified the commands to be more "modern", this is the new command list: Original (BW-DOS 1.3) New (BW-DOS 1.4) RENAME REN ERASE DEL PROTECT PROT UNPROTECT UNPROT CREDIR MD DELDIR RD CWD CD LOAD LOAD CAR CAR RUN RUN PRINT PRINT TYPE TYPE DIR DIR DIRS DIRS BASIC BASIC Also, added a "MAN" command that shows help for any internal/external command. Have Fun! 7 1 Quote Link to comment Share on other sites More sharing options...
Ricky Spanish Posted May 21 Author Share Posted May 21 1 hour ago, dmsc said: You can also test a modified version by @janzh, named "BW-DOS 1.4" Very nice ! Quote Link to comment Share on other sites More sharing options...
Ricky Spanish Posted May 23 Author Share Posted May 23 Just notice On 5/21/2023 at 2:10 PM, dmsc said: named "BW-DOS 1.4" Something in BW-DOS 1.4 is turning off the keystroke sounds, warm reset re-enables the sound. Quote Link to comment Share on other sites More sharing options...
Marius Posted May 24 Share Posted May 24 I have been using this DOS for a while in the past. It worked very nice, but... I had one serious issue with it. I was using it on a bigger partition and I use my Atari a lot for some kind of 'productive' work (writing txt's in a distraction free environment) and I experienced that the version of BW DOS I used was extremely slow when it comes to updating or replacing/overwriting existing files. It took even that long that sometimes I was afraid that my partition was 'screwed up'. That was the main reason I decided to move (back) to the disk version of SpartaDos. Anyone else who experiences this? It might be fixed in newer versions of BW DOS? I had pretty full partitions, so I am not sure whether it is something that is easy to test on a new/fresh partition. Quote Link to comment Share on other sites More sharing options...
baktra Posted May 24 Share Posted May 24 18 minutes ago, Marius said: I have been using this DOS for a while in the past. It worked very nice, but... I had one serious issue with it. I was using it on a bigger partition and I use my Atari a lot for some kind of 'productive' work (writing txt's in a distraction free environment) and I experienced that the version of BW DOS I used was extremely slow when it comes to updating or replacing/overwriting existing files. It took even that long that sometimes I was afraid that my partition was 'screwed up'. That was the main reason I decided to move (back) to the disk version of SpartaDos. Anyone else who experiences this? It might be fixed in newer versions of BW DOS? I had pretty full partitions, so I am not sure whether it is something that is easy to test on a new/fresh partition. The disk format is the same as SpartaDOS. So, if there is no difference in the settings (e.g., the VERIFY command), then it is probably the algorithm that looks for free space, manages it and overwrites the sectors. We would need someone who understands the very internals of that DOS. Cannot think of anyone else than Jiri Bernasek, or possibly @janzh. But as far as I know, Jiri Bernasek is out of the Atari game for a long time. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted May 24 Share Posted May 24 The disassembly is very interesting and the code is extremely concise. Since I need to write an SDFS file system driver at some point, it's a very useful reference. If I get anywhere with working through the code and adding meaningful labels (assuming I can find the time), I'll post it here. 1 Quote Link to comment Share on other sites More sharing options...
janzh Posted May 24 Share Posted May 24 (edited) BW-DOS is very slow in updating. It looks like a full VTOC scan is done. I am still try to figuring out how to fix it. There is no difference in different releases of BW-DOS. There is no functional error. It just takes time. You can minimize the issue with smaller partitions (smaller VTOC). BW-DOS was developed with minimal memory use in mind so sometimes performance is sacrificed. As soon as I find a solution or improvement I will update BW-DOS 1.4. @flashjazzcat If you like I can give you write access to the BW-DOS 1.4 GitHub repository. Edited May 24 by janzh 6 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted May 24 Share Posted May 24 1 hour ago, janzh said: If you like I can give you write access to the BW-DOS 1.4 GitHub repository. I appreciate it, although I would probably just fork it anyway and do my thing (I find I have to format source code in my own particular fashion before I start to mess with it). 1 hour ago, janzh said: BW-DOS was developed with minimal memory use in mind so sometimes performance is sacrificed. This is very clearly apparent, and I'm quite impressed by the methods employed. It's no bigger (at ~5K) than the FAT16/32 DOS I wrote a year or so back, but I think the space-saving methods in BW-DOS are even more aggressive. I'm especially intrigued by the MOVE_CALL command, which takes a list of in-line pseduo-instructions for copying and moving memory, etc. Very well thought out. 1 Quote Link to comment Share on other sites More sharing options...
janzh Posted May 25 Share Posted May 25 (edited) Ok. Just let me know if you found some improvements (@flashjazzcat). I would like to keep the sources compatible with FastAssembler. At the moment I work on FastAssembler compatible sources of OS XL Rev 2 (70% done). If I am finished then I will focus on this update performance issue. Now THE news: Jiří Bernášek (BEWE-Soft) just contacted me and send me the original sources of BW-DOS 1.3. It was written with ATMAS II. If I get the permission then I will publish them on GitHub. I ask him also for hints on the update performance issue. Edited May 25 by janzh 10 Quote Link to comment Share on other sites More sharing options...
pirx Posted May 25 Share Posted May 25 (edited) I wrote Jiří a letter yesterday with a link to your work, so happy Jiří still had the sources!!! Additional info - I've just pushed to github sources of Micro Sparta DOS - a fantastic util from Jiří that we further developed in the noughties: https://github.com/pkali/micro-sparta-dos I has got one cool trick to speed up disk operations I devised with @Pecus - the file sector map is read in advance and heavily compressed, often to a couple of bytes. This works miracles for sequential binary file reading. As it takes very little memory, it might be a cool trick to cache reads in a full system (maybe). It is also working with 512b sectors. If you find it interesting, I could translate the comments to English and clean up the sources a bit maybe? Edited May 25 by pirx 6 Quote Link to comment Share on other sites More sharing options...
janzh Posted May 25 Share Posted May 25 @pirx Thanx a lot! I just pushed the archive to GitHub: https://github.com/HolgerJanz/BW-DOS/blob/c84de35fab0b3db6e18d8bfa60c4a8aa87daade5/1.3/BW-DOS 1.30 Sources.atr I just browsed through the ATR. It contains sources for BW-DOS 1.0/1.1/.1.2/1.21 and the folder UPDATE2 contains 1.30. Furthermore the sources for B-TAPE are on this ATR. It will take some time for me to go through all of it. With the performance issue, Jiří confirmed my suppositions. Here what he wrote to me: As for the performance issue - yes, it's the trade-off between performance and memory usage. SpartaDOS uses many disk buffers, so it "remembers' state of many sectors of the disk (today we might call it a disk cache), so searching the bitmap table (or VTOC, if you prefer) is a quick operation. Those buffers, however, use a whole lot of memory. BW-DOS is focused on low memory usage, so that it squeezes below a relatively normal MEMLO limit, and while code optimizations also yield some precious bytes, cutting the number of disk buffers (256 bytes each) was the best way to save memory.So, BW-DOS have just three buffers - the bare minimum needed to write a SpartaDOS disk: One for data sector, second for sector-map of the file, and third for the bitmap (VTOC). It surely may have performance issues, especially with more files open simultaneously, or when large disks (where the bitmap/VTOC spans a lot of sectors) get to a state of considerable fragmentation of the contents (so that sectors for a new file are picked from many parts of the bitmap/VTOC, rather than written as uninterrupted ranges of sucessive sectors).When everything goes smoothly, the three buffers are sufficient. Once there's a need for more sectors at a time, SpartaDOS just uses another of it's many buffers. BW-DOS must free some buffer by writing it's contents (even if just partially finished) to the disk, so in more complex situations we may end up with a tiresome process of repeated swapping between RAM buffers and physical disk, even for small operations in the sectors content. The algorithm is more or less the same as in SpartaDOS, both will behave in a similar way when their available buffers are exhausted, and both manage to complete the operation even with insufficient number of buffers, at the cost of time and physical disk accesses. Sparta is just much more difficult to overload in this way, with it's extensive buffering space. Actually, both the systems will work even with a single buffer, but extremely slow.So it's all about the trade-off between RAM usage for buffers and the performace for more complex operations.An important part is the function of allocation pointers in the boot sector (last allocated sector for files/directories), which gives a starting point for bitmap/VTOC searches. It wasn't really optimal in Sparta, and early BW-DOS versions suffered from frequent resets of both pointers to the very begin of the disk (on all delete operations), triggering a long bitmap/VTOC search, and causing files and directories to mix together. Later I came with the compromie solution (for lack of any better idea) to reset the pointers to fixed values based on percentage of disk capacity, to keep the files/directories separation intact, but still the method is not ideal. In SpartaDOS this have little importance due to the extensive caching in disk buffers, but the bare minimum of 3 buffers in BW-DOS is more sensitive in this regard (i.e. just one buffer for bitmap/VTOC operations).My conclusion always was that BW-DOS is the best I can do in the little memory available, works more or less fine in majority of situations, and for more intensive work there's the option to use Sparta instead. More buffers in BW-DOS will ruin it's compatibilty provided by the low MEMLO value, making the whole project more or less pointless (for me at least), so I didn't go this way.BTW, Sparta can also split large 256-byte buffers to pairs of short 128-byte ones, which BW-DOS doesn't. This is to save code, because disks with 128-byte sectors are small anyway, and sort-of obsolete, and so are not a priority for me.Well, that's what I seem to remember after the long years passed... I can't really go into more detail, I just don't remember... --- I will check further because some times I observed that the allocation pointers in the boot sector get out of valid sector number so BW-DOS always starts from the beginning but that is a supposition I have to investigate further. 6 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted May 25 Share Posted May 25 Amazing. The disassembly has more comments than the original source code. 2 Quote Link to comment Share on other sites More sharing options...
Creamhoven Posted May 25 Share Posted May 25 2 minutes ago, flashjazzcat said: Amazing. The disassembly has more comments than the original source code. I don't even see the code anymore, Thomas. 2 1 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted May 25 Share Posted May 25 1 hour ago, Creamhoven said: 1 hour ago, flashjazzcat said: Amazing. The disassembly has more comments than the original source code. I don't even see the code anymore, Thomas. Even when I do that to my own source code, I still can't figure out what I was doing after a few weeks away! 1 Quote Link to comment Share on other sites More sharing options...
Creamhoven Posted May 25 Share Posted May 25 11 minutes ago, Stephen said: Even when I do that to my own source code, I still can't figure out what I was doing after a few weeks away! Just follow the white rabbit. 1 Quote Link to comment Share on other sites More sharing options...
janzh Posted May 25 Share Posted May 25 Tell or have been told that the different. Someone Quote Link to comment Share on other sites More sharing options...
Ricky Spanish Posted May 25 Author Share Posted May 25 (edited) IMO keep it nice and light. That said, I'm 100% positive @flashjazzcat can add a little magic to it. if he so inclines too. Edited May 25 by Ricky Spanish Quote Link to comment Share on other sites More sharing options...
janzh Posted May 25 Share Posted May 25 1 minute ago, Ricky Spanish said: IMO keep it nice and light. That said, I'm 100% positive @flashjazzcat can add a little magic to it. if he so inclines too. Thanx! 1 Quote Link to comment Share on other sites More sharing options...
Mathy Posted May 25 Share Posted May 25 Hello Holger Is there any chance Jiří will return to the Atari 8 bit scene? Sincerely Mathy PS maybe you can tell him about the Fujiama... Quote Link to comment Share on other sites More sharing options...
janzh Posted May 26 Share Posted May 26 @Mathy I will try. Unfortunately I cannot attend this year because we are still on vacation this time. 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted May 26 Share Posted May 26 (edited) 13 hours ago, Ricky Spanish said: I'm 100% positive @flashjazzcat can add a little magic to it. if he so inclines too. I'm not sure, since BW-DOS is already a marvel of concise coding, but I would like to see a 'get current path' CIO command added, so that applications can establish the path to the current working directory, and the command prompt could display the working directory path. This requires walking backwards up the path to the root, starting at the current working directory, so would be an interesting challenge to try and squeeze in. Edited May 26 by flashjazzcat 3 Quote Link to comment Share on other sites More sharing options...
Ricky Spanish Posted May 26 Author Share Posted May 26 3 hours ago, flashjazzcat said: so would be an interesting challenge to try and squeeze in. Smart 🍪 like you.. I'm sure it'd be a 🍰 walk. 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.