ENTERPRISE KLUB
2019. május 25., 1055 Budapest, Nyugati tér 9. 14-19 óráig
Részletek
Welcome, Guest. Please login or register.


Author Topic: EP128emu (Read 155270 times)

Offline IstvanV

  • EP addict
  • *
  • Posts: 4806
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 58.0 Firefox 58.0
    • View Profile
Re: EP128emu
« Reply #1260 on: 2019.March.21. 11:20:13 »
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.
« Last Edit: 2019.March.21. 11:39:51 by IstvanV »

Offline BruceTanner

  • EP user
  • *
  • Posts: 482
  • Country: gb
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 65.0 Firefox 65.0
    • View Profile
Re: EP128emu
« Reply #1261 on: 2019.March.21. 12:11:27 »
I would guess the extra byte is a ctrl-Z?

If :copy source is an EXOS device and the dest is also an EXOS device, it works in ASCII mode: one byte at a time, up to the first ^Z read from the source and with a ^Z added to the destination.

The exact behaviour is quite complicated, see COPY.HLP in the IS-DOS /HELP directory!

So I think you might have a different cause of being slow!

Offline IstvanV

  • EP addict
  • *
  • Posts: 4806
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 58.0 Firefox 58.0
    • View Profile
Re: EP128emu
« Reply #1262 on: 2019.March.21. 12:16:32 »
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.

Offline BruceTanner

  • EP user
  • *
  • Posts: 482
  • Country: gb
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 65.0 Firefox 65.0
    • View Profile
Re: EP128emu
« Reply #1263 on: 2019.March.21. 16:17:07 »
Thank you, the RDY fix seems to work now - old EXDOS/ep128emu is slow, old EXDOS/new ep128emu is much quicker :ds_icon_cheesygrin:. 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 :ds_icon_cheesygrin:. 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" :shock: :lol: :mrgreen:

Offline gflorez

  • EP addict
  • *
  • Posts: 2556
  • Country: es
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 65.0 Firefox 65.0
    • View Profile
Re: EP128emu
« Reply #1264 on: 2019.March.21. 17:34:22 »
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.

Online Zozosoft

  • EP addict
  • *
  • Posts: 13332
  • Country: hu
  • OS:
  • Windows NT 10.0 Windows NT 10.0
  • Browser:
  • Firefox 66.0 Firefox 66.0
    • View Profile
    • http://enterprise.iko.hu/
Re: EP128emu
« Reply #1265 on: 2019.March.21. 19:25:43 »
Teszt céljára Windows csomag az eddigi javításokkal:
Köszi!

Offline BruceTanner

  • EP user
  • *
  • Posts: 482
  • Country: gb
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 65.0 Firefox 65.0
    • View Profile
Re: EP128emu
« Reply #1266 on: 2019.March.21. 22:51:49 »
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 :lol: 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 :evil: :lol: :mrgreen:

Offline gflorez

  • EP addict
  • *
  • Posts: 2556
  • Country: es
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 65.0 Firefox 65.0
    • View Profile
Re: EP128emu
« Reply #1267 on: 2019.March.22. 10:10:13 »
Of course I didn't know!

One more obscure chapter on the Microsoft dirty story. The most known one is the spoil of CP/M from Digital Research.

Offline IstvanV

  • EP addict
  • *
  • Posts: 4806
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 58.0 Firefox 58.0
    • View Profile
Re: EP128emu
« Reply #1268 on: 2019.April.17. 12:14:55 »
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?

Online Zozosoft

  • EP addict
  • *
  • Posts: 13332
  • Country: hu
  • OS:
  • Windows NT 10.0 Windows NT 10.0
  • Browser:
  • Firefox 66.0 Firefox 66.0
    • View Profile
    • http://enterprise.iko.hu/
Re: EP128emu
« Reply #1269 on: 2019.April.17. 13:05:18 »
Ez a verzió kiadható a GitHub-on, vagy van még javítandó hiba?
Szerintem mehet.

Offline IstvanV

  • EP addict
  • *
  • Posts: 4806
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 58.0 Firefox 58.0
    • View Profile
Re: EP128emu
« Reply #1270 on: 2019.April.17. 23:53:54 »
« Last Edit: 2019.April.19. 18:35:41 by IstvanV »

Online Zozosoft

  • EP addict
  • *
  • Posts: 13332
  • Country: hu
  • OS:
  • Windows NT 10.0 Windows NT 10.0
  • Browser:
  • Firefox 66.0 Firefox 66.0
    • View Profile
    • http://enterprise.iko.hu/
Re: EP128emu
« Reply #1271 on: 2019.April.18. 07:19:47 »

Offline IstvanV

  • EP addict
  • *
  • Posts: 4806
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 58.0 Firefox 58.0
    • View Profile
Re: EP128emu
« Reply #1272 on: 2019.April.18. 11:38:21 »
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.

Offline BruceTanner

  • EP user
  • *
  • Posts: 482
  • Country: gb
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 66.0 Firefox 66.0
    • View Profile
Re: EP128emu
« Reply #1273 on: 2019.April.18. 12:09:15 »
:smt041 Thank you! :ds_icon_cheesygrin:

Offline IstvanV

  • EP addict
  • *
  • Posts: 4806
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 58.0 Firefox 58.0
    • View Profile
Re: EP128emu
« Reply #1274 on: 2019.April.23. 13:53:33 »
Kész (nem beta) 2.0.11.2 verzió, a régebbi beta1 és beta2 csomagokat töröltem.