"Universal Boot Initializer" ?

[Steve Nickolas]

I've seen this title applied to something like what I've seen on a few
disks. They'll be 13-sector, and have a bootstrap that boots on either a
13 or 16-sector drive.

Anyone know how this could be pulled off, how one could create their own
"universal" disk?

-uso.

[ict@ccess]

On Jan 13, 10:07 pm, Steve Nickolas

Probably both DOS's are on the same disk and you get a choice which
one you want to boot in to. Same idea as a dual boot DOS 3.3 / PRODOS
disk.

Rob

[Vladimir Ivanov]

One sector #0 in 13-sector format and one sector #0 in 16-sector format,
both on track #0?

[ict@ccess]

Ha! Just realized DOS has even booted yet. That would take a few
coffees and late nights following that code. Tis will be known as the
ultimate crack.

Rob

[Steve Nickolas]

Hm. I don't think so. I've used actual software like this and it's
straight 3.2 (or even 3.1, as in Castle Wolfenstein), apart from having 2
boot sectors.

-uso.

[Steve Nickolas]

Right. I'm just wondering how one would arrange that feat.

-uso.

[Vladimir Ivanov]

Easiest would be creating the track image in memory and writing the whole
track at once with simple routine.

At least the 16-sector boot ROM can load more than one sector, so you
would put few more 16-sector format sectors that hold code/tables that
support 13-sector mode. The rest of the track/disk you make in 13-sector
format.

If the 13-sector boot ROM has similar ability to load more than one sector
initially, the complementary is valid, too.

This should reduce the effort to bootstrap additional sectors from the
booting sector #0 so you can read the "alien" parts of the disk later.

[Steve Nickolas]

Weeeeeeeeell...

Of the first 3 tracks, here's usage for a DOS 3.3 48K slave:

0123456789ABCDEF
0##### ##########
1################
2#####

Would it be possible to change usage to something more like this?

0123456789ABCDEF
0#####
1################
2##### ##########

and then stuff two versions of the first 5 sectors onto the same track 0?
(i.e., a 16-sector version and a 13-sector version).

-uso.

[ict@ccess]

On Jan 14, 6:32 am, Steve Nickolas

I can see how that would work. Each set of 5 sectors would have its
own timing nybbles so that the start of the track would be in
different positions for a 16 sector disk and a 13 sector disk.

Well played

[Vladimir Ivanov]

Steve,

I am not totally sure what you're after, but if I got your questions
right:

On Sat, 14 Jan 2012, Steve Nickolas wrote:

> Weeeeeeeeell...
>
> Of the first 3 tracks, here's usage for a DOS 3.3 48K slave:
>
> 0123456789ABCDEF
> 0##### ##########
> 1################
> 2#####

Is T0/S5 missing for a reason?

> Would it be possible to change usage to something more like this?
>
> 0123456789ABCDEF
> 0#####
> 1################
> 2##### ##########

Moving part of T0 to T2 is just a matter of loader for booting purposes.
"INIT" would have to be rewritten, but it's screwed anyway since track #0
has to be written with non-standard format.

As we already agreed to, "INIT" is prime sacrifice. ;-)

> and then stuff two versions of the first 5 sectors onto the same track 0?
> (i.e., a 16-sector version and a 13-sector version).

Ok, I guess you want to keep T1..T22 in 16-sector format, only T0 is
funny.

Here's something even more easier to do and maintain:

Put one 16-sector and one 13-sector S0 on T0. Fill the rest of the track
with "macro" sectors encoded in 18-sector format, just as we discussed
recently. The beauty of this approach is that the code in both S0 will be
exactly the same for 13 and 16-sector cases - it will contain loader for
the "macro" sectors from T0. In case 256 bytes aren't enough for such a
loader (and you can't rely on the bootstrap ROM), revert to some simple
scheme, even 4&4. But the layout of 18-sector "macro" sector is very easy
and straightforward.

Again, you write T0 in single pass.


Now, the only problem with this scheme is that you want to have 16-sector
format with 13-sector P5/P6 PROMs on the disk controller. Not reliable and
you can't expect (I think) that users will have lucky combination of
16-sector sequencer PROM and 13-sector bootstrap PROM. (Consult Sather's
"Understanding the Apple II" for details)

So, to be on the safe side, you have to keep the whole disk in 13-sector
format, and the "macro" portion of T0 to be in either something analogous
to 18-sector format but with 5&1 encoding, or plain 4&4 for simplicity.

[Steve Nickolas]

On Sun, 15 Jan 2012, Vladimir Ivanov wrote:

>
> Steve,
>
> I am not totally sure what you're after, but if I got your questions right:
>
>
> On Sat, 14 Jan 2012, Steve Nickolas wrote:
>
>> Weeeeeeeeell...
>>
>> Of the first 3 tracks, here's usage for a DOS 3.3 48K slave:
>>
>> 0123456789ABCDEF
>> 0##### ##########
>> 1################
>> 2#####
>
> Is T0/S5 missing for a reason?
>
>> Would it be possible to change usage to something more like this?
>>
>> 0123456789ABCDEF
>> 0#####
>> 1################
>> 2##### ##########
>
> Moving part of T0 to T2 is just a matter of loader for booting purposes.
> "INIT" would have to be rewritten, but it's screwed anyway since track #0 has
> to be written with non-standard format.
>
> As we already agreed to, "INIT" is prime sacrifice. ;-)

