Hello,
after closing the thread about OS9L2 due to technical problems, I am opening this new thread so that we can comment the steps we have to
do to get a Dragonized version of the CoCo2 port of NitrOS-9 Level 2 done by John Federico
cheers!
NitrOS-9 Level 2 for the D64 with iMMUnity module
Re: NitrOS-9 Level 2 for the D64 with iMMUnity module
This is a copy of a message sent to me by John Federico
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I asked Claude about the Dragon differences and this is what I got back:
The port is built for a CoCo 1/2 and hasn't been tried on a Dragon.
A Dragon version looks very doable, though, because the two machines share the core chips that matter most for this port, and
NitrOS-9 already has Dragon drivers.
What is the same:
- The core chips: the 6809 CPU, the 6883 SAM memory/video address chip, the 6847 VDG, and the two 6821 PIAs at the same addresses ($FF00, $FF20).
Dragon Data designed the machine from the same Motorola
reference design as Tandy.
- Video: text and PMODE graphics through the SAM. The parts of our port that are hardest, the VDG screens in motherboard blocks,
the SAM programming and the graphics window, should carry over largely
unchanged.
- The clock: the VSYNC interrupt on PIA0 is the same idea. Dragons are PAL, so it ticks at 50Hz.
The recipe already has a PwrLnFrq=50 option, though it's never been tested.
What's different:
- Keyboard: the Dragon wires its keyboard matrix differently. NitrOS-9's Level 1 VTIO already translates
Dragon key scans to the CoCo layout (DragonToCoCo in level1/modules/vtio.asm).
The Level 2 VTIO we use has no such translation, so that would need adding.
- Floppy controller: DragonDOS uses a different controller interface, so the CoCo floppy driver (rb1773) won't work.
NitrOS-9 has Dragon versions in its Level 1 Dragon 64 port: ddisk.asm and boot_d64.asm.
- Booting: a Dragon boots with DragonDOSs BOOT command, which loads from a different place on disk than the CoCo's DOS command.
Our boot-track layout and the size-constrained boot module (rel.asm) assume the CoCo method, so this needs reworking.
The Dragon 64 ports boot_d64.asm and os9gen_d64 are the references.
- CoCo SDC: a CoCo cartridge, so the SDC image is CoCo-only.
A Dragon would boot from floppy, or from whatever storage interface Dragon owners use.
- Other ports:
- The Dragon 64 has a built-in 6551 serial port, and the 64 and 32 have a parallel printer port where the CoCo has a bit-banger serial port.
- NitrOS-9 has Dragon drivers for both (sc6551dragon, scdpp).
- The Dragon 64 also has ROM/RAM switching that a Level 2 port would have to account for.
- ROMs and reset: reboot and RESET return to BASIC through the ROMs reset vector.
The mechanism is the same on a Dragon, but it would need checking against the Dragon ROMs.
- The board itself: I do not know whether the i-MMU-nity physically fits or is electrically supported in a Dragon.
That is a question for Jim Brain. YES, IT IS SUPPORTED
How much work: probably a new recipe plus Dragon versions of the keyboard handling, disk driver, boot module and boot-track tools,
largely by reusing the existing Dragon 64 Level 1 code. The kernel changes,
CoVDG and the clock should carry over.
One caveat: the Dragon port currently has no working build recipe in the tree
(the supported-ports page says some ports lack current recipes), so its drivers may need some updating.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
cheers!
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I asked Claude about the Dragon differences and this is what I got back:
The port is built for a CoCo 1/2 and hasn't been tried on a Dragon.
A Dragon version looks very doable, though, because the two machines share the core chips that matter most for this port, and
NitrOS-9 already has Dragon drivers.
What is the same:
- The core chips: the 6809 CPU, the 6883 SAM memory/video address chip, the 6847 VDG, and the two 6821 PIAs at the same addresses ($FF00, $FF20).
Dragon Data designed the machine from the same Motorola
reference design as Tandy.
- Video: text and PMODE graphics through the SAM. The parts of our port that are hardest, the VDG screens in motherboard blocks,
the SAM programming and the graphics window, should carry over largely
unchanged.
- The clock: the VSYNC interrupt on PIA0 is the same idea. Dragons are PAL, so it ticks at 50Hz.
The recipe already has a PwrLnFrq=50 option, though it's never been tested.
What's different:
- Keyboard: the Dragon wires its keyboard matrix differently. NitrOS-9's Level 1 VTIO already translates
Dragon key scans to the CoCo layout (DragonToCoCo in level1/modules/vtio.asm).
The Level 2 VTIO we use has no such translation, so that would need adding.
- Floppy controller: DragonDOS uses a different controller interface, so the CoCo floppy driver (rb1773) won't work.
NitrOS-9 has Dragon versions in its Level 1 Dragon 64 port: ddisk.asm and boot_d64.asm.
- Booting: a Dragon boots with DragonDOSs BOOT command, which loads from a different place on disk than the CoCo's DOS command.
Our boot-track layout and the size-constrained boot module (rel.asm) assume the CoCo method, so this needs reworking.
The Dragon 64 ports boot_d64.asm and os9gen_d64 are the references.
- CoCo SDC: a CoCo cartridge, so the SDC image is CoCo-only.
A Dragon would boot from floppy, or from whatever storage interface Dragon owners use.
- Other ports:
- The Dragon 64 has a built-in 6551 serial port, and the 64 and 32 have a parallel printer port where the CoCo has a bit-banger serial port.
- NitrOS-9 has Dragon drivers for both (sc6551dragon, scdpp).
- The Dragon 64 also has ROM/RAM switching that a Level 2 port would have to account for.
- ROMs and reset: reboot and RESET return to BASIC through the ROMs reset vector.
The mechanism is the same on a Dragon, but it would need checking against the Dragon ROMs.
- The board itself: I do not know whether the i-MMU-nity physically fits or is electrically supported in a Dragon.
That is a question for Jim Brain. YES, IT IS SUPPORTED
How much work: probably a new recipe plus Dragon versions of the keyboard handling, disk driver, boot module and boot-track tools,
largely by reusing the existing Dragon 64 Level 1 code. The kernel changes,
CoVDG and the clock should carry over.
One caveat: the Dragon port currently has no working build recipe in the tree
(the supported-ports page says some ports lack current recipes), so its drivers may need some updating.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
cheers!
Re: NitrOS-9 Level 2 for the D64 with iMMUnity module
Well, degrees of rightitude there.
Edit: FYI I've pushed out a snapshot build of XRoar that includes John Federico's small - but presumably important! - iMMUnity code fix. Something to do with a 256-byte window vs a 512-byte one. I've not really tried to understand it, but Jim reckons it's the right fix anyway
Edit: FYI I've pushed out a snapshot build of XRoar that includes John Federico's small - but presumably important! - iMMUnity code fix. Something to do with a 256-byte window vs a 512-byte one. I've not really tried to understand it, but Jim reckons it's the right fix anyway
Re: NitrOS-9 Level 2 for the D64 with iMMUnity module
Hi Ciaran,sixxie wrote: ↑Tue Oct 13, 2026 7:31 pm Well, degrees of rightitude there.
Edit: FYI I've pushed out a snapshot build of XRoar that includes John Federico's small - but presumably important! - iMMUnity code fix. Something to do with a 256-byte window vs a 512-byte one. I've not really tried to understand it, but Jim reckons it's the right fix anyway
thanks for telling me you have pushed that snapshot. John told me that there were a few changes for XRoar as result of his tests
cheers!
pere
Re: NitrOS-9 Level 2 for the D64 with iMMUnity module
Having the emulator represent the HW is always important, but the issue was pretty minor and would have shown in only 1 use case.sixxie wrote: ↑Tue Oct 13, 2026 7:31 pm Well, degrees of rightitude there.
Edit: FYI I've pushed out a snapshot build of XRoar that includes John Federico's small - but presumably important! - iMMUnity code fix. Something to do with a 256-byte window vs a 512-byte one. I've not really tried to understand it, but Jim reckons it's the right fix anyway
The issue:
With the GIME, you can access RAM under the IO space, by mapping block $3f into a slot other than slot 7. I haven't looked at the GIME logic, but I assume GIME checks for accesses to $ffxx and overrides the RAM mapping to provide GIME registers, IO, etc.
With the SAM, there is no MMU, and little way to remap things. There is a bit in SAM that will make The upper 32kB viewable in the lower 32kB, I think, which could allow access to the uppermost page of RAM. But, this behavior does not match the MMU register behavior, so it's not used.
What's done instead is to put in a special check for the following condition. If the MMU is enabled, the CPU address[15:13] != 111, the motherboard RAM is being accessed, and the motherboard address[15:13] == 111, we redirect the read or write to internal iMMUnity RAM.
The emulator code, for some reason I cannot remember, was also using internal RAM for the next to uppermost page of RAM ($fexx) But, in all RAM mode on the SAM/VDG, that's RAM, so there is no need to fill in a hole with internal RAM. The update removes this check.
The only time this would be an issue is if someone put a VDG screen such that $fexx was pulled for video data. In this case, without the update XRoar would push the data to iMMUnity RAM, which the VDG cannot see, and thus the screen would look weird.
Jim