coco*: Unable to boot Nitros9 disk images from official distribution site

[n6il]

Unable to boot Nitros9 on MESS. All coco variants are affected. According to Tim Lindner some code is missing to correctly detect the disk images:

https://pairlist5.pair.net/pipermail/coco/2017-June/161466.html

The way this used to work before the feature was removed was if you named a OS-9/Nitros9 disk image as .os9 instead of .dsk then it would correctly detect the geometry of the image and it would boot correctly. Tim suggests that we all switch over to use JVC format instead of the normal DSK/OS9 formats, but there are hundreds if not thousands of disk images that would require conversion.

Steps to reproduce (using coco3 as an example but all the other cocos are similarly broken):

1. Download the latest Nitros9 from https://sourceforge.net/projects/nitros9/files/releases/v3.3.0/nos96809l2v030300coco3.zip/download
2. Using the nos96809l2v030300coco3_40d_1.os9 as an example, trying to boot this disk results in Nitros9 not booting. Instead it does a warm reset (clear screen with OK prompt)
3. Attempting to use the 80 track disk nos96809l2v030300coco3_80d.0s9 results in MESS crashing with a segfault. I've built at at 3643d83 on a Mac.

$ ./mess64 -window coco3 -flop1 /tmp/nos96809l2v030300coco3_80d.os9 
Value 1 not supported for option sound - falling back to auto
Segmentation fault: 11

[drencorxeen]

You must add at least the 2 byte JVC header to the OS-9 double sided disk images. The feature to use the OS-9 LSN0 to setup drive geometry was removed.

This is a pain, but can be worked around by using a HEX editor to add at the front of the disk image a $1202 for 18 sectors per track & 2 heads. If your disk image goes over the 18 sectors per track it will also not work correctly.

As far as real floppies go the most sectors that I have been a real floppy handle is 20 sectors at 256 bytes per track..

[n6il]

Another problem with being forced to use JVC is that many of the other emulators and tools that Coco users use don't support JVC.

So far only MAME/MESS and XRoar Emulators support JVC. The the other main emulator that Coco users use is VCC and this does not support JVC Format.

DriveWire and Toolshed are tools that are commonly used by Coco users and neither of these support JVC format.

So, I think if this issue winds up not being fixed and the developers continue to insist that we all switch to JVC format then there will be a lot fewer Coco users that will be able to use MESS/MAME for Coco emulation. I think most people will see the instructions and give up. For me personally, because most of the other tools that I use don't support JVC format it doesn't make sense for me to convert all my disk images to JVC Format. This issue would force me to stop using MESS for Coco Emulation.

[drencorxeen]

@n6il ,

Actually VCC supports the JVC header better than any other emulator besides the original emulator that had JVC support. Jeff Vavasours Color Computer emulator is the one that first introduced the JVC header.

Then VCC supported it as well.

Also the CoCoSDC minimally supports the JVC header to determine head count.

[rb6502]

MAME has DriveWire support as well, although I'm not familiar with the details.

[milliluk]

Please see https://github.com/mamedev/mame/issues/1386

This isn't just a CoCo thing. It affects Atari, NES, Apple2, PC and others.

[startaq]

nos96809l2v030300coco3_80d.dsk now boots without modifications on the coco3 driver.

[ghost]

does MAME actually provide a way to specify these things on the commandline?

all these 'guess based on image size' things in loaders make me uneasy, and while I understand they're necessary there are bound to be cases where the wrong guesses are made.

what seems to be a similar problem is happening with the CPC images http://forums.bannister.org//ubbthreads.php?ubb=showflat&Number=105111&page=4 where the code thinks that anything above a certain size can't be valid, where in reality size can be affected by many things.

i've said for cartridges we probably need some kind of 'template cartridge' system (which could then be referenced by elements in the software lists and also used to force a cartridge type for homebrew development) but I'm starting to wonder if the floppy system either needs commandline overwrites or a similar 'template' system so you can force a certain disk layout (DD/HD/QD etc.) when there's no header.