Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > VIA 6522 latching still unemulated.
2021-04-08 13:12
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.
2021-04-08 13:41
Krill

Registered: Apr 2002
Posts: 2801
You have just created a duplicate of one of the oldest open tickets.

https://sourceforge.net/p/vice-emu/bugs/582/

Now, this is one of the issues where something works in the emulator but doesn't work on the real thing.

This is not as bad, by a long shot, as something working on the real thing but not in the emulator.

If somebody creates software that doesn't work on the real thing but works in an emulator, joke's on them. =)
2021-04-08 14:22
Zibri
Account closed

Registered: May 2020
Posts: 304
I agree with you at a logical level but still since emulators EMULATE real hardware, they should emulate as much as they can and this is very easy to fix.

Also, without fixing this it will be trivial to include an emulator detection with a very few lines of code.

On a more important note, all emulator based on vice 1541 code (including pi1541) have a bad handling of zeroes...
With a simple program that writes bytes with mopre than 3 zeroes in them, you can easily spot the difference between an ALPS, a newtronics and an emulator.
Ultimate64 and u2+ have their own implementation and on this they are the best I have seen so far.
The test results on those look very similar to a newtronics 1541.
If u2+/u64 would also implement RPM and wobbling it would be almost perfect.
2021-04-08 16:18
chatGPZ

Registered: Dec 2001
Posts: 11073
Quote:
this is very easy to fix

should be easy to provide a patch then
2021-04-08 20:17
Zibri
Account closed

Registered: May 2020
Posts: 304
Quoting Zibri

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


Update:
this code works also ONLY in emulators.
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
2021-04-08 20:30
Zibri
Account closed

Registered: May 2020
Posts: 304
Quoting Groepaz
Quote:
this is very easy to fix

should be easy to provide a patch then

Yes, why don't you, then?
2021-04-08 20:51
chatGPZ

Registered: Dec 2001
Posts: 11073
You are the one who said "this is very easy to fix" - so that question goes right back to you.
2021-04-08 20:52
Frantic

Registered: Mar 2003
Posts: 1625
You guys
2021-04-08 21:53
Krill

Registered: Apr 2002
Posts: 2801
As Groepaz implies, there is a reason why two of the most popular emulators don't do this right. (Does Z64K, btw.? :D)

While it seems easy to implement that latch from a high-level description, there may be various subtle timings and corner cases to observe. Stuff that could potentially break many things, and thus requires extensive testing and even then might suffer regressions temporarily.

So again, i can see why things that work in a given emulator but don't work on original hardware are not exactly at the top of to-do lists, contrary to the other way around.
2021-04-08 22:18
chatGPZ

Registered: Dec 2001
Posts: 11073
Indeed. The first step would be to create an extensive set of testcases (an not just a bunch of code snippets, but programs that actually work in the testbench).
2021-04-09 02:27
Zibri
Account closed

Registered: May 2020
Posts: 304
I also found a discrepancy in how a varying series of zeroes is handled by real hardware and emulators...
Writing on a disk for example: FF FF FF 88 84 82 80 00 FF FF FF and then reading it back gives very identifiable results.
The best results I have seen come from U2+/Ultimate64 (which only misses wobbling emulation and speed setting to be perfect)
Vice and pi1541 give very identifiable results.
Moreover if you write that series of bits at "density" 3 (32 cycles per byte) and read it back at density 1 (28 cycles per byte) the result is even more different form a real hardware in good condition.
2021-04-09 12:41
chatGPZ

Registered: Dec 2001
Posts: 11073
That 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).
2021-04-09 14:23
Martin Piper

Registered: Nov 2007
Posts: 621
$1C0F should be the same as $1C01 except that $1C0F doesn't produce a handshake. Page 3 of http://archive.6502.org/datasheets/rockwell_r6522_via.pdf


The interesting thing is that in the standard 1541 code, $1c0f doesn't seem to be referenced at all.
2021-04-09 15:30
chatGPZ

Registered: Dec 2001
Posts: 11073
Those VIA Datasheet arent actually very useful to understand the detail behaviour of the VIAs (and they contain various mistakes too).
2021-04-09 15:43
Krill

Registered: Apr 2002
Posts: 2801
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. =)
2021-04-09 15:51
chatGPZ

Registered: Dec 2001
Posts: 11073
IIRC that part is mentioned in a single sentence in the MOS datasheet though :)
2021-04-10 11:58
Martin Piper

Registered: Nov 2007
Posts: 621
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.
2021-04-10 16:25
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.
2021-04-10 16:31
Zibri
Account closed

Registered: May 2020
Posts: 304
Quoting Groepaz
That 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".
2021-04-10 16:42
chatGPZ

Registered: Dec 2001
Posts: 11073
"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)
2021-04-11 08:32
Martin Piper

