TIPI - Geneve 9640 to Raspberry PI interface development

[+InsaneMultitasker]

TIPI mapped drives DSK1-4 can now be accessed in native OS and /4A modes.   

 

Native OS allows all level 2 and level 3 operations.  There are a few OS-related tests for DSKx that need to be reviewed and modified to complete the functionality, for example, the COPY command still attempts to access the floppy controller card.  

 

/4A mode is currently limited to level 3 operations.  A bit more research is required before I feel 'safe' to activate the level 2 IO.  

 

It is reasonable to assume that one could remove the floppy controller and leverage TIPI for DSKx access in the near future.

 

[GDMike]

But in order for this to work do we need a new boot prom?

I'm loving lll be able to use my tipi peb card 

Edited January 24, 2021 by GDMike

[+9640News]

7 minutes ago, GDMike said:

But in order for this to work do we need a new boot prom?

I'm loving lll be able to use my tipi peb card 

And I just got a working version with no Swan display overwrites on what I will call a 0.99 eprom and a new LOAD-SYS file for the TIPI that will autotrack loading of TIP1.AUTOEXEC when MDOS loads.  The present eprom first tests for ramdisk then HFDC, before it then looks for the TIPI.  Efforts tomorrow will be to see if I can add IDE and SCSI to that eprom while keeping the Swan.

 

 

 

 

[+InsaneMultitasker]

30 minutes ago, GDMike said:

But in order for this to work do we need a new boot prom

No. However, an updated boot EPROM will allow you to boot from the TIPI.  The two are complimentary aspects, neither is "required" for the other to function properly.

[+jedimatt42]

4 hours ago, BeeryMiller said:

And I just got a working version with no Swan display overwrites on what I will call a 0.99 eprom and a new LOAD-SYS file for the TIPI that will autotrack loading of TIP1.AUTOEXEC when MDOS loads.  The present eprom first tests for ramdisk then HFDC, before it then looks for the TIPI.  Efforts tomorrow will be to see if I can add IDE and SCSI to that eprom while keeping the Swan.

 

 

 

 

 

As there are 2 version of a 1.00 boot rom already out, why would you call this 0.99? How will people know that is newer than 1.00 ? 

 

Edited January 24, 2021 by jedimatt42

[GDMike]

39 minutes ago, jedimatt42 said:

 

As there are 2 version of a 1.00 boot rom already out, why would you call this 0.99? How will people know that is newer than 1.00 ? 

 

Crawling back into the darkness....

[+9640News]

7 hours ago, jedimatt42 said:

 

As there are 2 version of a 1.00 boot rom already out, why would you call this 0.99? How will people know that is newer than 1.00 ? 

 

Good question.  Version 1.00 released by Tony years ago, had various menu options for booting from multiple devices such as SCSI and got rid of the swan display.  Actually, Tony’s screen is a graphic screen as well of his creation.

 

Version 0.98 of the eprom supported the HFDC and DSK loading with a Swan.  Version 0.99 that I have now, supports the TIPI, HFDC, and DSK, and does not at this time have SCSI support.  As it lacks features of the 1.00, but is is a small upgrade from 0.98, thus that is the reason.

 

If IDE and SCSI are added, I would suspect it would be something > 1.00 release of the Eprom.  For now, the emphasis has been to get something for the TIPI users of the Geneve that do not have any kind of hard drive storage capability and wants to boot from the device.

 

Beery

[+9640News]

Matt,

 

Trying to chase down an issue with printing from Myart.  When I print, it locks the PI up tight requiring a power off/on to recover.  

 

The text in orange is print from ABASIC a DIS/FIX 128 file. Things print fine from MyWord as well.  Both prints fine.  In the green highlighted material, there is an error when I print to PI.PIO from Myart.  Is there anything obvious to you in the information in the log file to identify what may be at issue?

 

 

2021-01-24 20:43:22,495 TipiService : INFO     physical mode enabled
2021-01-24 20:43:22,495 TipiService : INFO     TIPI Ready
2021-01-24 21:22:43,524 PioFile     : INFO     open special? PI.PIO
2021-01-24 21:22:43,524 PioFile     : INFO     creating new spool: /tmp/print_2021_01_24_T21_22_43.prn
2021-01-24 21:22:43,545 PioFile     : INFO     write special? PI.PIO
2021-01-24 21:22:43,585 PioFile     : INFO     close special? PI.PIO
2021-01-24 21:22:43,585 PioFile     : INFO     converting /tmp/print_2021_01_24_T21_22_43.prn to PDF
2021-01-24 21:22:57,354 PioFile     : INFO     completed pdf conversion

 

