DWEEBS - applications for DWLOAD - DriveWire

[fridgemagnet]

Interesting (and useful) stuff. All those disks were created with DOSPlus 4.9 which I think is one of the less bug free variants of DragonDOS but there may well have been a few quirks left in there.

I doubt those disks images will ever be written to again since I can't see me accumulating more games for the machine but thanks for the info anyway.

jon.

[pser1]

Hi Jon,
now that the Java app is working fine, I have tried to copy all of the files from dsk2 to a new blank one, just to see if the DOS really needs more that 10 extents for just a file despite it is the last one and so more prone to fragmentation.
Have tried with DDOS11C, DDOS12A, SDOSE6 and SDOSE8, all of them have failed! I must give DosPlus4.9 a try too.
I was copying the files with a Basic prog that first reads the directory and then makes the copies, but when reaching the MENU.BAS it returns with IV ERROR
Then I have written a small basic that asks for a name and makes the copy from D1 to D2
The very same has happened most of the times ... but the only time it worked, the DIR command has sohwn a wrong free bytes number, so the copy process had failed in some moment(s)
I have seen that some directory entries are longer than 36 sectors (seems to be the maximum for Dragon Data systems)

After the DosPlus experiment, I will take the VDIR source and try to debug it with GDB, hopefully I will find out the origin of the problem.
thanks a lot

cheers
pere

[pser1]

Hello Jon,

back again with more news!
You have converted me into an unconditional of DosPlus4.9 (maybe I will give a chance to v5.0 too)
I have copied all of the files from dsk2 to a new formatted one with the basic program and has worked OK
The free bytes number is now 17,920 as my Java app calculated (by looking at the FAT bits)
And much to my surprise this time sector 3 has been really used, so no differences between FAT and directory entries!
Unfortunately 3DSWARS now occupies 15 extents instead of the prior 13, so heavily fragmented too.
It is very difficult to avoid such situations when using more than 90% of the disc sectors.

cheers
pere

[fridgemagnet]

Hi Pere,

More interesting stuff there, I've always been quite impressed with the DosPLUS variant, my controller originally had 1.0, then a few years later I upgraded it and never looked back. It has some quite nice features (like the ability to write data files using file numbers eg. OPEN #1 instead of FREAD/FWRITE calls) and some nice extensions to the general BASIC environment. Plus as you've found, seems to work pretty well as a DOS!

Rgs,

Jon.

[pser1]

Hi Jon,
the dweeb had been corrected along development. But it had another flaw. Now it works OK as simple VDIR
But when using
DLOAD"VDIR"F"DISK/DiskName" using your Gamesdisk2 it ends abnormally.
Looking at the RAM used to build the text table, I have found a lot of spaces between files so it grows too much and gets into the ROM after
overwriting the stack.
I should have to trace with this parameter, too

I will wait untikll this part is corrected too and then I will upload the new VDIR version

cheers
pere

[pser1]

well, finally the F (full) version works without problems.

Using the big disk has shown that when the first LSN for a file is more than 999 (4 digits), the text shifts to the right every line it happens ...

I attach:
- the corrected dweeb VDIR (same name, but different one)
- the source code (for asm6809)
- a text document with the results of DLOAD"APP/VDIR"F"DISK/GAMEDSK2" just to see the lot of entries that some files do occupy
specially the last one 3DSWARS.EXE

cheers
pere

EDIT: I have changed the VDIR.zip because it contained the compiled BIN instead of the dweeb (nx256 bytes long)

EDIT2: I have deleted the dweeb and the source code. Next message contains the very last version!

[pser1]

Hello,
once verified with a lot of disks, it seems it works OK.
So, I have decided to clean it up a little, then I had tested again and as it works flawlessly too, I send this new version.
I am going to delete the last version to avoid errors downloading ...

This is the final version of this dweeb, hopefully
I attach here the dweeb and the source code (for asm6809)

cheers
pere

[pser1]

Hi,

after modifying the dweeb VDIR so that it is able to work with big disks and with highly fragmented files, I have given a peek to the DLOAD and the more recent DLOAD1 dweebs.
They have a similar problem that shows up when the file occupies more than 11 extents.

I have corrected them and I am attaching here the dweebs and their source codes

cheers
pere

[pser1]

Hello,
Just a comment about the last modified dweebs.
I have kept both versions:
- VLOAD that uses TABLDR to do the final part of the task
- VLOAD1 that is a standalone dweeb

The very first one was developped to 'practice' on how to call DWLOAD from inside a ML program in order to load and execute another dweeb.
Once this worked, I forgot to melt the two parts into one ... but later I remembered that idea and created VLOAD1
So it seems better to use VLOAD1 whilst VLOAD-TABLDR are just programming examples ...

Finally we could say that any program inside a VDK image can be loaded / run-executed at will

Thanks to Jon for uploading the 720k disk full of programs till the point that the last one was so fragmented that it needed more that 11 segments!
This has helped debugging and correcting VDIR as well as the VLOAD variants

cheers
pere

[fridgemagnet]

marvellous stuff, I will grab the latest and see what else I can break...