Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
03462 DIP/Input Minor Always Oct 4, 2009, 20:27 Jan 9, 2010, 04:35
Tester TrevEB View Status Public Platform MAME (Official Binary)
Assigned To Resolution Bugs That Aren't Bugs OS Windows XP (32-bit)
Status [?] Resolved Driver starfire.cpp
Version 0.134 Fixed in Version Build C2D
Fixed in Git Commit Github Pull Request #
Summary 03462: starfir2: service mode does not complete all tests in Star Fire II
Description Tests 4-6 are skipped and the test returns to test 1
Steps To Reproduce Start game, enter service mode. press fire to proceed through the tests. At test 4 screen will show program memory chips for a second, then switch back to test 1
Additional Information
Github Commit
Flags
Regression Version
Affected Sets / Systems starfir2
Attached Files
 
Relationships
There are no relationship linked to this issue.
Notes
21
User avatar
No.05004
Fujix
Administrator
Oct 5, 2009, 05:28
What does it test for 4 to 6, btw?
User avatar
No.05010
TrevEB
Tester
Oct 6, 2009, 03:42
1. Crosshatch
2. Color Bar
3. Control Setup
4. Program Memory
5. Color Memory
6a. Main Ram 7/8th test
6b. Main Ram Full test
User avatar
No.05303
phantomdj
Tester
Dec 24, 2009, 08:30
edited on: Jan 6, 2010, 07:12
Based on the the STARFIR2 game's source code which was recently provided and close analysis using the debugger, I discovered that the program code tries to modify itself (!) and checks to see if the modification was sucessful. If not, the game resets, presumably due to a watchdog kick.

It appears that a fix for this "bug" is to make 3 memory addresses in ROM writeable.

Can we verify whether this bug does or does not exist on an actual arcade machine. Or has this verifcation already been done?

The addresses needed are #5D31, #5D74, and #5D75. This is hard for me to reconsile, since these addresses are supposed to be in READ-ONLY memory but the program code clearly tries to change them and causes the reset when they cannot be changed.

If anyone wants, I can post a partial disassmbly from STARFIR2 with comments written by the game's devoloper.

If you set the breakpoint:

bp 5d42,1,{a=12 ; g}

then the rest of the service mode tests will complete sucessfully. This change fools the code into thinking the ROM had been changed as it wanted.
User avatar
No.05338
TrevEB
Tester
Dec 28, 2009, 18:00
Thank you for doing the research on this!

Would it possible to see if this code exists in Star Fire 1 as well?

Keep in mind that Star Fire 2 was never released. There is no PCB for this game.

I will be attempting to convert an existing SF1 board to SF2 by swapping out the roms.

It is my hope that SF2 was intended to be an upgrade kit consisting of chips and artwork. David Rolfe said it should be possible to do it. If it works, then I will be able to report back any findings.
User avatar
No.05341
phantomdj
Tester
Dec 29, 2009, 07:31
The service mode test for Star Fire 1 are different. It looks like they all complete successfully in MAME.
User avatar
No.05342
TrevEB
Tester
Dec 29, 2009, 15:04
The tests do complete in Mame, though the test for scratchpad ram is not available in emulation yet.

http://www.mametesters.org/view.php?id=3461

There may be something of note by comparing SF1 to SF2.

Also, note that emulation of SF1 is not working correctly. I don't suppose that code rewrite has anything to do with color change? How does SF2 behave after the code is rewritten?

Does the program code get changed back to normal after the test?
User avatar
No.05424
phantomdj
Tester
Jan 6, 2010, 07:23
edited on: Jan 6, 2010, 07:25
I dont think it affects the color at all.

The bytes that are changed are one byte of program code and two bytes of checksums.

It does not look like the bytes are changed back later.

Here is the section of source code from file SFDIAG.ASM from starfire2. This section of code starts at ROM address #5D12.

;LOCATED LAST IN MEMORY
;ALTERS ITSELF AFTER BEING RUN THE FIRST TIME:
; 1) CHANGES ROMALT TO: LD A,@DE ($1A)
; 2) THE LAST USED ADR IN CHKTBL IS CLEARED AND MOVED BACK BY 1 BYTE

DOROM: LD HL,0 ;FIRST ADR TO CHECKSUM
     LD DE,CHKTBL-1 ;CHECKSUM TABLE ADR
     LD C,L ;ROM COUNTER
     LD B,MSB LSTADR ;BUILD ROM COUNT IN B
    REPEAT ROM.E+2
     SRL B ;SHIFT INSIFNIFICANT BITS
    ENDR
     INC B ;GET ROM COUNT IN B

ROMLP: PUSH BC ;PRESERVE COUNT
     LD B,ROM.K*4 ;NUMBER OF $100 BYTES PER ROM
     SUB A ;ZERO STARTS CHECKSUM COUNT
ROMLP1: ADD @HL ;ADD IN NEXT BYTE
     INC L ;NEXT ADR
     JR NZ,ROMLP1 ;DONE 256?
     INC H ;YES, NEW ADR
     DJNZ ROMLP1 ;LOOP FOR ROM
     LD B,A ;PRESERVE CHECKSUM
     INC DE ;NEXT ADR IN CHECKSUM LIST
