EXTBIO device identifiers

@sd_snatcher: of course you can use that code freely, otherwise I wouldn't have published it The same applies to all the source code downloadable from my page.

@konamiman:

Besides the "2.2. Rule 2", that's other thing making me worry: My current routine to call the driver is as simple as this:

push bc,de,hl
ld a,4
out (0FEh),a
call WRTOPLL
ld a,1
out (0FEh),a
pop hl,de,bc

I took care to never use the AF',BC',DE',HL' registers, so they don't need to be pushed on each OPLL write.

But if I convert the Universal OPL driver to the UNAPI interface, each call will result in:

1) push all ' and IX/IY registers.
2) push all BC,DE,HL, as those are modified by the Universal OPL driver routines
3) UNAPI's RAMHELPER _C4010@sym will do a lot o stack operations, then jp to _CALLRAM
4) UNAPI's RAMHELPER _CALLRAM will call SETSLOT@sym, CALLIX@sym, RESTSLOT@sym
5) SETSLOT@sym will push af,bc,de,hl,ix,iy, do it's stuff, pop af,bc,de,hl,ix,iy in reverse
6) RESTSLOT@sym will push af,bc,de,hl,ix,iy, do it's stuff, pop af,bc,de,hl,ix,iy in reverse

That's sure a heavy burden on the poor Z80A for each OPLL write. The current implementation is able the translate OPLL commands to OPLx in real time using the Z80A@3.5MHz. But with such a heavy burden, I don't think it will be able to to it anymore.

Aren't there any ways to optimize the RAM helper routines to minimize the stack operations? Otherwise it may be useful for package based devices like an ethernet interface, but certainly too heavy for byte-based devices like the RS-232 and the OPLs.

Another question I have: Does the RAM helper installation really needs to go to BASIC and return to DOS? The users tend to hate this, because it disrupts any BAT file, including the AUTOEXEC. This means that two programs that work like this (MEMMAN and a UNAPI driver, i.e.) can never be placed on AUTOEXEC and at least one of them will always need to be loaded manually.

Don't get me wrong with all those questions. I don't intend to criticize, only to improve. :)

@Leo:

I'm not sure if you refered to listing the APIs or the going BASIC/return DOS question so:

1) Is a client, so it doesn't have the go BASIC/return DOS problem. Do you have any UNAPI driver being loaded on RAM on your AUTOEXEC.BAT? Don't they interrupt the AUTOEXEC execution?

2) It lists all implementations of a specified API, but not all APIs available on a machine

@Leo

It will list more than 1 ethernet conected to the same MSX, because those are implemdentations of the same API. But it will not list any other API if you don't previously know its name.

Yep, the idea is to offer the Universal OPL driver currently featured on FireHawk HDD version with an UNAPI interface, so any MSX programmer can make use of it.

Probably it will be available both in RAM and ROM versions. Maybe even a hardware-accelerated version too (but this hw-accelerated is at planning stage yet, by a friend. Not sure if it will be completed).

But right now I'm having some trouble UNAPIfying it:

1) The unapiram.asm sample uses a trick to relocate the RAM helper that don't work wit the assembler I use (SjAsmPlus). But the UNAPI specification requires the RAM helper to be loaded by any extension loaded in RAM.

2) The RAM-helper is very inefficient for this kind of application. But It seems I could just ignore it and call the routines directly without much trouble, or using DOS2 paging routines.

3) The UNAPI specification don't allow APIs to offer their interface at page-2. But, because of (2), I believe I can "bend" this rule, as the limit is imposed by the RAM-helper itself.