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

[+jedimatt42]

I ssh in, and then use raspi-config to pull up the terminal menu tool. Then under network settings you can change hostname.

 

I usually do that while I'm in the same tool to grow the filesystem.

 

Lots more info under Raspbian OS stuff online.

 

-M@

[wolhess]

 

yep just make sure you have an account on myti99.com and log in with that same login on chatti..

 

I use a small ti basic program to load the latest off his webpage:

10 CALL TIPI("PI.HTTP://myti99.com/files/CHATTI")

also send me a message on there when you get on uid is gmcgill

 

Hi Greg,

 

Your Example works in TI BASIC.

 

I tried to call the chatti program from an XB program, but I got a "SUBPROGRAM NOT FOUND IN 10"

Is there a solution to do this in XB?

[+arcadeshopper]

 

Hi Greg,

 

Your Example works in TI BASIC.

 

I tried to call the chatti program from an XB program, but I got a "SUBPROGRAM NOT FOUND IN 10"

 

Is there a solution to do this in XB?

Sure. Use tursis loader in xb. I have it in my load prog on ftp.whtech.com under users and my name

 

Greg

 

Sent from my LG-H872 using Tapatalk

[wolhess]

Thank you for the fast answer,

 

I will take a look at this and make some tests.

[+jedimatt42]

This is a long standing issue with DSR extensions to BASIC. The specification for parameter passing expects the routine to parse the data out of VDP. With XB programs, the parameters are not always in VDP, as the code may be in expansion ram. So in XB, CALL does not search DSR ROMs for BASIC extensions except when in immediate mode ( no line number )

 

CALL TIPI is just an EA5 loader, that by default loads "TIPI.TIPICFG", it handles fairly longish names too...

 

If using another EA5 loader, like tursi's XB scratchpad loader, there is some name length restriction to recognize... You can programmatically set things like URI1 to HTTP://...... in XB by writing URI1=<value> to the PI.CONFIG file. Then use "URI1.FILENAME" to shorten the overall name. However, in your example I think you'll not run into a problem. If I recall scratchpad loader code supports names up to 64 characters.

 

URI1-3 were meant for this kind of programmatic setting... so I would get comfortable with expecting them to change dynamically as more software is developed.

 

-M@

[Tursi]

64 chars is correct for scratchpad loader.

[wolhess]

I did some tests with Tursis scratchpad loader and with the paragon ea5 loader and both are working for me.

 

Now I can run ea5 programs and I get access to PI.http... from standard XB.

 

Thank you.

[+9640News]

Matt,

 

I was reviewing the tipi-io.a99 file in the DSR source for the TIPI. Not being familiar with the utilities to turn the source into useable code, I see what looks like a macro(?) with a ".reset" and a ".transmit TSRB" instructions.

 

If this is indeed a macro, where would the definition, hopefully in assembly, for what that macro instruction(s) would be?

 

Beery

[+jedimatt42]

Just a little further up in the same file.

 

This code uses Ralph's xas99 assembler.

 

-M@

[+9640News]

Matt,

 

I think I have found a bug in the TIPI DSR with the Read (>04) & ReceiveMsg code processing.

 

If I load my program following a fresh powerup of the TIPI, when I go to see if I can read a byte of either length >1 or >0800 bytes, I get a character length of >01 with the character being a >00. This is without opening a connection/socket.

 

If I then open a connection, then read, all is well as I get a length of >00. I can "log off" a Telnet connection, and exit my program. Reloading my program where the TIPI has not powered up, I do not get a character length of >01, rather >00 when there is no connection if I had previously established a connection to a socket.

 

It seems on an initial powerup of the DSR, the ReceiveMsg routine may be defaulting to a wrong value initially????

 

What I am doing is loading a Telnet client where the connection may be still alive if I exited the program and returned, so I do not want to close it. Until I Open a Connection, the call to the Read connection is giving an incorrect response.

 

I think with your original telnet client, you defaulted to requesting the URL/Port right off the get go so the issue would likely not be seen.

 

I have tried closing the particular socket following a fresh powerup before reading the port with the same results.

 

Beery

 

 

 

 

[+jedimatt42]

Matt,

 

I think I have found a bug in the TIPI DSR with the Read (>04) & ReceiveMsg code processing.

 

If I load my program following a fresh powerup of the TIPI, when I go to see if I can read a byte of either length >1 or >0800 bytes, I get a character length of >01 with the character being a >00. This is without opening a connection/socket.

 

If I then open a connection, then read, all is well as I get a length of >00. I can "log off" a Telnet connection, and exit my program. Reloading my program where the TIPI has not powered up, I do not get a character length of >01, rather >00 when there is no connection if I had previously established a connection to a socket.

 

It seems on an initial powerup of the DSR, the ReceiveMsg routine may be defaulting to a wrong value initially????

 

What I am doing is loading a Telnet client where the connection may be still alive if I exited the program and returned, so I do not want to close it. Until I Open a Connection, the call to the Read connection is giving an incorrect response.

 

I think with your original telnet client, you defaulted to requesting the URL/Port right off the get go so the issue would likely not be seen.

 

