jedimatt42

Update 3.6 - April 14th 2023 - The JSON file handling will now unpack arrays into individual records to read. - Add experimental wildcarding in file names.... So, the array handling: if your query yields: [ 1, 2, 3 ] tipi will return 3 lines: 1 2 3 if your query yields: [ "hello" ] tipi will return 1 line: hello if your query yields a simple primitive value: "hello" tipi will return 1 line: hello --------------- The file path wildcarding... A while back @OLD CS1 suggested it would be handy to have conveniences in referencing files, like that C64 load "*",8,1 where "*" is a glob pattern for the commodore disk drive to process... So in that spirit, I added wildcarding to processing TI to linux file path translation inside TIPI. However, to not conflict with the wildcarding that I already support in ForceCommand at the OS level ( the my TI-99/4A OS ), I chose to use the Amiga filesystem wildcard symbol of #? If the wildcarding matches more than one item, they are sorted, and TIPI acts as though you selected the first item. So, if you go into Tunnels of Doom, and want to load pennies and prizes, you can use a file name like: TIPI.TOD.P#? Or if you want to reload that tidbit program named GAME/TB in your DEV directory, you can OLD TIPI.DEV.#?/TB It also works for directory names. Keep in mind, the TI does not know the full name of the matched file. So, if you use this when CD'ing into a directory in Force Command, it will think the current directory is the one with the #? expression. Which is fine as long as you don't undermine yourself. ( retro computing, no handrails ) This is pretty wild-west right now. I am contemplating adding more intelligence, so that it will only consider appropriate files for the type being operated on, such as limiting to directory for path parts, or PROGRAM images ( or TIPI convertible files ) for LOAD operations. ------ Docs are for Sundays...

I could probably extend the TIPI integration for JMESPath to unpack array results as separate records to be sequentially read

You are selecting all Author attributes from an array, so it returned an array of 1 item... You can add an array index to the query to select the first item in the array.. [0]

It is cool to see that the FCMDXB program is used to jump back into ForceCommand from within an XB program. Nice! Also, looking at the weather PIWEATH.TB, I'll just point out that the SUB PARSE isn't used, as you were able to skip that complexity by using the TIPI JSON query feature. This is good stuff! The ?J feature works with local files as well.. so you could probably handle services that use personal keys by stashing the keys in a separate SECRETS file that is in easy to read JSON format. Something like: { "wheresmyphone": { "apikey": "1238128371837238273" }, "whosatthedoor": { "login": "myuser@snailmail.com", "password": "Is this sentance a good passphrase?" } } which you could then query in the same way as you have the web resources... just open it with a local file path like: TIPI.?J.APPLETS.SECRETS or something... just an idea.

There was not a way to nudge in system for a while. I had broken my GitHub lineage. I have since fixed GitHub. But there is also this thread that I have pointed every TIPI user at. Spending my hobby time on writing an update to 2.41 that just tells the users a message seems like a waste of good hobby development time. As a case study, you found out. So there seems to be no need. I can't spend my time on FOMO or FOMU (fear of missing users LOL)

I think that curation effort was destroyed as part of a tantrum. https://www.thingiverse.com/search?q=ti-99&page=1&type=things&sort=relevant https://www.yeggi.com/q/ti99/ and some miscellaneous work, not really off-the-shelf-ready... the best thing in there is the PEB card shell template, I've used it (with adjustments) on my TIPIPeb, and my 2016SAMS - https://github.com/jedimatt42/99prints recent stuff for inside the PEB PSU https://forums.atariage.com/topic/349268-atx-power-supply-for-peb-seeking-more-detailed-information-on-replacing-the-original-ps/?do=findComment&comment=5231726 I would just encourage folks to tag things on your favorite sharing website with 'ti99' when you share.

I have examples of utilizing vast cartridge ROM and SAMS ram, but they are not beginner friendly, for accessing all the cartridge banking, and even SAMS ram bank switching. My approach changes the way you write the code... https://github.com/jedimatt42/fcmd As for using gcc to build overlays to work with the XB 2.9 environment, it's a little bit of a chocolate and peanut-butter issue... it may end up great, but those with the necessary knowledge aren't likely to bump into each other. Coercing the elf binary into an XB friendly loadable module might be do-able. But I'm guessing you'd have to spec out what CALL MLOAD does for us before we could help. Texas Instrument's CALL LOAD handles their uncompressed tag object format... It also stashes addresses into a link table so CALL LINK can find them by name. I would imagine to build some interoperability with any variant of XB, you would have to write a custom entry point ( usually what the crt variants provide ) that makes sure your code gets loaded where it needs to be, and when your C function is returned from, returns to XB correctly. I don't actually know what XB (2.9) is, but if this is XB GEM, I hear that returning correctly is a bespoke issue. I would expect, that in order to get far enough along to build interoperable components between GCC and any XB, you will have learned enough 4A assembly to just do XB and assembly, or learned enough of the 4A architecture to realize that you can do the stuff that XB makes look easy, pretty easy in C.