2021-01-24 21:26:43,838 PioFile     : INFO     write special? PI.PIO
2021-01-24 21:26:43,862 TipiService : ERROR    Unhandled exception in main
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 50, 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-01-24 21:26:44,384 TipiService : INFO     physical mode enabled
2021-01-24 21:26:44,385 TipiService : INFO     TIPI Ready
 

•  

[+InsaneMultitasker]

@BeeryMiller, I attempted to print to PI.PIO and the same exception occurred.  I then enabled the Geneve rs232debug, restarted the system, and tried to print again.  The debug only reported one IO call:

PBin : 0322 0000 3A1A FFFF 0080 0000 0080 0006 PI.PIO.    This is a write operation opcode >03 to PI.PIO, reclen 0x80 and total characters 0x80.

 

If the log is accurate, MYART did not open "PIO" before writing.  Is this operation possible with the RS232 DSR?  

 

@jedimatt42Perhaps the TIPI exception occurred because the special file PI.PIO was not opened first?  

 

Update: confirmed, Myart is not using the open opcode prior to the write opcode.  I corrected the print routine and it is now printing to PI.PIO.

 

MYART seems slow but I have no experience with the program so maybe two minutes is normal for rendering the image. 

2021-01-24 20:35:14,940 PioFile     : INFO     open special? PI.PIO
2021-01-24 20:35:14,941 PioFile     : INFO     creating new spool: /tmp/print_2021_01_24_T20_35_14.prn
2021-01-24 20:35:14,985 PioFile     : INFO     write special? PI.PIO
2021-01-24 20:35:15,051 PioFile     : INFO     write special? PI.PIO

<SNIP>
2021-01-24 20:36:54,794 PioFile     : INFO     close special? PI.PIO
2021-01-24 20:36:54,795 PioFile     : INFO     converting /tmp/print_2021_01_24_T20_35_14.prn to PDF
2021-01-24 20:37:11,988 PioFile     : INFO     completed pdf conversion
 

Black and white rendering of the dragon image as produced by Myart: 

[+9640News]

Tim, if there is no PI.PIO open and a subsequent close, then I think that explains what was happening.  If I understood Matt's comments from last year when he implemented the PI.PIO, it needs the Open and Close to trigger the appropriate responses for the PDF underlying code for the capture, and subsequent page(s) generation.

 

Hopefully those programs that don't follow the proper protocols are few and far between. 

 

Beery

 

[+jedimatt42]

1 hour ago, BeeryMiller said:

Tim, if there is no PI.PIO open and a subsequent close, then I think that explains what was happening.  If I understood Matt's comments from last year when he implemented the PI.PIO, it needs the Open and Close to trigger the appropriate responses for the PDF underlying code for the capture, and subsequent page(s) generation.

 

Hopefully those programs that don't follow the proper protocols are few and far between. 

 

Beery

 

Think of it as printing to a FILE, not a simulation of the PIO device.

[+InsaneMultitasker]

1 hour ago, BeeryMiller said:

If I understood Matt's comments from last year when he implemented the PI.PIO, it needs the Open and Close to trigger the appropriate responses for the PDF underlying code for the capture, and subsequent page(s) generation.

Agreed, I always would expect an Open before write, however, in the case of PI.PIO, there was no error when attempting to write to the unopened PI.PIO "file" and instead, TIPI threw an exception and reset. 

[+jedimatt42]

I couldn't read Beery's post. It was all green and hurt my eyes. Still does. But given InsaneMultitasker's summary, sounds like I should error on write, if no open occurred.

 

Surely just an oversight. Error handling isn't necessary if no one else writes a bug. LOL.

[+9640News]

5 hours ago, jedimatt42 said:

I couldn't read Beery's post. It was all green and hurt my eyes. Still does. But given InsaneMultitasker's summary, sounds like I should error on write, if no open occurred.

 

Surely just an oversight. Error handling isn't necessary if no one else writes a bug. LOL.

OK, here it is without it being in green.

 

2021-01-24 21:26:43,838 PioFile     : INFO     write special? PI.PIO
2021-01-24 21:26:43,862 TipiService : ERROR    Unhandled exception in main
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 50, 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-01-24 21:26:44,384 TipiService : INFO     physical mode enabled
2021-01-24 21:26:44,385 TipiService : INFO     TIPI Ready
 

[+9640News]

Just a FYI for others as I was testing some software with the TIPI for printing files to PI.PIO.  It appears The Printer's Apprentice, written in MDOS Forth does not do an open, write, and close as well.  Suspect The Geometer's Apprentice does the same thing since they are both written in Forth.  Anyways, just reporting reporting programs that don't follow the open/write/close process of writing to the printer.

 

 

[+InsaneMultitasker]

