jedimatt42

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.

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

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.

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

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.

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.

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.

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

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.

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.

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' _ )

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.

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.

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'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.

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.

Ah, man.. happens every year.

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.

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.

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

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)

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.

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.