I have been trying out using some Plus features for my demo with help from code at CPCtech and CPCRulez, but am having a few problems.
For example, if I setup the colour pallete in MODE 0 as the following:
;Setup CPC+ screen colours
org &8000 ;must not be between &4000 and &7FFF
start: di ;unlock ASIC
ld b,&bc
ld hl,sequence
ld e,17
seq: ld a,(hl)
out (c),a
inc hl
dec e
jr nz,seq
ei
ld bc,&7fb8 ;page-in ASIC registers to &4000-&7FFF
out (c),c
ld hl,colours ;copy colours into ASIC palette registers
ld de,&6400
ld bc,17*2
ldir
ld bc,&7fa0 ;page-out asic registers
out (c),c
jr start
;two bytes per colour.
;format xGRB
.colours
defw &0000 ; colour for pen 0
defw &0111 ; colour for pen 1
defw &0222 ; colour for pen 2
defw &0333 ; colour for pen 3
defw &0444 ; colour for pen 4
defw &0555 ; colour for pen 5
defw &0666 ; colour for pen 6
defw &0777 ; colour for pen 7
defw &0888 ; colour for pen 8
defw &0999 ; colour for pen 9
defw &0AAA ; colour for pen 10
defw &0BBB ; colour for pen 11
defw &0CCC ; colour for pen 12
defw &0DDD ; colour for pen 13
defw &0EEE ; colour for pen 14
defw &0FFF ; colour for pen 15
defw &0000 ; colour for border
;unlock ASIC sequence
.sequence
defb &ff,&00,&ff,&77,&b3,&51,&a8,&d4,&62,&39,&9c,&46,&2b,&15,&8a,&cd,&ee
...it works fine as long as I loop back (jr start) and keep on repeating the code. However, if I set it up once and then do something else then it resets and reverts to the normal CPC colours. Do you have to keep refreshing the ASIC registers or can you set it up once and leave it?
Also, I was looking at the split screen (rupture) feature of the CPC+ and got it working. But I can't believe there is no ASIC register to set the screen mode up for the split (so you can have for example MODE 0 at the top and MODE 1 at the bottom) - does this mean you still need to time it yourself in the frame flyback and still OUT the mode you want via 7FXX to the CRTC like on a normal CPC...?!
Your ASIC palette does not last because the firmware periodically (speed ink delays) updates the palette too (while the framefly back).
If you do not need the firmware facilities, simply kill it's interrupt service routine (put EI:RET at &0038) and you're done. Otherwise you can cheat some of it's internal variable so that it stops updating the palette. This can be done with eg. a frame flyback event:
;Setup CPC+ screen colours
org &8000 ;must not be between &4000 and &7FFF
start: di ;unlock ASIC
ld b,&bc
ld hl,sequence
ld e,17
seq: ld a,(hl)
out (c),a
inc hl
dec e
jr nz,seq
ei
; Setup a frame flyback event to prevent
; the firmware from updating the colours
ld hl,data_inklocker
ld b,%10000001
ld c,0
ld de,inklocker
call &bcd7 ; KL NEW FRAME FLY
ld bc,&7fb8 ;page-in ASIC registers to &4000-&7FFF
out (c),c
ld hl,colours ;copy colours into ASIC palette registers
ld de,&6400
ld bc,17*2
ldir
ld bc,&7fa0 ;page-out asic registers
out (c),c
ret
;jr start
; this routine will be called by the firmware on every frame flyback
; The trickery at &B7F8 only works with Firmware v2+
inklocker
ld a,&FF ; continually resets an internal
ld (&B7F8),a ; speedink counter so that the
ret ; kernel never updates the colours
;two bytes per colour.
;format xGRB
.colours
defw &0000 ; colour for pen 0
defw &0111 ; colour for pen 1
defw &0222 ; colour for pen 2
defw &0333 ; colour for pen 3
defw &0444 ; colour for pen 4
defw &0555 ; colour for pen 5
defw &0666 ; colour for pen 6
defw &0777 ; colour for pen 7
defw &0888 ; colour for pen 8
defw &0999 ; colour for pen 9
defw &0AAA ; colour for pen 10
defw &0BBB ; colour for pen 11
defw &0CCC ; colour for pen 12
defw &0DDD ; colour for pen 13
defw &0EEE ; colour for pen 14
defw &0FFF ; colour for pen 15
defw &0000 ; colour for border
;unlock ASIC sequence
.sequence
defb &ff,&00,&ff,&77,&b3,&51,&a8,&d4,&62,&39,&9c,&46,&2b,&15,&8a,&cd,&ee
;event block data
.data_inklocker
ds 9,0
Quote[...] does this mean you still need to time it yourself in the frame flyback [...]
Indeed there's no ASIC facility for the screen-mode. However, you can use the programmable raster interrupt to do that easily.
Quote from: Grim on 03:28, 18 January 10
If you do not need the firmware facilities, simply kill it's interrupt service routine (put EI:RET at &0038) and you're done.
Thanks Grim - I'm not using the firmware so I killed the interrupt (using
DI:RET) at &0038:
org &8000
ld a,&F3 ;kill interupt so it doesn't mess with ASIC settings
ld (&0038),a ;puts DI, RET at 0038h
ld a,&C9
ld (&0039),a
....
Quote from: Grim on 03:28, 18 January 10
Indeed there's no ASIC facility for the screen-mode. However, you can use the programmable raster interrupt to do that easily.
Yes, I see from CPCRulez that there is a programmable interrupt at &6800 in the ASIC (http://cpcrulez.fr/coding_cpcplus48.htm) and some explanation of it too (http://cpcrulez.fr/coding_cpcplus47.htm) but I don't understand it because my french is not good at all, I'm afraid :(
I want to be able to split the screen so the first 22 rows are MODE 0 and the bottom 3 rows are MODE 1. I was going to use the CPC+ split screen at line 176 and use it to set the mode, but now I know it's not possible.
Can you show me how to do it with the ASIC interrupt?
Quote from: redbox on 05:32, 18 January 10I was going to use the CPC+ split screen at line 176 and use it to set the mode, but now I know it's not possible.
Why is it not possible ? you can use PRogrammable Interrupts to create an interrupt at line 176-1 , wait interrupt w/ HALT and change to mode 1.
Quote from: fano on 07:33, 18 January 10
Why is it not possible ? you can use PRogrammable Interrupts to create an interrupt at line 176-1 , wait interrupt w/ HALT and change to mode 1.
Yes, this is what I want to do, but don't know how. Can you give me an example of the code?
I added split-screen/mode features to your source code example.
There's a very important thing to take care of when paging-in/out the ASIC bank within an interrupt service routine, which is to know how to restore the ASIC bank to it's original state (paged in/out) when the ISR finishes.
For example: the main program is happily poking into the ASIC registers when an interrupt occurs. The ISR does it's stuff and page-out the ASIC bank on exit. When returning to the main program, it will start poking into regular RAM instead of the ASIC registers! Ooops!
To avoid this problem, when the main program page-in/out the ASIC bank it must also set a flag somewhere so that the ISR knows which state to restore (paged-in/out). See the asic_pagein, asic_pageout and asic_pageres routines in the example below.
;Setup CPC+ screen colours
org &8000 ;must not be between &4000 and &7FFF
cnf_splitline equ 20*8
start: di
im 1 ; setup the IM1 ISR
ld a,&C3
ld hl,isr_screenmode
ld (&38),a
ld (&39),hl
ld b,&bc ;unlock ASIC
ld hl,sequence
ld e,17
seq: ld a,(hl)
out (c),a
inc hl
dec e
jr nz,seq
call asic_pagein ;page-in ASIC registers to &4000-&7FFF
ld hl,colours ;copy colours into ASIC palette registers
ld de,&6400
ld bc,17*2
ldir
ld a,cnf_splitline
ld (&6800),a ; set the raster interrupt scanline (PRI)
ld (&6801),a ; set the splitscreen scanline (SPLT)
ld hl,&0030 ; set the splitscreen address (SSA) for the bottom 3 rows
ld (&6802),hl ; (caution => SSA is a 16bit big endian register!!!)
call asic_pageout ;page-out asic registers
ei
; scramble the main screen offset
ld bc,&BC0D
out (c),c
inc b
scramble
inc c
out (c),c
jr scramble
isr_screenmode:
push af ; save all CPU registers
push bc ; modified by the ISR
ld bc,&7FB8 ; page-in ASIC registers
out (c),c
ld a,cnf_splitline-1
var_pri equ $-1
xor cnf_splitline-1 XOR 220 ; switch PRI between 175 and 220
ld (&6800),a ; set the raster interrupt scanline
ld (var_pri),a
sub 220 ; switch screenmode
ld a,&8D
sbc a,0
out (c),a
call asic_pageres ; restore the RMR2 to it's previous state.
pop bc ; restore CPU register
pop af
ei ; and exit
ret
asic_pagein: ; page-in ASIC registers
ld bc,&7FB8
jr asic_pageset
asic_pageout: ; page-out ASIC registers
ld bc,&7FA0
; Input
; BC = &7F00 + RMR2 value
asic_pageset: ; set custom RMR2 value
ld (asic_pageres+1),bc ; save the RMR2 value
asic_pageres:
ld bc,0 ; restore the saved RMR2
out (c),c
ret
;two bytes per colour.
;format xGRB
.colours
defw &0000 ; colour for pen 0
defw &0664 ; colour for pen 1
defw &0222 ; colour for pen 2
defw &0333 ; colour for pen 3
defw &0444 ; colour for pen 4
defw &0555 ; colour for pen 5
defw &0666 ; colour for pen 6
defw &0777 ; colour for pen 7
defw &0888 ; colour for pen 8
defw &0999 ; colour for pen 9
defw &0AAA ; colour for pen 10
defw &0BBB ; colour for pen 11
defw &0CCC ; colour for pen 12
defw &0DDD ; colour for pen 13
defw &0EEE ; colour for pen 14
defw &0FFF ; colour for pen 15
defw &0000 ; colour for border
;unlock ASIC sequence
.sequence
defb &ff,&00,&ff,&77,&b3,&51,&a8,&d4,&62,&39,&9c,&46,&2b,&15,&8a,&cd,&ee
sorry for the fuzzy or lack of explanations, I'm completely off, need to sleep now :)
Quote from: Grim on 08:11, 18 January 10
I added split-screen/mode features to your source code example.
That's great and thanks for the explanation Grim.
One problem - when I assemble and run the code example under WinAPE the bottom part of the screen (MODE 1) is static but the top half (MODE 0) jumps around all over the place. It would appear that the code to scramble the main screen offset is being called all the time when it shouldn't be...?
I just added the scramble routine to get some action going on the screen and see that the splitscreen at the bottom is working properly (it is not affected). Of course, you should synchronize the changes applied to the main screen (and/or splitscreen) offset with the VSync somehow, but that is left to you :)
Quote from: Grim on 16:28, 20 January 10
I just added the scramble routine to get some action going on the screen and see that the splitscreen at the bottom is working properly (it is not affected). Of course, you should synchronize the changes applied to the main screen (and/or splitscreen) offset with the VSync somehow, but that is left to you :)
Ah ok, thanks Grim for your help, I will have a play with the code and see what I come up with :)
Can I just ask if any ASIC coder knows anything about the soft scroll, cos in the manual it says the soft scroll effects the whole screen. From this and a bit of my memory back doing fluff and smart + back when I seem to recall this means that it can't be set via the line interrupt and therefore everything on the screen is offset by the soft scroll settings whateve you do. Makes doing score panels etc difficult
Would the only around this be in say Mode 0 to have 4 pixel shifted versions of the panel, and adjust the screen address on the interrupt up or down &800 depending on the vertical softscroll setting?
Anyone
Quote from: Trebmint on 19:47, 11 February 10
Can I just ask if any ASIC coder knows anything about the soft scroll, cos in the manual it says the soft scroll effects the whole screen. From this and a bit of my memory back doing fluff and smart + back when I seem to recall this means that it can't be set via the line interrupt and therefore everything on the screen is offset by the soft scroll settings whateve you do. Makes doing score panels etc difficult
Yep. I've been writing a scroller and it does scroll the whole screen regardless of the interupt/split. I've also been debating what to do about the score panel and have so far settled on a hardware sprite for energy/score because they stay in the same place without you having to do anything...
Quote from: Trebmint on 19:47, 11 February 10
Would the only around this be in say Mode 0 to have 4 pixel shifted versions of the panel, and adjust the screen address on the interrupt up or down &800 depending on the vertical softscroll setting?
Not tried this myself, but I will give it a go now you've mentioned it 8)
Oh thats a really stupid feature then, especially given the lack of sprites and the time it takes to fill them. Glad to have given you an idea, but it's a waste of good memory isn't. Could you use that a combination of crtc register 3? to shift a byte and therefore only do 2 copies. Perhaps thats pushing it.
Also since you're already writing this routine, perhaps you could make the code universal with a mapping format. We could then all use a few simple function calls to pixel perfect scrolling. Would simplfy writing a game immensly.
Not having a plus, I wasnt able to try anything on real hardware, but I did play with the soft scroll in Winape a while ago. What seemed to work was to set up the programmable interrupt to match the screen split, set the soft scroll at the start of the frame and have the code do what ever it needs to do in the time available before the split. Then halt to wait for the interrupt, and set the soft scroll variable a second time, giving a static score line. I didnt take it any further at the time, but perhaps it might even be possible make that second soft scroll setting under interrupt, doing away with the need for the halt.
Quote from: Trebmint on 19:47, 11 February 10
Can I just ask if any ASIC coder knows anything about the soft scroll, cos in the manual it says the soft scroll effects the whole screen. From this and a bit of my memory back doing fluff and smart + back when I seem to recall this means that it can't be set via the line interrupt and therefore everything on the screen is offset by the soft scroll settings whateve you do. Makes doing score panels etc difficult
Would the only around this be in say Mode 0 to have 4 pixel shifted versions of the panel, and adjust the screen address on the interrupt up or down &800 depending on the vertical softscroll setting?
Anyone
It can actually affect just part of the screen. If you set a pixel offset and then set it back to 0 some cycles later, then part of the screen will scroll.
Especially when considering vertical scroll.
I've tested this.
So it should be possible to re-program it on a screen split and give you a static panel.
I think Copter271 does this for vertical scroll.
The thing to be careful with is setting the pixel scroll to be the same as the pixel size of the mode. If you don't do that you can get some weird pixel stretching going on. I've not discovered exactly what is happening here so I can't say exactly what you'll see.
I just remember scrolling a mode 0 screen in mode 2 pixel increments and seeing the pixels kind of stretch or like they were dragging. A bit difficult to explain.
EDIT: You'll still need to do what Axelay suggests. You'll need to setup a raster int. But then you can hook the code into your interrupt handler and get it to set it there. So you don't really need the HALT. Just keep track of which raster interrupt your handling and you'll be cool.
Quote from: Trebmint on 22:26, 11 February 10
Also since you're already writing this routine, perhaps you could make the code universal with a mapping format. We could then all use a few simple function calls to pixel perfect scrolling. Would simplfy writing a game immensly.
With my scroll I stretched the screen to 50 chars wide so that 48 were visible and 1 char is left either side of the screen to draw to. The mapping and calculating of screen addresses is then done by the routine that prints the background, and I'm currently re-writing this routine so that it draws the background from tiles that can be re-used throughout the game level. I might well make a CPC tile mapper utility too so that I can use it again and other people can design levels etc.
At present, my code scrolls the screen perfectly using the hardware pixel scroll and I've got the hardware sprite animated. All of the routines haven't been optimised yet but I just wanted to get it working... :)
I've attached a DSK image here so you can download it and see what I've done (and of course, it looks cooler on a real Plus machine 8) ). Use RUN"DISC to load and then CURSOR RIGHT to scroll the screen and animate the monkey.
Quote from: arnoldemu on 11:35, 12 February 10
EDIT: You'll still need to do what Axelay suggests. You'll need to setup a raster int. But then you can hook the code into your interrupt handler and get it to set it there. So you don't really need the HALT. Just keep track of which raster interrupt your handling and you'll be cool.
This is a good idea and I'll give it a go as I have a lot of the raster interrupt code from my demo :D
That looks so cool. Great stuff.
Hmmm, now if we had a function that allowed you to say just set the scroll address in two 2 16 bit values for the X and Y of top left of the scroll, and it automatically updated updated the screen from the old value, so the routine would fill in any part necessary, so you could shift just a pixel or even have the entire screen redrawn.
With that and an editor erm well thats half way to game creation tool.
Quote from: Trebmint on 19:03, 12 February 10
Hmmm, now if we had a function that allowed you to say just set the scroll address in two 2 16 bit values for the X and Y of top left of the scroll, and it automatically updated updated the screen from the old value, so the routine would fill in any part necessary, so you could shift just a pixel or even have the entire screen redrawn.
The way I did it was to get the far right top line screen address, print the next part of the background and increase the screen address to print to by one byte. Then when the screen address reaches &C800 (i.e. the next pixel line down on the display) after scrolling, reset it. This is because the hardware scroll wraps the screen around when scrolling and you need to offset this. It's not much of a problem though because the screen has to be drawn on the right when you scroll anyway.
You can then easily calculate the top left screen address (using the same method as above) and then convert x and y to an address anywhere on the screen using one of the methods Grim and Arnoldemu suggested in this thread (http://cpcwiki.eu/forum/index.php/topic,536.0.html).
Not sure why you would need to re-draw the whole screen with this type of scroller though?
Looks great! That monkey sprite reminds me of Toki, a game I played a fair bit on my brothers Amiga. Are you looking to make it scroll vertically as well, or sticking with horizontal scrolling?
Quote from: Axelay on 01:54, 14 February 10
Looks great! That monkey sprite reminds me of Toki, a game I played a fair bit on my brothers Amiga. Are you looking to make it scroll vertically as well, or sticking with horizontal scrolling?
Thanks - the graphics are imported from the Atari ST version of Magic Pockets, but I'm not looking to do a re-make, more of a 'spin-off' if you see what I mean :)
I was going to do horizontal scrolling only when starting out (just to get it working really) but, the more I think about it, vertical scrolling as well would make the routines a lot more useful and make it look better. Also, I was worrying about the overhead, but the actual scroll routine is fast and adaptable because of the hardware handling so I should be worrying more about the slow background printing routine really :o
i know Kev has already answered this. You can set the soft-scroll register at ANY time during ANY scan line and it will only affect those pixels drawn during that time. It is therefore possible to soft-scroll a small rectangle in the middle of the screen if you really wanted to do that. My Frogger game individually soft-scrolls each 16 pixel high row of river or road using soft-scroll and hardware splitting about 14 times during each frame.
Quote from: Executioner on 01:55, 16 February 10
You can set the soft-scroll register at ANY time during ANY scan line and it will only affect those pixels drawn during that time.
This is good to know.
Only reason I said I thought it was not possible is because in the Arnold V Specification (http://www.kjthacker.f2s.com/docs/arnold5a.html) it states "This soft scrolling mechanism affects the whole of the main screen, regardless of the split screen facility, but it does not affect sprites". They obviously didn't know about the true capabilities of the machine, which is also evident when reading the source code comments in the RP11 Diagnostic Rom Cartridge (http://www.kjthacker.f2s.com/download/rp11src.zip).
Quote from: Executioner on 01:55, 16 February 10
i know Kev has already answered this. You can set the soft-scroll register at ANY time during ANY scan line and it will only affect those pixels drawn during that time. It is therefore possible to soft-scroll a small rectangle in the middle of the screen if you really wanted to do that. My Frogger game individually soft-scrolls each 16 pixel high row of river or road using soft-scroll and hardware splitting about 14 times during each frame.
Oh blimey I wish I knew that years ago. Will do so experiments with this now I think. CPC Plus rulez
@redbox :
Hi, i just want to know more about your project ? Is your game finished now ? Can you tell us more about it ? CAN see any preview ? Thanks.
Quote from: Grim on 03:28, 18 January 10
If you do not need the firmware facilities, simply kill it's interrupt service routine (put EI:RET at &0038) and you're done. Otherwise you can cheat some of it's internal variable so that it stops updating the palette. This can be done with eg. a frame flyback event [...]
You don't actually need to do any of that for the the video mode (although you do for palette etc).
B' always contains &7F, C' contains the current gate array settings, which includes mode and ROM settings. So, you just need to put the correct mode bits into BC' and the screen mode will stay correct even through interrupts and firmware calls.
The info shared above proved extremely useful to my attempt to code something on 6128 plus.
It should be included in the wiki pages for future reference...
BUT I got another question:
OK we have the split screens scroll independently - all working fine, but what to do about the hardware sprites that overlap with parts of screen which is static (say a HUD) ?
Is there a way to force sprites to appear only in the main screen?
I suspect to use CRTC Reg6 but it doesn't work..
Just Move them or change zoom to 0...
no, I dont want them to be erased totally.
I just want part of sprite to appear in the main screen and not in the other split screen below!!
Quote from: fgbrain on 13:09, 25 February 14
no, I dont want them to be erased totally.
I just want part of sprite to appear in the main screen and not in the other split screen below!!
setup a raster interrupt to happen at the same line as your screen split.
Now disable the sprites. Either write the mag value that turns them off, OR write a X or Y value that moves them to a position that is not seen (e.g. a previous Y value such as 0 - this would work because your panel is say, at line 200, and you can't display the sprites here if they are at line 0).
Then after the panel, another interrupt to either reset the mag, or to set their correct positions.
Setting mag is faster and easier than setting X or Y position.
I assume your screen split is using plus screen split and not crtc classic split?
if you used a crtc classic split the sprites would automatically repeat in the panel if they were near the top of the main screen, this is because sprite coordinates are computed from crtc values.
This will work and the sprites will appear to be cut by the panel.
EDIT: Attached source for an example that does exactly this.
It shows:
1. screen split
2. sprites cut using mag
You can see how the sprites are cut, and then later you can see them enabled again (this happens because I disable where split is - but this needs to be tweaked to make it accurate and hide in the border for example), and my later int to re-enable them again happens just after the panel at the bottom so you can see it enabling them again.
another way that could work:
put border between main area and panel.
setup a raster interrupt to happen at end of main screen.
setup standard screen split.
use r1 to set width to 0 - this causes border to appear for a short time.
then re-enable r1 a few lines later for the panel at the bottom.
never move your sprites too far down the screen so that they go past this border.
Sprites are hidden by the border.
it may take less cpu time compared to disabling the sprites using mag.
Example attached which shows the second idea.
You can see how the sprite is cut by the border.
The code is much more simple.
In this example the sprites cover the panel, so in your program you would need to limit them so they don't go this far down.
thanks for all examples. :D
I believe I see an ASIC limitation now. If you use ovescan (max 312 lines vertically) screen
the raster interrupt and split screen cannot occur after 255 line (8 bit register), correct ??
Or it occurs twice? Can't check here.
Quote from: fgbrain on 13:09, 25 February 14
no, I dont want them to be erased totally.
I just want part of sprite to appear in the main screen and not in the other split screen below!!
Sprites have a ranking, so one will always overlap the other, depending on their 'number
[size=78%]'[/size]
Quote from: fgbrain on 19:51, 25 February 14
thanks for all examples. :D
I believe I see an ASIC limitation now. If you use ovescan (max 312 lines vertically) screen
the raster interrupt and split screen cannot occur after 255 line (8 bit register), correct ??
I have one more example I thought up, but I would have to check it on a real plus.
The idea being to add extra lines with R5. You also put a split here. Now this may or may not work depending on how the CRTC in the Plus performs during this time, it may stop counting, can't remember.
But potentially you could split a sprite using this method, but then also the screen split may not work.
You are correct there is a limit in the screen split. it repeats after line 255. So you must set it to 0 after you are done to ensure it doesn't do this. In the official docs it mentions the extreme case where the repeat happens at line 1 again.
EDIT: The raster interrupt doesn't repeat and it seems like they made an error with the screen split because it too should have been driven off the same comparison mechanism.
Quote from: TFM on 20:58, 25 February 14
Sprites have a ranking, so one will always overlap the other, depending on their 'number[size=78%]'[/size]
this *could* be possible to hide a sprite with another of higher ranking. The problem is you can't extend the sprite over the whole width of the screen. Vertically yes you could and hide stuff on the left/right side.
Ah, I got your point.
This is weird..
I am trying to set up a vertical scrolling screen 32x30 char. (I say 30 char. lines because 32x8=256 is impossible I guess)
using ASIC split and soft scroll. The rest of screen is left for a panel.
The problem is that it seems impossible for the second split to remain stable. Although the screen mode changes fine, the soft scroll appears to affect whole screen.
And why do I need an interrupt since I splitted the screen fine using the ASIC registers ?
You meant you didn't reset scroll offset after the first screen ? (the one that scrolls)
Quote from: fgbrain on 08:33, 28 February 14
This is weird..
I am trying to set up a vertical scrolling screen 32x30 char. (I say 30 char. lines because 32x8=256 is impossible I guess)
using ASIC split and soft scroll. The rest of screen is left for a panel.
The problem is that it seems impossible for the second split to remain stable. Although the screen mode changes fine, the soft scroll appears to affect whole screen.
And why do I need an interrupt since I splitted the screen fine using the ASIC registers ?
fano is correct. You need to reset the scroll for the panel.
So you need an interrupt here to set a zero scroll.
EDIT: Internally all the split does is to reload the CRTC R12/R13 registers at the line after the value you program into the split.
It doesn't reset the scroll which acts independent.
Quote from: fgbrain on 08:33, 28 February 14
This is weird..
I am trying to set up a vertical scrolling screen 32x30 char. (I say 30 char. lines because 32x8=256 is impossible I guess)
using ASIC split and soft scroll. The rest of screen is left for a panel.
The problem is that it seems impossible for the second split to remain stable. Although the screen mode changes fine, the soft scroll appears to affect whole screen.
And why do I need an interrupt since I splitted the screen fine using the ASIC registers ?
Taller is possible, but you must set your split line (e.g. to 32 (256+32)), then set it back to 0 after, otherwise you get the bug.
EDIT: Although setting up a raster interrupt after this point would be part because it doesn't repeat from what I can tell.
Perhaps I was not clear.. Of course I reset the soft scroll when the panel is displayed. But still it doesnt remain stable...
Maybe it is a synchronization issue ?
EDIT:
I think I did it !! I should check on real hardware now