08258: Error booting OS-9 on coco2b

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
08258	Crash/Freeze	Major	Always	Mar 18, 2022, 21:24	Nov 13, 2022, 11:43

Tester	Bletch	View Status	Public	Platform	MAME (Self-compiled)
Assigned To	tlindner	Resolution	Fixed	OS	Windows 10/11 (64-bit)
Status [?]	Resolved			Driver	trs/coco12.cpp
Version	0.241	Fixed in Version	0.250	Build	64-bit
		Fixed in Git Commit	0ec162c	Github Pull Request #	#10538

Summary	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	capture28.png (2,946 bytes) Jun 28, 2022, 01:53 Uploaded by tlindner Real hardware running my test.
Attached Files	TIMEWP.zip (5,930 bytes) Jun 28, 2022, 01:54 Uploaded by tlindner Color Computer Timing Program

No.19934 Robbbert Senior Tester Mar 20, 2022, 16:14	link was 404, fixed
No.19935 Robbbert Senior Tester 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.
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?
No.19946 Robbbert Senior Tester 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..
No.19961 tlindner Moderator 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.
No.19962 Robbbert Senior Tester Mar 29, 2022, 00:13	Sounds like it could be a bug in the coco2b emulation then?
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.
No.20054 tlindner Moderator 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
No.20080 tlindner Moderator 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.
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
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?
No.20346 tlindner Moderator Jun 28, 2022, 01:53	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.
No.20809 Bletch Developer Nov 12, 2022, 21:19	Happy to see this fixed!