|
Testers ID:4027 (20pacgal hangs at boot)
#240283 - 12/03/10 06:56 PM
|
|
|
I find the problem in the following routine. See memory.c.
Code:
void address_space::prepare_map() { const region_info *devregion = (m_spacenum == ADDRESS_SPACE_0) ? m_machine.region(m_device.tag()) : NULL; UINT32 devregionsize = (devregion != NULL) ? devregion->bytes() : 0;
// allocate the address map m_map = global_alloc(address_map(m_device.baseconfig(), m_spacenum));
// extract global parameters specified by the map m_unmap = (m_map->m_unmapval == 0) ? 0 : ~0; if (m_map->m_globalmask != 0) { m_addrmask = m_map->m_globalmask; m_bytemask = address_to_byte_end(m_addrmask); }
// make a pass over the address map, adjusting for the device and getting memory pointers for (address_map_entry *entry = m_map->m_entrylist.first(); entry != NULL; entry = entry->next()) { // computed adjusted addresses first entry->m_bytestart = entry->m_addrstart; entry->m_byteend = entry->m_addrend; entry->m_bytemirror = entry->m_addrmirror; entry->m_bytemask = entry->m_addrmask; adjust_addresses(entry->m_bytestart, entry->m_byteend, entry->m_bytemask, entry->m_bytemirror);
"entry->m_addrmask" will be "0" in this time so that "entry->m_bytemask" also "0". In this case, adjust_address() with mirror != 0 causes wrong mask adjustment.
Code:
inline void address_space::adjust_addresses(offs_t &start, offs_t &end, offs_t &mask, offs_t &mirror) { // adjust start/end/mask values if (mask == 0) mask = m_addrmask & ~mirror; else mask &= m_addrmask; start &= ~mirror & m_addrmask; end &= ~mirror & m_addrmask;
In 20pacgal.c, "0xA000 - 0xFFFF" is defined as "AM_RANGE(0x0a000, 0x0ffff) AM_MIRROR(0x40000) AM_ROM". So... adjusted mask is "(0xFFFFF & 0xBFFFF (= ~0x40000)) = 0xBFFFF" (Not 0xFFFFF!).
This value is used in find_backing_memory() to add requested memory entry into each handlers. The problem happens when compare "0xA000 - 0xFFFF" (ROM) vs "0x4FF00 - 0x4FFFF" (sprite_color_lookup). Start_address is "0x4FF00 & 0xBFFFF = 0xFF00" and end_address is "0x4FFFF & 0xBFFFF = 0xFFFF". So write_handler regists "ROM" entry as "sprite_color_lookup" and it breaks the contents of ROM at boot sequence.
Quick fix is...
Code:
// computed adjusted addresses first entry->m_bytestart = entry->m_addrstart; entry->m_byteend = entry->m_addrend; entry->m_bytemirror = entry->m_addrmirror; entry->m_bytemask = m_bytemask; adjust_addresses(entry->m_bytestart, entry->m_byteend, entry->m_bytemask, entry->m_bytemirror);
Main point is that set tha value for (global) address_space's "m_bytemask" instead of address_map_entry's.
|
"Any company has no power to stop people emulating"
MAME is the emulator of no giving in the pressure from any company even if they don't allow
|
|
|
|
I can finally search a memory and create cheat codes based on 0.140u1...
[ATTACHED IMAGE]
Edited by ShimaPong (12/04/10 03:35 AM)
|
"Any company has no power to stop people emulating"
MAME is the emulator of no giving in the pressure from any company even if they don't allow
|
|
redk9258 |
Regular
|
|
|
Reged: 09/21/03
|
Posts: 3968
|
Loc: Troy, Illinois USA
|
|
Send PM
|
|
|
Re: Testers ID:4027 (20pacgal hangs at boot)
[Re: ShimaPong]
#240341 - 12/04/10 03:52 AM
|
|
|
> I can finally search a memory and create cheat codes based on 0.140u1...
But are you going to share them with others?
|
|
|
redk9258 |
Regular
|
|
|
Reged: 09/21/03
|
Posts: 3968
|
Loc: Troy, Illinois USA
|
|
Send PM
|
|
|
Re: Testers ID:4027 (20pacgal hangs at boot)
[Re: ShimaPong]
#240342 - 12/04/10 04:03 AM
|
|
|
Recompiled with your change. Deleted sta, nv ram and cfg files, still stuck IRQ message.
|
|
|
|
Re: Testers ID:4027 (20pacgal hangs at boot)
[Re: redk9258]
#240364 - 12/04/10 09:02 AM
|
|
|
> > I can finally search a memory and create cheat codes based on 0.140u1... > > But are you going to share them with others?
I really don't understand why people still waste their time with this guy.
|
|
|
|
Re: Testers ID:4027 (20pacgal hangs at boot)
[Re: Mamesick]
#240382 - 12/04/10 03:50 PM
|
|
|
> > > I can finally search a memory and create cheat codes based on 0.140u1... > > > > But are you going to share them with others? > > I really don't understand why people still waste their time with this guy.
Hope dies last? Also, for some MAMEWorld seems to act like the VR counterpart of Viagra, pimping their virtual Asian
...and therefore can be quite funny to watch if you keep it at the back of your mind that sharing will never take place. (Would be funny if Aaron would switch the cheat engine back to standard C, too.)
|
|
|
|
|
> Recompiled with your change. Deleted sta, nv ram and cfg files, still stuck IRQ message.
Don't worry. I have confirmed on 0.140u1 surely and passed the initialization and searched the memory and tested my customized cheat system. Memory search and chaet codes work fine even in this version and I have not had a problem right now though I'm now testing.
I don't know why still hangs after the fix because you lacks some info. So please try to test the follwoings and report again. - Set breakpoint $D779 (20pacgal) then check that writing a memory breaks (or doesn't braek) the contents between $FFF0 - $FFFF. - Check the value of "entry->m_bytemask" in prepare_map() on memory.c is NOT "0" just before calls adjust_addresses().
The reason of this bug will be that "incomplete" source is set and used like a single character for tagmap_hash. But there are the problem on MAME core side (not each drivers) so that more info and test are required.
[ATTACHED IMAGE - CLICK FOR FULL SIZE]
|
"Any company has no power to stop people emulating"
MAME is the emulator of no giving in the pressure from any company even if they don't allow
|
|
|
Re: Testers ID:4027 (20pacgal hangs at boot)
[Re: Mamesick]
#240384 - 12/04/10 04:28 PM
|
|
|
> I really don't understand why people still waste their time with this guy.
Because many people want to "enjoy cheating" I hate the most just like your "hack" MAME wins a rave review.
|
"Any company has no power to stop people emulating"
MAME is the emulator of no giving in the pressure from any company even if they don't allow
|
|
R. Belmont |
Cuckoo for IGAvania
|
|
|
Reged: 09/21/03
|
Posts: 9716
|
Loc: ECV-197 The Orville
|
|
Send PM
|
|
|
Re: Testers ID:4027 (20pacgal hangs at boot)
[Re: redk9258]
#240388 - 12/04/10 05:15 PM
|
|
|
> Recompiled with your change. Deleted sta, nv ram and cfg files, still stuck IRQ > message.
Aaron indicates that Shima's proposed fix is wrong and will break thousands of other drivers, so you shouldn't compile with that change. That said, it does at least point in the right direction.
|
|
|
|
Re: Testers ID:4027 (20pacgal hangs at boot)
[Re: ShimaPong]
#240390 - 12/04/10 05:26 PM
|
|
|
> > I really don't understand why people still waste their time with this guy. > > Because many people want to "enjoy cheating" I hate the most just like your "hack" > MAME wins a rave review.
At least my "hack" MAME works fine. Your fixes don't. And nobody can prove except yourself that your fucked cheats work or they are fakes. That said, I don't want to spend more time with you. Bye.
|
|
|
|
Re: Testers ID:4027 (20pacgal hangs at boot)
[Re: CrapBoardSoftware]
#240396 - 12/04/10 06:21 PM
|
|
|
When the next full release comes out, I can't wait to see what killscreen I'll get on Ms. Pac-Man (turbo speed) V1.00. I've been collecting killscreen info on as many "Class Of 1981" releases, and that'll be the next one. I still don't know if V1.05, V1.06, or V1.07 exist.
Sam Miller [email protected]
|
|
|
redk9258 |
Regular
|
|
|
Reged: 09/21/03
|
Posts: 3968
|
Loc: Troy, Illinois USA
|
|
Send PM
|
|
|
Re: Testers ID:4027 (20pacgal hangs at boot)
[Re: ShimaPong]
#240403 - 12/04/10 09:02 PM
|
|
|
Sorry, all of that is over my head.
|
|
|
|
|
> At least my "hack" MAME works fine. Your fixes don't. Yes, you are winner.
> I don't want to spend more time with you. Bye I want to spend more time though. You often reply the post I posted or related. If you don't want to spend more time, you should not reply any message. Otherwise, you should spend more time to hack MAME drivers and report/send it. Your partner, MASH, sometimes report (invalid) bugs with a hack-fix for Testers but I don't hear your hack recently so that I feel lonely.
Anyway, I search a memory for (secret) Pac-Man in 20pacgal and created "Add Ms.Pac-Man/Pac-Man Toggle Button" code. And added debugger command "resetcheat" and "reloadcheat" and cheat_manager::menu_update() to re-draw internal menu from out of UI.
[ATTACHED IMAGE]
|
"Any company has no power to stop people emulating"
MAME is the emulator of no giving in the pressure from any company even if they don't allow
|
|
|
> ALL
[Re: ShimaPong]
#240451 - 12/05/10 07:41 AM
|
|
|
Sorry my report, especially redk9258 but except Mamesihacker.
I compare the sequence of memory_init() between 0.140u1 and 0.139 and confirm both point to ROM region at find_backing_memory() point. Therefore my reported fix is not correct and even wrong.
Main difference is that "baseptr" is adjusted in 0.139 but not 0.140u1 so that write_handler breaks a code in ROM then hangs (I believe the main reason of hang). Further investigation is required, thanks! (except Mamesihacker)
|
"Any company has no power to stop people emulating"
MAME is the emulator of no giving in the pressure from any company even if they don't allow
|
|
|
|
Again
I re-trace memory.c and find different behavior between 0.139 and 0.140. See screenshot. locate_memory() doesn't assign the bank for $4FFF0 - $4FFFF in 0.140 though 0.139 re-assign it to expected memory from ROM region. "bank->base() == NULL" is FALSE because the base pointer in this bank is already filled at that point though it points to ROM region.
So rough fix is...
if (bank->base() == NULL && bank->references_space(*this, ROW_READWRITE))
to
if (bank->references_space(*this, ROW_READWRITE))
[ATTACHED IMAGE]
|
"Any company has no power to stop people emulating"
MAME is the emulator of no giving in the pressure from any company even if they don't allow
|
|