I have tried closing the particular socket following a fresh powerup before reading the port with the same results.

 

Beery

 

 

 

 

 

What do you mean by "Reloading my program where the TIPI has not powered up..." ??? I can only assume you do not mean that it does not have power. And what is a 'fresh powerup' ??? How does someone make a powerup 'fresh' ??

 

TiSocket READ operation returns a msg of 1 byte in length with a NUL byte as the value if the socket is not connected. This is by design, but probably a poor choice. If you regularly perform reads with a single byte buffer, I can see how this is ambiguous. But, it only happens if the socket is not connected. I had to return some message, and by my reasoning any message would be ambiguous. Maybe a 0 length message would cause less trouble. But just don't read from a socket unless you have opened it first. Use a flag in your program to track if you are in an open state or not.

 

I really never designed the socket protocol for single byte buffers. And I didn't expect anyone to read from a socket they haven't opened yet.

 

open sockets do not survive the execution of the DSR ROM powerup routine in the TIPI EPROM. When that routine executes it kills the TipiService process, which releases all resources, closes any open sockets, etc..

 

The TiSocket protocol is not a part of a DSR in the ROM, nor is this a problem with the recvmsg routine in the ROM. So changing the protocol is just a python change. I'll have to test PLATOTERM, and my TELNET, but I suspect, since I failed to document this ( I have corrected the wiki documentation ) that nothing is dependent on the result of reading from a closed socket. So I should be able to change it to return an empty message without breaking anything. I've captured this as an issue: https://github.com/jedimatt42/tipi/issues/111

 

-M@

[+9640News]

 

What do you mean by "Reloading my program where the TIPI has not powered up..." ??? I can only assume you do not mean that it does not have power. And what is a 'fresh powerup' ??? How does someone make a powerup 'fresh' ??

 

TiSocket READ operation returns a msg of 1 byte in length with a NUL byte as the value if the socket is not connected. This is by design, but probably a poor choice. If you regularly perform reads with a single byte buffer, I can see how this is ambiguous. But, it only happens if the socket is not connected. I had to return some message, and by my reasoning any message would be ambiguous. Maybe a 0 length message would cause less trouble. But just don't read from a socket unless you have opened it first. Use a flag in your program to track if you are in an open state or not.

 

I really never designed the socket protocol for single byte buffers. And I didn't expect anyone to read from a socket they haven't opened yet.

 

open sockets do not survive the execution of the DSR ROM powerup routine in the TIPI EPROM. When that routine executes it kills the TipiService process, which releases all resources, closes any open sockets, etc..

 

The TiSocket protocol is not a part of a DSR in the ROM, nor is this a problem with the recvmsg routine in the ROM. So changing the protocol is just a python change. I'll have to test PLATOTERM, and my TELNET, but I suspect, since I failed to document this ( I have corrected the wiki documentation ) that nothing is dependent on the result of reading from a closed socket. So I should be able to change it to return an empty message without breaking anything. I've captured this as an issue: https://github.com/jedimatt42/tipi/issues/111

 

-M@

 

If it doesn't break anything, then returning a 0 length from the read length would be preferred.

 

As far as "What do you mean by "Reloading my program where the TIPI has not powered up..." , I meant this example.

 

I can load a program (terminal emulator) in MDOS. I can exit such program. If I reload the program again, the TIPI has not when through the DSR powerup cycle. If however, I do the CTRL-SHIFT-SHIFT (fresh powerup), then that forces a MDOS reboot causing the TIPI DSR Powerup routine to execute which in turns will give me a 1 byte length response which a character of "0".

 

I've actually modified the code in the terminal emulator to support grabbing up to >0800 bytes of incoming text which as one would expect, greatly increases the speed of data capture and very noticeable for screen displays. However, with XMODEM file transfer, the code is written for a single byte transfer. So, I do have cases where single byte transfers are a lot easier to handle. Unfortunately, the extra overhead versus RS232 I/O reduces a file transfer speed I see at 38,400 baud on a Telnet modem to an equivalent 9600 transfer speed on TIPI. I've got to figure out if I want to rewrite code for block transfers when truth be told, few people will be transferring large files in the first place.

 

Beery

[+9640News]

 

The TiSocket protocol is not a part of a DSR in the ROM, nor is this a problem with the recvmsg routine in the ROM. So changing the protocol is just a python change. I'll have to test PLATOTERM, and my TELNET, but I suspect, since I failed to document this ( I have corrected the wiki documentation ) that nothing is dependent on the result of reading from a closed socket. So I should be able to change it to return an empty message without breaking anything. I've captured this as an issue: https://github.com/jedimatt42/tipi/issues/111

 

-M@

 

Matt,

 

I saw in the issues section where you documented a change. Have you completed any PLATOTERM and TELNET testing to confirm this change does not impact those applications?

I've been looking for an update in the TIPICFG app, but have not seen anything since the post. I wasn't sure if the code change was a DSR change or a Python change after seeing the "fix" you described to know how the update would be rolled out should you roll it out.

Beery

