- --
Viewing Issue Advanced Details
ID | Category [?] | Severity [?] | Reproducibility | Date Submitted | Last Update |
---|---|---|---|---|---|
05789 | DIP/Input | Minor | Always | Dec 8, 2014, 12:21 | Dec 11, 2014, 16:46 |
Tester | darq | View Status | Public | Platform | MAME (Official Binary) |
Assigned To | AWJ | Resolution | Fixed | OS | Windows Vista/7/8 (64-bit) |
Status [?] | Resolved | Driver | |||
Version | 0.156 | Fixed in Version | 0.157 | Build | Normal |
Fixed in Git Commit | Github Pull Request # | ||||
Summary | 05789: Wrong vblank IP_ACTIVE_HIGH value. | ||||
Description |
The IP_ACTIVE_HIGH in PORT_BIT 0x80 is wrong, the correct value should be IP_ACTIVE_LOW. To prove this, just implement a more realistic vblank read (with vpos usage) and without PORT_VBLANK. If you let IP_ACTIVE_HIGH instead of IP_ACTIVE_LOW, the game stucks after the memory check. I didn't go too deep into vblank implementation code in screen.c, but I really don't understand MCFG_SCREEN_VBLANK_TIME. |
||||
Steps To Reproduce | |||||
Additional Information | |||||
Github Commit | |||||
Flags | Noted in Source, Verified with Code | ||||
Regression Version | |||||
Affected Sets / Systems | |||||
Attached Files
|
|||||
Relationships
There are no relationship linked to this issue. |
Notes
2
No.11287
AWJ Developer
Dec 10, 2014, 02:24
|
Agreed, if you look at the vblank interrupt handler, the first thing it does is copy the palette from work RAM to palette RAM (this has to be done in vblank or you'd get snow, proving that the interrupt does fire at the start of vblank), then it writes to the scroll registers, reads the inputs, and finally waits for $e0044 bit 7 to be *high* before it copies the sprite list from work RAM. This only makes sense if bit 7 transitions from low to high some time after vblank. |
---|---|
No.11290
darq Tester
Dec 11, 2014, 16:46
|
Yes, you are right, in fact I obtained snow, heavy slowdowns or total freeze. |