TIPI Usage and Support

[GDMike]

4 hours ago, jedimatt42 said:

If you can point we at this software I can see what it is doing.. I know I've tested TI's Editor Assembler, but I do all my assembly with xdt99... So I've never tried the RAG stuff.

I've renamed them from their original form of RAGASM and RAGAS"N"

Fyi, I run these from classic 99 and never had trouble. I've also run this From ti peb floppy and gotek as well and seem ok .

 

 

RAG RAH

Edited June 7, 2021 by GDMike

[+InsaneMultitasker]

14 hours ago, jedimatt42 said:

These xb embedded EA5 loaders of old used sector io, which TIPI does not do. This never made sense as there is the much easier direct block read operation they could have used without having to decode the directory structure themselves.

Although not directly related to the EA5 loaders,  the historical reasons for using sector IO to decode the directory structures (catalog the files) were that sector IO was faster and it removed the hassle of dealing with records and floating point numbers.  Nearly all disk managers including Myarc's MDM5 (for the HFDC) relied upon direct sector IO.  And while they are still viable programs, we have moved beyond that with programs like DM2K. 

 

 

[+jedimatt42]

1 hour ago, InsaneMultitasker said:

Although not directly related to the EA5 loaders,  the historical reasons for using sector IO to decode the directory structures (catalog the files) were that sector IO was faster and it removed the hassle of dealing with records and floating point numbers.  Nearly all disk managers including Myarc's MDM5 (for the HFDC) relied upon direct sector IO.  And while they are still viable programs, we have moved beyond that with programs like DM2K. 

 

 

The cases I was referring to are not disk managers. Or even catalog listers.

[+Vorticon]

20 hours ago, arcadeshopper said:

http://ftp.whtech.com/Users/Gregory%20McGill/INFOCOMLOADER/

We found this issue early in TIPI testing and determined that was the loader as Matt said above here is a loader that works fine.

 

Sent from my LM-V600 using Tapatalk

 

 

 

 

Thanks! I'll give it a shot.

[+Vorticon]

21 hours ago, arcadeshopper said:

http://ftp.whtech.com/Users/Gregory%20McGill/INFOCOMLOADER/

We found this issue early in TIPI testing and determined that was the loader as Matt said above here is a loader that works fine.

 

Sent from my LM-V600 using Tapatalk

 

 

 

 

That did not work unfortunately. That's OK though. I just ended up creating a script to replace the LOAD program which launches the appropriate interpreter from TIPI as Matt suggested, and that works just fine.

 

I should mention that the readkey scripting command needs to be in lower case unlike the other commands which don't care. This tripped me up for a while and it's not mentioned in the wiki...

Edited June 7, 2021 by Vorticon

[+jedimatt42]

3 hours ago, Vorticon said:

That did not work unfortunately. That's OK though. I just ended up creating a script to replace the LOAD program which launches the appropriate interpreter from TIPI as Matt suggested, and that works just fine.

 

I should mention that the readkey scripting command needs to be in lower case unlike the other commands which don't care. This tripped me up for a while and it's not mentioned in the wiki...

For the reader, readkey is a command in ForceCommand. Nothing to do with TIPI in particular.

[+arcadeshopper]

That did not work unfortunately. That's OK though. I just ended up creating a script to replace the LOAD program which launches the appropriate interpreter from TIPI as Matt suggested, and that works just fine.
 
I should mention that the readkey scripting command needs to be in lower case unlike the other commands which don't care. This tripped me up for a while and it's not mentioned in the wiki...

Ok I looked and it looks like I uploaded the wrong file I'll get that fixed and update you when it is

Sent from my LM-V600 using Tapatalk

[+Vorticon]

Is there documentation on how to access the mouse with TIPI? I'm looking at adding mouse support to a current XB project.

[+arcadeshopper]

Is there documentation on how to access the mouse with TIPI? I'm looking at adding mouse support to a current XB project.

https://github.com/jedimatt42/tipi/wiki/Extension-Mouse


Sent from my LM-V600 using Tapatalk

[+jedimatt42]

Be sure to scroll past the messaging protocol and notice the existing driver linked for XB. Works the same as Mechatronics mouse.

[+Vorticon]

Awesome! Would it be possible to have a copy of the mouse.o file by any chance? I don't have xdt99 installed as I don't have much use for it.

[+arcadeshopper]

Awesome! Would it be possible to have a copy of the mouse.o file by any chance? I don't have xdt99 installed as I don't have much use for it.

Pretty sure it's in the forum here.

Sent from my LM-V600 using Tapatalk

[+jedimatt42]

1 hour ago, Vorticon said:

Awesome! Would it be possible to have a copy of the mouse.o file by any chance? I don't have xdt99 installed as I don't have much use for it.

The binary should be on that GitHub releases page.. The readme for the GitHub repository has a section labelled, 'Binary', with a link to the releases page for the repository. That page shows version 1.1 has an asset named tmouse.o

 

You should be able to download that.

 

There has been no interest, so I forgot that I intended to bundle the binary on the TIPI... 

[+Vorticon]

6 hours ago, jedimatt42 said:

The binary should be on that GitHub releases page.. The readme for the GitHub repository has a section labelled, 'Binary', with a link to the releases page for the repository. That page shows version 1.1 has an asset named tmouse.o

 

You should be able to download that.

 

There has been no interest, so I forgot that I intended to bundle the binary on the TIPI... 

Got it. Thanks!

