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

[+9640News]

OK, no problem.

 

On another note, I do now have a MDOS terminal program allowing me to log into the TIPI at localhost:23.  That gives me 80 column capability which is better than the Telnet capability I had on the 4A side where my choices were 40 or 64 columns.

 

I still need to clean the code up a bit for the IAC handling, but at least it is working.

 

Beery

[+9640News]

Matt,

 

I think I have found a bug in the TIPI read code that only happens when the code is being executed in a Server environment.  It appears to not be an issue when in a Client environment.

 

I have a routine where I added a loop to display a counter on the screen that is incremented each time I go into the routine . In the Server environment, I send out a request for a single character response from the client.  If there is no client attached to the server, my counter continuously increases as the TIPI code returns with an error as no socket is bound/attached.  However, if I have a client is attached, the Read routine waits for a character.  It never exits to allow me to return to loop again.  I know it is in the routine, as if I hit any character, then the server responds.  It is just sitting there waiting.  

 

I know with MyTerm I modified, as a Client there is no issue with no response.  It appears to be only occurring when doing a Read in the Server environment.

 

Beery

 

 

[+jedimatt42]

17 hours ago, BeeryMiller said:

Matt,

 

I think I have found a bug in the TIPI read code that only happens when the code is being executed in a Server environment.  It appears to not be an issue when in a Client environment.

 

I have a routine where I added a loop to display a counter on the screen that is incremented each time I go into the routine . In the Server environment, I send out a request for a single character response from the client.  If there is no client attached to the server, my counter continuously increases as the TIPI code returns with an error as no socket is bound/attached.  However, if I have a client is attached, the Read routine waits for a character.  It never exits to allow me to return to loop again.  I know it is in the routine, as if I hit any character, then the server responds.  It is just sitting there waiting.  

 

I know with MyTerm I modified, as a Client there is no issue with no response.  It appears to be only occurring when doing a Read in the Server environment.

 

Beery

 

 

 

Totally plausible... I'll have to take a look. ... ... ... Yep, I don't have any code to put the server side of the socket in non-blocking mode...    The beauty of free software.  I can probably fix it this week. 

 

-M@

 

[+9640News]

5 hours ago, jedimatt42 said:

 

Totally plausible... I'll have to take a look. ... ... ... Yep, I don't have any code to put the server side of the socket in non-blocking mode...    The beauty of free software.  I can probably fix it this week. 

 

-M@

 

Thanks Matt. Much appreciated.

 

Beery

[+9640News]

Matt,

 

Just a general question about the buffer(s) on the socket interface.  Is there a cap on the outbound socket interface before one gets an overrun condition?  I'm assuming on the inbound to the PI, the PI can negotiate that, however, I am asking if in a TIPI server environment if I send out some data stream faster than the client can receive it, is there a capacity limitation?

 

For example, if I send a text file out of a particular size, and the client pauses their data stream, how much data can be sent out before there is a buffer overrun?  I know the socket Write command has error code reporting, but is that only for if the socket drops connection, or would it also include the situation if the buffer was overrun?

 

Right now, just trying to understand if this may be something I need to plan long term.  

 

Beery

 

 

 

[+9640News]

Matt,

 

I have not been able to chase it down yet, but I am thinking there is some kind of underlying issue with the latest update (1.51) for the PI.  I'm hoping my description of what I am seeing will allow you to direct what I may need to do to help identify the issue (log files, etc).

 

For some reason, I believe some kind of communication between the PI and the TIPI is being lost.  I'll try and describe what I am seeing and this seems to be occurring after some period of time (hours).  In V1.50, I was online for 24'ish hours of testing without an issue with multiple calls with intentional client driven disconnects versus server driven disconnects.  With V1.51, things work ok for awhile as one would expect, then it doesn't.

 

After a user either disconnects from the "AfterHours server (BBS)", or from a timout, the board resets.  It sits in a loop checking the connection to see if there is a connection to accept about once every second or so.  I see the TIPI LED on the sidecar flashing so I know when it is interrogating the PI.  At a point in time, when a connection comes through, the LED stops blinking.  What should be happening at this step is that a file is retrieved and read (DV80 file) and it is sent back to the client character by character.  This does not happen.  This also happens with a local keyboard login, so I think something is going on in the accept part of the connection.

 

