Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
06639 Crash/Freeze Critical (emulation) Always Aug 1, 2017, 04:59 Aug 4, 2017, 06:39
Tester drencorxeen View Status Public Platform MAME (Official Binary)
Assigned To Duke Resolution Fixed OS Windows 10 (64-bit)
Status [?] Resolved Driver
Version 0.188 Fixed in Version 0.189 Build 64-bit
Fixed in Git Commit Github Pull Request #
Summary MESS-specific 06639: coco3, coco3h: crash of emulated system accessing multiple floppy drives
Description mounting OS-9 L2 or NitrOS-9 L2 in drive 0 and mounting another disk in drive 1 and doing drive access on both drives crashes emulated system.
Steps To Reproduce Mount OS-9 L2 or NitrOS-9 L2 boot disk in drive 0
Mount another disk image in drive 1 with OS-9 files on it.
type DOS at disk basic prompt to boot into OS-9 L2 or NitrOS-9 L2
Once at OS-9 L2 command prompt I type:
shell i=/w7&<ENTER>
load dir<ENTER>
>-Press CLEAR key (HOME)-<
On new window type:
chd /d1 ; chx /d1/cmds<ENTER>
dir x e; dir x e; dir x e; dir x e; dir x e; dir x e; dir x e; dir x e; dir x e; dir x e
<HOME>
Now we are back on term window we type:
dir x e; dir x e; dir x e; dir x e; dir x e; dir x e; dir x e; dir x e; dir x e; dir x e
<HOME>
Now that we are back on Windows W7 we press <ENTER> then we press <HOME>
Now we should be back on the TERM window and we press <ENTER>
If all goes correctly the dir command should be doing directories of both /d1/cmds and /dd/cmds which should freeze or cause interesting patterns on the emulated system.
Additional Information Video I made showing the steps I took as well.
Github Commit
Flags
Regression Version
Affected Sets / Systems coco3, coco3h
Attached Files
 
Relationships
related to 06640ResolvedDuke  coco3, coco3h: TRS-80 Color Computer FDC data corruption issue 
Notes
4
User avatar
No.14044
drencorxeen
Tester
Aug 1, 2017, 16:11
After more testing I found this might have to do with the FDC emulation.
I did some tests in Disk Basic and found that FDC is not switching to the correct Disk Image/Drive# correctly.

Steps I was able to do this and reproduce the problem:
start MAME and launch CoCo 3 or CoCo3h
create new disk image in drive 0
create new disk image in drive 1
DSKINI0
DSKINI1
DIR 1
type in basic program:
10 PRINT "DIR 0"
20 DIR 0
30 PRINT "END DIR 0":PRINT "DIR 1"
40 DIR 1
50 PRINT "END DIR 1"
60 GOTO 10
DIR 0
SAVE "TEST1.BAS"
DIR 0:DIR 1

Now you should see the contends of the directory on drive 0 showing up on drive 1 as well.
If you do a
DIR 0
wait a few seconds for drive motor to shut off and then do
DIR 1
The expected empty directory shows up. Now if you do a
DIR 1:DIR 0
You will get a blank directory for both drive 1 and drive 0.
So for some reason the FDC subsystem seems to not be switching between the drives correctly.

As a side note I have tested this in the Official MAME 0.188 32bit & 64bit binaries and it does the same thing.
User avatar
No.14045
star2root
Viewer
Aug 1, 2017, 16:18
Also effects the CoCo 2b. I have not confirmed it yet but I strongly suspect all CoCo 1, 2, and 3 systems with a floppy controller are effected.

If you want to try it out the simplest way to show this off is to do this:
Startup CoCo 2 or CoCo3 emulation
Create a new disk image and mount it in drive 0
Create a new disk image and mount it in drive 1
I used blank JVC disk images created by MAME. Then...

DSKINI 0
DSKINI 1

Enter a quick basic program like this and save it to disk:

10 PRINT "DIR 0"
20 DIR 0
30 PRINT "DIR 1"
40 DIR 1
50 GOTO 10
SAVE"TEST1.BAS"

Content of the program is not important, although this program will further illustrate the problem
 
Then all you have to do to see the problem is to:
DIR 0:DIR 1

It can also be produced by typing
DIR 0
DIR 1
on separate lines, if it is typed in fast enough.
User avatar
No.14050
drencorxeen
Tester
Aug 1, 2017, 21:35
More information I have done to test.

I went back to version 0.162 testing the FDC problems.

I found my FDC problems seem to have started with version 0.163 of MAME.
User avatar
No.14066
drencorxeen
Tester
Aug 4, 2017, 06:39
Ok so the commit that was made for a fix for the coco_fdc.cpp did seem to correct this issue at this time. I have been running the emulated system for hours now without any crashes.