ralphb

Just a note: xhm99 can also create HFE files, or decode them back to DSK. So next time you create a nonworking HFE file with TIDIR you can decode that file with xhm99 and compare the DSK images, or vice versa.

See the homepage, towards the end, or Greg.

Aren't you running for cheap stuff today? (Never mind, it spread to us as well.)

I could understand that the FINALGROM entry is missing (e.g., if the menu code is different and the console probes the cart port too quickly), but a "cyan screen of death" or even a "cacophony of death" could mean that there's an issue with the GROM emulation. Unless it's just contact problems. Again, please send me your error description, and I'm on the lookout for a QI console. (I do have a beige console with just two power pins, but the board is the original version. Maybe someone hacked the system?)

I've just released update 1.2, which doesn't fix any issues, but improves the dumping functionality: It now allows mixed images to be dumped. While this doesn't sound like much, it enables another image I've created: a Mini Memory with Save option. Selecting this option will save the contents of the mini memory at >7000->7FFF onto SD card, so that when you reload the image, your work is still there. In a way, this emulates the battery present on the original Mini Memory cart. After a successful save, the TI 99 will reset to the title screen, with Mini Memory still loaded. A blinking FinalGROM 99 LED indicates an error. fg-minimem.zip I've added the dump code in the middle of the image, as there was a streak of about 150 zero bytes. I hope that they didn't serve any purpose, but were just fillers. NOTE: If you're not interested in the Mini Memory, there is no need to upgrade your FinalGROM 99!

Duh, you're right ... Seems like I forgot it. But it is in the FlashROM bundle.

Sorry if I repeat myself (and others) here, but please have a look at the ZIP on WHTech.

Maybe you're using inverted images? Rasmus' games are in the WHTech ZIP, have you tried those? Is your 32K alright? (Sorry for asking the obvious.)

Now, about that problem ... Unfortunately, I don't have any v2.2 consoles (which I always conflated with QI consoles anyway) to test, so during development I only had the known GROM 0 fact to work with. If QI consoles still don't work, I'd also like to know why. The CRU lines are not used at all, so that isn't it. It would help to know what exactly doesn't work (menu, selection, image load, image start). OLD CS1, could you send me a short description? Or if someone wants to get rid of his or her QI console (for €€€), please let me know.

After my vacation, I'm still recovering from some Himalayan flu, but: No, the FinalGROM 99 will not see it, even when in single mode. I didn't know something like this existed, so I'm only looking at the programs, not at the subroutines (ADVERTISER does have a GPL header, though). I could add this case to the FinalGROM 99, however, to both single and menu mode. Give me some time for the patch ...

No, you haven't , but my notification email just bounced. I'll send you a PM.

I can try, after my vacation.

Quite elegant, really. It pays to have your own emulator.

Yes, I'm sorry, I have missed your question. I mostly read the development forum. You're right about your question -- these carts have been dumped and modified to be "regular" carts. Real MBX carts had 1 KB of RAM inside them, and IIRC used a slightly different banking scheme. It's not E/A 5 format, but just a different cart image. I could have supported the original MBX carts, but since they've been converted, I thought there are other, more important things to support.

Yes please, I'd be interested in that!

There's one exception, though; There are a few auto-starting GROM carts, e.g., by Scot Foreman, that don't have a name (because there's no menu where it could show up). In that case, I use the 8(.3) filename and append it with an asterisk. That's why the PHM3xxx* show up.

As long as XB programs fit the VDP RAM, i.e., they're not stored in "long" format, the same procedure as above could probably used. Just the final jump would target XB, which is a bit more complicated, as we don't have a commented disassembly for XB. BTW, I don't need to use special memory dumps, as saved BASIC programs are already VDP RAM dumps. When OLDing, the program is put low in VDP RAM and then shifted to the top of VDP RAM. My tool, however, drops it right where it belongs, but the BASIC interpreter doesn't seem to mind.

No, not yet. In fact, this is really a hack job that has been tested with two (2) programs for far. The scratchpad usage of TI BASIC is really messy, and it could be that programs with DATA might break, among others. Also, programs cannot be larger than 7.9K -- for bigger programs I would need to include bank switching.

I've hacked a little tool to convert TI BASIC into a GROM cart BIN that you can run in an emulator and on the FinalGROM 99. It's not perfect, because you'll have to type RUN when the prompt appears. As usual, the tool needs Python 2.x. To convert an encoded TI BASIC program into a BIN, type . bas2cart.py <basic.prg> . To generate an encoded TI BASIC program (i.e., the format as it is stored on a disk) from a listing (i.e., a text file), you can use the xbas99 program from the xdt99 suite. . xbas99.py -c <listing.txt> . As an example, I used BOMBER by Roland Schlosser. PRG is the encoded BASIC, BIN the result of bas2cart. Unrelated question: I wonder if running from GROM is slower than running from VDP RAM, as I image VDP RAM to be faster than GROM. bas2cart.zipbomber.zip

Duh, you're right. I was thinking too complicated ...

Thanks for the offer (and the kind words), but I still have some labels myself. And just as we speak (figuratively), it hit me where I put the label on my harddisk. Feel free to use or alter it.

Yes, that would be possible, but only because XB is a GROM program, and GROM might be made into GRAM. Also, XB has only free GROM 7 left, so depending on the contents of GROM 6, the XB program might be limited to 8K (unless you added everything to the ROM part). For ROM programs, the GPL header would remain in the lower half ROM bank, which cannot be configured as RAM. EDIT: clarification

Actually, I think BASIC programs can -- although I don't know of any tool right now. If I had more time, I might try to write one. Basically you'd need to move the cartridge contents to VDP RAM, and start the BASIC interpreter. Not sure if that would fit into scratchpad RAM, or if you needed 32K. For XB, however, you cannot have both XB and XB program running in the FG99 at the same time. Maybe the reload feature of the FG99 would work for that. (Everything spoken theoretically, of course.)

Originally, I just wanted to do one label for me. But printing one label wasn't economical, so I decided to get more and sell them at more or less cost. I'd gladly post the original file here, but I cannot find it anymore. It's not in the backup, either. Probably I saved it from Gimp right into my upload folder, where it was purged eventually. I wished I had mailed it instead of uploading, because then I would still have a copy.

That is correct. You can use 1B to 32KB images on the FlashROM, and it will mirror the code into unused banks. This is required for bank switching. A two-bank image might use all kinds of switch addresses, as only the lowest bit is honored. But the FlashROM looks at two bits (for four banks), so the two-bank image on the FlashROM might accidentally switch to non-existing banks 2 or 3. By mirroring code, banks 0/1 are identical to 2/3, so switching doesn't break the program. I wished that images for FlashROM 99 and FinalGROM 99 wouldn't be mixed in the same thread. But as a rule of thumb, images at most 32K in size and not split into C, D, G and not ending with G are FlashROM 99 files. The FinalGROM 99 can run all FlashROM 99 images, but may require renaming.