TIPI Usage and Support

[+9640News]

56 minutes ago, jedimatt42 said:

Oh, a gotcha... if your arks are V9T9, they would also show up on the TIPI as DF128, but the 4A software would get confused because the v9t9 header would be read as a record... If they have no TIFILES or V9T9 header, then they might work... SID files work for me in this way.

All of these files, at least initially, were uploaded via XMODEM from TI computers as the starting point if they have the .ARK extension.  These files are old enough that V9T9 did not exist at that time.

 

An exception I am not sure about would be some GIF files back in the 90's.  I would have to look at them individually to see if they had TIFILE headers or GIF97a (I think that was the header/tag) for the files from the early days in the first record.

 

Beery

2 hours ago, jedimatt42 said:

https://github.com/jedimatt42/tipi/wiki/File-name-rules

 

Thanks for that link.  It was what I was looking for but got distracted with the AUTO DSK1 capability and then missed that topic.  Most of my TIPI use has been on the Geneve so I haven't done directory listings with anything on it, rather using Windows sharing to view things along with TIDIR.

 

Beery

[+InsaneMultitasker]

Looking for a quick clarification:

 

From your Telnet code -  when reading from a socket, you are sending a message including a buffer size (see output[3,4]) via tipi_sendmsg.  Buffer size is initialized at 0?  Then in the tipi_recvmsg routine, it looks like R0 is initialized to the buffer length prior to calling the routine at >4010.   How does TIPI know how much data to return - is it controlled by the sent message or GPLWS R0?

 

 

