Jump to content
IGNORED

fully relocatable assembly linking with XB


jedimatt42

Recommended Posts

My TIPI XB mouse driver is partially relocatable, but followed by fixed addresses to maintain compatibility with the Mechatronics XB mouse driver mailbox addresses ( for CALL PEEK'ing values )

 

Over in TIPI support thread, we discussed, nixing the Mechatronic's compatibility in a variant that is fully relocatable. But to do this, I needed to write a routine that returns the address of the mailbox, so it isn't always hardcoded to 10000.

 

Here is what I wrote:

 

MBASE	STWP	R10
	MOV R10,@WORKSV
	LWPI	MWS

	; Get address of mailbox into FAC, and convert to a Float
	LI		R1,VPOS
	MOV		R1,@FAC

	; now the XMLLNK to convert to float...
	BLWP	@XMLLNK
	DATA	CIF

	; Now stuff the FAC float into BASIC variable parameter
	CLR		R0			; simple numeric assignment
	LI		R1,1		; assign to parameter 1
	BLWP	@NUMASG		; copy value in FAC to parameter 1

	; restore workspace and return
	MOV 	@WORKSV,@$+8
	LWPI	>AAAA
	RT

 

FAC is an EQU. CIF (convert into to float) is an EQU.

I've included REF lines for NUMASG, and XMLLNK

 

full source is here (on branch jm42/rorg):  https://github.com/jedimatt42/tipi-xb-mouse/blob/jm42/rorg/tmouse.a99

 

I'm using @ralphb 's xas99.py assembly. -C option omitted so it is not compressed, and we get XB loadability... 

'cept, I can CALL LOAD("DSK1.TMOUSE_O") in EA BASIC, but in XB, it errors with: "unrecognized character"

 

xas99.py is at HEAD of master: Date:   Mon Feb 1 17:17:25 2021 +0100

 

The DF80 file doesn't appear to be compressed...  lines look like: 

0021D        A0000B02AABC80AC0210B02E0C01F0B0201C0214BC801B834A7F2E5F

 

TMOUSE_O

 

Time for dinner though...

 

oh, while it loads when I use EA BASIC, call link("MBASE", MBOX) errors with an "unresolved reference"  

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

That was fun. I've never XMLLNK'ed before, or done XB parameters to CALL LINK... both on my to-learn list for a while...  I just don't really XB, but I'm happy to enable those that do when in a position to do so.

 

The additional routine left it 8 bytes shy of aligning the mailbox to the old Mechatronic's address. But it would only be there if loaded first. 

 

Enjoy.

  • Like 5
Link to comment
Share on other sites

8 hours ago, jedimatt42 said:

That was fun. I've never XMLLNK'ed before, or done XB parameters to CALL LINK... both on my to-learn list for a while...  I just don't really XB, but I'm happy to enable those that do when in a position to do so.

 

The additional routine left it 8 bytes shy of aligning the mailbox to the old Mechatronic's address. But it would only be there if loaded first. 

 

Enjoy.

Nice work! I'm hoping to be able to test it out sometime this week.

How about padding 8 bytes with BSS to actually make it compatible with the Mechatronic mouse? Compatibility is only needed for old programs like TI Artist and my own Soundgen, but in these cases the driver is loaded first anyway.

Link to comment
Share on other sites

9 hours ago, senior_falcon said:

When you get tired of waiting for the XB loader to do its thing, give XB256 a try. The loader is 20x faster, can use REFs and can load compressed code.

To be honest I'm a little bewildered with the different XB development products you have. How about a cheat sheet with the major features for each one? 

Incidentally, does CALL LINK work faster with XB256 than standard XB?

Link to comment
Share on other sites

46 minutes ago, Vorticon said:

Nice work! I'm hoping to be able to test it out sometime this week.

How about padding 8 bytes with BSS to actually make it compatible with the Mechatronic mouse? Compatibility is only needed for old programs like TI Artist and my own Soundgen, but in these cases the driver is loaded first anyway.

Tempting.

 

Ti-artist uses a completely different driver. 

 

I believe the mechatronics driver had to be first, and other modules had to be AORGed to coexist as well. 

 

How about we create a version of the mechatronics driver that is fully relocatable instead? With my additional LINK routine... 

  • Like 1
Link to comment
Share on other sites

5 minutes ago, jedimatt42 said:

Legacy programs should use legacy compatible drivers. (Of which there exist nearly none)

 

What I suggest would allow new programs to have a driver compatible with TIPI mouse and Mechatronics mouse (available in MAME)

Got it. I did not know that MAME emulates the Mechatronics mouse.

Link to comment
Share on other sites

1 hour ago, Vorticon said:

To be honest I'm a little bewildered with the different XB development products you have. How about a cheat sheet with the major features for each one? 

Incidentally, does CALL LINK work faster with XB256 than standard XB?

To the best of my knowledge, CALL LINK takes the same amount of time regardless of what assembly subs are in low memory. Having said that, CALL LINK has to go through the DEF table. If that is long and the sub is near the end of the table, then a little more time is required. If you are writing something with multiple A/L subs, the ones that you want to run faster should go at the end of the DEFs, and the ones that are slower should be at the beginning.

E.G.

DEF INPUT             input waits for the user to type something, so speed is not so important

DEF HCHAR

 

INPUT is placed at >3FF8 where it is last in the list, then HCHAR is placed at >3FF0, where it is first in the list.

 

As it says in the good book, Matthew 20:16, “So the last will be first, and the first will be last.”

  • Like 2
Link to comment
Share on other sites

Also, if the 1st two bytes of the name are different in all cases, then CALL LINK only has to compare the first word to know it is a mismatch.

So:

H1CHAR

H2CHAR

H3CHAR

H4CHAR

would find the match a little quicker than

HCHAR1

HCHAR2

HCHAR3

HCHAR4

But this is pretty insignificant compared to all the other delays built into XB.

  • Like 2
Link to comment
Share on other sites

1 hour ago, SkyPilot said:

 

Being new here, I probably shouldn't say, but does it matter?  Ppl here that want it could get the new one, anyone else who needs the old one probably already has it and can run as usual.

Preserving the old tech is one thing. But relying on that old tech is a dumb idea.

Edited by jrhodes
Link to comment
Share on other sites

1 hour ago, senior_falcon said:

Don't know how feasible that is without more information.

Seems pointless. All TIPI's that are up to date, have the mouse driver available in TIPI.TMOUSE.TMORORG/O  or TIPI.TMOUSE.TMOUSE/O depending on which one the client program wants... 

 

Tipi update 2.24 ( minutes ago )

  • Like 2
Link to comment
Share on other sites

Hmmm RXB 2020E has

CALL PLOAD( memory boundary , "DSK#.filename") ! say at >A000 for example as long as your XB program is not over 20K

 

This works with or without SAMS so this would perfect to load your Mouse Routines where you want to have it.

 

Honestly I am way ahead of your guys for solutions to loading programs as a Memory Image loads much faster then Object code.

 

(Note: CALL PSAVE( memory boundary , "DSK#.filename") ! this saves a memory image to disk for PLOAD to use.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...