jedimatt42

This was a slick build. I strayed a little... I cut out the 'PM' and spent money... Already had the PI and cables and adapters... but after using an old charger that looks just like @dgrissom's, I saw this: https://www.tindie.com/products/pisugar/pisugar2-battery-for-raspberry-pi-zero/ And they have a ready to print case, that the printer is currently working on... The rechargeable battery device has a software suite that installs on the PI and provides a web interface to configure a few things... 1. there is a momentary switch, so you can choose press, double tap, or long press to trigger shutdown, or some other script... 2. there is a RTC, so the PI can use the correct time when you take the model100 out without WIFI access. So, the only part of the software setup I changed, is to not add the config.txt entry for gpio-shutdown. --- I learned some cool things following these instructions.. lots of ways to accomplish similar tasks on linux... so @reboot entries in crontab were new to me. That one will stick with me. And BIG THANKS to @dgrissom for the guide! --- Now, if I could find a good USB -> 25 pin serial on a short 3 foot cable, I'd solder that sucker to the underside of the PI-Zero-W, and feel like it was really tidy...

You offered the best configuration, but the product offered compromises. The REPL99x manual l read didn't explain itself as contextually and clearly as you just did. It primarily conveyed you don't need the wires. If I care some other time, I'll have to re-read. I am not able to read the original German. I never saw anything in manuals for the EVPC that describe the potential for 2 cables... I think the nuances between the EVPC and EVPC2 were lost in me. I may have only seen an EVPC2 manual. If the EVPC(1) supports the VDP interrupt choice of on the bus's EXT-INT or via external wire, then I would have expected a DIP option in MAME simulating the physical configuration jumper. I wasn't able to understand the difference between EVPC and EVPC2, so I mistakenly held that expectation.

That doesn't seem like a 'MAME' type decision. In the real world, a user would choose one or the other... external wire, and VDP-INT is readable on CRU bit 2, or REPL99x, and VDP interrupt is on EXT-INT which is CRU bit 1. Seems like MAME should emulate the software compatibility issues of EVPC w/REPL99x.

So, looks like EVPC2 can send VDP-INT back to the 9901 on EXT-INT. Odd that my software works on MAME but not real hardware. I can't tell if EVPC on MAME is EVPC or EVPC2... I guess I should assume MAME is not EVPC2. My read of the EVPC docs lead me to think EVPC only supports the external wire going back to the console. My software is disabling interrupts at the cpu ( limi 0 ), then setting R12 to 0x0000, and testing bit 2, a cru input from the 9901 to see if the VDP-INT occurred. and then reading the VDP status register to clear it ( as if there is only one, but after detecting the VDP type, I am careful to set the VDP register-to-read back to 0 ) I don't see any way in mame to control the EVPC2 DIP settings, that control if the EXT-INT method is implemented or not. So I can only guess that MAME implements the jumper wire technique bringing the true VDP INT back to the 9901, and for EXT-INT, I would need to be testing some bit other than 2. I'll have to study the 9901 circuit... So, again maybe not EVPC2... IDK... this won't get much attention again until I have some use for my isPal detection. -------- As for the ERROR 07 issue... I guess I'll have to configure an actual floppy and reproduce the defect.

Version 1.10 in post#1. Hopefully fixed @wolhess's problem editing DSK1.AUTOCMD Fix the am/pm logic to be common, and should fix the MBP clock. Made environment variable names case insensitive. Key is promoted to ALLCAPS before interacting with the dictionary. Made internal consumption of environment variable values case insensitive where appropriate. XBMOD is still a file name on your fg99, it is just passed on to the cartridge. PATH needs to work with case-sensitive filesystem.

So, that is quite interesting that the 80 column mode works now.. The only thing different is I removed the loop I have that times based on VDP interrupts how many cycles I can get done between, and so determine if it is a PAL or NTSC system. The infinite loop symptom indicates that VDP interrupts never get to the 4A console... Is that true generally? I see this note on ninerpedia: No external Interrupt cables necessary when use (REPL99x) in the original Console. But, I'm guessing the REPL99 doesn't decode the VDP INT from some other sideport bus pin... VDP INT really needs to be sourced from the VDP or lots of compatibility issues are created.. is that a fair assessment? I'll put my PAL mode detection back in, but give it a cycle limit, so it doesn't try forever. It'll end up defaulting to NTSC ( currently this is just unused system information gathered once at startup ) --------------- a good group of things for a real 1.10 release.

That's an easy thing to fix... and the fix will save ROM bytes. I'll take a look at the consistency of case-insensitivity and fix some things there... command names are case-insensitive. file names are not... the keys for environment variables probably should be. The values have to be preserved, but when system things consume them, it makes sense to be insensitive on a case by case basis... I fell into case-sensitive on CLOCK values, because the TI filesystem/DSR-name-system is case-sensitive. The values for 3 of the clocks are device or file names. But I can do better.

