jedimatt42

That's interesting... when in Force Command, I of course have interrupts off, cause I haven't seen a disk controller that needs them on. But normally on a 4A, when at the TI title screen or in the BASICs, interrupts are on... so I should turn them back on in FC before branching into the cartridge. Force Command cannot actually wait for a cart to finish loading in a deterministic way. It sends a message to the FinalGrom99 asking for a cart to be loaded. There is no response from the FinalGrom99 after the image is loaded. The microcontroller on the cartridge does the loading, not the 4A. So then it can see if something shows up in the address space, but I'm not sure that is a promise from the FinalGROM that the image is completely loaded. I've seen evidence suggesting waiting longer is better. I'll have to dig into the FinalGROM design more, and prove this out.. maybe the CPLD doesn't enable the 4A databus while the ARM chip is loading - if that is the case, that can eliminate some FUD.

Loose wires shouldn't cause that gang during boot unless you mean something other than getting to the TI title screen when you say, "boot" The new symptom sounds like a crubase conflict...

So, with no PI attached, the TIPI board should still allow the 4A to boot, and execute all power up routines fine. I would try disconnecting the PI. If it still fails to boot, remove the eprom. If it still fails after that, reflashing the CPLD (there are instructions on the wiki). If it is still bonkers after that, then the CPLD is not controlling the bus transceiver (74hct245) direction correctly, and I would want to use a logic probe and see which of the 2 chips is being a jerk.

Cable orientation on the PI?

that is super weird... In the boot partition there is a config.txt that contains various options around the HDMI port. You might have to fiddle with some of those. I don't generally hook a screen up to my PI's... but I have somewhat recently checked that the console comes up on my primary TIPI's PI. The boot partition is a Windows visible partition, so if you shutdown the PI, place the SD card in your PC, you can edit the config.txt directly there. While you have the SD card in your pc, you can edit your wifi settings by creating a wpa_supplicant.conf file next to it ( too many details to quote here, just google that file name and raspberry PI and you'll get good examples ). Once wifi is up, even if the HDMI doesn't work, you can SSH in for further tuning.

Gift him one of these: https://www.amazon.com/Stocking-Christmas-Rechargeable-Headlight-Flashlight/dp/B08CXBGTT3/ref=sxin_10_pb?cv_ct_cx=headlamp&dchild=1&keywords=headlamp&pd_rd_i=B08CXBGTT3&pd_rd_r=2d044687-b494-4edb-9ba9-79410dca0b48&pd_rd_w=keYYE&pd_rd_wg=0oYmv&pf_rd_p=ffb450f7-bfad-4e7e-95e8-f2bd147e99a4&pf_rd_r=0789ZD90FR5QZ1JC1S1C&qid=1607389979&sr=1-4-8065ff8c-2587-4a7f-b8da-1df8b2563c11

I don't remember what fileset was used in 0.M, but I did some shuffling between naming the ROM 8.bin or C.bin... If you currently have both a FCMD8.bin and FCMDC.bin, the 8.bin might have gotten loaded, and been incompatible with the launch address baked into the GROM. ?? Guessing... IDK, looking at the code, I think the address in ROM that the GROM jumps into has been pretty stable. The zip has a bunch of files in it now... only FCMDG.bin and FCMDC.bin go on the FinalGROM99. (There should be no other FCMD?.bin on the SD-Card) I believe I switched to a 128k ROM at about 1.0. I increased the start delay time in the FC.FCMD EA5 program that switches the FinalGrom cartridge back to Force Command, since you have to give it more time to load before jumping into the cartridge space. It has been adequate on my system... But that shouldn't be an issue from the FinalGROM99 menu. Unfortunately, this just sounds like the problem I get when I haven't reseated my cartridge in a while.

This is still working for me with default XB, and Super Extended Basic, although my module name for XBMOD is SXB_G

For the 9938, I set register 0x08 to 0x08 to enable 64K memory type. I would say, I don't know why I do that. It just seemed to make sense when I quickly went through some documentation on setting up the mode. I verified, this still works on my MAME configuration. If typing WIDTH 40 works, and things look fine, then I believe I'm detecting the video chip correctly, but not initializing it for the mode correctly... maybe need to zero out some registers? I set registers: 0 = 0x04 // 80 columns 1 = 0x70 // text mode, unblanked, with interrupts 2 = 0x03 // pattern name table ( address 0x0C00 ?? this is not on purpose ) 4 = 0x02 // pattern definition table (font) address 0x1000 8 = 0x08 // 26.5 row mode 9 = 0x80 // non interlace So, register 2 is being set wrong, but still functioning in MAME when I place data in 0x0000 for the name table... It should have been showing up as blank for me, as the rest of my code thinks the name table is at 0x0000. Setting register 2 to 0x00 also still works in MAME... so... that's super weird.

