Viewing Issue Advanced Details
|ID||Category [?]||Severity [?]||Reproducibility||Date Submitted||Last Update|
|02587||Gameplay||Major||Always||Oct 23, 2008, 21:18||Oct 31, 2008, 18:39|
|Tester||Haze||View Status||Public||Platform||MAME (Self-compiled)|
|Assigned To||couriersud||Resolution||Fixed||OS||Windows XP/Vista 32-bit|
|Version||0.128u1||Fixed in Version||0.128u2||Build||Normal|
|Fixed in Git Commit||Github Pull Request #|
|Summary||02587: lohtb2: lohtb2 protection emulation is imperfect|
lohtb2 is now using the actual MCU dumped from the bootleg board.
I strongly believe this is an exact copy of the original MCU, done by the bootleggers, and the game should behave the same way as an original.
With the current MCU emulation the powerup are missing (see attract mode, after the first small statue there should be a powerup, the player should collect this to get a 'wider' shot and be able to kill the head on the wall) Without the powerup the attract mode finishes early.
In lohtj (which uses simulation code instead) this powerup is present
If the simulation code is used instead of the emulation with lohtb2 this powerup appears in lohtb2
If the MCU emulation is used with lohtj the powerup vanishes in that too.
The mising powerup is clearly related to the MCU emulation being used.
Couriersud had the following to say about the issue
On each line 1 interrupt during the copyright message, the mcu checks
the sound command address (0x0002) and if there is a 0x10 or 0x11 will
write this value to internal ram address 0x30-0x37, i.e. on 1st
interrupt to 0x30, than 0x31, .., 0x37, roll over to 0x30. The 0x10 has
to be some kind of repeating signal. Therefore it is connected to
vblank. I have no idea about the lower bit. Using mame_rand to set it
works as well. Other code will check 0x30 for 0x11/0x10 and do something
not yet understood. So there are still some bits missing.
The simulation just writes bytes here and there so that the game will
start and not crash. Is the behavior confirmed on a real PCB?
Ideally confirmation that this powerup is present on a Japanese LOHT board, as well as this specific bootleg (with the MCU, not the one hacked to work without it) would be good.
(assigned to couriersud for now so that it doesn't get forgotten)
|Steps To Reproduce|
|Affected Sets / Systems||lohtb2|
|There are no relationship linked to this issue.|
Oct 25, 2008, 23:52
|Hopefully the changes to the 80X51 core will make debugging easier now. Not forgotten.|
Oct 26, 2008, 19:33
0x68,0x00,0xa0, // push 0a000h
0x1f, // pop ds
0xc6,0x06,0x3c,0x38,0x47, // mov [383ch], byte 047h
0xc6,0x06,0x3d,0x38,0x47, // mov [383dh], byte 047h
0xc6,0x06,0x42,0x38,0x44, // mov [3842h], byte 044h
0xc6,0x06,0x43,0x38,0x44, // mov [3843h], byte 044h
Setting the memory to these values will enable the powerups.
Oct 26, 2008, 21:05
yes, that's what the previous simulation did, because the games have various checks. what needs to be worked out is why they *don't* get set using the mcu emulation code, they surely should.
loht misses powerups if the memory doesn't get set up correctly, other games have lockups at the end of levels etc. (loht might have that too, but I haven't played for long enough)
Oct 28, 2008, 08:02
edited on: Oct 28, 2008, 08:03
I am getting nearer. The whole setup is contolled by timer 0 of the 8751. The mcu will write code to the main cpu, unlock the cpu (memory lock) and wait for signal that the code has finished. If the code execution takes too long, it will time out and continue with the next piece of code.
I have a workaround which I will submit soon after some more testing. This will run the whole cycle. As a consequence, all memory locations are initialized and powerups work as well. It will however not display the "Warning" screen due to a priority issue. With color/attribute of 0x80 in videoram at 0xd0000 and 0xd8000, videoram at 0xd80000 will be displayed.
Some memory locations so that I do not forget them