SAMS STANDARD LOADER/SAVER

[SAMS STANDARD LOADER/SAVER]

Honestly, adoption sets a standard, not precedence. So neither of us will ever be able to realize a standard. The community is so small there isn't even a need.

 

It also doesn't hurt to have a different model that distinguishes the difference between prerequisite runtime.

[Bounce'n'Pounce (game released)]

21 minutes ago, PeteE said:

Loading file (B:\Ti-994a\bnp_8.bin) from disk: Type 8, Bank 0, Address 0x0000, Length 0x8000

is loading into address 0x0000 normal? I would have though that would be 0x6000.

[TIPI Usage and Support]

1 hour ago, RXB said:

You would think this would be in RAM not on the SD card and use a buffer in case it does lose power?

But that is one bad design if you think about a OS so prone to such a simple problem.

It's not the OS as much as SD card tech. SD cards are prone to the same issue in any other device including desktop PCs. 

 

TIPI configures most of the background OS write activity into ramdisks. 

The Linux OS caches what it has room for from the rest of the filesystem. 

This reduces risk considerably.

Does nothing to protect against brownout.

 

There are background daemons bundled with the Raspberry PI OS that periodically check for security updates. Otherwise an idle PI isn't really that prone. 

 

There has been a lot of progress in read-only filesystem operation support for Raspberry PI... https://www.google.com  

Some of the solutions require more rigorous testing to ensure the suite of systems work, than a hobby project like TIPI merits.

[SAMS STANDARD LOADER/SAVER]

I did explain.

 

But to state it simply, read the first blocks that have the loader instructions. Then following the metadata read a subset of blocks into VDP, set SAMS pages, move to pages, read next blocks, set pages, move to pages .. 

 

File size isn't an issue.

 

I am assuming a software is written that that understands the format and does work for the user.

 

I think as I reread your proposal, you are describing a convention users execute, Using existing software loaders.

[TIPI Usage and Support]

TIPI update 2.19

 

Fix crash when WRITE to PI.PIO without having OPEN'ed first or since last CLOSE.  It now returns an error to the 4A immediately.

[TIPI - Geneve 9640 to Raspberry PI interface development]

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;
}

 

[TIPI - Geneve 9640 to Raspberry PI interface development]

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.

[TIPI - Geneve 9640 to Raspberry PI interface development]

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. 

[TIPI - Geneve 9640 to Raspberry PI interface development]

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. 

[Gotchas in using CALL FILES?]

48 minutes ago, Lee Stewart said:

 

If you are talking about the VRAM file buffer stack, the TI DSR powers up with 3 file buffers.

 

...lee

 

Thanks for the correction!  Made me go re-read my TIPI DSR Panic subsided. I set it to 3 there. 

 

[TIPI - Geneve 9640 to Raspberry PI interface development]

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.

[TIPI - Geneve 9640 to Raspberry PI interface development]

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. 

 

[SAMS STANDARD LOADER/SAVER]

As an end user of EA5 programs, I dislike the PARSEC, PARSED, PARSEE, PARSEF, PARSEG style of naming. 

 

I'd much rather see LVL2 direct-read access meta-data at the front of the file that indicates it is a SAMS assembly language executable, or a SAMS XB program, and then embed the instructions of what blocks of the file to load into what pages of the SAMS, and keep it all as a single file. Unfortunately this requires building more tooling. But the end user gets a single file. These could be PROGRAM images, but not loaded with LOAD. or DIS/FIX 128 files... really doesn't matter. This is what I do in Force Command for it's binary executable format which I plan to extend to SAMS, except I cheat on the tooling. I just waste a little memory by having that metadata displace the start of binary code.

 

With your approach existing tooling can build independent 4k raw binaries. ( _ there is some emoji for 'meh/shrug' _ )

 

[Gotchas in using CALL FILES?]

Editor Assembly won't have any open files at the time that it branches into your program. 

 

EA5 loaders don't OPEN your file. When the LOAD operation is complete, the controller will not be actively using any VDP sector buffer that was used to facilitate the LOAD.

 

If exit involves resetting the console, then the powerup routines in the console ROM and on the controller cards will reset the VDP stack. I believe they set it to 1 on powerup. 

 

 

[TIPI Usage and Support]

9 hours ago, jedimatt42 said:

While a file might be 8k, it'll probably use a minimum of 1 allocation unit which will consume some ridiculous amount of space on a modern filesystem.

 

I wouldn't trust SMB to report correctly until verified with Linux directly. 

 

Telnet into the PI, and run

 

df -h .

(I think it is -h for human friendly output)

 

 

In my case, I have about 8000 files ( a ton of the SID files compatible with SidMaster99 )

 

[email protected]:~ $ df -h .
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        15G  2.2G   12G  16% /
[email protected]:~ $ cd tipi_disk
[email protected]:~/tipi_disk $ find . | wc -l
8421

 

From windows 10, with the share mounted as a drive, they seem to agree. 

 

I don't know where the picture on the left hand side from @InsaneMultitasker comes from... But the right hand side picture indicates the standard 4GB SD card image, with not a lot of additional space used. @InsaneMultitasker, if your SD card is larger than 4GB, you should follow the TIPI setup instructions from the wiki, that refer to growing the partition size. 