If I reset the TI, and reload the server program and a client attempts to call back in, the same thing happens again.  A connection is recognized, but no file sent.  I can repeat this multiple times calling and multiple times rebooting the TI with either a client connection attempt or a keyboard login attempt.

 

What I can then do is go and load TIPICFG.  TIPICFG loads fine.  I have been able to recover from this "stuck" server operation by Rebooting the PI.  Then, everything works fine again for a period of time until the cycle repeats itself, typically after a number of hours.

 

If it was a software programming issue on my end, I would think resetting the title screen back to the main menu would resolve itself when I would rerun the program.  It is only after I use TIPICFG to Reboot the PI does the issue clear itself.

 

I've looked at your TIPI DSR code and I think I could implement a PI reboot after every server connection, but I think we would both agree that is only a band-aid to the issue.

 

If there is a Log file you think that would help, then I would need to know how to get to the log files in question (chdir, etc) after a localhost:23 telnet connection and copy it to a path like TIPI.DSK1.  Or, I could attach a monitor/keyboard to the PI if that route would be simpler.  

 

Anyways, I hope what I wrote you might have an idea to the issue.  And I do really appreciate your support you have given for the TIPI.

Beery

 

 

[+arcadeshopper]

I'd look in the TIPI log and the daemon one Matt posted before you can ssh in from your pc to get to them.. send me a pm if you need more help

Sent from my LM-G820 using Tapatalk

[+9640News]

47 minutes ago, arcadeshopper said:

I'd look in the TIPI log and the daemon one Matt posted before you can ssh in from your pc to get to them.. send me a pm if you need more help

Sent from my LM-G820 using Tapatalk
 

I'm going to need some help there as maneuvering around the PI structure, is a bit foreign to me.  I'll PM you.

Beery

 

[+jedimatt42]

Yep, it sounds like some sort of cleanup/resource exhaustion. 

 

Once it is in failure state, before rebooting anything, from a PC with an sftp client:

 

sftp tipi@tipi

get /var/log/tipi/tipi.log

get /var/log/daemon.log

exit

 

Maybe in the next update I should add a windows share for the logs. 

 

-M@

 

[+9640News]

4 hours ago, jedimatt42 said:

Yep, it sounds like some sort of cleanup/resource exhaustion. 

 

Once it is in failure state, before rebooting anything, from a PC with an sftp client:

 

sftp tipi@tipi

get /var/log/tipi/tipi.log

get /var/log/daemon.log

exit

 

Maybe in the next update I should add a windows share for the logs. 

 

-M@

 

I did see this in the daemon.log file, but I have slept since, and I thought the connection issue hit after I left for work which would have been 6:30 EST, but it looks like the log file may be off an hour.

 

