Mixing two different graphic modes

Hardware Hacking, Programming and Game Solutions/Cheats
pser1
Posts: 1655
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Mixing two different graphic modes

Post by pser1 »

Hello,

it seems that you have nailed it!
Thanks a lot Steve and sorchard for this great work.

I have not had the time to test the fourth version.
Remembering the 3rd one, I assume that to use it in combination with ml code it will be enough to call the external code from the test block.
I will try to use it from Basic calling the Inkey routine and reading the output memory byte.
I will let you know how it goes for me.

cheers
pere
zephyr
Posts: 1474
Joined: Mon Jul 21, 2008 1:18 am

Re: Mixing two different graphic modes

Post by zephyr »

Be aware that using the SYNC instruction will slow things down considerably if you intend calling the keyboard routine frequently from your main loop. Although my previous method of using a countdown does not completely eliminate the flicker, it will have very little impact on the running speed of your main routine. You could combine the two methods to stop the flicker completely without slowing the execution speed too much.

Updated demo code attached.
Attachments
ZIRQ5.zip
(1.1 KiB) Downloaded 273 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,

thanks a lot!
I was just making tests with zirq4, with a few changes to be able to call it from Basic.
I works great, the only problem I have found is that when loading an image from disc, there are some conflicts with the IRQ handler
So, I have added a byte control (as in SJ Woolham) to inhibit the ISR routine at will from outside (Basic or ml)
This way it load in PMODE4 but really fast and then the split applies recovering PMODE3
I attach an VDK with the Basic demo program, the binary and the source (excuse me, but I still work with DskDream)

I will give apeek at this last version.
I include here the txt code ...

cheers
pere

Code: Select all

*
*  PM34SE4 - PMODE 3 AND 4
*
       ORG   $4000
       PUT   $4000
*
ONOFF  EQU   $76
INPKEY EQU   $77
COUNT  EQU   $E6
*
       FCB   $7E
START  FDB   INSTAL
       FCB   $7E
REDKEY FDB   INKEY
       FCB   $7E
QUIT   FDB   EXIT
*
INSTAL ORCC  #$50
       STA   $FFC0
       STA   $FFC3
       STA   $FFC5
       STA   $FFC6
       STA   $FFC9
       STA   $FFCB
       STA   $FFCC
       STA   $FFCE
       STA   $FFD0
       STA   $FFD2
*
       LDX   <$72
       STX   OLDRST+1,PCR
       LDX   $010D
       STX   OLDISR+1,PCR
       LEAX  RESET,PCR
       STX   <$72
       LEAX  ISR,PCR
       STX   $010D
*
REDGE  LDA   $FF03
       ORA   #$03
       STA   $FF03
       ANDCC #$AF
       RTS
*
INKEY  SYNC
       JSR   $BBE5
       BEQ   INKEY
       CMPA  #$03
       BEQ   EXIT
       STA   <INPKEY
       RTS
*      BRA   INKEY
*
EXIT   ORCC  #$50
       CLRA
*
RESET  NOP
OLDRST LDX   #$B44F
       STX   <$72
OLDISR LDU   #$9D3D
       STU   $010D
       CMPA  #$12
       BNE   FEDGE
       JMP   ,X
*
FEDGE  LDA   $FF03
       ANDA  #$FD
       STA   $FF03
       ANDCC #$AF
       RTS
*
ISR    LDA   <ONOFF
       BEQ   OFF
       LDA   $FF03
       BMI   SPLITS
       RTI
OFF    LDA   $FF02
       RTI
*
SPLITS LDA   #$E0
       STA   $FF22
       LDX   <COUNT
WAIT   LEAX  -1,X
       BNE   WAIT
       LDA   #$F8
       STA   $FF22
       LDA   $FF02
INTRTN RTI
*
Attachments
26 - TEST PM3-4.zip
(11.91 KiB) Downloaded 272 times
pser1
Posts: 1655
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Mixing two different graphic modes

