ralphb

Oh, now you're spoiling it! I did indeed consider an upgrade to 1 MB for the final version, as my local supplier suddenly has a 1M x 8 IC in stock. I only go the Digikey if I have to, as shipping is expensive, and I have to add an additional 19% sales tax onto the quoted prices.

No, I did this entirely on my own. I guess it might seem aloof or something, but I simply enjoy figuring stuff out and finding solutions for difficult problems. Asking for help would be kind of cheating. But then of course I did rely big time on a lot of previous work by other people. Tursi's comments on GROMs given to somebody else were particularly helpful, and for a lot of other TI internals AtariAge had been a gold mine. The FG will work with QIs just as other carts, i.e., ROMs won't. But then I think you could add a GROM wrapper around those images so that they'll show in the menu. The FG would make that easier. I didn't dare to test GROM 0-2 yet, with or without the console GROMs present. Technically, they're supported, but I haven't tested what would happen. Can't say for now. Personally I find SD cards extremely comfortable and much preferred to cables, but sure, if it's not a big deal, why not? I'll get back to you about this idea. Yes, it's working quite well with a flat solder tip, although I did trash the first five boards (both by hand and with a small Chinese reflow oven). Both sound great! I'll definitely get in touch with you! Cheat codes would be a matter of modifying the images, as are ROM images for QI consoles. It's not a FinalCartridge (or whatever they were called) ... MESS carts are just cart dumps, so they work. n fact, what you see in the video are unzipped MESS rpk's. Zipped files, however, cannot be supported, as there's simply not enough RAM to uncompress them. Maybe one could use uncompressed ZIPs, but I don't think it's really worth the effort. Printed carts are kind of difficult, as could be seen with the FlashROM. But some people are very good at finding empty standard shells, and maybe they'll provide some for us.

Wow, thanks for your enthusiastic comments! Time to get working again then ... Yes, you'll have 512 KB of ROM, divided into 64 banks. Yes, I kept the 171 images limit, but now it's per directory. You could have 171 directories, and each one of that could have 171 programs, or maybe more directories. Directories can be up to 127 chars deep, including /. In fact, I recommend to have fewer games per folder, as it takes a bit longer to scan GROM images for building the menu. GROM images are horrible. Not only can the image name appear way down in GROM 6, but there are also autostarting GROMs without name at all. Those are listed with their filename plus an asterisk (*). Not yet, but I'll try to. All of those only page the upper 4K, right? Or is it the lower? Note that the images were just everything I could find on WHTech in one particular folder. I haven't tested all of them, but some aren't playing nice (Schach for the TI 99/4 (?) comes to mind). That's still totally open. Are there any cartridges (other than MM and WSM mentioned above) that had RAM in past? I would imagine that if you make the RAM bankable, you'd do so independently of the ROM. But I'd like to stress that there's not that much space left in the CPLD, so I cannot realize every good suggestion here, I'll think about it. Pressing S would, of course, start entry 'S'. But maybe with a modifier ... Thanks for all the feedback/suggestions!

