6522 VIA emulation: T1LH writes vs. T1 interrupt

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
Post Reply
User avatar
scarybeasts
Posts: 165
Joined: Tue Feb 06, 2018 7:44 am
Contact:

6522 VIA emulation: T1LH writes vs. T1 interrupt

Post by scarybeasts » Sat Dec 29, 2018 3:04 am

Hi,

I noticed a surprisingly basic disagreement between the various emulators in core timing / interrupt handling. Should be easy to resolve :-)

Both b-em and jsbeeb have a specific condition when T1LH is being written, to only clear T1 interrupt if we're in T1 continuous mode. Other emulators (MAME, b2, beebem) always clear T1 interrupt regardless of mode -- I suspect these are correct.

Very easy to resolve -- anyone can run VIA.I1 on a real beeb from the attached SSD? I suspect it'll give 64 / 0, matching MAME, b2, beebem, but you never know!


Cheers
Chris
Attachments
tests.ssd
(100 KiB) Downloaded 12 times

User avatar
BigEd
Posts: 2644
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: 6522 VIA emulation: T1LH writes vs. T1 interrupt

Post by BigEd » Sat Dec 29, 2018 11:45 am

(Edit: this is one of several related threads: )

Yep, 64/0:

Code: Select all

>L.
   10 REM RESULTS FROM DEC 2018
   20 PRINT "VIA TEST: DOES T1LH WRITE CLEAR INT IN ONE-SHOT?"
   30 DIM MC% 100
   40 DIM R% 16
   50 P% = MC%
   60 [
   70 OPT 3
   80 SEI
   90 LDA #&7F
  100 STA &FE6E
  110 LDA #&00
  120 STA &FE6B
  130 STA &FE64
  140 STA &FE65
  150 NOP
  160 NOP
  170 LDA &FE6D
  180 STA R%
  190 LDA #&00
  200 STA &FE67
  210 LDA &FE6D
  220 STA R%+1
  230 CLI
  240 RTS
  250 ]
  260 CALL MC%
  270 REM B-EM: NO: 64, 64
  280 REM B2: YES, 64, 0
  290 REM BEEBEM: YES: 64, 0
  300 REM JSBEEB: NO, 64, 64
  310 REM MAME: YES, 64, 0
  320 PRINT ?(R%)
  330 PRINT ?(R%+1)
>RUN
VIA TEST: DOES T1LH WRITE CLEAR INT IN ONE-SHOT?
1AFF          
1AFF          OPT 3
1AFF 78       SEI
1B00 A9 7F    LDA #&7F
1B02 8D 6E FE STA &FE6E
1B05 A9 00    LDA #&00
1B07 8D 6B FE STA &FE6B
1B0A 8D 64 FE STA &FE64
1B0D 8D 65 FE STA &FE65
1B10 EA       NOP
1B11 EA       NOP
1B12 AD 6D FE LDA &FE6D
1B15 8D 64 1B STA R%
1B18 A9 00    LDA #&00
1B1A 8D 67 FE STA &FE67
1B1D AD 6D FE LDA &FE6D
1B20 8D 65 1B STA R%+1
1B23 58       CLI
1B24 60       RTS
        64
         0
>
Last edited by BigEd on Tue Jan 01, 2019 10:33 am, edited 3 times in total.

Coeus
Posts: 1392
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: 6522 VIA emulation: T1LH writes vs. T1 interrupt

Post by Coeus » Sat Dec 29, 2018 4:05 pm

Ok, this one seems straightforward enough. I have updated b-em to behave as for the real hardware. The change is in github in the lastest version of the branch sf/viafix.

User avatar
scarybeasts
Posts: 165
Joined: Tue Feb 06, 2018 7:44 am
Contact:

Re: 6522 VIA emulation: T1LH writes vs. T1 interrupt

Post by scarybeasts » Sun Dec 30, 2018 6:18 am

Thanks BigEd!