Post by pser1 »

back again Steve,

I inclose here a Basic program that does the same as the demo in the VDK and once loaded the screen, enters a subroutine
that waits for keytrokes to be received. No control over these, just enter ends the entry and reaching the 26th character quits too

To me it is fast enough.
I will read later the 5th version and try to compare speed by reading keyboard.

thanks a lot

cheers
pere

Code: Select all

100 CLEAR200,32767
110 CLS:PRINT"PRESS ANY KEY TO INSTALL PROGRAM";
120 IF INKEY$=""THEN120

130 PCLEAR4
140 PMODE3:PCLS2
150 LOAD"PM344.BIN"
160 POKE&H76,1:POKE&HE6,5:POKE&HE7,74
170 PRINT:PRINT"DONE. PRESS AGAIN TO START IT"
180 PRINT:PRINT:PRINT"EACH TIME YOU SEE NOTHING MOVES JUST PRESS THE 'S' KEY. THANKS";:PRINT
190 IF INKEY$=""THEN 190

200 EXEC&H4000
210 GOSUB340
220 LINE(10,129)-(245,190),PSET,BF

230 GOSUB340
240 COLOR3:LINE(75,50)-(175,90),PSET,BF

250 GOSUB340
260 POKE&H76,0:LOAD"HOBITPM3.BIN":POKE&H76,1

280 GOSUB370

290 EXEC&H4006:PRINT
300 PRINT"this is just a demo":PRINT
310 PRINT"thanks to zephyr and sorchard!":PRINT

320 PRINT"STRING RECEIVED:":PRINT R$
330 END

340 POKE&H77,0
350 EXEC&H4003:IFPEEK(&H77)<>ASC("S")THEN350
360 RETURN

370 R$=""
380 POKE&H77,0:EXEC&H4003:A=PEEK(&H77):IF A>0 THEN R$=R$+CHR$(A)
390 IFA=13 THEN410
400 IF LEN(R$)<26 THENI$="":GOTO380
410 RETURN
Attachments
TFSPEED.CAS
Test for PMODE34 keyb speed reading
(1.77 KiB) Downloaded 272 times
sorchard
Posts: 530
Joined: Sat Jun 07, 2014 9:43 pm
Location: Norwich UK

Re: Mixing two different graphic modes

Post by sorchard »

I've attached a commented disassembly of GraphText. It's worth a look just to see the masterful coding of SJ Woolham.
sixxie wrote:If only this had come up before the last day of my holiday
Yet another manifestation of Murphy's Law ;)

I'm giving some thought towards creating some video test cards, to aid in comparing real & emulated timing.
Attachments
graphtext.zip
Disassembly of SJ Woolham's GraphText
(4.6 KiB) Downloaded 285 times
Stew
pser1
Posts: 1655
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Mixing two different graphic modes

Post by pser1 »

an excelent reverse engineering work, sorchard. Congrats!
I had begun doing that same work, but as soon as I got something to work with I quitted the hard task.
It's a work to be saved, there are many things to learn reading it carefully!

cheers
pere
sorchard
Posts: 530
Joined: Sat Jun 07, 2014 9:43 pm
Location: Norwich UK

Re: Mixing two different graphic modes

Post by sorchard »

Regarding timing tests this is what I've come up with so far. Being a bit of a technical exercise it's not particularly exciting to look at, but serves to visually verify the timing of the vertical and horizontal syncs on rising & falling edges, total cycles per frame and irq latency.

The idea on each test page is that the colour set changes should align with the checkerboard test pattern.

These have been checked on a real Dragon 64. I'd be interested to know if the same results are obtained on the various D32 versions & PAL CoCos.

The good news is that xroar breezes through these tests no problem, even the 'phased' irq latency tests which I thought might throw up something. Good work sixxie :-)

I think this means we can probably narrow down the difference in behaviour observed with GraphText* to instructions that clear the irq flag. e.g. lda $ff02. Maybe I can set up some tests that walk the frame sync edge through some of these instructions like I've done for the irq latency tests...