*** UPDATE: Please see here for final FinalGROM 99! *** Since fall I've been working on a successor cartridge to the FlashROM 99, and my prototype is finally in a state where I can present it: https://www.youtube.com/watch?v=_ZUQY5fRBhc As you can see, the look and feel of the FinalGROM 99 is very similar to the FlashROM (as are the videos ). But the new cart also offers some substantial improvements: supports both ROM and GROM images has 512K of RAM for 64 banks or 56 banks + 5 GROMs supports folders can use raw cartridge dumps fits regular cartridge shell (eventually) Note that the reset button is not working yet, so I had to turn the console off and on again in the video. At the heart of the FinalGROM 99 is a CPLD (complex programmable logic device), which replaces all of the 74 logic ICs found on the FlashROM. CPLDs are similar to very, very small FPGAs, but predate those by quite a bit. The XC95144XL used here is probably the last "modern" chip that supports 5V signal levels. The microcontroller still manages the SD card, loads images, and generates the menus. While the picture shows an ATmega 328, a 168 is actually sufficient. The SRAM chip has 512K, which is the upper affordable limit for 3V parallel SRAM. This yields 64 banks, with GROMs residing in the upper 8 banks (although only 5 are used now). Finally, the voltage converter transforms the 5V supplied by the TI into 3.3V used by all board components. That includes the CPLD, which can read 5V signals, but outputs 3.3V signals (which the TI99 can understand). Probably the biggest downside of the FinalGROM 99 is the reliance on SMT technology, which is more difficult to solder by hand. But 5V tolerant CPLDs are not available in through-hole or PLCC format, the only exception being some Atmel CPLDs that could only be programmed by ridiculously expensive software. But please note that this is a prototype! This cart won't even fit the TI cartridge port, as my board layout has been exceptionally stupid. But thanks to the port expander, I could still use the board and even add a FlashROM for debugging purposes. At last I found the true purpose of a Widgit! The final version of the FinalGROM 99 will replace the microcontroller and the voltage controller by SMD parts. I'm still undecided whether I should go full SMD or keep through-hole caps and resistors. Button and LED will definitely remain through-hole, so that people can mount those parts in a cart shell. The next steps will be to design the final board and get new PCBs. That done, I can send out some test boards. Note that updating the CPLD will require a JTAG cable, whereas the ATmega can be updated via SD card (at least that's the plan). Do you have any reasonable suggestions for features? One thing that had already been suggested was write support. If the logic fits, I could add a DIP switch (or an SD config file) that would enable writing to select parts of the RAM. Are there any precedents for this? I know of Mini Memory and the Wiesbaden Supermodule -- are there any others? Finally, please excuse the somewhat grandiose name of the cart. The natural name FlashGROM seemed just too close to FlashROM, so to avoid confusion I went with FinalGROM. EDIT: added link to released cart

Yes, surely, sometimes weird code translates into a very simple circuit. Bank switching is one such example, albeit a very simple one.

That's pretty werid, but also cool that you and/or someone was able to re-engineer that. Thanks for posting that snippet!

Thanks, Tursi, for the clarification! And also Michael for confirmation. So wrapping is not an issue. And I also discovered the source for my confusion. When looking at PHM3053G.BIN (TI Invaders rpk) from WHTech, the upper 2K are filled with data, and it's not just garbage, as there's "PRESS/ANY/KEY/TO/BEGIN" in there. But now it dawned on me that >1800->1FFF is just a mirror of >0800->0FFF in that BIN. Regarding "gromemu", where would that go? In layout.xml, <pcb type="gromemu">? Edit: Bonus questions, are there any known 8K-GROM BINs? I was looking at Congo Bongo, whose GROM 4 has the upper 2K mirrored, but the upper 2K of GROM 3 are unique -- so either they're junk, or valid data ...

Thanks, Michael, I'll use "gromemu" for 8Ks from now on.

I found something odd about GROM addressing in MESS 178. This short GPL program . main fmt row 4 col 8 htex '[email protected]>6000' fend move 10,[email protected],[email protected] move 10,[email protected],[email protected] b main aorg >7000 t7 text 'TEXT >7000' aorg >7800 t8 text 'TEXT >7800' end . should print . [email protected]>6000 TEXT >7000 TEXT >7800 . on screen, and it does do in Classic99 and on real iron (well, my GROM cart). But in MESS the last line is . [email protected]>6000 TEXT >7000 TEXT >7000 . Now my understanding is that real GROMs are 6K and the address counter does wrap around at >17FF, although the Ubergrom doesn't. On the other hand, there are countless cartridges with look-a-like GROMs that are 8K in size and that need to address those bytes. How does MESS handle GROM addresses above >17FF? Why am I missing the third line? Can I enable 8K addresses in the layout.xml? The BIN file with the program: gmove.bin EDIT: Fixed the output.

Yes, thanks, most text is now very readable. It's not perfect, as buttons, icons, spacings, and even the file open dialog do not scale. But for me the modified TIMT works fine, so again thank you!

