Nitr-OS9 vs OS-9

A place to discuss everything Dragon related that doesn't fall into the other categories.
bluearcus
Posts: 142
Joined: Wed Sep 07, 2016 4:45 pm

Nitr-OS9 vs OS-9

Post by bluearcus »

I've just started messing around with Xroar, Dw4 and Nitr-OS9...

After some messing around, I have Nitr-OS9 booting from Drivewire. Great. Now... how about running some application software.

Hmm, not so great. It seems that thanks to Nitr-OS9's Level2 & CoCo3-centric ways, the Level 1 system has got a bit flabby.

Even with a reasonably stripped bootdisk, I've only 125 pages of memory free. Original DragonData OS-9 boots to leave 145 after entry into 51 column mode.

This means few applications will run when a drivewire enabled Nitr-OS9 system is up. Stylograph certainly won't. I haven't even considered BASIC09 or any of the other heavyweights.

That rather puts a kink in the appeal of drivewire based setups for me... Although I've managed to improve the situation by a handful of pages, I can't see how it would be possible to regain 5K or so to get back to a decent memory situation.

Could this problem be attacked by making a hybrid of DData OS9 and Nitr-OS9?

Yours, a bit disappointed.

Mike
bluearcus
Posts: 142
Joined: Wed Sep 07, 2016 4:45 pm

Re: Nitr-OS9 vs OS-9

Post by bluearcus »

To clarify a little...

Is there any reason why the Nitr-OS9 device drivers and descriptors for DW can't be shipped across to DragonData or Eurohard OS9?

I'm trying the process at the moment, but it's more involved than I'd expected... involving some Init module editing and I'm currently trying to work around the difference between a CoCo disk boot and a DragonDos one for DW booting (I guess CoCo Os9 and Dragon Os9 have different OS9gen implementations?)

Hohum, all good fun. Not sure if I'm going to get anywhere though. Long time since I used debug, looked at the system programmers manual or my copy of 'The Rainbow guide to OS9'!
bluearcus
Posts: 142
Joined: Wed Sep 07, 2016 4:45 pm

Re: No luck so far

Post by bluearcus »

Well, seems it's not straightforward to achieve.

First attempt was making a hybrid Eurohard 2.0 OS9 with Nitr-Os9 DW drivers and a Nitr-OS9 boot setup (Os9 gen from within Nitr-OS9 to ensure a DW capable disk with CoCo boot track arrangement).
That didn't work. Disk starts booting but never gets past the text mode splash.

That suggests that either the driver modules are somehow incompatible, or the boot is falling over in some other manner after load of the boot track. Not sure how to go about determining what is going wrong?

i was considering re-attemptting using DragonData Os9 next as the target environment.

The process I've been trying is as follows.

Save OS9 modules to a working directory. Omit physical DragonData disk controller module and associated descriptors.
Add drivewire driver and descriptor modules, virtual serial module and descriptors.
Edit Init module to change default startup execution path from /D0 to /DD, fix CRC with verify.
Os9gen from within Nitr-OS9 to make a bootdisk using this module set.

However, a bit more googling suggests that the Nitr-Os9 os9gen won't be including the correct kernel and other early stage boot modules in that boot track, as these are taken straight from the running system and Nitr-OS9's modules differ from the OS9 ones. Doh!

That sounds like either a hand-made boot track would need to be generated, or a custom os9gen created which can be run from OS9 against the modules setup as above. Hmm.

Mike
bluearcus
Posts: 142
Joined: Wed Sep 07, 2016 4:45 pm

Re: Nitr-OS9 vs OS-9

Post by bluearcus »

That suggests two possible approaches to me.

1) Os9gen on DragonData Os9 with the required modules, then hand move the boot track to comply with the CoCo 'boot' approach.

Disadvantage of this is you need a new version of OS9gen to avoid having to do this every time. CoCo OS9gen might work though.

2) Make a modification to the DLOAD"DOS" Dweeb to accept Dragon format boot disks. Either make it check both relevant tracks, or produce a new variant "BOOT" which uses the dragon boot track standard.

This seems the better approach I guess.

Mike
bluearcus
Posts: 142
Joined: Wed Sep 07, 2016 4:45 pm

Re: Nitr-OS9 vs OS-9

Post by bluearcus »

Or, I guess there's another way. Get the Pere's DosPlus extender running, and boot using that.

Can anyone share a working Xroar.conf for D64 with the extender and becker port?
pser1
Posts: 1655
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: Nitr-OS9 vs OS-9

Post by pser1 »

