GX4000 scan line doubling

[andycadley]

Kudos to @arnoldemu for the basic idea:

Today I tried to double the pixels vertically on a plus.
I wasn't successful but I will tweak the timing a bit more when I have time.

The method I used:

1. standard raster interrupts.
2. wait for vsync start
3. HALT (now 2 HSYNCs after start of vsync)
4. Enable DMA channel 0.

DMA channel 0 processes a pause instruction to wait until the first line of the display.
Then 1 interrupt for each line, with a stop/int at the end.

5. Interrupt handler checks if DMA interrupt
6. If it is, it sets the vertical soft scroll. It toggles the value between 0 and &70 after each write:

What should this do?

VCC=0, RC=0, SSCR=0 -> RA output no change (RA output = 0)
VCC=0, RC=1, SSCR=&70 -> RA output (1+7=8 but because only lower 3 bits are output) (RA output=0)
VCC=0, RC=2, SSCR=0 -> RA output no change (RA output = 2)
VCC=0, RC=3, SSCR=&70 -> RA output (3+7=10 but because only lower 3 bits are output) (RA output=2)
VCC=0, RC=4, SSCR=0 -> RA output no change (RA output = 4)
VCC=0, RC=5, SSCR=&70 -> RA output (3+7=12 but because only lower 3 bits are output) (RA output=4)
VCC=0, RC=4, SSCR=0 -> RA output no change (RA output = 6)
VCC=0, RC=5, SSCR=&70 -> RA output (3+7=14 but because only lower 3 bits are output) (RA output=6)

The display is therefore like this:

C000
C000
D000
D000
E000
E000
F000
F000
C050
C050
D050
D050
E050
E050
F050
F050

So going to next line looks a bit like this:

Code Select Expand


ld a,h
add a,&10
ld h,a
ret nc
ld a,l
add a,&50
ld l,a
ld a,h
adc a,&c0
ld h,a
ret


With this method you can change height of screen and vsync position.

This appears to be the only way to do it using soft scroll.

I wanted to use dma interrupts so I can interrupt each line so the code can be used in a game for example.

It almost worked.

I will try again with it, perhaps I can make it work next time.

It almost worked. 

The missing piece in the puzzle is the way the Plus machines cache MA as part of their hardware scrolling, since your theory was never generating a value where RA = CRTC R9, things don't quite work and scanlines start getting repeated. At first I thought you could go the other way and instead scroll the screen in the other direction. Unfortunately that means you get two lines in a row where RA = R9 and so MA gets reloaded too often, messing everything up.

The solution? Toggle the value of CRTC R9 at the same time as fiddling the SSCR, such that when SSCR = 0, R9 = 7 and when SSCR = &70, R9 = 6. Now everything lines up nice and neat and we get a super-chunky resolution display.

Attached is a Z80 source file and an example Cart (which displays the Navy Seals screen, taken straight from the B-Asic disc!) but in chunky vision! To keep things simple I just use the PRI for timing interrupts, the equs near the top can be tweaked to run the effect over part of the screen.

Tested on a real GX4000. Doesn't seem to work in WinAPE.

[CraigsBar]

Well it works on an expanded 464plus and 6128pls as well


I have found WinAPE not to be the best CPR testbed. Many of the System carts I made as requested will just bootloop on WinAPE, but work fine on OSX Arnold or ACE under MorphOS.


Craig

[ssr86]

 
What is the overhead per frame for this?

[arnoldemu]

What is the overhead per frame for this?

looking at this code, it's all the processor time during the display.

I'll see if I can adapt it to use dma interrupts and then it'll be more useable I think in games.

[arnoldemu]

@andycadley:

Nice.

I was relying on the RC>=R9. This causes the MA to be cached too.

I think another problem I had was I was using DMA, I did that so other code could run code at the same time allowing games to use it more easily. I didn't seem to find enough time to acknowledge the interrupt (auto ack disabled), and write the appropiate value.

But, I'll give it another go with your modifications

EDIT: It didn't work on my wip arnold, but I've fixed that now. Time for another test program to confirm my fix is good.
I see the image repeated. I'll need to check that on gx4000 to see if that is exactly what it should be. Does makes sense and it's chunky

[Devilmarkus]

If this is the wanted result, I'm happy:

[arnoldemu]

If this is the wanted result, I'm happy:

looks better than the one I get 

[Devilmarkus]

Funny: For me WinApe crashes... ?!?

[Devilmarkus]

Any photo please from real GX4000 showing this screen...

[andycadley]

This is the result on the real thing (apologies for my crappy camera!)

[TFM]

This is the result on the real thing (apologies for my crappy camera!)

IMHO that's an excellent picture. One can see every pixel. Thumbs up!

[andycadley]

I think another problem I had was I was using DMA, I did that so other code could run code at the same time allowing games to use it more easily. I didn't seem to find enough time to acknowledge the interrupt (auto ack disabled), and write the appropiate value.

Yeah I was aiming more for just a rough proof-of-concept. Although given the number of registers you end up needing, the need to have the ASIC paged in throughout and time to acknowledge interrupts, I suspect it might be easier to interleave any other code in one big, carefully timed loop than to try and do it asynchronously.

[andycadley]

Funny: For me WinApe crashes... ?!?

Did it actually crash? On the version I have, which I think is the latest, it just turns the screen black. What it's appears it's actually doing (having played about in more detail) is repeating the first 8 lines of the screen each time because it never properly triggers moving on to the next character line.

[arnoldemu]

IMHO that's an excellent picture. One can see every pixel. Thumbs up!

@TFM: agreed.

@andycadley: I am really pleased you got it working and my ideas gave you inspiration.
Picture quality is fine, it's easy to see the pixels.

I thought the image would look like that, so I have a bit more testing work to do to fix it fully on arnold wip.

You are correct about the result from winape. Arnold had the same. I made it better, but it didn't look like that.

I think you're right about keeping the asic ram open all the time and the use of registers, but I'll give it a go anyway

If I can think up any other methods I'll share them as usual

[Executioner]

In order to fix this I can either do a heap of tests to find out exactly when the ASIC uses the incremented MA value, or you could tell me. Currently WinAPE matches when VLC = (SSC shr 4) xor 7 when HCC = HDISP.

[arnoldemu]

In order to fix this I can either do a heap of tests to find out exactly when the ASIC uses the incremented MA value, or you could tell me. Currently WinAPE matches when VLC = (SSC shr 4) xor 7 when HCC = HDISP.

I will when I can get it to display correctly in Arnold, I still don't know the full details.

[Executioner]

Funny: For me WinApe crashes... ?!?

You've probably got a ROM enabled or not using CRTC 3 with Plus enabled. I find it best to select a Plus profile first and disable all ROMs. WinAPE doesn't work with this because it repeats the first character row for the whole screen and the first character row is blank. It seems to never get the R9=SCC xor 7 match to increment the MA to the next character line.