Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
07298 Crash/Freeze Major Sometimes Apr 24, 2019, 14:37 Jul 20, 2019, 14:12
Tester star2root View Status Public Platform MAME (Self-compiled)
Assigned To Resolution Open OS MacOS X
Status [?] Confirmed Driver coco3.cpp
Version 0.208 Fixed in Version Build 64-bit
Summary MESS-specific 07298: coco1, coco2, coco2b, coco3: Inserting additional cartridges into the multi-pak causes MAME to crash
Description Inserting either the SSC or an RS232 pak into the multi-pak in slots 1, 2, or 3 causes MAME to crash.
Steps To Reproduce Select external=multi-pak, then leave the disk controller inserted in slot 4 and insert another cartridge into a different slot.
Additional Information On the TI-99/4A, so far the PEB and inserting cards into the PEB slots seems to work, but the coco systems do not.
Regression Version
Affected Sets / Systems coco1, coco2, coco2b, coco3
Attached Files
related to 06655ResolvedAmatCoder cgenie, coco3: Unloading and big changes in interface slots can cause CRASH 
User avatar
Apr 24, 2019, 15:37
related to MT 06655?
User avatar
Apr 24, 2019, 15:54
Same crash, so yeah. It is that interface issue that has yet to be fixed proper
In this case, you can use the command line to perform the slots you want, for example:

> mame64 coco3 -ext multi -ext:multi:slot1 rs232 -ext:multi:slot2 ssc -ext:multi:slot3 orch90

I'll confirm and set up as related.
User avatar
Apr 24, 2019, 19:46
Actually, the latest build (0.209) seems to have fixed this, as long as you reset after making the change.
User avatar
Apr 24, 2019, 21:21
Correction, it still occurs, though not as frequently. I was able to reproduce this issue when loading software from the software list. The attempt to virtually unplug the multi-pak and plug in a cartridge caused MAME to lose it's mind. It is much better behave than before though.
User avatar
Apr 25, 2019, 10:56
edited on: Apr 25, 2019, 11:01
I had no issue inserting the various devices into slots via NewUI (from Tafoid's command-line example), but then I attempted to load a game called backgamm from the software list.

Exception at EIP=01a71fab (cococart_slot_device::call_load()+0x001b): ACCESS VIOLATION
While attempting to read memory at 0000001c
EAX=0ad30228 EBX=0af0863c ECX=0af08440 EDX=01a71c10
ESI=00000001 EDI=0ae5ea98 EBP=0028c4d8 ESP=0028c43c
Stack crawl:
  0028c4d8: 01a71fab (cococart_slot_device::call_load()+0x001b)
  0028c558: 02da515f (driver_device::device_start()+0x005f)
  0028c5e8: 02d66d73 (device_t::start()+0x0463)
  0028c628: 02dfc112 (running_machine::start_all_devices()+0x0072)
  0028c6a8: 02e01073 (running_machine::start()+0x0963)
  0028c738: 02e027f7 (running_machine::run(bool)+0x0127)
  0028f6e8: 0171d5ed (mame_machine_manager::execute()+0x01cd)
  0028f858: 0178abb3 (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&)+0x0463)
  0028fa88: 0178afb9 (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> > > >&)+0x0039)
  0028fab8: 0171b53d (emulator_info::start_frontend(emu_options&, osd_interface&, std::vector<std::__cxx11::basic_string<char, std::char_trait
s<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&)+0x002d)
  0028feb8: 05a9025a (main+0x012a)
  0028ff88: 004013e2 (__tmainCRTStartup+0x0272)
  0028ff94: 763a336a (BaseThreadInitThunk+0x0012)
  0028ffd4: 779298f2 (RtlInitializeExceptionChain+0x0063)
  0028ffec: 779298c5 (RtlInitializeExceptionChain+0x0036)
User avatar
Apr 25, 2019, 11:05
More testing... since my settings are saved in coco3.ini, attempting to restart coco3 resulted in an immediate crash. However it was noted that the fdc had been unplugged prior to the crash. So, I modified coco3.ini to leave the game cart in, and removed ext multi. The system then started up and the backgammon game worked.
Then I loaded ext multi and this resulted in another crash with the same dump as previous. So, it seems there's some kind of conflict between game carts and the ext multi.
User avatar
Apr 27, 2019, 09:46
That is what I have found on further testing also.
User avatar
Jul 20, 2019, 14:12
edited on: Jul 20, 2019, 16:40
Original bug has been fixed, however the conflict between multi and game carts still happens.