Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
05541 Core Major Always Apr 20, 2014, 15:33 Apr 25, 2014, 11:00
Tester Robert Gault View Status Public Platform MESS (Official Binary)
Assigned To Osso Resolution Fixed OS Windows XP
Status [?] Resolved Driver coco12.cpp
Version 0.153 Fixed in Version 0.154 Build Normal
Summary MESS-specific 05541: coco2b and coco3/3h: coco2b and coco3/3h will not run correct versions of NitrOS-9
Description When attempting to boot NitrOS-9, coco2b, coco3, and coco3h will freeze solid. The instruction is CWAI #$AF. However, it is not that simple.

The difference between coco2 and coco2b is the MC6874 and MC6874Ti video chips. The version of NitrOS-9 for the coco2b uses true lower case. That for
the coco2 uses inverse text characters. Coco2b emulation will freeze with both the coco2 and coco2b disks.
As a test, I compiled MESS after changing src/mess/drivers/coco12.asm. The following lines were commented out.
static MACHINE_CONFIG_DERIVED( coco2b, coco2 )
MCFG_MC6847_ADD(VDG_TAG, MC6847T1_NTSC, XTAL_3_579545MHz, coco12_state::mc6847_config)

static MACHINE_CONFIG_DERIVED( coco2b, coco2 )
// MCFG_MC6847_ADD(VDG_TAG, MC6847T1_NTSC, XTAL_3_579545MHz, coco12_state::mc6847_config)

With this change coco2b emulation will run both disks without freezing although you can't read the screen with the coco2b disk.

Similar problems exist with coco3/3h emulation and NitrOS-9 Level2 which freezes when booting. Coco3 emulation will run normally using a coco2 disk or a coco2b disk with Level1.
Steps To Reproduce Obtain test disks from
The disks to test are:
Change the extensions from .dsk to .os9 before mounting in MESS.
Additional Information
Regression Version
Affected Sets / Systems coco2b and coco3/3h
Attached Files
There are no relationship linked to this issue.
User avatar
Robert Gault
Apr 22, 2014, 16:41
I should have said that once one of the above disks is mounted in the first drive, you start NitrOS-9 with
The boot process will start and you will see a list of modules being loaded into memory. If the process is going to freeze, it will happen when you are asked to enter the date. No key strokes will register if the boot process has frozen. If the debugger is active and you switch to it, the current instruction will be a CWAI.

With the limited knowledge I have on how MESS actually works, I could not find how changing from MC6847_NTSC to MC6847TI_NTSC could possibly cause a freeze at this point. I have not found the analogous difference between Level1 and Level2 that would freeze coco3 and coco3h emulation at the same instruction.
User avatar
Apr 22, 2014, 19:47
The only one really knowledgeable with the COCO driver has not really had much time to work on bug fixes or development. You are obviously the most knowledgeable COCO user - does this work on any previous version? Unfortunately due to the nature of MAME, it's core, one part of one device can throw a whole driver out of whack (as you've observed, I'm sure).
User avatar
Robert Gault
Apr 23, 2014, 01:52
Emulation was still normal with the .152b release for both NitrOS-9 Level1 or Level2 with the appropriate versions coco2, coco2b, coco3, and coco3h.

I would think that there are only two sources for an unresponsive keyboard, keyboard emulation or incorrect CWAI emulation. What complicates matters is that Level1 on a coco3 will not freeze while it does on a coco2b. Further that Level2 freezes on coco3 or coco3h emulation. That suggests the problem is not with keyboard emulation. However, I don't see how a change from MC6847 to MC6847TI can alter interrupt emulation on a coco2b. There are lots of possibilities for failure on a coco3 as the GIME chip controls both video and interrupt service.

I've looked through all the coco, MC6847, and GIME source code I can find and nothing stands out for me. The only clue to the problem is that removal of MC6847TI from coco2b emulation removes the freeze. That clue ought to make correction simple for anyone who really understands the source code which I do not.
User avatar
Apr 23, 2014, 06:26
edited on: Apr 23, 2014, 07:01
Please try adding:
MCFG_MC6847_HSYNC_CALLBACK(WRITELINE(coco12_state, horizontal_sync))
MCFG_MC6847_FSYNC_CALLBACK(WRITELINE(coco12_state, field_sync))
at line 345 of drivers/coco12.c
The clone was probably just overlooked.

EDIT: Did coco3 work in the last few MESS versions?
User avatar
Robert Gault
Apr 24, 2014, 19:23
That fix worked and now coco2b emulation works correctly with NitrOS-9.

Coco3 emulation worked correctly in 152b and for many subsequent revisions. I don't know when it started freezing as described above . I'm not able to determine that as it would not be noticeable without trying to run NitrOS-9. I don't always check when updating the source code and recompiling.
User avatar
Robert Gault
Apr 25, 2014, 02:09
This bug should not be marked resolved as coco3 and coco3h emulation still do not run NitrOS-9 but freeze exactly as coco2b emulation froze.

However, the same fix is not likely to work as driver/coco3.c contains
MCFG_GIME_HSYNC_CALLBACK(DEVWRITELINE(PIA0_TAG, pia6821_device, ca1_w)) // TODO not hooked up in gime.c
MCFG_GIME_FSYNC_CALLBACK(DEVWRITELINE(PIA0_TAG, pia6821_device, cb1_w)) // TODO not hooked up in gime.c
User avatar
Apr 25, 2014, 05:45
have you updated the source? They both work from r29862 onwards.
The coco3 problem was a typo (irq callback in a firq callback macro).
User avatar
Robert Gault
Apr 25, 2014, 11:00
I just updated and tested. It is all working.

Thank you very much for the fixes!