BW-DOS v1.30

[Ricky Spanish]

Just an FYI: loads BASICXE.OSS (w/ BASIC XE cart) no problem. 

 

Also;

[DOS]

D:TIME

D:DATE

D:CLOCK ON

 

Works very well.

[+mytek]

Yeah I like this DOS as well, and use it for various projects 👍

[flashjazzcat]

U1MB users may avoid the 'TIME' and 'DATE' steps by installing the ULTD.SYS driver provided here:

 

https://atari8.co.uk/apt/toolkit/

 

[dmsc]

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!

 

[Ricky Spanish]

1 hour ago, dmsc said:

You can also test a modified version by @janzh, named "BW-DOS 1.4"

Very nice !

 

 

[Ricky Spanish]

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.

[Marius]

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.

[baktra]

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.

[flashjazzcat]

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.

[janzh]

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

[flashjazzcat]

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.

 

[janzh]

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

[pirx]

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

[janzh]

@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.

[flashjazzcat]

Amazing. The disassembly has more comments than the original source code.

 

[Creamhoven]

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.

[+Stephen]

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!

[Creamhoven]

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.

[janzh]

Tell or have been told that the different.

 Someone 

[Ricky Spanish]

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

[janzh]

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!

 

[Mathy]

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...

 

 

[janzh]

@Mathy I will try. Unfortunately I cannot attend this year because we are still on vacation this time.

[flashjazzcat]

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

[Ricky Spanish]

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.