jedimatt42

It was just reported to me that long values for URI aliases crash the TIPI configuration tool. You can use BASIC or a DV80 editor to recover by writing "URI1=" to "PI.CONFIG" ( or whichever URI alias you set long )

I love how nobody can read. --- Why am I a jerk about this --- To help our future selves... Atariage provides a search facility, and if I'm looking for issues with versions of XB related to the Force Command 'XB' command, I'm going to search in the Force Command thread, and go nuts not able to find it.

BTW: Force Command discussion belongs over here: Or in new threads...

https://github.com/jedimatt42/tipi/blob/1ea33e66d7209a47d5defbbee2fe5d7da24af3aa/examples/telnet/terminal.c#L518 I don't remember why left arrow is disabled. input to this function is probably result of KSCAN(5) ... so in the Appendix of "Texas Instruments TI-99/4A Computer: User's Reference Guide" Appendix - figure 3

The TIPI PEB board kicad stuff is up there in GitHub.

I didn't actually cripple my TELNET on purpose... I mostly just lost interest. I don't BBS. So making it capable of undermining the work of Stuart seemed like a poor return on investment.

He's asking for a BYE in XB that instructs the finalGrom to load the Force Command cartridge, and then reset per usual. I think relying on XB cartridge to do this is ridiculous. Bad system architecture. I have discussed a more universal mechanism, via load interrupt. This puts the responsibility in Force Command, where it belongs. This is how I would want it for my own use. And on one of Omega's setups, that would just be CTRL-ALT-F11. Less keystrokes than B Y E RETURN. As it stands, a user could type RUN "TIPI FC.FCMDXB" instead of BYE. But that isn't keyboard efficient.

I leave mine on forever.. there is likely something very specific causing the issue... There is a tipimon.service that watches the file system and snatches up disk images to do the conversion. It also creates a cache of all the TI meta-data so the browser interface isn't super slow reading the TIFILES header of every file it lists... It uses an 'inotify' mechanism to create listeners on all the directories it finds. While I leave mine on forever, I always seem to be restarting the services due to testing upgrade or something similar.... This tipimon is the only stateful, long lived service. Maybe I should consider giving it a reset-expiration... make it like windows... so you reproduce the problem reliably for hours pulling your hair out, and then it just starts working correctly, and you the operator have done nothing...

The Mechatronics Gram Karte also has a tool in the DSR for doing this with your own BASIC code. The docs note, that more VDP RAM for stack/etc is then available to your program since your program resides in the GROM during execution.

@Vorticon I just tested with the CF2K_V25.dsk in my TIPI uploaded under the sub-folder DISKS and it worked as expected, created the folder inside. There have been some disk formats that won't convert to sector dumps correctly. I recently improved that greatly.. but it wasn't exhaustive. However, it wouldn't matter where you tried, those formats wouldn't unpack anywhere. If it turns out to be the disk image, I welcome a PM with it so I can use it to test and improve the feature. Also, if the folder for the volume name already exists, there is a mechanism to roll the name until it finds one that is available... If there are errors during the unpacking process, they end up in the /var/log/daemon.log

You should go read all the great documentation on Fred Kaal's website. That is to say, I don't really understand what you are asking... TIPI level 2 IO adheres to the rules of a TI floppy controller + directory support. The PI.HTTP device is a stream input device like RS232... you can read records from it. The PI uses a command to fetch the resource at the URL provided, and then splits the data up into records and offers them for the 4A to READ from with level 3 IO (open, read, status, close, load). If you are trying to skip sockets and build a web downloader... I don't understand all the library whatever stuff.. but yes, if you have a URL to a TIFILES formatted file, and you open the PI.HTTP url to it as DIS/FIX 128, you will get the TIFILES/XMODEM header in the first 128 byte record, and then subsequent pairs of records make up the logical sectors of the file. My FTP program doesn't use PI.HTTP, but it does the same necessary second phase work of detecting the TIFILES header, and then using LVL2 IO to write the file. LVL3 IO on a TI is limited to 256 byte paths. As recently outlined in some other thread, URI1-3 devices exist so that you can extend that limit by setting the URI1 or whichever device alias first, and then accessing the stream with the shortcut. I regret giving URI1-3 a 3 letter prefix, cause people think that means 'disk' Using LVL3 IO, open, write, close, you can set the alias, and then you can use it to fetch a long path... For example: OPEN "PI.CONFIG", APPEND, DISPLAY, VARIABLE 254 WRITE "PI.CONFIG" "URI1=HTTP://my-file.repository.org/somewhere/deep/down/in/the/tree/4AFILES/category1/A" CLOSE "PI.CONFIG" OPEN "URI1.but/wait/there/is/more/some_really_long_named_file.arc" INPUT, DISPLAY, FIXED 128 ... Now you have opened the url: HTTP://my-file.repository.org/somewhere/deep/down/in/the/tree/4AFILES/category1/A/but/wait/there/is/more/some_really_long_named_file.arc Of course saving that file with that really long name will require you to come up with a 10 character short name. If it is an XMODEM/TIFILES file, there is a name inside the header.

