TIPI - Geneve 9640 to Raspberry PI interface development

[+9640News]

At this point, I was testing my code to make sure multiport handling was possible.  I didn't clearly see a way for the second (or more) server handle to know how to pass the server port handle off to the the client port write command unless the PI code was going to manage everything in the background.

 

Beery

[+jedimatt42]

16 minutes ago, 9640News said:

At this point, I was testing my code to make sure multiport handling was possible.  I didn't clearly see a way for the second (or more) server handle to know how to pass the server port handle off to the the client port write command unless the PI code was going to manage everything in the background.

 

Beery

 

The 9900 side of things uses these byte ids. For the bind, accept, and unbind operations those are keys to a map in memory on the PI that associate to the server socket. 

 

The accept returns an ID for the client, that is also just a byte, and is the key in a map on the PI again that associates to an actual open connection. On a server this is used then for the write, read, and close. This map is shared so the server socket id isn't needed to work with a connection after it has been accepted. 

 

It sounds like in each of your processes, the write from server to remote used client_id 0x01 regardless of the id returned by the accept. 

 

 

 

[+9640News]

22 minutes ago, jedimatt42 said:

 

The 9900 side of things uses these byte ids. For the bind, accept, and unbind operations those are keys to a map in memory on the PI that associate to the server socket. 

 

The accept returns an ID for the client, that is also just a byte, and is the key in a map on the PI again that associates to an actual open connection. On a server this is used then for the write, read, and close. This map is shared so the server socket id isn't needed to work with a connection after it has been accepted. 

 

It sounds like in each of your processes, the write from server to remote used client_id 0x01 regardless of the id returned by the accept. 

 

 

 

If I understand you correctly, you think it is a coding issue on my side?  If so, no problem then  I will dig deeper in my code and chase this down unless you think the PI side is not updating things between the client/server side of things. 

 

 

[+9640News]

Problem solved.

 

OK, I rechecked my server manager and then the programs and those were all ok.  Within the TIPI XOP library, dug into the opcode call and was moving the handle byte into the wrong message string. I corrected my error, and looks like all is well.

 

Beery

[+9640News]

The Geneve is now passing information off to 8 telnet clients from the "Server manager".  It is too many clients due to the time slices for each task, but it is what it is.  At least the TIPI/PI can handle it so that is good.  At best, I think a maximum of 4 programs (5 total counting the Server manager) and that is intercepting the time slices for each program is the acceptable limitation.

 

Beery

 

[+InsaneMultitasker]

2 hours ago, 9640News said:

The Geneve is now passing information off to 8 telnet clients from the "Server manager".  It is too many clients due to the time slices for each task, but it is what it is. 

Is this because each program requires more time than the time slice allows or a symptom of context switching too frequently?  I've rarely exceeded two tasks, so reading that you had 8 clients operational was a nice mind-blowing surprise 

 

[+9640News]

Message also in response to TIPI - Geneve 9640 to Raspberry PI interface development - Page 13 - TI-99/4A Development - AtariAge Forums topic area where I think the answer is more appropriate, but posting here as well since the question was asked.

 

1 hour ago, InsaneMultitasker said:

Is this because each program requires more time than the time slice allows or a symptom of context switching too frequently?  I've rarely exceeded two tasks, so reading that you had 8 clients operational was a nice mind-blowing surprise 

 

Here's the deal.  On the Geneve, each task is allowed 6 "slices" from the running task.  There is a countdown at >0102.  When >0102 reaches >0000, it switches to the next task.  If the program is very heavy into running XOP's when interrupts are off, this counter takes a VERY VERY long time to countdown.  If I am predominantly monitoring every few instructions a TIPI Server Accept command, there are very few cycles of interrupt time for the counter to count down. I test on the "Server Manager" after cycling through each of the 4 port addresses, a test if the counter is greater than >0001, it changes it to >0000.

 

Then on the running tasks, send I am sending text out, I do something very similar.  With something that is doing more non-XOP operations, then I would not see it necessary to adjust the timer as much.

 

Another option I may want to consider is adjusting the timer at the operating system level and not at the task level.

Beery

[+InsaneMultitasker]

25 minutes ago, 9640News said:

If I am predominantly monitoring every few instructions a TIPI Server Accept command, there are very few cycles of interrupt time for the counter to count down. I test on the "Server Manager" after cycling through each of the 4 port addresses, a test if the counter is greater than >0001, it changes it to >0000.

The performance overhead for OS task context switching and XOP switching certainly adds up in a heavy polling situation.

 

49 minutes ago, 9640News said:

If I am predominantly monitoring every few instructions a TIPI Server Accept command,

Does this mean that each task is sitting in a tight loop calling the TIPI XOPs?  Can you reduce any load by limiting how often you monitor?  I am reminded of the state machine perspective, where tasks are run only once per cycle to free up time for other things that must be done. For example, instead of looping a keyboard test 1,200 times every 1/60th of a second, only test it once every 1/30th of a second.  Maybe the server accept routine doesn't need to run 500 times per 1/60th of a second and could do the same work in 10 times per 1/60th of a second, giving the task/interrupt timer a chance to count down more quickly and context switch more effectively.  I don't know how often your routine is executing, and you'd have to implement a counter to better understand the number of calls being made over time.

[+InsaneMultitasker]

Tonight I needed to load MyWord to edit a 2000+ line source file to fix a problem with Abasic.  I was feeling some dread of trying to locate Myword, copy the files to a disk drive or ramdisk, sector edit the loader to point to the right device, etc.  It then dawned on me that I could probably run the program from TIPI.  I remapped the Geneve OS's DSK1 to the TIPI drive 1, copied Myword to the corresponding RPi folder, and launched Myword.  The Myword title screen flashed up on the screen and out of the corner of my eye, I saw my physical floppy DSK4 turn on.   Arrgh.  The loader was configured for DSK4.   I then remapped the OS DSK4 to TIPI's DSK1, launched MyWord, and within a few seconds the text editor was up and running.   I really like the TIPI. 

 

 

[+9640News]

On 1/24/2022 at 9:58 PM, InsaneMultitasker said:

The performance overhead for OS task context switching and XOP switching certainly adds up in a heavy polling situation.

 

Does this mean that each task is sitting in a tight loop calling the TIPI XOPs?  Can you reduce any load by limiting how often you monitor?  I am reminded of the state machine perspective, where tasks are run only once per cycle to free up time for other things that must be done. For example, instead of looping a keyboard test 1,200 times every 1/60th of a second, only test it once every 1/30th of a second.  Maybe the server accept routine doesn't need to run 500 times per 1/60th of a second and could do the same work in 10 times per 1/60th of a second, giving the task/interrupt timer a chance to count down more quickly and context switch more effectively.  I don't know how often your routine is executing, and you'd have to implement a counter to better understand the number of calls being made over time.

Yes, it was sitting in a tight loop.    And, I started modifying to the time slice decrementer at address >0102 in the task to >0001 where it would task switch when it counted down from >0006 to >0000.  Anything that was greater than >0001, I changed that word to >0001 to minimize time.

[+9640News]

Matt,

 

Can you take a look at the error in this TIPI.log file?  I was running Diskassembler for MDOS, and was going to send the disassembled output to a TIPI directory and I am getting an error.  I don't understand what the error in the log file means.

 