I've included the source code in case anyone might find it of use or would like to add more tests. There's a handy macro to implement a precise delay anywhere from 2 to approx 500000 cycles.

Edits:
*I meant the new split-screen code. GraphText was OK :oops:
Attachment removed. New version in next post.
Last edited by sorchard on Sat Nov 01, 2014 1:21 pm, edited 1 time in total.
Stew
sorchard
Posts: 530
Joined: Sat Jun 07, 2014 9:43 pm
Location: Norwich UK

Re: Mixing two different graphic modes

Post by sorchard »

I've added a 19 phase irq latency test that includes an instruction which clears the irq flag (lda $ff02). It works in a similar way to the 3 and 6 phase tests: The frame sync signal is forced to occur in exactly the same place every frame by ensuring that the number of cycles in the interrupted loop is an exact divisor of the number of cycles to service the irq and the number of cycles per frame.

By varying the number of cycles between sync and the start of the loop we can walk the frame sync signal through the instruction stream cycle by cycle and, to use an overly dramatic analogy, we can probe the fine structure of matter like a particle accelerator :-)

What I've learned is that the irq suppressing effect of lda $ff02 occurs during a one cycle window (Phase 6/19 in the new test sequence). In xroar this window is wider with intermittent effects so would seem to be a reasonable explanation for the differences observed when developing the split-screen code.

Anyway, the code creates a stable environment to have a closer look with a logic probe or even a scope if anyone gets sufficiently bored over Christmas!

One of the things I would like to do (eventually) is create a VHDL description of the Dragon hardware so will probably revisit this from time to time.
Attachments
tmgtest_v1_1.zip
(14.94 KiB) Downloaded 270 times
Stew
sixxie
Posts: 1346
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: Mixing two different graphic modes

Post by sixxie »

This looks like a fantastic tool. As soon as I get time, I'll be finding out where XRoar gets it wrong...
sorchard wrote: What I've learned is that the irq suppressing effect of lda $ff02 occurs during a one cycle window (Phase 6/19 in the new test sequence). In xroar this window is wider with intermittent effects so would seem to be a reasonable explanation for the differences observed when developing the split-screen code.
Is this after clearing, there is a window where a new IRQ will not be acknowledged? Possibly because it takes that long to actually clear the output... I'll still have a Logic capture showing that somewhere, will consult when I get a mo.

..ciaran
sorchard
Posts: 530
Joined: Sat Jun 07, 2014 9:43 pm
Location: Norwich UK

Re: Mixing two different graphic modes

Post by sorchard »

sixxie wrote:Is this after clearing, there is a window where a new IRQ will not be acknowledged? Possibly because it takes that long to actually clear the output... I'll still have a Logic capture showing that somewhere, will consult when I get a mo.
The more I think about this, the less I feel I understand it.

The evidence says, yes, it looks like the flag clear condition (read of $ff02) has to land on a particular cycle relative to the frame sync to prevent the irq signal from the PIA being asserted. Otherwise, the irq is asserted as normal.

The 19 cycle test loop starts with these two instructions:

lda $ff02
nop

During the 1st 5 phases of the test, the irq is being serviced between lda & nop.

During the 6th phase, the irq would normally be serviced after the nop but it has been suppressed.

On the 7th phase, the irq is serviced after nop as normal.

I find this behaviour a little surprising as I was kind of expecting a 'shadow' lasting a few cycles where the lda $ff02 had cancelled the irq before it was serviced. i.e. what xroar is doing seems closer to reasonable expectation that what is actually happening on real hardware! It's as if the real irq signal is coming back on again, immediately after clearing.

I'm now wondering what happens if the second instruction is longer than a nop. Would this result in a longer window with no irq? And what happens with clr $ff02, where the read is not on the last cycle of the instruction? Looks like a little more investigation is required...
Stew
Post Reply