CD...

Today I connected an 8-speed CD (Mitsumi) via SMUC as a Slave. If anyone remembers, I previously wrote here about the 16-speed Hitachi :-)
This CD is no less buggy, but it still works. This time I managed
to come a little closer to the essence of the problem, now, in fact, everything is in order:
CDPlayer. Here everything is quite sad: it is almost
impossible to work normally in it, since it is impossible to switch tracks normally:-(Operations like
“Move tray”, “Stop playing”, etc. work without failures:) Upon
further digging it turned out that the operation of starting playback also
works normally - here the problem lies in something else: when we poke at
"Select track" the table of tracks located on disk (as I understand it,
it contains song numbers and their offset and ends with the #AA byte).
It is pumped out of the CD in words (which are 16 bits each :)). First, the low byte is taken, then the high byte, and so on in a circle. So, my CD, as I understand it, does not have time to provide the next word, and there are no delays in waiting for readiness in the program, that is, CDPlayer does not check whether the CD-ROM is ready to send the next word to the computer. For example: we have the sequence:
... 03 00 4C 1B ...
reading, we get: ... 03 00 03 00 4C 1B ...
or something similar.
If you make artificial delays when reading this table (for example, tracing it in the shadow with the command slow#84;)), then the table is read normally, although it takes a long time;)) Apparently, if the CD is faster, then such problems will not arise. Even when I connected a 16-speed CD, disabling
Turbo helped, but it doesn’t help with this CD;(
2Vlad Sotnikov: Maybe it’s better to check the Busy signal here, as when working
with a screw, but only for each byte, or is this impossible for a CD?

CD-WALK. Everything here is the same as with the previous CD: device is not
determined, but if you skip the check, then everything works with a bang. And in the
trace mode the check passes: -\ Apparently, the problem here is the same:
the CD does not keep up with the computer.
The check passes, even if you do not trace its stages (more precisely, the nested
subroutines in the check subroutine would be enough...

I really hope that this information will help the authors). working on the
program:-)

I wish you good luck!
Sincerely, Fyodor Odegov aka FION.

31 Oct 01 18:18, Fyodor Odegov -> All:

FO> It is pumped out of the CD in words (which are 16 bits :)). First
FO> the low byte is taken, then the high byte, and so on in a circle. So my CD, as
FO> I understand, does not have time to provide the next word, and there are no readiness delays
FO> in the program, that is, CDPlayer does not check whether the CD-ROM
FO> is ready to send the next word to the computer. For example: we have the sequence:
FO> ... 03 00 4C 1B ...
FO> reading, we get: ... 03 00 03 00 4C 1B ...
FO> or something similar.
FO> If we make artificial delays when reading this table (for example,
FO> tracing it in the shadow with the command slow#84;)), then the table it reads
FO> normally, although it takes a long time;)) Apparently, if the CD is faster, then such
FO> problems will not arise. Even when I connected a 16-speed CD, turning off Turbo helped
FO>, it doesn’t help on this CD;( 2Vlad Sotnikov: Maybe
FO> it’s better to check the Busy signal here, as when working with a screw, but only for
FO> each byte, or is this impossible for a CD?

BSY is not intended for this. If we do synchronize, then only by DRQ.
Each CD (and screw too) has a buffer for at least 1 sector, usually something
in the region of 16-128 kilo.Sectors are first read into it and only then
transferred to the computer. You only need to synchronize between sectors; the sectors themselves can be sucked in at least by INIR. There is also a block mode, where you can carry blocks of up to 64 KB at a time without any delays or synchronization.
This is strange. Maybe there is something crooked in the hardware? Are the signals ringing?

WBR, Jason.