ROMALT: LD @DE,A ;**CHANGE TO LD A,@DE AFTER FIRST RUN**
     CP B ;DID CHECKSUM CHANGE?
     CALL ROMWRT ;WRITE ROM BLOCK IN C
     POP BC ;NOW RESTORE ROM COUNT
     INC C ;NEXT ROM
     LD A,@$9400 ;SATISFY WATCHDOG
     DJNZ ROMLP ;AND LOOP FOR MORE ROMS

     LD HL,ROMALT ;ROM LOCATION TO ALTER
     LD A,$1A ;HAS IT BEEN CHANGED TO LD A,@DE?
     CP @HL ; ..?
     RET Z ;DONE IF SO
     LD @HL,A ;NO, CHANGE IT NOW
     EX DE,HL ;GET LAST CHECKSUM ADR IN HL
     LD A,$12-$1A ;GET AMOUNT BY WHICH WE CHANGED CHECKSUM
     SUB @HL ;SO THE ENTIRE VALUE GOES TO ZERO
     LD @HL,B ;AND ZERO THE OLD CHECKSUM
     INC HL ;STORE IN NEXT ADR
     LD @HL,A ; ..
     RST $30 ;AND BREAK
User avatar
No.05440
TrevEB
Tester
Jan 7, 2010, 00:50
Providing information on behalf of David Rolfe:

I can tell you what’s happening. It’s an initialization thing.

The checksum table needs to have a checksum value for each ROM.

The way that checksum table gets filled is, once the final code is ready, we run the diagnostics in RAM once time.

It builds the checksum table and makes a small alteration to the checksum calculation routine so that, upon subsequent runs, it will check the checksum rather than building it.

So what you have here is the raw code. To run it for production, it needs to be initialized.

Presumably you can nurse it through the steps to make the one-time changes to itself – that is, fill in the checksum table and change its own code – and THEN you’ll have the final ROM.
User avatar
No.05441
TrevEB
Tester
Jan 7, 2010, 00:56
So I think the best way to proceed would be to allow the code to be modified, thus providing the final rom.

Then submit that rom to Mame to update and correct the existing set.

If you would send me that specific updated rom, that would be very helpful for my project.
User avatar
No.05443
phantomdj
Tester
Jan 7, 2010, 08:55
I have done as you requested. The ROM file sfire2.12 has been modified with the checksum table and the changed instruction to read, instead of write, the checksums. I have tested it and it does work. The self test now completes as it was supposed to.

You can download the updated ROM file set from my site:

http://donhodges.com/starfire/starfir2.zip

Looks like we are well on our way to squashing this bug.

For those that are curious, the following bytes have been changed:

ROM #5D31 changed from 12 to 1A
ROM #5D6F through 5D76 changed from all 00's to 51 47 E8 52 9F 00 93
User avatar
No.05445
etabeta
Developer
Jan 7, 2010, 10:07
it might be better to patch the roms when MAME loads them, leaving the original code unchanged (of course, proper description of the reason the patch is needed should be added as well)
User avatar
No.05449
TrevEB
Tester
Jan 7, 2010, 17:33
Awesome!
Chips burned and ready for a test run.
Sent email to your web site address regarding next possible fix.

http://www.mametesters.org/view.php?id=3460
User avatar
No.05450
Haze
Senior Tester
Jan 7, 2010, 18:23
eta> your comment doesn't make sense. MAME shouldn't contain fixes for bugs which exist on the original.
User avatar
No.05456
phantomdj
Tester
Jan 8, 2010, 06:35
IT would seem after all that this "bug" is not a MAME bug. MAME for this function is working correctly. The problem is that the ROM file that has been supplied for starfire2 is not a production ROM. It was apparently supplied by its creator, David Rolfe, and was not completed 100%.

Either the fixed ROM should be released as a separate entity (starfire2a?), or the MAME starfire2 ROM should be replaced with the "fixed" one.
User avatar
No.05457
etabeta
Developer
Jan 8, 2010, 07:06
d'oh, I misread a couple of comments above, sorry...
User avatar
No.05458
Haze
Senior Tester
Jan 8, 2010, 11:08
I don't think there is need for a change. It's only the test mode, there are tons of games out there with test modes which are broken.

A comment about why the test mode is broken, and what can be done to fix it (if desired) should suffice. The ROM is as it was provided by it's creator, the final state of development it was left in before it was cancelled, that state just happens to have a few bugs left in from the development cycle.
User avatar
No.05459
etabeta
Developer
Jan 8, 2010, 12:05
yup, exactly like dkong & pacman bugs which prevent gameplay on later stages

eventually, a cheat can be added to starfire2.xml to fix this behavior
User avatar
No.05460
TrevEB
Tester
Jan 8, 2010, 15:08
Guys, read what David said.

It is not a bug.
It is raw code designed to initialize and test the finalized roms.

If the game had left the factory, either as a prototype, or mass production, the S12 rom would have been altered as phantomdj has produced.

It is the final s12 rom that belongs in mame.
User avatar
No.05461
Haze
Senior Tester
Jan 8, 2010, 21:01
I'm not arguing what has been said. I respect his work in figuring all this out from the code provided, but given that it never actually shipped back in the day I see no need for a change. The first time the game 'shipped' as such was when these roms were given to Mamedev to support, by the developer, in the form you see them today.

Documenting why the problem exists and how it can be fixed is fantastic, creating a fake fixed rom so that it goes away is not.
User avatar
No.05463
TrevEB
Tester
Jan 8, 2010, 22:52
Ok......
In the meantime, I think this issue can be considered resolved and closed.

I leave it to the higher ups to decide which way is best.

If the roms are to be left alone, then perhaps the "final" rom should be provided such as "sfire2.12a"
since most of us don't do hex editing.

Most of us don't even look at test mode either I suppose.
User avatar
No.05464
phantomdj
Tester
Jan 9, 2010, 04:35
In the event that "fixed" ROMs are not to be supported in MAME, I have posted the cheat info (in the old MAME format - not XML) on Pugsy's cheat forum. Perhaps he will add it to the next cheat archive.

http://www.mamecheat.co.uk/forums/viewtopic.php?f=4&t=3560