jedimatt42

Unusually refer to Fred's website, ti99-geek.nl He details the lvl2 stuff in a clearly labelled page under documentation. (Direct linking is suppressed, or I would) TIPI uses 0x17, following the pattern of other devices that support directories.

What does this do, and how does it relate to a 4A program to display images?

Good question, I had to look it up. The update should scan all files under the linux path /home/tipi/tipi_disk regardless of mount point traversal.

Is there a well documented de-QI mod? Seems like a void in the knowledge base that adds to FUD.

UPDATE 2.10 - 2020-11-06 - Repairs mixed up Variable record FIADs during TIPI Update. Finds only the Variable record files that are wrong in the way TIPI makes them wrong, and corrects them. I'll add manual execution instructions to the tipi wiki, but you shouldn't need that unless you are restoring an old backup of FIADs.

UPDATE 2.9 - 2020-11-03 Fix for off by one on end of file marker in tipi generated FIADs for VARIABLE record files. Fix for non-ascii characters in os native files. -- like I said earlier, writing the fix-your-files script will take a bit longer... but this stops propagating the mistake.

Thanks for satisfying that. This weekend, I'll move my PI close enough to a TV to try the HDMI connection. And I will try a fresh TIPI 2.5 install.

I don't need the EOF offset marker because I have the end of sector marker in the data for Variable record files... When TIPI reads a Variable record file, it traverses the linked list in each sector, and when it gets to an end of sector 0xff marker, it continues to the next sector, and then processes the linked list there... and so on... all the records get loaded into an array of bytearrays. cause 100s of megabytes of ram are available. If everything is consistent, it should never matter. Level 2 read writes are cool, except for the meta-block, block 0. That is your FDR or whatever... and I transform my 0x06 into the slot that should have your 0x05, and give it to a different disk controller that later gets confused. The actual file data in blocks is fine... I think as Fred said in another thread, what's in the FDR is the internal business of a storage device. Except where he and I devices like HDX that then expose those bits in what are supposed to be standardized FIAD formats.

WARNING: There is a bug in the handling of VARIABLE record files in TIPI. When they write, I increment the last sector data offset as I write the 0xFF end of sector marker, before I stuff the file header. So things doing LVL2 direct read while trying to determine the last sector length are getting an off by one error. TIPI doesn't use this value when reading the file back with RECORD level IO. Copying such files off of TIPI to a floppy, or other controller, or copying the FIAD off to an emulator will likely cause trouble with the use of some devices. TIPI also pads VARIABLE length files empty sector space with 0x00's... so I should be able to write code into the migration/upgrade process that finds your variable record files and fixes them. The last sector will be all zeros after the end of sector marker 0xFF. I'm tired tonight, so I'm not going to rush the fix out. It's just deleting one line of code, but then there is the update machinery.. The repair migration will come as a subsequent update.

The version I used is Raspbian 10 (buster) So to be clear, I'm asking you to find out if "Raspberry Pi OS (32-bit) Lite", latest available from https://www.raspberrypi.org/downloads/raspberry-pi-os/ works (does not have the blanking issue) on your hardware? This separates if the issue is your hardware, or something specific to the additional TIPI centric software. If the problem persists without the TIPI software, there are still things you can research to recover the PI. The SoC's have eeprom on them, that can get corrupt... The power supply could just be crap. The display might not detect well. There are controls in a Raspbian "config" file related to disabling and or forced detection of the HDMI port. I don't recall exactly... To help troubleshoot, I recommend having an ethernet cable attached the PI, and having a strategy to find the IP address through nmap or your router, so you can SSH in. If it is live at all. Keep it simple... don't connect anything you don't need ( audio, mouse, keyboard ) just Ethernet, HDMI, then POWER. You can hot plug the keyboard if the screen stabilizes. Take the TIPI out of the equation. I've heard stories of using the audio jack confusing the HDMI selection. Keep it as simple as possible. The PI attached to your TI is a disk drive and network adapter for your TI. It is designed to be remotely monitored. You can SSH in... You can mount the TIPI share on any other desktop/laptop OS and manage the files from there. Installing the 'desktop' packages is not recommended by the guy who has to answer these questions. That creates a substantial number of other processes increasing disk/sd-card activity, logging, memory usage... I've carved off 200megabytes for ramdisk so that logging and other temporary things don't wear down the sd card. It isn't tuned for the desktop applications running. Remember when flashing the SD card image, there isn't a ton of room on the SD card until you grow the filesystem. It's hobby grade code. Updates and patching processes aren't designed for out-of-space errors. If as you said earlier in another channel, you want to monitor the PI while it is busy being a TIPI, then try something like `atop` from the console ( if you can solve your hdmi issue )

Does the exact same hardware do the same thing with an unmodified "Raspberry Pi OS (32-bit) Lite" sd image?

There are a number on youtube providing gameplay footage, and homebrew shots, but here is a 'mainstream' video if you will from the 8-bit Guy.

I would use TIPI, and make it a software problem. Like mouse. Any usb device should be extendable to the TI by adding the correct 'RawExtension' to the TIPI messaging system. Or, using traditional hardware, you could wire the motor control on the cassette port to a vibration motor mounted to the traditional TI joystick. A 4A rumble pack.

http://ftp.whtech.com/datasheets and manuals/Specifications/Peripheral Expansion System Theory Of Operation and Technical Traning Guide 1982-09-03.pdf Oh, I have never looked in that one before... Always assumed it was just about a power supply and backplane. That is a rich doc! About all of the individual peripherals from TI in great detail.

This would be awesome, except you said it is on WHT, and years ago... which I assume is a 3 letter filesystem name for http://ftp.whtech.com... The communities very own write only memory. (I'm only partly sorry for writing that... I dream of giving up on software development and spending a decade exploding that archive of archives out to search engine friendly content.) Any idea, what they'd be called in the sitelist.txt?

You'll give up a feature in post #289

The Geneve only supports cartridge roms upto 16K as far as I can tell...

I would expect, having looked at the parts, it would go nicely on an UberGrom board.

First, what is 'bruh. O.o' ? Second, you missed my point, but I don't care. I don't know what "quality resin" looks like, and why it is worth the extra couple hours. Maybe that's where you can start...

I don't really understand how playing with chemicals overlaps with electronics design, or software. I generate my STL files in OpenSCAD from code. I can't make 3D mouse driven modellings tools work. many tech-heads making PCBs have never etched one, myself included. Instead we through money at someone. Could you be lumping too many diverse types of hobbies into the group of people you refer to as 'tech-heads'? Your cause seems like a good use of a youtube channel.

I am the girl in the video there that ran away, if offered something wonderful for free, the first thing I think of is how much it will cost over its lifetime. I respond poorly to marketing, so poorly I don't recognize it. I apologize, Omega.

Instead of letting anyone in on anything, it just says you know something we don't know... It is unactionable, non-information. Seems like rumor spreading... If you aren't supposed to talk about something, then you shouldn't be posting even this. If you are not under gag order, than why not say something real?

ah, yes, new nvram directories under ~/.mame/ for each system... It seems to work to remove the ti99_4ev and ti99_4ae and soft link them over to the ti99_4a directory.

Does using the evpc card, since it requires a different 'machine' in mame, mean that the non-volatile storage for a horizon ramdisk is in a different filesystem location?

I'm a software guy, I don't know how to program a silicone pour mold... and things like resin or silicone sound like getting your hands dirty... But... go for it! show us how it is done!