Re: Floppy disk bootloader, now with Twiggy support

I think it would be pretty easy to make a universal version of the bootloader for floppies, at least where "universal" means "Twiggy or Sony"---you just need to use the ROM ID to select the track table and values for the kDdZzMask, kNextDrEor, and kTrk0Sects constants. How you would tell a 400k Sony drive from an 800k drive is beyond me, though.

The bootloader should already be multi-disk for Twiggy systems, where "multi" means "two" and where both disks are already sitting in the drives. But I haven't actually tried this. I suppose it could be "multi" "disk" for Sony systems too, if you were using a Floppy Emu-like device that could change sector and tag data on the fly. But that's a little silly.

I'm not sure I'm going anywhere in particular with the bootloader---although originally created it to boot NeoWidEx, it's mainly an idle pasttime now. The Twiggy support was for another little program I've written, but even that program fits inside 512 bytes, so no bootloader was really necessary.

I've now updated the Python program
<https://github.com/stpltn/bootloader/blob/master/dc42_build_bootable_disk.py> in the archive to include built-in copies of the bootloaders, so the program should be everything you need to make a bootable disk image. This new version also allows you to create "truncated" .dc42 files, like the one used for BLU, at least for 400k and Twiggy disks. This can really save on the amount of time you spend transferring and writing disk images, but it also seems that these truncated images are not compatible with LisaEm!

That said, it seems like truncated images work on my Lisas, either via Floppy Emu or via loading and writing a disk image with BLU.

--Tom

On Saturday, November 4, 2017 at 9:23:33 PM UTC, James MacPhail wrote:
>
>
> >I've updated my public domain Lisa floppy disk bootloader to include
> >support for Twiggy disks.
>
> It is interesting to watch where you are going with this!
>
> >disk media type is controlled by source code configuration options
> >(unlike e.g. whatever code bootloads BLU)
>
> I have to admit that the BLU loader "cheats" by knowing that it is
> not on an 800k disk, and therefore is less than 400k, so it always
> will fit on the first side of a Twiggy. As a result, the loader
> doesn't need ever use the second side of a disk.
>
> Removing the side-select logic makes it easier to fit in one sector
> -- it simply selects the sectors/track table depending on the drive
> type (as indicated by the I/O Board ROM ID).
>
> If a "universal" loader cannot be optimized to fit in one sector, one
> could use a two stage loader; a universal loader will certainly fit
> on the first side of the first track, and that can be loaded using
> the BLU strategy. I suspect that would be enough room to make it a
> multi-disk loader too.
>
> James
>

-- 
-- 
-----
You received this message because you are a member of the LisaList group.
The group FAQ is at http://lowendmac.com/lists/lisa.html
To post to this group, send email to lisalist_at_email.domain.hidden
To leave this group, send email to lisalist+unsubscribe_at_email.domain.hidden
For more options, visit this group at http://groups.google.com/group/lisalist
--- 
You received this message because you are subscribed to the Google Groups "LisaList" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lisalist+unsubscribe_at_googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



text/html attachment: alternate version of message