Page 1 of 1

QubATA 3.10 I/O area address

Posted: Tue Nov 07, 2017 11:43 pm
by Pr0f
A question on the QubATA driver:

Is it possible to have the ROM loaded at one address range, and the hardware address as described by the GAL's at another address? I see in the driver it looks like it's coded for 0C000, but I am guessing the driver code itself is relocatable. Does the address represent the bottom of the 16K address range that expects to see the multiple 16 addresses of the IDE registers at that the last 256 bytes of that 16K block - as they would be on a QubIDE card for instance?

Can it be changed so that the actual address of the I/O block is provided and can be different from the ROM location?

Re: QubATA 3.10 I/O area address

Posted: Wed Nov 08, 2017 8:03 am
by tofro
Technically, everything is possible on a QL ;)

The question is: what is it good for? The QL's memory map is laid out in the expectation that each expansion board is allocated one (or more - but apart from very specific cards like the SuperGold Card, I don't know any that do) 16k address slots for ROM and I/O addresses. What you propose would allocate more than one slot and waste address resources.

I don't know the QubIDE hardware, neither do I have specific insights into the driver, but would expect there is only one address decoder for the slot base address that is used both for memory and I/O, configured by jumpers - Your approach would need two of them, so most probably couldn't be done with the hardware as-is. I would also expect the code to assume the I/O addresses in the same slot it lives in, addressing them using PC-relative addressing (The code cannot assume a specific load address, but it can assume a fixed offset between ROM and I/O in the QL memory map design - An assumption you'd make invalid).

So, very probably, without major changes to hardware and code, you wouldn't be able to do that. I'm also not seeing any benefits other than wasting yet another memory slot that would then no longer be available for a Trump card, for example. There is no way to re-use the then partially occupied address slots for anything else.


Re: QubATA 3.10 I/O area address

Posted: Wed Nov 08, 2017 10:06 am
by Pr0f
The project in question is to integrate a qubide into a black box QL 'clone'. It's a one off experiment, but I plan to use some part of the largely undecoded QL expansion area between 18000- and 1c000, as 'technically' the I/O is internal, and let's face it - Sinclair are not going to be using any of that address space for new features this late in the game. The ROM portion of the Interface was going to be made available at either 10000 or 14000.

Nasta eluded to the possibility of doing this in another thread, and it does make perfect sense. What I wanted to know was could the ROM version of the driver be edited to reflect the different I/O address than where the ROM was running from.

So you see, I am not in the way of any slot's or using any other prime memory real estate - just using up some of the slack... :D

Re: QubATA 3.10 I/O area address

Posted: Wed Nov 08, 2017 11:29 am
by tofro
What could be done is - if you are willing to free up and dedicate a base address register (instead of PC) in the QubIDE ROM to point to your selected I/O area. This would end up in a major rewrite of the driver, though. You´ll probably need to go that way, as absolute long addressing of I/O (the other possible route) will very probably make your code no longer fit into 16k.

It still escapes me, however, why you would want to invest that effort just for the gain of 255 bytes of I/O area. You´ll probably spend more code than that to free that base register.


Re: QubATA 3.10 I/O area address

Posted: Wed Nov 08, 2017 12:19 pm
by Pr0f
I think in the Qubide assembly source, the I/O area is defined as a manifest constant - so changing it once and reassemble does the trick. QubATA driver and ROM image is in compiled form.

But then this was just a question. If the image is loadable anywhere - why is there a reference in the REXT file to a 'hard' address, or does that somehow get overwritten on loading - I didn't think that happened.

So the reasons behind this are more managing how I/O is addressed and memory addressed, and not having to deal with additional decoding in the ROM space, leaving that just as memory.

Re: QubATA 3.10 I/O area address

Posted: Wed Nov 08, 2017 1:19 pm
by tofro
I just had a short check on it: The driver appears to do some interesting things:

In windev_asm (INIT), it seems to copy itself from ROM into allocated RAM and patch the detected hardware addresses directly into the code. Not the most RAM-efficient method, but would make relocating the driver to some other I/O address easier (and the actual ROM position in the memory map largely irrelevant).


Re: QubATA 3.10 I/O area address

Posted: Wed Nov 08, 2017 1:26 pm
by Pr0f

I came across this in the documentation:

IO.EXTOP (trap#3, d0=$9) Do externally operation

Call parameters :

a2 address of the user routine to be called
d1/d2/a1 parameters supplied to the user routine passed in a2
Return :
d0/d1/a1 as returned from user routine
When control is passed to the user routine, following registers are supplied as:
a0 pointer to the Channel Definition Block
a2 pointer to the FAT for the drive
a3 pointer to the Driver Definition Block
a4 pointer to the Physical Definition Block
a5 pointer to the base of the drive IDE registers (drive selected)
a6 base of system variables

User routine is called in Supervisor mode. All registers (other than d0/d1/a1) may be smashed.

all of which suggests it has packed the address of the hardware in A5 and indexed that by the drive number too, at some point....

so coming back to your discovery, when running from the ROM image, it doesn't actually run from there, but from a 'modified' copy in RAM then ?

Re: QubATA 3.10 I/O area address

Posted: Thu Nov 09, 2017 7:23 pm
In fact, QubATA driver can run from anywhere in memory provided it knows the hardware base address of the controller.
This is why the REXT version has to be configured with the hardware address before running.
The Romed version copies itself from ROM to RAM and patches on the fly the code image with the correct hardware address.

This hardware base address is used by the driver to access IDE registers with some rules depending of the platform.
For QubIDE interface, registers are sit on the last 256Bytes of the 16KBytes of the ROM base as they are decoded by GALs. For Q40 platform, this rules are different. So, driver sources have to be compiled separatelly for each platform with the adequate addresses layout.

Also, for Qubide interface, driver does at begining some actions inside the ROM space to ensure the hardware is correct (GALs version per example).

Re: QubATA 3.10 I/O area address

Posted: Thu Nov 09, 2017 10:01 pm
by Pr0f
In theory is it possible to have the hardware registers at a different address, i.e. not in the last 256 bytes, assuming the GALS are set to a different address?

Re: QubATA 3.10 I/O area address

Posted: Fri Nov 10, 2017 8:27 am
Absolutely but you should use a specific recompiled version of driver otherwise the actual binary will not work even you configure the hardware address within the config block in rext image.

I can supply a new version if you tell a little more about your project & hardware.