Giana Sisters STE - New Game!

[AtariZoll]

I bought used WinFastPro card (much worse than Pinnacle). Here is how looks on Falcon working in PAL mode:

ggsZfalcPAL.jpg

Flawless - at least level 1. Except clouds - Zamuel_a will know what I mean
Unfortunately, this fix did not improve work on Mega STE.

[MasterOfGizmo]

The game runs on the MIST. Interestingly it works in MegaSTE mode and not in regular STE mode. The symptom in normal STE mode is that it skips the "scroller screen" and jumps from the title image directly to the "Get Ready" screen, but pressing the fire button there doesn't start the game.

However, in MegaSTE mode it's also unplayable because there "cloud section" and the "game section" are shifted right. So the screen address setting isn't working as it should. Other programs doing similar (obsession pinball and some ste reference code from atari) work. It seems on the MIST the address changes happen too early.

I wonder if the address changes are done in the middle of a line in GianaSTE. Are they? And does the shifter supposed to use the address at the end of that line? My shifter does address changes immediately, even in the middle of a line. Is this wrong?

[MasterOfGizmo]

I disabled the jagpad if it detects a Mega STE and it worked on my Mega without a problem.

Ah, sounds like this may be related to my "MIST in STE" mode problem. Perhaps my "faked" STE joystick ports are broken ... i never tested them.

[MasterOfGizmo]

Are there any other ST games that should be remade for STE?

Gauntlet2 comes to my mind. Jagpad 4 player mode and smoother scrolling ...

[nativ]

Are there any other ST games that should be remade for STE?

Gauntlet2 comes to my mind. Jagpad 4 player mode and smoother scrolling ...

Heck why not add in playable over a network! Ethernet ( online ) or Midi Local some G3 Lynx version type scheme might work.


Hmmm.. how about PANG! with hicolour/pcs backgrounds?

Silkworm could do with some love.

maybe fix that Falcon Galaga 88 version for STe?

[Zamuel_a]

I tried yesterday evening little more to make it work on Falcon, but had no success, better said, it crashed in very early stage. Problems happen right at title pic and music play. It works only if CPU is set to 16MHz and caches off. But when click fire, it starts to fill screen with some crap starting at bottom.
Continued today, and find the main problem: there is nasty code (likely in original too) what causes bus error, and at that point crashes on Falcon.

Code: Select all

at $101AE
move.l  $78000,a1   * Missing #, or use lea
move.w  #$1F3F,d0
cls clr.l  (a1)+
dbf   d7,cls      * should be with d0



Most likely above is party of anti-cracker protection. After fixing it, and doing some other changes, it works on Falcon.
Must set Falcon in STE bus compatible mode, CPU to 16 MHz, both caches off. I did not deal with PMMU table (it will be overwritten) so, should move it to high RAM too, otherwise may expect errors in later stages. I removed HW test and writes to Vfreq. HW register ($FF820A).

I found this part in the code and it's nothing special. The old screen address starts at $78000 (still used for the title image) and this routine clears the title image before the main scroller starts. It's strange why it works since d7 should be d0 and the missing #, but it do the job. I changed it to be correct now anyway.

[AtariZoll]

...
I found this part in the code and it's nothing special.

It is special - not so much for me, who saw a lot of similar anti-cracker stuff. It causes bus error immediately - because there will be 0 in a1 . So bus error while it's vector=0. So, it jumps to addr. 0 ...
Making games to work on Falcon, TT means among many other things removing copy protections completely. For instance Copylock will crash or fail 100% on 68030 - even if it is changed to pass copy protection test.

[Eero Tamminen]

Unfortunately, in middle of all this, my capture card died (used it over 12 years), so I can not attach screenshot. It works in RGB mode at 50 Hz almost for sure, and likely at 60 Hz too - but I was not able to test in lack of monitor for it, after capture card ended his serve of Atari community
Good thing is that it works even with VGA monitor attached.

Does it work with Hatari in Falcon mode? That emulates both VGA & RGB screen and has screenshot functionality.

[Zamuel_a]

In level 1-2 in the end jump up on top the door and you get invisible. Bug?

Found and fixed. It's not really a bug. Giana is 24 physical pixels wide but handled as a 32 pixel wide sprite so she was trying to go outside the screen. 8 pixels are always invisible so I added 8 pixels to the screen edge check.

[Zamuel_a]

I wonder if the address changes are done in the middle of a line in GianaSTE

It is changed as soon as possible after a loop that waits for the current line to finish, so the new screen is set at the beginning of the line.

