- --
Viewing Issue Advanced Details
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 | |||
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.
| ||||
TIMEWP.zip (5,930 bytes) Jun 28, 2022, 01:54 Uploaded by tlindner Color Computer Timing Program | |||||
Relationships
There are no relationship linked to this issue. |
Notes
13
No.19934
Robbbert Moderator
Mar 20, 2022, 16:14
|
link was 404, fixed |
---|---|
No.19935
Robbbert Moderator
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 Moderator
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 Moderator
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! |