Nice simple resolution, and both jsbeeb and b-em get to remove an if statement which is strangely satisfying :-)


Cheers
Chris

User avatar
BigEd
Posts: 2644
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: 6522 VIA emulation: T1LH writes vs. T1 interrupt

Post by BigEd » Sun Dec 30, 2018 9:40 am

Hmm, but that if statement must have been put in for some reason?

User avatar
scarybeasts
Posts: 165
Joined: Tue Feb 06, 2018 7:44 am
Contact:

Re: 6522 VIA emulation: T1LH writes vs. T1 interrupt

Post by scarybeasts » Mon Dec 31, 2018 3:05 am

BigEd wrote:
Sun Dec 30, 2018 9:40 am
Hmm, but that if statement must have been put in for some reason?
Heh, reason lost in the mists of time?

jsbeeb's VIA logic is based on b-em's best I know. Why does b-em have that logic? No idea but looking at some of the even older emulators: BeebInC (1998?) has a commented out version of this if statement; model-b (2003?) has this logic intact.


Cheers
Chris

User avatar
SarahWalker
Posts: 1204
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: 6522 VIA emulation: T1LH writes vs. T1 interrupt

Post by SarahWalker » Mon Dec 31, 2018 10:42 am

I think we've already established that I had no idea what I was doing when writing B-em's VIA code.

Coeus
Posts: 1392
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: 6522 VIA emulation: T1LH writes vs. T1 interrupt

Post by Coeus » Mon Dec 31, 2018 12:37 pm

SarahWalker wrote:
Mon Dec 31, 2018 10:42 am
I think we've already established that I had no idea what I was doing when writing B-em's VIA code.
I assume you started from the datasheet? After the discussions about the 6845 previously it does seem that the datasheets only include a level of detail sufficient for people to use the chip for the kind of things the designers had in mind and are not sufficiently detailed to say what happens in all the corner cases. So if "knowing what you're doing" means having run these test cases that's hardly common knowledge.

Anyway, having removed this extra logic b-em passes not only the test case for this thread but also the Kevin Edwards protection tests cribbed from RTW's VirtualBeeb as per the other thread.
Last edited by Coeus on Mon Dec 31, 2018 12:39 pm, edited 1 time in total.

User avatar
hoglet
Posts: 8583
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: 6522 VIA emulation: T1LH writes vs. T1 interrupt

Post by hoglet » Mon Dec 31, 2018 6:30 pm

Coeus wrote:
Mon Dec 31, 2018 12:37 pm
I assume you started from the datasheet? After the discussions about the 6845 previously it does seem that the datasheets only include a level of detail sufficient for people to use the chip for the kind of things the designers had in mind and are not sufficiently detailed to say what happens in all the corner cases. So if "knowing what you're doing" means having run these test cases that's hardly common knowledge.
It did occur to me that some of these tests may end up revealing differences between different manufacturer's 6522s.

The different NMOS parts I'm aware of are:
- Rockwell R6522
- MOS 6522
- Synertek SY6522
- UMC UM6522

I'm not sure which were official second sources (and used the same mask set).

There are known bugs in the MOS 6522 (relating to the shift registers) for example. So it wouldn't surprise me if there were other differences of behaviour in some of these corner cases.

So it might be worth testers declaring what 6522 is being tested in the real machines.

I'm also planning to run these soon on Beeb FPGA.

Dave

User avatar
scarybeasts
Posts: 165
Joined: Tue Feb 06, 2018 7:44 am
Contact:

Re: 6522 VIA emulation: T1LH writes vs. T1 interrupt

Post by scarybeasts » Mon Dec 31, 2018 8:21 pm

