Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
04811 Gameplay Minor Always May 8, 2012, 03:23 May 10, 2012, 13:59
Tester Robert Gault View Status Public Platform MESS (Self-compiled)
Assigned To micko Resolution Fixed OS Windows XP
Status [?] Resolved Driver coco3.cpp
Version 0.145u8 Fixed in Version 0.146 Build Normal
Summary MESS-specific 04811: coco3, coco3h: RTC emulation is not working
Description The summary says it all. I will attempt to upload a zip file containing two .dsk images. These disks contain a test program that demonstrates adding a new string function to Basic, DATE$. This will read the RTC for date and time.

Try the programs with coco3(h) emulation with 0.145u7 or older versions of MESS. The programs will work. They don't with 0.145u8.
Steps To Reproduce Start either coco3 or coco3h emulation. Use ANY software that should be able to read the MESS RTC, Disto or Cloud-9.
The enclosed zip contains two .dsk images that can be used to test either RTC unit.

1) mess coco3 -flop1 DISTOswread.DSK
2) type: RUN "SWREAD
3) The message will show up: CLOCK NOT FOUND

Previous versions would show the precise time based on current PC time.
Additional Information
Regression Version 0.145u8
Affected Sets / Systems coco3, coco3h
Attached Files
zip file icon MESS RTC (3,077 bytes) May 8, 2012, 03:23 Uploaded by Robert Gault
There are no relationship linked to this issue.
User avatar
May 8, 2012, 04:10
edited on: May 8, 2012, 04:24
Before we can even validate this bug, you need to provide the exact procedure needed to duplicate. Please modify/edit your bug in Steps to Reproduce field to illustrate exactly how to load or enable the device in question. I modified some fields and tried to simplify the report.

EDIT: Adding duplication instruction found in the .zip itself. Please keep to the structure provided in the form to spell it out as simply as possible how to duplicate. Thanks.
User avatar
Robert Gault
May 9, 2012, 02:08
edited on: May 9, 2012, 12:07
I have found the source of the problem but don't know how to fix it.

Starting at line 113, there is an attempt to read the type of RTC selected. The test is not working, presumably in line 119.
If I force the result to return RTC_DISTO with a new line, then the RTC works in emulation.
My guess, it is how ioport now works.


coco_rtc_type_t coco_fdc_device::real_time_clock()
	coco_rtc_type_t result = (coco_rtc_type_t) ioport("real_time_clock")->read_safe(RTC_NONE);

	/* check to make sure we don't have any invalid values */
	if (((result == RTC_DISTO) && (m_disto_msm6242 == NULL))
		|| ((result == RTC_CLOUD9) && (m_ds1315 == NULL)))
		result = RTC_NONE;
	result = RTC_DISTO;    /* new test line */
	return result;
User avatar
May 10, 2012, 12:15
usual ioport read from wrong device