int read_socket() {
  output[0] = TI_SOCKET_REQUEST;
  output[1] = socketId;
  output[2] = TI_SOCKET_READ;
  output[3] = 2; // buffer size is 512 bytes
  output[4] = 0;
  tipi_on();
  tipi_sendmsg(5, output);
  int bufsize = 0;
  tipi_recvmsg(&bufsize, buffer);
  tipi_off();
  return bufsize;

 

void tipi_recvmsg(unsigned int* len, unsigned char* buf)
{
  GPLWS_R0 = (unsigned int)*len;
  GPLWS_R1 = (unsigned int)buf;
  __asm__("lwpi >83E0\n\tmov @>4010,r4\n\tbl *r4\n\tlwpi >8300");
  *len = GPLWS_R0;

[+jedimatt42]

2 hours ago, InsaneMultitasker said:

Looking for a quick clarification:

 

From your Telnet code -  when reading from a socket, you are sending a message including a buffer size (see output[3,4]) via tipi_sendmsg.  Buffer size is initialized at 0?  Then in the tipi_recvmsg routine, it looks like R0 is initialized to the buffer length prior to calling the routine at >4010.   How does TIPI know how much data to return - is it controlled by the sent message or GPLWS R0?

 

 

int read_socket() {
  output[0] = TI_SOCKET_REQUEST;
  output[1] = socketId;
  output[2] = TI_SOCKET_READ;
  output[3] = 2; // buffer size is 512 bytes
  output[4] = 0;
  tipi_on();
  tipi_sendmsg(5, output);
  int bufsize = 0;
  tipi_recvmsg(&bufsize, buffer);
  tipi_off();
  return bufsize;

 

void tipi_recvmsg(unsigned int* len, unsigned char* buf)
{
  GPLWS_R0 = (unsigned int)*len;
  GPLWS_R1 = (unsigned int)buf;
  __asm__("lwpi >83E0\n\tmov @>4010,r4\n\tbl *r4\n\tlwpi >8300");
  *len = GPLWS_R0;

 

There are layers to the protocol...

 

the tipi protocol for recvmsg doesn't consume a buffer limit... you just better not overrun.... too much hassle... retro computing... good enough... 

 

The socket protocol is layered over that... You send a _message_ containing the socket read request, including in that message the size of the buffer you intend to read into. 

Then you use recvmsg to read into that buffer. The routine stored in ROM who's address is at >4010 leaves the read size in R0 of the workspace it was called from. 

 

From gcc, I borrow the GPLWS so the ROM routines can use a full workspace and not worry about the state of the gcc workspace. 

 

[+InsaneMultitasker]

16 minutes ago, jedimatt42 said:

 

There are layers to the protocol...

 

the tipi protocol for recvmsg doesn't consume a buffer limit... you just better not overrun.... too much hassle... retro computing... good enough... 

 

The socket protocol is layered over that... You send a _message_ containing the socket read request, including in that message the size of the buffer you intend to read into. 

Then you use recvmsg to read into that buffer. The routine stored in ROM who's address is at >4010 leaves the read size in R0 of the workspace it was called from. 

 

From gcc, I borrow the GPLWS so the ROM routines can use a full workspace and not worry about the state of the gcc workspace. 

 

Layers makes sense but I feel like I'm missing the connection.  I start by sending a _message_ containing the read request and specify the intended buffer size as 512 bytes per above sample. Got it.

 

However... before I call recvmsg, GPLWS R0 is set to the buffer length.  Must/should R0 be set equal to or less than what was contained in the _message_?   I understand that >4010 returns the read size.   

 

Example:  in my latest test code I send a _message_ with an intended buffer size of 8192 bytes then I call >4010 with GPLWS R0 set to 512.  GPLWS R0 returns how many bytes TIPI sent into the buffer; I drain that buffer then start the process over again.

[+jedimatt42]

50 minutes ago, InsaneMultitasker said:

Layers makes sense but I feel like I'm missing the connection.  I start by sending a _message_ containing the read request and specify the intended buffer size as 512 bytes per above sample. Got it.

 

However... before I call recvmsg, GPLWS R0 is set to the buffer length.  Must/should R0 be set equal to or less than what was contained in the _message_?   I understand that >4010 returns the read size.   

 

Example:  in my latest test code I send a _message_ with an intended buffer size of 8192 bytes then I call >4010 with GPLWS R0 set to 512.  GPLWS R0 returns how many bytes TIPI sent into the buffer; I drain that buffer then start the process over again.

 

Sorry, you are confusing code with requirement...  when GPLWS R0 is set before the actual recvmsg call, that might as well be a CLR R0... it is a remnant from a time when I thought I'd care to make things more robust... 

 

[+jedimatt42]

7 minutes ago, jedimatt42 said:

 

Sorry, you are confusing code with requirement...  when GPLWS R0 is set before the actual recvmsg call, that might as well be a CLR R0... it is a remnant from a time when I thought I'd care to make things more robust... 

 

 

Maybe you'd better be served by some assembly language example code.. Stuart has some on his website:  search for RCVRSP2  on this page: http://www.stuartconner.me.uk/ti/ti.htm#internet_web_browser

 

[+InsaneMultitasker]

18 minutes ago, jedimatt42 said:

 

Maybe you'd better be served by some assembly language example code.. Stuart has some on his website:  search for RCVRSP2  on this page: http://www.stuartconner.me.uk/ti/ti.htm#internet_web_browser

 

Thanks.  I found my way there by looking at the TIPI routine table on the raw extensions wiki page where there is a comment, "To access these routines, see examples/telnet/tipi_msg.c".   I was trying to understand yours and Beery's TIPI code versus just modifying things 'to work'.   I'll review Stuart's code tomorrow and I also see there is a TCP extension wiki page with more good detail.  

[+jedimatt42]

TIPI Update - v1.63 - 2020-06-06 

 

- TiSocket open command would crash, and leave a client hanging, on bad hostname + ':' + port string in request.   Now it returns a failure to open immediately.

[+jedimatt42]

TIPI ROM Update - 2020-05-25 - ( Cause not many of you need it ) - https://www.jedimatt42.com/downloads.html

 

Fix some MOV that should have been MOVB, which behaves differently on the Geneve than the 4A when the sources is the VDP read data port. Impacted error code handing for LVL2 IO routines. 

[+jedimatt42]

15 hours ago, jedimatt42 said:

TIPI ROM Update - 2020-05-25 - ( Cause not many of you need it ) - https://www.jedimatt42.com/downloads.html

 

Fix some MOV that should have been MOVB, which behaves differently on the Geneve than the 4A when the sources is the VDP read data port. Impacted error code handing for LVL2 IO routines. 

 

You won't experience this bug on a 4A. The fix is compatible with both the 4A and the Geneve. 

It should go without saying that a sideport TIPI doesn't need a fix that only helps on a PEB based Geneve. 

[+arcadeshopper]

2 minutes ago, jedimatt42 said:

 

You won't experience this bug on a 4A. The fix is compatible with both the 4A and the Geneve. 

It should go without saying that a sideport TIPI doesn't need a fix that only helps on a PEB based Geneve. 

Any Geneve users that need this DSR update I have a exchange service on arcadeshopper.com or you can purchase a new rom..whatever you like

[Nick99]

13 minutes ago, arcadeshopper said:

Any Geneve users that need this DSR update I have a exchange service on arcadeshopper.com or you can purchase a new rom..whatever you like

I will order a new rom soon. 

[+9640News]

I'm assuming a TL866CS will burn the eprom?

 

Beery

[+arcadeshopper]

2 hours ago, BeeryMiller said:

I'm assuming a TL866CS will burn the eprom?

 

Beery

yes its just a 27c256  any burner should be able to handle that.. the image is in the link above or on the github/wiki 

[+9640News]

42 minutes ago, arcadeshopper said:

yes its just a 27c256  any burner should be able to handle that.. the image is in the link above or on the github/wiki 

Thanks.

Beery

[ElectricLab]

If someone messaged me on myti99.com using their browser, please re-send here on AA. There was (and still is) a bug in that webpage that munges the data and I got a garbled email instead.

I think it may have been about a password reset, but I couldn't tell.

[+jedimatt42]

So, coming up in the upgrades for TIPI, will be python2 -> python3 conversion of the services... latest version of xdt99, hopefully integration of code to make the emulation support 'common'...

 

However, many of you who have been on this journey since early days, maybe be on systems that have 'upgraded' from raspbian Jessie or Stretch. The python3 work is going to require buster, and I'll have to prevent systems still running Jessie or Stretch from upgrading.  Updated SD card image will be provided when this goes out... and users on 'buster' should still be able to upgrade. 

 

So, now is a good time to start thinking about your backup strategy... periodically copying the TIPI share off to a PC before you run upgrades... etc... 

 

I've also added a note, that unless you are in expert mode doing development of the tipi services, master branch is not for you!  I will be disabling the upgrade process for the master branch completely, because I often check in things there that aren't complete. 

 

 

[mr_gw454]

11 hours ago, jedimatt42 said:

So, coming up in the upgrades for TIPI, will be python2 -> python3 conversion of the services... latest version of xdt99, hopefully integration of code to make the emulation support 'common'...

 

However, many of you who have been on this journey since early days, maybe be on systems that have 'upgraded' from raspbian Jessie or Stretch. The python3 work is going to require buster, and I'll have to prevent systems still running Jessie or Stretch from upgrading.  Updated SD card image will be provided when this goes out... and users on 'buster' should still be able to upgrade. 

 

So, now is a good time to start thinking about your backup strategy... periodically copying the TIPI share off to a PC before you run upgrades... etc... 

 

I've also added a note, that unless you are in expert mode doing development of the tipi services, master branch is not for you!  I will be disabling the upgrade process for the master branch completely, because I often check in things there that aren't complete. 

 

 

The master branch issue is something I experienced (and thank you to you and Greg for getting me back up and running yesterday).  Fortunately, I make backup SD images frequently so it's easy to fall back to just before an attempted upgrade.  No idea on how my branch was set for 'master' rather than 'release' as I have not used any manual git commands.  Either way, it looks like you are addressing it in future upgrades.

 

A move to python3 is good and it makes sense.  Backing up our TIPI shares, etc., should not be an issue.  I actually installed tms9900-gcc and many other TI based development tools (which is why I occasionally ask you about things related to compiling fcmd, etc.).  I'll need to start over with those types of installations with a move to a current Raspbian version.

 

It goes without saying (but will anyway) how much I appreciate all your efforts with this project.  Thank you.

 

[+arcadeshopper]

@GDMike this is the support topic.

Did you read the wiki on how drive mapping works?

Sent from my LM-G820 using Tapatalk

[+jedimatt42]

@GDMike yes, typically TI software uses a DSRLNK routine that searches for a device by name starting from the lowest crubase and working itself up until it finds a Device Service Routine that elects to handle the device. 

 

TIPI provides the TIPI. device name, for primary use. It provides mapping device names DSK1-4 for use with legacy software that requires / assumes files on a legacy device name. 

 

So what you should do is entirely dependent on the requirements of the software you are trying to run. 

 

Automap is good enough for most things. Well, most things I run... 

 

Mapping is meant to be dynamic and fluid, not something you setup once and then just pretend you have a bunch of drives. TIPI should be thought of as providing one drive "TIPI." and providing flexible options for accessing it.

[Nick99]

Jedimatt, Is there a limitation of how big disk-images that can be transferred/extracted to TIPI via the TIPI:9900?

I have made a disk-image that is 1.44 meg, just to save time and being lazy, but it just copy the .dsk to the TIPI instead of extracting it.

It works fine with 360K disk, have not tried 720K.

[+jedimatt42]

1 minute ago, Nick99 said:

Jedimatt, Is there a limitation of how big disk-images that can be transferred/extracted to TIPI via the TIPI:9900?

I have made a disk-image that is 1.44 meg, just to save time and being lazy, but it just copy the .dsk to the TIPI instead of extracting it.

It works fine with 360K disk, have not tried 720K.

Is it a sector dump image??? TIPI delegates sector dump images to xdm99 from the xdt99 suite for file extraction. 

I wrote my own code to do trackdump to sector dump conversion, and I know there are a few sizes it doesn't work with as they are ambiguous... I intended to revisit, and let it just try one form and try the other if that doesnt' validate... 

 

I would expect xdm99 to work with 720k... that would be DSDD80... what tools are you using to do that with??  

 

TO SAVE TIME?  WHY?   Just open the file share, copy the FIADs over, no need to put them in a manufactured disk image... TIPI's DSK image is not meant to be the primary means of moving files... If the FIADs are v9t9 instead of TIFILES, you can still just copy them over, and then from the web-ui use the file actions to convert them to TIFILES.. you can multi-select...

[Nick99]

45 minutes ago, jedimatt42 said:

Is it a sector dump image??? TIPI delegates sector dump images to xdm99 from the xdt99 suite for file extraction. 

I wrote my own code to do trackdump to sector dump conversion, and I know there are a few sizes it doesn't work with as they are ambiguous... I intended to revisit, and let it just try one form and try the other if that doesnt' validate... 

 

I would expect xdm99 to work with 720k... that would be DSDD80... what tools are you using to do that with??  

 

TO SAVE TIME?  WHY?   Just open the file share, copy the FIADs over, no need to put them in a manufactured disk image... TIPI's DSK image is not meant to be the primary means of moving files... If the FIADs are v9t9 instead of TIFILES, you can still just copy them over, and then from the web-ui use the file actions to convert them to TIFILES.. you can multi-select...

Thanks,

I use TIDisk-Manager for OSX to create the disk image.

I´ve got alot of pics that I have painted on my PC´s an Mac´s through the years that I converted to GIF and want to view them on my TI. It didn't work by just moving the GIFs to the TIPI-folder, so I tried this way to get it in TI-format.

Edited June 22, 2020 by Nick99

[+jedimatt42]

Looking at the web-ui/automatic conversion TIPI does, I wasn't placing sectors in the correct place for MFM trackdump images... I've got a fix, but it is stacked behind the python 3 upgrade. Which will hopefully be this weekend... But maybe not...

[+jedimatt42]

Update 2.0 - 2020-06-30

* Python3.7 conversion / updates / fixes - This was about bringing the software stack up, since python2 is end-of-life already.

* fixes in for previous post mentions about unpacking track dump disk images 

 

The upgrade process from raspbian-stretch will not work. The automated upgrade process shouldn't let you proceed past 1.65. 

I will enable raspbian-buster upgrade tomorrow most likely - it's too late to get it done today. However it will take so long you will regret it and wish you just grabbed the new SD card image.  hours... 

 

There is a branch change... the 'release' branch is dead ending so 'stretch' images don't pull down the new code. 'buster' images will swap branchs to 'buster-release' automatically.  You don't need to know that... it'll just work, or you'll be stuck... or your internet will fail in the middle and through one form of frustration or another, you'll want the new sd card image..   

 

https://www.jedimatt42.com/downloads.html