Hook to Memory Mapper segment

By S0urceror

Resident (44)

S0urceror's picture

20-02-2020, 13:51

Hi,

I want to hook H.CHGE to code installed on a Memory Mapper segment.

Problem is that the following sequence:

call CALLS ; [3] - mapper support routine received via Dos2 EXTBIO
db 0       ; [1] - segment number of allocated segment
dw 0000h   ; [2] - address of my routine on allocated segment
ret.       ; [1]

Is 7 bytes total. And the room for any BIOS hook is only 5 bytes. Enough for a inter-slot call through RST 30h but not for the similar CALLS function for memory mappers.

Any ideas how to achieve this? And which page would you recommend for the hook to keep functioning in BASIC and DOS?

Let me know!

Login or register to post comments

By Grauw

Ascended (8735)

Grauw's picture

20-02-2020, 20:58

S0urceror wrote:

Is 7 bytes total. And the room for any BIOS hook is only 5 bytes. Enough for a inter-slot call through RST 30h but not for the similar CALLS function for memory mappers.

Any ideas how to achieve this?

Lower HIMEM and put a little helper routine in upper memory which 1. saves the current mapper segment, 2. selects the desired mapper segment, 3. does an interslot call to the mapper slot, 4. restores the mapper segment, and 5. returns. Then jump to that from your hook.

S0urceror wrote:

And which page would you recommend for the hook to keep functioning in BASIC and DOS?

You must both select the mapper page and select the slot. Unfortunately there is no standard function available which combines the two. As for which page to use, I think page 1 and 2 would work equally well. Page 0 is less ideal. Page 3 won’t work.

By S0urceror

Resident (44)

S0urceror's picture

20-02-2020, 22:57

I already figured I had to do something like that. Have my hook now running on page 2 via a small helper routine in page 3, created by lowering HIMEM as you stated.

Thanks Grauw!

By ducasp

Master (218)

ducasp's picture

27-02-2020, 12:52

You might use Konamiman's RAMHELPR, I did an UNAPI driver with a hook to the interruption hook, it is easy to use once.you understand the concept. ????

https://github.com/ducasp/MSX-Development/blob/master/MSX-SM...

What is relevant to you is probably:

Lines 100-115 : ramhelpr detection
Lines 225-291: mapper block allocation and copy of your code to allocated mapper block
Lines. 293-334: hook patching
Line 560: start of mapper block code
Lines 585-586: hook to interrupt calls here

If you aren't doing an UNAPI compliant code, you might as well just use the first hook patch of the code, extbio hook, and replace with your own H.CHGE hook, simpler and cleaas you can use adress $4000 for it....

Advantages: ramhelpr is done, available and pretty much standard and tested (though it could have a big with call Kanji in Basic, this is an issue I need to investigate whether it is ramhelpr or my code doing something wrong) and your manager won't be another one occupying more memory and cpu time on an already large stack of calls bios does (assuming person already uses ramhelpr for something else) and development time is decreased
Disadvantages: another piece of software is required to be loaded before your code and it won't work without it (but it is freely available and you can distribute it)

By S0urceror

Resident (44)

S0urceror's picture

27-02-2020, 18:43

Hi ducasp, looked at that as well but decided to use some of the work area of my MSX USB Unapi driver for the underlying USB Hid keyboard driver. This solves my problem neatly and doesn’t introduce another dependency.

Check my post on MSX USB to see the end result. Have a base Unapi driver now serving client programs and underlying drivers that specialize in specific USB devices. One for keyboard, one for serial, one for network, etc.

If someone makes other USB hardware and creates a new base driver everything will continue to work. Thanks to the Unapi base that I improved further.

By ducasp

Master (218)

ducasp's picture

27-02-2020, 23:48

Your work is shaping up really well! It is amazing to see the progress you've made so far. Cool