[Coco] Just another peek...

Dave Philipsen dave at davebiz.com
Sat Oct 10 13:28:22 EDT 2015


Well, Gary wrote the low level drivers for NitrOS9, I adapted the code and made it non position indepedent for use under DECB. To my knowledge nothing has been done yet for HDBDOS.  I started working on the Boot module but my development was purely on the CoCo3FPGA.  I haven't set up a PC or Linux system with lwtools yet and that's a whole other learning curve for me.  So I was part way along with the Boot module and not backing up my source code.  It was residing on the SD card of the CoCo3FPGA. Well, to make a long story short, I trashed some sectors on the card and lost access to it.  I still have the card and it's quite possible the stuff is still recoverable in some way but would probably take more effort to retrieve than it would just to start from scratch again.  It was so nice, too, because the whole process was very fast using some script files and not having to transfer files to/from the CoCo.  At 25 MHz the CoCo 3FPGA buzzed through the task in a matter of seconds.

I have just started back up with the CoCo as a hobby after an absence of some 24 years. I do not have any of my old stuff (MPI, floppy, B&B HD, RS232, etc.).  I only have three CoCo 3s that were left over from the last project I ever did on the platform which involved a custom cartridge with numeric keypad interface and a BASIC program in it that auto-booted and was used in a restaurant chain for an order pickup system. (Customers sitting at tables would see their number appear on a video screen and would go pick up their pizza or whatever when it was ready.) So I was buying CoCo 3s 5-10 at a time for $99 apiece back in the early 90s and when the company stopped buying the systems from me I still had 3 of them left over.  But since the CoCo3FPGA is pretty much a self-contained system I've decided to go with that for now instead of finding all of the stuff I need for a real CoCo 3 setup. And at this point I'm not even sure I want to go back to the real CoCo 3!

Gary has been very busy with the HDL development of the CoCo3FPGA and it's a wonder that he even got the low level drivers written for the SD card along with everything else he's been doing. At this point I'm a little discouraged losing the work that I had done up until this point and I figured that there is someone out there (like you) who is much more familiar and nimble with the tools needed to accomplish this.  After I trashed my SD card Gary had just finished up with the 640x450 256-color mode so I decided to do a little work on getting a demo running to show off just what this system is capable of.  I've had a cross-assembler for years that runs under DOS and I did figure out how to use some of the Toolshed tools so that I can copy files out of the DOS window environment to a Drivewire disk image for easy porting and testing on the FPGA.  So that is what I have been focusing on for now.  I can, with some effort, install and start using the lwtools assembler to finish the work on Boot myself and I will if no one steps up to the plate to help.  I am just looking for a way to get it done a little more expediently by someone with a little more experience and expertise than me.

As I mentioned before I've already actually booted the FPGA from SD card. It's just that the bootfile contained the standard modules that continue booting NitrOS9 (2nd stage) using Drivewire. For me, the Boot module is the missing link.  I think I could fit the low level sector read stuff within the 768 bytes but it might be tough to get the initialization code in as well with that limitation.  It is for that reason that I was also thinking about a way to enlarge the Boot file slightly.  Since we are booting from an SD card and new code had to be written for DECB to boot from that card I didn't see the track 34, 18 sectors, and size of Boot module issues so much as hard and fast limitations anymore.


Dave Philipsen

> On Oct 10, 2015, at 10:24 AM, Brett Gordon <beretta42 at gmail.com> wrote:
> 
> If you're selling them all-set-to-go,  I am interested in purchasing
> one anyway regardless.  Anyway,  If someone has written the HDBDOS
> driver, and the OS9 driver, would they not be the more logical ones to
> write the BOOT driver?  After all: the BOOT driver is one of the
> simplest of the three to write.
> 
> As far as the repos go, I don't see SDIO drivers in either HDBDOS ?
> 
> I just checked Fuzix's driver for SDIO, and they compile down to about
> 1400 bytes.  This is mostly C source, though, and I'm sure we can get
> it smaller.
> 
> 
> 
> 
>> On Sat, Oct 10, 2015 at 9:18 AM, Dave Philipsen <dave at davebiz.com> wrote:
>> You can consider numbers 1 and 3 as effectively done already. As for fitting BOOT into 768 bytes or less I'm not 100% sure on that. It may be possible...
>> 
>> Dave Philipsen
>> 
>>> On Oct 10, 2015, at 6:16 AM, Brett Gordon <beretta42 at gmail.com> wrote:
>>> 
>>> In order to do stand-alone SD booting, the current OS9 two-stage boot
>>> does indeed require 3 drivers be written:
>>> 
>>> 1. One for HDBDOS/DECB
>>> 2. One for the boot loader (BOOT)
>>> 3. One for the Nitros9 run-time. (I guess someone did this already)
>>> 
>>> *Someone* here wrote a OS9 ROM booter effectively combines nos. 1 and
>>> 2 into one driver. (but leaves you without DECB), and requires one to
>>> monkey around with writing ROMs (which *is* pretty easy now-a-days)
>>> 
>>> The current Nitros9 BOOT implementation requires any new drivers to
>>> fit into 768 bytes of memory.  I'm guessing the SD driver would fit in
>>> there (even with the hideousness of the SDIO initialization code).
>>> 
>>> For writing any new driver, owning the subject hardware helps.  If I
>>> get the gumption to do all the crap needed to get a CoCoFPGA, I *may*
>>> help.  I've done the CoCoSDC drivers for HDBDOS.  And I don't think
>>> the BOOT driver is too difficult, considering the unholy union that
>>> BOOT/REL/KRN is. It's important to note though, because of our wacky
>>> "eat-your-own" and "nay-saying" that happens in this community, any
>>> coco programming I do now is for *myself*.  I will open-source it, of
>>> course, but if I take any crap, I will drop it like a plagued rat.
>>> 
>>> --
>>> Brett M. Gordon,
>>> beretta42 at gmail.com
>>> 
>>> --
>>> 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
> 
> 
> 
> -- 
> Brett M. Gordon,
> beretta42 at gmail.com
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco


More information about the Coco mailing list