 No.05004
Fujix Administrator
Oct 5, 2009, 05:28
|
What does it test for 4 to 6, btw? |
|---|---|
 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 |
|
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. |
|
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. |
|
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. |
|
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? |
|
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 |
|
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. |
|
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. |
|
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 |
|
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) |
|
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 |
|
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. |
|
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. |
|
No.05457
etabeta Developer
Jan 8, 2010, 07:06
|
d'oh, I misread a couple of comments above, sorry... |
|
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. |
|
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 |
|
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. |
|
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. |
|
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. |
|
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 |