Jump to content
IGNORED

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
Link to comment
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
Link to comment
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 5
Link to comment
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. 

Link to comment
Share on other sites

  • 2 weeks later...

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.

 

 

 

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

 

Link to comment
Share on other sites

  • 1 month later...

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.

Link to comment
Share on other sites

  • 1 month later...

@jedimatt42

 

I came across a behavior with the TIPI last night on my Geneve.  Saving files on the Geneve to the TIPI, the files were being saved with the correct time.  In my PI.CONFIG file, I had TZ=America/New_York.  Not TZ was in uppercase.

 

When I went to read PI.CLOCK, I was getting a time 3 hours earlier reported in my AfterHours code.  I rebooted the PI, but time did not change.  Finally, I ssh'd in and issued the 

 

sudo timedatectl settimezone America/New_York

 

I tested but time was not correct until I rebooted the PI.  I've got a PI4 in the system.  So, I am not sure if this was a PI4 issue at the moment, or if the code for PI.CLOCK is not looking at the TZ config variable, or if something else is not going.  Right now, just reporting for informational purposes.

 

Beery

 

 

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

@jedimatt42 and @InsaneMultitasker

 

Matt,

 

I know the "standard" is a bit arbitrary between various terminal emulators with the TIFILES header. With MyTerm for the Geneve, Michael Riccio expanded the header.  I have added some code in the construct he used for transferring files that maintained creation and update time/date of the original files.  I know nothing like this was ever implemented on the TI-99/4A. I'm not sure if this is something you may want to consider or not.

 

 

 

 

* Construct File Header if not Dis/Fix 128

XMDSB  LI   R0,TIHEAD    No, TI header data
       MOV  *R0+,*R6+    >07,'T'
       MOV  *R0+,*R6+    'I','F'
       MOV  *R0+,*R6+    'I','L'
       MOV  *R0+,*R6+    'E','S'

       LI   R1,FINFO+2   No, File information
       MOV  *R1+,R3      Get file type
       MOV  *R1+,R2      Get file length
       MOV  R2,*R6+      Save file length
       MOV  R2,@SECREM   Set remaining sectors
       ANDI R3,>F7FF     Mask out protection bit
       MOV  R3,*R6+      Save file type
       DECT R3           Dis/Fix 128?
       JNE  XMDS1        No, Send header

       MOV  *R1,R3       Yes, Get record length
       ANDI R3,>00FF     Want LSB only
       CI   R3,128       Dis/Fix 128?
       JNE  XMDS1        No, Send header

       MOV  @FTHEAD,R3   Yes, Send header for Dis/Fix 128?
       JNE  XMDS1        Yes, Send header

       LI   R6,>6000     No, Reset buffer pointer
       SETO @TIFILE      Not a TI file
       JMP  XMDS3        Skip this

XMDS1  MOV  *R1+,*R6+    Put rec len in header
       MOV  *R1+,*R6+    Put lev 3 recs in header
       MOV  *R0+,*R6+    'M','Y'
       MOV  *R0+,*R6+    'T','E'
       MOV  *R0,*R6+     'R','M'
       MOV  *R1+,*R6+    Creation time
       MOV  *R1+,*R6+    Creation date
       MOV  *R1+,*R6+    Update time
       MOV  *R1+,*R6+    Update date
       MOV  *R1,*R6+     Extended info

       LI   R1,>CA53     Filler data
XMDS2  MOV  R1,*R6+      Fill buffer
       CI   R6,>6080     End of first record?
       JL   XMDS2        No, Keep blanking

  • Like 1
Link to comment
Share on other sites

15 minutes ago, 9640News said:

@jedimatt42

 

I came across a behavior with the TIPI last night on my Geneve.  Saving files on the Geneve to the TIPI, the files were being saved with the correct time.  In my PI.CONFIG file, I had TZ=America/New_York.  Not TZ was in uppercase.

 

When I went to read PI.CLOCK, I was getting a time 3 hours earlier reported in my AfterHours code.  I rebooted the PI, but time did not change.  Finally, I ssh'd in and issued the 

 

sudo timedatectl settimezone America/New_York

 

I tested but time was not correct until I rebooted the PI.  I've got a PI4 in the system.  So, I am not sure if this was a PI4 issue at the moment, or if the code for PI.CLOCK is not looking at the TZ config variable, or if something else is not going.  Right now, just reporting for informational purposes.

 

Beery

 

 

 

