jedimatt42

The 2.16 SD Card image was borked, in that I did not setup wifi on it before archiving it. It isn't totally DOA. You can use wifi on it by using CALL TIPI, set the wifi SSID and PSK , write, then wait a while... it reboots the pi.. ... then CALL TIPI("TIPI.NET.TELNET") login to localhost at port 23, and sudo cp /etc/wpa_supplicant/wpa_supplicant.conf /boot/ sudo reboot now wait a while, and then reset the 4A... if thing seem hung... wait a little while longer... Then CALL TIPI should show an IP address in the upper right, provided you entered everything correctly. Or create the wpa_supplicant.conf correctly on the /boot partition of the sd-card before booting the PI with it. This is the official how to get yourself out of WiFi issues technique provided by Raspberry PI .org But, I'm going to fix it, and produce a new image.

Renamed the thread slightly, hopefully it improves the visibility/discoverability. (or maybe just an excuse to ... bump)

PM me (I'll PM you this time) or a friend that has the password, to get the password, and then follow the details in post #1 of the virtual club thread: https://atariage.com/forums/topic/308212-zoom-ti-99ers-pandemic-4a-club/ Maybe I need to rename that thread too...

https://www.peconnectors.com/sockets-sip-machined/hws4913/ They have longer single pin items also. With an extra square post segment in the middle portion.

My link in is dead. They are indeed single pin machine sockets. I got them from peconnectors.com, but they no longer seem to be available there. More rigorous searching may find something. They are however the same thing that is available in a SIP format. With a fine solder tip, I suspect that technique could be adjusted.

I'm not opposed to restoring it. I just changed the cursor character to 0 which looks like a space. I think it is still blinking, LOL.

@wolhess regarding the flashing cursor from READKEY, I took the cursor away on purpose. It never printed the key that you pressed either. So I decided it was wrong to have READKEY act like a line input command. Version 1.14 fixes the SAMS mapping before launching a cartridge. Mega Menu works for me with XB GEM 2.8 via the XB TIPI.MM.MM command. (Jumping directly into XB GEM 2.8's T80XB menu entry, and friends, still doesn't work.)

Thanks @wolhess, love the details! Do you have SAMS? I suspect that since I started using SAMS, I am not restoring it the right state before jumping into cartridges. That would explain issues with the size of the XB program showing the symptom. I also think this is why the XBGEM entry points like TML no longer work directly from Force Command. This gives me some things to test

PM sent. Welcome!

@retroclouds, I'll add it to github issues. Along with the need to rework that. It hasn't handled long lines well - ever. You probably ran into a buffer overrun! Now can you use it to jailbreak your 4A? Back when I was writing TIPICFG, I now realize I almost never prevented buffer overruns in my 4A code. (Ah, this is already recorded: https://github.com/jedimatt42/tipi/issues/141)

That seems like a preferable approach, so the burden of knowing what extensions are used by a program remain with the programmer, and this knowledge requirement isn't distributed to all of the users of the program.

Hopefully, this is the last release in 2020... Update 1.13 - download in post #1 - improve TIPI mapping as discussed for XB command. - include those modified times in the 80 column directory listing. - I think this modified sysinfo to show 9929 for the PAL system if we think it is not a '38, '58 or F18A. - A few bug fixes related to the bar.

Back to on topic... I was attempting to handle the case of a real disk drive in all that code in TIPI.FC.LOAD. But even that was wrongly coded... the SEG$(A$,8,4) should actually have been SEG$(A$,1,4) as I'm trying to pull the device name off the front of the full file path. But all of that is pointless if automap is on, DSK1 will get mapped again when the TIPI.FC.FC/XB is loaded. I need to simplify TIPI.FC.LOAD to 10 RUN "TIPI.FC.FC/XB" and change the generated TIPI.FC.FC/XB to handle the mapping restoration: 10 OPEN #1:"PI.CONFIG" 20 PRINT #1:"DSK1_DIR=<oldmapping>" 30 CLOSE #1 40 RUN "<yourpath>" That way, I've undone the temporary mapping to get XB to load TIPI.FC.LOAD, and restore your explicit mapped or unmapped state of DSK1 prior to running the actual desired xb program. That should allow running from mapped DSK1 or TIPI, or physical DSK1 without astonishment.

PM sent.

Yes! Yes! That is what I'm asking of you. Now, to be clear, this forum is public.

Temporary stuff sticks around for months. If not years, and requires messaging campaigns to expunge. I think you are talking about @wolhess issue with XB, in which he clearly has a thorough understanding of what is going on and how to work around it.

XB certainly always overrides the DSK1 mapping on TIPI. It must set it to TIPI.FC. so that XB will find the TIPI.FC.LOAD program and run it on startup. XB also writes a second file TIPI.FC.FC/XB that contains the RUN "YOUR.PROGRAM.FULLY.QUALIFED" As you've seen this is what TIPI.FC.LOAD runs. I think I assumed people would have AUTOMAP on, so DSK1 would get remapped to the folder containing the target basic program when that is loaded by the PI. The XB command should be able to take a file in the current directory, or a full path. These 2 cases seem to be what I do in practice. You should be able to use a relative path, but I'm guessing there is a bug with that. I'll test. There are a couple places in that code that could be going wrong. There is room for improvement in the mapping handling. The generated TIPI.FC.FC/XB program could be written to hold the code to reset the DSK1 mapping to what it is before the XB command ran. This way if AUTOMAP is off, you shouldn't have to write little shims to set the mapping... If AUTOMAP is on, this would get overridden again, consistent with TIPI behavior. But if AUTOMAP is off, then this would undo the transient mapping to TIPI.FC for the LOAD magic. So this is an improvement I will make. TIPI also has a feature where you can put a DV80 file in the directory of the PROGRAM file and if AUTOMAP is on, when that PROGRAM is loaded the mappings declared in that file loaded. I pretty much never use manually mapped DSK1 for anything, so I only tested XB where the path passed was from TIPI, or is DSK1 it expected the real floppy. I didn't try DSK1. where it is mapped. If I reset the mapping of DSK1 in TIPI.FC.FC/XB that should also fix the issue with XB DSK1.WEATHER3 using the real floppy instead of the TIPI path that DSK1. was mapped to.

Now what did I just get done saying about workarounds? Give a developer a chance at a proper solution before confusing the ecosystem with hacks.

Are all of the enables good? one is supposed to be active-high. High 10k pull-ups on the outputs might help. After doing, that, removing the '138, do you still get erratic values at the pull-up point? caused maybe by the downstream circuit?

I have no idea why that doesn't just work for you. Is it only working for me?

If it worked that way, wouldn't that be nice... I refer you to the developers resources thread, where all the documentation and specifications for most aspects of the 4A architecture are linked. My statement about 'made up' was flippant, and not accurate. I don't think you understand what TIPI is... I have adhered to the specifications of the 'TI OS' as much as practical... but as noted earlier, my copy was missing pages.

See previous posts not too far up the road.

We are talking about the FDR attribute of a file, not the XB flag. in the manual: "TI Extended BASIC", page 163, the reference for SAVE in Chapter 4, subsection 'options', second paragraph: It is the protection available with the Disk Manager module that we are discussing... not the SAVE PROTECTED option that those pokes manipulate. We are trying to discuss the thing that has to do with disk controller level stuff. Well, except we are done discussing it. The summary: TIPI doesn't support the disk manager protection feature, except to set and unset it. It fails to enforce it. Enforcing it could be a good thing, which I've filed as an issue in the project github repository. Native files (things not in TIFILES format) on linux are treated as read-only ( mostly ) and it could clarify things to users, if TIPI reported them as protected ( P ) in the catalog records it generates at the disk controller level. And if it uniformly enforced the protection.

Arcadeshopper did some testing, and he gets the flashing light problem if FCMDG and XB28GEMG are together in a subdir. But not if they are together at the ROOT of the SD card. I haven't verified this. But They do 'work' ( no flashing light ) in my setup, which has both in the ROOT of the SD card. That might be a issue with the FinalGROM firmware, except, that Arcadeshopper verified he can go from XB28GEMG back to FCMDG... so that points to an subtle issue in Force Command's XB command. We can do more testing on our end before you need to spend your hobby time on this.

I don't think the things I changed belong to that loader. I had to reset the 26.5 row VDP register. Re-lock the F18A Map pages 0-16 of SAMS to addresses 0-64k, (I should then turn off the mapper, but didn't) All of the why, was because I had turned on optional hardware. I have to do these same resets before switching FinalGROM cartridges also. Maybe some of that matters if you want to support XBGEM's 80 column extension... Or maybe it isn't a problem since it isn't also doing 26.5 or 30 row mode.