|
|
Post by willymanilly on Oct 13, 2018 21:43:44 GMT
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?
No, I haven't tested that theory yet. I will look into it. Not sure if it will work that way otherwise RFO would have been affected. RFO waits for VBLANK to go low before changing from 1 -->0 the same as your 8 x 1 method uses. Where RFO is different is it changes back to 1 while VBLANK is still low. Definitely worth testing though. The VDC is full of surprises so I'm not ruling anything out.  |
|
|
|
Post by willymanilly on Oct 13, 2018 23:18:25 GMT
I've done some preliminary testing of doing the reverse method and VBLANK doesn't seem to toggle which freezes the test program. I'm assuming CTH needs to be higher than 0 in the VBLANK area to be able to set VBLANK low again. I've also tried switching CTH from a higher to lower value and I haven't been able to trigger the extra lines. I've tried adjusting the vertical smooth scrolling register and that doesn't have any influence on the results...
|
|
|
|
Post by tokra on Oct 14, 2018 8:16:36 GMT
I'm assuming CTH needs to be higher than 0 in the VBLANK area to be able to set VBLANK low again. But that is exactly what my current VDC-FLI-mode is doing. I wait for VBLANK and then switch from 0 to 1 (or something else). |
|
|
|
Post by willymanilly on Oct 14, 2018 8:54:09 GMT
I'm assuming CTH needs to be higher than 0 in the VBLANK area to be able to set VBLANK low again. But that is exactly what my current VDC-FLI-mode is doing. I wait for VBLANK and then switch from 0 to 1 (or something else). Yes, I agree. What I'm saying is if you reverse the setting of the character total height (CTH), i.e. attempt to switch from 1 (or something else) to 0 at VBLANK, VBLANK will stay set until you change the CTH to a non zero value.
I've updated the test to include the VBLANK time in the results. The calculations of the scan lines are the same as the total frame time discussed earlier in this post. The first 6 tests are the same as the previous version. Test 7 is the same as test x except Y smooth scrolling is set to 1. Tests 8-10 transition from CTH of 2 to 1 using Y smooth scrolling values of 0, 1, and 2. The very last test is the test machine default VDC register values. My test machine has an old version of the ROM that defaults to 320 scan lines and sets total vertical characters to 126.
I've had to update the model Z64K uses considerably to incorporate the above. I'm just doing some testing and will replace the unreleased version of Z64K I have in the Z128K Emulator beta testing, bug report and feature requests thread shortly.
I haven't included the test that reverses the transitions because it locks up the program.
The source needs a major cleanup but it should be reasonably clear I hope.
Attachments:VDC81.asm (4.88 KB)
VDC81.prg (1.05 KB)
|
|
|
|
Post by willymanilly on Oct 14, 2018 11:14:48 GMT
I also noticed a terrible error in VDC Mode Mania V1.11 that must have slipped in there. In line 3000 it tries to load and set the "settings.itf"-file. This will set register 7 to a totally wrong value if the file exists. This one had me mystified for a while. I created a .d81 image of your VDC mode mania that fits all the first 4 modes on it so I could avoid swapping disks all the time when testing on Z64K. That explains why I was seeing a value of $62 being written to register 7. I always wonder why the VDC needed that obscure value for 8 x 1 mode and I used a hack in Z64K to sync correctly. With the sd2iec version I use on real hardware, line 3000 is correct in the basic program.
I just checked on real hardware with the error version of line 3000 and I'm actually glad to see it display how Z64K displays it without the hack. It shows the image split in the middle with top of image at bottom of screen and bottom of image at top of screen. I guess I can safely remove that hack now.
BTW happy to share .d81 image, of course with line 3000 fixed.
|
|
|
|
Post by tokra on Oct 14, 2018 13:06:49 GMT
Yeah, sorry for that, no idea how that went in there. It wasn't in the version before that. I don't really need a .d81, but thanks.
Regarding the 8x1 switch, I think I understand now, that you must switch from $e0 back to another value while in VBLANK, to allow for VBLANK to appear at all.
One more idea: You could measure the number of cycles from the end of VBLANK to the start of the next VBLANK, deduct about 50-100 cycles and do the switch like that
1. wait for VBLANK to end
2. set CTH to $e0
3. wait number of cycles to next VBLANK - 50
4. set CTH to $e1 (or $e2 ... $ff)
5. check for keypress (to quit gfx-mode)
6. wait 50 cycles (to make sure VBLANK has started)
7. goto 1
Doing it like that you would not have to set up the CIA-interrupt and auto-correction-logic since it automatically synchronized with step 1. For simple image-display this should be enough.
|
|
|
|
Post by willymanilly on Oct 14, 2018 20:45:31 GMT
One more idea: You could measure the number of cycles from the end of VBLANK to the start of the next VBLANK, deduct about 50-100 cycles and do the switch like that 1. wait for VBLANK to end 2. set CTH to $e0 3. wait number of cycles to next VBLANK - 50 4. set CTH to $e1 (or $e2 ... $ff) 5. check for keypress (to quit gfx-mode) 6. wait 50 cycles (to make sure VBLANK has started) 7. goto 1 Doing it like that you would not have to set up the CIA-interrupt and auto-correction-logic since it automatically synchronized with step 1. For simple image-display this should be enough. Yes, that should work! I doubt I'll find time today but I should have some free time tomorrow after my day job to test this out. |
|
|
|
Post by willymanilly on Oct 15, 2018 2:53:41 GMT
I was just thinking of another thing to try is changing changing the VSYNC position and Vertical Displayed value in a way so they are not triggered on every second frame. In theory this should join 2 screens into one by removing the vertical sync for one frame, similar to what the VIC version of Risen from Oblivion does on the Boris Vallejo image....
|
|
|
|
Post by willymanilly on Oct 16, 2018 5:20:35 GMT
I've been focused on implementing everything into Z64K we've discovered so far while discussing the 8 x 1 mode so I haven't had anytime to work on your suggestions. One thing I have noticed which I am sure you already know is if you set register 7 to a value of 3 instead of 2, the extra lines from the overflow fills the bottom of the screen instead of the top. This is obvious because the amount the image moves up. With this information and the VBLANK time in my test programs, we can assume the extra lines occur at screen row counter 2 with the program you use to trigger the 8 x 1 trick. Once I create the additional tests I should be able to conclude a reasonably accurate VDC model where we should be able to determine an increased image resolution for NTSC 8 x 1. PAL is already maxed out I think unless we trying merging 2 frames into one as discussed in my previous post. That would be assuming the VDC will actually allow that to happen though. |
|
|
|
Post by tokra on Oct 17, 2018 13:18:32 GMT
Ah, thanks for the observation regarding register 7. I noticed this myself but had no explanation. Your idea of mering two frames would only be useful for expanding the 8x1-mode for PAL I guess?
Another thing: Why do you think interlace-text-mode with attributes has graphics corruption? I noticed I can get rid of this with value 0 to register 36. But since interlace is essentially just two fields, why should each rasterline need more time than non-interlace mode?
|
|
