News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_Cwiiis

Trouble using overscan mode

Started by Cwiiis, 22:54, 30 August 21

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Cwiiis

I'm experimenting and trying to use overscan mode. Setting the registers goes fine and I can see the correct video mode. I've chosen banks 2 and 3 (so &8000-&FFFF) as my screen area, but it seems when I clear bank 2, I end up causing the machine to reset.

I assume I must be overwriting the stack, so my first thought was to just ld sp,&7FFF to have it grow backwards from the end of bank 1 (my program is at &1200 at the moment and does very little, so I'm nowhere near there), but changing the stack pointer results in more crashing/odd behaviour. Perhaps this is an interrupt handler going awry? I'm using interrupts, but I've disabled the firmware interrupt handler by writing &C9FB to &0038.

Does anyone have any tips for me? I can attach code/answer questions if it isn't obvious what's happening from this description.

GUNHED

The area between &A700 and &BFFF contains the RAM parts of the native OS. And the stack. So don't use it.
Usually people use &4000-&7FFF and the regular screen for 32 KB V-RAM (you need to switch using some Z80 code though). For my productions I used blocks 0 and 3 (needs to use interrupt mode 2 though and a proper OS).
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

andycadley

If you use ram from &8000 onwards, you need to make sure that you aren't calling any firmware routines. You'll also need to make sure that the lower ROM is disabled, or you will potentially run into the issue of an interrupt going to the ROM version of the handler rather than your stub routine.

Cwiiis

Quote from: GUNHED on 00:21, 31 August 21
The area between &A700 and &BFFF contains the RAM parts of the native OS. And the stack. So don't use it.
Usually people use &4000-&7FFF and the regular screen for 32 KB V-RAM (you need to switch using some Z80 code though). For my productions I used blocks 0 and 3 (needs to use interrupt mode 2 though and a proper OS).
The regular screen being the bank starting at C000? I thought the used banks had to be continguous[1], but you're saying to use bank 1 and bank 3 - how do you go about this?

[1] https://www.cpcwiki.eu/index.php/Programming:Overscan

GUNHED

You can use an interrupt to switch between banks.
There are examples at: http://www.cpctech.org.uk/


Here an example for screens at 0 and &C000:



https://www.youtube.com/watch?v=zBXRbDGjYYQ
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

ComSoft6128

No joy with the link I'm afraid :(

Cwiiis

Quote from: GUNHED on 15:23, 01 September 21
You can use an interrupt to switch between banks.
There are examples at: http://www.cpctech.org.uk/


Here an example for screens at 0 and &C000:



https://www.youtube.com/watch?v=zBXRbDGjYYQ



There's quite a lot of source that isn't that highly commented on that site, is there a specific example you're thinking of? I guess this involves changing a CRTC register after a particular scanline, but 16k doesn't divide evenly when a scanline is 384 pixels, so I'm not sure how this would work exactly? I suppose you could move that last scanline towards the end of the adjacent previous bank, but this is starting to sound like a bit of a nightmare :)




For my particular case, I really don't care where my program is or about using firmware functions (or at least, I don't mind some setup / teardown to use them), but I can't seem to figure out a safe way of setting up a 32k screen. Do I need some kind of bootstrap?

Cwiiis

Quote from: ComSoft6128 on 15:45, 01 September 21
No joy with the link I'm afraid :(




