Main > Driving & Racing Cabinets

Mame hacks that make driving games play better with mouse/spinner/360wheel

<< < (17/22) > >>

Yolo_Swaggins:
For some reason i can get the hdrivairp game to load up the first warp level but the game acts like i am offroad all the time. Never used to load for me. Thought it might be something to do with the diagnostic jumper.



geecab:
That's cool! So what do you think are the main differences are between hdrivairp and hdrivair? Looks like the dash has had a make over on hdrivairp...

Good work btw on the nvram work. I wasn't able to write new CNTSPTRN and PATCEN values to the nvram files for hard drivin, race drivin or street drivin. When I load the game, my edited nvram files just get ignored and I go straight into the service / wheel calibration mode (As if no nvram files existed). Are you able to write new CNTSPTRN and PATCEN values with your script without them being ignored then? Probably have a bug in my script, I wrote it pretty quick :)

Yolo_Swaggins:
I'm using the HxD hex editor to make the changes to the combined nvram file then splitting it back up into the 2 original files and it works. Did you check if it's combining the files in the right order? the one that works for me is combined_high_200e_low_210e but not combined_high_210e_low_200e. When i look at it in a hex editor i can see the names for the high scores.

This is the script i use to combine them


--- Code: ---def combine_high_low(high_bytes, low_bytes):
    """Combines two byte arrays where the first array provides the high byte
    and the second array provides the low byte for each 16-bit word."""
    if len(high_bytes) != len(low_bytes):
        raise ValueError("Both files must have the same length.")
    combined = []
    for hb, lb in zip(high_bytes, low_bytes):
        # Combine into a 16-bit word
        combined_word = (hb << 8) | lb
        # Append high byte
        combined.append(combined_word >> 8)
        # Append low byte
        combined.append(combined_word & 0xFF)
    return bytes(combined)

def read_file(file_path):
    """Reads a file and returns its contents as a byte array."""
    with open(file_path, 'rb') as file:
        return file.read()

def write_file(file_path, data):
    """Writes binary data to a file."""
    with open(file_path, 'wb') as file:
        file.write(data)

def read_address(data, address):
    """Reads a 16-bit value from the combined data at a specified address."""
    # Each address points to two bytes forming a 16-bit value
    index = address * 2
    return data[index] << 8 | data[index + 1]

def main():
    # Paths to the input files
    path_200e = 'F:/Desktop/MAME/nvram/harddrivcb/mainpcb_200e'
    path_210e = 'F:/Desktop/MAME/nvram/harddrivcb/mainpcb_210e'
   
    # Read the files
    data_200e = read_file(path_200e)
    data_210e = read_file(path_210e)
   
    # Combine files: High byte from 200e, low byte from 210e
    combined_high_200e_low_210e = combine_high_low(data_200e, data_210e)
    # Combine files: High byte from 210e, low byte from 200e
    combined_high_210e_low_200e = combine_high_low(data_210e, data_200e)
   
    # Save the combined data to new files
    write_file('F:/Desktop/MAME/nvram/harddrivcb/combined_high_200e_low_210e', combined_high_200e_low_210e)
    write_file('F:/Desktop/MAME/nvram/harddrivcb/combined_high_210e_low_200e', combined_high_210e_low_200e)

    # Read specific addresses
    address_212 = read_address(combined_high_200e_low_210e, 0x212)
    address_213 = read_address(combined_high_200e_low_210e, 0x213)
    print(f"Address 0x212: {address_212} (0x{address_212:04X})")
    print(f"Address 0x213: {address_213} (0x{address_213:04X})")
   
    print("Files combined successfully and saved.")

if __name__ == '__main__':
    main()

--- End code ---

Then this is the one i use to split it up.


--- Code: ---def read_combined_file(file_path):
    """Reads the combined file and returns its contents as a byte array."""
    with open(file_path, 'rb') as file:
        return file.read()

def split_combined_file(data):
    """Splits the combined data back into high and low byte arrays."""
    high_bytes = []
    low_bytes = []
    for i in range(0, len(data), 2):  # Process two bytes at a time
        high_byte = data[i]           # High byte (from the first file)
        low_byte = data[i + 1]        # Low byte (from the second file)
        high_bytes.append(high_byte)
        low_bytes.append(low_byte)
    return bytes(high_bytes), bytes(low_bytes)

def write_file(file_path, data):
    """Writes binary data to a file."""
    with open(file_path, 'wb') as file:
        file.write(data)

def main():
    # Path to the combined file
    combined_path = 'F:/Desktop/MAME/nvram/harddrivcb/combined_high_200e_low_210e'
   
    # Read the combined file
    combined_data = read_combined_file(combined_path)
   
    # Split the combined file back into original high and low files
    high_data, low_data = split_combined_file(combined_data)
   
    # Save the split data back to original file paths
    write_file('F:/Desktop/MAME/nvram/harddrivcb/mainpcb_200e', high_data)
    write_file('F:/Desktop/MAME/nvram/harddrivcb/mainpcb_210e', low_data)
   
    print("Files have been successfully split and saved.")