Registered: Nov 2007
Posts: 621
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.
2021-04-11 23:22
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.
2021-04-12 03:10
ChristopherJam

Registered: Aug 2004
Posts: 1356
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: 1698
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
chatGPZ

Registered: Dec 2001
Posts: 11073
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
Account closed

Registered: May 2020
Posts: 304
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
Account closed

Registered: May 2020
Posts: 304
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
Account closed

Registered: May 2020
Posts: 304
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
Account closed

Registered: May 2020
Posts: 304
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
chatGPZ

Registered: Dec 2001
Posts: 11073
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: 1356
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.
2021-07-18 03:22
willymanilly

Registered: Jan 2016
Posts: 27
Just stumbled accross this thread!

Quoting Groepaz
Those VIA Datasheet arent actually very useful to understand the detail behaviour of the VIAs (and they contain various mistakes too).


Couldn't agree more with this statement! :) Is it possible the following extract is one of the mistakes you mention? See below for context. :)
"The PA port and the PB port on the R6522 can be enabled in the Auxiliary Control Register (Figure 14) to be latched by their individual port control lines (CA1, CB1). Latching is selectable to be on the rising or falling edge of the signal at each individual port control line"

Quoting Krill
As Groepaz implies, there is a reason why two of the most popular emulators don't do this right. (Does Z64K, btw.? :D)


Z64K has latching implemented but Freespin exposed a bug with it which caused the demo to get stuck on track 1. Other emulators with a VIA port latch "fix" also get stuck at track 1.

Looking at part of the Freespin loader source, if the 6522 datasheet is to be believed, storing 6f into 1c0c should cause the latching to occur on a positive edge instead of the usual negative edge.

// switch from square wave generation to loading
lda #$6f
sta $1c02
sta $1c0c // ee is the default, but 6f works, too.
lda #$41
sta $1c0b

The "hack" I ended up implementing in Z64K to support Freespin and to not break the latching behaviour mentioned in VICE bug #582 was to force the latch to always occur on a negative edge when latching is enabled. The IRQ still uses the value in the ACR to determine what edge to trigger on. There's still parts of the latch emulation that does not strictly follow the information contained in the datasheet so it won't surprise me if something new comes out and breaks the latching emulation again.

Quoting Zibri
I agree with you at a logical level but still since emulators EMULATE real hardware, they should emulate as much as they can and this is very easy to fix.

We do our best but implementing features based purely on high level documentation is actually very challenging because it does not always give the full picture of what's happening at the low level. This is where a test suite of programs where the results have been confirmed on real hardware like the ones available in Testbench are very useful and can make things so much easier to fix.
2021-07-18 14:27
chatGPZ

Registered: Dec 2001
Posts: 11073
I am still waiting for the apparently very easy to do patch that fixes it :)
2021-07-19 18:32
Quiss

Registered: Nov 2016
Posts: 37
It seems that $6f in $1c0c causes loading to break on (some) real hardware, as well. In particular, I just received word that an 1541 with an older Alps drive mechanism (and a short board) won't run Freespin either, but works fine if $1c0c is set $ee.
2021-07-19 18:42
chatGPZ

Registered: Dec 2001
Posts: 11073
would be awesome if you could knock up a couple small test programs for this stuff :)
2021-07-19 22:25
willymanilly

Registered: Jan 2016
Posts: 27
Quote: It seems that $6f in $1c0c causes loading to break on (some) real hardware, as well. In particular, I just received word that an 1541 with an older Alps drive mechanism (and a short board) won't run Freespin either, but works fine if $1c0c is set $ee.

I'm light of Freespin failing on some real hardware I'm thinking now the issue is more likely to do with the length of the byte ready signal which triggers the port latching.

$ee in 1c0c should always guarantee valid data will be on the port pins because it triggers as soon as the byte ready signal asserts itself. If $6f is used the latching may occur when the shifter has already shifted another bit depending on when the byte ready signal resets itself.

Another useful test would be to determine how long the byte ready signal is for different drive models. I've already tested in emulation that shortening the length of the byte ready signal allows Freespin to run the complete demo without requiring a hack to the VIA port latching!
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
Mike
curtcool
algorithm
bepp/ΤRIΛD
pcollins/Quantum
WVL/Xenon
Guests online: 189
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 No Bounds  (9.6)
6 Comaland 100%  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 No Sprites  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 Party Elk 2  (9.7)
2 Cubic Dream  (9.6)
3 Copper Booze  (9.5)
4 Rainbow Connection  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Onscreen 5k  (9.5)
7 Dawnfall V1.1  (9.5)
8 Quadrants  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Birth of a Flower  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Nostalgia  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Diskmag Editors
1 Jazzcat  (9.4)
2 Magic  (9.4)
3 hedning  (9.2)
4 Newscopy  (9.1)
5 A Life in Hell  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.092 sec.