Retrieving hardware configuration information about romwbw

[wwarthen]

Hi Dean,

Hope all is well.

Doing fine. Hope you are as well.

I am trying to catchup with where we at with the ability to retrieve hardware configuration stuff. I am not sure i remember which approach you decieded to go with.

Yes, has been a little confusing. I will answer all the questions below, but let me start with a quick summary. Two things have been done to attempt to address hardware information.

First, the XXX_DEVICE functions in each driver type now return information in HL. The H register will return the "MODE" configuration setting of the unit and the L register will return the base I/O port address. For either H or L, zero is returned if the unit has no concept for that value. This data is intended to be the quick and simple way to access unit information.

Second, a new set of SYSGET functions have been added SYSGET_XXXFN. These are "out of band" functions that return a specific unit's function table address and the address of the unit's internal config/status table entry. The config/status table entry is entirely driver specific, so the caller must be aware of that. These functions allow two things: 1) a way to bypass some of the HBIOS function dispatching overhead, and 2) access to the full set of internal driver data.

I freely acknowledge that both of these require some knowledge of the driver being used and will likely change in the future. The _DEVICE extension is a bit less likely to change, but it also far less capable.

I would like to be able to access some hardware attributes. I had a look at the code and docs. And observed the following:

a. The TMS ports. I see code for the BF_VDAQRY function, returing the TMS_DATREG. It only returns one port - I guess the assumption other ports are assume to be incremented from this.

I assume you actually mean the BF_VDADEV function. This is the "DEVICE" function for VDA devices. In this case, I think the data register is the base I/O address since it is consistently the lowest address of the pair used.

b. The SN76489 has a new function SN7_DEVICE - which returns the SN76489_PORT_LEFT. It does not return the right port number.

Yes, this driver is messy because it is hard to pin down the exact concept of a base I/O address. I arbitrarily chose the left port because it seemed most natural. In the case of this driver, I think it really needs a config/status table created that has entries for left and right so the SNDFN function can be used. Alternatively, at this point, the right channel port can be assumed to be 4 less than the left. I admit that does not feel like a great solution, so I think implementing the config/status table for that driver would be good.

c. The AY driver has a similiar configuration.

Yup, and in the case of the AY driver the situation is ever worse because of the different possible combinations of left and right channel ports. In this case, a mode value exists which can be used to figure things out, but, like above, a config/status table would be a welcome addition to the driver.

d. The sound drivers also have a sub-function BF_SNDQUERY, that allows for the retriving of all io ports.

Yes, and while that is inconsistent with the other driver categories, I think it is fine. Most of the driver categories have a query function of some kind. It returns configuration information that makes sense for the type of driver. For example, the character drivers use it to return serial line characteristics.

e. I see a new functions (VDAFN, SNDFN and similiar others for other devices)
These seem to return an address in DE for driver specific config. The Sound drivers are returning 0 and the TMS driver is returing the TMS_PPIx entries - but nothing else.

I hope I have explained that in my preface comments. Let me know if I need to expand on my explanation.

I may not have interpreted this right, and it may also be still under-development, so my questions below may be jumping the gun a bit:

1. Is the expectation that all drivers will return key attributes through the xxxFN functions? With the other access methods deprecated?

Yes, the _XXXFN functions are intended to return the address of the config/status data of the specific unit. In a perfect world, all drivers would keep all status/config data in this data block. For performance reasons, this may not be a reasonable goal in all cases. In the case of the sound drivers, I think they should have a config/status data block implemented even though it is just static data.

I wasn't planning to deprecate anything else. The new _XXXFN functions are hard to use and require intimate knowledge of the driver and subject to constant change. The XXX_DEVICE and _VDAQRY are much easier to use and a little less prone to impact from driver changes. I don't feel compelled to remove them, but I do want to be very judicious about creating more mechanisms to return config information.

2. Should the TMS driver's data table also include TMS_DATREG and TMS_CMDREG

Yes, it should. However, be careful. The current data table is used to define the PPI addresses for the PPI keyboard interface.

3. The TMS driver also has a mirror of the internal registers TMS_INIT9918. It be nice to be able to read this also, so that i can determine if the interrupt line has been enabled or not. To avoid disabling that.

That information could be moved into the config/data table of the driver.

4. Can the Sound drivers implement this fully to not only return the IO ports, but also clock frequency?

Can and probably should.

I am happy to help do some of the coding here - if this is what you want.

I am happy to have you do it! I would only ask that you quickly check with me on anything that extends or changes the current functions or conventions first. :-) Also, keep an eye on code size increases -- I am getting increasing more concerned about that.

I have been playing with my fork of bbcbasic, and got it doing plotting lines and pixels through the TMS chip. It be nice to able to retrieve the IO ports from HBIOS, instead of having it hard-coded in the assembly. It be also nice to get information that would enable me to inject the right level of wait states for IO access.

I strongly agree. That is exactly what I did with the experimental version of XModem. That has worked out beautifully.

The bbcbasic fork also uses the sound driver interface to enable full sound capability.

Excellent!

[vipoo]

Cool,

Sounds like I have something to work on this weekend - its a long weekend here - would you believe my country celebrate a Queens Birthdays this weekend?

I would like to extend the _XXXFN - for the TMS and sound drivers.

I hear you in regards to footprint size - I will look for any easy optimsations. I dont think what i need to add will have much impact.

For my hbios build, I seem to be well within the memory limits - so is there a specific config that is showing its close to the limit? - how do we know if we are using too much memory?

Cheers
Dean

[wwarthen]

Sorry for the delay getting back to you. I have had some distractions here.

Sounds like I have something to work on this weekend - its a long weekend here - would you believe my country celebrate a Queens Birthdays this weekend?

Nice. Have a great weekend!

I would like to extend the _XXXFN - for the TMS and sound drivers.

Great, thanks.

I hear you in regards to footprint size - I will look for any easy optimsations. I dont think what i need to add will have much impact.

Agreed. Should not be an issue.

For my hbios build, I seem to be well within the memory limits - so is there a specific config that is showing its close to the limit? - how do we know if we are using too much memory?

I have an ECB system with 12 slots that I use to test a maxed out setup. I have noticed that it can get within a few thousand bytes of filling the 32K HBIOS bank.

However, rather than using my Frankenstein system as a metric, I have instead created a configuration called SBC_max. It does not have every feature possible enabled, but most features are included. It would be surprising for someone to use all of the features in this "max" configuration, but I think it works as an early warning system that we are getting in trouble. At present, the max configuration has 2300 bytes free.

Although this is not a legitimate real system configuration, it still worries me that we are that close to the limit. I am guilty of not worrying about sizes in the past. When HBIOS begain, 32K seemed like a huge amount of space. There are many places where space could be recovered in the current code base, just a matter of time and effort.

Thanks,

Wayne

[wwarthen]

I'm going to close this issue. As far as I can tell, it is resolved. If not, please reopen it.

Thanks,

Wayne