|
|
Post by willymanilly on Oct 12, 2018 18:29:54 GMT
Interesting that your emulator already shows the corruption (Figure 1). Any idea what causes this? I notice if I add 60 (horizontal display value) to the screen memory starting address, the images appears fine using the following values. i.e. Change the 16th data item in line 3020 from 8 to 68. Change register 4 to 229
Change register 6 to 228
Change character Total Height back to default $01 when transitioning from character height 0.
This mode seems to only generate 232 scan lines so I conclude it doesn't trigger the overflow for some reason. (Test program reports 38b4).
Increasing the character total height to a value larger than 1 without changing the other values triggers the overflow. For example setting it to 2 will give 264 scan lines (Test program reports 4086) , same as C128 VDC NTSC system default. Note the screen memory starting address should be set back to it's original value if you changed it. i.e. 16th data item in line 3020 should be 8.
|
|
|
|
Post by tokra on Oct 12, 2018 22:41:55 GMT
Hmm, while I can confirm the values of your test-program, the values make no differnce in VDC Mode Mania. The image is displayed alright with the screen-memory add, however my TV still says it's 60 Hz and the bottom lines are still missing.
I entered 255 for reg 4 and 254 for reg 6 in your test-programa and this gives a values of $3fxx, pretty close to $4048, so theoretically it should display the full image at 60 Hz, however this still shows as 56 Hz on my TV, so I suppose it still adds the extra lines... hmmm.
|
|
|
|
Post by willymanilly on Oct 13, 2018 0:26:43 GMT
Hmm, while I can confirm the values of your test-program, the values make no differnce in VDC Mode Mania. The image is displayed alright with the screen-memory add, however my TV still says it's 60 Hz and the bottom lines are still missing. I entered 255 for reg 4 and 254 for reg 6 in your test-programa and this gives a values of $3fxx, pretty close to $4048, so theoretically it should display the full image at 60 Hz, however this still shows as 56 Hz on my TV, so I suppose it still adds the extra lines... hmmm. I think my test program could possibly fail with lower character values because it doesn't have enough cycles to complete the display of the results before the end of the VBLANK. I think it needs about 2 scan lines to calculate and display the result. I will check and update the test program to avoid this and post up shortly. |
|
|
|
Post by willymanilly on Oct 13, 2018 1:39:19 GMT
OK, I've updated the test program and am now getting much better and expected results.
The first 3 lines are the same as the original tests. I've also included some additional tests as we've discussed earlier.
I have tabulated the values of the test in the following table. I'm much happier with these results because I won't need to update the model of the new VDC emulation at the moment because it shows exactly the same results as real hardware.
Thanks Tokra for confirming the refresh rates. I don't have any other method to confirm refresh rates so your information was very useful.
For the test program, I moved all the calculation of the results out of the VBLANK area so the results should have plenty of time to calculate and display now, assuming VBLANK stays active at least 47 VICIIe cycles. I might need to use 2Mhz mode and zero page locations if we discover an instance where VBLANK time is shorter but I'm assuming VBLANK will always remain active at least 1 VDC scan line so I can't see this being an issue. 
| Test | Horizontal Total | Vertical Total | Vertical Displayed | Character Total Height | Scan lines
| | 1 Default | 126 | 255 | 254 | 7 | 295
| | 2 PAL | 127 | 255 | 254 | 24 | 312
| | 3 NTSC | 126 | 223 | 222 | 7 | 263
| | 4 NTSC | 126 | 228 | 227 | 2 | 263
| | 5 NTSC | 126 | 229 | 228 | 1 | 263
| | 6 ? | 126 | 255 | 254 | 1 | 289
|
Attachments:VDC81.asm (3.33 KB)
VDC81.prg (825 B)
|
|
|
|
Post by tokra on Oct 13, 2018 8:31:24 GMT
Thanks, will try this later tonight. Maybe you could make the test-program more flexible, by asking for user-data input to regs 4, 6 and 9?
Also, does it reset the VDC before or after? I was thinking about trying to play with register 3 (upper 4 bits) vertical sync-width.
I must confess my TV only shows rounded vertical frequency Hz-numbers. I could crack out my XVGA-Box (GBS 8219), which seems to display the frequency a little more accurately, but this still is not "valid" test-equipment. If I remember correctly someone used an osicalltor to measure the frequencies back in the old-forum-days.
|
|
|
|
Post by willymanilly on Oct 13, 2018 8:53:32 GMT
I must confess my TV only shows rounded vertical frequency Hz-numbers. It was good enough to flag there was something wrong with the test program. Using the CIA timer method should be very accurate now. I plan on updating the test to include VBLANK time and will add options to allow customised tests. I will be putting more focus on to that and the VDC split program once I finish testing and release the new VDC emulation which I am hoping to have completed tomorrow. |
|
|
|
Post by tokra on Oct 13, 2018 13:39:13 GMT
Still thinking about how to avoid the extra 32 lines. Maybe the method to activate the 8x1 mode can be optimized... Can you elaborate why you think those lines appear? Is it because of the switch from 2 to 1 lines while the internal Counter ist at 2 and waiting for 1 and as such will overflow? In that case it shoul be possible just to wait for 1 VDC-rasterline so that the overflow does not happen.
|
|
|
|
Post by tokra on Oct 13, 2018 19:42:33 GMT
Maybe you can amend the vdcsplit-program to confirm this. If you switch from character-total-height 2 to 1, there is always the chance that the internal row-counter is at 2 at the moment of the switch and the internal counter is waiting for it to switch to 1, which will not happen and as such it will overflow after the internal maximum row-height of 32 is reached.
Generally speaking switching from a higher value to a lower value may cause this. Technically you should just do the switch from a higher to a lower value when you are still on the beginning of the lower-value-raster-line, so the next switch will be recognized in time.
Do test this theory I suggest vdcsplit switch from $e7 to $e1 within a visible raster-line in the middle of the screen. By changing the raster-line (or even horizontal-position) where the split occurs you should immediately see on the screen if an extra 32 lines are added in between or not.
|
|
|
|
Post by willymanilly on Oct 13, 2018 21:00:36 GMT
From every test I've tried, the extra lines always appear when switching from 0 back to any number. Adding a delay of 1 or more scan lines does not seem to make any difference.
One thing I notice Risen from Oblivion does different is it switches from 0 --> 1 on the scan line just before the VBLANK is set which doesn't seem to trigger the extra 32 lines. The side effect for RFO method is the attribute memory starting location is shifted by 3 bytes when latched.
To do the RFO method you will need to use exact timing to ensure you get the correct VDC line because waiting for VBLANK will be too late. RFO uses interrupts with both of the CIA 1 timers to manage exact timing. See code from RFO that handles this below. For this to work reliably we'll need to find first determine the VICIIe exact speed in 1 Mhz mode. We will also need to autocorrect the timing to avoid the VICIIe becoming out of sync with the VDC timing. I was actually planning on including this exact function in my VDC split program which will use the light pen to stabilise timing. When I do, I will see if I can apply the RFO method to your 8 x 1 image using NTSC screen dimensions.
I will try your suggested method as well to see if that works. In theory it sounds like a plausible solution but the VDC is proving to have heaps of surprises in how it operates.
fc80: 48 PHA
fc81: ad 0d dc LDA $dc0d
fc84: 4a LSR
fc85: 90 50 BCC $fcd7
fc87: a9 20 LDA #$20
fc89: 2d 00 d6 AND $d600
fc8c: d0 fb BNE $fc89
fc8e: a9 19 LDA #$19
fc90: 8d 0e dc STA $dc0e
fc93: 8a TXA
fc94: 48 PHA
fc95: 98 TYA
fc96: 48 PHA
fc97: a2 0a LDX #$0a
fc99: ca DEX
fc9a: d0 fd BNE $fc99
fc9c: a9 83 LDA #$83
fc9e: 8d 0d dc STA $dc0d
fca1: a9 19 LDA #$19
fca3: 8d 0f dc STA $dc0f
fca6: a9 09 LDA #$09
fca8: 8d 00 d6 STA $d600
fcab: a9 00 LDA #$00
fcad: 8d 01 d6 STA $d601
fcb0: 20 03 e0 JSR $e003
fcb3: e6 07 INC $07
fcb5: ad d5 fc LDA $fcd5
fcb8: 0d d6 fc ORA $fcd6
fcbb: d0 07 BNE $fcc4
fcbd: a9 01 LDA #$01
fcbf: 8d d7 81 STA $81d7
fcc2: d0 0b BNE $fccf
fcc4: ad d5 fc LDA $fcd5
fcc7: d0 03 BNE $fccc
fcc9: ce d6 fc DEC $fcd6
fccc: ce d5 fc DEC $fcd5
fccf: 68 PLA
fcd0: a8 TAY
fcd1: 68 PLA
fcd2: aa TAX
fcd3: 68 PLA
fcd4: 40 RTI
fcd5: 8f 01
fcd7: a9 00 LDA #$00
fcd9: 8d 0f dc STA $dc0f
fcdc: a9 02 LDA #$02
fcde: 8d 0d dc STA $dc0d
fce1: a9 09 LDA #$09
fce3: 8d 00 d6 STA $d600
fce6: a9 01 LDA #$01
fce8: 8d 01 d6 STA $d601
fceb: 68 PLA
fcec: 40 RTI
|
|
|
|
Post by tokra on Oct 13, 2018 21:18:55 GMT
From every test I've tried, the extra lines always appear when switching from 0 back to any number. Adding a delay of 1 or more scan lines does not seem to make any difference.
My thinking is that the extra lines appear on the OTHER case - switching from "any number" back to 0 - since only then the overflow should appear. Did you test that? Or is the VDC just playing hardball again?
|
|
