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.
Next, UTE= will BLOAD DISK USE CALL 32115, which is a routine to display a diagram of detailed file-by-file info of how the disk's sectors are used, like that created by the Copy II+ utilities. As the filename states, it's done with a CALL 32115.
The last thing UTE= does is BLOAD CATVACA CALL 31700, a routine that is a variant of CATALOG which, instead of skipping deleted files, will highlight them in inverse mode so you can see where a new filename will be added to the catalog listing (i.e.
wherever the first vacancy is).
But the HELLO program process is actually not done yet, because with this DOS you can optionally name a SECOND HELLO program, its name stored in the "second filename buffer" immediately after the first buffer (normally used only by the RENAME command)
a file to execute after the first one is done (and which will be displayed by CALL 40000 if such a second HELLO is designated, BTW). On this disk, the second HELLO is DISASS 66 80-COL (BRUN TO ^Y), which is installed as the user-defined Monitor command,
and will, on the 80-column screen, disassemble 66 machine language instructions in three columns. It also contains a routine to search an Applesoft program for specifoed code at CALL 39000, and a routine to display a SIMPLE disk-use diagram (not file-by-
file) based on VTOC disk-use information, at CALL 39500.
This DOS, BTW, was originally an offshoot of what somebody called "PIG-DOS", which did indeed sacrifice disk-formatting (and the INIT command) so they could include code for fast loading of Applesoft and binary files. The lack of INIT did not concern
me, as long as there'd be normal DOS disks around, or other software (such as Copy II+) that could format disks. And actual "formatting" is especially not of concern with emulators, where you can "format a new disk" by simply copying a .DO or .DSK file.
So I would scarcely "shrug" it off. It happens that I eventually re-wrote their fast-load code, as it had been rather buggy, and I made it more compact to boot, allowing me space to implement other features I've discussed. PIG-DOS originally replaced the
INIT command with one they called HIDE, which would take a filename you'd give it and make a setting in the file's catalog entry so that the PIG-DOS CATALOG command would not display it; in other words, HIDE the file. Issuing HIDE on the file again would
un-hide it. This was not very useful, however; if a normal DOS were booted, the "hidden" file would show up; it was only "hidden" to PIG-DOS. I eliminated this feature, and replaced HIDE with BOOT, a command, with a filename, that would just write DOS to
disk (on tracks 0 and 1 only). The one, or two, filenames would thus become the disk's HELLO program(s), just like when INIT wrote DOS to disk. This made it easy to replicate my DOS on any number of disks.
In the end, if there's any difficulty booting a real disk reconstituted from the .DO file, there must be some alteration from the disk I originally had, because that disk booted fine on IIe, IIGS, or whatever. In fact, yet another feature of my DOS is
IIGS-specific: CALL 43000 will set a IIGS to fast mode, while CALL 43003 will set it to normal speed (this routine contains instructions only a IIGS can interpret).
P.S. On a side note, when I found that the "New conversation" feature on this group's page won't let me attach files, I checked the handful of other Googlegroups I belong to. All the others would allow me to attach ONE image file, and one group would
allow a "general" attached file, or, separately, an image file. I guess there's a group setting made by the owner to control this feature, but that's only a guess.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)