I don't run mine inside the PEB, and it is also very rarely rebooted... only if something compels me to change SD cards.. So I'd guess if heat was your issue, running inside the PEB produces heat... I always assumed airflow for cards is pretty poor in there...

FCTN-U is a super abnormal thing, except that I've been lazy and keep forgetting that there is a version comparison issue with the TIPICFG on the current sd-image.. So once I make a new sd-image, I'm really the only person who should need the FCTN-U.. so I guess it's update the docs or update the image LOL... There are a couple other reasons to update the image for those PI Zero W users... And I'd like to figure out this screen issue... cause that'll be a configuration well outside the TIPI software domain.

Indeed, the XB command requires TIPI to be able to manipulate what is seen as DSK1.LOAD Some of the quirks, suggest I need to reset more console state in the FG99. Probably I am leaving the AUTOCMD open if EA is run from AUTOCMD. I will take a look.

I don't know what Directory Manager is. I have seen the logs fill up, but haven't been able to track down why... Other than that, and failure to find a home network, I haven't seen any reason to reboot a TIPI's PI. The update restarts the services upon completion. This is usually visible in the daemon.log (unless you reboot) I will have to figure out why the log rolling for the OS isn't working.

Making a new full image requires a ton more time than releasing an update via git merge. I start from fresh Raspberry PI OS, make sure everything 3rd party is updated, then run the part that is automated. Fix a little automation, and do some manual steps, including zeroing the sd card after imaging, before compressing... And then the expensive upload. And then when everyone unnecessarily downloads the new image, I get a higher AWS bill.

Nothing stands out, but I'll have to go through the same steps again and see if it reproduces...

Awesome! Thanks for rapid testing!

forcecmd_1.10_test.zip use command: CLOCK=MBP then DATE Does it provide the date ( with a year of 0, cause MBP doesn't support a year ) ?

Good enough for me then, nothing will change...

Ah, this: http://www.unige.ch/medecine/nouspikel/ti99/mbp.htm#Acessing clock I'll take a look.

Update 1.9 - - disabled some NTSC/PAL detection, that works for me in MAME, but might hang with some 9938 cards. maybe? guessing? - added file modified timestamps for TIPI, and works with HFDC, should work with HDX, and IDE. timestamp only shown in 80 column made file listing. (DIR)

Are their docs for how to read it somewhere? If so, and you are willing to test, I'm willing to add it.

Update - 2.13 - 2020-12-12 - added Internal/Fixed 146 type catalog with modification timestamps. This follows the format outlined by Fred Kaal in ti99-geek.nl -> Documents -> reading directories. If a catalog file is opened with record length 0 or 146, you get timestamps from TIPI. Directories have 0 values for timestamps. Creation time is 0 for all situations. Files have last modified timestamps. Like IDE and HDX, the year is complete and not offset from something. I do not know of any software for the 4A that uses this.

Looking to move the Sunday timeslot to the Saturday timeslot, and on Saturday... a.k.a. normalizing to a single weekly timeslot. 99% of the time, it is the same group of people, but the alternating time is continuing to be a little confusing for people. Ready, set... DISSENT?

The manual references tidbit, but not being a practiced user, I am curious how divergent this is from Tidbit? A super set? Or some more complex overlap?

I agree (and am guilty) that we are venturing into complete disregard for English, and probably all other languages on these pronunciations...

Back to developing TIPI itself.. I'm working on adding file timestamp support. For people with the HDX, IDE, HFDC, or Geneve, this is a historical thing. So, I'm adhering to Fred's docs on the matter: ti99-geek.nl, -> documentation -> reading directories In my implementation, I'll also follow Fred's DSRs, and return a full 4 digit year. What I cannot do / isn't worth the effort / is produce the linux creation date. Last modified date is natural and common on linux/unixs, but creation date isn't supported by all filesystems, and from the best of my ability to research, is possible, but difficult, running external custom executables as root, etc... and who actually needs the creation timestamp? We live without it on our modern computing systems and the world hasn't ended. So, creation time will be filled in with zeroes. I have the TIPI side working. But other than a hand crafted BASIC program, ( finally used PRINT USING, WooT! ) I don't know of any 4A software that cares... Anyone know of anything to test it with?

The new version of Force Command utilizes the SAMS if present. So if it is unreliable, then you'll see lots of crashing in Force Command. Outside of Force Command, sounds like the board is not good at pretending to be a 32K, or even just co-existing in the PEB by keeping it's data off the bus when it isn't it's turn...