Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
08258 Crash/Freeze Major Always Mar 18, 2022, 21:24 7 days ago
Tester Bletch View Status Public Platform MAME (Self-compiled)
Assigned To Resolution Open OS Windows 10/11 (64-bit)
Status [?] Confirmed Driver coco12.cpp
Version 0.241 Fixed in Version Build 64-bit
Fixed in Git Commit Github Pull Request #
Summary MESS-specific 08258: Error booting OS-9 on coco2b
Description There seems to be a problem running OS-9 when the disk image in a ZIP file. See steps to reproduce.
Steps To Reproduce 1. Download https://colorcomputerarchive.com/repo/Disks/Operating%20Systems/OS-9%20Level%201%20v02.01.00%20(Tandy)%20(OS-9)%20(6847T1).zip
2. Put OS9-L1V201M.DSK into its own ZIP file (OS9-L1V201M.ZIP)
3. mame coco2b -flop1 OS9-L1V201M.ZIP
4. Type in "DOS" in the emulation to start OS-9

RESULT: The OS-9 boot process gets into an infinite loop. OS-9 starts to load up, but then it flips back to "OS9 BOOT"

This does not happen if you run OS9-L1V201M.DSK outside of the ZIP file, suggesting that having the image write protected is a problem.
Additional Information
Github Commit
Flags
Regression Version
Affected Sets / Systems
Attached Files
png file icon capture28.png (2,946 bytes) 7 days ago Uploaded by tlindner
Real hardware running my test.
tlindner
zip file icon TIMEWP.zip (5,930 bytes) 7 days ago Uploaded by tlindner
Color Computer Timing Program
Relationships
There are no relationship linked to this issue.
Notes
12
User avatar
No.19934
Robbbert
Developer
Mar 20, 2022, 16:14
link was 404, fixed
User avatar
No.19935
Robbbert
Developer
Mar 20, 2022, 16:24
Instead of putting the disk into a zip, I made it read-only, and then the problem occurred.

MAME never writes zip files, they are considered read-only. I believe the situation is normal.
User avatar
No.19944
Tafoid
Administrator
Mar 25, 2022, 21:10
I think so as well. .ZIP images are meant to be read-only by default because adjusting a softlist item would cause it no longer to be detected as valid. There is no mechanism that I know of that deals with floppy disk .dif files like we have for CHDs that require rewriting/updating. Should there be?
User avatar
No.19946
Robbbert
Developer
Mar 26, 2022, 18:31
edited on: Mar 26, 2022, 18:32
That would be a feature request., and even then the disk would have to be outside of its zip, because MAME has no capability of writing zips. As things stand, I consider this to be an invalid report..
User avatar
No.19961
tlindner
Tester
Mar 28, 2022, 16:29
I just tested with this a real CoCo 2B and a real floppy drive and booting the (write protected) OS worked perfectly.
After booting I verified that I could not write a file to the disk. Just to make doubly sure the write protect notch cover was doing it's job.
User avatar
No.19962
Robbbert
Developer
Mar 29, 2022, 00:13
Sounds like it could be a bug in the coco2b emulation then?
User avatar
No.19969
Tafoid
Administrator
Mar 30, 2022, 00:32
Only confirming the behavior in MAME - in a .zip (resets and loops booting) and loose it boots OS-9 seemingly correctly.
Assuming that original hardware will boot correctly if write protect tab is covered as stated, this is the bug to note.
User avatar
No.20054
tlindner
Tester
Apr 14, 2022, 15:36
I've long known OS-9 writes to a disk sector during boot. The sector in this case is the root directory file descriptor.

I traced the CPU execution and found the FDC will pull INTRQ about seven instructions after the write command is issued when the write protect is enabled. This causes an NMI on the 6809 and the service routine will adjust the stack to point to the base of the saved registers (instead of the tip). Then pull CC and Y from the stack, which is weird because the stack would currently contain a return address from a branch to subroutine instruction. So now the stack is hosed.
Then it continues testing the FDC status register looking for a problem, when it checks write protect, it sets an error code and does an RTS. This causes it to jump into the weeds because the stack is all messed up.

That is as far as I got. I will continue my investigation.

CCA1: STB $FF48
[:ext:fdcv11:wd17xx] Initiating command a0
CCA4: LDY #$FFFF
CCA8: LDB #$28
CCAA: ORB $00A9,U
CCAE: STB $FF40
CCB1: LDB #$A8
[:ext:fdcv11:wd17xx] cmd: write sector (c=a0) t=0, s=3
CCB3: ORB $00A9,U
CCB7: LBSR $CE4D
[INTRQ -> NMI]
0109: JMP $CD0F
CD0F: LEAS $C,S
CD11: PULS CC,Y
CD13: LDB $FF48
[:ext:fdcv11] m_wd17xx->status_r: 40
CD16: BITB #$04
CD18: LBNE $CE28
CD1C: LBRA $CDFA
CDFA: BITB #$F8
CDFC: BEQ $CE12
CDFE: BITB #$80
CE00: BNE $CE14
CE02: BITB #$40
CE04: BNE $CE18
CE18: COMB
CE19: LDB #$F2
CE1B: RTS
EE88: NEG $00
User avatar
No.20080
tlindner
Tester
Apr 17, 2022, 19:24
I have a proposed patch. I added a 30ms delay between the write command and the INTRQ.
https://github.com/tlindner/mame/tree/fdc-writeprotect-delay
I have further testing to do, but so I would also like any feedback.
User avatar
No.20262
Bletch
Developer
May 30, 2022, 12:46
Just saw this :-(

This seems reasonable to me, but I definitely would like to get Sarayan's take on this
User avatar
No.20263
galibert
Developer
May 30, 2022, 14:37
That delay seems both arbitrary and high. Any reason for that value? The chip doesn't have a ~3K cycles counter afaict. Anything that would point to some kind of documented value there? What's roughly the minimal time under which things break?
User avatar
No.20346
tlindner
Tester
7 days ago
I would like to have an oscilloscope to measure this, but I don't have one.
Instead a wrote a CoCo program to increment an accumulator after I issue a write sector command on a write protected disk.
This loop is 5 cycles. The CoCo runs at 894.9 Khz. I ran this program on a real CoCo 3 with an FD-501 disk controller that uses a WD1773 (8507). It reported a count of 20. My calculations are here: https://docs.google.com/spreadsheets/d/1yBH18TyhmZBf5OChWvDDq10XLS0sWLBYxzH_vOoiNuo/edit#gid=0
I conclude the INTRQ delay in this system is 111.7 microseconds when trying to write to a write protected disk.
I will try to ask friends to get more data.