EXTBIO device identifiers

Page 4/5
1 | 2 | 3 | | 5

By konamiman

Paragon (1159)

konamiman's picture

10-06-2010, 21:46

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

By sd_snatcher

Prophet (3498)

sd_snatcher's picture

12-06-2010, 01:48

@konamiman

Ok, tks! Smile

Great specs, btw!

If I may, it would be good to have some standard ways to:

1) List all the UNAPI extensions connected to a MSX. Kind of a "dir" of the extensions. The
2) Request an extension to unload itself. ROM extensions would just remove themselves from the chain. This can be used to easily solve eventual conflicts.

I would also request a change to the rule "2.2. Rule 2", that states that the entry-point for the routines must be on page-1 or page-3. I would like that at least the page-2 could be used to, for a good reason (IMO): I'm interested on making a single ROM containing both the MSX-Audio BIOS and the Universal OPL driver. But that would require the Universal OPL driver to reside on the page-2, because the MSX-Audio BIOS already takes the entire page-1 for itself and leaves little room for relocation.

By sd_snatcher

Prophet (3498)

sd_snatcher's picture

12-06-2010, 04:43

@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. :)

By Leo

Paragon (1236)

Leo's picture

12-06-2010, 11:09

i think there is an apps on konamiman that lists & discover all unapi extension, i had compiled and it is in my autoexec.bat so my msx starts always by listing rom unapis already installed

here:
http://www.konamiman.com/msx/unapi/apilist.asm

By sd_snatcher

Prophet (3498)

sd_snatcher's picture

12-06-2010, 14:53

@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

By Leo

Paragon (1236)

Leo's picture

12-06-2010, 16:54

1) no ram loaded only rom
2) i have tested that prog only while having 1 unapie ext , but i seemed to me it coudl list ;ore than one , but i have not tested it.

i may do the test for many unapi 's never tried to put 2 ethernet at the same time , though i have many

By sd_snatcher

Prophet (3498)

sd_snatcher's picture

12-06-2010, 18:32

@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.

By Leo

Paragon (1236)

Leo's picture

12-06-2010, 20:36

all right, what apis are you writing in ram ? for audio ?

By sd_snatcher

Prophet (3498)

sd_snatcher's picture

12-06-2010, 21:07

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.

By Leo

Paragon (1236)

Leo's picture

13-06-2010, 17:14

i believe this page1 thing is related to routines that take in argument an pointer , like HL.

I think , for example , to unapi ethernet : Internestor lite knows unapi rom/ram in page 1 or 3
so it will pass to the unapi routines only HL argument in the page2 range , typically for the send frame
or get frame routines.

So on Audio if you put routines in page2 and also music data ( whatever ) on page2 is it going
to be complicated ( it is never impossible ) ?
typically sw have page2 for them , in ram , and page 0 for bios and page 1 for extbio's , so putting
extbio in page 2 is really good ? if you have page 0 for bios , page 1 for extbio1 and page 2 for extbio2
you dont have much left on page3...

Cant you have entry point of all unapis in same page1, even if actual code if doing page switching under the hood?

Page 4/5
1 | 2 | 3 | | 5