Mixing two different graphic modes

Hardware Hacking, Programming and Game Solutions/Cheats
zephyr
Posts: 1474
Joined: Mon Jul 21, 2008 1:18 am

Re: Mixing two different graphic modes

Post 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
sorchard
Posts: 530
Joined: Sat Jun 07, 2014 9:43 pm
Location: Norwich UK

Re: Mixing two different graphic modes

Post 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.
Stew
User avatar
Bosco
Posts: 330
Joined: Tue Mar 04, 2014 11:49 pm
Location: Nottingham, UK

Re: Mixing two different graphic modes

Post 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? :lol:

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. :)
pser1
Posts: 1655
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Mixing two different graphic modes

Post 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
*
Attachments
10 - PMODE34SW.zip
(9.58 KiB) Downloaded 248 times
pser1
Posts: 1655
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Mixing two different graphic modes

Post 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
zephyr
Posts: 1474
Joined: Mon Jul 21, 2008 1:18 am

Re: Mixing two different graphic modes

Post 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.
Attachments
ZIRQ.zip
(801 Bytes) Downloaded 247 times
pser1
Posts: 1655
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Mixing two different graphic modes

Post 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
zephyr
Posts: 1474
Joined: Mon Jul 21, 2008 1:18 am

Re: Mixing two different graphic modes

Post 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
Attachments
ZIRQ2.zip
(938 Bytes) Downloaded 250 times
pser1
Posts: 1655
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Mixing two different graphic modes

Post 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
zephyr
Posts: 1474
Joined: Mon Jul 21, 2008 1:18 am

Re: Mixing two different graphic modes

Post 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.
Post Reply