[MasterOfGizmo]

Ah, sounds like this may be related to my "MIST in STE" mode problem. Perhaps my "faked" STE joystick ports are broken ... i never tested them.

Found the problem. My non-existent jagpads (just the io ports are present to satisfy TOS) were reporting all four directions to be active. Fixed it and now it runs in normal STE mode as well. Thanks for pointing me to that

[MasterOfGizmo]

I wonder if the address changes are done in the middle of a line in GianaSTE

It is changed as soon as possible after a loop that waits for the current line to finish, so the new screen is set at the beginning of the line.

Just to understand this: You have a timer b running that fires in those two lines. Then you wait for the current line to finish and change the address? How do you wait for the end of the line? It seems that this check succeeds to early on the MIST.

Would you mind sharing the code doing the wait?

This is how the screen looks like when the game starts and Giana hasn't been moved at all:

giana_ste_mist.jpg

[npomarede]

I wonder if the address changes are done in the middle of a line in GianaSTE

It is changed as soon as possible after a loop that waits for the current line to finish, so the new screen is set at the beginning of the line.

Just to understand this: You have a timer b running that fires in those two lines. Then you wait for the current line to finish and change the address? How do you wait for the end of the line? It seems that this check succeeds to early on the MIST.

Would you mind sharing the code doing the wait?

Your problem looks similar to the one I had in Hatari when the lower part of the screen was going up/down 1 line from time to time because video address was read during active display.
In your case, is the lower part always shifted with the same amount of pixels, or is this unstable ?

For zamuel_a, I think the part where you change video address should be optimised the same way I posted to fix the case in Hatari. I think there's a small jitter that makes writing to video reg ff8209 during active display and this behaviour is not very well defined (of course, if it's stable on an STE, then it should work under Mist, but that would allow to see if it's the cause of the problem). Try to prepare all the values you want to change before waiting for the change in $fffa21 and do the writes with some "move.b dx,(ax)" for maximum speed.

Nicolas

[MasterOfGizmo]

Your problem looks similar to the one I had in Hatari when the lower part of the screen was going up/down 1 line from time to time because video address was read during active display.
In your case, is the lower part always shifted with the same amount of pixels, or is this unstable ?

To my own surprise it's completely stable. It'd be interesting to see how a version looks that uses different background colors for all three parts. One could then see where exactly the address changes take place.

[npomarede]

To my own surprise it's completely stable. It'd be interesting to see how a version looks that uses different background colors for all three parts. One could then see where exactly the address changes take place.

I can measure that with Hatari, I will post the timings later

[AtariZoll]

...
Does it work with Hatari in Falcon mode? That emulates both VGA & RGB screen and has screenshot functionality.

It works not - serious video error - only horizontal line instead play field. And I post only real HW screenshots, especially in case of Falcon, where emulation is still not at desired level.

[MasterOfGizmo]

I can measure that with Hatari, I will post the timings later

I meant it'd be interesting where my malfunctioning version changes the address. The working one will just display solid rectangles, i am sure.

I have already played it to a point where Giana can jump pretty high. I see where the Giana sprite vanishes and where it re-appears so i know where the lines changes.

[npomarede]

Here're the 2 points where video address / scrolling are changed.

1st one is at hbl 78, it sets the clouds part after the score part :

Code: Select all

A1=$ff820f
A2=$ff8265
cpu video_cyc= 40364 428@ 78 : $17b4e4 : 1281                                 move.b    d1,(a1)
cpu video_cyc= 40372 436@ 78 : $17b4e6 : 1482                                 move.b    d2,(a2)
cpu video_cyc= 40380 444@ 78 : $17b4e8 : 13f9 0017 939f ffff 8205             move.b    $17939f,$ffff8205
cpu video_cyc= 40408 472@ 78 : $17b4f2 : 13f9 0017 93a0 ffff 8207             move.b    $1793a0,$ffff8207
cpu video_cyc= 40436 500@ 78 : $17b4fc : 13f9 0017 93a1 ffff 8209             move.b    $1793a1,$ffff8209
cpu video_cyc= 40464  16@ 79 : $17b506 : 4239 00ff fa1b                       clr.b     $fffa1b


2nd one is at hbl 103, it sets the main game part :

Code: Select all