Timezone isn't set on boot... it's intended to be a persistent configuration in the raspi-config.  When you write the PI.CONFIG file and set TZ, it is supposed to trigger ( if it changes ) invoking raspi-config to set the timezone however the Raspberry PI OS does it. So, it's not likely to have anything to do with PI4, or Geneve. 

 

I'd recommend (as a workaround) ssh into the PI, and run sudo raspi-config  then use the menu system to set the timezone. 

 

Really shouldn't need a reboot... I'll have to take a look at see if I can make it break. 

 

  • Like 1
Link to comment
Share on other sites

6 minutes ago, 9640News said:

@jedimatt42 and @InsaneMultitasker

 

Matt,

 

I know the "standard" is a bit arbitrary between various terminal emulators with the TIFILES header. With MyTerm for the Geneve, Michael Riccio expanded the header.  I have added some code in the construct he used for transferring files that maintained creation and update time/date of the original files.  I know nothing like this was ever implemented on the TI-99/4A. I'm not sure if this is something you may want to consider or not.

 

 

 

 

* Construct File Header if not Dis/Fix 128

XMDSB  LI   R0,TIHEAD    No, TI header data
       MOV  *R0+,*R6+    >07,'T'
       MOV  *R0+,*R6+    'I','F'
       MOV  *R0+,*R6+    'I','L'
       MOV  *R0+,*R6+    'E','S'

       LI   R1,FINFO+2   No, File information
       MOV  *R1+,R3      Get file type
       MOV  *R1+,R2      Get file length
       MOV  R2,*R6+      Save file length
       MOV  R2,@SECREM   Set remaining sectors
       ANDI R3,>F7FF     Mask out protection bit
       MOV  R3,*R6+      Save file type
       DECT R3           Dis/Fix 128?
       JNE  XMDS1        No, Send header

       MOV  *R1,R3       Yes, Get record length
       ANDI R3,>00FF     Want LSB only
       CI   R3,128       Dis/Fix 128?
       JNE  XMDS1        No, Send header

       MOV  @FTHEAD,R3   Yes, Send header for Dis/Fix 128?
       JNE  XMDS1        Yes, Send header

       LI   R6,>6000     No, Reset buffer pointer
       SETO @TIFILE      Not a TI file
       JMP  XMDS3        Skip this

XMDS1  MOV  *R1+,*R6+    Put rec len in header
       MOV  *R1+,*R6+    Put lev 3 recs in header
       MOV  *R0+,*R6+    'M','Y'
       MOV  *R0+,*R6+    'T','E'
       MOV  *R0,*R6+     'R','M'
       MOV  *R1+,*R6+    Creation time
       MOV  *R1+,*R6+    Creation date
       MOV  *R1+,*R6+    Update time
       MOV  *R1+,*R6+    Update date
       MOV  *R1,*R6+     Extended info

       LI   R1,>CA53     Filler data
XMDS2  MOV  R1,*R6+      Fill buffer
       CI   R6,>6080     End of first record?
       JL   XMDS2        No, Keep blanking

 

I've heard of placing timestamps in the TIFILES headers, but I'm not inclined to do that, just as I ignore the name in the TIFILES header. The intention is to allow managing files from the host operating system with as little external tooling required as possible. So, if you open up the windows share, and move a file, or copy it, or do something that modifies the unix system's idea of timestamp on the file, that is what is used.  last modified time from the host OS agrees with what is reported to the 4A.

 

Replicating the data into the TIFILE header would be improbable to keep correct given outside actions can be taken.

 

  • Like 1
Link to comment
Share on other sites

1 minute ago, jedimatt42 said:

 

I've heard of placing timestamps in the TIFILES headers, but I'm not inclined to do that, just as I ignore the name in the TIFILES header. The intention is to allow managing files from the host operating system with as little external tooling required as possible. So, if you open up the windows share, and move a file, or copy it, or do something that modifies the unix system's idea of timestamp on the file, that is what is used.  last modified time from the host OS agrees with what is reported to the 4A.

 

Replicating the data into the TIFILE header would be improbable to keep correct given outside actions can be taken.

 

No problem.  I just wanted to throw it out there as I came across the info again and thought it may be of benefit, etc.

 

Beery

 

  • Like 2
Link to comment
Share on other sites

  • 1 month later...

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 ?

 

Link to comment
Share on other sites

What kind of hardware wants to couple itself to TIPI?

 

---

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.

 

I don't know if that is actually possible or just a theory... Maybe it is harder to call console's DSRLNK, seeing how nobody does... 

 

---

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?

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