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.

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

Teszt céljára Windows csomag az eddigi javításokkal:

Ez a verzió kiadható a GitHub-on, vagy van még javítandó hiba?

Feltöltöttem: https://github.com/istvan-v/ep128emu/releases/tag/2.0.11.2

Változások az előző verzióhoz képest:

• 11 szektor/sávos floppy formázás javítva.
• Floppy /RDY jel javítva, vagy legalábbis nincs hosszú várakozás a változására az EXDOS-ban.
• A debuggerben a töréspontoknál megjegyzések is használhatók, ; vagy # karakter után a sor további része figyelmen kívül marad.
• Ugyanitt SjASM .exp file formátum is támogatott lett, a "címke: EQU 0000xxxxh" az "xxxx" címre állít be töréspontot (a "h" után közvetlenül továbbra is használhatók paraméterek).
• Bár ezeket rajtam kívül valószínűleg nem használja senki, az epcompress kis mértékben hatékonyabb lett -m1, -m2, és -m4 formátumoknál -8 és magasabb szint használatakor, azonban lassabb is.

Kész (nem beta) 2.0.11.2 verzió, a régebbi beta1 és beta2 csomagokat töröltem.