Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
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-08 20:17
Zibri

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

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

Registered: Dec 2001
Posts: 9790
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: 1499
You guys
2021-04-08 21:53
Krill

Registered: Apr 2002
Posts: 1835
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
Groepaz

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

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

Registered: Dec 2001
Posts: 9790
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: 421
$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
Groepaz

Registered: Dec 2001
Posts: 9790
Those VIA Datasheet arent actually very useful to understand the detail behaviour of the VIAs (and they contain various mistakes too).
Previous - 1 | 2 | 3 | 4 - 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
Scrap/Genesis Project
Morpheus/IPC
The Sarge/Fairlight
jailbird
T.M.R/Cosine
JEZ
Krill/Plush
AMB/Level 64
Sentinel/Excess
Ze Smasher/F4CG
Guests online: 151
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 The Shores of Reflec..  (9.5)
10 Wonderland XII  (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 Organizers
1 Burglar  (9.9)
2 Sixx  (9.8)
3 Irata  (9.8)
4 Taper  (9.8)
5 hedning  (9.7)

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