Update 3.5 - - Added JSON querying capability of file contents. - when opening a URL through PI.HTTP, or PI.HTTPS, or a local native file, you can use the native file handing modifier: ?J to indicate that it should be processed as a JSON data file. - the modifier goes after the device name, so TIPI.?J.MYJSONDATA or PI.?J.http://my.favorite.json.provider.org/the/best/data/ever - the query syntax follows an available 'standard' that is available in many modern languages: https://jmespath.org/tutorial.html Here is an example (TIDBIT style XB): MAIN: URL$="https://api.open-meteo.com/v1/forecast?latitude=32.46&longitude=-86.46&current_weather=true&temperature_unit=fahrenheit&windspeed_unit=mph&precipitation_unit=inch" READDATA: OPEN #1:"PI.?J."&URL$,DISPLAY ,VARIABLE 254 PRINT #1:"current_weather.temperature" LINPUT #1:TEMP$ PRINT #1:"current_weather.winddirection" LINPUT #1:WD$ PRINT #1:"current_weather.windspeed" LINPUT #1:WS$ CLOSE #1 SHOW: PRINT "Temp: "&TEMP$ PRINT "Wind speed: "&WS$ PRINT "Direction: "&WD$ Normally opening the PI.HTTP to such a URL provides the following result: {"latitude":12.3456789,"longitude":12.3456789,"generationtime_ms":0.2345655987548828,"utc_offset_seconds":0,"timezone":"GMT","timezone_abbreviation":"GMT","elevation":67.0,"current_weather":{"temperature":50.6,"windspeed":12.0,"winddirection":66.0,"weathercode":3,"is_day":1,"time":"2023-04-08T23:00"}} With the file open in JSON mode, you can write a JMESPath query and the result of the query is made available as the text records that can be read. So, in the example I write the query: current_weather.temperature And the next LINPUT #1:TEMP$ reads 50.6 into the TEMP$ variable. (All of the magic of TI DISPLAY format is still working for you in BASIC, so TEMP could have been a numeric variable instead of a string if you want.) An empty string written as a query, will provide the entire JSON ( broken into length limited records ). This is the default state of the records if no query has been issued. As should be apparent in the example, you can query the file multiple times to fish different bits out of the data. If you write an illegal query expression, the error message from the JMESPath parser will be set as the available record data. A thing to note, when TIPI consumes the JSON data, it will order the keys and strip unnecessary whitespace. (Documentation on the TIPI wiki is still pending looks a lot like the above text)

???

Thanks, I've linked that to the Known-incompatible-software page on the TIPI wiki.

For the cards I have eyes on, these are their regulator situations: Shift838 IO : 5v TI Flex Card : 5v Corcomp DSDD Floppy Controller : 5v Foundation 128K : 5v Mechatronics GRAM Karte : 5v PGRAM : 5v SAMS 2016 : 5v TIPI : 5v, 3.3v Rave99 Speech In PEB : -5v, 5v TI FDC : 12v, 5v TI RS232 : 12v, 5v TI 32K Memory : 12v, 5v SidMaster99 : 12v or 9v (depending on SID chip) All of the 12v regulators I observed were LM7812C variants. I think, the deal is that regulation does not work properly on these, but the upstream power supply being regulated and the load in system of the 12v side on each card being relatively low, and the absolutely MASSIVE heat sink attached to most of these cards. I'd like to measure some of this myself still. In the long run, I'd also prefer to replace the regulators across the boards with the appropriate DC-DC switching replacements.

Locked up is a bit vague, until you say things like you can't even type at the USB keyboard... Socket connections that are firewalled off can lead to the 2 minute timeout in the client situation as the host pretends to not even be there for ports it doesn't want to respond too... I never have a keyboard on my PI, as the TIPI PI is meant to be used headless. The new kernel module may be in a hot loop, on purpose, which could have caused this behavior... We should be able to A-B test the same issue in emulation mode and not have my kernel module involved...