2022-01-29 20:40:33,835 TipiService : INFO     Request completed.
2022-01-29 20:40:41,777 TipiDisk    : INFO     Opcode 5 LOAD - TIPI.DEBUG.BUGDOS
2022-01-29 20:40:41,777 Pab         : INFO     opcode: Load, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 16384
2022-01-29 20:40:41,777 tinames.tinames: INFO     TIPI.DEBUG.BUGDOS -> /home/tipi/tipi_disk/DEBUG/BUGDOS
2022-01-29 20:40:41,779 TipiDisk    : INFO     LOAD image size 6912
2022-01-29 20:40:43,136 TipiService : INFO     Request completed.
2022-01-29 20:43:11,029 TipiDisk    : INFO     Opcode 0 Open - TIPI.DEBUG.SRC.AAA
2022-01-29 20:43:11,030 Pab         : INFO     opcode: Open, fileType: Sequential, mode: Input, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 0
2022-01-29 20:43:11,030 tinames.tinames: INFO     TIPI.DEBUG.SRC.AAA -> /home/tipi/tipi_disk/DEBUG/SRC/AAA
2022-01-29 20:43:11,030 TipiDisk    : INFO     (2) Passing to other controllers
2022-01-29 20:43:11,030 TipiDisk    : ERROR    responding with error: 0
NoneType: None
2022-01-29 20:43:11,031 TipiService : INFO     Request completed.
2022-01-29 20:43:11,040 TipiDisk    : INFO     Opcode 0 Open - TIPI.DEBUG.SRC.AAA
2022-01-29 20:43:11,040 Pab         : INFO     opcode: Open, fileType: Sequential, mode: Update, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 0
2022-01-29 20:43:11,040 tinames.tinames: INFO     TIPI.DEBUG.SRC.AAA -> /home/tipi/tipi_disk/DEBUG/SRC/AAA
2022-01-29 20:43:11,042 TipiService : INFO     Request completed.
2022-01-29 20:43:11,051 Pab         : INFO     opcode: Close, fileType: Sequential, mode: Update, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 0
2022-01-29 20:43:11,051 tinames.tinames: INFO     TIPI.DEBUG.SRC.AAA -> /home/tipi/tipi_disk/DEBUG/SRC/AAA
2022-01-29 20:43:11,052 TipiService : INFO     Request completed.
2022-01-29 20:43:11,061 TipiDisk    : INFO     Opcode 0 Open - TIPI.DEBUG.SRC.AAA
2022-01-29 20:43:11,061 Pab         : INFO     opcode: Open, fileType: Sequential, mode: Append, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 0
2022-01-29 20:43:11,061 tinames.tinames: INFO     TIPI.DEBUG.SRC.AAA -> /home/tipi/tipi_disk/DEBUG/SRC/AAA
2022-01-29 20:43:11,063 TipiService : INFO     Request completed.
2022-01-29 20:43:11,072 Pab         : INFO     opcode: Close, fileType: Sequential, mode: Append, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 0
2022-01-29 20:43:11,072 tinames.tinames: INFO     TIPI.DEBUG.SRC.AAA -> /home/tipi/tipi_disk/DEBUG/SRC/AAA
2022-01-29 20:43:11,073 TipiService : INFO     Request completed.
2022-01-29 20:43:11,079 LevelTwo    : INFO     set path request
2022-01-29 20:43:11,083 LevelTwo    : INFO     unit: 0, path: TIPI.DEBUG.SRC.
2022-01-29 20:43:11,084 tinames.tinames: INFO     TIPI.DEBUG.SRC. -> /home/tipi/tipi_disk/DEBUG/SRC
2022-01-29 20:43:11,084 LevelTwo    : INFO     set unit 0 path to TIPI.DEBUG.SRC.
2022-01-29 20:43:11,085 LevelTwo    : INFO     direct input
2022-01-29 20:43:11,089 LevelTwo    : INFO     unit: 0, blocks: 0, filename: AAA, startblock 0
2022-01-29 20:43:11,089 tinames.tinames: INFO     TIPI.DEBUG.SRC.AAA -> /home/tipi/tipi_disk/DEBUG/SRC/AAA
2022-01-29 20:43:11,089 LevelTwo    : ERROR    file doesn't exist
2022-01-29 20:43:11,099 Pab         : INFO     opcode: Close, fileType: Sequential, mode: Append, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 0
2022-01-29 20:43:11,099 tinames.tinames: INFO     TIPI.DEBUG.SRC.AAA -> /home/tipi/tipi_disk/DEBUG/SRC/AAA
2022-01-29 20:43:11,099 TipiDisk    : ERROR    responding with error: 0
NoneType: None
2022-01-29 20:43:11,100 TipiService : INFO     Request completed.
2022-01-29 20:43:11,109 TipiDisk    : INFO     Opcode 0 Open - TIPI.DEBUG.SRC.AAB
2022-01-29 20:43:11,109 Pab         : INFO     opcode: Open, fileType: Sequential, mode: Append, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 0
2022-01-29 20:43:11,110 tinames.tinames: INFO     TIPI.DEBUG.SRC.AAB -> /home/tipi/tipi_disk/DEBUG/SRC/AAB
2022-01-29 20:43:11,111 TipiService : INFO     Request completed.
2022-01-29 20:43:11,120 Pab         : INFO     opcode: Close, fileType: Sequential, mode: Append, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 0
2022-01-29 20:43:11,120 tinames.tinames: INFO     TIPI.DEBUG.SRC.AAB -> /home/tipi/tipi_disk/DEBUG/SRC/AAB
2022-01-29 20:43:11,121 TipiService : INFO     Request completed.
2022-01-29 20:43:11,128 LevelTwo    : INFO     set path request
2022-01-29 20:43:11,131 LevelTwo    : INFO     unit: 0, path: TIPI.DEBUG.SRC.
2022-01-29 20:43:11,132 tinames.tinames: INFO     TIPI.DEBUG.SRC. -> /home/tipi/tipi_disk/DEBUG/SRC
2022-01-29 20:43:11,132 LevelTwo    : INFO     set unit 0 path to TIPI.DEBUG.SRC.
2022-01-29 20:43:11,133 LevelTwo    : INFO     direct input
2022-01-29 20:43:11,137 LevelTwo    : INFO     unit: 0, blocks: 0, filename: AAB, startblock 0
2022-01-29 20:43:11,137 tinames.tinames: INFO     TIPI.DEBUG.SRC.AAB -> /home/tipi/tipi_disk/DEBUG/SRC/AAB
2022-01-29 20:43:11,137 LevelTwo    : ERROR    file doesn't exist
2022-01-29 20:43:11,147 Pab         : INFO     opcode: Close, fileType: Sequential, mode: Append, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 0
2022-01-29 20:43:11,147 tinames.tinames: INFO     TIPI.DEBUG.SRC.AAB -> /home/tipi/tipi_disk/DEBUG/SRC/AAB
2022-01-29 20:43:11,147 TipiDisk    : ERROR    responding with error: 0
 

