[Coco] Just another peek...

Fri Oct 9 19:54:27 EDT 2015

On 2015-10-09 17:07, Bill Pierce via Coco wrote:
> Dave, Not owning an FPGA (or SD card reader), so my knowledge would
> VERY limited to what I know of how a standard system works, but I
> think enlarging the "boot track" would involve modifying DECB... more
> than modifying OS9 (almost).
> The DOS cmd loads the entire contents of track 34 (18 sectors) to
> $2600 then executes it. So the limit is in the DOS cmd.
> 

Yes, well presumably you'd have to modify DECB anyway since the DOS 
command utilizes the FD controller for the booting of OS9 and we would 
now want to use the SD controller to boot it.  The only reason for OS9 
loading 18 sectors is because that was conveniently the size of one 
track on a 1980s era floppy disk.  And the only reason for it loading 
from track 34 was that was the last track (logically numbered from 0-34) 
on a floppy disk of that era.

> Also, enlarging the kernel, would entail modifying all the various
> locations of modules (and addresses pointing to them) as that would
> move everything else up in memory as well. Then you run into the whole
> "crossing 256 byte & 8k boundries" thing.

I'm only proposing the enlargement of one module, Boot, for some extra 
code that the SD controller requires to initialize and read sectors.  It 
would probably be enlarged in the neighborhood of one or two more 
256-byte sectors. This would require that Boot be positioned a little 
lower down in memory but I don't think it would be much of an issue. Rel 
and Krn would still stay in their same position. As for the rest of the 
modules that load with the OS9Boot file it would have no effect on them.

> 
> Of course, making it single pass would involve a whole new boot
> techniqe as the kernel's first job is locating the rest of the
> bootfile (OS9Boot) and loading it into memory. Yes, it could probably
> be done, but it would take heavy modification to the kernel files
> (rel, boot, krn). Brett Gordon was working on something similar with
> his CocoBoot, you may want to look into that.
> 

I'm not sure it would involve too much.  Basically, you'd just have to 
skip over where Krn loads OS9Boot into memory  and then resume where it 
searches memory for the modules.  I know that's an over-simplification 
but....  Actually, I read an article written by Boisy about ROMming OS9. 
  You could sort of think of it like that.  In fact, the CoCo3FPGA could 
be programmed to load all of the modules into memory at once and then 
lock out writes to the memory effectively making it a 'ROM'.  It's not 
that much different.

In reality, I'm not so dead set on doing a one-stage boot as I am 
getting the boot from SD card working.  Because of the fact that not all 
SD cards are created equal the initialization is a little more complex 
than for, say, a FD or HD controller. For that reason, it looks like I 
just need a sector or two more space and I think that's do-able.  I 
understand how those three modules are very particular about their 
positions in memory but I also don't see a reason why the Boot module 
can't be just a little bit bigger with a starting point in memory just a 
little bit lower.  I've already created a very simple utility that will 
load a particular "track" off the SD card in to $2600 and execute it.  
In fact, I have already booted NitrOS9 from the SD card.  In lieu of 
using the DOS command I simply executed a small m/l program from DECB.  
The problem is that the current code in the version of Boot that was on 
the SD card 'boot track' boots the rest of the OS from the FD controller 
which in the case of the CoCo3FPGA is translated into drivewire 
commands.  I just need to modify Boot to initialize and read sectors in 
from the SD card and then make sure that the kernel knows how to boot 
the rest of the system from a 'partition' on my SD card.  I was part way 
into this when I learned a hard lesson: when you're playing with 
low-level disk (SD card) I/O and writing drivers that manipulate that 
controller, don't store your only copy of the source code on that same 
drive!  I don't think I need to go into details.... :)

Dave Philipsen

> One thought; though I have no clue how the FPGA & SD are set up and
> how you are currently booting; would be to make a "standard" boot disk
> which contain nothing but the kernel. Then once it loads, it looks to
> the larger partition for the OS9Boot. This way RSDOS sees a standard
> sized disk and boot track...
> 
> I assume the whole problem though, lies in getting the SD card
> routines that load the boot, into the kernel and staying the porper
> size (18 sectors). That's beyond my knowledge.
> 
> As I said, I have no idea how FPGA boots OS9 as I don't own one (yet),
> so it's hard to say how such a thing would be done.
> 
> 
> 
> 
> 
> 
> Bill Pierce
> "Charlie stole the handle, and the train it won't stop going, no way
> to slow down!" - Ian Anderson - Jethro Tull
> 
> 
> 
> My Music from the Tandy/Radio Shack Color Computer 2 & 3
> https://sites.google.com/site/dabarnstudio/
> Co-Contributor, Co-Editor for CocoPedia
> http://www.cocopedia.com/wiki/index.php/Main_Page
> Global Moderator for TRS-80/Tandy Color Computer Forums
> http://www.tandycoco.com/forum/
> 
> E-Mail: ooogalapasooo at aol.com
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Dave Philipsen <dave at davebiz.com>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Fri, Oct 9, 2015 5:02 pm
> Subject: Re: [Coco] Just another peek...
> 
> 
> I have already contacted one person who subscribes to this list looking
> for
> help in developing a stand-alone boot into NitrOS9 but have not yet
> received a
> reply from him.  If anyone has some experience with this and
> would like to help
> it would be much appreciated.  Basically what is
> involved is the modification
> of the Boot module and perhaps re-location
> and re-sizing of the boot track to
> the SD card.  In fact, as I see it
> there's no reason why we couldn't change the
> two-stage boot process into
> a single-stage process and boot the entire NitrOS9
> system in one fell
> swoop!
> 
> 
> Dave Philipsen
> 
> 
> On 2015-10-09 13:27, Michael Brant
> wrote:
>> I am also interested in knowing more about the SD card access as i
>> 
> would
>> want a stand alone setup.
>> On Oct 9, 2015 2:24 PM, "Barry Nelson"
> <Barry.Nelson at amobiledevice.com>
>> wrote:
>> 
>>> I would want one of these, but I
> do not want to have to use an
>>> external
>>> DriveWire server. Any updates on
> how the SD card access is going?
>>> 
>>> 
>>> 
>>> >    Dave Philipsen dave at
> davebiz.com
>>> 
>>> >    Fri Oct 9 10:51:34 EDT 2015
>>> 
>>> 
>>> 
>>> >    It works
> just like the other video modes on the CoCo 3. The video
>>> memory is part of
> the 512k memory map. In this case about 288,000
>>> bytes of
>>> memory are
> used.
>>> 
>>> 
>>> 
>>> >    Dave Philipsen
>>> 
>>> 
>>> 
>>> Ø  On Oct 9, 2015, at
> 1:45 AM, Brett Gordon <beretta42 at gmail.com>
>>> wrote:
>>> 
>>> >    >
>>> 
>>> Ø
> That's awesome Dave!  So where exactly is this video memory coming
>>> from?
>>> 
> 
>>> Ø  ahhh.. i really want one of these now...
>>> 
>>> >    >
>>> 
>>> Ø  --
>>> 
> 
>>> Ø  Coco mailing list
>>> 
>>> Ø  Coco at maltedmedia.com
>>> 
>>> Ø
> https://pairlist5.pair.net/mailman/listinfo/coco
>>> 
>>> 
>>> --
>>> Coco mailing
> list
>>> Coco at maltedmedia.com
>>> 
> https://pairlist5.pair.net/mailman/listinfo/coco
>>> 
> 
> --
> Coco mailing
> list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco