05541: coco2b and coco3/3h: coco2b and coco3/3h will not run correct versions of NitrOS-9

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	trs/coco12.cpp
Version	0.153	Fixed in Version	0.154	Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	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. stock static MACHINE_CONFIG_DERIVED( coco2b, coco2 ) MCFG_MC6847_REMOVE(VDG_TAG) MCFG_MC6847_ADD(VDG_TAG, MC6847T1_NTSC, XTAL_3_579545MHz, coco12_state::mc6847_config) MACHINE_CONFIG_END test static MACHINE_CONFIG_DERIVED( coco2b, coco2 ) // MCFG_MC6847_REMOVE(VDG_TAG) // MCFG_MC6847_ADD(VDG_TAG, MC6847T1_NTSC, XTAL_3_579545MHz, coco12_state::mc6847_config) MACHINE_CONFIG_END 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 http://nitros9.sourceforge.net/latest The disks to test are: nos96809l1v030300coco2_80d.dsk nos96809l1v030300coco2b_80d.dsk nos96809l2v030300coco3_80d.dsk Change the extensions from .dsk to .os9 before mounting in MESS.
Additional Information
Github Commit

Flags
Regression Version
Affected Sets / Systems	coco2b and coco3/3h

Attached Files

No.10615 Robert Gault Tester 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 DOS [ENTER] 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.
No.10618 Tafoid Administrator 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).
No.10620 Robert Gault Tester 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.
No.10621 Osso Moderator 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?
No.10624 Robert Gault Tester Apr 24, 2014, 19:23	Osso, 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.
No.10625 Robert Gault Tester 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
No.10626 Osso Moderator 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).
No.10627 Robert Gault Tester Apr 25, 2014, 11:00	I just updated and tested. It is all working. Thank you very much for the fixes!