Rally-x freeplay with attract mode?

brzezicki

Well-known member
Joined
Nov 6, 2006
Messages
4,536
Reaction score
485
Location
Maryland
Anyone know if this is out there already? Rally-x has a freeplay built in but it keeps the static screen, I hate leaving static screens on my games if they are on.
 
I don't think it exists. I ended up using one of Adam's/Onecircuits Coinups on mine. Works great and does the job for me.

I'd really like to see this feature with a high score save as well though.
 
I don't think it exists. I ended up using one of Adam's/Onecircuits Coinups on mine. Works great and does the job for me.

I'd really like to see this feature with a high score save as well though.

Rally-X only saves one score and it only does it on the screen, oddly enough.

None of the scores are manipulated in main memory.
 
i started looking into this (to apply what i learned in your videos) for mike... but didn't get too far (have to figure out a better way to deal with the checksum rom check failure)

what i do know so far, is:
0x8024 is where credits are stored in ram
0x746 is the location in rom 1b that decrements the credit count
setting 0x746 to 00 (nop) and one of the 00 bytes like 0x12 back to 35 (which is what was removed from 0x746) near the beginning of the rom will fix the checksum rom1 error

i got stuck trying to get the comparison to credit count when start is pressed to pass even when 0, which should then keep attract mode running but allow a game to start (theoretically, clearly i'm a total amateur)... setting a wp on reading from 0x8024 will stop at code byte 0x441 doing a seemingly constant check while in attract mode that i have to get back to it and figure out how to make sense of that
 
So good work so far!

I don't know if I follow you regarding the last paragraph but more than likely attract mode is checking the credits right before it starts the attract screen basically if credits are present it probably will jump to the "press's player 1 to start screen" if not continue with attract mode

This might be tricky as you'll probably need to add a bit of code at that section that rather than checking if any credits are there, instead see if p1 or p2 start is pressed or something then jump to the section of code that actually starts the game if so.
 
this might help you a bit. it's hard in MAME debugger when your dealing with code that's
more than just what fits on the screen since it only shows so much at a time.

here's the entire disassembly for rally-x in one big text file.
https://drive.google.com/file/d/0BxQMpcsrCd4UZTRLWjBVUkdCNzA/view?usp=sharing

There has been some automatic processing of the code done to analyze it and it should be labeld in parts. things that start "sub_xxxx"
are part that the analysis program thinks are subroutines. the number xxxx is the address the subroutine starts at
(also the addresses are on the left first part of each line)

you can download it and annotate it if it helps you figure out what's up.
 
Last edited:
Thanks, i'll try to make sense of it

As far as my last paragraph, basically when i set a watchpoint on reading of the credit count, it stops very often on a comparison to $09, which i noticed when you have 9 credits it accepts no more and turns on the coin lockout, so i assume its related to that

My goal when looking at it was to find a comparison to 0 when start was pressed and let that comparison start a game instead of failing, but maybe thats not the best approach (maybe setting the credits to 9 but allowing attract mode meanwhile is the better approach, dont know)

I stopped while trying to figure out a wayto disable the checksum check or easily compute a checksum correction but got stuck there as well (without which making the above changes was very cumbersome)

Now i'm inspired to revisit it so i'll see what i can figure out
 
It also may help you to just skip/bypass the rom check so you can work without being hindered. Once your code works I can show you how to encode the Roms so it checks your checksum
 
thats what i meant, i haven't figured out how to do that... and i'm not talking about mame's checksum check, but rather the games initializing rom check... ie when i changed the decrementing byte to a nop, the game would fail (and reset) with a "ROM 1" error rather than the typical "ROM OK" message... i was able to get around this by setting an unused byte from 00 to 35 (the opposite of the change i made where it mattered)... but to make multiple/complex changes i have to figure out how to disable the rom check on bootup

that will be the first thing to figure out as i look at this again

the final checksum correction should be easy enough to compute once, but as i'm experimenting i need to disable the check
 
If you NOP the instruction at 0x397E, that should force it to always pass the ROM test. That would be changing 0x097E and 0x097F to 0x00 in ROM 1K.

DogP
 
here's another thing that might help you out. I just loaded your credit counter into the program I am using, and had it tell me the things that it can see that references the credit counter

here is a list (screen shot) of instructions that reference the value stored at 0x8024
the 2nd colume show whether it's a read or a write the third column gives you
something like sub_2D8+166

to find the address of the actual instructions just take the number after sub (2D8) and then add or subtract the next number (+166) these numbers are hex. that will give you the addresses of the instructions that reference said memory. (there may be others that it missed but that looks like it's probalby most if not all of them I'd imagine)

if you need any help understanding things just give a shout, DogP has already given some great help and others might jump in too. I'm super busy this next few weeks but will certainly see if I can help if you have questions as time permits.




Sweet thanks that works and should help the tweaking trial and error (didnt get to spend any time on it yet though)
 

Attachments

  • Capture.PNG
    Capture.PNG
    16.9 KB · Views: 15
Ugh... leave the opcodes in... use a monospaced font.

the file I exported has no font/markup it's pure ASCII text (well ok IDA put in some non 7-bit ascii chars) you'll see these were there are immediate byte values > 127) but basically the file is just raw text, you can have your editor format with whatever font people desire.

