TIPI - Geneve 9640 to Raspberry PI interface development

[+InsaneMultitasker]

16 minutes ago, arcadeshopper said:

So wouldn't resetting the Geneve also call the routine? And if not you're missing something in your power up to support TIPI

By the time Beery gets to TIPICFG, the TIPI onboard EPROM powerup has been called twice - once by the Geneve boot EPROM and once by the emulated /4A ROM (due to rompage).  

[+jedimatt42]

5 hours ago, InsaneMultitasker said:

Is the service restart inhibited if the bit is set and cleared, then immediately followed with a TIPI operation such as an IO read or write?  Beery and I tested powerup code early on (using your ROM as the guide) and the powerup only worked some of the time, seemingly random.  I'm wondering if we need(ed) a delay between the powerup and post-powerup operation.

 

My power up routine in the TIPI ROM assumes the execution speed of a 4A. 

 

It sets the second cru bit, busy loop ( 4A speed assumed ), and clears the bit.  This triggers a kill of the tipi.service. 'systemd' then observes the absence of the process, and restarts it. The cru bit must be set long enough to propagate the signal to the python GPIO interrupt handler. 

 

If TIPI messages are sent while the service is down, they will block until the service is done starting. 

 

I haven't had a need to solve the storm problem... on the 4A this only happens if I hit reset a bunch of times like a child. When I have seen that, 'systemd' logs a warning that there are too many restarts of the tipi.service, and that it is backing off. Do something else for a little while ( like get a cup of coffee, from a different room ) and it will have resumed normal operation... usually.

 

This cru controlled service reset, is completely different than TIPICFG's reboot option. The latter issues the linux command 'reboot now' - the cru base reset routine is designed to prevent the need to reboot the PI. 

 

----

 

Program lifecycle is important. On a 4A... there really isn't task switching without going back through console powerup routines. So... if TI-Artist locked up on a 4A due to a tipi.service crash, you just reset the 4A, and the tipi.service crash is cleared by the console powerup routine.  On a 4A any file left open is abandoned by going through the powerup again. All state in the tipi.service such as left-open sockets and whatever is cleaned up implicitly by the PI OS when the tipi.service process exits. 

 

It seems GPL works that way.. 

 

