The NABU-LIB C Library is designed for the Nabu not the Retro.
With this statement declared early on, lets have a look at what is possible to port and what simply won't work on the Retro.
| Hardware | Status | Comments |
|---|---|---|
| PSG | NOT COMPATIBLE | The Retro has no PSG. |
| VDP | COMPATIBLE | Interrupts might need some work. |
| Joystick | NOT COMPATIBLE | The NABU Joysticks are driven by a driver IC on the keyboard and present as ASCII on the keyboard IO Port. |
| Keyboard | NOT COMPATIBLE | The Retro does not have a keyboard. |
| HCCA | NOT COMPATIBLE | The Retro does not have an HCCA although something similar is in the works. |
| Interrupts | PART COMPATIBLE | The Retro has no interrupt service routines defined. It would need to provide ISR support. |
| ROM Control | UNKNOWN | There is an IO register on the NABU that allows to disable ROM. |
We can look for some basic supported functionality by implimenting library functions for the VDP and Joysticks as the Retro does have both of these available.
The retro does not currently use interrupts in the BIOS and CP/M. This means we can use them in the Retro port of NABU-LIB.
side note: The more I think about this, the more I think we just need our own library. Porting might not cover what we need to do here.
Besides the VSYNC interrupt which would need to be dealt with in tandem with the work required to impliment interrupts, the rest of the functions are straightforward to impliment.
The NABU joystick library will need to be rewritten to support the Retro IO layout which is a trival excersize.
Without a Keyboard it could be quite difficult to port games from one system to the other. If that's the goal of this system, we "could" engage in some kind of serial interface hackery, but that would be less than ideal. Games that rely on keyboard input usually require low level / low lag input response.
Suggestion here is to determine the purpose of the library port and understand what we want to do with it. Ultimately our choices are limited.
- Support keybaord input via Serial.
- Support user input via Joystick only.
- Some kind of hybrid solution.
The NABU has a fully functioning network access to storage solution which appears to be provided by NABU-LIB. I haven't used it so don't know how it works specifically. If the Retro CPM environment is being upgraded to support DISK over Network capability (HCAP) then I "guess" this is something we can do.
The Retro has a filesystem! So we just need to impliment something that lets CP/M take care of file IO.
NABU-LIB has this snippet in its init function:
// Turn off the rom
IO_CONTROL = CONTROL_ROMSEL | CONTROL_VDOBUF;According to the NABU Technical Manual this to say about it:
ROM
A 4K byte ROM (Read Only Memory) contains the bootstrap software. Upon
reset, this software performs a minimal self test on the processor board and initializes the system. It also contains software which can communicate with the HC.CA or a floppy disk to allow for bootstrapping.
The ROM may be selected or deselected under software control. When selected, any memory read request to addresses 0000 - OFFF hex will be directed to the ROM; write requests to these addresses will go to RAM.
I "assume" this means that we can dynamically disable the rom and re-enable it later or it's automatically re-enabled during a warm boot. The concept of Warm Boot in NABU is only applicable to CP/M. Everything else in Nabu Land appears to require a reset. (happy to be corrected on this point.)