[Coco] Fuzix: Now on CoCo2

[Brett Gordon]

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?




>
> I do have a few questions for you Brett:
>
> Do you have any programming reference for the CocoSDC?
>

in the mail


> 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)



> Should we move the CocoSDC driver over to Kernel/dev?  Not sure if having
> a device named “sd” and a different one named “sdc” in the same directory
> would be too confusing...
>

The naming has already lead to confusion.  Move to kernel/dev only common
code.  we'll have to factor the common bits out of both platforms.  Alan's
pushing for swapping again, and this will radically change my driver base
away from the other coco/dragon ports :(, so things will diverge
(unfortunately).  Let things shake out, then factor the common stuff out.

Alan also commited some an 8k banking model, so the coco3 port will
probably change over to that.  This new banking model will (someday) allow
a userspace apps to map in video memory into user-space, allowing for fast
graphics access. (graphical games!).  Then will need a palm-os (or
android-ish) style gui, just for fun.

brett