What is different about "booting a disk" in AppleWIn (as an Apple IIe-enhanced) from an actual Apple IIe machine that would mean that a disk that does boot-up on an actual Apple IIe will instead crash when an image of it is booted in AppleWin? The disk (
and image thereof) contains a modified version of DOS 3.3 which, as I say, boots up fine on an actual Apple IIe.

Here is the last screen-height portion of what appears when the boot-up crashes:

00DD- FF ???
00DE- 00 BRK
00DF- 00 BRK
00E0- FF ???
00E1- FF ???
00E2- 00 BRK
00E3- 00 BRK
00E4- FF ???
00E5- FF ???
00E6- 00 BRK
00E7- 00 BRK
00E8- FF ???
00E9- FF ???
00EA- 00 BRK
00EB- 00 BRK
00EC- FF ???
00ED- FF ???
00EE- 00 BRK
00EF- 00 BRK
00F0- FF ???
00F1- 01 00 ORA ($00,X)
*
A343- A=00 X=57 Y=98 P=36 S=E4
*

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Also, I might ask, is there a substantive difference between a .DSK file and a .DO file? Someone converted some actual disks for me, and I was expecting .DSK files, but instead he gave me .DO files; but when simply changing the extension from .DO to .DSK
the "disk" could still be CATALOGged, LOADed from, SAVEd to, etc. by AppleWin either way. But these .DO files are the ones from disks which booted on my Apple IIe that won't boot in AppleWin.

On Tuesday, July 19, 2022 at 6:43:25 AM UTC-4, Alan Rat wrote:

What is different about "booting a disk" in AppleWIn (as an Apple IIe-enhanced) from an actual Apple IIe machine that would mean that a disk that does boot-up on an actual Apple IIe will instead crash when an image of it is booted in AppleWin? The disk

(and image thereof) contains a modified version of DOS 3.3 which, as I say, boots up fine on an actual Apple IIe.

Here is the last screen-height portion of what appears when the boot-up crashes:

00DD- FF ???
00DE- 00 BRK
00DF- 00 BRK
00E0- FF ???
00E1- FF ???
00E2- 00 BRK
00E3- 00 BRK
00E4- FF ???
00E5- FF ???
00E6- 00 BRK
00E7- 00 BRK
00E8- FF ???
00E9- FF ???
00EA- 00 BRK
00EB- 00 BRK
00EC- FF ???
00ED- FF ???
00EE- 00 BRK
00EF- 00 BRK
00F0- FF ???
00F1- 01 00 ORA ($00,X)
*
A343- A=00 X=57 Y=98 P=36 S=E4
*

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/19/22 6:43 AM, Alan Rat wrote:

What is different about "booting a disk" in AppleWIn (as an Apple IIe-enhanced) from an actual Apple IIe machine that would mean that a disk that does boot-up on an actual Apple IIe will instead crash when an image of it is booted in AppleWin?

It may have some sort of (perhaps unintended) dependency on memory
contents on startup. There's some different ways of initializing memory
on AppleWin to help address this sort of thing (the -memclear switch).

Do you have a disk image we could try?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, July 19, 2022 at 3:53:57 AM UTC-7, alanr...@yahoo.com wrote:

Also, I might ask, is there a substantive difference between a .DSK file and a .DO file? Someone converted some actual disks for me, and I was expecting .DSK files, but instead he gave me .DO files; but when simply changing the extension from .DO to .

DSK the "disk" could still be CATALOGged, LOADed from, SAVEd to, etc. by AppleWin either way. But these .DO files are the ones from disks which booted on my Apple IIe that won't boot in AppleWin.

Disk images can be in sector order ("DOS order" / .do) or block order ("ProDOS order" / .po). The .do/.po extension makes the ordering explicit. ".dsk" can be either, so the program using it has to make an educated guess.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/19/22 6:53 AM, Alan Rat wrote:

Also, I might ask, is there a substantive difference between a .DSK file and a .DO file? Someone converted some actual disks for me, and I was expecting .DSK files, but instead he gave me .DO files; but when simply changing the extension from .DO to .

DSK the "disk" could still be CATALOGged, LOADed from, SAVEd to, etc. by AppleWin either way. But these .DO files are the ones from disks which booted on my Apple IIe that won't boot in AppleWin.

Apple II disks have something called sector skew, or "order" - physical
sectors on a 5-1/4" disk don't follow in 1,2,3 order. And the specific
order that is used by DOS (i.e. 3.3) is different than that followed by
ProDOS. So if a person is extracting sectors from a disk and copying
them out to the outside world, they have the ability to record them in
an image file in either "order" - not necessarily following what the
operating system actually used, either.

