[Coco] Fuzix: Now on CoCo2

[Michael R. Furman]

I took a stab at making boot.s work on Coco2 w/CocoSDC and Coco3:

http://www.ocs.net/~n6il/fuzix_coco2_boot_s.html <http://www.ocs.net/~n6il/fuzix_coco2_boot_s.html>

The booter is nice and small:

$ lwasm -o boot_coco2.bin -DCOCO2 boot.s
$ bindumper2 boot_coco2.bin
0000: Type: 0 Size: 19 Addr: 1900
001e: Type: 0 Size: 1d2 Addr: 193f
01f5: Type: ff Size: 0 Addr: 195f
File Size: 01fa

$ lwasm -o boot_coco3.bin boot.s
$ bindumper2 boot_coco3.bin
0000: Type: 0 Size: 19 Addr: 7a00
001e: Type: 0 Size: 23f Addr: 7a3f
0262: Type: ff Size: 0 Addr: 7a5f
File Size: 0267

I had to remove the entire IDE driver because I ran out of memory, can’t be trying to write FUZIX on top of the ECB ROM...  Do you think that if I told the SDC to switch images to FUZIXFS.DSK on drive 0 before EXEC’ing the booter and I straight copied your CocoSDC driver and blkdev that I have any chance of FUZIX finding the filesystem and booting? Now that I have the booter and the kernel I guess the next step is to fire up the old grey beast and see what happens!

—

Michael R. Furman
Email: n6il at ocs.net
Phone: +1 (408) 480-5865


> On Dec 6, 2016, at 1:18 PM, Brett Gordon <beretta42 at gmail.com> wrote:
> 
> I have sent you a direct email with one untested sdc replacement for
> bootstrap.s, and darren's docs.
> 
> concerning the regular driver:  You'll have to rip out the blkdev interface
> out of the coco3 sdc driver.  Must get transfer params from udata, now.
> Also: Alan's mini_ide works on assumed partitions, so 32MB will have to be
> added for each minor as an LBA offset.  This needs to happen because the
> first minor, is the swap partition (and has the RAM part of the kernel
> image too), another partition will have to be root.
> 
> see inlined:
> 
> 
> On Tue, Dec 6, 2016 at 2:55 PM, Michael R. Furman <snip> wrote:
> 
>> Bootstrap.s is icky, reads a raw memory image instead of a DECB bin, and
>> it’s really designed to bootstrap a ROM system.  It seems like your coco3
>> loader would work with a few changes, I think I will try that.  I’m pretty
>> sure I figured out where to load it so it won’t get overwritten by
>> fuzix.bin, looks like the last 1-2k of FUZIX's screen area should be unused
>> by both FUZIX and DECB.
>> 
> 
> Yup, I was thinking an external booter would save having to even have
> bootstrap.s. probably have to cleverly flip to 64 all ram mode to insert
> the kernel where it belongs, then the booter could just use sdcdos's DSKCON
> routines to load the kernel, or load it from a DECB file (like I do with
> coco3)... or squeeze the booter below $1a00 and above basic RAM at $e00...
> should be doable in 3k?
> 
> 
> 
> 
> 
>> Does your CocoSDC driver support multiple drives, if I passed through SDC0
>> or SDC1?
>> 
> 
> yup. Alan's ide mini_ide driver uses the top bit of of the minor number to
> pass the drive number, so yes that could be used to do the bottom bit of
> the SDC command code (which is it's drive no., 0 or 1)
> 
> 
>