archive.worldofdragon.org

Hm! Good point

pser1 wrote:

Code: Select all

                  LDA             LDAF
Elisa 100 lines  12 sec          11 sec
Elisa 200 lines  24 sec          18 sec
Elisa 300 lines  39 sec          25 sec
Elisa 546 lines  93 sec (1m33s)  41 sec

In my case the Listing will be transfer as tokenized... I should test how long this takes...

as you will,
but I will never compare something that runs in the PC world to something that runs in our beloved Dragons at a bit less than 1MHz
The transmission time will be the same but the process time not, of course.
Just remember that XRoar has a keystroke with wich you can accelerate everything to full PC speed (so, not emulating the Dragon real hardware)

cheers
pere

Hello,

as I was developping the VLOAD dweeb, I decided to build it in two parts, because I wanted the very first one to be re-used when I could prepare other dweebs,
the VCOPY for instance that will allow the user to copy just one selected file from an VDK to a real floppy.
This implied that to use it, by now, you need to have the second part "TABLDR" located in the DW4 root, so that VLOAD can find and use it.

As time goes by and I still cannot begin with the VCOPY dweeb, I have decided to put the two old parts together in just one file for easy of use.
The name is VLOAD1 but you can rename it as you like.
It contains the code of both old parts and works the same way.
The TABLDR is no more needed (for this VLOAD1) but if you have something that relies in VLOAD, then keep it in the DW4 root folder anyway

cheers
pere

Hi all,

I have got my drivewire adaptor working now on a D64, all seems to behave as expected and have been playing with some of the very useful dweebs posted here.

Have encountered one of my disks though that VDIR doesn't want to process. It doesn't generate an error (either on the Dragon or the server) it just seems to yield an empty directory listing. The other images I've tried all work as expected so it's a little odd. I've resized the VDK header to the 256 byte boundary. If I get a chance I may take a closer look but it's the GAMESDISK2 image I posted in the zip file here: viewtopic.php?f=7&t=4980

Rgs,

jon

fridgemagnet wrote:Hi all,

I have got my drivewire adaptor working now on a D64, all seems to behave as expected and have been playing with some of the very useful dweebs posted here.

Have encountered one of my disks though that VDIR doesn't want to process. It doesn't generate an error (either on the Dragon or the server) it just seems to yield an empty directory listing. The other images I've tried all work as expected so it's a little odd. I've resized the VDK header to the 256 byte boundary. If I get a chance I may take a closer look but it's the GAMESDISK2 image I posted in the zip file here: viewtopic.php?f=7&t=4980

Rgs,

jon

Hello,

I am going to download this VDK and give it a peek with another tool (in Java) that shows the directory of DData disks
I will let you know, just give me some time.

cheers
pere

No rush, it was more just an observation...

Cheers,

jon

Hi,
using my Java app has given the very same error.
This is the app I just 'copied' when building the dweeb so it has inherited that error. Debugging the Java app I have found the reason why this has happened:
When a file needs more than one entry in the directory, usually it occupies another one in the very same directory sector (each sector acomodates for 10 dir entries)
That works for most of the disks, but sometimes, as with disk2, the extension doesn't fit in the same sector and it has to be calculated with data in byte 24.
I didn't do that, I just told the program to always use the very same sector, leading to array index overflows in Java in that case.

That said, I will look at how I implemented this in the dweeb and hopefully it will be easy to patch.

I had always worked with 180K disk, but I tested the dweeb with 360K and 720 as well. Obviously they were not fragmented enough to show that problem.

Thanks a lot for finding it out. As soon as I get it solved, I will upload the new version of the dweeb VDIR

cheers
pere

more on that question.

Your disk2 is really a perfect test to pass!
The game 3DSWARS.EXE is sooo fragmented that after having occupied the 4 normal extensions, it gets a whole directory entry (7 more extensions)
and besides these, it needs another two!
I am pleased to tell you that I had never worked with such a disk!
I have a parameter that shows the sectors occupied by each file (in Java and with the dweeb as well), and I have detected that the two final extents have been misunderstood
in Java, returning a nice free bytes value of -14,592
I have opened the VDK to see the hex values in the directory and this 'ugly' way I have found out the real numbers that both programs have missed.

A bit of extra work to correct first in Java and then look at the asm implementation.
Really a great test file!!

cheers
pere

well it wasn't by design I assure you however pleased I can help!

Hello,
Java works now flawlessly with the three disks, but ...
Inside that App I programmed a small function that compares the FAT against the directory entries and detects the sectors that have not the same status in both places.
The disk2 has this 'difference':
Sector 3 (numbered from 0 will be number 2) is used according to the FAT, but it is not used in any of the saved files!
This means the disk has lost 256 bytes, not a problem this kind of error. Some DOSes tend to show this behaviour.
The disk1 has the very same error in sector 3 too. What a coincidence!
The disk3 has this very same error in the same sector!, but besides it has another dangerous one:
Sector 289 (num 288 from 0) is free according to the FAT, but it is used in GAMEDIR.DAT
If you add a new file into that disk and the system decides to use that free sector, the new file will be OK, but the prior one using it will be corrupted. It's called 'crossed links'
So, in this case, it would be a good idea to copy all the files to another clean disk.
Hope to be able to correct the dweeb VDIR and upload it here as soon as possible.
Anyway I must have a look at VLOAD too, because the function reading the sectors needed to load a file are the same in the 'bad' VDIR, so it must be corrected too.

cheers
pere