AuthorTopic: EP128emu (Read 190554 times)

I made EXDOS look at RDY by copying files to a nearly-full disk. Current EXDOS is very inefficient allocating disk space on a nearly-full disk, so it takes a long time, and the motor turns off before the write.

In EXDOS 1.3/1.4 the code that looks at RDY goes:

I was able to reproduce the issue by copying a file with :COPY on a FAFO formatted 880K disk image where the block size is 1, it took minutes to copy 29 kilobytes of data. Interestingly, there is no problem on another image that is of a more standard 800K size and uses 2 sectors per block. But it seems more complicated than I thought, because even with the RDY change, :COPY is still very slow, and for some reason switches to copying the data one byte at a time with EXOS 5 and 7.

In the character based (slow) mode, :COPY also makes the output file one byte longer than the input.

Edit: the slowdown actually occurs when the default device is FILE:, and I add DISK: to the file names, it is not related to the image size.

The Git sources now include updated code for emulating RDY, and the "spin down" and writing delay timers have been made slightly longer as well. During the spin up and down periods, RDY is quickly toggled on and off, which is a hack, but it should work well with EXDOS.

Thank you, the RDY fix seems to work now - old EXDOS/ep128emu is slow, old EXDOS/new ep128emu is much quicker . This was doing the same thing I originally noticed the problem with: copy f:\help a:\, then :attr a:\*.* -r, then :del a:\*.* (f:\help is the directory containing the IS-DOS help files on SD card or IDE drive).

Also disk change is working . When it is enabled in EXDOS 3, I can do lots of :dir one after the other, and only the first one does a disk access, after that the sectors are buffered. Then remove and replace the disk image, and the next :dir accesses the disk because it has seen the disk change signal. Unfortunately I can't reproduce the original problem I saw (doing a similar thing) because that used a hacked version of EXDOS 1.3 that I no longer have (hacked enough to make disk change work, at least as much as it could in that version). So I'll say that problem has "gone away"

You are being very sharp with the 3.0 update.... Disk change was a feature I loved on the A500. When the system asks for a particular system directory\file inside a unique system disk, that signal allowed the OS to ask for the correct disk if the file is not found on the actually inserted disk. MS/DOS can't do it. It is blind to a disk change.

You are being very sharp with the 3.0 update.... Disk change was a feature I loved on the A500. When the system asks for a particular system directory\file inside a unique system disk, that signal allowed the OS to ask for the correct disk if the file is not found on the actually inserted disk. MS/DOS can't do it. It is blind to a disk change.

I don't know if this is the same thing - in EXDOS it is a performance thing. (It has always been n the code, but nobody knew how to enable it and it very quickly became outdated anyway as post-1985 disk drives introduced new variations.)

In EXDOS each disk has a random number (volume id) in the boot sector. When a file is open or a search is underway, EXDOS remembers the volume id, so that it can check that the correct disk is still there if the user has not done anything for a while (eg the disk light has gone off). But to do this it has to re-read the boot sector, which means stepping the floppy drive head back to the start track, reading the boot sector, and stepping the head back to where it was again. If EXDOS knows the disk has not changed, it does not have to do this.

Later MS-DOS and Windows boot sectors have a random number volume id too.

But I discovered something interesting recently: when EXDOS was finished, MSX-DOS 1 had been released (it didn't have sub-directories, that had only just arrived in MS-DOS 2). EXDOS put the string "VOL_ID" in the boot sector to indicate the random number is present. After IS went bankrupt in 1985, Robert Madge went to Japan to try and sell EXDOS as MSX-DOS 2, as it was compatible with MSX-DOS 1 but with sub-directories. He failed, as we now know, but a year or two later MSX-DOS 2 was released...and it had the string "VOL_ID" and a random number in the boot sector, just not quite at the same address! So Microsoft copied the EXDOS idea