I do have a question though. If the driver is about 355 bytes long and is relocatable, that will put it between >24F4 and >2657 if it is loaded first. But the docs also mention that you are using addresses >2710 - >2719 as mailbox addresses in order to maintain compatibility with the old Mechatronics driver, so is there a memory gap between the end of the driver and the mailbox addresses? If there is, then I will need to AORG any custom assembly programs I'd like to load after the mouse driver. otherwise they will overwrite the mailbox addresses and crash when the latter are used by the mouse driver. Am I understanding this correctly?

Edited June 28, 2021 by Vorticon

[Stuart]

19 minutes ago, Vorticon said:

Got it. Thanks!

I do have a question though. If the driver is about 355 bytes long and is relocatable, that will put it between >24F4 and >2657 if it is loaded first. But the docs also mention that you are using addresses >2710 - >2719 as mailbox addresses in order to maintain compatibility with the old Mechatronics driver, so is there a memory gap between the end of the driver and the mailbox addresses? If there is, then I will need to AORG any custom assembly programs I'd like to load after the mouse driver. otherwise they will overwrite the mailbox addresses and crash when the latter are used by the mouse driver. Am I understanding this correctly?

Could you just add a BSS at the end of the driver to reserve enough bytes to get it past >2719?

[+arcadeshopper]

at least with the mech driver I found that if I loaded it first, other things loaded above it

 

[+Vorticon]

17 minutes ago, arcadeshopper said:

at least with the mech driver I found that if I loaded it first, other things loaded above it

 

ALC programs are usually loaded sequentially, but the issue is that the mouse driver is using a set of addresses as mailboxes beyond its actual end address, so I'm wondering if there is a gap there unless jedimatt covered the gap with a BSS as stuart suggested.

[+jedimatt42]

I think, even with the old mechatronics driver, they picked address easy to document, not addresses in their relocatable code. 

 

It seems to me, there should be another call link that returns the address of the mailboxes, and then the xb code should use those... Abandoning the mechatronics hardcoded address compatibility... A tmouse_r.o ... 

 

 

 

[+Vorticon]

20 minutes ago, jedimatt42 said:

I think, even with the old mechatronics driver, they picked address easy to document, not addresses in their relocatable code. 

 

It seems to me, there should be another call link that returns the address of the mailboxes, and then the xb code should use those... Abandoning the mechatronics hardcoded address compatibility... A tmouse_r.o ... 

 

 

 

A separate driver without Mechatronics compatibility makes total sense for new projects with the TIPI mouse and simplifies life  

Forgot to ask: will you be considering that?

Edited June 28, 2021 by Vorticon

[+jedimatt42]

The problem is, I'm no good at assembly integration with XB... the mailbox addresses are indeed AORG'ed, and not BSS padded. Removing the AORG solves the core problem, but then we have to have a CALL LINK("MMAIL", MBASE), and the assembly has to stuff the base address into MBASE... That would only have to be called once. 

 

... 

 

Reading E/A manual....

 

...

 

Is 17.2.1 - NUMASG utility available in XB ? 

[+jedimatt42]

Being entirely too lazy to design a new interface, it might look like this, instead of what is there now:

 

;
; TIPI Extended BASIC mouse driver similar to but not compatible with 
; Mechatronics mouse driver.
;
; CALL INIT::CALL LOAD("TIPI.TMOUSE/O")
;
; CALL LINK("MBASE", MBOX)
; -- set MBASE to address of beginning of data exchange mailbox
; 
; CALL LINK("MOUSE0") 
; -- Will block until mouse button 1 is pressed. A subsequent
;    CALL PEEK(MBOX,VPOS,HPOS) will read location data.
;    MKEY will be 255.
;
; CALL LINK("MOUSE1")
; -- Install an interupt service routine to update the mouse location and
;    button status. 
;    Control flow returns to the calling XB
;    program. Subsequent CALL PEEK(MBOX,VPOS,HPOS,MKEY) calls will
;    provide the updated status. 
;
; CALL LINK("MCLR")
; -- Uninstalls the interrupt service routine.
;
; CALL LOAD(MBOX+3,VHOME,HHOME)
; -- stores the value of VHOME and HHOME in address MBOX+3 and MBOX+4. The
;    driver will move the pointer to this position if second mouse button
;    is pressed.
;
; CALL LOAD(MBOX+5,LEFT,RIGHT,TOP,BOTTOM)
; -- stores a bounding box to contain the pointer.
;

 

[+Vorticon]

7 minutes ago, jedimatt42 said:

The problem is, I'm no good at assembly integration with XB... the mailbox addresses are indeed AORG'ed, and not BSS padded. Removing the AORG solves the core problem, but then we have to have a CALL LINK("MMAIL", MBASE), and the assembly has to stuff the base address into MBASE... That would only have to be called once. 

 

... 

 

Reading E/A manual....

 

...

 

Is 17.2.1 - NUMASG utility available in XB ? 

Yes it is. This is the document you should read.

TI Extended BASIC Assembly Language Code Programmer's Guide.pdf

[+jedimatt42]

Gonna have to start a dev thread, cause something went wrong... 

[+jedimatt42]

Ok, the fully relocatable driver is documented and where the old one was: https://github.com/jedimatt42/tipi-xb-mouse

 

I can't really test it fully... my hardware isn't very healthy at the moment.

[+jedimatt42]

Update 2.24 - Bundle the XB mouse drivers into the TIPI.TMOUSE. directory

 

Developers can assume that is where they are and CALL LOAD("TIPI.TMOUSE.TMOUSE/O") or CALL LOAD("TIPI.TMOUSE.TMORORG/O") depending on which one they want.