Coeus wrote:
Mon Dec 31, 2018 12:37 pm
SarahWalker wrote:
Mon Dec 31, 2018 10:42 am
I think we've already established that I had no idea what I was doing when writing B-em's VIA code.
I assume you started from the datasheet? After the discussions about the 6845 previously it does seem that the datasheets only include a level of detail sufficient for people to use the chip for the kind of things the designers had in mind and are not sufficiently detailed to say what happens in all the corner cases. So if "knowing what you're doing" means having run these test cases that's hardly common knowledge.

Anyway, having removed this extra logic b-em passes not only the test case for this thread but also the Kevin Edwards protection tests cribbed from RTW's VirtualBeeb as per the other thread.
Regarding the datasheets, they're a tough read and I've found a few references to them being incorrect.
For example, I just found code to emulate a Commodore disc drive and it appears to have been developed at least partially with a logic analyzer so could be a source of inspiration:
https://github.com/pi1541/Pi1541/blob/m ... /m6522.cpp
On line 599 there's a large comment about incorrect data sheets.

Historic BBC VIA development appears to be empirical (i.e. does Kevin Edwards' protection work yet?) and additional empirical testing for corner cases is probably going to carry us a bit further until there's a "visual 6522" to play with.


Cheers
Chris

tom_seddon
Posts: 339
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: 6522 VIA emulation: T1LH writes vs. T1 interrupt

Post by tom_seddon » Tue Jan 01, 2019 2:57 am

Regarding the notes around line 599, and the data sheets - the fact that T1LH writes clear the T1 flag is mentioned in the MOS and WDC data sheets, but not in the Rockwell one and not in the AUG (which judging by the diagrams appears to be based on the Rockwell data sheet, so perhaps not surprising). This affects Skirmish, which (as I recall) just hangs up if this aspect is wrong.

EDIT: wait, hang on, there's some additional logic in that code, isn't there? - looks like doing this can switch off the T1 IRQ flag entirely, while still leaving the PB7 toggling behaviour active. Ugh. Maybe this affects something in my Skirmish postscript, but I'm not going to think about it right now. What a pain this stupid chip is.

--Tom

P.S. for whatever it's worth, some Skirmish notes, from an email I wrote at the time:
Got it [Skirmish] working yesterday. Turns out that writing to the T1 high latch acknowledges a T1 interrupt if T1 is in free-run mode. (And possibly in single-shot, but I'll have to try it out on a real beeb... I'm BBCed out after this weekend.) The AUG doesn't mention this, but the data sheet does.

The IRQ code is reproduced below, with some comments. Skirmish acknowledges the T1 IRQ 'properly' for one state, but not for the other, which makes me wonder whether this wasn't a bug in the code that went unnoticed (It was then getting the same T1 IRQ straight away, thinking it was the next one, with predictable results -- this was what made me look at the data sheet more closely!)

T1 alternates between 16269 and 3695, making 19964 in total -- the length of a non-interlaced frame, as you'd probably noticed. I'm still not sure what that polling of T1 is for. Strikes me it should throw the whole thing out, because it delays another 400 cycles after the timeout, I think, but still it magically stays in sync!! But I was never that great at reading others' code anyway...

I'm hoping to do a new release next weekend. It will have this fix. It also has joystick support, both BBC joystick and using joystick for keys, so you can play Skirmish and Arcadians as they were designed to be -- using a Playstation pad

--Tom

Code: Select all

1E45: LDA   &FC        A5 FC    ; IRQ1V
1E47: PHA              48      
1E48: TXA              8A      
1E49: PHA              48     
1E4A: TYA              98      
1E4B: PHA              48      
1E4C: LDA   &FE6D      AD 6D FE ; UsrIfr
1E4F: BIT   &8F        24 8F    ; UsrT1?
1E51: BNE   &1E74      D0 21    ; if UsrT1, &1e74
1E53: AND   #&20       29 20    ; UsrT2?
1E55: BNE   &1EC5      D0 6E    ; if UsrT2, &1ec5 (don't think this actually happens)
1E57: LDA   &FE4D      AD 4D FE ; SysIfr
1E5A: LDX   #&3D       A2 3D    ; 
1E5C: STX   &FE4E      8E 4E FE ; disable all except ca1 (vsync)
1E5F: AND   #&40       29 40    ; SysT1?
1E61: BEQ   &1E6D      F0 0A    ; if not SysT1, &1e6d
1E63: PLA              68       
1E64: TAY              A8      
1E65: PLA              68      
1E66: TAX              AA      
1E67: PLA              68      
1E68: STA   &FC        85 FC   
1E6A: JMP   &DC93      4C 93 DC ; forward t1 IRQs to the OS routine (key handling etc.)

; no UsrT1, no UsrT2, no SysT1
1E6D: LDA   #&3F       A9 3F    ;   
1E6F: STA   &FE4D      8D 4D FE ;acknowledge all flags whatever it was
1E72: BNE   &1EBD      D0 49    ;JMP &1ebd

; UsrT1
; &46 is handler state
; if ==0, set T1 to 16269
; if !=0, set T1 to 3695
; (16269 + 3695 = 19964, length of non-interlaced frame)
1E74: LDA   &46        A5 46    ;
1E76: BEQ   &1E80      F0 08    ;

; ?&46 != 0
1E78: LDA   #&6F       A9 6F   
1E7A: LDY   #&0E       A0 0E    ;e6f = 3695
1E7C: LDX   #&00       A2 00    ;X ends up in &46
1E7E: BEQ   &1EA9      F0 29    ;JMP &1ea9


;&5c set at &1501 (no others)
1E80: INC   &5C        E6 5C    ; 
1E82: LDA   &5C        A5 5C    ; 
1E84: AND   #&02       29 02    ; 
1E86: LSR   A          4A       ; 
1E87: AND   &5C        25 5C    ; 
1E89: ORA   #&14       09 14    ; 
1E8B: STA   &FE20      8D 20 FE ; alternate flashing colours every now and again

1E8E: LDA   #&40       A9 40    ;
1E90: STA   &FE6D      8D 6D FE ;acknowledge UsrT1

1E93: LDA   &FE65      AD 65 FE
1E96: CMP   #&0C       C9 0C   
1E98: BCC   &1EA3      90 09    ; wait a bit
1E9A: BNE   &1E93      D0 F7   
1E9C: LDA   &FE64      AD 64 FE
1E9F: CMP   #&DF       C9 DF   
1EA1: BCS   &1E9C      B0 F9    ; wait a bit more
1EA3: LDX   #&08       A2 08   
1EA5: LDA   #&8D       A9 8D   
1EA7: LDY   #&3F       A0 3F    ; UsrT1 = &3f8d (16269)

;this bit resets T1 and loads a new palette.
1EA9: STA   &FE66      8D 66 FE 
1EAC: STY   &FE67      8C 67 FE ; 
1EAF: STX   &46        86 46    ;

;set up palette
;X is 0 or 8

;if 0, values are 07 13 26 35 44 51 60 72 (normal skirmish palette??)
;if 8, values are 06 16 26 36 46 56 66 76 (all red)

1EB1: LDY   #&08       A0 08   
1EB3: LDA   &139A,X    BD 9A 13
1EB6: STA   &FE21      8D 21 FE ; again, knobble palette
1EB9: INX              E8      
1EBA: DEY              88      
1EBB: BNE   &1EB3      D0 F6  
1EBD: PLA              68      
1EBE: TAY              A8      
1EBF: PLA              68      
1EC0: TAX              AA      
1EC1: PLA              68      
1EC2: STA   &FC        85 FC  
1EC4: RTI              40
Last edited by tom_seddon on Tue Jan 01, 2019 3:15 am, edited 2 times in total.

User avatar
tricky
Posts: 3778
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: 6522 VIA emulation: T1LH writes vs. T1 interrupt

Post by tricky » Tue Jan 01, 2019 10:04 am

I guess we can try other 6522s at ABUG.

Post Reply