The last 2 of these meetings have been recorded. Notes in the Chat are also saved... These and future artifacts will be available here: https://nextcloud.jedimatt42.com/s/t4mm8aF2ASZiXaL You'll be prompted for a password. It is the same as the meeting password.

That's OK, you all have your priorities There were 18 people at one time during the call today.

TIPI uses the rule, that '.' in a file name is presented as '/' to the TI. And TI '/' and '\' characters in names become '.' on the hosted linux filesystem. The other characters mentioned should function without transformations.

This sounds similar to a problem reported earlier by Omega... Hmm. Or was this the inverse of the problem he had... He was using RXB also... and so I tested with it... but I never got to the bottom of it. I don't think I was able to reproduce. There were all kinds of other questions raised that probably had nothing to do with anything, but led me to dismiss it as something unique to him. You could check for me, and see what is being written to the DV80 file: TIPI.FC.FC/XB It should be a single line like: 10 RUN "TIPI.SOMEDIR.WMEXP732", where the thing in quotes is the full path to whatever experiment you are running... There is some accounting in the /var/log/tipi/tipi.log

That's so funny...

My TELNET program isn't complete enough of an ANSI terminal or vt100 to support lynx in a satisfactory way. This might be on purpose...

recorded: https://github.com/jedimatt42/tipi/issues/138 Not going to rush this out, cause nobody needs reboot anyway.

(just information) Device names on the TI do not equal file storage devices.. URI1 - URI3 are more like RS232/1 RS232/2 than DSK1. You can connect to a stream and read records from it... no LVL2 IO at all is supported, and they are read-only. So, you can load programs or access record data from them, just as on a 4A you can load a program or open a record based file from a serial port... Technically they are aliases for the PI. device's PI.HTTP and PI.HTTPS support. The FTP program uses lower level TCP stack from TIPI, and then implements the FTP application layer protocol on the 9900. This demonstrates that the cloud is the limit (LOL).

PeteE did some debugging and confirmed the problem I saw and identified the solution for the entanglement that was observed using the emulation. Update 2.6 is available, and fixes what @wolhess reported for hardware. Your empty records may be written again!

I wouldn't feel right building that program and including it in software I give away. Since the core of the PDF conversion comes from a retro oriented commercial product where their for-pay feature set targets that use case.

A little quantum entanglement with the "I have a bad internet connection and run a BBS from my TIPI" code. The good news, It is broken the same in emulation... The bad news, it is broken in 2 places. That 'safepoint' feature made this more complicated... and it will require some study...

@wolhess nice find! Looks like we severely broke empty record handling... It reproduces in emulation as well. the PI side code to handle empty messages ( 0 length ) is misbehaving. I'll keep working on it tonight, but it'll probably take a couple days to get an update released.

Thanks, that tracks with what is recommended by TI, and suggested by Fred Kaal's documentation. One of these days: https://github.com/jedimatt42/tipi/issues/137

So, I haven't been able to find info that says how the extended timestamp info is requested... Surely if the catalog is opened with a recordlength of 38, it should not.. and if with a recordlength of 146, it should... but what is the behavior when that is opened with a recordlength of 0? Does it default to the legacy 38 mode, or default to the timestamped mode? How many VDP buffer overruns occurred in legacy software if the default was to include the timestamps?