Menu
▾
▴
1 Attachments
#1219 CIA shiftregister bugs
moved over from #1206
Andre Fachat - 2020-03-29:
There are only two things I needed to fix to make it run on the real thing when it already worked on VICE or vice versa, so I guess there may be something to do:
In the NMI routine, after the start bit, the timer is set to shift in from SDR2. It actually worked on VICE without the timer output sent to PB7 (where it is routed to CNT2, as clock input to the shift register). I had missed this before, and had to enable the PB7 output to make it work on the real C64:
- lda #%00010001
+ lda #%00010011
sta C64CIA2+CIA_CRB ; start timer, force load latch
So, there could be a bug that VICE shifts in from SDR using Timer B, even without the timer underflows on PB7 which is (in my understanding) necessary. This is confirmed from my tests today.
Another point I found that might be a bug: when I tested the software that originally worked on hardware, I found that I had to introduce a delay when sending two bytes to SDR (after an SDR empty interrupt):
lsr
sta C64CIA1+CIA_SDR ; 7 data bits, 1 start bit
ror
ora #$7f
+jsr delay
sta C64CIA1+CIA_SDR ; 1 data bit, 7 stop bits
Looking at the VICE code, it seems the new byte is only taken into the shift register on the first timer underflow. So one has to introduce the delay to make sure one timer underflow appears before writing a new byte.
The CIA datasheet however says: "The data in the Serial Data Register will be loaded into the shift register, then shift out to the SP pin when a CNT pulse occurs."
So it should be possible (and in my previous (historic) experience I think it is) that when the SDR is empty one can directly write two bytes without delays: one that is immediately passed through to the actual shift register, while the second byte stops in the SDR, to be loaded into the shift register when it ran empty. (I probably should confirm this next week, but the code without the delay ran successfully in older days on real hardware)
[...]
I'll attach a small test program that shows different timing between the x64sc and a C128 in C64 mode. VICE prints out 10 times "$FCF2" while the C64 prints out "$FCEB" (with only 1-2 cycles off in the first iterations each).
However, that does not show the actual problem when shifting out the data. The test writes to SDR twice directly after each other. In the real machine, the RS232 transmits all 16 bits - in VICE SDR, the rs232 code only gets a single byte - so output is mangled. But that is not something an all-in-the-machine test can show.
added the testprog to the repo (CIA/shiftregister/). also confirmed it works on C64 with new and old CIA
it would be cool if you could provide code that can be used to test this in vice... i have no idea how :)
Last edit: gpz 2020-04-28
Part of the issue is the timing of when the ICR SP flag is updated after the shift register acknowledges it is ready for next byte. A few quick tests I did suggest it should be one cycle later.
Attached is a modified version of the provided test program provided by Andre that can be compiled using ACME. It simply tests when the shift register acknowledges it is empty with 1 byte writen to the SDR register. This passes on my real c64c and c128D in c64 mode. It fails in VICE. VICE result is FCF1, real result is FCEA.
FYI, I also confirmed the orginal test passes on both my real machines.
Last edit: William McCabe 2020-04-30
Attached is another test which adds a delay before writing a byte to the SDR after Timer A has started and waits until the SDR flag is set. The test executes 21 times decreasing the delay by 1 cycle each run. Red text in results shows mismatch in timing compared to my real hardware(same systems as decribed above) .
Based on these results it looks like there is a 4 cycle delay on real hardware compared to VICE for when the SDR flag is set. More tests should probably be done with different baud rates to see if the delay is consistent.
cool, i added both to the repo. now we need someone who understands that code to fix it =P
Attached is another test that shows the ICR value for every cycle from just before the first Timer A underflow to when the SDR is empty. On real hardware the Timer A flag is set after the first underflow. The SDR flag is set when the final bit is shifted via the shift register. These results are shown by default. On VICE it seems to support the 4 cycle delay therory looking at the last series of I's at the bottom of the screen. The results on VICE also show the SDR flag is set well before the final underflow for shifting. This is probably something to do with what's discussed in the next paragraph.
Pressing space toggles the screen which shows the value of the ICR immediated after loading the SDR register for each of the cycles. On VICE they are all zeros. On real hardware the SDR bit is set depending on when TImer A was stopped on the previous test. Timer A is stopped by the test as soon as it detects SDR flag i set. This needs more investigation but I'm guessing the shift register picks up from where it left off from the previous test because it hadn't finished the final shift in the previous test, it only flagged the SDR was available for new data....
The attached test passes on my real hardware. My C64C has new CIA and my C128 has old CIA. First screen of results is the same for both. The second screen of results are very similar for old and new CIA. The only difference is the SDR is cleared in the cycle after it is first set for new CIA before being set again in the following cycles. Look at the dumps for more detail.
I think these results, especially from the second screen, will keep me busy for a bit trying to figure out what's going on with the SDR flag. I've tried in the past to try to understand the VICE code but will leave that to someone more experienced with it. ;) I will share any conclusions I make once the results make a bit more sense to me.
thanks again!
Attached are some more tests with different baud rates of Timer A that have been tested and pass on real hardware.
I've managed to fix Z64K that passes all the attached tests without breaking anything else including Krill's c128 burst loader and the UP9600 modem. I've tried to do the same for VICE but I just don't understand VICE's CIA code enough to be able to apply a fix.
I've included in the attached archive a patch of my attempt to fix VICE which should allow all shift register tests to pass after someone, who understands how VICE's timing works, applies a 4 cycle delay before setting the ICR's SDR flag . The patch doesn't break anything I'm aware of that doesn't require the actual transfer of bits. Athena and all of the shift register tests that previously passed in the VICE test repostory still work with the patch.
** WARNING ** My patch does break burst mode and userport RS232 in VICE because I don't understand how VICE updates the SP and CNT states. In theory the logic should allow 2 bytes to be written directly after each other to the SDR where the RS232 should be able to transmit all 16 bits. There's some hints in my patch where the CNT/SP transitions should happen. The patch in it's current form SHOULD NOT and is not intended to replace the current revision of the VICE's CIA code. Someone who understands the VICE source much better than me will need to apply a 4 cycle delay to the setting of the SDR flag and fix the CNT/SP transitions.
Sorry for late reply... i have prepared the new testprogs for the repo and testbench... and also tested on real C64s. to my surprise the supposed tests for "old" CIA all fail on my real C64 (two of them, not with old CIA of course). where do those dumps come from? actual C64s? or did you just assume the irq triggers one cycle earlier and created them in a hex editor? :) the test for "new" CIA all work correctly on those C64s for that matter!
and i copied the patch to patch #233 so it doesnt get lost and/or forgotten :)
Last edit: gpz 2020-06-17
Tests for new cia was tested on my real c64c
Tests for old cia was on my c128D.
I ran the irqdelay testprog as a quick test to confirm which cia each machine had.
The old cia tests will fail on new cia machines and vice versa. I will double check to make sure I sent you the correct bin files later today.
Last edit: William McCabe 2020-06-17
The strange thing is that... the dumps look correct (the "old" dumps are one byte offset as i would expect). however, the tests do fail on my C64s. and the "new" tests work fine (on two C64s, both with CIAs that absolutely require the "old" versions of other tests)
i also find it kinda surprising (and actually unlikely) that the -4,-5,-6 dumps are the same for old/new, but the others are not.
not sure how to interpret this... please double check :) if you still get different behaviour with that C128D, it'd be very interesting to know what exactly the markings of those CIAs say.
Ok, Yeah it's starting to sound like it might be something else affecting the results for the C128D. I just assumed it was different because of old CIA's. When i retest later today I'll open it up and grab the CIA markings and forward it on. :)
one thing you could try... use the other CIA for the test. it has an internal 1571, right? that means the shiftreg is connected to the IEC bus, and the CIA in the drive, etc. perhaps that distorts the result
I just retested on my c128D and confirm all the "old tests" pass using the compiled prgs in the cia-sdr-icr.zip file I provided above. -4 -5 -6 tests pass as well.
Yes, C128D has internal 1571. Sounds like a good test swapping of CIA's but I prefer not to risk damaging my working hardware if I can help it. :) I'll see if I can get some other c128 users to run the tests and share the results from their machines instead.
I opened up the C128D to confirm it uses MOS6526 4485 on the main motherboard . The 1571 uses a 6526A-01 4985 S.
uuuh dont swap the CIAs in the C128 ... change the test so it uses CIA1 instead of CIA2 =D CIA1 isnt connected to the serial bus, so that takes out that potential source for interference :)
Lol, Yeah I was just thinking that after I posted. Happy to try that. :)
Just tested using CIA1 instead and get exactly same results on my C128D as the CIA2 tests. All the "old cia" tests pass. The dumps in the attached zip file are exactly the same as the previous zip file. I've only modified the source to use CIA1 instead of CIA2.
For completeness I just tested on my real C64c and all the "new cia" tests pass on for the cia1 version of the tests.
wow, thats seriously disturbing now. especially since your CIA is newer than mine (the other way around it'd make a bit of sense at least)
ok well, i did two things... first i made sure the problem isnt some instable behaviour of the test program. i changed the colors slightly and disabled interrupts permanently. see the attached .asm
then, i have run them all again on my c64 with "old" CIAs... and once again, very surprisingly, the "old" tests fail and the "new" tests do not. we either have found some really weird issue with your C128... or a third kind of CIA (mine have timestamp 3084 and 3384 ).
i dont have a 4485 CIA in my collection unfortunately, so i have made a zip with the testprograms for others to check (i will post on csdb)
edit: i also posted on csdb and lemon:
https://csdb.dk/forums/?roomid=7&topicid=143203
https://www.lemon64.com/forum/viewtopic.php?p=918494#918494
lets see... :)
Last edit: gpz 2020-06-18
Ok first result (from alwyz)
C64 NTSC
250507 Motherboard
6526 / 2283 - U1
6526 / 0583 - U2
Delay-old has green border
Delay-new has red border (fail)
4,5,6 all give green border
And here's where it gets interesting:
new-50 - green border
new-51 - green border
new-64 - green border
new-7 - green border
new-8 - green border
old-50 - red border
old-51 - red border
old-64 - red border
old-7 - red border
old-8 - red border
-> this matches my 3084/3384 chips!
@William MCabe is "MOS6526 4485" the only thing written on that chip? or anything extra?
found one 6526 with timestamp 2685 -> results like above (detects as "old", "new" pass, "old" fail)
another: CSG 6526 / 4389 216A -> detects as "new", "new" tests pass, "old" fail
Last edit: gpz 2020-06-18
C64
ASSY NO. 250466
U1 MOS 6526 2486 S
U2 MOS 6526 2486 S
delay2-new RED
delay2-old GREEN
4 GREEN
5 GREEN
6 GREEN
new-50 GREEN
new-51 GREEN
new-64 GREEN
new-7 GREEN
new-8 GREEN
old-50 RED
old-51 RED
old-64 RED
old-7 RED
old-8 RED
and one more: MOS 6526 / 4286 206A -> detects as "new", "new" tests pass, "old" fail
@William MCabe do actually both of your CIAs detect as "old" with the irqdelay2 program?
this is really starting to look strange :)
Yes, both CIA's report as old. I've run several old CIA specific tests including the ones from Lorenze-2.15 testsuite and they all pass.
I retested with the zip file you are sharing and the "old" CIA tests still pass, new fail on C128D. delay2-old GREEN
delay2-new RED
I've shared your post to https://c-128.freeforums.net/thread/858/cia-riddle-run-tests so hopefully get some results from some other C128's
I only looked at one of my CIA's related to orginal tests (U4 which is mapped to $dd00) to get the markings. There were no other markings on it. It's just got MOS 6526 4485. I have to remove disk drive etc to see the other one but considering results have been the same for both chips I will hold off on doing that for the time being, I will go to the extra effort of getting the markings off the other chip if no-one else shares the same results me. :)
Flat C128 - ASSY n/a - NTSC - SID 6581
U1 .. MOS 6526 4485
U4 .. MOS 6526 2684
delay2-new .. RED
delay2-old .. GREEN
4/5/6 .. all GREEN
new-7/8/50/51/64 .. all RED
old-7/8/50/51/64 .. all GREEN