[+jedimatt42]

I think it is saying the file doesn't exist.

 

There is a bug here in TIPI.  When using an actual device name of TIPI., I shouldn't return 0 for missing files like I do on purpose for DSK*. 

 

Try creating the DEBUG.SRC. directory first... 

[+9640News]

13 hours ago, jedimatt42 said:

I think it is saying the file doesn't exist.

 

There is a bug here in TIPI.  When using an actual device name of TIPI., I shouldn't return 0 for missing files like I do on purpose for DSK*. 

 

Try creating the DEBUG.SRC. directory first... 

The TIPI.DEBUG.SRC. path already exists.  I had opened the Diskassembler to send the disassembled source code with the filename AAA to TIPI.DEBUG.SRC.

 

Beery

[+jedimatt42]

1 hour ago, 9640News said:

The TIPI.DEBUG.SRC. path already exists.  I had opened the Diskassembler to send the disassembled source code with the filename AAA to TIPI.DEBUG.SRC.

 

Beery

 

Interesting, upon closer look, I see the app is openning the file with LVL3 IO for write, then using LVL2 IO to read before it has been closed.  TIPI doesn't write the file until it has been closed... So it doesn't know the file exists yet... the lvl2-direct-input operation does not consult the LVL3 record IO abstraction (which came first in the TIPI design) ... fixing this would require some creative work.

 

[+jedimatt42]

I've logged an issue in the TIPI github, but for now it's going on the incompatible software list.

[+9640News]

37 minutes ago, jedimatt42 said:

I've logged an issue in the TIPI github, but for now it's going on the incompatible software list.

OK.  I saw the issue and did not know the cause.  I know of only two people actively using the DISKaSSEMBLER for MDOS by Tom Freeman, @InsaneMultitasker and myself.  I have no idea if there are other programs on the 4A side of things that do something similar.

Beery

[+InsaneMultitasker]

41 minutes ago, 9640News said:

OK.  I saw the issue and did not know the cause.  I know of only two people actively using the DISKaSSEMBLER for MDOS by Tom Freeman, @InsaneMultitasker and myself.  I have no idea if there are other programs on the 4A side of things that do something similar.

Beery

DKA might be using level 2 to write the output file via direct output (bwrite) using composed sectors and/or memory buffers to reduce the output processing time. You'd have to enable the rs232 debug within the OS's main opcode routine to trace what happens when you output to a non-tipi device.

 

