Discussion: Rygar AGA Edition

[jotd]

this timing issue looks like a legend. It is a legend, except for the CD32 buttons. I've zoned 2 source files that I'm using for my whdload slaves (read the buttons, read the whole joystick).

It has been elaborated various EAB threads (the authors are mentionned)

- original code by asman with timing fix by wepl
"getting joypad keys (cd32)"
http://eab.abime.net/showthread.php?t=29768

- adapted to single read of both joysticks thanks to Girv
- added detection of joystick/joypad by JOTD, thanks to EAB thread:
http://eab.abime.net/showthread.php?...51#post1175551

[mcgeezer]

Originally Posted by Toni Wilen

You only need to write once to POTGO if you only need to read normal digital joystick button 2 (and optionally 3), it is described in HRM (Interface hardware chapter, Digital IO on the controller port. "These lines can be also used for button input"..).

Only CD32 pad need more complex method.

EDIT: There is confusing information floating around because POT lines can work at least in 3 different configurations. (read variable resistor = analog joystick/paddle, normal I/O pin, I/O pin with internal pullup. Analog joystick mode can be also used to read digital buttons but it just makes it much more complex without any gains)

Here is the main loop in the game, I think I probably know what is going on now.

I've highlighted in Red the calls where the 2nd button reads/writes are done.

It would seem I'm doing things the wrong way round... Each frame I read POTGOR then write to POTGO straight afterwards.

I probably should write to POTGO straight after the vertical blanking wait, then read the buttons much later in the frame.

.wait:	
	bsr	WAIT_FOR_VERTICAL_BLANK

	tst.w	RYGAR_LIVES
	bmi	.start_game
	bsr	CHECK_EVENTS
	tst.w	d0
	bmi.s	.wait

	bsr	UPDATE_TIMER
	bsr	CYCLE_COLOURS

	bsr	PAN_CAMERA_POSITION ; Read POTGOR bits here

	move.w	#$c000,POTGO(a5)

	bsr	SANCTUARY

	bsr	DBUFF
	bsr 	UPDATE_COPPER_SPRITES
	bsr	COPY_BG_TO_SCREEN

	tst.w	UPDATE_SCORE
	beq.s	.skip_score_update
	clr.w	UPDATE_SCORE
	bsr	UPDATE_PLAYER_SCORE

.skip_score_update
	IFNE	DEBUG_TEXT_ENABLE
	bsr	DEBUG_TEXT
	ENDC

	bsr	ANIMATE_SPRITES
	bsr	RESTORE_ALL_SPRITES
	bsr 	REST_DISKARM_BACKGROUND
	bsr	BLIT_TILE_ONSCROLL_X
	bsr	BLIT_TILE_ONSCROLL_Y

	bsr	HDL_STONES
	bsr	HDL_ITEMS
	bsr	HDL_DISKARM
	bsr	PLOT_ALL_SPRITES	

	moveq	#8,d0
	bsr	UPDATE_ROUND_GUIDE

	bsr	SPAWN_ENEMIES

	add.l	#1,FRAME_COUNTER
	addq.w	#1,FRAME_BG

	bra	.wait

At the moment I can't actually check this because my A1200 is currently being recapped. In the meantime I will see what jotd patched and work back from there too.

[ross]

