[Coco] Trying to build new images

[Bill Gunshannon]

On 1/8/17 12:49 PM, Gene Heskett wrote:
> On Sunday 08 January 2017 11:38:53 Bill Gunshannon wrote:
>
>> On 1/8/17 10:05 AM, Bill Pierce via Coco wrote:
>>> Robert, first, he is trying to build a boot from/for L1... A
>>> daunting task to say the least LOL Probably not enough memory to run
>>> all the needed cmds. In fact, I don't think the shell in L1 supports
>>> all the script cmds.
>>
>> Huh?  What scripts are you talking about?
>>
>> This is the script from the system that I am trying to use.
>>
>> -t
>> -x
>> tmode .1 pau=0
>> echo * NitrOS-9 Level 1 Boot Creation Script
>> echo *
>> echo * This script creates a bootable DriveWire 3 disk image
>> echo * using the dw.bl bootlist file.
>> echo *
>> echo * The resulting disk will boot NitrOS-9 from DriveWire drive 0.
>> echo *
>> prompt Insert a blank disk in /x1 and press a key:
>> echo *
>> echo * Step 1: Format disk in /x1
>> format /x1 "NitrOS-9 Level 1 Boot Disk" r
>> ynn
>> echo *
>> echo * Step 2: Create a custom boot track
>> del bttemp
>> merge ../MODULES/BOOTTRACK/rel ../MODULES/KERNEL/krn
>> ../MODULES/KERNEL/krnp2 ../MODULES/SYSMODS/init
>> ../MODULES/BOOTTRACK/boot_dw>bttemp
>> echo *
>> echo * Step 3: Create the bootfile and boot track
>> os9gen /x1 -t=bttemp<../BOOTLISTS/dw.bl
>> del bttemp
>> echo *
>> echo * Step 4: Populate the disk with essential files
>> copy ../MODULES/SYSMODS/sysgo_dd /x1/sysgo
>> makdir /x1/CMDS
>> copy -w=/x1/CMDS ../CMDS/shell
>> echo *
>> echo * We're done
>>
>> What commands are not in Level1?  And, as stated previously, script
>> runs to completion with only one error and it's not really an error.
>> "del bttemp" fails because at that point "bttemp" does not yet exist.
>>
> It very well should exist, the merge command above it should have created
> it.

No, the actually delete it twice.  Once in the beginning because if it
were there then the merge would fail.  And then again at the end.  Just
being safe, I guess.

> Had it not been there, os9gen should have complained.  However I
> think I see the error above. as I've also had problems with mb, such
> that my mb script does things somewhat differently.
>
> The first thing to try is adding a space in this statement:
>
> merge ../MODULES/BOOTTRACK/rel ../MODULES/KERNEL/krn
>  ../MODULES/KERNEL/krnp2 ../MODULES/SYSMODS/init
>  ../MODULES/BOOTTRACK/boot_dw>bttemp
>
> so it becomes:
>
> merge ../MODULES/BOOTTRACK/rel ../MODULES/KERNEL/krn
>  ../MODULES/KERNEL/krnp2 ../MODULES/SYSMODS/init
>  ../MODULES/BOOTTRACK/boot_dw >bttemp

I will try that right now. But being as the OS9Boot was being
creaed I don't think that's a problem.

>
> Bear in mind this is an email, and the word-wrap has broken up the line
> in the mb script and the above 3 lines you see here are actually a
> single long line.

Yeah, i got that.  I also learned that build has a  line length
limit so I actually had to break it up into multiple lines to
get it on the system in the first place.

>
> And do the same with the os9gen line
>
> os9gen /x1 -t=bttemp<../BOOTLISTS/dw.bl
>
> makeing it:
>
> os9gen /x1 -t=bttemp <../BOOTLISTS/dw.bl
>

For some reason (probably just aesthetics) I had already done that.

