Running banked Predator causes crash on coco1/2/3

[JoakimLarsson]

It shouldn't crash but there should also be a compatibility warning from the softlist I think

warning: install_bank_generic: In range ffe0-ffff mirror 0, start address is outside of the global address mask 9294f21, did you mean 4f20 ?

Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffefd5d6063 in KERNELBASE!DebugBreak () from C:\WINDOWS\System32\KernelBase.dll
(gdb) bt
#0  0x00007ffefd5d6063 in KERNELBASE!DebugBreak () from C:\WINDOWS\System32\KernelBase.dll
#1  0x000000000072f611 in emu_fatalerror::emu_fatalerror(char const*, char*) ()
#2  0x000000000072f87b in fatalerror(char const*, ...) ()
#3  0x00000000007321e9 in address_space::check_optimize_mirror(char const*, unsigned int, unsigned int, unsigned int, unsigned int&, unsigned int&, unsigned int&, unsigned int&) ()
#4  0x0000000000743b75 in address_space::install_bank_generic(unsigned int, unsigned int, unsigned int, char const*, char const*) ()
#5  0x0000000000c53fda in sam6883_device::sam_space<(unsigned short)65504, (unsigned short)65535>::point_specific_bank(sam6883_device::sam_bank const&, unsigned int, unsigned int, memory_bank*&, unsigned int, unsigned int, bool) ()
#6  0x0000000000403033 in sam6883_device::configure_bank(int, unsigned char*, unsigned int, bool, device_delegate<unsigned char (address_space&, unsigned int, unsigned char)>, device_delegate<void (address_space&, unsigned int, unsigned char, unsigned char)>) ()
#7  0x00000000004032bd in sam6883_device::configure_bank(int, unsigned char*, unsigned int, bool) ()
#8  0x000000000040748e in coco12_state::configure_sam() ()
#9  0x00000000006f5560 in device_t::start() ()
#10 0x000000000077e72b in running_machine::start_all_devices() ()
#11 0x0000000000784069 in running_machine::start() ()
#12 0x000000000078594b in running_machine::run(bool) ()
#13 0x00000000004bf07f in mame_machine_manager::execute() ()
#14 0x00000000005324f1 in cli_frontend::start_execution(mame_machine_manager*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) ()
#15 0x00000000005329fb in cli_frontend::execute(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) ()
#16 0x00000000004bd107 in emulator_info::start_frontend(emu_options&, osd_interface&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) ()
#17 0x00000000004090b7 in utf8_main(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) ()
#18 0x0000000000b65ace in wmain ()
#19 0x0000000000401410 in __tmainCRTStartup () at C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:329
#20 0x000000000040153b in mainCRTStartup () at C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:212
(gdb)

[npwoods]

At first glance, this is baffling me. The call that is failing is the one that sets up the $FFE0-$FFFF memory bank. I've confirmed that this call is the same whether 'mame64 coco2b predator' is invoked, 'mame64 coco2b popcorn' is invoked, or 'mame64 coco2b' is invoked.

Is there somebody more familiar with the MAME memory subsystem that could look at this (@galibert?)

Any issue with the softlist failing to identify this as a CoCo 3 title incompatible with CoCo/12 should be seen as a separate issue.

[JoakimLarsson]

In fact it SEGfaults for coco3, I am looking at this as I need to figure out coco banking

Starting program: C:\msys64\home\edstrom\work\mame\mame64.exe coco3 predator -window
[New Thread 21604.0x7018]
[New Thread 21604.0x75b4]
[New Thread 21604.0x77fc]
[New Thread 21604.0x7528]
    _/      _/    _/_/    _/      _/  _/_/_/_/
   _/_/  _/_/  _/    _/  _/_/  _/_/  _/
  _/  _/  _/  _/_/_/_/  _/  _/  _/  _/_/_/
 _/      _/  _/    _/  _/      _/  _/
_/      _/  _/    _/  _/      _/  _/_/_/_/

mame 0.189
Copyright (C) Nicola Salmoria and the MAME team

Lua 5.3
Copyright (C) Lua.org, PUC-Rio

[New Thread 21604.0x77f8]
[Thread 21604.0x77f8 exited with code 0]
[New Thread 21604.0x7738]
[New Thread 21604.0x762c]
[New Thread 21604.0x4358]
[New Thread 21604.0x73e8]
[New Thread 21604.0x6cf0]
[New Thread 21604.0x6d78]
[New Thread 21604.0x4714]
[New Thread 21604.0x7314]
[New Thread 21604.0x5c48]
[New Thread 21604.0x7134]
[New Thread 21604.0x6d60]
[MAME]> [New Thread 21604.0x5f8c]
get_cart_base1
get_cart_base1

Thread 1 received signal SIGSEGV, Segmentation fault.
0x00000000026a7c4b in m6809_base_device::device_reset() ()
(gdb) bt
#0  0x00000000026a7c4b in m6809_base_device::device_reset() ()
#1  0x0000000003300a39 in device_t::reset() ()
#2  0x000000000339bc20 in running_machine::run(bool) ()
#3  0x0000000001d6477f in mame_machine_manager::execute() ()
#4  0x0000000001dd7bf1 in cli_frontend::start_execution(mame_machine_manager*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) ()
#5  0x0000000001dd80fb in cli_frontend::execute(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) ()
#6  0x0000000001d62807 in emulator_info::start_frontend(emu_options&, osd_interface&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) ()
#7  0x0000000001cae7b7 in utf8_main(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) ()
#8  0x00000000039353ce in wmain ()
#9  0x0000000000401410 in __tmainCRTStartup () at C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:329
#10 0x000000000040153b in mainCRTStartup () at C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:212
(gdb)```

[galibert]

That kind of address mask, makes me think something scribbled all over memory... OG.

…

On Sun, Sep 24, 2017 at 11:58 PM, npwoods ***@***.***> wrote: At first glance, this is baffling me. The call that is failing is the one that sets up the $FFE0-$FFFF memory bank. I've confirmed that this call is the same whether 'mame64 coco2b predator' is invoked, 'mame64 coco2b popcorn' is invoked, or 'mame64 coco2b' is invoked. Is there somebody more familiar with the MAME memory subsystem that could look at this ***@***.*** <https://github.com/galibert>?) Any issue with the softlist failing to identify this as a CoCo 3 title incompatible with CoCo/12 should be seen as a separate issue. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2673 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AI0i8XcetIqycr9FVvmR1So_uWCEB0cUks5sltCNgaJpZM4PiCRl> .

[JoakimLarsson]

Yes, that is my thought too, I had other values on that mask using trimmed down SUBTARGET builds

[npwoods]

I've recompiled with winalloc, and it seems there is a buffer overrun in cococart_slot_device::call_load(). I can take a look.

[JoakimLarsson]

it looks like the memcopy in cococart.cpp call_load doesn't check that the rom will fit into the rom area, it tries to copy 64Kb into the 32Kb area in the case of predator, so it will overwrite stuff. By upping the rom area from 32Kb to 64Kb in coco_pak.cpp it will fit and not crash. Predator doesn't start up however, maybe because banking is different, I'll have a check

[ajrhacker]

I've fixed not only the ROM area issue, but also some entirely separate problems with the banking. The old implementation tried to reload a 16K area from a file that in softlisted cases wouldn't have been opened. It was also wrong for CoCo 3, whose on-board banking allows for 32K of cartridge space.