ralphb

OK, but then why is my program not working? What is the byte code for "MOVE 2,G*>8300,[email protected]"?

Is the addressing mode G*>xxxx a valid GS argument in a MOVE statement? AFAIK, the official GPL documentation doesn't mention it, but it can be inferred from combining MOVE bits I and C. In fact, assembling this program . GROM >6000 DATA >AA01 DATA >0000 DATA >0000 DATA MENU DATA 0,0,0,0 MENU DATA 0 DATA START BYTE 7 TEXT 'G* TEST' VAL TEXT 'HI' START DST VAL,@>8300 MOVE 2,[email protected],[email protected] MOVE 2,G*>8300,[email protected] B $ . with the Ryte Data GPL assembler yields this byte code for the second MOVE statement: . (MOVE) 37 (Count) 00 02 (GD) a0 b4 (GS) 90 00 . The GS byte code stands for 2 byte address indirect 0 or >8300. But when I execute above program in MESS, only one "HI" is shown. I've tried changing "9000" to "00", "8000", "FF0000", "FF8300", but none of them work. So, is G* for real?

Well, hard to argue with that. But the FinalGROM 99 does have 512 KB of banked RAM ... just sayin'.

Do you update the map during game play? If not, could it be made into a cartridge that doesn't use SAMS anymore?

Are you using a reflow oven? If not, you wouldn't need the stencils. Everything on your board can be hand-soldered, especially your resistors. But I recommend to get a flat tip solder iron, desolder wire, and lots of flux. It's almost as easy as it looks here:

I updated version patch 1.1 so that the FinalGROM 99 is now showing a proper V1.1 in the menu. It also ups the SD access delay to 5 ms. If your SD card still doesn't work after the patch, I recommend using a different card (4-8 GB seem ideal).

No, you're exactly right. The FG99 only supports bank switching that writes to ROM cart space >6xxx/>7xxx. A lot of CRU switching carts have been converted to this, but Red Baron probably hasn't been yet.

No. Look at this ZIP for programs that run with the FinalGROM 99. There's also an index that shows you which programs need an additional 32K. Many legacy programs were converted to disk images, but those need 32K and either Extended BASIC or Editor/Assembler (or their modern equivalents) to run.

Also, there's a little dot behind the v1. Yeah, it's too subtle.

Good point. What I meant is that my patch file "version_1_1.avr" will update the FG99 uC, but you need to rename it to UPDATE.AVR first. I'll reword the section.

Yes, as the docs state, you have to rename it to "UPDATE.AVR". And the version is indeed "V1.", as I was planning to represent the subversion as number of dots. Maybe I'll change this for future versions if people get confused. Regarding your non-fix, I'll send you a custom patch to figure out what your SD card needs.

I've published the very first patch for the FinalGROM 99 that fixes some minor annoyances: When you turn on your console, the FinalGROM 99 blinks with pattern #1 (see troubleshooting section), but works normally when you press the FinalGROM 99 reset button once. The FinalGROM 99 menu shows system or hidden files or folders To apply the update, please go to the homepage and read section "How to Upgrade the FinalGROM 99" carefully, then download and apply the patch file. For those with issue #1, you'll have to press FG reset once to get going when you see the blinking LED. In case of questions, please ask before you try!

Yes, both of them.

I'm going to publish an update that will ignore hidden and system files.

Wow, that is ... efficient!

Very nice indeed! You need some real precision drilling ...

Alright, I happen to have a diagram of the menu structure here: The first byte of a cartridge is always >AA, followed by version (ignored), program count (here ignored), and reserved (usually ignored, but FG99 uses this for RAM/GRAM mode). At >6006, the menu chain starts (green). The first green number points to the first menu entry, the first menu entry to the second, and so on, until the chain hits >0000. Now right behind the chain is the start address of each menu entry (purple). For a ROM cart, this must be between >6000 and >7FFE. For simple hexediting, the start address should be left alone. After the start address, you have the menu title (blue), which is preceded by a length byte (uncolored). This is what you must edit if you want to change a name for the FinalGROM 99. Most of the time, you're limited by the length byte, as you cannot grow beyond this without overwriting other important data. In this dump, you can read 5 entries on the right ASCII pane, but when you count the menu entries (e.g., the purple boxes), you only see 3 entries. Thus, two are hidden, and probably non-functional. If you want to eliminate all but one entries, you change the very first green word at >6006 to point to the green box of the entry you want. Then, for that entry, change that green word to >0000. You now skipped previous entries, and cut the chain at your entry, resulting in just your entry. You can merge two entries into one single entry if you want to create a longer entry name. But I prefer to keep it as much original as I can. I always suspect that some program might use or check its menu entries as a sort of space saving method or copy protection. EDIT: typo

1. Yes, you're the second person to report this. The first person resolved this by using a faster SD card. I can send you a test update that delays initialization a little. If that helps, I can roll it out for others. 2. You cannot have more than 9 pages in the menu. If you have more entries, split them up into two different folders. This is, among other things, a space limitation of the single bank menu that the FlashROM already had. 3. If you're talking about the ZIP, Hunt the Wumpus is the only game where I kept the multi-lingual menu. Mostly, because it's one of my favorite games. If you have other images with nonsense entries such as "ENGLISH" or "DUTCH" or "GAME", you can use a hex editor to prune the menu. That's what I did. 4. PeBo already answered that. I think you can also say "show hidden files" somewhere in Windows, which might help to delete this.

Not to belittle the work Paul has done, but the ZIP file on WHTech is also pretty comprehensive, ordered, and has hand-edited images that fix the menu (name instead of "English", other languages removed) and some weird cartridges (which acted like a translator and implemented their own menu -- WTF?).

If it were the FinalGROM 99, you could take the standard XB image and add your XB program converted to internal format and some glue that moves your program to VDP RAM. For plain BASIC, or for using a FlashROM, I have no answer right now.

Note that the micro push button I used is also available with longer buttons, I think up to 11 mm. You could desolder the short buttons and put in the long ones. These might be long enough to protrude from the cart shell, but I haven't tried that.

Well, you cannot connect them together, one is GND, the other is -5V. But you can use a DPST button to switch both contacts at the same time. I kept them apart so that you could reset the TI, but keep the program, if you wanted to retry/restart the current program. The TI reset is only needed for programs that don't support FCTN-=.

That is an option, of course, but I personally would find it sufficient if MESS emulated the running of one single image, like Michael proposed: mame ti99_4a -cart finalgrom -memc <file> But you'd have to add two flags to enable RAM mode and/or GRAM mode. Also, to be fully compliant, you'd have to support loading of other programs from a running program and dumping the SRAM contents back to the image. None of this needs the menu.

They are not SMD switches, but through-hole micro push buttons. The button I used is made by NAMAE and its product number starts with JTP-1130xx, where xx is the exact type. If you can't get it in the US, I can send you two.

Well, the ZIP accidentally contains an inverted image. Here's the working one: jetpac.bin