-brian
 
i can't really figure out what to do unfortunately, i'll continue poking at it as i try to make sense of some of the bitwise comparisons and opcodes

so far:
as dogP pointed out nop'ing 397E & 397F will prevent the rom checksum failure from stopping execution
nop'ing 0746 prevents credit count from decrementing on 1P start
nop'ing 0735 and 0736 prevents credit count from decrementing(-2) on 2P start
8024 contains the current credit count

code at 0717 runs when you have a credit and checks for the press of start button by using input address A000 for 1p and A080 for 2p, but does not run when waiting for a credit

code at 14D7 checks those same inputs (A000 and A080) for the credit input


conceptually, i thought i would be able to have it check for start button input each time it would normally check for a coin input and ignore the fact that it didn't have credits, but have failed so far... i guess the next approach i'll try would be to have free play turned on (input A100 has the dip switches), but force the attract mode to run anyway

of course, especially since i don't have a rally-x, i'm really only interested in doing this as a form of practice to better learn how to do this for games i do need, so any tips/help greatly appreciated, even if just conceptual guidance in my approach
 
Last edited:
I have not had a chance to look at it much but more than likely there is an outer loop that checks if any credits exist, if credits exist it will go to the static screen that waits for you to hit 1 or 2 start.

What you'll probably need to do find the find that outer code that originally checks the credits modify it instead to check for p1 or p2 start. If either of those are hit add 1 or 2 credits respectively and then modify the code that usually sits and waits for you to hit start, and instead have it immediately start a 1 player or 2 players game if 1 or 2 credits are detected (make the check for p1 or p2 start to always return yes.)

I have not looked at the code yet for that loop but I bet that's what is happening and is probably a reasonable approach.

A good idea is to take it in small steps, for example step one simply override the p1 or p2 start check to return true so the game autos tarts if any credits exist. Once you get that add a little more logic till you finally get the exact behavior your looking for.

Remember you can always add you own code blocks later in empty areas and use a call to access that code then return back.

I think there is empty space near the end of the rom section.
 
Last edited:
yeah i believe you're right, and i think its the 14D7 section i mentioned, but i have to make sense of the bitwise stuff to make it check for start instead of coin input, which change the entire bytes like so:
1p start changes A000 from FF to BF
1p coin changes A000 from FF to 7F

