Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

jedimatt42

Members
 View Profile  See their activity

  • Content Count

    3,431

  • Joined

  • Last visited

  • Days Won

    3

Posts posted by jedimatt42

  5. Posted

    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. 

    • Like 2

  6. Posted

    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. 

    • Like 4

  7. Posted

    7 minutes ago, pcoderdude14 said:

    Well...it seems that my PI  is working fine.   I was able to "login" to the Raspberry PI OS "Lite" version (without the HDMI cutting out, like it does in the TIPI 2.5 version) and I was able to (then)  hook up a keyboard and change the "PI" password.  So, I don't know  what  else to try..I did have problems with SSH and "login" to the PI.  I used an  ethernet cable, and, (checking with the program "ifconfig" ) saw  that the PI had  generated a IP-Address.  All of this  I COULD NOT do with the TIPI 2.5 version.  I don't have access to my TIPI and TI99 console right now, but, I  am guessing that the RasPIOS  "Lite" would  make little difference  "hook up" to my Ti99/TIPI!?!  Any other ideas?  I think I've tried just  about everything with TIPI 2.5

    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. 

     

  8. Posted

    4 hours ago, InsaneMultitasker said:

    I've made a note to look at the Horizon ROS to validate how EOF is reported as it might be more stringent (too stringent?) than some other spinning disk controllers. I saw an error on the ramdisk that doesn't occur in a floppy controller and I wonder if it is related. 

     

    I know what you mean about being tired - that's today for me ;)  Question that came to mind:  Level 2 reads/writes happen on a 'block' basis so I'm not so sure there would be any impact felt there.   Your second sentence mentions TIPI doesn't use the EOF value when reading back the file. Is that a manifestation of how the rpi back end deals with the file or am I just reading to much into that. 

     

    <deleted image as I did not intend to copy it into this response>

     

     

    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.

     

  9. Posted

    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. 

    • Like 4

  10. Posted

    5 hours ago, pcoderdude14 said:

    I  don't  know about "Raspberry Pi OS (32-bit) Lite" but I have been able  to  run TIPI ver. 1.43 on this machine(3B+) well as (3b,  and,  4b-4G-ram).

    I also  have tried the 2.5 sdimage on the other RasPI's with the same thing happening.

    The sdimage starts to "boot" then at a certain point ,  the screen  just "blanks" (on the  RasPI side) and when I  try at this  point to

    use CALL TIPI, I cannot get an IP address and I cannot  "H"alt the RasPI or reboot.  I  have to do that manually on  the RasPI.

    Is "Raspberry PI OS (32-bit) Lite" the version you used to  make the TIPI  ver. 1.43 image?  I'm trying to "install" a "GUI" on my

    3B and would am  trying to gather as much info  about the TIPI as I can in  case  I run into trouble.  So far, though...no problems with

    TIPI ver 1.43 🙂

     

    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 )

  11. Posted

    14 hours ago, pcoderdude14 said:

    I mean the display for the RasPI just "blanks".  I see that the "disk" LED (green) on the RasPI is still moving,  when this  happens. And,  I am able to use the TI99 console to "CALL TIPI".  But, when I try "H"(Halt)  on console,  the Raspi doesn't do anything.  Also , I cannot "pull" a IP address off the Raspi,  from TI99 console, either.

     

    Jt

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

    • Like 1

  15. Posted

    On 10/26/2020 at 7:34 AM, Ksarul said:

    In the case of the TI cards, the original JEDEC equations are available in several of the documents on WHT (I put them there many years ago). That should give you a good comparison set to verify the four TI cards in your list.

    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? 

     

  16. Posted

    On 10/27/2020 at 7:26 PM, Omega-TI said:

    Wow, that would be kind of neat.  The sad thing is, I've not programmed a 1284P in so long I've forgotten how to do it.  The 49F040 is a piece of cake though.  You know the old saying, "Use it or lose it".  Sadly, I've lost it.

    You'll give up a feature in post #289

    • Like 1

  18. Posted

    On 9/4/2020 at 8:16 AM, mizapf said:

    Obviously, no one tried to build a RPK for MAME, so here is my attempt. It is the original XB GEM (with 16K ROM); for the XB 2.8 GEM I had to change the bank handling in the gromemu cartridge type, so I will publish the 2.8 RPK when the new MAME release is out.

     

    By the way, is there a real Extended Basic 2.8 GEM, or does it only depend on emulation or FinalGROM? (This is relevant for me whether I extend the current paged378 type or the gromemu type, which is a catch-all for exotic cartridge types.)

    extended_basic_gem.rpk 41.32 kB · 15 downloads

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

    • Like 1

  20. Posted

    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.

  23. Posted

    7 minutes ago, jedimatt42 said:

    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? 

    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. 

    • Like 3

  25. Posted

    2 hours ago, wierd_w said:

    I am really quite surprised that for things without moving parts, people in the tech community do not use silicone pour molds with resin.

     

    I mean, COSPlay kids use the darn things, and get real elaborate with them-- for one-off pieces.  A proper pour mold will give you reliable reproduction and durable end result, with multiple pulls before the mold degrades.

     

     

     

     

    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!

    • Like 2
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...