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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - BruceTanner

Pages: [1] 2 3 4 5 6 7 8 ... 31
I did just try to reply to a SlashNet post elsewhere - but when posting I got kicked out - maybe got too carried away by attaching too much :D - Try again - may be just do a new post like JSP did once - to introduce myself.
I have found enterpriseforever.com very slow over last few days, sometimes to the point of my connection timing out, so don't take it personally :lol:

EP128Emu / Re: EP128emu
« on: 2019.April.18. 12:09:15 »
:smt041 Thank you! :ds_icon_cheesygrin:

Programozás / Re: Sjasm fejlesztése
« on: 2019.April.05. 14:51:10 »
As we're on the subject :mrgreen: ...what would be really nice :mrgreen:  ...is if ep128emu could read in a symbol table file from sjasm or M80, and then whenever the disassembler window prints an address, attempt to look up the address in the symbol table and print the symbol instead. It won't get it right all the time but it is very useful when it does! :twisted:

Hall of Fame / Re: Q&A with Bruce Tanner (IS-BASIC writer)
« on: 2019.March.25. 14:59:29 »
Are the source codes downloadable anywhere?
Not yet, they are a mess of files from various programs all mixed together, so not really usable currently. A long-term project for Zozo...

Hall of Fame / Re: Q&A with Bruce Tanner (IS-BASIC writer)
« on: 2019.March.23. 14:05:57 »
They were among the source code fileds Zozo got from Werner.

Hall of Fame / Re: Q&A with Bruce Tanner (IS-BASIC writer)
« on: 2019.March.22. 11:42:12 »
This is new piece of the story :-)
I thought I had mentioned this before somewhere :oops:. It was only recently that I realised what had gone on!

There is reletad IS WordStar document file, dated 1985.08.21:
Yes that looks very much like it was written (by MRL) to prepare for Robert Madge's Japan trip!

There are other Wordstar documents about possible enhancements to IS-DOS, talking about enhanced batch file commands and even possible multi-tasking. I think they were all part of the same trip!

EP128Emu / Re: EP128emu
« 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:

EP128Emu / Re: EP128emu
« 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:

EP128Emu / Re: EP128emu
« 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!

EP128Emu / Re: EP128emu
« on: 2019.March.20. 23:26:11 »
it would work if I set RDY to 0 only when the motor is at full speed and there is a disk image opened, and 1 at any other time? Because of the LED display, there is already a timer that simulates spinning down, so it is not difficult to add a spin up period as well, but it would only affect RDY.
Yes that sounds perfect.

In theory, ep_fdd.cpp sets the disk change flag at line 269 whenever an image file is opened or closed, but maybe this is buggy for some reason?
Yes I agree that looks right! I will see if I can reproduce my original problem, maybe it was an EXDOS problem after all.

EP128Emu / Re: EP128emu
« on: 2019.March.20. 17:16:30 »
minél nagyobb a szám, annál jobb a szoftver :mrgreen:

EP128Emu / Re: EP128emu
« on: 2019.March.20. 16:29:56 »
I have changed track writing in the Git source code, FAFO seems to work now with 11 sectors per track.
These are the first few sectors in "11a" mode:
:ds_icon_cheesygrin: Thank you!

On the RDY and disk change signals, how are these expected to work exactly? I also tried to find where the EXDOS ROM is checking RDY, but I could not find it anywhere during simple usage like :DIR or saving a small BASIC program.
Disk change: it is working in ep128emu, all that is missing is to set it when a the disk image is changed. in ep128vm.cpp it is initialized during cold reset
Code: [Select]
      if (isColdReset)
and it is reset at the right time
Code: [Select]
      if (value & 0x40)
but it is never set from anywhere else - just need to set it when a new disk image is set so the z80 code knows there is a new disk.

RDY: it is difficult to make EXDOS use it! Probably why nobody has noticed it before!

When the motor is OFF and a WD command is given, the WD turns the motor on. It will take some time for the motor to get up to the correct speed. On read operations, EXDOS does not wait for the motor to speed up, it just keeps re-trying the read until it works. But on write operations it must wait for motor to spin up to speed before writing data, and it does this by looking at RDY.

But most of the time for write operations the motor will already be on because it will have been reading FATs and directories, so it does not need to wait. But if it *does* need to wait, it looks at RDY. Current EXDOS versions waits for it to change state but I think that might be a bug, it should just look for it to go low. This would work with ep128emu because ep128emu always says RDY.