The site uses a self-signed cert, I had to use Chrome (Firefox won't let you view sites with self-signed certs) and I had to use the .de address - here's the link that works ok in Chrome if you bypass the security warnings: https://cpctech.cpcwiki.de/source.html

GUNHED

Can't find my 'examples' right now sadly. In case it's of any help have a look at my Giana Sisters Soruce Code (Vortex format, 704 KB, use ParaDOS, better VaraDOS or X-DDOS for drive B). Good luck!
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

Longshot

Hi.
The Convimgcpc tool on PC, written by Demoniak, creates a 32k file from #200, which does not overwrite the system (its entry point is at #811 to update CRTC colors and registers).
The CRTC format of the screen is as follows:
R1 = 48 (width)
R2 = 50 (horizontal positioning)
R3 = 9 (but you can put 6 instead)
R6 = 34 (272 lines)
R7 = 35 (vertical positioning)
R12 = 13 (00001101) activation of overscan bits and start of screen at #200
R13 = 0
Rhaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!!

Cwiiis

Quote from: Longshot on 18:46, 01 September 21
Hi.
The Convimgcpc tool on PC, written by Demoniak, creates a 32k file from #200, which does not overwrite the system (its entry point is at #811 to update CRTC colors and registers).
The CRTC format of the screen is as follows:
R1 = 48 (width)
R2 = 50 (horizontal positioning)
R3 = 9 (but you can put 6 instead)
R6 = 34 (272 lines)
R7 = 35 (vertical positioning)
R12 = 13 (00001101) activation of overscan bits and start of screen at #200
R13 = 0
R3 is horizontal/vertical sync width, the wiki thinks this should always be more than 8... Setting modes already, I haven't needed to change it at all (default is 142,  i.e. 8,14), what purpose does it serve here? Also, wouldn't 1101 make the screen start at #100 (256)? And if its entry point is #811, doesn't putting the screen in banks 0 and 1 overwrite the program? Or is that beyond a scanline, so safe for a few bytes?

Longshot

#11
What is stated in the wiki is incorrect. ;D

The maximum duration of the HSYNC processed by the GATE ARRAY for horizontal image synchronization is 6 µsec.
Also in the context of displaying an image, it is useless to have R3> 6.

You must not leave 14 either, otherwise CRTC 2 (Motorola) will not be able to properly process its VSYNC as it will occur during HSYNC  because R2 is equal to 50 to center the image. From C0=50, if R3 is 14, the VSYNC test will occur during HSYNC.The absence of a signal will cause the vertical desynchronization of the image on this CRTC.

Finally, the value 8 for the number of lines of the VSYNC (top quartet of R3) is not a problem in your case, but should be avoided in general because only CRTC 0, 3 and 4 can manage a variable number of lines. Leaving 0 causes all CRTCs to generate a 16-line VSYNC. All equals.

The screen starts at #200, because the CRTC address is in words. So you have to multiply by 2 the CRTC pointer.


Finally, the Demoniak program is hidden in a filler. Indeed, if you have 48x2 = 96 bytes per line, characters of 8 lines.
The screen starts at 512 (#200), and there are 2048-512 = 1536 bytes (#600) left.
1536/96=16 char lines for the first 16kb page + a 32 byte filler not displayed, in which is the code.
Rhaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!!

Cwiiis

Quote from: Longshot on 21:20, 01 September 21What is stated in the wiki is incorrect. ;D The maximum duration of the HSYNC processed by the GATE ARRAY for horizontal image synchronization is 6 µsec. Also in the context of displaying an image, it is useless to have R3> 6. You must not leave 14 either, otherwise CRTC 2 (Motorola) will not be able to properly process its VSYNC as it will occur during HSYNC  because R2 is equal to 50 to center the image. From C0=50, if R3 is 14, the VSYNC test will occur during HSYNC. The absence of a signal will cause the vertical desynchronization of the image on this CRTC. Finally, the value 8 for the number of lines of the VSYNC (top quartet of R3) is not a problem in your case, but should be avoided in general because only CRTC 0, 3 and 4 can manage a variable number of lines. Leaving 0 causes all CRTCs to generate a 16-line VSYNC. All equals. The screen starts at #200, because the CRTC address is in words. So you have to multiply by 2 the CRTC pointer. Finally, the Demoniak program is hidden in a filler. Indeed, if you have 48x2 = 96 bytes per line, characters of 8 lines. The screen starts at 512 (#200), and there are 2048-512 = 1536 bytes (#600) left. 1536/96=16 char lines for the first 16kb page + a 32 byte filler not displayed, in which is the code.


Thanks, that's super helpful! That illuminates quite a lot :)

I had a look at SmartPlus's display bas/asm and it does much the same thing. It uses these CRTC register settings:

&1: &30 (H displayed - 48)
&3: &85 (H sync - 8, V sync - 5)
&2: &32 (H pos 49)
&7: &23 (V pos 35)
&6: &22 (V displayed - 34)
&C: &D (%1101 - Bank 0, 32k, &100 word offset)
&D: 0 (Low offset)

It loads the assembly program to &8000 - it loads the image data into &C000 and &4000, but copies &C000-&FFFE to &0000 once it jumps to the assembly - this bit I don't understand, shouldn't it copy to &0200? It also copies &60 bytes from &7FA0 to &3FA0 - I've no idea what that's about... I guess that's after a scanline, but it doesn't access it, so I'm at a loss... It disables interrupts too, though if there's no chance of overwriting &0038/&0039, it should be ok to use them I suppose?

I'm still not reaching a full understanding here, hopefully some of this source will have the answer!

Cwiiis

Thanks to all of this I finally have things working - program at 8000, screen in banks 0-1 with a &200 offset... Now I just need to figure out the right mapping again :)

Longshot

&32 = 50 (not 49)
&85 contains 2 bad values. 5 is insufficient. And this causes the image to shift to the right because the HBL period is too short.06 is the correct value.

I don't know the SmartPlus tool, and how it structures its data. But if it copies & C000 to & 0000 with R12 = & D then it means that there is no data displayed between & C000 and & C1FF.

Perhaps the zone that is copied replaces the line that was initially occupied by the transfer code called at the beginning. You can try removing this transfer from a 96 byte line to see if there is a line missing in the middle of the image.

Overwriting the area between 0 and & 3B is not important if interrupts are disabled.
The program can also contain between & C000 and & C03B the copy of what is normally in & 0.
Rhaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!!

Powered by SMFPacks Menu Editor Mod