cpu video_cyc= 52644 420@102 : $17b59e : 1281                                 move.b    d1,(a1)
cpu video_cyc= 52652 428@102 : $17b5a0 : 1482                                 move.b    d2,(a2)
cpu video_cyc= 52660 436@102 : $17b5a2 : 13f9 0017 9397 ffff 8205             move.b    $179397,$ffff8205
cpu video_cyc= 52688 464@102 : $17b5ac : 13f9 0017 9398 ffff 8207             move.b    $179398,$ffff8207
cpu video_cyc= 52716 492@102 : $17b5b6 : 13f9 0017 9399 ffff 8209             move.b    $179399,$ffff8209
cpu video_cyc= 52744   8@103 : $17b5c0 : 4239 00ff fa1b                       clr.b     $fffa1b


All video address changes are made when display is not active (during background color 0 border), so this should not give a problem.
In some case (not in these traces), there's a small delay and write to ff8209 can be very close to cycle 28 ; considering STE needs to prefetch video data 16 cycles earlier than STF to handle scrolling, maybe this is what is giving you a problem ?
That's why it would be interesting if zamuel_a could post a new version where video changes would be :

Code: Select all

lea $179396+1,a3
move.b (a3)+,ff8205.w
move.b (a3)+,ff8207.w
move.b (a3)+,ff8209.w


If this new version works better then it would show that the problem in Mist is because ff8209 is changed to close to the point where pixels starts to be fetched/displayed (by the way, I think the cloud part is shifted too in Mist, but it's harder to see because there's only a blue background)

Nicolas

[tresas]

Amazing job @Zamuel_a!!!
I would like an overscan like "pacmania" , 32 colors intro screen and sid voice ( yes im greedy!!! ) but in any case what i saw was marvellous!!!!
Please give us more projects pleaseeeee!!!!

[MasterOfGizmo]

Your problem looks similar to the one I had in Hatari when the lower part of the screen was going up/down 1 line from time to time because video address was read during active display.

I found the problem: My shifter implementation was adding the STE line offset register at the beginning of the hsync which is signifcantly after the end of the display and thus after GianaSTE updated the video addresses. So the next line started at the newly set address + the STE line offset. Adding the line offset right after display end solved the issues.

GianaSTE now runs nicely on the MIST

Thank you for another beautiful game for my little toy!

[npomarede]

I found the problem: My shifter implementation was adding the STE line offset register at the beginning of the hsync which is signifcantly after the end of the display and thus after GianaSTE updated the video addresses. So the next line started at the newly set address + the STE line offset. Adding the line offset right after display end solved the issues.

GianaSTE now runs nicely on the MIST

Thank you for another beautiful game for my little toy!

Indeed, content of ff820f should be added to ff8205/07/09 when display is off and you start drawing the right border using background color 0 (near cycle 376 if we use Hatari/Steem way of counting cycles on each line)

Nicolas

[Zamuel_a]

Amazing job @Zamuel_a!!!
I would like an overscan like "pacmania" , 32 colors intro screen and sid voice ( yes im greedy!!! ) but in any case what i saw was marvellous!!!!
Please give us more projects pleaseeeee!!!!

Well, overscan in this type of game would look strange. Why would you want to see more sky?

[Zamuel_a]

If anything can be changed in the Timer B routines or if anyone is interested in how i works, here is the code for it:

(The VBI routine is simplified alittle since there are alot of other stuff going on, music and such)

my_vbi
move.w #$2700,sr
move.b #1,$fffa07 ;only timer B running
or.b #1,$fffa13 ;turn on Timer B

clr.b $fffa1b ;disable Timer B

move.b #15-2,$fffa21 ;number of counts
move.l #TimerB1,$120 ;move in my Timer B routine

move.b #8,$fffa1b ;set Timer B to event count mode
move.b #0,LINEWID ;start by set address to status bar
move.b #0,HSCROLL
move.b adrtemp_top+1,VCOUNTHI
move.b adrtemp_top+2,VCOUNTMD
move.b adrtemp_top+3,VCOUNTLO

move.w #$2300,sr

rte

;--------------------------------------------------------------------------
TimerB1 move.w #$2700,sr
bclr #7,$fffff8a3c.w ;turn off blitter

movem.l d0-d2/a0-a2,-(sp)

lea $fffffa21.w,a0

lea scr_counter+1(pc),a1

move.b (a0),d0 ;wait for next line
wait_l1 cmp.b (a0),d0
beq.s wait_l1

;sync screen

move.b VCOUNTHI.W,(a1)+ ;get current screen address
move.b VCOUNTMD.W,(a1)+
move.b VCOUNTLO.W,(a1)+

move.l scr_counter,d0
sub.l adrtemp_top,d0 ;calc were we are

cmp.l #160*(16-2),d0
bgt.s TB1_a

