[Coco] DECB development under OS9

[Dave Philipsen]

Yep, understood.  I may give it a try tonight.  From what Bill said it would just be a matter of creating the HRS_DATA file with this line in it:

/sd1 #00000


Dave


> On May 14, 2018, at 4:58 PM, Robert Gault <robert.gault at att.net> wrote:
> 
> The logic behind what Bill explained is that I wrote my program to work with real and virtual hard drives where there were both OS-9 and Disk Basic partitions. With the RGBDOS ROM supplied with KenTon SCSI hard drives, the first sectors of the drive (if desired) would be OS-9 followed by up to 256 Disk Basic "drives" 35 tracks of, 18 sectors of 256 bytes.
> The same arraignment was adopted by MESS and VCC for the .vhd emulated hard drives with a default OS-9 section of $5A000 (368640 decimal) sectors followed by 256 Basic drives. This value is stored in the ROM at $D938-$D93A. My Basic program SPECS.BAS will read this value and report it.
> 
> As a real hardware example, my first SCSI drive was a Tandon TM252 formatted with 32760 OS-9 sectors followed by 12 Disk Basic drives. A very small drive by today's standards.
> 
> Given that there is no way to tell what type of drives are mounted on Drivewire, it has the option of setting an OFFSET for each drive (if they are .vhd types) and whether the drives are separate or mimic the Disk Basic partition of a .vhd drive (DW set to "HDBDOS translation").
> 
> Robert
> 
> Bill Pierce via Coco wrote:
>> Dave, HRSDOS requires you to have a file in "DD/SYS/HRS_DATA" that contains the offset in sectors (in decimal) to the RSDOS partition on that drive. It's just a plain text file, "HRS_DATA" with no extension. You list each drive on your system and the offset to the rsdos partition (if any).
>> Example:
>> /d0 #000000
>> /d1 #000000
>> /x0 #368640
>> /x0 #368640
>> 
>> The list must be formatted exactly as above including the "#". There's example files on my MShell installation disks in the "dd/sys" folder as MShell uses HRSDOS to access RSDOS disks. All you would have to do is change the offsets to match your drives.
>> As you see above, standard floppies would need no offset.
>> 
>> 
>> 
>> 
>> 
>> 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
>> 
>> 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: Mon, May 14, 2018 2:52 am
>> Subject: Re: [Coco] DECB development under OS9
>> 
>> I tried both the RSDOS and the HRSDOS utilities.  The syntax of the two seemed pretty similar. It seems that perhaps there is a special setup needed for HRSDOS as it would not do what I wanted it to do "out of the box".  To be fair I did not go through all of the documentation although it seems it was more specifically designed for a SCSI HD with multiple RSDOS partitions.The RSDOS utilty, however, seemed to work as expected.  Using 'rsdos -dir /sd1' yielded a directory listing of the disk image I mounted to drive 1 before booting OS9.  Using 'rsdos -put README.TXT /dd/readme.txt' copied the OS9 file to the RSDOS disk image.  When I rebooted to DECB and mounted the drive I found the file that I had copied there from OS9.So the ability to move files back and forth between OS9 and DECB is already available in OS9 and has been for some time.  And it seems my idea of developing an m/l program under OS9 for DECB will work. It would be a fairly simple matter to write a script that would
> assemble the source file and copy the binary output file to the DECB image on /sd1.  Then just reboot the computer and test it out.  I might have to look into how to 'AUTOEXEC' a file on startup with the CoCoSDC and then I could just write a program that would present a menu for either booting into OS9 with the DECB partition mounted on drive 1 or just booting DECB with the DECB partition mounted to drive 0.  (Just so I don't have to manually mount the drives every time I reboot.)Perhaps Robert may chime in to clarify how I might use HRSDOS to accomplish this as well.DaveOn 5/11/2018 5:13 PM, L. Curtis Boyle wrote:> I think the RSDOS utility will do this already, so you could set that up in a script to copy to/from a DECB disk image directly.>> L. Curtis Boyle> curtisboyle at sasktel.net>>>>> On May 11, 2018, at 4:02 PM, Dave Philipsen <dave at davebiz.com> wrote:>>>> I have a possible project that I'd like to get a little input on.  I would like to use NitrOS9 as my development platform for programs that will run under DECB.  The reason for this is that NitrOS9 is well suited in that it has plenty of disk space and several assembler options available.  It would be easy to include the headers inside of the source code for compatibility with the DECB LOADM format as I've already done this with a cross assembler under DOS/Windows.  I'm not really keen on the idea of having to develop on a PC, transfer the output file via drivewire to the CoCo, and test.>>>> I have a CoCo3 with 512K and I have CoCoSDC that has disk images for booting NitrOS9 as well as images for DECB.  What I was thinking is that I could write a utility program that runs under NitrOS9 that would allow me to copy files back and forth to one of the DECB disk images on the CoCoSDC.  Maybe it has already been done.  Has anyone ever attempted this?  If not, is there anyone who would want to give me a little advice on how, theoretically, it might be done?>>>> I see there is a low level driver for the cocosdc
> and I'm wondering how difficult it would be to mount a DECB disk image and access the image as another drive under NitrOS9.  I realize that because of the difference in disk format the drive would not be natively read/writeable from NitrOS9 but as long as all of the virtual sectors were accessible then I could write a program to access the data/programs in the DECB file system.  So I guess I'm asking whether it would be feasible to mount one or more DECB disk images on the CoCoSDC as virtual drives; /SD1, /SD2, etc.>>>> This would allow me to write a program under NitrOS9, assemble it, copy the DECB format binary to the correct DECB image on the CoCoSDC, then reboot the computer and test the program out in DECB. Another idea I have which would be an add-on to this would be a way to actually compile a NitrOS9 C program and either trap or replace the system calls and have the program usable under DECB.  I know this is a bit of a stretch but it might be possible if only certain limited
> system calls were used from the C program.>>>>>>>> Dave>>>>>> -- >> Coco mailing list>> Coco at maltedmedia.com>> https://pairlist5.pair.net/mailman/listinfo/coco>>>-- Coco mailing listCoco at maltedmedia.comhttps://pairlist5.pair.net/mailman/listinfo/coco
>> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco