Previous Thread
Next Thread
Print Thread
Page 1 of 2 1 2
Joined: Sep 2014
Posts: 13
L
lowen Offline OP
Member
OP Offline
Member
L
Joined: Sep 2014
Posts: 13
Hello.

Sometime in 2012 there was a report on Erik Klein's vintagecomputer forums that TRSDOS, CP/M, and LS-DOS 6.3.1A were bootable and working on MESS's trs80m2 emulation. No version information was given in the post, unfortunately.

As of 0.154 TRSDOS and CP/M will boot, but images in .imd format of LS-DOS 6.3.1A and DOSPLUS II do not successfully boot, issuing a Disk Error message in the case of LS-DOS and an equivalent message for DOSPLUS II. Multiple .imd's of both were attempted.

So I'm attempting to bisect where the regression occurred, but am having some difficulty locating the MESS from 2012, as it was distributed as a patch at that point, correct? Once I find a version where LS-DOS successfully boots, I'll be able to bisect more effectively and pull the various revisions out of SVN and see where it broke.

So, does anyone know where I can find MESS source from 2012 and 2011?

Or maybe someone even has an idea of why LS-DOS doesn't fully boot (the Disk Error message is from the boot sector, not the boot ROM, so I know at least the first sector of the disk is being properly read); anyone? The same build does successfully boot a TRSDOS 2.0 image from Bill Degnan's vintagecomputer.net

Last edited by lowen; 09/16/14 10:59 PM.
Joined: May 2012
Posts: 429
Likes: 1
R
Senior Member
Offline
Senior Member
R
Joined: May 2012
Posts: 429
Likes: 1

Joined: Mar 2001
Posts: 16,943
Likes: 69
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,943
Likes: 69
The operative question is if trs80m2 is using the legacy or modern floppy subsystems. Because if it's been upgraded, I can predict right now the bisect will finger the upgrade, and thus be kind of meaningless smile

Joined: Sep 2014
Posts: 13
L
lowen Offline OP
Member
OP Offline
Member
L
Joined: Sep 2014
Posts: 13
Originally Posted By remax


Ah, that's the piece I was missing.....

Originally Posted By R. Belmont
The operative question is if trs80m2 is using the legacy or modern floppy subsystems. ...


It would appear that it currently is using the modern subsystem. There are several commits mentioning things related to the floppy subsystem that would likely mean this in the current history.

So, what sort of information could be useful for fixing this regression?

Joined: Sep 2014
Posts: 13
L
lowen Offline OP
Member
OP Offline
Member
L
Joined: Sep 2014
Posts: 13
Update:

Ok, thanks to the link posted by remax I was able to duplicate the report on Eric Klein's vcf Tandy forum that the trs80m2 driver in MESS (0.145 was current at the time the post was made) would at that point boot LS-DOS 6.3.1A, with several images that I have booting properly.

And thanks to the stickied post about bug reporting, I'm reading the docs and such at mametesters, and will put up a bug report later this week, hopefully.

Last edited by lowen; 09/17/14 05:02 PM. Reason: Added mametesters info.
Joined: Sep 2014
Posts: 13
L
lowen Offline OP
Member
OP Offline
Member
L
Joined: Sep 2014
Posts: 13
Ok, found the version that first breaks.

0.147 works fine with an IMD of LS-DOS 6.3.1A, but 0.148 does not, giving the following error message:
Quote:
Device 8" double density double sided floppy drive load failed: Unable to identify the image format


This error does not occur with 0.154; rather, it boots the boot sector, which then issues the Disk Error message. Now will try SVN trunk......

Joined: Mar 2001
Posts: 16,943
Likes: 69
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,943
Likes: 69
0.148 had a rewrite of the IMD format which strictly enforced the specs; unfortunately nobody creating such images bothered to do the same.

You'll find that the boot sector is failing after issuing a command sequence to the FDC; knowing what the sequence is would be the necessary next step.

Joined: Sep 2014
Posts: 13
L
lowen Offline OP
Member
OP Offline
Member
L
Joined: Sep 2014
Posts: 13
Ok, thanks for the pointer.

I'll dig into the boot track (the Model II ROM actually loads the whole track 0 into RAM on boot, not just the first sector) and see what's triggering this. I have a gut feel about it, but I need to confirm. LS-DOS really pushes the 1791 and its format to the limits, so it could be a poorly documented or undocumented hardware behavior that I'm seeing that would be caught by stricter adherence to specs. These images do, after all, boot and run under the older version, with one exception, and that exception is double-sided.

The images I'm using were produced by Dunfield's ImageDisk 1.18. One was a read of a physical disk that boots properly on hardware, and the other two were conversions of DMK images (using DMK2IMD in Dunfield's package) of physical media that long ago booted on hardware.

Joined: Jun 2009
Posts: 20
Member
Offline
Member
Joined: Jun 2009
Posts: 20
I had tried to convert the DMK's to IMD a couple years back (March of 2012) for use in MESS and ran into some issues. Did some investigation with Dave D. himself and this is what he came up with (figured it might be good info to archive here):

"I've looked into it, and I conclude that the .DMK images you are using are defective!

The IBM System-34 MFM format specification requires that there be three 0x1A bytes immediately preceeding the Address Marks (both the ID address mark and the Data address mark) - these are used by some controllers to help identify the address mark - more importantly, the CRC *INCLUDES* these three bytes from the disk as well as the address mark itself - note that a "real" FDC gets these values FROM THE DISK - not by "fakng" them the way LIBDMK does. If you were to create real disks directly from these .DMK images, I'm pretty certain most controllers would give CRC errors.

The .DMK images that you gave me have only two 0x1A bytes preceeding the address marks (in violation of the System-34 spec. - which is the standard for Double-Density encoding).

DMK2IMD interpretes the .DMK exactly the same way as a real FDC would - it reads these bytes from the data stream (I simulate the holding in a shift register by resetting the input point back 3 (ID) or 4 (DATA) bytes.

I have updated DMK2IMD to detect this condition and warn you about it - I have also added a '/A' option to work-around the bad address marks by "faking" the prefix bytes With this option it seems to read your images OK.

I've just posted am updated ImageDisk (1.18) to my site, containing this and a few other small things I've tweaked since the last release."

Hope this is helpful.

Joined: Sep 2014
Posts: 13
L
lowen Offline OP
Member
OP Offline
Member
L
Joined: Sep 2014
Posts: 13
Ah, that would explain why Tim updated his images to "work better with DMK2IMD" later in 2012......

One of the images I tried was made by B Degnan using ImageDisk 1.18 from physical media, and it won't boot either (post 0.148, that is). Both images boot pre-0147.

But that's certainly something to look at.

Page 1 of 2 1 2

Link Copied to Clipboard
Who's Online Now
2 members (Dorando, 1 invisible), 29 guests, and 2 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,132
Posts119,654
Members5,029
Most Online890
Jan 17th, 2020
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com