Page 2 of 6
Re: Mixing two different graphic modes
Posted: Fri Sep 19, 2014 12:14 am
by zephyr
pser1 wrote:Hello,
I know that a few of you have got to show in the screen a part in a PMODE and the rest in another resolution ...
I am interested in having the upper 3/4 of the screen devoted to PMODE3 or maybe SG24 (144 pixels high) and the rest (48 pixels high) for PMODE4
To make things easier, this proportion may be changed along the execution of the program.
The program will work at a slow speed, so no timing problems ... not an action game!
Could anyone give me any hint to program the routine that would control this PMODEs combination, if it is affordable, of course?
thanks a lot in advance
regards
pere
It may be helpful to disassemble Steve Woolham's GraphText program.
viewtopic.php?f=7&t=723
Re: Mixing two different graphic modes
Posted: Fri Sep 19, 2014 8:41 am
by sorchard
zephyr wrote:It may be helpful to disassemble Steve Woolham's GraphText program.
I've never seen this before. It works really well. Pretty sophisticated too... it must be hooked into BASIC in a number of places to do what it's doing.
The heart of it is fairly simple though: A quick look through the disassembly shows that it works by redirecting the vsync irq. The irq handler sets text mode, then delays 9000 cycles then sets graphics mode. Simple as that; no hsync. There is an obvious performance hit but it works well in xroar so is probably the best approach.
Edit:
Just noticed something subtle:
It programs the PIA to detect the rising edge of the frame sync pulse instead of the usual falling edge. This means less time is needed to be wasted in a delay loop to reach a given position on the screen.
Re: Mixing two different graphic modes
Posted: Fri Sep 19, 2014 1:30 pm
by Bosco
sorchard wrote:So the first thing the D64 did after 10 years in the dark was load Flagon Bird from my phone. I've got to say this game is awesome on the emulator and even better on the real thing! It's slightly easier to play on real hardware as well, but I'm not sure why.
Glad to hear your D64 has survived sorchard. Was it like unboxing a hibernating tortoise and wondering if it's still in the land of the living?
I agree FB is easier to play on real hardware. I think it's because the update is smoother/more uniform. I used to test in XRoar at 60Hz for the same reason.
These split screen demos are very impressive! I take my hat off to you guys.
Re: Mixing two different graphic modes
Posted: Fri Sep 19, 2014 3:58 pm
by pser1
hello,
I have modified the irq-handler to do, according to me, the same that the SJWoolham's one does.
I must have done something wrong becuase I keep on having unstability in the two PMODEs boundary and
the upper screen flickers from time to time (getting the full screen the PMODE4, that should only be applied to the lower part)
@sorchard
Have you had the time to make any tests on the ideas Steve mentioned?
For if anyone is willing to help, I am attaching an VDK image with the source, binary and a Basic test program.
If anyone prefers just the plain txt source, I copy it herunder
Code: Select all
*
* PM34SW - test for two simultaneous graphic modes
*
ORG $4000
put $4000
*
ctrl equ $0114 * flag (1 byte) --- What is this for???
count equ $f8 * counter (2 bytes) to change PMODE
*
instal ORCC #$50 * Disable IRQ/FIRQ interrupts
LDX #ISR * get new IRQ-dispatch routine
CMPX $010D * is it already installed?
BEQ UNINST * uninstall it - disable control
*
ENABLE STA $FFC0 * clear SAM V0
STA $FFC3 * set SAM V1
STA $FFC5 * set SAM V2
STA $FFC6 * start of graph memory = $0C00
STA $FFC9 *
STA $FFCB *
STA $FFCC *
STA $FFCE *
STA $FFD0 *
STA $FFD2 *
LDA $FF03 * enable Frame Sync Interrupt
ORA #$03 * detect rising edge
STA $FF03 *
LDA $FF01 * Disable Horizontal Sync Interrupt
ANDA #$FE *
STA $FF01 *
BRA CHGVEC * change to the new IRQ-dispatcher into vector
*
UNINST LDX #$9d3d * get std default value
LDA $FF03 * enable Frame Sync Interrupt
ORA #$01 *
STA $FF03 *
*
CHGVEC STX $010D * set IRQ dispatch routine
ANDCC #$AF * enable IRQ/FIRQ interrupts
RTS * return to caller
*
isr lda >ctrl * internal counter (?)
beq vsync * if zero processs interrupt
jmp $9d3d * else go to std irq-handler
vsync lda #$e0 * set PIA1 = 1110 0--- (colorset 0)
sta $ff22 * set PMODE3
ldx >count * get wait counter
iloop leax -1,x * decrement
bne iloop * till zero
lda #$f8 * set PIA1 = 1111 1--- (colorset 1)
sta $ff22 * set PMODE4
lda $ff02 * clear VSYNC IRQ flag
ldd >$0112 * get timer value
addd #1 * increment it
std >$0112 * stores it back
lda <$e4 * play not yet ended?
lbne $afd9 * go to PLAY interrupt routine
lda <$8e * sound not yet ended?
lbne $8802 * go to SOUND interrupt routine
rti * return from interrupt
*
Re: Mixing two different graphic modes
Posted: Fri Sep 19, 2014 4:32 pm
by pser1
by the way, I have made the tests on my Dragon64 and the results are much the same: flickering and boundary unstability
cheers
pere
Re: Mixing two different graphic modes
Posted: Fri Sep 19, 2014 6:17 pm
by zephyr
Code: Select all
CHGVEC STX $010D * set IRQ dispatch routine
ANDCC #$AF * enable IRQ/FIRQ interrupts
RTS * return to caller
Returning control to BASIC will restore the default text mode. Try the attached demo (Encoder 09 source) code.
Re: Mixing two different graphic modes
Posted: Fri Sep 19, 2014 7:36 pm
by pser1
Hello Steve,
I have used this code instead of mine, calling it from inside a Basic program that simply works in high resolution, so I have a RTS instead of the forever loop.
The Basic makes a PCLS2 in PMODE3 and then draws a square in the low part and later a rectangle in the upper part and loops forever.
To step between these drawings, the program waits for the inut of a "S" with an INPUT$, so you can let it wait as much time as you want.
Tested in XRoar it still shows flickering on the PMODE3 part and the modes boundary left part moves a bit.
This last effect is small, so acceptable, but the 'random' flickering is a bit awkward.
Despite the very low 'requirements' of the INKEY$, it produces the flickering anyway ... don't know if it could be solved in any way
thanks a lot
regards
pere
Re: Mixing two different graphic modes
Posted: Fri Sep 19, 2014 11:40 pm
by zephyr
pser1 wrote:don't know if it could be solved in any way
You could call the keyboard routine from your ISR. Try the attached updated demo (Encoder 09 source) code.
Load ZIRQ2, then test with the following BASIC example code.
Code: Select all
10 PMODE3,1:PCLS
20 POKE255,ASC("S"):EXEC
30 CIRCLE(128,96),90,2
40 GOTO 20
Re: Mixing two different graphic modes
Posted: Sat Sep 20, 2014 9:01 am
by pser1
Hello Steve,
I have tested this last one and works great, no flicker, no boundary unstability!!
My initial idea was to use this IRQ-handler to be splitting the screen while a machine code program is running at the same time.
The ml program will be inquirig keyboard internally via [$8006], I hope that this will not afffect the IRQ-handler.
Of course, the ml will be 'drawing' on the screen and sometimes it will do an upper scroll to a part (the lower or the upper)
To make things more interesting, each upper scroll will imply to move the boundary 8 pixels up, but this seems easy to get by modifying
the wait value in the ml code, I hope.
Besides, from time to time it could load an image from disk, and the boundary should be put back to the first value.
Having seen that the interaction with the new routine to 'read' the keyboard works flawlessly (to help Basic, I assume)
I hope this would not be necessary from inside ml code, I mean that if no value is put in $FF and the routine is not called again,
it will be running anyway catching every VSYNC as expected and maintaining the splitting and will never get stuck waiting for a key to be pressed.
Thanks a lot for your unvaluable help ... once again!!
cheers
pere
Re: Mixing two different graphic modes
Posted: Sat Sep 20, 2014 9:23 am
by zephyr
pser1 wrote:
The ml program will be inquirig keyboard internally via [$8006], I hope that this will not afffect the IRQ-handler.
I think the only way to avoid flicker is to call the keyboard routine from the ISR.