[TIPI Usage and Support]

While a file might be 8k, it'll probably use a minimum of 1 allocation unit which will consume some ridiculous amount of space on a modern filesystem.

 

I wouldn't trust SMB to report correctly until verified with Linux directly. 

 

Telnet into the PI, and run

 

df -h .

(I think it is -h for human friendly output)

 

 

[TIPI Usage and Support]

TIPI's TELNET is a proof of concept/example program so people can see what is possible with the TIPI TCP support... And a PI fixing tool in the event of desperation.

 

I don't BBS, so it isn't ever going to be a priority for me. But the source is available in the examples section of the github repo.

 

I've heard Beery has TCP enabled some other term program. Maybe it is more feature rich.

 

 

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

Sounds like everyone is projecting their own issues on my vague comment.

 

My issue is that at the office the signal to noise ratio is less than 1:100. And that is with zero outside advertisement. 

 

My free Gmail is supersaturated with marketing. I treat it like a database. I never 'get' email when it is sent. I occasionally search my email for the receipt or itinerary that I expect to be there.

 

I pay for another freely available email service. So I have one channel where the signal to noise is closer to 6:10.

 

Signal to noise at Atariage is pretty low too. I have all forms of notification turned off. But this is the form that suites me best. A searchable database of conversations.

 

I don't think email will ever be replaced. It is part of our identity now, like your primary phone number, or postal address. The rest of the world is entitled to spam you at all these public interface points. And you can't order a pizza if you don't play the game.

[TIPI Usage and Support]

9 minutes ago, RickyDean said:

That would have been true, last year. Lol...

Ah, man..  happens every year. 

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

39 minutes ago, BeeryMiller said:

Matt,

 

Nice addition and example you have for the PI.UDP capability.  I had started looking at the protocols for POP3 and SMTP recently trying to understand what may be possible for some kind of simple email communication.  I think your basic example would lend itself with the ability for an implementation possibly even within an extended basic program.  Getting a list of emails on the server I think is viable, however, I start to struggle with managing the actual size of the emails as I am looking at one mailbox where most of the emails are 100K+ to MB in size.

 

Off the top of my head, I think this would really preclude any useful implementation. Even with a SAMS, I think this would be impractical.  So, my question to you or others, does anyone concur with my reasoning or are there options I may not have considered?

 

I guess I could see the ability to send an email from one's TI, but it is the receipt of emails I think becomes the challenge unless I am missing something.

 

Any feedback is welcome.

 

Beery

 

 

 

 

 

 

Feedback: why would someone want to use email on any platform, modern or retro? Email is a broken societal construct.

 

I think all the email protocols are TCP, not UDP.

 

You'd want to use a method that leaves email on the server, but when it brings an individual message down, strips all the HTML and CSS out so you have a chance at displaying what is typically a 1k message. 

 

Encryption is typically required today, so unless you run your own email server, that's probably a non-starter.

[TIPI Usage and Support]

Update 2.18 - 2020-02-02 ( a nearly perfect date )

 

Updated the PI.PIO support to use off the shelf Printer2PDF code, instead of my previous mods to control paper size.

 

Added PI.UDP and UDP messaging support for UDP sockets.

[TIPI Usage and Support]

3 hours ago, Shift838 said:

That's what I did.  I started with the latest SD image, downloaded the DSR from JediMatt's site and burned it to a new EPROM.

 

the CPLD file on your site is the latest from 2019?

There was only ever one CPLD update/download made available. I think. 

[TIPI Usage and Support]

Update time depends on soooo many factors... I'd recommend going back to the IDE controller, and selling the TIPI on ebay. (just kidding)

 

Going from 1.x to 2.x worked from one user, after they let it go overnight... but depending on what base-os your 1.x was still on, it might not ever make it to 2.x.. So just start over with the latest SD card image.  

 

Everyone - when you've let it go that long... just start over with the latest SD card image. Clearly there is nothing on the old image you would care about.

(of course, I guess I'm talking to the people that don't follow this thread)

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

4 hours ago, arcadeshopper said:

What you had before seemed to work

Sent from my LM-V600 using Tapatalk
 

 

The units are different than what I specified before given the software upgrade and removal of my hack to set paper dimensions from environment variable in IDK what unit... probably was dots. But at least I don't have to mod the software to change the paper size. 

 

Ebay says NOS tractor feed paper was indeed 8.5" x 11" after removing the sides. 

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

I am trying to fine tune the PI.PIO, after updating the RWAP's main Printer2PDF epson emulation code. I had some page size numbers I was using before, but I don't recall were the source for them was... I'm wondering if anyone has US fan-fold '80 column' tractor feed paper and can give me a measurement in millimeters? Looking for the post-perforation-tear-off dimensions. The default length of the page for the converter doesn't seem right, and the default width seems a little narrow. 

 

Searching the internet, there is some grey area on what the standard was, as standard US sizes changed as a result of the presidency in the 80s. Or so I've read.

 

I would gladly receive the same for typical tractor feed paper used in the UK as well, although I suspect the software has that right.