[+arcadeshopper]

 

Matt,

 

I saw in the issues section where you documented a change. Have you completed any PLATOTERM and TELNET testing to confirm this change does not impact those applications?

I've been looking for an update in the TIPICFG app, but have not seen anything since the post. I wasn't sure if the code change was a DSR change or a Python change after seeing the "fix" you described to know how the update would be rolled out should you roll it out.

Beery

 

Matt's been pretty busy with real life the last week or three so probably he hasn't pushed the change to the public repo yet.

 

Greg

[+9640News]

 

Matt's been pretty busy with real life the last week or three so probably he hasn't pushed the change to the public repo yet.

 

Greg

 

Thanks. No problem. We all get busy at time with our non-TI or me, non-Geneve life.

 

Beery

[+jedimatt42]

I did a little testing with Telnet and Ftp. All was fine.

 

I usually announce updates in the support thread.

 

---

 

I am not sure why, Beery, you are not sure if this would be a python change or ROM change when in my last post I said it would be a python change. And the GitHub issue is referencing a line of python code. There is no python in the ROM. And as I tried to state before, the TiSocket protocol for TIPI is not in the ROM.

 

I guess I need to draw some architectural diagrams of the software stack.

 

---

 

I'll try and get the update out Friday evening.

 

-M@

[+9640News]

Thanks Matt. I know you said it was a Python code change. I saw your line code change, but that single note looked like it could have been a C routine leading me to think you may have decided to do something different. I have never looked at Python code.

 

Beery

[+9640News]

Matt,

 

On another note, I am seeing something in some of my coding I am not sure where the specific issue may be. I'm in a rural area, and presently having some intermittent but frequent drops in my internet connection.

 

Right now, when I want to receive some text, I am receiving a message of >1A00 bytes in my buffer for processing.

What happens with the python code and the DSR should there be a break in the internet connection and not all the bits of a character were received? Will the system hang somewhere in the receivemsg code?

 

I'm having some non consistent lockups in my code and I am trying to isolate the point of failure and it appears to be around the issue of a broken internet connection.

I just did not know how the PI and the Python code talked to the TIPI to know if there could be something going on there.

 

Beery

[+jedimatt42]

When using the socket API, the open sockets are configured to not block on read. So they read what is available, but return right away if there is no data.

 

There is a socket timeout at the TCP level, that usually results in a 2 minute block if using a socket that is unhealthy.

 

But I haven't seen a problem reading from a BBS telnet connection after it has disconnected.

 

Next time let it sit for 3 minutes and see if control returns to your program. The closest thing I have experienced is opening a bad port number. It eventually comes back.

 

-M@

[+9640News]

OK, I know I have not let it sit for 2 minutes. Maybe a minute, but not 2 or 3. Easy enough to do and test.

 

I'm at the very end of a long run for the cable. I'm lucky I even have cable internet capability. It has gotten worse the past week, so it is nearing time to call out AT&T again...........

 

Beery

[+jedimatt42]

Thanks Matt. I know you said it was a Python code change. I saw your line code change, but that single note looked like it could have been a C routine leading me to think you may have decided to do something different. I have never looked at Python code.

 

Beery

 

k.

 

The update is available now. v1.40 - just changes this contract as now described on the TCP extension page of the wiki... read now returns a 0 length array if the socket is not connected. -- tested Irata.Online, Telnet, FTP...

 

Chatti, snek, and chess do not use the TCP extension, so shouldn't be impacted.

 

-M@

[+9640News]

 

k.

 

The update is available now. v1.40 - just changes this contract as now described on the TCP extension page of the wiki... read now returns a 0 length array if the socket is not connected. -- tested Irata.Online, Telnet, FTP...

 

Chatti, snek, and chess do not use the TCP extension, so shouldn't be impacted.

 

-M@

 

Thanks Matt. Will be testing this evening.

Beery

[+9640News]

The update resolves the issue. Thanks.

 

Beery

[+jedimatt42]

The update resolves the issue. Thanks.

 

Beery

 

What about your hanging issue? I assume this does not address your hanging issue.

 

-M@

[+9640News]

The code still hung last night and I had a point where I waited from one commercial break into the next commercial break without it releasing.

 

I am not 100% sure on a separate issue, but the fix may have created another unintended behavior.

 

I went to "log out" of my BBS. When it goes to log out, it transmits a pretty large ANSI graphic of Garfield. I was playing a bit with the size of the receive buffer message code, so I am not sure if I was receiving something like >0400 bytes or >1A00 bytes at the time. Well, during the receive portion, it hung up which would have been the rapid send of the graphic, and then the BBS would have dropped the socket connection.

 

What I am wondering is what happens let's say if there are >2000 bytes in the graphic, I receive a fraction of it, go to display the data on the screen, and then by the time I go back to retrieve more, the connection has dropped. Will the receivemsg code continue to send me the buffered data until it has sent all the data, then send a length of zero, or does at the time the socket is dropped and it will return me with a length of 0 bytes even though it had buffered data before the connection was dropped?

 

I hope I explained that so it makes sense.

 

Beery