| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
VIA 6522 latching still unemulated.
let's imagine that on disk are recorded 5 bytes:
we call them x1 x2 x3 x4 and x5
now imagine we positioned in front of them, we skip 3 and read the fourth.
if to do that you use this code:
CLV
LDA $1C01 ; A here contains X1
LDY #$03
loop:
BVC loop
CLV
DEY
BNE loop
LDA $1C01 ; A = X1 on RH and X5 on emulators
on vice, pi1541 and ultimate64/u2+
A will contain "x5".
But on real hardware it will contain X1.
The following code instead will work on both:
CLV
LDA $1C01 ; A here contains X1
LDY #$03
loop:
BVC loop
CLV
DEY
BNE loop
LDA $1C0F ; A = X5
That happens because 1C01 keeps the last byte READ (with any LOAD operation or any other cpu instruction that does a READ) while 1C0F contains the actual shift register.
Note:
also putting a "useless" LDA $1C01 inside the loop and the reading 1C01 will work too. But still I think that's an important feature present on BOTH VIA CHIPS that should be emulated. |
|
... 25 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Martin Piper$1C0F should be the same as $1C01 except that $1C0F doesn't produce a handshake. I seem to remember that reading $1c0f doesn't clear the latch, while reading $1c01 does. On real hardware, that is. =) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
IIRC that part is mentioned in a single sentence in the MOS datasheet though :) |
| |
Martin Piper
Registered: Nov 2007
Posts: 634 |
Zibri, just a thing to note:
The two code snippets have different cycle timings:
Quote:
CLV
LDA $1C01 ; A here contains X1
LDY #$03
loop:
BVC loop
CLV
DEY
BNE loop
LDA $1C01 ; A = X1 on RH and X5 on emulators
And:
Quote:
The only code that works on RH is this:
CLV
LDA $1C01 ; A here contains X1
LDY #$03
loop:
BVC loop
CLV
LDA $1C01
DEY
BNE loop
LDA $1C01 ; A = X5
Which would be altering things a bit. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: IIRC that part is mentioned in a single sentence in the MOS datasheet though :)
Exactly.
And Ignored by emulators apparently. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting GroepazThat kind of stuff even varies between real drives, eg the "long board" will allow reading more zeros in a row reliably. Its also highly sensitive to rotation speed, and various other subtle factors. As long as existing weak bit protections pass, i doubt anyone will loose his sleep over it (ie what krill wrote above).
Weak bits don't really exist. All protections I have seen so far that supposedly use "weak bits" in reality they just wrote a bunch of "0" bits in strategic places.
That includes Rubicon and it was confirmed by the author of the protection.
The bits were considered to be weak because they change state between two reads but that does not happen because of some strange invented thing. It happens because of jitter and wobble that cause more or less zeroes to be read, flipped or skipped losing framing. That gives the illusion of "changing bits". |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
"It happens because of jitter and wobble that cause more or less zeroes to be read, flipped or skipped losing framing."
thats exactly what weak bits are - was there any doubt about it?
(actually there are also "real" weak bits - written with reduced write current - however that is extremely rare) |
| |
Martin Piper
Registered: Nov 2007
Posts: 634 |
Well some floppy manufacturers that did protection products did degauss their floppies first and then use highly calibrated and time controlled disk writers (using a sync hole) that could create areas that effectively lacked magnetic information. They would be read as noise and have data read timing characteristics that were very hard to reproduce in drives without the sync hole and calibration. |
| |
Comos
Registered: May 2004
Posts: 71 |
Quote: Well some floppy manufacturers that did protection products did degauss their floppies first and then use highly calibrated and time controlled disk writers (using a sync hole) that could create areas that effectively lacked magnetic information. They would be read as noise and have data read timing characteristics that were very hard to reproduce in drives without the sync hole and calibration.
I guess that was the Securispeed protection scheme. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Quoting GroepazThat kind of stuff even varies between real drives, eg the "long board" will allow reading more zeros in a row reliably.
I gather from the comments in the pi1541 sources that at least one of the drives physically cannot read more than three zeros in a row, as there's a timer circuit that just spits out a continuous loop of 100010001000, unless it sees a flux change in which case it restarts the loop from a point half a bit before the next 1 is emitted.
Is there a difference between long and short boards in that regard? |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quote: Quoting GroepazThat kind of stuff even varies between real drives, eg the "long board" will allow reading more zeros in a row reliably.
I gather from the comments in the pi1541 sources that at least one of the drives physically cannot read more than three zeros in a row, as there's a timer circuit that just spits out a continuous loop of 100010001000, unless it sees a flux change in which case it restarts the loop from a point half a bit before the next 1 is emitted.
Is there a difference between long and short boards in that regard?
This is part of the clock recovery "PLL". If the bitrate from disk is slightly slower than the reference bitrate you will occasionally get a one bit as your third bit. This is due to the sequence wrapping before the whole last '0' was passed. This mean unless the bitrates are crafted in a special way, only two consecutive '0's may be used reliably (but see below).
I don't think this behaviour is different between long and short (custom IC), but IIRC there are other issues relating to longer runs on later drive models, i.e noise gradually taking over generating spurious bits and possibly a recovery time after long '0' runs. Someone else could perhaps fill in here? I never had a later drive myself. |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