Mar 13 14:59:22 tipi3 systemd[1]: tipi.service: Main process exited, code=killed                          , status=15/TERM
Mar 13 14:59:22 tipi3 systemd[1]: tipi.service: Succeeded.
Mar 13 14:59:22 tipi3 systemd[1]: Stopped TI-99/4A DSR Service.
Mar 13 14:59:22 tipi3 systemd[1]: Started TI-99/4A DSR Service.
Mar 13 14:59:22 tipi3 systemd[1]: Stopping TI-99/4A DSR Service...
Mar 13 14:59:22 tipi3 systemd[1]: tipi.service: Main process exited, code=killed                          , status=15/TERM
Mar 13 14:59:22 tipi3 systemd[1]: tipi.service: Succeeded.
Mar 13 14:59:22 tipi3 systemd[1]: Stopped TI-99/4A DSR Service.
Mar 13 14:59:22 tipi3 systemd[1]: Started TI-99/4A DSR Service.
Mar 13 14:59:23 tipi3 systemd[1]: Stopping TI-99/4A DSR Service...
Mar 13 14:59:23 tipi3 systemd[1]: tipi.service: Main process exited, code=killed                          , status=15/TERM
Mar 13 14:59:23 tipi3 systemd[1]: tipi.service: Succeeded.
Mar 13 14:59:23 tipi3 systemd[1]: Stopped TI-99/4A DSR Service.
Mar 13 14:59:23 tipi3 systemd[1]: tipi.service: Start request repeated too quick                          ly.
Mar 13 14:59:23 tipi3 systemd[1]: tipi.service: Failed with result 'start-limit-                          hit'.
Mar 13 14:59:23 tipi3 systemd[1]: Failed to start TI-99/4A DSR Service.
Mar 13 14:59:23 tipi3 tipiwatchdog.sh[586]: Job for tipi.service failed.
Mar 13 14:59:23 tipi3 tipiwatchdog.sh[586]: See "systemctl status tipi.service"                           and "journalctl -xe" for details.
Mar 13 14:59:23 tipi3 systemd[1]: tipi.service: Start request repeated too quick                          ly.
Mar 13 14:59:23 tipi3 systemd[1]: tipi.service: Failed with result 'start-limit-                          hit'.
Mar 13 14:59:23 tipi3 systemd[1]: Failed to start TI-99/4A DSR Service.
Mar 13 14:59:23 tipi3 tipiwatchdog.sh[586]: Job for tipi.service failed.

 

daemon.log tipi.log tipi.log.1

Edited March 14, 2020 by BeeryMiller

[+9640News]

Matt, not aiming this specifically at you, just general with the mouse programming on the TIPI.

 

While I am in a holding pattern on another project, I've been playing with code to interface the mouse to the MDOS side of things.  Back in the early 90's, Bruce Hellstrom wrote software drivers that used either the Myarc Mouse on the Geneve 9640 or a serial mouse that plugged into the RS232 card.  These drivers installed themselves into the operating system of MDOS and could be activated by a command in the user's task page 0.  The mouse would work in all text and all graphic modes. Once activated, they ran from the interrupts and updated a set of command registers with location, speed, button pressed, and a couple of other bytes of info.

 

With the 9938 and the Vid XOP calls, MDOS returned to the driver the precise x/y location.  With the serial mouse, there was a bit more work to work out the initialization and the data fed back.  I've seen 3, 4, and 5 byte sequences that could be reported in the serial code.

 

I've got the calls to the TIPI for the mouse written into the XOP, and I can see the changes in direction left/right, up/down.  Trying to work that bit into the driver code now.  The serial code wasn't clearly commented in the interface, and I was hoping to get some feedback from anyone that may have messed around with software controlling the mouse on the 4A.

 

Any thoughts on if it is better to incorporate a change in the x or y direction by a pixel at a time, or the full change the mouse has measured?  I ran a rough test outside the driver code and I could see a change of "1" to over "10".  Just trying to get a feel for movement.  It's easier to INC/DEC a value, than dealing with negative numbers than the additional hurdle if adding/subtracting pushes the mouse location outside the boundaries of the screen across all the various modes.

 

I'm still trying to understand how the TIPI returns three bytes for x, y, and buttons.  I can move the single byte into a register, and do a SRL and it knows if it was a negative or positive direction movement as I could see >FFF0 or >0010 depending upon the direction of movement when I display the register's content.

 

FWIW, I've got a two button wireless mouse with a scroll wheel between the two buttons.  It correctly reports the bits for the button, but also has additional reporting beyond those three buttons.  Matt, any significance?

 

Beery

 

 

[+jedimatt42]

The source code in assembly for my ti-artist driver may be of use to you. See the link in the mouse extension docs.

 

It reads and interprets the x,y deltas and button data. Then scales it by 5/8. 

 

Movement is joystick like if you move one pixel at a time. That sucks. 

 

-M@

[+9640News]

18 minutes ago, jedimatt42 said:

The source code in assembly for my ti-artist driver may be of use to you. See the link in the mouse extension docs.

 

It reads and interprets the x,y deltas and button data. Then scales it by 5/8. 

 

Movement is joystick like if you move one pixel at a time. That sucks. 

 