So it has to be done with a separate program. The tool wouldn't fit in
INIT space anyway.

>> and then stuff two versions of the first 5 sectors onto the same track 0?
>> (i.e., a 16-sector version and a 13-sector version).
>
> Ok, I guess you want to keep T1..T22 in 16-sector format, only T0 is funny.

I dunno if it'd work that way. Might have to be a 4-track 13-sector DOS.

> Here's something even more easier to do and maintain:
>
> Put one 16-sector and one 13-sector S0 on T0. Fill the rest of the track with
> "macro" sectors encoded in 18-sector format, just as we discussed recently.
> The beauty of this approach is that the code in both S0 will be exactly the
> same for 13 and 16-sector cases - it will contain loader for the "macro"
> sectors from T0. In case 256 bytes aren't enough for such a loader (and you
> can't rely on the bootstrap ROM), revert to some simple scheme, even 4&4. But
> the layout of 18-sector "macro" sector is very easy and straightforward.
>
> Again, you write T0 in single pass.
>
>
> Now, the only problem with this scheme is that you want to have 16-sector
> format with 13-sector P5/P6 PROMs on the disk controller. Not reliable and
> you can't expect (I think) that users will have lucky combination of
> 16-sector sequencer PROM and 13-sector bootstrap PROM. (Consult Sather's
> "Understanding the Apple II" for details)

Which is why these disks usually run some form of DOS 3.2 (Bob
Sander-Cederlof's assembler documentation for an early version actually
mentioned using a 16/13 DOS 3.2.1), and one I've seen runs a form of 3.1.

>
> So, to be on the safe side, you have to keep the whole disk in 13-sector
> format, and the "macro" portion of T0 to be in either something analogous to
> 18-sector format but with 5&1 encoding, or plain 4&4 for simplicity.
>

Yeah.

-uso.

[Steve Nickolas]

Replying to myself.

The best I can see the usage of DOS 3.2 with a 16-sector bootstrap would
be to use 3.5 tracks, rather than 3, thus:

Track usage as seen from DOS 3.3 on the left, 3.2.1 on the right.
# - native sector. % - non-native "sector", shown stretched or squashed by
410/342. (this may be inaccurate)

0123456789ABCDEF 0123456789ABC
0##### %%%%%% ##### %%%%
1%%%%%%%%%%%%%%%% #############
2%%%%%%%%%%%%%%%% #############
3%%%%%%% ######

Basically, a few "common" sectors written on track 0 both in DOS 3.2 style
and in DOS 3.3 style, then 2.5 tracks containing the rest of the DOS
image, probably 3.2.1, reordered and with a different loader. It may even
be possible to have track 0 reread AFTER the base rwts is loaded, and load
up to 4 additional sectors there. Maybe others could be freed up and it
would actually fit in 3 tracks, allowing for no loss of capacity.

Formatting would of course require a separate tool... there's no way in
hell to ram all that code into DOS 3.2.1 space.

-uso.

[Linards Ticmanis]

On 01/15/2012 03:17 AM, Steve Nickolas wrote:

> Basically, a few "common" sectors written on track 0 both in DOS 3.2 style
> and in DOS 3.3 style, then 2.5 tracks containing the rest of the DOS
> image, probably 3.2.1, reordered and with a different loader.

I think the way it was usually done was to have everything in 13-sector
format, except for one single boot sector that can be read by the
16-sector controller card. That sector then just contains an equivalent
of the 13-sector boot ROM and the first thing it does is to simply load
the 13-sector boot sector and jump to it. From there, everything is
almost the same for the two code paths; the 13-sector boot sector is
modified only insofar as it detects whether it has been read in directly
by a 13-sector controller card or by the 16-sector boot sector and
adjusts accordingly (boot sectors generally re-use some part of the
controller ROM routines since they're too small to do anything useful
without that trick).

At least that seems to be what the original release of "Ultima" (later
known as "Ultima I") does, the only universal booter I have looked at in
some detail.

--
Linards Ticmanis

[Steve Nickolas]

Castle Wolfenstein and Alien Addition are universal booters. The NIBs
have this feature intact.

-uso.

[Antoine Vignau]

Another one is Softporn adventure by On-line systems,
av