Hi Geezer, I normally do a single initial write to POTGO (#$FF00).
And then you can read all joystick state in one go (per frame).

This works properly for joystick with 2nd button tied to ground when closed (like on mouse).

Probably the best thing to do for other configurations is an option menu in game.

[Irek´72]

@mcgeezer and jeff:Okay, just I tried it with original CD32 joypad, and the main character can jump again even on the 040 CPU. (WHD and ADF Ver.) Of course the joystick I have has two buttons. I did not know that the game works only with some joysticks types correctly. (I mean the jump of course) However, it is a bit strange that jumping with joystick on a small Amiga configuration worked for a few seconds and did not work on bigger ones.

@Toni:I played the game under WinUAE with the keyboard. I had no control problems there.

@Nightshft:Of course, I also noticed the graphical glitches in the game on both Amiga configurations and WinUAE.

[ross]

Ok, I have a half guess (only half ) why it does not work in some conditions.

Geezer, PM

[Toni Wilen]

Writing same value should not make any difference (except if also bit 0 is set).

But KS ROM vertical blank routine is still active and it writes $0F00 to DFF034 which surely causes issues.

[ross]

Originally Posted by Toni Wilen

Writing same value should not make any difference (except if also bit 0 is set).

But KS ROM vertical blank routine is still active and it writes $0F00 to DFF034 which surely causes issues.

Yes, exactly this in my PM

Just a curiosity, cut/paste:

         To sense whether the right mouse button is being
         pressed on a mouse plugged into game port 0, you
         must first set pin 9 to output.  (i.e.:  OUTLY = 1
         and DATLY = 1 or write $0c00 to POTGO.  For a mouse
         plugged into port 1, use OUTRY and DATRY instead.)
         Finally, wait about 300 µs for the voltage to reach
         the game port - and then read the status of pin 9
         via the DATLY bit in POTGOR.

Why the 300µs? An hardware debouncer in PAULA?

[Toni Wilen]

There are capacitors in POT lines that takes some time to charge/discharge (needed for POTxDAT support) but in my measurements it only takes less than 20us when button is pressed (short to ground) but I am not sure how long it takes when output is Paula pin. (=pin is output and button is not pressed). It probably is very short delay in "digital" read mode because button needs to be almost shorted (very low resistance) for Paula to detect pressed button.

When reading analog joystick and POTGO bit 0 is set, Paula has 7 (NTSC) or 8 (PAL) scan line capacitor discharge delay. So 8 lines should be "officially" long enough

Another possibility is simply almost 30 year old capacitors causing side-effects.

[ross]

Thanks

[jotd]

the workaround to avoid waiting is to read POTGOR first, then write to POTGO.

The very first read is likely to fail, but all others will work.

About what Toni said: "KS ROM vertical blank routine is still active and it writes $0F00 to DFF034 which surely causes issues."

The fact that it writes in DFF034 is also likely to fix the read issue for a game using OS. But I wouldn't recommend that.

Irek I suggest that you try whdload version with 2-button joystick and you tell me if it works.

[Nightshft]

Originally Posted by Irek´72

@mcgeezer and jeff:Okay, just I tried it with original CD32 joypad, and the main character can jump again even on the 040 CPU. (WHD and ADF Ver.) Of course the joystick I have has two buttons. I did not know that the game works only with some joysticks types correctly ...

AFAIK there are two types of Joysticks with 2 logical buttons. Amiga, where Button 2 connects Pin9 to Gnd (as usual). And C64 where Button 2 connects Pin9 to +5V (because C64 internals, namely SID, need it this way to work).

Irek you could use a multimeter to check if Button 2 connects Pin 9 with Gnd (Pin 8) or +5V (Pin 7). Whats your Joystick model if you want to tell?

[Toni Wilen]

It would not work at all if button connects to +5v, at least when using current reading method.

I am quite sure the real cause is KS ROM POTGO writes:

Line 305: POTGO_R: 5500 00025492 (game read)
Line 306: POTGO_W: C000 00031F98 (game write)

Line 15: POTGO_R: 5500 00FC7696 (KS read)
Line 16: POTGO_W: 0F00 00FCD476 (KS write)

KS write "overrides" game's POTGO write and I guess 306-16 lines can be enough for capacitor to lose all charge even when button is not pressed (+capacitor quality, Paula input line quality, +5v power supply level and perhaps others) and always returning button pushed state.

If you need active system interrupts, one simple solution would be to add lowest level (=runs last in interrupt chain) vertical blank interrupt that writes to POTGO. Or use potgo.resource to allocate and set correct bits.

[mcgeezer]

Originally Posted by Toni Wilen

It would not work at all if button connects to +5v, at least when using current reading method.

I am quite sure the real cause is KS ROM POTGO writes:

Line 305: POTGO_R: 5500 00025492 (game read)
Line 306: POTGO_W: C000 00031F98 (game write)

Line 15: POTGO_R: 5500 00FC7696 (KS read)
Line 16: POTGO_W: 0F00 00FCD476 (KS write)

KS write "overrides" game's POTGO write and I guess 306-16 lines can be enough for capacitor to lose all charge even when button is not pressed (+capacitor quality, Paula input line quality, +5v power supply level and perhaps others) and always returning button pushed state.

If you need active system interrupts, one simple solution would be to add lowest level (=runs last in interrupt chain) vertical blank interrupt that writes to POTGO. Or use potgo.resource to allocate and set correct bits.

Hi Toni,

I actually don't need to run the system interrupts... it's just I have simply forgotten to turn them off. It is likely the cause of other intermittent issues that I am seeing with the colour loading as sometimes the background colours are screwed up and transparent through the front playfield.

I confirmed that there is something else in ROM writing to POTGO with the WinUAE debugger (w 0 $dff034 2 W) and sure enough I get two writes per frame.

Trying to fix now... I'm assuming a move.w #$7fff,INTENA(a5) will be a good start...

Appreciate everyone's help with this.

Graeme

[Irek´72]

Originally Posted by jotd

Irek I suggest that you try whdload version with 2-button joystick and you tell me if it works.

I tried the WHDLoad version and as I wrote yesterday, the jump function does not work. The two joystick buttons cause always a shoot. By accident, I discovered that the left mouse button also made a shot of fire and killing all enemies. Would it be possible to take out the second button as a jump, and make the jump with simple movement of the joystick?( just an idea)
The WHDLoad version crashes from time to time with a fault. (see attachment)

Originally Posted by Nightshft

Irek you could use a multimeter to check if Button 2 connects Pin 9 with Gnd (Pin 8) or +5V (Pin 7). Whats your Joystick model if you want to tell?

Thank you for your hint. Unfortunately, I can't tell you that, it's a big secret, but I can tell it was 3 different joysticks from different manufacturers. I tested all again and all buttons worked without problems.(even with your joytest tool )

[jotd]

Irek, I have removed the extra stuff I was doing to "fix" the jump. Was already done in the game, and I incorrectly didn't see it.

Also the fact that the game crashes is because there are wrong reads/writes. Rygar team should fix it, since their code does nothing useful at this point (besides being wrong) where the code is probably intended to do something.

In the meanwhile, use MMU=NONE if it works.

Seems that code crashes in the image decode routine:

$5bf0f5ba rts
›1m$5bf0f5bc cmpi.l       #$434d4150,(a0)                ;a0 = $0fff0fff , compare against "CMAP"
›22m$5bf0f5c2 beq.b        $5bf0f5c8
$5bf0f5c4 addq.w       #2,a0

[trydowave]

Originally Posted by mcgeezer

No, the ADF is bootable.

Did you disable all of your external drives so you get the maximum chip ram?

Can you provide a screen shot?

i couldnt get the whdload or the mounted floppy to work. it tried to load on the whdload but just crashed.

created a floppy from the adf and used that instead no problems.

great job on the conversion. Feels like i was playing the arcade game on mame. I did notice some slowdown on a later level once. Not complaining just wondering if all these sprites and parallax are pushing even AGA?

[mcgeezer]

Originally Posted by trydowave

i couldnt get the whdload or the mounted floppy to work. it tried to load on the whdload but just crashed.

created a floppy from the adf and used that instead no problems.

great job on the conversion. Feels like i was playing the arcade game on mame. I did notice some slowdown on a later level once. Not complaining just wondering if all these sprites and parallax are pushing even AGA?

Glad to read you got sorted and thanks.

Yes, the engine really is pushing the AGA... an OCS Amiga couldn't do it.

[mcgeezer]

Added more enemies... see if you can spot them. I'm particularly pleased with the Dragon Rider as it can traverse the entire map scaling and jumping obstacles.

[ Show youtube player ]

[Foul]

The 4 enemies @24''

Excellent!

[Reido]

Originally Posted by Foul

The 4 enemies @24''

Excellent!

Yeah very cool!