+InsaneMultitasker Posted February 24, 2021 Share Posted February 24, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 24, 2021 Share Posted February 24, 2021 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 1 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted February 24, 2021 Share Posted February 24, 2021 Does that mean it should not increment the record number in the PAB for variable records? Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 24, 2021 Share Posted February 24, 2021 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. 5 Quote Link to comment Share on other sites More sharing options...
GDMike Posted February 24, 2021 Share Posted February 24, 2021 Was a tipi update pushed recently? 1 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted February 24, 2021 Share Posted February 24, 2021 Was a tipi update pushed recently? No and they are never pushed they wait for you to update in tipicfgSent from my LM-V600 using Tapatalk 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted February 25, 2021 Author Share Posted February 25, 2021 I do push to Github, but not to your TIPI... Your TIPI peeks, prompts, and pulls. 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted February 25, 2021 Share Posted February 25, 2021 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. Quote Link to comment Share on other sites More sharing options...
+9640News Posted March 6, 2021 Share Posted March 6, 2021 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. Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted March 7, 2021 Author Share Posted March 7, 2021 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. Quote Link to comment Share on other sites More sharing options...
+9640News Posted March 7, 2021 Share Posted March 7, 2021 Thanks for the feedback Matt..... and for the explanation! Quote Link to comment Share on other sites More sharing options...
+9640News Posted April 20, 2021 Share Posted April 20, 2021 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. Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted April 20, 2021 Author Share Posted April 20, 2021 (edited) 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 April 21, 2021 by jedimatt42 Quote Link to comment Share on other sites More sharing options...
+9640News Posted April 20, 2021 Share Posted April 20, 2021 Content edited. 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted April 21, 2021 Author Share Posted April 21, 2021 I am not allowed to discuss cyber security in social media, per my employment. Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted April 21, 2021 Author Share Posted April 21, 2021 I shouldn't have brought it up. Quote Link to comment Share on other sites More sharing options...
+9640News Posted April 21, 2021 Share Posted April 21, 2021 I didn't say a thing....... <edit> Quote Link to comment Share on other sites More sharing options...
+9640News Posted June 14, 2021 Share Posted June 14, 2021 @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 1 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted June 14, 2021 Share Posted June 14, 2021 @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 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 14, 2021 Author Share Posted June 14, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 14, 2021 Author Share Posted June 14, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted June 14, 2021 Share Posted June 14, 2021 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 2 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted July 21, 2021 Share Posted July 21, 2021 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 ? Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted July 21, 2021 Author Share Posted July 21, 2021 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? Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted July 21, 2021 Author Share Posted July 21, 2021 You could also free up more scratchpad by copying it onto the VDP stack and restoring it. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.