But in MDOS, there is an actual operating system. tasks are created, switched, etc... A program like Myart ( don't remember how myart is run ) can crash things with the PI.PIO bug, and then jumping back into MDOS leaves the tipi.service still hung. I assume. 

Edited February 14, 2021 by jedimatt42

[+InsaneMultitasker]

53 minutes ago, jedimatt42 said:

It sets the second cru bit, busy loop ( 4A speed assumed ), and clears the bit.  This triggers a kill of the tipi.service. 'systemd' then observes the absence of the process, and restarts it. The cru bit must be set long enough to propagate the signal to the python GPIO interrupt handler. 

 

If TIPI messages are sent while the service is down, they will block until the service is done starting

I honestly do not recall any observable message blocking when I was testing the powerup routine, in fact, the only thing I do recall observing was the lack of a logged reset message when I executed any level3 IO request immediately following the reset.  On the other hand, I do not recall ever seeing a time where the Geneve boot EPROM powerup or GPL rompage /4a powerup failed to trigger a tipi reset, so I assume(d) the TIPI ROM-based timing loop is sufficient, and that my immediate, subsequent IO request was what disrupted the powerup.  I documented the need to revisit this code at a later date and moved on to other aspects of the DSR;  it's later now, so I'll test it this weekend.

 

1 hour ago, jedimatt42 said:

A program like Myart ( don't remember how myart is run ) can crash things with the PI.PIO bug, and then jumping back into MDOS leaves the tipi.service still hung.

Myart runs from MDOS mode.   I think that the point Beery was trying to make is that the TIPI rom-based EPROM powerup was executed but he still had no "access" to the PI as a result of the PI.PIO 'crash'.  Maybe there are multiple reset scenarios being conflated?  I'll defer to Beery to clarify his own actions and intent.

 

1 hour ago, jedimatt42 said:

On a 4A any file left open is abandoned by going through the powerup again. All state in the tipi.service such as left-open sockets and whatever is cleaned up implicitly by the PI OS when the tipi.service process exits.

That's an important point to keep in mind.  Hmm, a TIPI reset after each task completes could be problematic for open batch files executed from the TIPI.    (Has FC tackled batch files and program execution in any particular manner?)   I/we have been more concerned with the front end so it will require a bit of research into how a task cedes control to the OS and what cleanup, if any, occurs at that time.  Maybe I'll write a short, misbehaving MDOS program to see if I can purposely lock all available file handles.

 

[+jedimatt42]

ForceCommand closes the script if it passes control to user code. If return is successful, it reopens and seeks to the next line. If user code crashes the TIPI, that user code is stuck in one of the DSR recv message routines. So the only way back to ForceCommand in such a case is through the console power up path.

 

I guess I will have to try and reproduce this crash on the 4A. 

 

I would think that the cru reset process triggered by an MDOS reboot would also kick the PI from your description, such that manually restarting the PI isn't necessary. IDK about the issue with making a request 'too soon' after the reset. On a 4A it is a computational millennium between power up and any program asking the TIPI for anything.

 

My main point with all this reset talk is that a user should not encounter a situation that requires rebooting the PI. After a client device, 4A or Geneve, misbehaves resetting that client device should get the PI rolling again.

 

-----

 

I will see if I can correct the top level exception handler to pro-actively reset the tipi.service. 

 

And then fix the PI.PIO to properly error on write if not open. 

[+jedimatt42]

55 minutes ago, jedimatt42 said:

...

I will see if I can correct the top level exception handler to pro-actively reset the tipi.service. 

...

 

The top level exception handler already resets the tipi.service implicitly on catastrophic fail such as writing to PI.PIO without having opened: 

 

2021-02-14 08:25:24,470 PioFile     : INFO     write special? PI.PIO
2021-02-14 08:25:24,485 TipiService : ERROR    Unhandled exception in main    <-------- Oh, I already had code deal with this.
Traceback (most recent call last):
  File "./TipiService.py", line 79, in <module>
    if specialFiles.handle(pab, filename):
  File "/home/tipi/tipi/services/SpecialFiles.py", line 52, in handle
    handler.handle(pab, devname)
  File "/home/tipi/tipi/services/PioFile.py", line 31, in handle
    self.write(pab, devname)
  File "/home/tipi/tipi/services/PioFile.py", line 105, in write
    with open(self.data_filename, "ab") as data_file:
TypeError: expected str, bytes or os.PathLike object, not NoneType
2021-02-14 08:25:24,935 TipiService : INFO     physical mode enabled
2021-02-14 08:25:24,936 TipiService : INFO     TIPI Ready    <------------ it restarted 

This happened while the 4A was still locked up waiting for an answer from the DSR write routine. 

 

So I don't understand why the tipi.service is 'hung' still after you exit Myart.

 

Anyway, on to correcting the crash in the first place. Fixing it so it properly errors back to the 4A.

[+jedimatt42]

TIPi update 2.19 will fail fast if writing to PI.PIO without having opened the file. 

 

But wait, that doesn't fix Myart... sure.. I know... but PI.PIO is tolerant of re-opening, to support issues where programs don't close. So you an go into TI BASIC and 're-open' PI.PIO, then close it to trigger flushing the print job.

 

Likewise, since myart doesn't behave, an open and close tool could be written for MDOS to run first, then run myart... print... then exit, and run the tool again to close. ( maybe... IDK the rules on XOP file close routines ) 

 

 

--- as an aside -- barely on topic ---

 

Here is the ForceCommand user code I used to test:

 

#include "fc_api.h"

int main(char* args) {
  struct DeviceServiceRoutine* pi_dsr = 0;
  pi_dsr = fc_find_dsr("PI", 0);        <---- this is a new API I had to expose - so PROGRESS.

  if (pi_dsr == 0) {
    fc_tputs("PI. not found\n");
    return 0;
  }

  struct PAB pab;
  pab.Status = 0;
  pab.OpCode = 0;
  pab.ScreenOffset = 0;
  pab.VDPBuffer = 0;
  pab.CharCount = 0;
  pab.RecordNumber = 0;
  pab.RecordLength = 80;

  pab.pName = "PI.PIO";
  pab.NameLength = 6;

  int err = fc_dsr_write(pi_dsr, &pab, "Hello World", 11);

  if (err) {
    fc_tputs("failed to write to PI.PIO\n");
  }

  return 0;
}

 

[+9640News]

Matt,

 

Your 2.19 update takes care of the Myart issue.  

 

And after I tried to print, and Myart recognized it could not print, I then copied my AUTOEXEC file to PI.PIO and everything resumed as it should.

 

Many thanks for the update.

 

Beery

 

 

[+InsaneMultitasker]

I was trying to assemble a few files on the Geneve using the TIPI PEB.  The MAKE utility was not working right so I started looking more closely at the files and noticed that many files presented by the OS (from the TIPI folders) have timestamps that are either wrong or out of range for a 24-hour clock.   I first compared the times on the Geneve to the times in the Windows TIPI Share; quite a few are different.  Then I remembered @jedimatt42 's comment about looking at the rpi so I PUTTY'd to the same location and entered 'ls -l'   Now I'm even more confused because there are some file timestamps that match between each of the three systems but many are wrong or mismatched.  Although my company would probably like a 32-hour day, I'm in no rush for such a thing.   I'm hoping there may be an explanation and/or remedy.  (I had hoped to run a few tests from XB/rompage but my Geneve video ram is acting up again).   

 

(Edit: I just noticed after some 12/24 hour math that the Win10/Rpi files are 2 hours apart - maybe my time zone got reset from Central to Pacific)?   Anyway, I put another Geneve into my system temporarily and timestamps appear "normal" when cataloged with an Extended BASIC program - both with and without rompage.    @9640News - the Geneve DIR command might have a bug to track in the OS dev topic.

 

 

       

[+9640News]

Tim,

 

There is a setting you can write in PI.CONFIG you can set that will set you to the time zone of your choice.  I have to look up the specific command when I get back home.

 

Beery

[+jedimatt42]

https://github.com/jedimatt42/tipi/wiki/PI.CONFIG#timezone-setting

[+InsaneMultitasker]

45 minutes ago, 9640News said:

 

There is a setting you can write in PI.CONFIG you can set that will set you to the time zone of your choice.  I have to look up the specific command when I get back home.

 

Thanks, I have that info from the wiki - I'm thinking that the setting reverted to Pacific time or I made a mistake the last time I re-configured things.  The real problem appears to be with the MDOS/Geneve OS DIR command displaying the wrong information.  I dismantled my Geneve to inspect the VRAM once more so I won't be able to do any more debugging tonight.

[+InsaneMultitasker]

The Geneve OS time issue has been resolved.

 

With the HFDC and similar peripherals, the seconds value is always even as a result of being divided/multiplied by 2.  The TIPI seconds value is either odd or even.  

 

When the file timestamp is smashed into the format "hhhhh mmmmmm sssss" for processing, each float is converted to an integer then combined.   When the seconds value is odd, meaning the low order bit is set, that low bit is shifted into the high order bit for the smashed hours value (due to a circular shift).   The aberration was only evident when the hours high order bit wasn't set and the seconds value was odd. 

 

Masking the seconds value's low order bit (to make the value even) resolved the issue. 

 

[+9640News]

Matt,

 

Going to float an idea if it is something you may consider, or if someone else may want to implement as a non-TIPI mod to the PI.  I know you really have no interest in supporting the Geneve, and this is less likely an issue for the TI-99/4A as the utilities for the TIPI don't push the boundaries, but I still see some opportunities for the 4A.

 

Can there be a service that runs on the PI, that monitors some other GPIO pins on the PI that would trigger either a PI reboot, or a PI shutdown routine?  Someone could build some kind of switch box with perhaps a couple of momentary contact switches and maybe an LED feedback to show the PI acknowledged the shutdown/reboot that would affix to the side of the PEBox.

 

Over the past month, I bet I have had to unplug my PI at least a dozen, if not more times, to force a reboot due to a lockup.  This has been because of pushing the Geneve interface to the PI to some extremes.  Last night, I did a TYPE PI.CONFIG at the MDOS prompt.  No problem displaying the CONFIG file.  As I was going to pass on my PI.CONFIG file to someone else, I did a COPY PI.CONFIG to <path>.

 

Well, MDOS does a BREAD which is not supported but an OPEN/READ/WRITE/CLOSE is supported.   I should have used an editor to load and then save to a different name, but I didn't.  My issue there.  The command locked the PI and Geneve both up.  Rebooting the Geneve did not unhang the PI requiring a PI power cycle.  Hours earlier, I had to run TIPICFG to force a PI Reboot as I had been doing so much filecopying from TIPI to HFDC, I lost the windows share and no way to recover without a PI reboot. Fortunately in this second case, the TIPI services were still running so I could do a reboot instead of a power cycle.

 

Anyways, just wanted to float the idea if you or others might want to pursue something along these lines.  I think I have been very fortunate and never corrupted a SD thus far during a force reboot.  Just trying to think of another solution without pulling power.

 

Beery

 

 

[Shift838]

29 minutes ago, 9640News said:

Matt,

 

Going to float an idea if it is something you may consider, or if someone else may want to implement as a non-TIPI mod to the PI.  I know you really have no interest in supporting the Geneve, and this is less likely an issue for the TI-99/4A as the utilities for the TIPI don't push the boundaries, but I still see some opportunities for the 4A.

 

Can there be a service that runs on the PI, that monitors some other GPIO pins on the PI that would trigger either a PI reboot, or a PI shutdown routine?  Someone could build some kind of switch box with perhaps a couple of momentary contact switches and maybe an LED feedback to show the PI acknowledged the shutdown/reboot that would affix to the side of the PEBox.

 

Over the past month, I bet I have had to unplug my PI at least a dozen, if not more times, to force a reboot due to a lockup.  This has been because of pushing the Geneve interface to the PI to some extremes.  Last night, I did a TYPE PI.CONFIG at the MDOS prompt.  No problem displaying the CONFIG file.  As I was going to pass on my PI.CONFIG file to someone else, I did a COPY PI.CONFIG to <path>.

 

Well, MDOS does a BREAD which is not supported but an OPEN/READ/WRITE/CLOSE is supported.   I should have used an editor to load and then save to a different name, but I didn't.  My issue there.  The command locked the PI and Geneve both up.  Rebooting the Geneve did not unhang the PI requiring a PI power cycle.  Hours earlier, I had to run TIPICFG to force a PI Reboot as I had been doing so much filecopying from TIPI to HFDC, I lost the windows share and no way to recover without a PI reboot. Fortunately in this second case, the TIPI services were still running so I could do a reboot instead of a power cycle.

 

Anyways, just wanted to float the idea if you or others might want to pursue something along these lines.  I think I have been very fortunate and never corrupted a SD thus far during a force reboot.  Just trying to think of another solution without pulling power.

 

Beery

 

 

There is an option to use a momentary to issue a clean shutdown of the Pi.  I did it on my Pi3 a couple of years ago that has a service in the background to monitor a specific GPIO pin.  Fairly easy mod.  let me dig it out and i'll post it here.

[+jedimatt42]

This is the sort of thing you just search the web for and run into a hundred solutions. (Running command on gpio push button)

 

I don't know what a BREAD is. Sounds like the LVL2 io direct read. The PI. devices are more like RS232 and PIO than files. And only supported by LVL3 io access.

 

Seems like an OS issue. You can't translate 'PI.' to a unit number so MDOS should fail before even talking to the TIPI. 

 

TIPI should have returned an error trying to find the CONFIG file on some random drive mapping. I will look at fixing the error handling in that code path. But it is wrong for level 2 io to be called for the "PI." device name.

 

The only thing special about the Geneve in this case is more error paths are explored. I mostly did happy path testing.

Edited March 9, 2021 by jedimatt42

[+InsaneMultitasker]

2 hours ago, 9640News said:

Well, MDOS does a BREAD which is not supported but an OPEN/READ/WRITE/CLOSE is supported. 

The Geneve TIPI DSR code is expected to return an error if any level 2 calls are made to the PI. , URIx. devices.  This means opcodes 0-9 are safe, >9 are not safe.  If the PI.file bread (direct input >24 equivalent) is passing to the TIPI, let me know and I'll review further.

[Shift838]

9 hours ago, 9640News said:

Can there be a service that runs on the PI, that monitors some other GPIO pins on the PI that would trigger either a PI reboot, or a PI shutdown routine?  Someone could build some kind of switch box with perhaps a couple of momentary contact switches and maybe an LED feedback to show the PI acknowledged the shutdown/reboot that would affix to the side of the PEBox.

 

 

I never got around to having the PCB tooled, but I did find the file.  I did it back in 2018.

 

It uses a ATTINY85 coded to use a tactile switch.  When pressed it will issue a good shutdown command that will close all files and shut your Pi down nicely.

 

it also has a LED that stays on while the pi is running.  Once pressed the LED flashes while the PI is doing it's thing to shutdown.  When shut down, the LED turns off.

[+9640News]

That looks like a nice setup.  I'd be interested in several if others were interested as well.

 

Beery

[Shift838]

i'll probably be ordering a batch of these with my next order of boards.  I need to put another protoboard together on this design.  Since I moved a couple of years ago, i don't know where it is.  So i need to prove it works again just so I know I got the right file.  I have all the parts here to do it, so i just need to get it done next day or so.

 

I want to finish up another PCB design before I order a set.  Gotta combine PCB orders to get the most out of the shipping charges.  I think they round up to the nearest pound.  so 4 oz's package I get charged for a pound anyway.  

Edited March 10, 2021 by Shift838

[webdeck]

For my TIPI, I just do something like this: https://gilyes.com/pi-shutdown-button/

 

All you need is a pushbutton momentary contact switch and a bit of code running on the pi.  Short press to reboot and long press to shutdown.  

 

I also added a LED that shows when it is powered on via the serial port approach here: https://howchoo.com/g/ytzjyzy4m2e/build-a-simple-raspberry-pi-led-power-status-indicator (LED goes off when it has safely shutdown and it is okay to remove power.)  All you need is a resistor and an LED, and the config entry.

 

-Mike

[+jedimatt42]

2 hours ago, webdeck said:

For my TIPI, I just do something like this: https://gilyes.com/pi-shutdown-button/

 

All you need is a pushbutton momentary contact switch and a bit of code running on the pi.  Short press to reboot and long press to shutdown.  

 

I also added a LED that shows when it is powered on via the serial port approach here: https://howchoo.com/g/ytzjyzy4m2e/build-a-simple-raspberry-pi-led-power-status-indicator (LED goes off when it has safely shutdown and it is okay to remove power.)  All you need is a resistor and an LED, and the config entry.

 

-Mike

Thanks. I've used these methods myself in the past. These articles are well written, so I've linked them into a new tipi.wiki page: https://github.com/jedimatt42/tipi/wiki/safe-shutdown

 

Good stuff!

[globeron]

On 11/26/2020 at 1:16 AM, 9640News said:

I just did a search on my bbs for the search term SWAN and did not find the file.  Not sure where it may be found.

 

I do know I have in my BIBLE program, code to display a Myart image.  It is in the BIBLE directory, file BIBLEMYART.  It has everything I think you are seeking to display in low and high resolution.  I have copied the code below as a TIFILES image DIS/VAR 80 file.

 

If you are looking for the swan specifically, I have an 8K dump of the Eprom plus a few lines from the eprom source that sets the video registers and copies the 8K image to VDP.

 

Beery

 

BIBLEMYART 5.63 kB · 11 downloads

 

Hi, sorry just saw this post.  Thank you.  Once I have a bit more time, need to sort out how to compile assembly on the Geneve9640.  

 

the swan.dsk is here:

 

 

 

 

 

 

 

 

[globeron]

On 1/10/2021 at 10:54 PM, arcadeshopper said:

Where's this disk archived?


Sent from my LM-V600 using Tapatalk
 

 

http://ftp.whtech.com/Geneve/9640 News disks v1-3/pc99 disks/9640V2%234.DSK

SECTORONE batch file has DISP as a loader for MYART file type "TITLE" (but only for low resolutions, so I still cannot load the SWAN)

but the concept is okay, load a picture, either wait a few seconds or press a button and continue in the .bat file)

 

 

 

[+9640News]

Matt,

 

I've been trying to resolve a programming issue trying to use Geneve Advanced Basic calling the TIPI TCP client extensions.  I believe I finally found the issue and I believe it is how the PI handles the Open URL string and the terminating character(s).  I have some code that sends a block of characters out to a second terminal on the RS232 port so I can confirm what I think is being sent is actually being sent.

 

I am sending a open URL string of '192.168.1.72:9640'.

 

If I then terminate the string with bytes >0D,>0A,>00, then the connection is not made.  The tipi.log file says 'failed to connect: 1'.

 

If I terminate the string with >20,>00,>20's (repeating) [Example #1], then no connection either.

 

However, if I terminate the string with continuous >20's [Example #2], then I always get a connection.  I am thinking that perhaps the string termination is being handled on a word basis versus a byte basis if >20 is the terminating the string ????  That's just a guess.  Anywhere else I use the OPEN a URL TCP extension always has a number of spaces behind the string.

 

Example #1
TIPI Open URL String

2201 0131 3932 2E31 3638 2E31 2E37 323A 3936 3430 2000 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2000 2201 0200 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 736E 73A2 0000 1700 2201 0301 0100 2201 0317 0100 0300 0000 020C 1000 1D00 0200 AA00 9020 4000

 

Example #2
TIPI Open URL String

2201 0131 3932 2E31 3638 2E31 2E37 323A 3936 3430 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2020 2000 2201 0200 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 736E 73A2 0000 1700 2201 0301 0100 2201 0317 0100 0300 0000 020C 1000 1D00 0200 AA00 9020 4000

 

[+jedimatt42]

When you send the open message, it shouldn't have trailing bytes...  the sendmsg routine should be specifying the actual length of the message which in this case is 20 bytes.. 

 

This message is received by the python code and split on the ':' the second part should just be the digits in the port. But if you are sending a padded buffer, the python int(string) function is having to deal with the extra data. 

 

So your open request should only be this part:  2201 0131 3932 2E31 3638 2E31 2E37 323A 3936 3430