Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user NoobTracker ! (Registered 2021-04-13) You are not logged in 
CSDb User Forums


Forums > C64 Coding > VIA 6522 latching still unemulated.
2021-04-08 13:12
Zibri

Registered: May 2020
Posts: 148
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.
 
... 20 posts hidden. Click here to view all posts....
 
2021-04-11 23:22
Comos

Registered: May 2004
Posts: 54
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.
2021-04-12 03:10
ChristopherJam

Registered: Aug 2004
Posts: 1130
Quoting Groepaz
That 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?
2021-04-12 09:28
tlr

Registered: Sep 2003
Posts: 1441
Quote: Quoting Groepaz
That 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.
2021-04-12 11:28
Groepaz

Registered: Dec 2001
Posts: 9780
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.

using non preformatted disks and then duplicating with the so called "trace machine" was pretty much the standard process for floppy duplicating :) unformatted areas are not what is typically referred to as "weak bits" though. (and protections based on this are actually easy to fool by writing something like a 10000100000 pattern, ie more or less random chunks 4 or more zeroes with ones in between)
Quote:
I don't think this behaviour is different between long and short (custom IC)

Somehow that is what i remember though. It might not be directly related to the data seperator, but some other detail.
2021-04-12 13:10
Zibri

Registered: May 2020
Posts: 148
Quoting Groepaz
"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)

I was meaning that the ones "written with reduced write current" didn't really exist or they are just the byproduct of bad media or bad drives. They were never used as a protection system.
2021-04-12 13:13
Zibri

Registered: May 2020
Posts: 148
Quoting Martin Piper
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.

Also this while it's theoretically possible (and reproducible) from a 1541 point of view doesn't change much. What counts is what the 1541 is physically able to read "reliably". Anything "unreliable" would be intepreted in different ways by different drives in different conditions.
2021-04-12 13:15
Zibri

Registered: May 2020
Posts: 148
Quoting ChristopherJam
Quoting Groepaz
That 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?

Funny you mentioned it. pi1541 abd Vice are the ones who behave very differently in the presence of zeroes.
Also OC118 drive writes and reads less zeroes in a row than a 1541.
The best I have seen so far on emulators is the u2+/u64.
2021-04-12 13:19
Zibri

Registered: May 2020
Posts: 148
Quoting Groepaz
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.

using non preformatted disks and then duplicating with the so called "trace machine" was pretty much the standard process for floppy duplicating :) unformatted areas are not what is typically referred to as "weak bits" though. (and protections based on this are actually easy to fool by writing something like a 10000100000 pattern, ie more or less random chunks 4 or more zeroes with ones in between)
Quote:
I don't think this behaviour is different between long and short (custom IC)

Somehow that is what i remember though. It might not be directly related to the data seperator, but some other detail.

Exactly: specific patters with different sequences of "0" bits produce predictable results.
By analyzing those results on RH an emulators, pi1541 and Vice can be easily identified.
u2 and u64 instead behave like a (too) perfect 1541.
2021-04-12 13:21
Groepaz

Registered: Dec 2001
Posts: 9780
Quote:
I was meaning that the ones "written with reduced write current" didn't really exist or they are just the byproduct of bad media or bad drives. They were never used as a protection system

Thats quite a claim - how do you know this? (US Patent 4849836 shows a few more rarely used methods to create weak bits)
Quote:
Exactly: specific patters with different sequences of "0" bits produce predictable results.

no. what you will read is more or less random noise, not predictable (on real drives, obviously).
2021-04-12 16:04
ChristopherJam

Registered: Aug 2004
Posts: 1130
Quoting tlr
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).

Oh that part I'm well aware of - but you need the reading drive to run at 8/7ths of the speed of the writing drive for 10001 to read as 1001, or 8/9ths to read 10001 as 100011. Even the latter would require a 36rpm difference between the speeds of the two drives, which seems a tad unlikely, no?

(As I understand it, the first "1" is declared two quarterbits after the flux is detected, then "0"s declared at six, ten, and fourteen quarterbits).

Quote:
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.

Yes, I suspect the automatic gain control is more likely to be an issue in practice - the longer the gap between flux changes the more likely it is that the drive will amplify noise to the point that it reads as a spurious 1 bit.
Previous - 1 | 2 | 3 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
curtcool
Fuzz/Retro64
DonChaos
Ze Smasher/F4CG
Steffan
NoobTracker
Acidchild/Padua
Guests online: 99
Top Demos
1 Edge of Disgrace  (9.6)
2 Coma Light 13  (9.6)
3 Uncensored  (9.6)
4 Unboxed  (9.6)
5 Comaland 100%  (9.6)
6 Lunatico  (9.6)
7 Memento Mori  (9.6)
8 Christmas Megademo  (9.5)
9 We Love to Party  (9.5)
10 The Shores of Reflec..  (9.5)
Top onefile Demos
1 Copper Booze  (9.8)
2 To Norah  (9.7)
3 Lovecats  (9.6)
4 Square Booze  (9.5)
5 Daah, Those Acid Pil..  (9.5)
6 Elite Code Mechanics  (9.5)
7 Dawnfall V1.1  (9.5)
8 No Mercy for the Tro..  (9.4)
9 Quadrants  (9.4)
10 Babbo Maiale  (9.4)
Top Groups
1 Booze Design  (9.4)
2 Fossil  (9.4)
3 Censor Design  (9.3)
4 Oxyron  (9.3)
5 PriorArt  (9.3)
Top Swappers
1 Derbyshire Ram  (10)
2 Jerry  (9.8)
3 Acidchild  (9.7)
4 Starlight  (9.6)
5 Violator  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2021
Page generated in: 0.043 sec.