Are there TI programs that do this as well?  I suspect that if we look closely at the Geneve DSR, OPEN'ing the PIO device is just window dressing to set the special flags (.LF, .CR) and the associated output conditions, with the OPEN status tracked only by the calling program or application. For example, XB tracks the OPEN status whereas assembly does so only if the programmer codes it properly?

[+9640News]

1 hour ago, InsaneMultitasker said:

Are there TI programs that do this as well?  I suspect that if we look closely at the Geneve DSR, OPEN'ing the PIO device is just window dressing to set the special flags (.LF, .CR) and the associated output conditions, with the OPEN status tracked only by the calling program or application. For example, XB tracks the OPEN status whereas assembly does so only if the programmer codes it properly?

Before this week, the only thing I was using for printing was MyWord until I began testing some other programs with the latest MDOS changes.

 

Hard to say how many programs may be at issue. Then, the other issue would be if they did any error detection as I think Matt indicated he may be adding an error on write response if no open first.    I think we need that, as if a user only has TI system, it creates a lockup.  Haven't tried telnetting into localhost from a PC to see if I could do a sudo reboot now entry to avoid pulling the power on the PI.

 

[+InsaneMultitasker]

I'm looking for source code to John Johnson's XCOPY Geneve utility.  He released source for XDIR, XPROT, and a few others however, neither Beery nor I can find the source to XCOPY.   The program is susceptible to buffer overflow when the PATH+filename exceeds 40 characters.  If anyone has it in their archives and could post it here, that would be appreciated

 

[+InsaneMultitasker]

Removed post - I meant to post it in the Geneve OS dev thread.

[+9640News]

Matt,

 

Running 2.18.  Not sure if you modified 2.17 to account for this or not and the newer 2.18 with the new PI.PIO printing I saw the issue.  If printing to PI.PIO, if the printjob never does an OPEN command, and just writes, it locks up the TIPI.

 

Poor programming on the anyone not opening the port and them presumably, not closing either.  It requires a power cycle of the PI if it is a standalone system to recover.

Beery

 

[+jedimatt42]

9 hours ago, BeeryMiller said:

Matt,

 

Running 2.18.  Not sure if you modified 2.17 to account for this or not and the newer 2.18 with the new PI.PIO printing I saw the issue.  If printing to PI.PIO, if the printjob never does an OPEN command, and just writes, it locks up the TIPI.

 

Poor programming on the anyone not opening the port and them presumably, not closing either.  It requires a power cycle of the PI if it is a standalone system to recover.

Beery

 

 

I can see how I'd execute an implicit open on write, but close is required to trigger document generation. So, it seems like there is no point in fixing this.

 

If you have to power-cycle the PI, that tells me the TIPI service lifecycle design is just incompatible with the Geneve. 

 

[+jedimatt42]

As a remedy for something much faster than power cycling the PI, you should write an MDOS program that sets TIPI's second CRU bit for a brief moment, and then clear it. This would simulate what a 4A does when it goes through the title screen process. Or a TIPI supporting MDOS should do this at the exit of every program or some other boundary that requires TIPI to be 'READY'. If this signal is stormed too frequently in a short period of time, the PI systemd will pause restarting the service until some extended period of calm. 

 

I would hope, in Geneve GPL, powerup routines are still run as part of starting up the 4A console ROM. 

 

The powerup routine in the TIPI ROM is an important piece of the software design.

Edited February 14, 2021 by jedimatt42

[+InsaneMultitasker]

3 minutes ago, jedimatt42 said:

If this signal is stormed too frequently in a short period of time, the PI systemd will pause restarting the service until some extended period of calm.

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.

[+9640News]

7 minutes ago, jedimatt42 said:

As a remedy for something much faster than power cycling the PI, you should write an MDOS program that sets TIPI's second CRU bit for a brief moment, and then clear it. This would simulate what a 4A does when it goes through the title screen process. Or a TIPI supporting MDOS should do this at the exit of every program or some other boundary that requires TIPI to be 'READY'. If this signal is stormed too frequently in a short period of time, the PI systemd will pause restarting the service until some extended period of calm. 

 

I would hope, in Geneve GPL, powerup routines are still run as part of starting up the 4A console ROM. 

 

The powerup routine in the TIPI ROM is an important piece of the software design.

 

Just making some notes here.

 

OK, I ran a program to print to PI.PIO without OPENing first.  The TIPI locks up.  I reboot, then enter GPL with Editor Assembler in Rompage mode.  I load TIPICFG from WDS1, not TIPI.  I am unable to force a Reboot from TIPICFG.  If I understand your last message, this should have triggered the reset. Maybe related to @InsaneMultitasker question?

 

The Geneve master DSR is not utilized here.  The normal powerup routines on the cards are the ones active.

 

 

 

 

[+arcadeshopper]

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

Sent from my LM-V600 using Tapatalk