Code:
ROM:14C5 sub_14C5:
ROM:14C5 nop
ROM:14C6 push	 hl
ROM:14C7 push	 de
ROM:14C8 push	 bc
ROM:14C9 push	 af
ROM:14CA ld	 a, (byte_82AA)		;checks coin dip switch
ROM:14CD and	 a
ROM:14CE jr	 nz, loc_14D7		;if zero
ROM:14D0 ld	 hl, 8024h		;then free play is on
ROM:14D3 ld	 (hl), 0FFh		;so set credit counter to FF
ROM:14D5 jr	 loc_1513		;and skip credit button check
ROM:14D7				;else check for credit button inputs
ROM:14D7 loc_14D7:
ROM:14D7 ld	 hl, 82ACh
ROM:14DA ld	 a, (byte_A000)		;poll the 1p input byte
ROM:14DD ld	 b, a
ROM:14DE rra				;? rotate right accumulator
ROM:14DF rl	 (hl)			;? rotate left value in 82AC
ROM:14E1 inc	 hl
ROM:14E2 rl	 b
ROM:14E4 rl	 (hl)
ROM:14E6 inc	 hl
ROM:14E7 ld	 a, (byte_A080)		;poll the 2p input byte
ROM:14EA rla
ROM:14EB rl	 (hl)
ROM:14ED ld	 a, (hl)
ROM:14EE and	 0Fh			;? somehow this is checking
ROM:14F0 cp	 0Ch			;? for 1p coin switch
ROM:14F2 call	 z, sub_1518		;? (7F instead of FF in A000)
ROM:14F5 dec	 hl
ROM:14F6 ld	 a, (hl)
ROM:14F7 and	 0Fh			;"
ROM:14F9 cp	 0Ch			;"
ROM:14FB call	 z, sub_1518
ROM:14FE dec	 hl
ROM:14FF ld	 a, (hl)
ROM:1500 and	 0Fh
ROM:1502 ld	 b, 1
ROM:1504 cp	 0Ch
ROM:1506 jr	 nz, loc_1513
ROM:1508 ld	 a, (byte_89F6)
ROM:150B set	 6, a
ROM:150D ld	 (byte_89F6), a
ROM:1510 call	 sub_152A
ROM:1513
ROM:1513 loc_1513:
ROM:1513 pop	 af
ROM:1514 pop	 bc
ROM:1515 pop	 de
ROM:1516 pop	 hl
ROM:1517 ret
ROM:1517 ; End of function sub_14C5
 
Last edited:
ok if it goes to 0xBF when 1P start is held down
all you have to do to tell if it's held down
is

ld a, (0xA000)
and a, 0x40
call nz some_function

where some_function would
add 1 credit, then
ret

that said I haven't done z80 assembly for a while so I might be wrong I also haven't had a chance to look at the code in question.

-brian



yeah i believe you're right, and i think its the 14D7 section i mentioned, but i have to make sense of the bitwise stuff to make it check for start instead of coin input, which change the entire bytes like so:
1p start changes A000 from FF to BF
1p coin changes A000 from FF to 7F

Code:
ROM:14C5 sub_14C5:
ROM:14C5 nop
ROM:14C6 push	 hl
ROM:14C7 push	 de
ROM:14C8 push	 bc
ROM:14C9 push	 af
ROM:14CA ld	 a, (byte_82AA)		;checks coin dip switch
ROM:14CD and	 a
ROM:14CE jr	 nz, loc_14D7		;if zero
ROM:14D0 ld	 hl, 8024h		;then free play is on
ROM:14D3 ld	 (hl), 0FFh		;so set credit counter to FF
ROM:14D5 jr	 loc_1513		;and skip credit button check
ROM:14D7				;else check for credit button inputs
ROM:14D7 loc_14D7:
ROM:14D7 ld	 hl, 82ACh
ROM:14DA ld	 a, (byte_A000)		;poll the 1p input byte
ROM:14DD ld	 b, a
ROM:14DE rra				;? rotate right accumulator
ROM:14DF rl	 (hl)			;? rotate left value in 82AC
ROM:14E1 inc	 hl
ROM:14E2 rl	 b
ROM:14E4 rl	 (hl)
ROM:14E6 inc	 hl
ROM:14E7 ld	 a, (byte_A080)		;poll the 2p input byte
ROM:14EA rla
ROM:14EB rl	 (hl)
ROM:14ED ld	 a, (hl)
ROM:14EE and	 0Fh			;? somehow this is checking
ROM:14F0 cp	 0Ch			;? for 1p coin switch
ROM:14F2 call	 z, sub_1518		;? (7F instead of FF in A000)
ROM:14F5 dec	 hl
ROM:14F6 ld	 a, (hl)
ROM:14F7 and	 0Fh			;"
ROM:14F9 cp	 0Ch			;"
ROM:14FB call	 z, sub_1518
ROM:14FE dec	 hl
ROM:14FF ld	 a, (hl)
ROM:1500 and	 0Fh
ROM:1502 ld	 b, 1
ROM:1504 cp	 0Ch
ROM:1506 jr	 nz, loc_1513
ROM:1508 ld	 a, (byte_89F6)
ROM:150B set	 6, a
ROM:150D ld	 (byte_89F6), a
ROM:1510 call	 sub_152A
ROM:1513
ROM:1513 loc_1513:
ROM:1513 pop	 af
ROM:1514 pop	 bc
ROM:1515 pop	 de
ROM:1516 pop	 hl
ROM:1517 ret
ROM:1517 ; End of function sub_14C5
 
Back
Top Bottom