Jump to content
jedimatt42

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

Recommended Posts

11 hours ago, jedimatt42 said:

For FIXED record type files, the controller should increment the record number in the PAB with each READ. TIPI is currently not doing this in all cases. Tursi pointed this out. Currently TIPI is not doing this for RELATIVE access mode. 

Although it isn't directly TI related, I ran into this same situation while implementing the Geneve OS implementation of TIPI fixed record IO, however, from what I could glean from TI documentation I read, there was a no clear answer.  I think I forced the increment to match the Geneve DSR but I may have misinterpreted the ambiguity and will revisit the implementation notes for consistency with your release. 

  • Like 1

Share this post


Link to post
Share on other sites
43 minutes ago, InsaneMultitasker said:

Although it isn't directly TI related, I ran into this same situation while implementing the Geneve OS implementation of TIPI fixed record IO, however, from what I could glean from TI documentation I read, there was a no clear answer.  I think I forced the increment to match the Geneve DSR but I may have misinterpreted the ambiguity and will revisit the implementation notes for consistency with your release. 

The docs are terrible on this point, and the E/A manual is actually wrong, saying it's updated for RELATIVE mode files rather than FIXED. It was one of the things Classic99 struggled on for a while with most apps working but some failing. The authority is the actually implemented disk controller ROM, since that's what everything is built around. ;)

 

We can see it in both the READ and WRITE opcodes, which call >5510 to handle the record number in the PAB, only if fixed:

 

* in READ
A52EC  BL   @A54FC            get status byte in R0, from FDR
       JLT  A5306             var
       BL   @A5510            fix: get rec # compare to # of recs/file
* in WRITE
       BL   @A54FC            get file status byte from FDR
       JLT  A5402             var
 
       BL   @A5510            fix: get rec # from PAB, sect # in R0
A5510  MOVB @>FBFE(15),5      get record # from PAB, check if valid
       SRL  5,8               -------------------------------------
       JNE  A551C             get # of rec/sector from FDR
       LI   5,>0100           0: default to 256
A551C  MOV  @>0054(9),3       PAB ptr
       AI   3,>0006           point to rec #
       BLWP @>005A(9)         set VDP to read
       DATA >0062             address in R3
       MOVB @>FBFE(15),1      get record # from PAB
       SWPB 1
       MOVB @>FBFE(15),1
       SWPB 1
       MOV  1,0               save it
       JLT  A553C             too big
       JMP  A5542             ok
A553C  BL   @A4C72            update data then return with error
       DATA >8000             "memory full"
A5542  INC  0                 next record
       BLWP @>005A(9)         set VDP to write
       DATA >0063             address in R3
       MOVB 0,@>FFFE(15)      write back # of future record
       SWPB 0
       MOVB 0,@>FFFE(15)
       CLR  0
       MOV  1,3               save # of desired rec
[...]

>5510 is not called from any other place, and you can see that the only time it doesn't increment the record in the PAB is when the record number is negative.

 

(This is Thierry's DSR disassembly, if you want to follow along...)

dc_full.txt

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Does that mean it should not increment the record number in the PAB for variable records?

Share this post


Link to post
Share on other sites
27 minutes ago, Asmusr said:

Does that mean it should not increment the record number in the PAB for variable records?

Correct. For variable records, the record number isn't used during read or write, and it's not updated. (There are variables in the file buffer that track the current sector and current offset in that sector instead).

 

For READ, variable file handling starts at A5402, and the variable record data fetch is at A5362, with A536C handling "next sector" (NOT next record!) and A5390 called for an already-open file. It doesn't use the record number here at all. This is why variable files can't be opened as relative access. (Had to try it to verify that my memory was right!)

 

Thierry describes the system seeking through the variable records, but I don't think that happens... it does not happen for every read or write. Even for Append, it knows the last sector and (tested this) jumps straight there.

 

Not 100% sure though, it takes a while to walk through the DSR code, very jumpy. ;)

 

You can also see this in the Classic99 debugger (or any of the others) by watching your PAB while doing accesses with the TI DSR.

 

  • Like 4

Share this post


Link to post
Share on other sites
Was a tipi update pushed recently?
 
No and they are never pushed they wait for you to update in tipicfg

Sent from my LM-V600 using Tapatalk

  • Thanks 1

Share this post


Link to post
Share on other sites

My SNP program kept giving me an error while trying to read/write to a work folder I have been using for months after not using the program for a couple days. 

But after copying the folder and deleting the original and pasting the folder back- everything started working again. It was just weird and I couldn't find a reason until the folder move/replace.

