Additional Hbios Code Space

[stickbreaker]

@wwarthen
I saw you mention additional code space to support CPM3, How hard is it to use this feature for CP/M2.2?

I am working up multiple SPI device drivers and bumping against the HBIOS code sizes.

what I am thinking about would be some switched pages/frames, with RomWBW's 32KB lower page, and the Z180 1MB memory map, I would like to have an approved framework that uses an arbitrary 32K ROM/RAM bank. This 32k page would have support code to handle HBIOS calls and data buffer exchanges. I am working with a 4x20 LCD, 4x4 matrix switch pad they both need code and data storage to function. so, a 32k Ram bank with code and data that can make HBIOS calls(SPI driver access).

What i want is to be able to write CP/M app code that uses these devices:

// untested code, probably won't compile :<
//pascal
WriteLCD("hello There");
//

type
STR32 : String[32];

var
  DEVICE : byte; {LCD DEVICE ID}

Procedure WriteLCD( text:STR32);  // HBIOS code interface
begin
inline (
 {
      LD HL, (text) 
      push HL
      LD B,(HL)
      INC B
      LD C,(DEVICE)
      PUSH BC
L1:  POP BC
      DEC B
      JR Z, L2   
      POP HL
      INC HL
      PUSH HL
      PUSH BC
      LD E,(HL)  ;character
      LD B,1    ; CIO write
      CALL $FFF0
      XOR A
      JR Z, L1
      POP BC
L2:  POP HL
);
end;

Challanges

• One of the big issues I am considering is how/when to allocate a 32k Bank of Ram for Driver code/storage and share this page with multiple device drivers, I would like to have the equivalent to CMOS setup to select devices.
• How to link these drivers into HBIOS at boot without recompiling
• Have the drivers in a section of ROM, this list of Drivers is data for CMOS setup and installation
• Document a Format for Code Fixup tables to allow relocatable Z80 driver code
• Implement Fixup code during boot
• Implement Fixup table generation

Chuck.

[wwarthen]

Hi @stickbreaker,

HBIOS space limitations have indeed become a huge problem. I'm not sure I am following your proposal entirely, but will answer the best I can.

I saw you mention additional code space to support CPM3, How hard is it to use this feature for CP/M2.2?

Well, there is a reserved bank referred to as AUX in HBIOS. This is the bank used by CP/M 3 and ZPM3 for it's additional bank of code. This bank is generally available for CP/M 2.2 (and derivatives). However, CP/M 2.2 has no concept of banked memory, so it would need to be added in some way by you. It would not be hard for an application to stuff code in that bank and invoke it using HBIOS. It would be extremely difficult to extend CP/M 2.2 into a multi-bank OS. Since that is what CP/M 3 is, I am not sure why yo would want to.

I am working up multiple SPI device drivers and bumping against the HBIOS code sizes.

I'm sure you are! 😊

what I am thinking about would be some switched pages/frames, with RomWBW's 32KB lower page, and the Z180 1MB memory map, I would like to have an approved framework that uses an arbitrary 32K ROM/RAM bank. This 32k page would have support code to handle HBIOS calls and data buffer exchanges. I am working with a 4x20 LCD, 4x4 matrix switch pad they both need code and data storage to function. so, a 32k Ram bank with code and data that can make HBIOS calls(SPI driver access).

There are a lot of words here that I am not quite following. If you are asking about using additional RAM banks as an area to store/grow HBIOS drivers, then there are severe issues to work around. HBIOS was never intended to do that. As an example, the current HBIOS bank contains both the code and data for HBIOS. If drivers are placed in a different bank, you could potentially dispatch there, but they would have no access to critical variables in the stantard HBIOS bank.

What i want is to be able to write CP/M app code that uses these devices:

So, to be clear, applications are very different than HBIOS drivers. There is an existing HBIOS API that allows applications to determine available RAM banks. An application can put code there and such code can make normal HBIOS calls. However, an SPI driver that is to be available to all applications must be written as an HBIOS driver and would not be easy to place in a RAM bank other than the single standard HBIOS bank. Your example seems more like an application calling HBIOS which can be done from any RAM bank.

• One of the big issues I am considering is how/when to allocate a 32k Bank of Ram for Driver code/storage and share this page with multiple device drivers, I would like to have the equivalent to CMOS setup to select devices.

This is so far beyond the scope of the current HBIOS that I can't begin to provide any guidance.

• How to link these drivers into HBIOS at boot without recompiling

Likewise, dynamic linking of HBIOS drivers is completely outside of HBIOS capabilities. This would require a ground-up rewrite of HBIOS.

• Have the drivers in a section of ROM, this list of Drivers is data for CMOS setup and installation

If you could find a way to place drivers in an alternate bank, then I suppose you could place them in ROM as well. You need to solve the dynamic linking and multiple HBIOS code banks issues first.

• Document a Format for Code Fixup tables to allow relocatable Z80 driver code
• Implement Fixup code during boot
• Implement Fixup table generation

Same answer as dynamic linking above.

I apologize if I sound negative, but I literally do not know how to help you achieve your goals. Even if you seriously attempted the kind of rewrite needed, you would be dramatically increasing the complexity of RomWBW. The existing complexity of RomWBW is the most common complaint I have from hobbyists. The features are loved, but many casual hobbyists are overwhelmed by the current complexity. Frankly, so am I.

Thanks, Waynbe

[stickbreaker]

@wwarthen Well, I'll have to do some more deep dives and get a better understanding of how the CIO and DIO devices are dispatched.

It is my current understanding that ROM disk and RAM disk sizes are set during compile time, so no runtime discovery or allocation changes.

So, to be clear, applications are very different than HBIOS drivers. There is an existing HBIOS API that allows applications to determine available RAM banks. An application can put code there and such code can make normal HBIOS calls.

Can these banks be permanently allocated(not released after APP end)?
I can only find this function:

8.9.3 Function 0xF2 – System Set Bank (SYSSETBNK

That just gave me another idea, Load my drivers into this application bank above the HBIOS in Hierarchy.
Just call direct into this bank from my app,

• Can I just DI(disable Interrupts)/EI if i need to have a private stack,
• Can interrupts be serviced while executing code in this alternate page?

However, an SPI driver that is to be available to all applications must be written as an HBIOS driver and would not be easy to place in a RAM bank other than the single standard HBIOS bank. Your example seems more like an application calling HBIOS which can be done from any RAM bank.

I can see that, One of my problems is that i want to add additional storage devices that are visible as HBIOS/CP/M devices.

Thanks for the feed back
Chuck.

[wwarthen]

Hi @stickbreaker,

So, to be clear, applications are very different than HBIOS drivers. There is an existing HBIOS API that allows applications to determine available RAM banks. An application can put code there and such code can make normal HBIOS calls.

Can these banks be permanently allocated(not released after APP end)? I can only find this function:

8.9.3 Function 0xF2 – System Set Bank (SYSSETBNK

The bank layout is determined at build time. There is no mechanism to allocate a bank and keep it allocated permanently. The function you have listed is to map a physical bank to the bank area of the CPU. It does not allocate banks, just chooses which bank is currently mapped to the low 32K of CPU address space.

That just gave me another idea, Load my drivers into this application bank above the HBIOS in Hierarchy. Just call direct into this bank from my app,

• Can I just DI(disable Interrupts)/EI if i need to have a private stack,

Yes, but you want to minimize the time spent with interrupts disabled because you can miss clock ticks, etc. Also, if you make HBIOS calls from this bank, HBIOS may turn interrupts back on. HBIOS does not maintain the state of interrupts.

• Can interrupts be serviced while executing code in this alternate page?

In theory, yes. When an interrupt fires, the interrupt handler in high memory will set up a private stack in high memory to sue while servicing the interrupt. The interrupt will be dispatched to the main HBIOS bank and, when done, will restore the original stack and low memory bank.

However, an SPI driver that is to be available to all applications must be written as an HBIOS driver and would not be easy to place in a RAM bank other than the single standard HBIOS bank. Your example seems more like an application calling HBIOS which can be done from any RAM bank.

I can see that, One of my problems is that i want to add additional storage devices that are visible as HBIOS/CP/M devices.

Yup, that is a big problem. It is one I would also like to solve, but I have not thought of any straightforward solution yet.

Thanks, Wayne