It is uncommon yet there are a few programs that use level 3 to open a file, then level 2 to read or write for speed reasons. Archiver comes to mind as a possible offender, a few of my own programs use a related method for testing the file path then setting the right level 2 opcode (device based) to READ (but not write) the file;   GenASM and GenLINK (reading) use some combinations of level 2/3 for READ, though doubtful for write.

[+jedimatt42]

the tipi log shows what it tried to do:

 

open-input, open-update, close, open-append, close, set-dir, direct-input, close

 

it never wrote... at least not yet.  This may be more a simple matter of close not creating the file if there are zero records. I'll have to take a peek - yep, a quick TI BASIC open, close test shows no file is created... I could see people using that to specify the TI filesystem types in a PAB which is nicely documented, and not have to manufacture the FDR for direct-output.. I will see what I can do... 

[+jedimatt42]

I think update 2.30 of TIPI should help.  You have to add record EAGER_WRITE=on to PI.CONFIG, and it'll create the file on open... Might still totally screw up if both LVL3 and LVL2 are used to write while the file is OPEN.

[+9640News]

7 hours ago, jedimatt42 said:

I think update 2.30 of TIPI should help.  You have to add record EAGER_WRITE=on to PI.CONFIG, and it'll create the file on open... Might still totally screw up if both LVL3 and LVL2 are used to write while the file is OPEN.

I will test this evening.  Thanks for the update.  

[+9640News]

Matt, got off work early due to the ice storm hitting our area.

The update with the EAGER_WRITE=on added to PI.CONFIG works for the Geneve.

Thanks!

 

Beery

[+InsaneMultitasker]

 

@dheyou can try this "TIPI Status" MDOS program to update your TIPI, if you are adventurous... 

 

TSTAT with no parameters will show you the status (same as PI.STATUS)

TSTAT C, will show the config  (PI.CONFIG)

TSTAT H, halt (PI.SHUTDOWN)

TSTAT R, restart (PI.REBOOT)

TSTAT U, upgrade (PI.UPGRADE)

TSTAT ?, displays the options (?CHRU)

 

The upgrade detection isn't working properly, which may be a reason I didn't release the program? This was also around the same time that @9640News and I turned attention to MDOS 7.30 and with the addition of PI.xxxx device to MDOS, I guess this program was forgotten. ?

 

Edit: v.6 deleted; see next post for v.8

 

[+InsaneMultitasker]

OK.  Made a few tweeks to close out the weekend. 

 

TSTAT version .8 seems to detect the update status.   I also added a working spinner for the Restart and (hopefully) the Update processes.  I'm not ready to force an update here but the restart worked as expected   The warning bell alerts the user for halt, restart, and update.

 

If you "TSTAT H" to halt (turn off) the RPi, then attempt a restart with "TSTAT R", the program will freeze until you physically turn the RPi back on.  After 15-20 or so seconds, the spinner will engage and when the services are ready, control is released to MDOS.  

 

TSTAT

 

Edit: The spinner fails in MODE 60 (graphics mode) for some reason that escapes me.  Not sure if it is the OS' fault or mine - I will poke around this week. 

[+InsaneMultitasker]

PEBKAC error in v.8 - I was calling a BL routine with one DATA element when it required two.  The first word of the subsequent instruction was being consumed by the BL routine, so depending on what was in memory at the time the program blew up 'randomly'.    Neat! 

 

v .9 fixes the bug, adds CTRL-C support to the restart/update operations (just in case), fixes the spinner for text/graphics modes, and enables the interrupt handler to service the sound list processor.  Without the last change, pressing "Y" (to restart or update) too quickly sounds the alarm tone until the TIPI has restarted!   Yea, that was not the best thing to discover late at night whilst my better half was asleep. 

 

TSTAT  

[+dhe]

On 2/3/2022 at 1:04 PM, 9640News said:

Matt, got off work early due to the ice storm hitting our area.

The update with the EAGER_WRITE=on added to PI.CONFIG works for the Geneve.

Thanks!

 

Beery

 

Hi @9640News,

  Can you post your PI.STAT?

  Do you recommend EAGER_WRITE=On for all?