Ok, I don't name these things, but TIPI 3.x is based on newish Raspberry PI OS, which is based on the upstream Debian Bullseye OS. TIPI 2.x is based on old Raspberry PI OS, which is similarly based on Debian Buster. So if anyone has upgraded to TIPI 3.x and Buster, they have done something unholy. The TIPI community should probably not talk about Buster and Bullseye, and just stick to the version number. This is my mistake for pushing the insides where only the outsides belong.

Hopefully you added the floppy sounds for your own enjoyment and not due to some request. I would assume if you like sounds you should add all the sounds you want... maybe just make them opt-in instead of opt-out.

I have unbroken my ability to patch the 2.40 line, (thanks to @arcadeshopper having so many TIPIs deployed) so users starting with the 2.37 sd image provided by some vendors should be fine to update to 2.40 with the normal update mechanism. That is where that road ends. The 3.x line is the new road, for so many 1st and 3rd party reasons.

TIPI 3.4 Update - improved the Backup & Restore page in WEB-UI to prevent downloading a backup while the archive is still building. - added 'Tools' -> 'Emulation Mode' page in WEB-UI to allow switching configuration for use with the emulators, vs a real 4A.

The breakout board I used has an on/off switch as well, but I just left it in the off position.

Thanks! I revised my previous post...

That's a good idea. Captured.

To migrate to TIPI 3.x If you TIPI 2.x is does not offer the 'Tools' -> 'Backup & Restore' menu: - copy your tipi.local\tipi windows share contents to your modern computer. - copy your tipi.local\pdfs windows share contents to your modern computer. - if desired, copy the /home/tipi/tipi.config & /home/tipi/.tipivars data & /home/tipi/ - install the new sd card image from https://jedimatt42.com/downloads/tipi-sdimage-bullseye-3.1.zip - configure the tipi fresh as in the instructions on this page: https://github.com/jedimatt42/tipi/wiki/tipipeb-installation If your TIPI 2.x does have 'Tools' -> 'Backup & Restore' menu: - go to the backup & restore page: http://tipi.local:9900/backup - press 'Backup Now' - download the backup file to your modern computer. - install the new sd card image from https://jedimatt42.com/downloads/tipi-sdimage-bullseye-3.1.zip - If you backup is not so huge that you need to grow the linux filesystem on the TIPI first, then - while still on your modern computer, copy the backup tipi-backupXXXXXX.tar.gz file you created to the 'boot' partition on the sdcard. - eject the sd card safely, and install in your PI. - the backup should restore automatically during bootup. It will likely reboot once as well. - Else, boot the PI off the new sd card image - configure the network via 'CALL TIPI' so you can get to the web-ui, or if you are special, setup a /boot/wpa_supplicant.conf before booting the PI - update to TIPI 3.3 - go to the http://tipi.local:9900/backup page, and upload your backup file - select your backup file, and press Restore Backup

TIPI update 3.3 - Still April 1st, still not a joke. Update WEB-UI backup page to have 'x' to delete backup files. Update restore mechanism to tolerate TIPI 2.x backups that aren't actually gzipped even though they are named .tar.gz

No. That might get you to some form of Raspberry PI OS bullseye, but then required libraries would be removed out from under, and you'd still be on the 'buster' branch of the actual TIPI software. And I just found out I hosed that branch up such that there can be no more updates delivered through it. That was a mistake, but it is fine, cause I can't support 2 branches of the code anyway..

Note, the 3.x line of TIPI requires the new SD card image, based on Raspberry PI OS Bullseye, available at https://jedimatt42.com/dl There is a bug in the 2.x WEB-UI backup system, where the act of downloading the backup file converts the .tar.gz file to just a .tar, but leaves the .gz file extension... anyway, I need to fix the TIPI 2.x WEB-UI backup download headers to prevent this. Manual (drag-n-drop) backup of the TIPI windows share always works.

TIPI Update 3.2 - 2023-04-01 ( Not a joke ) Fixed bug found by @dgrissom in PI.HTTP... when url contains multiple query parameters Added 'Search' tab to WEB-UI that allows searching by substring in the name, restricting search to various common file storage types, and from the results being able to jump to the file browser view for the containing directory. Changed the WEB-UI page layout a bit, to make it easier for me to maintain by eliminating the use of tables. Updated emu_setup.sh to provide hint about restarting the tipi.service after the configuration change.

Thanks! I did not know that! That explains why it has never worked from a windows browser for me, and only from my linux browser... since I have the windows browser automatically trying https when I just type in a hostname. Sure enough that fixed it for me. (TIPI 2.x buster, and 3.x bullseye) (added that to the wiki, cause I will forget)