dmsc Posted June 16, 2023 Share Posted June 16, 2023 Hi! 9 hours ago, janzh said: It is to make the source more readable. The EOR optimization is fragile if somethings changed by the caller. Yes, but I doubt the caller will change Have Fun! Quote Link to comment Share on other sites More sharing options...
Ricky Spanish Posted June 26, 2023 Author Share Posted June 26, 2023 So far , so good. the only PITA is it unable to load anything DOS 2.5. Quote Link to comment Share on other sites More sharing options...
janzh Posted June 27, 2023 Share Posted June 27, 2023 (edited) BW-DOS only supports SpartaDOS file system. Use tool MENU to copy files between SpartaDOS and Atari file system. For more information about tool MENU see documentation page 11 pp. https://github.com/HolgerJanz/BW-DOS/blob/main/BW-DOS 1.4.pdf Edited June 27, 2023 by janzh 1 Quote Link to comment Share on other sites More sharing options...
Ricky Spanish Posted July 24, 2023 Author Share Posted July 24, 2023 Any updates for this wonderful DOS ? Quote Link to comment Share on other sites More sharing options...
janzh Posted July 25, 2023 Share Posted July 25, 2023 Still work in progress. In the summertime I do not spend so much time on my Atari. Quote Link to comment Share on other sites More sharing options...
Ricky Spanish Posted July 25, 2023 Author Share Posted July 25, 2023 12 hours ago, janzh said: Still work in progress. In the summertime I do not spend so much time on my Atari. understandable. Enjoy the summer !! Quote Link to comment Share on other sites More sharing options...
Jiří Bernášek Posted September 13, 2023 Share Posted September 13, 2023 I don't have much time to look, but now I see that there's quite a lot of progress, which is great! I seem to remember a few things, which may be relevant to the previous discussion: - The motivation for "XOR $55" obfuscation in the binary files was not a "protection". Looking at the list, these are all resident drivers. Since they provide the option to uninstall (the OFF option), there are some checks for presence of installed resident code (I don't remember exact procedure and motivation, might also be an attempt to avoid installation of second copy), which include a memory search for the said code. Because of this, the binary file (possibly still partially present in disk buffers below MEMLO) shouldn't contain the same pattern, and so I decided to encrypt it. - The motivation for clearing user RAM after boot-up is somehow inherited from Micro-SpartaDOS gameloader, to achieve the same (maximum) level of compatibility. While testing the gameloader on my game collection, including rather obscure items inherited from boot-tape versions of the 80's, I observed several pieces not running well (or displaying garbage) if not loaded into a clean RAM. I believe that this requirement was more of a bug, not revealed due to the nature of tape-boot process (always into clean RAM), but it doesn't really hurt to have the maximum compatibility at least for the first application after boot-up (typical case, if one just want to run a game). It doesn't cost RAM, since the initialization code is just temporary. - Loading the DOS code to upper RAM and then copying to $700 is indeed motivated by the possibility to run the DOS from another DOS. This most notably includes the MicroSpartaDOS gameloader (which also sits at $700), to allow for convenient handling of combined disks with part of the contents running with the gameloader, and part with full DOS. Both are loaded in the mentioned way, allowing to switch between the loader and full DOS by running one from the another, and vice versa. - The handling of CAR and BASIC is more or less inherited from SpartaDOS, and somehow normal at the time. I would be very careful with pushing these to external commands, so that usage of BASIC doesn't get a pain. Especially CAR is a simple transfer-control operation, which I felt shouldn't depend on availability of system diskette, and shouldn't touch the contents of user RAM. - Labels in the original sources are horrible, not really something worth preserving. They are result of desperate attempts to fit the source into the limited text buffer of ATMAS II. After removal of comments, the labels were the only option to save a few characters... So they became rather cryptic. I relied on extra notes on paper (which might still exist, somewhere, but were not really extensive / self-documenting to be understood after all these years...) Have a nice day, and thanks for all the interest for BW-DOS... 11 1 Quote Link to comment Share on other sites More sharing options...
pirx Posted September 13, 2023 Share Posted September 13, 2023 (edited) @Jiří Bernášek hello! So glad to see you!!!!! I am also so happy that your exquisite work has been finally re-discovered @Pecus and me also worked on MicroSpartaDos: https://github.com/pkali/micro-sparta-dos We even made a utility to modify the config to easily add titles and different color schemes It must be somewhere.... swi Edited September 13, 2023 by pirx Quote Link to comment Share on other sites More sharing options...
Jiří Bernášek Posted September 14, 2023 Share Posted September 14, 2023 Oh, oh... There's also the question of allocation pointers and performance, which gave me several sleepless nights back in the 90's - and another few sleepless hours today. I should avoid it to keep my health (and family) intact! But anyway, I seem able to remember and summarize the options and motivation for now: There are three concerns involved (in the order of importance at the time of BW-DOS creation): - Code size. The "1/16" rule is the most simple option. - Performance on disk reads, which are most frequent operations. With classic Atari floppies, this requires minimal fragmentation of files, and (even more) directories, or else all the head movements take ages to complete (again and again, as the disk is read repeatedly). - Performance on writes, where searches over large VTOC portions are slow (as observed earlier in this thread). This was not much of a concern back in the 90's, with classic floppies dominating the scene, making typical VTOC short and physical disk access waaay slower than any operation inside the DOS. Harddisks and emulators change the relevance a lot (that's sure), but still, write delays are one-off and less frequent, if compared to read delays. SpartaDOS was optimized in two ways: VTOC searches were both byte-oriented and bit-oriented, saving time at the cost of extra code, and introduction of the allocation-pointers (mostly) saved repeated searches over occupied parts of the disk. BW-DOS was optimized differently, leaving VTOC searches only just bit-oriented (slower, but saves code length), and attempting to remove the weakness of SpartaDOS on file/directory deletions - which is the main question to discuss here. The idea behind allocation pointers is to remember where to continue searching next time, and also to separate files from directories, avoiding directory fragmentation. It works fine on newly formatted disks and through simple writes, but problems arise on deletions. The pointers are handled at sector level. Introducing a file context would be problematic (or expensive in terms of code length - the process may get aborted just anywhere due to an error). So, while deleting a *sector*, we have a decent number of options, how to update the pointers: - Do nothing. Writes go smoothly, but without recycling space from deletions, so they quickly wrap around, down to the directory area. From that moment on, any additions to directories get fragmented. - Always update with the number of deleted sector. This would leave the pointer at the last sector of deleted file. Newly written file uses only one sector in the old place, so this option combine all the bad outcomes together: Old file not preserved for undeletion, new file fragmented, long VTOC search performed after first sector written, wrap-around down to directory area earlier than needed. - Set the pointer to the first sector of the deleted file (also mentioned here, earlier). Yes, this is good (new file goes where the old one was) - but how to do it, exactly? To preserve the file/directory separation whenever possible, the strategy is as follows: Update the pointers only downwards (to catch just the first sector in terms of both file and VTOC order), values over the current directory-allocation pointer are file-sectors (updating file-pointer), values under are directory-sectors. - This is how Sparta is doing it (as far as I remember, feel free to correct me!), and it looks fine, but there are serious problems with deletions down in the directory area. Try to format a fresh disk with SpartaDOS, create one subdirectory, then say "oh, that was a mistake", and remove that subdirectory again. Now examine the pointers: They are both together at the bottom of the disk, just ready to fragment and mix your directories and files all together, before you even started to write your first file! Not nice. - What really happened: On deletion of the first sector of your subdirectory, Sparta found it to be below directory-allocation pointer, and (correctly) updated that pointer down. On deletion of the second sector, however, the number was higher than the (new) value in the pointer, so the sector was considered to be a file, thus updating the file-pointer to a value just after the directory-pointer. The file/directory separation is now gone (the same happens when files wrap around to the directory area on a full disk, and are then deleted). - Important point: There's no mechanism to restore the file/directory separation. You may delete and rewrite all your files and directories a million times (with Sparta), yet the pointers have no tendency to settle back to where they started on a freshly formatted disk. Once the disk gets fragmented for whatever reason, it never fix itself. - So, this is where I came with the "1/16" rule. Reset of the pointers to a fixed value creates the desired tendency towards properly file/directory separated structure, which catches on once there's some free space in the appropriate disk regions. But, of course, this is done at the expense of VTOC searching time in the other case. It might be fair to call it "abuse" of the VTOC search on first write, to complete the recovery from deletions, but it works (also with Sparta) with no extra code needed. This (and no further) is where I got in the 90's, before I got too tired with the project (and until there were no reasons to release updates). - Thinking of it now, the best solution might be a combination of both strategies: Update both the pointers to the number of deleted sector, only downwards. Avoid updating the file pointer, when the number would go below the "1/16" rule. This includes both the Sparta's optimization, and also the tendency towards recovery of the file/directory separation. BUT - it costs extra code... OK, that's all for now... I hope to forget it, in order to sleep in the nights again (Hi, Pirx, nice to see you, too!) 4 1 Quote Link to comment Share on other sites More sharing options...
janzh Posted September 18, 2023 Share Posted September 18, 2023 Nice to read from you again, Jiri. Welcome back! @Jiří Bernášek Yes, this hobby can be very time consuming and you have to take care of yourself. I do it time boxed and I am listen to my wife The strategy of sector allocation with minimum performance and memory is always a compromise. I am quite satisfied with the current one. It works now for several month and I could not see any issues. I always keep an eye on the VTOC of my working drive. It is a 4MB harddisk partition. I did an update: added executables BWDOS14.EXE and BWDOS14H.EXE (including HISIO driver by Hias), they can be used to start BW-DOS from cartridges like The!Cart, AVG, Uno etc. RAMDISK:SYS now supports ICD Rambo 256k (main banks are ignored now @Ricky Spanish) and Axlon extensions, if your computer is equipped with both PORTB and Axlon then you can install one ramdisk for each add banking file R256D208.BNK for RAMDISK.SYS, it is for the ICD Rambo 256k with main banking, it contains all extra banks plus the main bank RAM under the OS ROM (you could go further and use the main bank $8000-$BFFF if you work with a 16k cartridge like Atari Loge or Microsoft Basic 2) MEM now shows correct values for Newell 256k PORTB and Antonia 4MB Axlon MEM now supports a file option to store the current valid PORTB values in the format for RMADIASK.SYS, this file can be used as a starting point to edit with CUT or HEXEDIT. Added HISO driver by Hias @HiassofT For details see: https://github.com/HolgerJanz/BW-DOS/blob/main/BW-DOS 1.4.pdf https://github.com/HolgerJanz/BW-DOS/blob/main/BW-DOS 1.4.atr Like @dmsc always writes: Have fun! 1 1 Quote Link to comment Share on other sites More sharing options...
dmsc Posted September 18, 2023 Share Posted September 18, 2023 Hi @Jiří Bernášek, nice to hear from you!! It is great to learn about your reasoning on the update of the file/dir allocation pointers, it certainly makes a lot of sense for the standard disks back in the day. I think that today, most people uses flash based storage - with no seek times - so a simpler strategy (like the one Janz implemented) is better, as it is faster and a little smaller code-wise. I also have a fork of BW-DOS in my github, over at https://github.com/dmsc/bwdos-mads , I'm optimizing all the resident programs and utilities to minimize the RAM usage: - All the "low memory" utilities fit bellow $600 now, so you can use them to load and examine the page-6. - Many simpler utilities are at least one sector smaller, so they load faster. I see BW-DOS as the DOS of choice when generating new ATR images, as it is free and extremely capable, thank you very much for releasing it! Have Fun! Quote Link to comment Share on other sites More sharing options...
dmsc Posted September 18, 2023 Share Posted September 18, 2023 HI! On 9/13/2023 at 12:50 PM, Jiří Bernášek said: I don't have much time to look, but now I see that there's quite a lot of progress, which is great! I seem to remember a few things, which may be relevant to the previous discussion: - The motivation for "XOR $55" obfuscation in the binary files was not a "protection". Looking at the list, these are all resident drivers. Since they provide the option to uninstall (the OFF option), there are some checks for presence of installed resident code (I don't remember exact procedure and motivation, might also be an attempt to avoid installation of second copy), which include a memory search for the said code. Because of this, the binary file (possibly still partially present in disk buffers below MEMLO) shouldn't contain the same pattern, and so I decided to encrypt it. Yes, I discovered it while modifying the resident programs - I solved it by simply limiting the search for the installed program to an address higher than the disk buffers, but this is not a great solution, as different DOS could have the disk buffers in other places. Problem with the XOR is that assembling the programs is more difficult, needing an extra step. On 9/13/2023 at 12:50 PM, Jiří Bernášek said: - The motivation for clearing user RAM after boot-up is somehow inherited from Micro-SpartaDOS gameloader, to achieve the same (maximum) level of compatibility. While testing the gameloader on my game collection, including rather obscure items inherited from boot-tape versions of the 80's, I observed several pieces not running well (or displaying garbage) if not loaded into a clean RAM. I believe that this requirement was more of a bug, not revealed due to the nature of tape-boot process (always into clean RAM), but it doesn't really hurt to have the maximum compatibility at least for the first application after boot-up (typical case, if one just want to run a game). It doesn't cost RAM, since the initialization code is just temporary. - Loading the DOS code to upper RAM and then copying to $700 is indeed motivated by the possibility to run the DOS from another DOS. This most notably includes the MicroSpartaDOS gameloader (which also sits at $700), to allow for convenient handling of combined disks with part of the contents running with the gameloader, and part with full DOS. Both are loaded in the mentioned way, allowing to switch between the loader and full DOS by running one from the another, and vice versa. I keept this copying exactly for this reason - it is very useful to be able to load the DOS from another DOS. On 9/13/2023 at 12:50 PM, Jiří Bernášek said: - The handling of CAR and BASIC is more or less inherited from SpartaDOS, and somehow normal at the time. I would be very careful with pushing these to external commands, so that usage of BASIC doesn't get a pain. Especially CAR is a simple transfer-control operation, which I felt shouldn't depend on availability of system diskette, and shouldn't touch the contents of user RAM. In my fork, I optimized the commands a little, and I also think that having BASIC and CAR as resident commands is important. In my fork, MEMLO is already 3 bytes less than in the 1.3 version, this with the added "MAN" command that Janz implemented. On 9/13/2023 at 12:50 PM, Jiří Bernášek said: - Labels in the original sources are horrible, not really something worth preserving. They are result of desperate attempts to fit the source into the limited text buffer of ATMAS II. After removal of comments, the labels were the only option to save a few characters... So they became rather cryptic. I relied on extra notes on paper (which might still exist, somewhere, but were not really extensive / self-documenting to be understood after all these years...) I don't find the labels that hard to understand - in fact they are a lot better than the tipical "L***" labels in disassembled sources 😛 On 9/13/2023 at 12:50 PM, Jiří Bernášek said: Have a nice day, and thanks for all the interest for BW-DOS... Thank you again for releasing it back in the day, and releasing the source now. I have only one request - can you clarify the license of the released sources? Have Fun! Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted September 18, 2023 Share Posted September 18, 2023 Nice, Hi Jiri! ok. Just off topic… did you release your intros/demos, too, with source? i am looking for the Abbuc intro with the 3d scroller and the one which had procedural generated music 🙂. Sorry don’t want to go off topic here Quote Link to comment Share on other sites More sharing options...
Jiří Bernášek Posted September 18, 2023 Share Posted September 18, 2023 4 hours ago, dmsc said: I have only one request - can you clarify the license of the released sources? It's free for everyone... I used to keep the sources for myself back in the 90's, due to bad experience with quality of third-party modifications, but now I'm over 20 years out of Atari scene, so I see them as abandoned. I also believe that (almost) 30 years old computer software is somehow "prehistoric", making any restrictions pointless. If you want some formal statement - well, I'll try: "I'm Jiří Bernášek, the only author of all Atari 8-bit software signed BEWESOFT, including BW-DOS up to version 1.30, and I release it all to the Public Domain, including sources where available. There might be issues with the game Midnight, released in 1993 by Mirage software, Poland. Otherwise, I'm not aware of any further legal limitations." I hope it makes sense, I'm not a lawyer... 3 hours ago, Heaven/TQA said: Just off topic… did you release your intros/demos, too, with source? i am looking for the Abbuc intro with the 3d scroller and the one which had procedural generated music 🙂. I didn't release these sources yet, but I have no problem to do so. Technical part is a different question, though: They still exist (mostly) on Atari Floppies, in a place where I don't live anymore, and SIO2PC link doesn't work anymore due to changes on PC side. My current time budget doesn't allow me to solve this, so I never proceeded to transfer more of my sources, beyond the most important part. 4 Quote Link to comment Share on other sites More sharing options...
Mathy Posted September 18, 2023 Share Posted September 18, 2023 (edited) Hello Jiří 2 hours ago, Jiří Bernášek said: ... I'll try: "I'm Jiří Bernášek, the only author of all Atari 8-bit software signed BEWESOFT, including BW-DOS up to version 1.30, and I release it all to the Public Domain, including sources where available. There might be issues with the game Midnight, released in 1993 by Mirage software, Poland. Otherwise, I'm not aware of any further legal limitations." Thank you very much! 2 hours ago, Jiří Bernášek said: I didn't release these sources yet, but I have no problem to do so. Technical part is a different question, though: They still exist (mostly) on Atari Floppies, in a place where I don't live anymore, and SIO2PC link doesn't work anymore due to changes on PC side. My current time budget doesn't allow me to solve this, so I never proceeded to transfer more of my sources, beyond the most important part. The Atari 8 bit scene is still quite active in the Czech Republic. I'm sure we can find somebody to help with that or even take the task off your hands if you like. Sincerely Mathy Edited September 18, 2023 by Mathy Quote Link to comment Share on other sites More sharing options...
janzh Posted September 19, 2023 Share Posted September 19, 2023 (edited) 13 hours ago, dmsc said: HI! On 9/13/2023 at 5:50 PM, Jiří Bernášek said: I don't have much time to look, but now I see that there's quite a lot of progress, which is great! I seem to remember a few things, which may be relevant to the previous discussion: - The motivation for "XOR $55" obfuscation in the binary files was not a "protection". Looking at the list, these are all resident drivers. Since they provide the option to uninstall (the OFF option), there are some checks for presence of installed resident code (I don't remember exact procedure and motivation, might also be an attempt to avoid installation of second copy), which include a memory search for the said code. Because of this, the binary file (possibly still partially present in disk buffers below MEMLO) shouldn't contain the same pattern, and so I decided to encrypt it. Yes, I discovered it while modifying the resident programs - I solved it by simply limiting the search for the installed program to an address higher than the disk buffers, but this is not a great solution, as different DOS could have the disk buffers in other places. Problem with the XOR is that assembling the programs is more difficult, needing an extra step. In BW-DOS you can use start-up-MEMLO: BW-DOS 1.3 BW_SMEMLO = COMTAB+30 (BW-DOS 1.4 = $744). It contains MEMLO at boot time. You just have to search between BW_SMEMLO and MEMLO. Example see sources of RAMDISK.SYS. Edited September 19, 2023 by janzh 1 Quote Link to comment Share on other sites More sharing options...
Ricky Spanish Posted September 22, 2023 Author Share Posted September 22, 2023 On 9/18/2023 at 10:14 AM, janzh said: RAMDISK:SYS now supports ICD Rambo 256k (main banks are ignored now @Ricky Spanish) and Axlon extensions, if your computer is equipped with both PORTB and Axlon then you can install one ramdisk for each Excellent ! I'll try it out, & many thanks ! Quote Link to comment Share on other sites More sharing options...
Ricky Spanish Posted November 21, 2023 Author Share Posted November 21, 2023 Hello, hope you had a good summer ! Any updates ? I'm really enjoying this DOS. Especially the last update ! Thanks ! Quote Link to comment Share on other sites More sharing options...
janzh Posted November 21, 2023 Share Posted November 21, 2023 The last time I worked on FastAssembler updates. https://github.com/HolgerJanz/FastAssembler Last BW-DOS 1.4 updates including FastAssembler (See https://github.com/HolgerJanz/BW-DOS/commits/main) : - MEM * bug fix for Newell RAMBO 256k and Antonia 4MB Axlon mode * shows now both PORTB and Axlon (yes, there are machines that have both) * can save PORTB values to file for RAMDISK.SYS (file can be edited with HEXEDIT e.g. to remove banks) - RAMDISK.SYS supports PORTB and Axlon - new added High SIO tool HISIOK.SYS by Hias - new executables BWDOS14.EXE and BWDOS14H.EXE (with HISIOK.SYS) for cartridges like AVG, Uno, The!Cart, Side3 etc. - new version of FastAssembler 1.8 16-11-2023 You can check the GitHub repository for updates in the future. Furthermore I converted the XL OS Rev. 2 sources to FastAssembler: https://github.com/HolgerJanz/FastAssemblerAtariXLOS So FastAssembler on an Atari now can assemble itself, the OS, and BW-DOS. Regards Holger 4 1 Quote Link to comment Share on other sites More sharing options...
pirx Posted November 21, 2023 Share Posted November 21, 2023 On 9/18/2023 at 4:43 PM, Jiří Bernášek said: I release it all to the Public Domain, including sources where available. There might be issues with the game Midnight, released in 1993 by Mirage software, Poland. Just to clarify - MiraGE released all their 8-bit and 16-bit games to the Public Domain, so Midnight is free as well! 1 Quote Link to comment Share on other sites More sharing options...
pirx Posted January 26 Share Posted January 26 BUMP! And a question - is there a way to open a file from the current directory? e.g. I have file "CHIP8.CFG" in drive D8: I am in drive D8: When doing `OPEN #1,4,0,"D:CHIP8.CFG"` Bewe wants to read file `"D1:CHIP8.CFG"` as far as I understand in SDX "D:" works as a current path thing, maybe there is no such concept in Bewe? Quote Link to comment Share on other sites More sharing options...
janzh Posted January 27 Share Posted January 27 Only the command processor of BW-DOS has the concept of current drive. All CIO calls use 1 if no drive number was provided. The current drive of the command processor in the format Dx:<EOL> can be found at $7A6. So you can get the current drive from $7A7 with PEEK(1959). This only works from version 1.4 of BW-DOS. 1 1 Quote Link to comment Share on other sites More sharing options...
pirx Posted January 28 Share Posted January 28 (edited) I have a problem with BW-DOS from this address: https://github.com/dmsc/bwdos-mads @dmsc Everything works nicely, but when I format a new disk with DOS initialization it does not boot. I thought I was doing something wrong, but I did the same thing with BW-DOS 1.30 from atarionline and it works perfectly. BOOT command does not work for me as well. (all on Altirra) Edited January 28 by pirx Quote Link to comment Share on other sites More sharing options...
dmsc Posted January 28 Share Posted January 28 Hi! 33 minutes ago, pirx said: I have a problem with BW-DOS from this address: https://github.com/dmsc/bwdos-mads @dmsc Everything works nicely, but when I format a new disk with DOS initialization it does not boot. I thought I was doing something wrong, but I did the same thing with BW-DOS 1.30 from atarionline and it works perfectly. BOOT command does not work for me as well. (all on Altirra) The problem is the last commit: I lowered the load address to allow booting on 16K machines, but I forgot to change the boot code included in the FORMAT command, and it now loads over the boot sector code. The reason the original image works is that MKATR uses a different boot loader that resides in low memory. I will fix it ASAP. Have Fun! 1 Quote Link to comment Share on other sites More sharing options...
dmsc Posted January 28 Share Posted January 28 Hi again! 1 hour ago, pirx said: I have a problem with BW-DOS from this address: https://github.com/dmsc/bwdos-mads @dmsc Everything works nicely, but when I format a new disk with DOS initialization it does not boot. I thought I was doing something wrong, but I did the same thing with BW-DOS 1.30 from atarionline and it works perfectly. BOOT command does not work for me as well. (all on Altirra) Ok, fixed now, but I should rewrite the FORMAT command completely at some point, replacing the old boot loader with something smaller. The problem is that the boot code should be capable of loading current BW-DOS (at $2300) and old one (at $36E0), so the current location will only boot the new BW-DOS. Currently I put the BOOT code at $3E00, this will not work with old BW-DOS. I will probably rearrange things a little. Have Fun! 2 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.