Thanks for letting me know though that it would all be on me. 

Share this post


Link to post
Share on other sites

Matt,

 

I'm not sure if this is a TIPI issue, a "local" issue to me, or what.  If you would, see if you can telnet into 9640News.ddns.net:9640

 

You should not be able to connect, as AT&T blocks the ports at either my AT&T router, or at the tower for my cellular internet connect.  If your TIPI/PI locks up, then I think there is something that may require investigation.

 

From the telnet connection when I try to open, I do not get a response back from the PI/TIPI.  It hangs waiting on a connection or a no-connection response.  Now, if I use my local IP 192.168.x.x:port address, I can connect to the system. The 9640news.ddns.net site points at another computer on my network, just not accessible but the IP address is being updated on no-ip.com.    I don't know where the failure to report a connection is arising from.  If you can generate a lock-up on your end, then I don't know if this particular situation is something you can address.  If you get a refused connection and no-lockup, then the issue is completely on my side with my AT&T cellular firewall.

 

 

 

Share this post


Link to post
Share on other sites
18 hours ago, 9640News said:

Matt,

 

I'm not sure if this is a TIPI issue, a "local" issue to me, or what.  If you would, see if you can telnet into 9640News.ddns.net:9640

 

You should not be able to connect, as AT&T blocks the ports at either my AT&T router, or at the tower for my cellular internet connect.  If your TIPI/PI locks up, then I think there is something that may require investigation.

 

From the telnet connection when I try to open, I do not get a response back from the PI/TIPI.  It hangs waiting on a connection or a no-connection response.  Now, if I use my local IP 192.168.x.x:port address, I can connect to the system. The 9640news.ddns.net site points at another computer on my network, just not accessible but the IP address is being updated on no-ip.com.    I don't know where the failure to report a connection is arising from.  If you can generate a lock-up on your end, then I don't know if this particular situation is something you can address.  If you get a refused connection and no-lockup, then the issue is completely on my side with my AT&T cellular firewall.

 

 

 

 

❯ telnet 9640News.ddns.net 9640
Trying 107.126.86.124...

 

waits for a very long time before giving up... security feature of your firewall.  This is very typical. 

 

after a couple minutes I get a typical error finally...

 

telnet: Unable to connect to remote host: Connection timed out

 

With my TIPI.NET.TELNET, I observe the same thing. After a couple minutes the client socket connection gives up and TIPI reports the error back to the 4A as a failure response to the socket open message.

 

This is your firewall providing a valuable service of hiding the difference between your server being there but not listening on the specified port, and your server not being there. Without the firewall, if something attempts to connect on a port that server is not listening on, the connection is rejected immediately, making it easy to tell that the server is actually there.

 

Share this post


Link to post
Share on other sites

Matt,

 

Throwing a question out there for consideration.  You have probably created the single, most useful hardware product for the TI-99/4A that is out there with the release of the TIPI.  It is a product many of us have grown very dependent  upon.  Unlike other hardware products, we are a bit at the mercy of other developers besides yourself should there be parts of the PI software that get updated breaking some features of the TIPI.

 

Over the years, we have had a number of very talented programmers taken from us prematurely.  That's why I am glad you have posted your TIPI code up on Github, and I have tried to follow through as well with updates at my repository as well.  There are a couple of areas that are still private, but there is at least one other individual that has access and I have not sure pushed or pulled him along <grin> to get sources so others could make changes should something happen to either of us.

 

Thinking about your note on the PI-4 got me to thinking this morning on my drive in to work.  You already have a SDimage of the PI software.  If I understand some of your postings over the past couple of years, the PI has the ability to update software versions of libraries, etc.  That's all good, however I think that may be an issue at the same time, especially if the maintainer of the TIPI wasn't able to maintain the software/updates for some reason.  I just think we are never promised tomorrow.

 

So, my question, if you have not already considered it, would be is it possible to have within TIPICFG an "PI Update" option, defaulted to no, that prevented the PI from updating any resources.  I think that sorta already happens if it can not establish an internet connection.  However, if it can establish an internet connection, I guess there are some PI service(s) that would update things.  Is there an option/flag/setting within the PI that could prevent that from happening?  That way, if there are updates that don't jive with the latest TIPI setup, we aren't left stranded with our hardware.

 

Maybe you have already taken this into consideration, etc.  

 

Food for thought.

Share this post


Link to post
Share on other sites

Being able to freeze the software stack is desirable... some of my update scripts are lazy and update all things if any new thing is required. 

 

-- redacted --

Edited by jedimatt42

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