why it is not possible?

Page 2/3
1 | | 3

By hit9918

Prophet (2923)

hit9918's picture

29-01-2017, 00:00

the thing is that the C64 has buffer RAM on the floppy itself. the cpu can read stuff without a deadline long after a sector was loaded.
while on the MSX cpu reads the data directly off the floppy head in time, with disabled interrupts.

software DMA:
interrupt
device RAM
copy device RAM while enabled interrupts

with devices who meet this spec one can have audio dma disk dma like amiga.

By PingPong

Prophet (3898)

PingPong's picture

29-01-2017, 12:01

So the problem is the need to do a polling on some I/O address in order to sync and read data from disk?
I ever guessed that disk fdc takes care of disk related operations like go to sector, read something in a buffer then the cpu has to read this.
while this is requiring full CPU attention it does not mean that interrupts should be disabled all the time.
maybe it is a problem of addressing disk drive using a BIOS instread of directly talking to the controller?

to me the process of polling is similar to the same i use to wait for the VDP command ready flag.
I can implement by doing the polling with ints disabled and this prevent me to execute some interrupt driven operations
I can implement by doing the polling, and for each poll cycle to briefly enable ints, and this allow to catch for interrupts

It's a matter of implementation not a real tech limits.

Is this the same for Disk Drive I/O ?
Assuming a very light interrupt routine, just to play psg, can the disk management stuff made out of sync?

By RetroTechie

Paragon (1563)

RetroTechie's picture

29-01-2017, 14:46

PingPong wrote:

while this is requiring full CPU attention it does not mean that interrupts should be disabled all the time.

In the case of MSX floppy controllers, it does. The Z80 has to read each individual byte from the FDC as they pass under the disk r/w head. The rate at which this happens, simply doesn't allow processing an interrupt routine in between (no matter how short).

Just do the math: data rate is 250 kbits/sec = 31250 bytes/sec. Read: each byte takes on average ~115 Z80 clock cycles. Just enough time for a short loop, perhaps a 2nd (or 3rd?) pass through that loop, and read/write byte to main memory. Not enough for an interrupt routine in between with CALL/RET sequence, store/restore registers etc.

Between sectors & tracks there's more time, but if interrupt takes too long and a marker is missed, the disk needs to make an extra round & disk transfers become extremely slow. Interrupts could be enabled during a seek to 'random' track, but there's little point. Hence why working in DI state is normal for diskROM/FDC operations.

HDD/flash interfaces have the luxury of retreiving the data when they wish, any delays and the controller just keeps sitting there with the next data ready. For this to work with floppies, MSX would need a dedicated co-processor like found in C64 floppy drives. Which was kind of expensive back in the day... Eek!

By hit9918

Prophet (2923)

hit9918's picture

29-01-2017, 19:00

Quote:

I ever guessed that disk fdc takes care of disk related operations like go to sector

yes, this is possible with enabled interrupts EI.
the copy of the 512 bytes of the sector must go with DI. a sector takes roughly a video frame. this looks good.

yesterday I thought the topic was digi wav, but a vblank interrupt chiptune player is possible
at least in hardware coding, what the diskROMs do is another question

tell the WD to fetch a sector
and then ask whether data is ready
all this goes with EI.
if data available, then go DI and copy the sector

now, if right before that DI instruction you got hit by interrupt, the WD will tell "you fetched data too slow".
no problem, send the command again and wait for another revolution.
and waiting for it again goes with EI.

and I think THAT issue is where diskROMs go DI, avoiding this error handling
they go DI already in the moment of issuing the command.
and the worst case for the sector to arrive is one revolution, 0.2 seconds!
THAT must be why the keyboard always looses chars.

otherwise tests smell like diskROMs nicely enable interrupts after every sector.
e.g. hbd 50, poke &hfc9a,&hc9 does remove the LED OFF CALSLT and save cpu time, and then the disk transfer speeds up a bit.
the poke would make no difference if multiple sectors would be done with DI.

By giangiacomo.zaffini

Champion (267)

giangiacomo.zaffini's picture

29-01-2017, 19:02

What if sound application is the only part to run full throttle and disk i/o is interrupted and/or chopped to the least offending pieces? How does it takes to read from disk the least data in order to keep audio application running and no more than that? Can DOS/DOS2 just return from a i/o call and leave polling application to wait for data?

By hit9918

Prophet (2923)

hit9918's picture

29-01-2017, 19:47

while the sector slips under the head, the z80 must directly read from the head.
there is no way this can be interrupted.

the controller is like 1 byte of buffer.
now if it had a counter register telling which byte number this is in the sector, then one could make funny partial reads.
then coud be interrupted by line interrupts lol
and try read these bytes in the next revolution

By hit9918

Prophet (2923)

hit9918's picture

30-01-2017, 20:15

It might be possible without controller coding, with the PHYDIO sector read function
the disk
1 2 3 4 5 6 7 8 9 track 1
10 11 12 13 track 2

after reading sector 9 ask sector 12.
the head step happens in the time the sectors 10 and 11 pass by.
after the step the diskROM goes DI for sector arrival, but the sector 12 is very near. the bad 0.2 seconds DI zones no more happen.

By PingPong

Prophet (3898)

PingPong's picture

30-01-2017, 21:18

hit9918 wrote:

while the sector slips under the head, the z80 must directly read from the head.
there is no way this can be interrupted.

cannot believe!
i've ever though that a fdc controller advantage over the tape I/O driven by z80 was the ability to tell the FDC, "Please read a sector" and the operation is handled by the latter.....
You are telling me that the cpu must synchronize reads at the correct speed via kind of polling.
what a sadness.....
that what i define a very stupid controller!

By Albert Pieter Dotinga

Resident (39)

Albert Pieter Dotinga's picture

30-01-2017, 21:56

Sometimes... I admire the c64 for its great games like turrican/turrican II Smooth parallax scrolling. The almighty SID that kills the psg easy with its filters... And we never had a turrican on msx..... Crying realy msx programmers shame on you Smile please consider it....

By syn

Prophet (2097)

syn's picture

30-01-2017, 23:26

PingPong wrote:

You are telling me that the cpu must synchronize reads at the correct speed via kind of polling.
what a sadness.....
that what i define a very stupid controller!

That's just how FDCs work, even on modern systems like PC.
In fact, the MSX turboR FDC is PC-compatible (yes it is 1.44MB capable).

Info provided by GuyveR800

Page 2/3
1 | | 3