|
Post by willymanilly on Nov 25, 2020 12:57:47 GMT
The VDC is definitely one weird beast. I've had a quick look at this to see if I can work out what's happening. In summary my observations so far for bitmap mode:- - If register 27 >0 increase the attribute latch value by 1.
- After the first attribute row has been read increase the attribute pointer by (register 27)-2 if (register 27) >0 in addition to the normal increase of the attribute pointer by register 27.
I've updated Z64K's model (the new Version 2 only) with the above. Let me know if you notice it breaks anything else. On a side note this actually makes the VDC FLI image in Risen from Oblivion work without any hacks!
I'm guessing the other oddities are related to timing issues that wendling pointed out. They are not currently emulated. I will need to do a lot more testing to have enough info to be able to update the emulator model to show those.
This post has my interest and I definitely welcome other peoples insights to what is happening or any other test programs in bitmap mode with register 27 greater than 0.
Screenshot from updated Z64K
|
|
|
Post by willymanilly on Jul 16, 2020 10:52:58 GMT
Do all 856x based machines, which would include all C128's, display grey dots when updating VICII color registers while they are being displayed? I'm assuming they do. My 8566 equipped C128D definitely does display the grey dots while my 6569 equipped C64 doesn't show them at all. I know the VIC version of Risen From Oblivion puts this "feature" to good use in a couple parts of the demo. Here's a simple program from www.lemon64.com/forum/viewtopic.php?t=29996 which shows the glitch in action that can be run in either c128 or c64 mode. 1000 lda #0 1002 sta $d021 1005 sta $d020 1008 jmp $1002
10 fort=0to10:readx:poke4096+t,x:nextt 20 data169,0,141,33,208,141,32,208,76,2,16 30 sys4096
|
|
|
Post by willymanilly on Jun 20, 2020 21:40:08 GMT
Thank you. Looks like we have another timestamp that shows the same behaviour as 4485! BTW, new tests have been updated. They're the same as the previous ones, they have just been renamed to reflect the observations so far and also include tests for the cia1. The previous tests only tested cia2. If anyone is interested you can see where these results are being discussed on the VICE bug report linked above or on CBM Hackers at cbm-hackers.2304266.n4.nabble.com/a-CIA-riddle-please-run-these-tests-td4669242.html
|
|
|
Post by willymanilly on Jun 19, 2020 11:47:46 GMT
Thankyou. I'll share these results on the bug report. So far it's looking like only MOS 6526 with a timestamp of 4485 pass with the "old" tests. All other CIA's regardless if they are old version or new pass with the "new" CIA tests.
|
|
|
Post by willymanilly on Jun 18, 2020 19:44:01 GMT
Copied from csdb.dk/forums/?roomid=7&topicid=143203. Grateful if someone can take the time to run the tests mentioned below on real hardware. So far my C128D is the only machine tested that passes with the "old" CIA tests. The tests need to be run in C64 mode. "While debugging a certain thing in VICE [1] we discovered a strange thing which doesnt quite match what we thought we knew about the CIAs. Perhaps there is actually a 3rd kind of CIA in the mix We need a couple people to run a few test programs [2] and report the results to find out what we are really looking at.
Please first note down:
- what machine are you testing (c64/c128) - what ASSY is it (ASSY number on the motherboard) - what CIAs are on the board. write down ALL markings (eg: MOS 6526 / 1888 216A)
Now run the "delay2-new" and "delay-old" programs. Green border means "test passed", and will generally tell if you have a "new" or "old" CIA. (Contrary to popular belief this can NOT be reliably determined from whats written on the chip)
After that, run the other programs.
4.prg 5.prg 6.prg should pass on any type of CIA (green border means passed) *-new.prg should pass on "new" CIA and fail on "old" CIA *-old.prg should pass on "old" CIA and fail on "new" CIA
To confirm the above, make sure to really run ALL programs and please tell which fail and which do not. Especially interesting are results that are different from the above expected behaviour. Also interesting are tests done on C128D and/or using a CIA with timestamp 4485 as William used in that bug report.
Thanks!
[1] Bug report: sourceforge.net/p/vice-emu/bugs/1219/ [2] Test programs: sourceforge.net/p/vice-emu/bugs/_discuss/thread/538e31942f/ba33/attachment/cia-shiftregister-tests.zip
|
|
|
Post by willymanilly on Jun 15, 2020 0:08:53 GMT
I can see a couple of possible issues with your code. - What assembler are you using? Is it case sensitive? I notice you have declared LOBYTE but reference it as lobyte.
- I can't see anywhere in your code where you actually read/write to the VDC registers. I assume you intend vdcstatus and vdc_rw to be references to them. If that is the case then you will need to assign vdcstatus and vdc_rw the actual VDC register locations. Depending on your assembler it should be something like the following.
vdcstatus = $d600 vdc_rw = $d601
|
|
|
Post by willymanilly on May 1, 2020 9:24:06 GMT
The lower scroller is flickering on my machine. The background colors behind the text is skewed and moves a bit randomly. Upper scroller and moving color blocks looks correct. That's exactly how it looks on my machine. Yes, I'm guessing the developers of the demo were assuming all C128's had a different value for that line of the @ symbol compared to a standard c64. A quick basic check in C64 mode to see what value your machine has for the check is:- 10 poke 56334,peek(56334)and254 20 poke 1,51 30 print peek(53248+5) 40 poke 1,55 50 poke 56334,peek(56334)or1
If it prints out a value of 98 (#$62) the check will fail on your machine.
|
|
|
Post by willymanilly on May 1, 2020 4:26:58 GMT
I read from somewhere that the c128 and c64 charroms might be different. Doesn't seem to be different on my real hardware where it matters for this demo though. I found a simpler way to run the VDC part in emulators and hardware that fails the check. It is as follows. - At the fail screen press runstop+restore
- poke 8461,0
- sys 8448
On my hardware the bottom scrolling logo is jittery, even more so than Z64K. Otherwise seems very similar to how Z64K handles it. I would be interested in how it displays on other peoples systems and to know if you had to use the bypass to run it.
|
|
|
Post by willymanilly on Apr 30, 2020 23:43:58 GMT
A way to bypass the check in VICE and Z64K is to set a break point at 2100 in the machine monitor before running the VDC-demopart directly in c64 mode. The following commands work in both VICE and Z64K
bk 2100 x
When the breakpoint is triggered enter the following. note: You will need to press enter twice to exit assemble mode after the first of the following commands.
a 210c cmp #$61 x
|
|
|
Post by willymanilly on Apr 30, 2020 23:20:53 GMT
BTW the emulator check seems to be simply a test of the character ROM.
.c:2109: 20 fc 33 JSR $33fc .c:210c: c9 62 CMP #$62 .c:210e: d0 03 BNE $2113 .c:2110: 4c 10 34 JMP $3410 ;FAIL
.c:33fc: a9 ff LDA #$ff .c:33fe: 85 00 STA $00 .c:3400: a9 33 LDA #$33 .c:3402: 85 01 STA $01 .c:3404: ad 05 d0 LDA $d005 .c:3407: a2 37 LDX #$37 .c:3409: 86 01 STX $01 .c:340b: a2 07 LDX #$07 .c:340d: 86 00 STX $00 .c:340f: 60 RTS
|
|