if __name__ == '__main__':
    main()

--- End code ---

If i write a value into a place it shouldn't be it makes the test menu pop up on boot. if i just copy the section that contains the calibration info or alter it it works fine and i can see the changes it makes when i enter the test menu.

Yolo_Swaggins:
From:   KIM::MARGOLIN     17-JUL-1991 16:33:59.46
To:   RAY,MONCRIEF,SMITHSON
CC:   MARGOLIN
Subj:   BM


1. The only problem I can think of relates to the use of the new OptoCoupler
Pot. When this pot is used, Resistors R182, R183, and R184 mut be removed.
(They do not appear on the production parts list.)

2. In the Driver, one of the 8 bit A/D inputs was connected to a half wave,
unfiltered sample from one of the transformer secondaries. In Self-Test I
calculated RMS by appropriate MultiPlies and Square Root routines.

The routines were never installed in a MultiSync and would take time to
convert. The harness and power supply board would have to be modified to
provide this additional signal.

The following is a description of the Opto Reader:

   
Optocoupler Decoding Means
--------------------------
The quadrature outputs of the Optocoupler are latched at 8 MHz in 185U.
These latched outputs (NEWQ0 and NEWQ1) are once again latched at 8 MHz to
provide a delayed version of the signals (OLDQ0 and OLDQ1).

The reason for creating delayed versions of the signals is to permit the
detection of signal edges by PROM 195U.

The PROM determines whether a counter should be clocked, and if so, in
what direction.

The Latch/PROM do not constitute a state machine since there is no feedback
from the PROM.

If an illegal state is produced, the PROM will not clock the counter.

One 8 MHz clock after Q0 and Q1 from the OptoCoupler produce a valid sequence
the circuit will operate. It cannot get hung up.


   SECTION PROGRAM


_______________________________________


I think this is referring to Steel talons but i thought i'd share it incase it was something that wasn't known before, been looking through the internal atari emails from around 1990/1991.


Just found this one too.

From:   KIM::MILTY        18-JUL-1991 08:06:16.14
To:   @ENCODER.LIS
CC:   
Subj:   OPTICAL ENCODER USES


 I HAVE BEEN ASSIGNED THE TASK OF DESIGNING THE NEXT GENERATION "TESTER"
FOR THE OPTICAL ROTARY ENCODER (THE LITTLE GUY ,ABOUT THE SIZE OF OUR 5K
POT ).
 "I NEED INPUT"..HOW IS THIS ENCODER ENVISIONED BEING USED ?
I MEAN ,IN TERMS OF RESOLUTION.....HOW FAST WILL IT SPIN...?
THE OUTPUT RATE IS 128 PULSES/REVOLUTION PER CHANNEL (2 CHANNELS
IN QUADRATURE 90 DEGREES APART )
"BADLANDS STEERING" WAS 1:1 WITH A 58 PULSES/REVOLUTION RATE.
"WHIRLY-GIG          IS 1:1 WITH A 72   "        "        "
"RACE DRIVIN (COMPACT)" 1:1 WITH A 72   "        "        "
"ROADBLASTERS"      WAS GEARED 1:4 WITH A 36 P/R RATE....BUT THEN
                    THE STEERING WAS RESTRICTED TO 1/2 TURN,SO A
                    TOTAL OF 72 PULSES WOULD BE "SEEN" FROM
                    LOCK TO LOCK OF THE STEERING CONTROL.
....SOOO,LOOKING DOWN THE ROAD,...HOW MUCH "RESOLUTION" COULD WE
USE ,...
"GUMBALL RALLY" HAD AN ENCODER ON EACH MOTOR WHICH COULD SPIN AS FAST
AS 3600 RPM WITH 24 PULSES/ROTATION (1440 PULSES/SEC )...TO DO THE
SAME JOB THIS NEW ENCODER WOULD NEED TO SPIN AT 675 RPM.
 IS THIS A TYPICAL APPLICATION ????
I UNDERSTAND LETA GETS INVOLVED IN THE CIRCUIT,...RUSTY,WHAT LIMITATIONS
MIGHT BE ENCOUNTERED? IS IT JUST PROCESSOR SPEED LIMITED?

IS THERE ANY REASON TO PURSUE 1,000 PULSES / MILLISECOND ?



IF YOU HAVE ANY REQUIREMENTS,POSSIBLE APPLICATIONS,IDEAS,PERTINENT INFO OR DATA PLEASE
REPLY TO THIS ADDRESS.

         MILTY
__________________

geecab:
>>If i write a value into a place it shouldn't be it makes the test menu pop up on boot. if i just copy the section that contains the calibration info or alter it it works fine and i can see the changes it makes when i enter the test menu.

Hm, so I think you are copying a block of bytes? My script just changes 2 bytes for CNTSPTRN, and 2 bytes for PATCEN. I'm pretty sure it is editing/saving the nvrams correctly. After it changes the 4 bytes to something new (stopping the nvrams from working), I can use my script to revert back the 4 bytes back to what they were, and then it works. No big deal this I guess, but it would be handy if it worked :)

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version