- --
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 | |||
| Version | 0.145u8 | Fixed in Version | 0.146 | Build | Normal |
| Fixed in Git Commit | Github Pull Request # | ||||
| Summary |
|
||||
| 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 | |||||
| Github Commit | |||||
| Flags | |||||
| Regression Version | 0.145u8 | ||||
| Affected Sets / Systems | coco3, coco3h | ||||
|
Attached Files
|
|||||
Relationships
| There are no relationship linked to this issue. |
Notes
3
|
No.08518
Tafoid Administrator
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. |
|---|---|
|
No.08528
Robert Gault Tester
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. mess\machine\coco_fdc.c 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. /*-------------------------------------------------
real_time_clock
-------------------------------------------------*/
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;
} |
|
No.08537
micko Developer
May 10, 2012, 12:15
|
usual ioport read from wrong device |