Question regarding Driver IO port mapping convention about romwbw

[wwarthen]

First of all, I'm sorry this change impacted you. I should have notified you when I did it.

Originally, when the world was simpler, all drivers had a simple "ENABLE" config along with a "MODE" setting and that was it. The MODE setting encompassed everything required to conditionally build the driver for the target hardware.

Over time, the variety of hardware grew beyond my wildest expectations. So, some drivers have been reworked to support almost total flexibility for ports, etc. A good example of this is the SIO driver.

In my mind, the downside to the more flexible drivers is the complexity in the config files. For an average user, it is painful, if not impossible, to configure the SIO driver (take a look at the number of config settings for that driver). The older model of just using a MODE setting is simple, easy to understand, and less error prone.

So, in the end, my rule is that drivers use the MODE setting until/unless there is a strong need to make it super flexible.

In the case of the TMS driver, I'm not ready to make it more complex even though it would not be hard to do. My preference would be to add an additional "MODE" to support the ColecoVision standard ports. I almost did this when I made the change, but sort of felt like the ColecoVision ports were problematic due to conflicts with the Z180 register mapping. I do see there is some logic to doing this because J.B. has used the ColecoVision ports for his sample apps (I think).

I am completely open to adding a new MODE to the TMS driver for the ColecoVision ports.

Thoughts?

-Wayne

[vipoo]

I am still learning much of the architecture/modelling you have built into HBIOS. Your reply helps me understand objective better - thanks.

I had noticed the SIO did seem to allow a change of base port via config - and I see how there is added complexity in the driver - yet the config file is simple: SIOnBASE to map the port.

The h/w configuration of my unit is a mixture of coleco and MSX. I have it running on the normal int - (NOT NMI, as this seem to produce lots of PANICS)

I guess running CP/M apps with NMI interrupts is not typically recommended - and because its not possible to disable, when bank switching things can go haywire. Unless there is some trick i am not aware of?

As i was hacking - loading up colecovision roms was cool - but i also wanted to play with coding the chip - so i needed to flip back and forth the interrupt. I've started to wonder if I could tweak of the hardware design, and build a version that would allow me to flip the interrupt line thru an IO port.

I had wondered if it be possible, rather than a coleco mode - have a usr mode - so something like this in the driver:

#IF (TMSMODE == TMSMODE_USR)
TMS_DATREG	.EQU	TMS_USRDATREG
TMS_CMDREG	.EQU	TMS_USRCMDREG

TMS_PPIA	.EQU	TMS_USRPPIA
TMS_PPIB	.EQU	TMS_USRPPIB
TMS_PPIC	.EQU	TMS_USRPPIC
TMS_PPIX	.EQU	TMS_USRPPIX
#ENDIF

And then in my configuration, something like:

TMSMODE 	.SET	TMSMODE_USR
TMS_USRDATREG	.EQU	$BE
TMS_USRCMDREG	.EQU	$BF
TMS_USRPPIA	.EQU	0
TMS_USRPPIB	.EQU	0
TMS_USRPPIC	.EQU	0
TMS_USRPPIX	.EQU	0

But this is not a big deal - i can certainly manage with local patch files.

So quite happy to leave as is.

Cheers
Dean

[wwarthen]

I am completely fine with the idea of TMSMODE_USR. That way, the average user does not need to worry about any added complexity.

I know it seems trivial to specify a couple of ports. But keep in mind, probably half of the RomWBW users don't know what a port is... :-)

NMI is evil. It cannot be masked and will always lead to system corruption in a system like RomWBW. It is only useful in very simplistic environments. It is totally unacceptable in a bank switched world. In theory, it could be used within RomWBW if you launch an app and the app never makes BDOS or HBIOS calls, hooks NMI when it starts, and restores it before exiting.

Sure, a hardware mod with a simple latched port could be used to control the I/O ports on the fly. I am not very familiar with the ColecoVision and MSX world. Are you actually running legacy ColecoVision and MSX code?

Thanks,

Wayne

[vipoo]

I have been able to get ColecoVision roms working - following J.B. examples. I have not done the MSX stuff - because the required the z80ctrl which i dont have.

I got the demo cpm apps working - but they mess with interrupts hooks - and for me at least, dont exit cleanly - i am in the process of seeing if I can refactor them to work with hbios correctly.

For example, get the port config from HBIOS, instead of having its own hardcode port numbers.

One of the challenges is interrupt handling - one of the apps wants to sync up with the vsync interrupt. The way it does it at the moment, it just overwrite the INT vector, disabling HBIOS' use of interrupts. And it never cleans up.

So i trying to figure out ways to do that at application level.

[wwarthen]

I got the demo cpm apps working - but they mess with interrupts hooks - and for me at least, dont exit cleanly - i am in the process of seeing if I can refactor them to work with hbios correctly.

For example, get the port config from HBIOS, instead of having its own hardcode port numbers.

That makes sense.

One of the challenges is interrupt handling - one of the apps wants to sync up with the vsync interrupt. The way it does it at the moment, it just overwrite the INT vector, disabling HBIOS' use of interrupts. And it never cleans up.

So i trying to figure out ways to do that at application level.

If it is using INT (and not NMI), there is an HBIOS API to install and remove an INT hook. See the INTTEST app.

[vipoo]

If it is using INT (and not NMI), there is an HBIOS API to install and remove an INT hook. See the INTTEST app.

I have started down the path. But in intercepting the int for the TMS chip, I will effectively disable the HBIOS TMS handler running - so it wont get the interrupt.

I am not sure there is an existing mechanism to 'hook' into the interrupt chain - without 'disabling' the hbios handler.

I will do some 'hacking' and see what happens.

Dean.

[wwarthen]

When you use the INT API to hook an interrupt, your handler decides whether to handle the interrupt and return or pass control to the next handler in the chain. However, your handler could just "monitor" the interrupts and always pass control to the next handler just like you would if you didn't handle it.

Alternatively, you can always hook the interrupt at 0xFF00. HBIOS sets things up so that an IM1 interrupt always just does a JP to 0xFF00. HBIOS sets up it's bank and the TPA bank so that an interrupt can occur in either bank and the JP to 0xFF00 will occur.

[vipoo]

I guess we should close this issue