-M@

Thanks for that information Matt.  I browsed the TI-Artist code but will need to dig back into it again.  I probably will not get to dig back into it again until this weekend as it looks like I will turn into a plumber for my parents this evening.

 

Beery

 

[+9640News]

Matt, just a quick question.  Did you have time to review the log reports I posted above?  If you did, did it shed any light on the resources issue?

 

Beery

[Stuart]

On 3/17/2020 at 3:04 PM, BeeryMiller said:

Matt, not aiming this specifically at you, just general with the mouse programming on the TIPI.

 

While I am in a holding pattern on another project, I've been playing with code to interface the mouse to the MDOS side of things.  Back in the early 90's, Bruce Hellstrom wrote software drivers that used either the Myarc Mouse on the Geneve 9640 or a serial mouse that plugged into the RS232 card.  These drivers installed themselves into the operating system of MDOS and could be activated by a command in the user's task page 0.  The mouse would work in all text and all graphic modes. Once activated, they ran from the interrupts and updated a set of command registers with location, speed, button pressed, and a couple of other bytes of info.

 

With the 9938 and the Vid XOP calls, MDOS returned to the driver the precise x/y location.  With the serial mouse, there was a bit more work to work out the initialization and the data fed back.  I've seen 3, 4, and 5 byte sequences that could be reported in the serial code.

 

I've got the calls to the TIPI for the mouse written into the XOP, and I can see the changes in direction left/right, up/down.  Trying to work that bit into the driver code now.  The serial code wasn't clearly commented in the interface, and I was hoping to get some feedback from anyone that may have messed around with software controlling the mouse on the 4A.

 

Any thoughts on if it is better to incorporate a change in the x or y direction by a pixel at a time, or the full change the mouse has measured?  I ran a rough test outside the driver code and I could see a change of "1" to over "10".  Just trying to get a feel for movement.  It's easier to INC/DEC a value, than dealing with negative numbers than the additional hurdle if adding/subtracting pushes the mouse location outside the boundaries of the screen across all the various modes.

 

I'm still trying to understand how the TIPI returns three bytes for x, y, and buttons.  I can move the single byte into a register, and do a SRL and it knows if it was a negative or positive direction movement as I could see >FFF0 or >0010 depending upon the direction of movement when I display the register's content.

 

FWIW, I've got a two button wireless mouse with a scroll wheel between the two buttons.  It correctly reports the bits for the button, but also has additional reporting beyond those three buttons.  Matt, any significance?

 

Beery

 

 

For my Internet Browser, I took the simple approach of just checking in what direction the mouse is moving, and ignoring how fast the mouse was moving. The screen resolution for the TI is so low that trying to implement any form of mouse 'acceleration' didn't really seem worth the effort. I move the cursor two pixels at a time which is fine for the browser but no use of course for any drawing-type programmes. I've copied below the mouse code in case it is of any use.

*No key pressed and no joystick movement. Check if any movement from TIPI mouse.

CHKMSE  BL   @RDTPMSE       Read data from TIPI mouse. Data returned in buffer MSEBUFF.

        CLR  R4             Flag to indicate if there was mouse movement.

        CLR  R1
        MOVB @MSEBUFF,R1    Get horizontal movement. This is:
*                           >00 = no horizontal movement
*                           >FF (slow) - >81 (fast) = movement left
*                           >01 (slow) - >7F (fast) = movement right
        JEQ  CHKMSE2        No horizontal movement. Check vertical.
        SETO R4             Set flag to indicate mouse movement. (Instruction doesn't affect any status bits)
        JGT  CHKMSE4        Jump if movement to the right.
        DECT R2             Movement is to the left. Decrement X position.
        JMP  CHKMSE2
CHKMSE4 INCT R2             Increment X position.

CHKMSE2 MOVB @MSEBUFF+1,R1  Get vertical movement. This is:
*                           >00 = no vertical movement
*                           >FF (slow) - >81 (fast) = movement up
*                           >01 (slow) - >7F (fast) = movement down
        JEQ  CHKMSE3        No vertical movement. Check button.
        SETO R4             Set flag to indicate mouse movement. (Instruction doesn't affect any status bits)
        JGT  CHKMSE5        Jump if movement down.
        DECT R3             Movement is up. Decrement Y position.
        JMP  CHKMSE3
CHKMSE5 INCT R3             Increment Y position.

CHKMSE3 MOVB @MSEBUFF+2,R1  Get button press. This is:
*                           >x8 = no button press
*                           >x9 = left button press
*                           >xA = right button press (not used by the browser)

        ANDI R1,>0F00       Isolate required nibble.
        CI   R1,>0900       Left button press?
        JEQ  JOYFIRE        Yes. Jump to routine that handles keyboard <ENTER> key (via joystick routine as jump out of range).

        MOV  R4,R4          Flag set to indicate mouse movement?
        JEQ  MSST001        No, jump to continue.
        B    @MSSP10        Yes, process new sprite position.
        
****************************************************************
*Subroutine - read data from TIPI mouse.
*Call: BL @RDTPMSE
****************************************************************

RDTPMSE MOV  R11,@SAVR11    Save return address.
  
        LI   R1,1           Number of bytes in message to send.
        MOV  R1,@GPLWSR0    Save in GPL workspace R0.
        LI   R1,B20         Address of message to send.
        MOV  R1,@GPLWSR1    Save in GPL workspace R1.
        MOV  @MSEBUFA,@TIPIBUF  Set TIPI buffer address.

        BL   @TIPICOM       Send TIPI command message and get result, which is three bytes -
*                           horizontal movement, vertical movement, and button press.

        MOV  @SAVR11,R11    Restore return address.

        B    *R11           Return.        

 

[+jedimatt42]

8 hours ago, BeeryMiller said:

Matt, just a quick question.  Did you have time to review the log reports I posted above?  If you did, did it shed any light on the resources issue?

 

Beery

It looks like the reset signal happened too many times, and the Linux service manager decided to stop restarting it. I need to tune the tipi.service file to disable that limitation. 

 

-M@

[+jedimatt42]

Back on mouse, I found mouse joystick emulation unnatural in the 80s and still do today.  I had good luck scaling with a simple multiply then divide. And it is fun to use instructions that many CPUs in the era didn't even have. Complex Instruction Set for the win!

 

-M@

[+9640News]

1 hour ago, jedimatt42 said:

It looks like the reset signal happened too many times, and the Linux service manager decided to stop restarting it. I need to tune the tipi.service file to disable that limitation. 

 

-M@

Thanks for the feedback.  At least there is a game plan.

 

Beery

 

[+9640News]

2 hours ago, Stuart said:

For my Internet Browser, I took the simple approach of just checking in what direction the mouse is moving, and ignoring how fast the mouse was moving. The screen resolution for the TI is so low that trying to implement any form of mouse 'acceleration' didn't really seem worth the effort. I move the cursor two pixels at a time which is fine for the browser but no use of course for any drawing-type programmes. I've copied below the mouse code in case it is of any use.

 

Got the code and thanks for the feedback.  Another way to skin the cat and keeps things simple.

 

Beery

[+jedimatt42]

13 hours ago, BeeryMiller said:

Got the code and thanks for the feedback.  Another way to skin the cat and keeps things simple.

 

Beery

BOO.

 

Scaling the value isn't difficult, and you will end up with a much more mouse like feel.  

 

Sad face emoji

 

[+jedimatt42]

13 hours ago, BeeryMiller said:

Got the code and thanks for the feedback.  Another way to skin the cat and keeps things simple.

 

Beery

Really?

 

You guys have way more practice and experience with assembly.

 

Why bother giving people a mouse that acts like arrow keys?

 

Come on, step up...

 

-M@

 

(Paid for by the solo campaign to prevent crappy mouse experience and try to apply pressure through public shaming)

[GDMike]

Great Way to escalate

[+9640News]

34 minutes ago, jedimatt42 said:

Really?

 

You guys have way more practice and experience with assembly.

 

Why bother giving people a mouse that acts like arrow keys?

 

Come on, step up...

 

-M@

 

(Paid for by the solo campaign to prevent crappy mouse experience and try to apply pressure through public shaming)

There is more to the mouse driver than what you or others may realize.

 

I am sure I will pull pieces from both the TI-Artist example and the browser example.

 

The mouse driver code for MDOS is interrupt driven.  

 

When Bruce Hellstrom back in the 90's wrote the driver code, you wrote a byte at a specific memory location that turned on the mouse usage for the program currently running.  In principal, you could have the mouse driver running in multiple programs and reporting position to multiple programs.

 

Once it was turned on for a program, there were byte registers of some number of bytes that reported x position, y position, left-button position, middle-button position, right-button position, and mouse speed.  There was also a "command" register byte, and another byte or two that I would need to pull documentation to remember.

 

As the driver worked in all text modes and all graphic modes, mouse speed and scale of speed needed to be different dependent upon video mode.  The driver is very functional and very smooth and behaves as one would expect say on a Mac or Windows system.  However, keep in mind that in text mode, it is not a sprite character being moved but a crosshairs character (+ character) that is moved and the underlying character read/replaced. 

 

In text mode, one can not move a pixel at a time.  In theory, I guess one could if you read a 2 x 2 character block on the screen and "overlaid" a pointer over that 2 x 2 block and replaced the character definitions and substituted new characters for the new definition.  Don't ask me to write any such code as it is more than I would want to even consider.

 

In graphic modes though, just define a sprite, and move whatever direction needed and you program the speed for mouse movement into the program.  

 

FWIW, my assembly programming skills are not advanced.  If it had not been for the Geneve and MDOS and the use of the XOP libraries, I would likely never have ventured beyond any programming besides extended basic on the TI-99/4A.  My attempts at assembly on the TI-99/4A were very crude as I just did not have a good grasp of the internals for lack of material and good published examples of working source code 30 years ago.  With MDOS, it was 4 lines of code using an XOP and I could reference a PAB and what I wanted went where I told it to go.  If I wanted to write text to a graphics screen, it was 3 lines of code to set the video mode, and 4 lines of code plus the text string to write the contents to the screen.  The operating system did the rest for me.

So, what I am saying is while I can program in assembly and follow other's code and make tweaks, some of what comes more naturally to others is not as obvious to me at this point in time.

 

Beery

 

[+jedimatt42]

Strategies: if the Geneve side contract involves scaling anyway... Since the contract requires a virtual screen, that the driver just returns current location from, you have to scale the movement, then apply it to the virtual pointer location... You could also just create a virtual screen of typical PC proportions... 1280 x 1024 or something more correct... then apply the TIPI mouse deltas raw... Then based on screen resolution, scale the current mouse location when it is requested. 

 

Maybe the real question is, exactly why would you build a TIPI based mouse driver for a Geneve? That already has a native mouse?  You can get one of the dozens of usb(ps2)Amiga mouse adapters, and adapt them ?  Or smally mouse? Fabrice's website details converting Atari ST to Geneve, converting from Amiga to Atari ST is easy too...  Or the device Shift838 produced.  There will never be a shortage of native mouse solutions for the Geneve again.

 

But whatever floats your boat... When I use a piece of software that treats the mouse like arrow keys, I just prefer to use actual arrow keys.

 

Keep in mind, I'm not your audience. So don't let me stop you from your fun.

 

-M@

 

 

[+9640News]

I'll have my fun <grin>.

 

And you are right, there is a mouse already for the Geneve.  However, I did not have a mouse for my Geneve I could use until Shift838 produced his device a few months ago.  I have 2 Geneves I am using, and a third that is unstable but only one mouse I can use via Shift838's interface.  At this junction, I do not know if there would be more than 2 or 3 people that would even use a mouse driver, though it is my intent to get it up and useable and equivalent to the regular Geneve mouse as options.

 

Right now, I am just building various pieces of code to use the TIPI on the Geneve and learning/testing the capabilities.  Not sure yet where it will finally end, though some of the additional functionality you have added increases the potential I can see, just do not know if I can get there myself.

 

Time will tell.