[Coco] NitrOS9 question

L. Curtis Boyle curtisboyle at sasktel.net
Fri Oct 6 13:37:30 EDT 2017


Hmm… the only locations and code that should be hard coded for memory position is the kernel (boot) track - which REL, BOOT and whatever they call OS9p1 these days (krnp1?) - that has to fit in the highest 8K block in the memory map, and the vector page RAM portion of that ($FE00-$FEFF *has* to map there, to stay mapped in at all times to handle IRQ’s, system calls, task switching, etc.). If your REL/BOOT/KRNP1 doesn’t work out to exactly $1200 bytes (4608 bytes), then REL would need to be patched to copy the boot track with the proper offset to make sure the vector page RAM code is exactly lined up, since all IRQ’s vector through hard coded addresses in this page. (It’s why you will notice that we padded those 3 modules, if necessary, to always be the exact same size).
The rest of the files (OS9Boot itself), shouldn’t matter, unless you hit the BLOB (which if I remember is related to the floppy controller, so it may not apply anymore… I seem to recall that Kevin Darling, etc. figured out how to avoid it, and not just with forcing modules in a certain order).

L. Curtis Boyle
curtisboyle at sasktel.net

TRS-80 Color Computer Games website
http://www.lcurtisboyle.com/nitros9/coco_game_list.html



> On Oct 6, 2017, at 7:37 AM, Bill Pierce via Coco <coco at maltedmedia.com> wrote:
> 
> Dave, I seem to remember an issue a while back where it was found that the bootfile had to be at least a certain size (Aaron just confirmed this). I don't remember how big, but I think it's due to how some modules set up the data areas and some HAVE to fall on 256 page boundaries. And when you get near the 8k/16k boundary, if a module breaks across that boundary, it will fail. Also, certain tables are expected to be in exact locations.
> It's not so much the boot order bug, but just the way it works. I'm not sure this is what's happening in your case as you're using the ccbkrn which throws a wrench in the works as we're removing main modules. I'm not saying this is a bad thing, Brett did a good job with this (and Boisy) and it works.
> 
> As for term_6551 VS T2... it looks to me that OS9 needs to know screen restraints (#cols, #rows, cntr codes, etc) which is set with the term, regardless of whether the screen is on the Coco or a remote, it's still under OS9 control. T2 provides no such info, term_6551 does. This is why all the headless boots use the term_xx for what ever type of system is used (6551, dw4, etc). I may be wrong here, but that's the way it looks to me.
> 
> Oh, and the systype reference... the "levelx/defs/defsfile.asm" you mentioned is NOT used to build the NitrOS9 modules. That file is in place to be copied to the distro disks for backwards compatibilities. It's not part of the current build process. The defs are defined in "levelx/defsfile" in the root dir of each system build. The defs used in the build process are in the root/defs dir (os9.d, scf.d, rbf.d, cocovtio.d, coco.d, etc), not the defs in each system dir. There's a lot of stuff in this area that seems to have never been updated to match current convention and really needs some work (maybe soon). The name changes to the defs files throw a wrench in everything once you actually move to OS9 and try to use the repo disks without renaming the defs back to the old names. I was working on fixing this stuff when I got sidetracked into a bunch of recording (real life, who needs it?). I hope to get a break soon so I can finish all the patches I started (fixing a bunch of things), which will bring a lot of things like this back in order.
> 
> 
> 
> 
> 
> 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
> 
> 
> 
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
> 



More information about the Coco mailing list