move.b (a0),d0 ;wait for next line
wait_l2 cmp.b (a0),d0
beq.s wait_l2

TB1_a
lea LINEWID,a1
move.b tempLINEWIDc,d1
lea HSCROLL,a2
move.b tempHSCROLLc,d2

move.b (a0),d0 ;wait for next line
wait_l3 cmp.b (a0),d0
beq.s wait_l3

;sync finished

move.b d1,(a1)
move.b d2,(a2)
move.b adrtemp_c+1,VCOUNTHI
move.b adrtemp_c+2,VCOUNTMD
move.b adrtemp_c+3,VCOUNTLO

; --- setup Timer B for next part ---

clr.b $fffa1b ;disable Timer B
move.b #23-2,$fffa21 ;num of counts to start of border
move.l #TimerB2,$120 ;move in my Timer B routine
move.b #8,$fffa1b ;set Timer B to event count mode
bclr #0,$fffa0f ;tell ST interrupt is done

move.b #%10000000,$fffff8a3c.w ;turn on blitter
move.w #$2300,sr
movem.l (sp)+,d0-d2/a0-a2
rte

;--------------------------------------------------------------------------
TimerB2 bclr #7,$fffff8a3c.w ;turn off blitter
move.w #$2700,sr

movem.l d0-d2/a0-a2,-(sp)

lea $fffffa21.w,a0

lea scr_counter+1(pc),a1

move.b (a0),d0 ;wait for next line
wait_l4 cmp.b (a0),d0
beq.s wait_l4

;sync screen

move.b VCOUNTHI.W,(a1)+ ;get current screen address
move.b VCOUNTMD.W,(a1)+
move.b VCOUNTLO.W,(a1)+

move.l scr_counter,d0
sub.l adrtemp_c,d0 ;calc were we are

cmp.l #SCREEN_WIDTH*(24-2),d0
bgt.s TB2_a

move.b (a0),d0 ;wait for next line
wait_l5 cmp.b (a0),d0
beq.s wait_l5

TB2_a
lea LINEWID,a1
move.b tempLINEWID,d1
lea HSCROLL,a2
move.b tempHSCROLL,d2

move.b (a0),d0 ;wait for next line
wait_l6 cmp.b (a0),d0
beq.s wait_l6

;sync finished

move.b d1,(a1)
move.b d2,(a2)
move.b adrtemp+1,VCOUNTHI
move.b adrtemp+2,VCOUNTMD
move.b adrtemp+3,VCOUNTLO

; --- setup Timer B for last line ---

clr.b $fffa1b ;disable Timer B
move.b #159,$fffa21 ;num of counts to start of border
move.l #TimerB3,$120 ;move in my Timer B routine
move.b #8,$fffa1b ;set Timer B to event count mode
bclr #0,$fffa0f ;tell ST interrupt is done

move.b #%10000000,$fffff8a3c.w ;turn on blitter
move.b #1,timer_b_finished
move.w #$2300,sr ;turn on interrupts
movem.l (sp)+,d0-d2/a0-a2
rte

;--------------------------------------------------------------------------
TimerB3 move.b #1,bottom_border
bclr #0,$fffa0f ;tell ST interrupt is done
rte

[FedePede04]

I bought used WinFastPro card (much worse than Pinnacle). Here is how looks on Falcon working in PAL mode:

I'm curious, which capture / Tv chip is on the winfastpro.

[MrMaddog]

I tried yesterday evening little more to make it work on Falcon, but had no success, better said, it crashed in very early stage. Problems happen right at title pic and music play. It works only if CPU is set to 16MHz and caches off. But when click fire, it starts to fill screen with some crap starting at bottom.
Continued today, and find the main problem: there is nasty code (likely in original too) what causes bus error, and at that point crashes on Falcon.

Code: Select all

at $101AE
move.l  $78000,a1   * Missing #, or use lea
move.w  #$1F3F,d0
cls clr.l  (a1)+
dbf   d7,cls      * should be with d0



Most likely above is party of anti-cracker protection. After fixing it, and doing some other changes, it works on Falcon.

[...]

Here is Falcon fixed v. of alpha2 - I took freedom to name so second release

GGSF1.ZIP

Zamuel_a: ask in PM for further details about adding Falcon fix in game.
And I think that this will work well on Mega STE too, at first attempt. I was not able to test because died capture card.

Yeah, that's the problem I had on Steem SSE with the screen filling up (not with old Steem). The GIANA.TOS program you included works on it now. Don't even need to use the Falcon loader to run it. Thanks Atari_zol and Zamuel!