No way, I'll stop using this monitor only if I get a 5K monitor.

Michael, it just occurred to me that TIMT is really, really hard to read on a 4K monitor. Is there anything you could do (as Java 8 seemingly can't)?

Thanks, Bmack36!

OK, thanks for the clarification. @Matthew: Could you publish online that one page manual that came with the F18A? I cannot find mine anymore, and it seems to be the only source for the DIP switch configuration.

You're right. I just checked Parsec on a US system, and the yellow alien does crash into the scenery! They wouldn't on an EU system. So there is some difference in game play, in some sense. I wondered how the programmers compensated for different Hertz, and now I know they didn't. But isn't there a DIP switch on the F18A for selecting the frequency? I cannot find the original leaflet that came with the F18A anywhere online.

Fair enough, but both are 50 Hz machines. Here's a short video showing Parsec on the F18A: parsec.mp4

Great effect! How about adding flying into the screen? (Brings back horrible memories of Windows ... )

Maybe I'm wrong, maybe this has been discussed before, but: There's something odd about the timing on a F18A system. Take a look at this screenshot of Parsec running on a European TI 99 with a F18A, version 1.6 (I think): You may have noticed that all alien craft are flying lower than on a regular TI. Consequently, if you move your ship up, you can let the game sit alone without your ship ever crashing, and the aliens achieving insane speeds. On a regular TI, the ship crashes rather soon. I guess that Parsec is using auto-motion, so slow alterations in speed (VDP timer? GROM clock?) would cause this. Are there other explanations for this? (The image looks funny as I photographed my 4K monitor where the TI/F18A is running as picture-in-picture -- quite a convenient setup for development.)

That's pretty cool looking! Thanks for building these.

No idea how the Navarone actually works ... Don't they switch -5V (instead of +5V)? Does TI Invaders plus any Atarisoft work for you?

What a great hack -- awesome!

Hehe, that might even work, but certainly not in a compatible way. I don't even if know if there is a common standard for mice that all/most legacy programs use.

I'm currently working on a GROM-capable successor cart, and yes, it will have more RAM. The prototype PCB should arrive within some days, but it'll take some more months before the cart is ready to ship.

Can the TI Diagnostics module be converted? Someone asked me about a FR99 conversion to check up his half-broken TI 99 ...

Last night I finally released a new version of xdt99. The main new feature is the introduction of xhm99, an HFE image manager for HxC floppy emulator images. xhm99 can convert from disk image to HFE image and vice versa. . xhm99.py --to-disk image.hfe xhm99.py --to-hfe disk.dsk . Additionally, it supports all options of the xdm99 disk manager to manipulate HFE images without conversion. For example, to list the contents of an HFE image, simply type . xhm99.py image.hfe . If you want to add, extract, rename, or remove files to/from/in an HFE image, type . xhm99.py image.hfe -a file.txt -f df80 # add file.txt in format DIS/FIX 80 using filename FILE xhm99.py image.hfe -e FILE -t # extract FILE from disk as TIFILES file file.tfi xhm99.py image.hfe -r FILE:NEWNAME # rename FILE as NEWNAME on disk xhm99.py image.hfe -d NEWNAME # delete NEWNAME on disk . If you have an E/A #5 program meant for Classic 99 that you want to run on real iron, type . xhm99.py image.hfe -X dssd -a EA5FILE EA5FILF -t . to create a new HFE image with that E/A #5 program. You can resize HFE images, e.g. from SSDD to DSSD so that the TI controller can read them: . xhm99 image.hfe -Z dssd . If you have a controller with 80 track support, you can also create or convert to 80 track images: . xhm99 image.hfe -Z dssd80t . All of these commands work with xdm99 and disk images as well. Note that xhm99 only supports TI floppy formats (i.e., Shugart/IBM), so for all other formats you would need to rely on the original HxC tool. And I still need to add support for DSDD80T disk images. xdt99 is available here, and the full manual is found here. Finally, this is the first release of xhm99, so if you have an HFE image that xhm99 cannot process I'd appreciate it if you could send me a bug report.