Well, I have a whole new light to shed on the problems with booting my disk images.
I actually have three disk images with the same modified DOS, none of which will boot in AppleWin. Since I know they normally would boot on an actual machine, this pointed to some difference in the way ApplWin boots a disk. But now I've made a crucial discovery.
In what seemed to be a separate issue, shortly after I received the disk images from he who made them for me, I found a defect in a program on the first disk that was not in my original floppy disk. I traced the error to track 8, sector 9, bytes $4D to $5A in that sector: the bytes in this range were altered. I restored the correct values for those bytes before passing the disk image to David.
Now, however, I've discovered that on the second AND third disk images I received, track 8 sector 9 bytes $4D to $5A were ALSO altered, apparently with the same bad values! So EVERY disk image I got has IDENTICAL defects! Suppose, then, if track 8 sector 9 is not the only place where these images were corrupted — suppose part of the stored DOS also got messed up! Now, David said the booting DOS, "tries to run something like the HELLO program," but "finds what seems to be SOME RANDOM GARBAGE" (my emphasis). So just where is this "random garbage"? Well, since the crashed address showed $A343, it's no surprise that address range $A33F to $A34C, part of the code for BLOAD (also used by BRUN), is indeed garbage — in fact, it's the identical sequence of 14 garbage bytes I had found on track 8 sector 9! So the booting DOS was unable to BLOAD or BRUN what it was supposed to, crashing instead. In the disk image files the messed up BLOAD routine is in track 0 sector $F, at bytes $3F to $4C therein. I looked back at my floppy disk to see what SHOULD be there, made the corrections in the disk image file, and now it boots perfectly! After correcting this in all three files the next step will be to see where else the image files have the 14 garbage bytes.
For the record, the 14 bad bytes are: 44 CB 00 00 96 00 00 46 54 81 00 00 00 00
P.S. Further to my previous side note, as I do in fact own one of the Googlegroups I belong to, I checked to see what indeed the owner may set about posting and attachments — possible new features since I set up the group I own, which was years ago. It turns out there's a checkbox for allowing posting by email, which THIS group apparently has turned off. There is also a setting for WHO may post attachments: owner, moderators, members, or anyone at all. Apparently members are not included at this group. There does not, however, seem to be control over WHAT may be attached, that I can tell.
On Tuesday, July 19, 2022 at 11:10:59 PM UTC-4, Alan Rat wrote:
> Limitations again force me to "start a New conversation" to make a reply:
> The DOS that was on the disk the image was created from used to boot up on a IIGS just fine, as with a IIe. The reason that Copy II+ can't identify the HELLO program is that it assumes that information must be in track 1 sector 9; but thanks to my space-saving scheme that stores DOS in just tracks 0 and 1, it's in track 1 sector 6 instead (so as far as Copy II+ is concerned, what it sees in sector 9 is "gibberish"). Another feature of the DOS that may not have been expected is that the HELLO program can be of any file type, including an EXEC'd text file, without DOS requiring any modification for the file type. And on this disk it IS an EXEC'd text file, the one whose name begins "UTE=...". What UTE= does is load or run several files as given in the remainder of UTE='s filename, as this DOS has a "wildcard" character, the ] being it, that acts like a "trailing *". Thus just a small portion of each file's name to be loaded or run is sufficient, and several can fit in the remainder of UTE='s name (at each point where there is a ], it knows that what comes after that is another file's name; if the next character is "–" it will (B)LOAD the file, if not, it will (B)RUN it) — and to change what gets loaded/run, all you have to do is RENAME UTE= accordingly.
> Here, UTE= is told to BRUN CAT ProDOS/SHOW HELLO:40000, which extends a feature of this DOS that whenever it does a CATALOG, it checks that track $11 sector 0 conforms to a VTOC before continuing; if not, it checks to see if it's a ProDOS disk; if so, it reports the disk's free space as ProDOS records that info, and checks to see if there's an extension to CATALOG the ProDOS disk, which is what this file does (if there isn't one, CATALOG just terminates after reporting the free space). This file also includes a feature whereby issuing CALL 40000 will display the name of the disk's HELLO program. Since this information, normally in track 1 sector 9, is simply the name of the file included with an INIT command that stored DOS on disk, in the "first filename buffer", this routine looks for the name "APPLESOFT" that can be found in the same disk sector. It starts looking for this where *this* DOS has that pattern, in track 1 sector 6, and increments the sector in track 1 until it finds it (normally in sector 9), then displays the HELLO program name in the same sector., as well as listing any command-parameter values associated with the running of said program (also in that sector). The CAT Pro... file is BRUN so it gets set up as the extension that CATALOG will be looking for.
> Next, UTE= will install (by a BRUN) Integer BASIC in the language card, if possible.