Historically, a .DO suffix meant that a disk was recorded in DOS sector
order (regardless of what the original OS was/is). A .PO suffix meant
that a disk was recorded in ProDOS order (again, regardless of reality).
Most image transfer tools always use DOS order for 5-1/4" disks no
matter what. The suffix of .DSK is ambiguous, and offers no clues as to
which order the image is in.

Most tools can apply some fairly standard heuristics to figure out what
the actual order, and underlying OS, actually is. It is *possible* that
those heuristics are failing to correctly identify what your disk image
is trying to represent, so that's why it would be very interesting to
actually look at it. It's also possible that the disk image is
mislabeled and is actually in ProDOS order even though it says .DO,
which can confuse some tools (AppleWin included). So you might even try renaming your file with a .PO suffix to see if that changes anything.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <6abe0c83-0ec4-46b3-8c26-69485f0b68ddn@googlegroups.com>,
fadden <thefadden@gmail.com> wrote:

On Tuesday, July 19, 2022 at 3:53:57 AM UTC-7, alanr...@yahoo.com wrote:

Also, I might ask, is there a substantive difference between a .DSK

file and a .DO file? Someone converted some actual disks for me, and I
was expecting .DSK files, but instead he gave me .DO files; but when
simply changing the extension from .DO to .DSK the "disk" could still be >CATALOGged, LOADed from, SAVEd to, etc. by AppleWin either way. But
these .DO files are the ones from disks which booted on my Apple IIe
that won't boot in AppleWin.

Disk images can be in sector order ("DOS order" / .do) or block order >("ProDOS order" / .po). The .do/.po extension makes the ordering
explicit. ".dsk" can be either, so the program using it has to make an >educated guess.

Minor point. I believe .dsk should always be "DOS order"...but there are a
lot of images which violate that rule. I think the emulators and tools
which try to auto-detect are doing a disservice to the community in
general--we could clean up the .dsk mess if emulators required users to
rename the broken files.

KEGS does NOT support ProDOS ordered files in .dsk images. You must rename
the image. I'm trying to do my small part to clean up the mess.

Kent

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/19/22 6:43 AM, Alan Rat wrote:

Here is the last screen-height portion of what appears when the boot-up crashes:

00DD- FF ???
00DE- 00 BRK
00DF- 00 BRK
00E0- FF ???
00E1- FF ???
00E2- 00 BRK
00E3- 00 BRK
00E4- FF ???
00E5- FF ???
00E6- 00 BRK
00E7- 00 BRK
00E8- FF ???
00E9- FF ???
00EA- 00 BRK
00EB- 00 BRK
00EC- FF ???
00ED- FF ???
00EE- 00 BRK
00EF- 00 BRK
00F0- FF ???
00F1- 01 00 ORA ($00,X)
*
A343- A=00 X=57 Y=98 P=36 S=E4
*

I have my hands on the disk image now. It's a perfectly normal
DOS-order disk. And, it boots it's DOS fine - but it tries to run
something like the HELLO program, finds what seems to be some random
garbage, and spews the above.

What I did was boot the disk to the same monitor prompt in AppleWin
(doesn't matter if you give it a //e or II+), give it a 3D0G, and boom,
I'm in DOS. I was going to INIT another disk and give it a real HELLO
program, but this DOS that is purporting to save space saw fit to
eliminate the INIT function. Shrug.

I reconstituted the disk image to a real disk and booted it on a GS, and
got exactly the same results. So my guess is there's some sort of
problem with the boot program/specification. I brought it up under Copy
II+ to see what it thought the boot program was, and it just said there
wasn't one. So there's definitely something wrong with the way the boot program is specified (or laid out or executed or...?). Or something
went wrong in the ripping process, but since just about everything else
works, I'm not clear about how that might have happened unless there's
some out-of-band data like the volume number that matters.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/19/22 8:05 PM, David Schmidt wrote:

On 7/19/22 6:43 AM, Alan Rat wrote:

Here is the last screen-height portion of what appears when the
boot-up crashes:

00DD-   FF          ???
00DE-   00          BRK
00DF-   00          BRK
00E0-   FF          ???
00E1-   FF          ???
00E2-   00          BRK
00E3-   00          BRK
00E4-   FF          ???
00E5-   FF          ???
00E6-   00          BRK
00E7-   00          BRK
00E8-   FF          ???
00E9-   FF          ???
00EA-   00          BRK
00EB-   00          BRK
00EC-   FF          ???
00ED-   FF          ???
00EE-   00          BRK
00EF-   00          BRK
00F0-   FF          ???
00F1-   01 00       ORA   ($00,X)
*
A343-    A=00 X=57 Y=98 P=36 S=E4
*

I have my hands on the disk image now.  It's a perfectly normal
DOS-order disk.  And, it boots it's DOS fine - but it tries to run
something like the HELLO program, finds what seems to be some random
garbage, and spews the above.

What I did was boot the disk to the same monitor prompt in AppleWin
(doesn't matter if you give it a //e or II+), give it a 3D0G, and boom,
I'm in DOS.  I was going to INIT another disk and give it a real HELLO program, but this DOS that is purporting to save space saw fit to
eliminate the INIT function.  Shrug.

I reconstituted the disk image to a real disk and booted it on a GS, and
got exactly the same results.  So my guess is there's some sort of
problem with the boot program/specification.  I brought it up under Copy
II+ to see what it thought the boot program was, and it just said there wasn't one.  So there's definitely something wrong with the way the boot program is specified (or laid out or executed or...?).  Or something
went wrong in the ripping process, but since just about everything else works, I'm not clear about how that might have happened unless there's
some out-of-band data like the volume number that matters.

You can download the image here to have a play yourself (time limited): https://ftp.apple.asimov.net/unsorted/AlanRat1.DO

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Just did a quick -memclear 0 .. -memclear 7 tests and that didn't solve the crashing at $AA41: 00 BRK. (I've updated the GitHub issue.)

Next step will be to transfer this over to a real floppy and boot on real hardware.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, July 19, 2022 at 3:43:25 AM UTC-7, alanr wrote:

What is different about "booting a disk" in AppleWin (as an Apple IIe-enhanced) from an actual Apple IIe machine that would mean that a disk that does boot-up on an actual Apple IIe will instead crash when an image of it is booted in AppleWin? The disk

(and image thereof) contains a modified version of DOS 3.3 which, as I say, boots up fine on an actual Apple IIe.

We would need to see the actual disk image to track down what the exact cause is but as David suggests it could be the MIP (Memory Initialization Pattern) that is causing this. (We saw a few rare titles having problems when I implemented this years ago
back in 2014 with AppleWin issue #206.)

As David points out you can use the command line option: -memclear # to specify the exact memory initialization pattern:

0 = MIP_ZERO
1 = MIP_RANDOM
2 = MIP_FF_FF_00_00
3 = MIP_FF_00_FULL_PAGE
4 = MIP_00_FF_HALF_PAGE
5 = MIP_FF_00_HALF_PAGE
6 = MIP_PAGE_ADDRESS_LOW
7 = MIP_PAGE_ADDRESS_HIGH

Alan, I was able to snag the disk images from Asimov (Thanks David!) and have created AppleWin issue #1123 for you ...
* https://github.com/AppleWin/AppleWin/issues/1123

... but in the future for specific troubleshooting of AppleWin issues that involve disk images:

1. Please create a new AppleWin issue on GitHub via:
* https://github.com/AppleWin/AppleWin/issues/new/choose

2. Add the zipped disk image(s) to the issue. You will need to .zip existing .DSK/.DO images due to GitHub not accepting raw binary files.

Thanks
Michael

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks anyway, Michael, but as I stated in other messages I posted, I found out exactly what the problem actually was. All the disk images I received from the guy who made them for me contained an identical set of errors, one of which messed up the
booting process, so none of my disk-images would boot without crashing. The specific problem with trying to boot was that in what represents track 0 sector $F of every disk image file, bytes $3F to $4C were altered, and contained garbage. What these 14
bytes SHOULD have is: 8E 72 AA 8C 73 AA 20 6B A4 AE 72 AA AC 73. If these bytes are corrected, the disk image (or any actual disk reconstituted from it) boots fine, and the DOS works perfectly! The 14 BAD byte values, BTW, are: 44 CB 00 00 96 00 00 46 54
81 00 00 00 00. The identical set of 14 bad bytes are found at precise intervals on all of the disk images I received, when counting UP by tracks, and DOWN by sectors (down by sectors being how files are normally stored in DOS 3.3, BTW), and shifting up
14 bytes in the sector in successive instances. I have found the bad byte sequence at:
Track 0 sector $F at byte $3F
Track 8 sector 9 at byte $4D (already corrected in David's copy)
Track $10 sector 3 at byte $5B
Track $19 sector $D at byte $69 (wrapping to next track when sector # wraps around)
Track $21 sector 7 at byte $77


On Wednesday, July 20, 2022 at 9:51:11 AM UTC-4, Michael AppleWin Debugger Dev wrote:

Just did a quick -memclear 0 .. -memclear 7 tests and that didn't solve the crashing at $AA41: 00 BRK. (I've updated the GitHub issue.)

Next step will be to transfer this over to a real floppy and boot on real hardware.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks for the update. I've closed the AppleWin issue since you found the cause of bad random bytes on the copies. (I verified that the S0/TF/3F patch of 14 good bytes indeed fixes the disk enough to boot.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks back; I went back to my floppy and got the other patch corrections for the errors on the disk:
T10/S3/5B: 90 F6 A2 8A BD F2 B3 F0 0B E6 44 D0 02 E6 — this affects CATVACA that I discussed in another post
T19/SD/69: C9 71 D0 D0 03 60 CA 25 5C B3 7C 03 03 5F — tail end of TRI-STAR: only affects postgame continuation
T21/S7/77: C1 C7 CF D2 D9 01 20 06 0E 60 D3 C3 2D D0 — affects YAHTZEE: I didn't look into how, but it can't be good
I believe these are the only defects on the disk; given that the errors are at regular intervals, and a large file called SLOTS occupying most of what's between T10 and T19 seems to be intact. (BTW so no one is confused, you meant T0/SF/3F in your post.)

On Wednesday, July 20, 2022 at 11:43:00 AM UTC-4, Michael AppleWin Debugger Dev wrote:

Thanks for the update. I've closed the AppleWin issue since you found the cause of bad random bytes on the copies. (I verified that the T0/SF/3F patch of 14 good bytes indeed fixes the disk enough to boot.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, July 19, 2022 at 3:06:50 PM UTC-7, Kent Dickey wrote:

Minor point. I believe .dsk should always be "DOS order"...but there are a lot of images which violate that rule.

...unless it's an 800KB disk image, in which case it's in block order, because it doesn't make sense for an 800KB image to be anything else.

I'd prefer it if everyone stopped using ".dsk" to name raw data images. Of course, if we're going to get pedantic, the suffixes should be ".so" / ".bo".

(FWIW, ".dsk" is also used by DiskCopy 4.2, but those can be identified fairly reliably, and aren't as common in the Apple II world.)

I blame Larry Wall ("... strict in what they emit, and liberal in what they accept").

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

ERRATA:

1. Oops! I have a correction to my earlier correction. I forgot I had made changes to the TRI-STAR program since I sent it off to have the disk image made; the T19/SD/69 changes I listed before were wrong for the semt-off version. It should be:
T19/SD/69: 40 39 28 C2 29 24 B6 70 17 03 4D 36 B1 23
And the upshot of this is that in the program, line 5030 should look like:

5030 IF A$="Q" THEN 9999: IF A$="B" THEN 6000: CALL -1059: GOTO 5020

2. For "ERRATA" above, read "ERRATUM".

On Wednesday, July 20, 2022 at 1:06:44 PM UTC-4, Alan Rat wrote:

Thanks back; I went back to my floppy and got the other patch corrections for the errors on the disk:
T10/S3/5B: 90 F6 A2 8A BD F2 B3 F0 0B E6 44 D0 02 E6 — this affects CATVACA that I discussed in another post
T19/SD/69: XXXX — tail end of TRI-STAR: only affects postgame continuation T21/S7/77: C1 C7 CF D2 D9 01 20 06 0E 60 D3 C3 2D D0 — affects YAHTZEE: I didn't look into how, but it can't be good
I believe these are the only defects on the disk; given that the errors are at regular intervals, and a large file called SLOTS occupying most of what's between T10 and T19 seems to be intact. (BTW so no one is confused, you meant T0/SF/3F in your post.

)

On Wednesday, July 20, 2022 at 11:43:00 AM UTC-4, Michael AppleWin Debugger Dev wrote:

Thanks for the update. I've closed the AppleWin issue since you found the cause of bad random bytes on the copies. (I verified that the T0/SF/3F patch of 14 good bytes indeed fixes the disk enough to boot.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 20 Jul 2022, fadden wrote:

On Tuesday, July 19, 2022 at 3:06:50 PM UTC-7, Kent Dickey wrote:

Minor point. I believe .dsk should always be "DOS order"...but there are a >> lot of images which violate that rule.

...unless it's an 800KB disk image, in which case it's in block order, because it doesn't make sense for an 800KB image to be anything else.

I'd prefer it if everyone stopped using ".dsk" to name raw data images.
Of course, if we're going to get pedantic, the suffixes should be ".so"
/ ".bo".

(FWIW, ".dsk" is also used by DiskCopy 4.2, but those can be identified fairly reliably, and aren't as common in the Apple II world.)

I blame Larry Wall ("... strict in what they emit, and liberal in what
they accept").

What ApplePC did - and I imitated in my first emulator - was default to DO
if the filesize was 143360, and allow you to switch to interpreting the
disk as PO.

-uso.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)