At the blue screen, if you blindly type: WIDTH 40<enter> Does the display correct itself? I added PAL detection, and 9938 detection and the 9938 80x26.5 mode a few releases back. These work on the mame eu evpc configuration. This is probably the problem. I've never heard of a REPL99 card... so don't know how that plays into things.

@wolhess Here is a fix: Update 1.8 - fix readkey I moved the readkey command to a different ROM bank, and missed where it called another function without a bank-switching wrapper.

Oh, no, the thread title changed again... you know what that means LOL... So the IDE.TIME is worth testing now.

Oops, I missed a spot for the IDE.TIME, so don't bother testing that yet. [email protected]

Update 1.6 - in post #1 Added date command and bar command. date will print current date time. bar will show a title bar in the top row that doesn't scroll away. Use the CLOCK environment variable to control which source clock device is used. Tested PI.CLOCK ( this is the default if the variable isn't set ), and CLOCK ( classic99, should work for triple tech cards ) Implemented IDE.TIME, but I don't know how I can test it. So maybe you guys can confirm if it works or not... ??? Bar updates about every 15 seconds if the blinking square cursor is displayed. That may change. Inverse colors only operate in F18A 80x30 mode. 40 column display abbreviates 'Force Command v1.6' to just 'v1.6' - it would have fit, but I felt it was too much. https://atariage.com/forums/topic/290966-force-command-ver-16-kinda-like-commandcom-from-1985/

Sunday at 3pm Pacific this week.

I wish there was an add blocker that blocked these micro-blog pages entirely.

ok, fixed.

but of course I broke things

find . -type f | xargs grep "\.py" | egrep -v "python3" now shows no python invocations without explicit use of python3

I don't use the system python on my machines, so yes, it defaults for my user to python 3. But I like to at least fix my makefiles to not be so assuming.

I recently deleted the 0.M from the thread. The only compatible issue I am aware of is the removal of 'CALL' command. Now just use the script name without the 'CALL' in front. Been that way since 1.0. CALL DSK1.MYSCRIPT is now just DSK1.MYSCRIPT

I'll fix up the building instructions. that'll help, and can fix all my references to xdt99 tools so no editing is required. 80 column in Force Command is built explicitly for the 9938 80x26.5 mode, and the F18A 80x30 with extended color attributes mode. So it doesn't work in classic99 emulator either. VDP detection is here: https://github.com/jedimatt42/fcmd/blob/master/b10_detect_vdp.c And in this file: https://github.com/jedimatt42/fcmd/blob/fef52275be9ff6e69c439e14b275246329bdeae4/libti99/b8_vdp_settext80.c#L12 You can remove the register 8 and 9 setting, and change the 25 and 26 in that file to 23 and 24 to get a 80x24 2-color display.

@speccery case matters for device and file/directory names on the TI and TIPI. Force Command won't let you cd to a destination that doesn't look like a device or directory ( cd actually opens the catalog to verify ) so if DSK1 isn't mapped, you'll have trouble. TIPIMAP command in ForceCommand will list your mappings just like TIPICFG (CALL TIPI) did. Regarding building it - You'll run into bugs... I publish bugs to the master branch in github... I publish tested builds to post #1 in this thread. You shouldn't need --recurse-submodule I'm curious what symptom indicated you needed that? If that is needed, I broke something bad. the python3 -D (notice the extra spaces) was just because xdt99 suite of tools wasn't found. ( I should probably write some build docs. ) and I should fix my makefiles so you don't have to edit Ralph's xdt99 programs.

If it becomes too PC like, easy fix, just don't use the software. Hopefully it just makes it easier for you to setup and run the applications and games you actually want to use.

Updated - 1.5 - See post #1 For SAMS users, there is a history command, and !<number> to recall into the command line edit buffer. UP and DOWN arrows work to navigate also.. This is an in-memory history, using a single 4K sams page. Items will fall off the far end of the list to make room for new items at the front. items use 2 bytes + length of the command For not SAMS, the history command works. !1 should work. but you only have a single item history list in VDP (that REDO buffer from a few releases back) For everyone, added CTRL-c, FCTN-4 support to break out of all the commands that loop through stuff and print stuff. Already had support in 'TYPE' for this. It is generalized and applied to everything from listing environment variables to deleting files with a wildcard pattern.