bluearcus wrote:Or, I guess there's another way. Get the Pere's DosPlus extender running, and boot using that.
Can anyone share a working Xroar.conf for D64 with the extender and becker port?
Hi, Mike
I am attaching here the bat and the roms I use to test on XRoar my DosPlus50 extender ...
as I have the XROAR.CFG modified, you will find here a small bat with the
cartridge definiton I use ...

Hope it helps.
I am sorry I cannot be of much help. I used OS-9 back in the 80's but I have not used it any more

cheers
pere
DosPlus50Extended pack.zip
(39.98 KiB) Downloaded 257 times
User avatar
tormod
Posts: 416
Joined: Sat Apr 27, 2013 12:06 pm
Location: Switzerland
Contact:

Re: Nitr-OS9 vs OS-9

Post by tormod »

Hi Mike,

Interesting stuff! Yes, NitrOS-9 level1 has shared some development (actual modules) with level2 and although this has given level1 a lot "for free" it has also become more memory intensive. One could easily make jokes about level1, it has grown so many features and can now do everything... except running applications :)

Porting DriveWire to Dragon Data OS-9 would be great! The DriveWire drivers themselves are not large, so this would allow more programs to run, and a more "retro-purist" experience.

I think you are right about using OS-9 os9gen to prepare the boot track. But does it also include the DriveWire boot module in the kernel track?

As for boot-strapping it, modifying DWDOS (or the "DOS" dweeb) would be fairly simple, as long as it is just about asking a number of sectors from a given start sector.

Another alternative would be the tools in ToolShed to cross-build disk images on a PC, as being used in the NitrOS-9 build. The ToolShed os9gen command has an option to make Dragon DOS boot floppies and you hand it a kernel track file and a boot track file.

Regards,
Tormod
bluearcus
Posts: 142
Joined: Wed Sep 07, 2016 4:45 pm

Aha... now I get it I think

Post by bluearcus »

Hi Pere, Tormod,

Interesting stuff.

From reading the Os9 Level 1 system programmers manual, and googling, I'd believed the process was quite simple.
Boot track loading and execution which chains the OS9boot file (while still running boot track code). Then system init and go. Easy to assume as the IoMan and everything onwards is within os9boot.

However, looking at the module directory on running systems, and the Nitr-OS9 sources I now see that the boot module which is included in the initial kernel modules load is the key - as this is what actually chains OS9boot, and so a custom boot module for DW needs to be included in the boot track modules?

Hmm... Off to try and build a custom boot track with a DW boot module then :-)
User avatar
tormod
Posts: 416
Joined: Sat Apr 27, 2013 12:06 pm
Location: Switzerland
Contact:

Re: Nitr-OS9 vs OS-9

Post by tormod »

Yes, the bootloader ("BOOT" command or DWDOS etc) simply loads the "kernel track" into memory from $2600 onwards, and jumps to $2600. This kernel track is composed of REL which relocates the whole thing to upper memory ($EE00 for NitrOS-9), the first part of the kernel OS9, the second part OS9P2, INIT and the boot module BOOT_xxx, which is a device-specific loader. The kernel initializes using parameters set in the INIT module, and calls the BOOT_xxx module to read the OS9BOOT file (what I called the boot track above, "boot file" is maybe better). So the poor newborn kernel needs the boot module in order to find and load the boot file.

I don't know what was the original reasoning here, but I guess it is advantageous that as much as possible is read into memory the proper OS9 way and that the boot loader is kept as simple as possible (to fit in DOS). And the boot file can be generated quite simply from a running OS-9 system, and that anything special like the kernel track can be kept as small as possible on the system floppy. Otherwise one could think that it could make sense for the bootloader to read kernel and boot file into memory already, and just let the kernel discover the modules now already in RAM. Then there would be no reason for the boot module. This is what Brett's CoCoBoot is doing.

Anyway, as you probably have seen in the NitrOS-9 source, the DriveWire boot module is also quite simple.
bluearcus
Posts: 142
Joined: Wed Sep 07, 2016 4:45 pm

Re: Nitr-OS9 vs OS-9

Post by bluearcus »

Haven't got it working yet.

Drivewire seems to be alive during the boot process (after a Dragon boot header'd boot track on the Tandy track 34 area has been loaded and executed). That makes me think everything's OK upto that point.

Sadly though, Os9 doesn't then come up. I wonder if the device drivers are doing something that original Level 1 doesn't like.

Next step. Remove the drivewire elements in OS9Boot and bring up a non RBF dependent version to make sure the load process is all OK. If it is then I might have to start looking at gdb. Oh Lordy.
Post Reply