RDY is set by a real drive when it has counted 6 disk rotations. The WD can do that instead and the new EXODOS 3 uses this so that it does not need to look at RDY (newer PC style drives do not even have a RDY signal).

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:
Code: [Select]
BIT 7,E ;Test if motor on delay is needed
JR NZ,NO_MOT ;If not then skip.
SET 7,E ;If it is then set motor on flag
SET 3,C ;Get current state of /RDY signal
IN B,(C) ; in order to test for a change.
LD HL,0E935h ; (E935h*67)/4 = 1000000us = 1s 
MOT_LP: IN A,(C) ;14T
XOR B ;5 T Test if /RDY line has changed
JR NC,NO_RDY ;13T Skip if not
IN B,(C) ; Get new /RDY state
LD A,00CH ; If timeout is more than 50ms
CP H ;   from its epiry then set it to
JR NC,NO_RDY ;   50 ms, otherwise leave it alone.
NO_RDY: DEC HL ;7 T Decrement timeout count
LD A,H ;5 T
OR L ;5 T
JR NZ,MOT_LP  ;13T Loop 'til expired.  67T per loop
NO_MOT: CODE LXI H ;Skip the next instruction.
NO_DLY: RES 2,E ;For read sectors and verfiy sectors,
; clear "settle delay" flag.
LD (IY+DELAY_FLAGS##),E ;Store new delay flags.

To emulate a real drive, it would have to go Not Ready when the motor goes off, and Ready *some time* after the motor is turned on by a WD command (in EXDOS this will be a seek command before the write). On a real drive *some time* is up to about 1s but usually a few 100 ms.

But nobody else has noticed this, and EXDOS 3 will not use RDY, so probably not worth spending a long time on this unless you particularly want to make the emulation more accurate.


EP128Emu / Re: EP128emu
« on: 2019.March.20. 14:07:23 »
My FAFO still using it at all formats except the 11/22 sectors.
Can it show the track pattern, gaps etc? It would be interesting to see!

i'm also :-) And at the beginnig used a 8 sectors format! Only at version 2.0 added the 9 sectors format. Probably because the first PCs have a belt driven drives, which need a more speed tolerance?
And the 5 1/4" formats grew from 8" formats, which had to work with even older 1970s technology. I don't know what the IAM is for - it tells you where the start of the track is, but there is a little hole in the disk for that! I thought maybe that came from 8" disks too.

EP128Emu / Re: EP128emu
« on: 2019.March.20. 12:42:30 »
Thanks Zozo, I wasn't 100% sure - the 10 (and 11) sector formats do not have the Index Address Mark field. The WD177x doesn't need this according to the datasheet but I read something somewhere which suggested the IBM PC floppy controller might need it. Maybe that was just the original IBM PC? Or maybe just bad info? The rest of the 10 sector format is in-spec and very similar to the 9 sector format so I wonder why IBM/MS did not use the 10 sector format in the beginning, and get bigger floppys?

EP128Emu / Re: EP128emu
« on: 2019.March.20. 10:35:33 »
(Please excuse English in Hungarian forum)

11 sector format: to fit 11 sectors on a track, it is necessary to make the gap between sectors very small. In fact smaller than the WD177x datasheet says in the minimum :oops:. But it seems to work! But I can see in the ep128emu source code (wd177x.cpp, WD177x::writeDataRegister() )  that it checks for a minimum gap size. These are my notes on track formats (will need fixed-spaced font and 80 columns to display properly):
Code: [Select]
; *********************************
; Disk spins at 300rpm = 5rps.
; Data rate is 250kb/s = 31,250 bytes/s.
; 31,250/5 = 6250 bytes/track
; (padding added to 6500 to allow for tolerances in disk speed).
; 9 sector format has an Index Address Mark (IAM) for PC compatibility but the
; WD177x doesn't need that for operation. So the PC-incompatible 10 and 11
; sector formats do not have this feature on the track to save track space for
; the extra sector(s).
; ==============
; datasheet       9       10       11
; miniumum  sectors  sectors  sectors GAP    Description
; --------  -------  -------  ------  ------ ---------------
; TRACK HEAD:                 
;    32x4Eh  60x4Eh   60x4Eh  !10x4Eh Gap 1a Index postamble         \
;                                                |
;            12x00h                                                   |
;             3xC2h                          IAM preamble             |
;               FCh                          IAM                       > HEAD
;            60x4Eh                   Gap 1b IAM postamble            |
;           ---       --       --                                     |
;           136       60       10            BYTES IN TRACK HEAD     /
; EACH SECTOR:                                               
;     8x00h+ 12x00h+  12x00h+ ! 3x00h+                       \       \
;     3xA1h   3xA1h    3xA1h    3xA1h Gap 2  ID preamble      |       |
;               FEh      FEh      FEh        ID Mark          |       |
;             1xTRA    1xTRA    1xTRA          Track #        |       |
;             1xSID    1xSID    1xSID          Side #          > ADDR |
;             1xSEC    1xSEC    1xSEC          Sector #       |       |
;             1xLEN    1xLEN    1xLEN          Length #       |       |         
;             2xCRC    2xCRC    2xCRC                         |       | 
;    22x4Eh  22x4Eh   22x4Eh   22x4Eh Gap 3a ID postamble    /         > SECTOR
;    12x00h+ 12x00h+  12x00h+  12x00h+                       \        |    x n
;     3xA1h   3xA1h    3xA1h    3xA1h Gap 3b Data preamble    |       |
;               FBh      FBh      FBh        Data Mark        |       |
;           512xDAT  512xDAT  512xDAT          User data       > DATA |
;             2xCRC    2xCRC    2xCRC                         |       |
;    24x4Eh  84x4Eh   40x4Eh  ! 1x4Eh Gap 4  Data postamble  /        |
;           ---      ---       ---                                    |
;           658      614       566           BYTES PER SECTOR        /
; TRACK TAIL:                                           
;    16x4Eh 192x4Eh   50x4Eh  !14x4Eh Gap 5  Index preamble          \
;           ---      ---        --                                     > TAIL
;           192       50       14            BYTES IN TRACK TAIL     /
;                             ^
;                             ! = EXCEEDS DATASHEET MINIMUM !
;           136+      60+       10+
;         9*658+  10*614+   11*566+
;           192       50        14
;         =====     ====      ====
;          6250     6250      6250            BYTES ON DISK
;           136+      60+       10+
;         9*656+  10*612+   11*564+
;           192       50        14
;         =====     ====      ====
;          6232     6230      6228            BYTES IN BUFFER
;                                             different because CRC is 2 bytes
;                                             on disk but 1 byte (F7) in buffer
; Padding   250x4Eh  250x4Eh   250x4Eh
;            18x4Eh   20x4Eh    22x4Eh
;         =====     ====      ====
;          6500     6500      6500            BYTES IN BUFFER TOTAL
; The extra padding to bring the size up to 6500 is to allow for variation in
; disk speed - bytes from the padding will be written as long as the WD177x is
; requesting more bytes.
; So the differences between the images are:
; 11 sector format has a smaller Gap1a Index Preamble
; 9 sector format has the IAM and pre- and post-amble
; 11 sector format has a smaller Gap 2 ID Preamble
; all formats have a different Gap 4 Data Postamble
; All formats have a different Gap 5 Index Preamble

Sector interleaving: I have not tried it yet (work in progress!) so it might work anyway! Explanation: the gap between sectors with the 11 sector format is very small. If you are reading more than one sector, by the time you read the second sector it has already passed the head, so the WD177x has to wait for another disk revolution. This makes it slow. So to avoid this, on the 11 sector format, interleaving is used - instead of the obvious sector order of 1,2,3,4,5,6,7,8,9,10,11, the 11-sector format uses something like 1,7,2,8,3,9,4,10,5,11,6. Maybe it will work anyway in ep128emu, maybe not, I just thought I'd mention it...

Disk change: ep128emu provides the disk change signal initially, and the z80 can reset it. This all works, but if the "disk" is changed through the menus, it needs to set the disk change signal again.

/RDY problem: EXDOS 3 does not use /RDY so now avoids the problem! But it is a difference from real hardware. I was able to make EXDOS <= 1.4 show the problem: copy lots of files to A: (I used the IS-DOS help files \HELP\*.HLP) and then delete them all - it takes a long time. This is because the "motor" turns off, so the EXDOS notices this, and waits for /RDY to change state (ie back up to speed) with a 1s timeout, but in ep128emu /RDY is constant (last line of Ep128VM::exdosPortReadCallback() in ep128vm.cpp). You could say this is a bug in EXDOS waiting for /RDY to *change* rather than waiting for /RDY to be *low*, but it is a difference between ep128emu and real hardware.

But nobody else seems to have noticed the /RDY problem and EXDOS 3 does not use /RDY so maybe not the most urgent fix!


Pages: [1] 2 3 4 5 6 7 8 ... 31