Jump to content
jedimatt42

TIPI - TI-99/4A to Raspberry PI interface development

Recommended Posts

10 hours ago, jedimatt42 said:

Maybe it is harder to call console's DSRLNK, seeing how nobody does...

 

fbForth 2.0 calls it via the MG DSRLNK/GPLLNK routines. It is, indeed, more difficult to manage because it is in GPL ROM.

 

...lee

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites

@jedimatt42 I have a Pi hat and I’m wondering if I can write a DSR for it. Without any changes to the TIPI itself.
 

So I thought of creating a socket interface to the Hat on Linux. Then the TI accesses it as a file like TIPI.TCP=
 

I did not think a DSR could call other DSRs, so I looked into using the Pi message interface directly. Then I saw that you left a subroutine entry point table!

 

calling the console DSRLNK… scary. I suppose it’s easier to devise a scanning routine that fits into FAC. Something kludgy that expects to find the first device name=TIPI. 
 

however, I just realized that I can’t plug in both the Hat and the TIPI interface. Duh. 
 

So this is not going to work. 


 

  • Like 1

Share this post


Link to post
Share on other sites

The TIPI uses a small subset of the PI's GPIO for the purpose of allowing extension in the field.

 

Also, without any modifications of the DSR ROM, the PI. device capabilities can be expanded with simple python additions - ~/tipi/services/SpecialFiles.py

 

This is how I provided things like PI.PIO without a ROM update.

  • Like 2

Share this post


Link to post
Share on other sites
11 hours ago, jedimatt42 said:

What kind of hardware wants to couple itself to TIPI?

a Pi Hat! I’ve worked out how to disable the pins that Tipi shared. So I need to unsolder the header and use tall stacker header on those 10 pins. Actually that will make room for the Tipi IDC connector to fit better. 
 

Quote


 

 

---

I would think (guessing) the smallest RAM usage to detect TIPI's CRUBASE would be to use ROM code to setup a console ROM DSRLNK (via XMLLNK?) . Actually call the link from console RAM, return to it... R12 should have the CRUBASE value as a side-effect. Then return back to your ROM. It would have to be a request like 'close' to PI.CLOCK or something benign like that.


 

that seems the best. Let me think through my best idea, scanning.

 

in PAD
SBZ 0   map out DSR
LI R12,>1000
! SBO 0      Enable DSR ROM
MOV @>4008,R0  device chain
INCT R0    skip link to next
MOV *R0,R0
SBZ 0        leave DSR ROM
CI R0,>0454   length 4 'T' kludge
JEQ DONE
AI R12,>0100
CI R12,>2000
JL !
DONE  RT

* caller compares R12 to >2000 to validate
* 18 words. in PAD, 4A to 6B. 6D is MAX!
Quote

The TIPI CRUBASE is not stored. However maybe with more context, there can be a way for a hint to be provided by the caller of your DSR entry?

I could also assume the user runs the configuration program from BASIC and enters it there. I’m not sure where to store it. Ideally persistent. But the persistent storage is on the Pi Hat. Urghh. 
 

optimizing…

* replace AI,CI,JL

SWPB R12

INC R12

SLA R12,11

JEQ DONE * reached >2000

SRL R12,3

JMP !


Nope, that’s 6 words to replace 5

Edited by FarmerPotato
  • Like 1

Share this post


Link to post
Share on other sites
12 hours ago, FarmerPotato said:

I had an idea where another DSR calls the send/receive routines in the TIPI DSR.

 

In the source, header and tipi-io, there are pointers to the 4 send/receive routines ,in a table at >4010. So other programs  might call them and be relatively future compatible. 
 

I worked out how one DSR could move its trampoline code into >834A. About 8 words is enough to map out the calling DSR, map in TIPI, make the call, then put things back. 
 

The trampoline doesn’t need any more registers, since the DSR copies it up to PAD and modifies the instructions to restore R12 and branch return address. 

The message would be in VDP, most likely,  since a DSR can’t own any cpu RAM. 
 

the thing I can’t figure out, is how can one DSR find the cru base of the TIPI DSR? Is this stored anywhere?
 

Unless it were possible to fit a small enough scanning routine in >834A ?

 

I don't know enough on the 4A side of things, but I did do a fair amount of building a library of calls to the TIPI in the AfterHours source code that I then stored in the >6000 to >7FFF range of an 8K-EA cart.

 

Can you scan for the CRU of the TIPI once, and store the CRU somewhere?  Possibly in some self modifying code ???

 

Second thought, can you use the ISR to your advantage and activate it to leverage some code for you?

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites

@FarmerPotato, if your detect scan assumes the TIPI name is the first in the name linked list, I will make a note in the TIPI source so I don't change that in the future...

Share this post


Link to post
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.

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