>>> 2nd, I've found in most cases those scripts do not work as the
>>> syntax for copy does not match the version currently in the repo, so
>>> usually, grfdrv, sysgo, startup, and shell (or any of the cmds dir)
>>> do not get copied. I think it works with the old copy. There are
>>> other problems with those scripts that I have mentioned here on the
>>> list as they are old and do not reflect the current repo. Hopefully,
>>> that is getting ready to be changed.
>>
>> I am truly confused by this.  Are we even talking about the same
>> scripts?
>>
>>> 3rd, he's not using hdbdos and is trying to boot from a floppy disk
>>> or image.
>>
>> Well, I am using an HDB-DOS ROM but once youi boot into NitrOS9
>> doesn't that just sit on the side lines idle anyway with NitrOS9
>> handling all the hardware access itself?  And I am booting from
>> Drivewire and trying to build what I thought would be the same image
>> built on a different drive.
>>
>>> And Bill, most people actually build their disk images using the
>>> same utilities used to make the disks in the repo which are
>>> generated by PC tools (LWTools & ToolShed), and not in OS9.
>
> Something I have never done. LWTools and Toolshed build the full maryann
> of Nitros9 from the sources, and do it about 500x faster if not
> generating the listings. I always mount the .dsk I want to build a boot
> floppy from in one of drivewires x drives, copy into that image the mb
> and bl files that make a floppy image someplace, and then move it to my
> hd as one of the hdbdos disks.
>>
>> Then why provide the scripts and bootlists at all? Why not just say
>> "you can't get there from here?"  I do not have a PC build environment
>> and I would really like to do this on OS9.  If I wanted to work on a
>> PC I would throw all the COCO's out and just work on a PC.  Heck, I
>> don't even run emulators.  :-)
>
> Neither do I, this is a pure linux house, with 5 pc's and one
> raspberrypi, all running linux. And all but this one has a metalworking
> machine attached to it. One of my other hobbies.

Oh yeah, when someone asked about other machines I forgot to mention
Pi's and Arduinos.  I think I have  more computing power available
in my house than they have on the ISS.

>
> AIUI, your system does not have a working big drive. I think that would
> be the first thing I'd do,

That's the whole purpose of this exercise.  I have a Tc3, SUperIDE and
3 Glenside boards. I have two working COCO2's, hope to have a couple of
COCO3's back if they can be repaired and on COCO1 that didn't come on
when I dug it out (it is on the bottom of my list of priorities). I hope
to have a couple of systems to play with, all with big disks as I have
some ideas I want to work on for fun.  Like Unix on the 6809. And maybe
even Xinu. :-)

> is getting the hard drive working. However,
> with drivewire working, drive size isn't a limit until you need to up
> the cluster size at about 131 megabytes. So as long as DW is working, a
> x descripter can point to a big enough disk image to hold most of what
> we've done in the last 30 years on coco3's.
>

Drivewire is nice, but it has its share of warts, too.  Especially
on the PC end.  And I haven't been able to get the Linux version to
run at all.  But, one step at a time.  I have even given some thought
to looking into Drivewire clients for other systems like the original
TRS-80's and PDP-11's.  After all, this is just a hobby for me
anymore.

> I still have some floppies that work, but those are beginning to be rare
> & hard to find.

I have piles of floppy drives floating around.  Everything from 3.5" to
8".  And the floppies, too.  I have boxes of brand new 720K 3.5" and
even brand new, unopened 8".  I've been at this a long time.  :-)


>The drive interface technology has changed so much over
> the last 30 years, such that if Mark or any of our hardware whiz's were
> to try and build an interface to handle a sata drive, I can easily see
> the end product at well above a hundred dollar bill. That won't sell to
> us in enough qty's to pay the bills.  Sad but true.

I think we already have it.  I have SATA to IDE converters that mount
right on the back of the drive.  I hope to try them with SSD's once I
get this OS stuff sorted out.  And, there are always CF to IDE adapters.
CF is really cheap.

bill