Jump to content

ralphb

Members
  • Content Count

    828
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by ralphb


  1. 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?

     


  2. Yes the map is randomly generated and is updated when you light it up, tunnel through walls or pick up items. One of the objectives when I started this project was to use SAMS for something that could not be done using 32K+ROM, but as the game is now there is so little variation in the map that it could be much smaller without affecting the game play.

     

    Well, hard to argue with that. :thumbsup:

     

    But the FinalGROM 99 does have 512 KB of banked RAM ... just sayin'. ;)


  3. Ordered a solder paste stencil form oshstencils.com.. I'll see how that goes. Hope to have one assembled by the end of the month.

     

    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:

    • Like 2

  4. 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).

    • Like 8

  5. I don't think the FinalGROM supports the pagedcru cartridge paging method.

     

    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.


  6. Does this mean that a part of the code for the game Tutankham will probably have to be modified by you?

     

    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.


  7. 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.


  8. 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!

    • Like 3

  9. Alright, I happen to have a diagram of the menu structure here:

     

    post-35214-0-89507600-1501172616_thumb.png

     

    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

    • Like 3

  10. Finally got to try it out tonight and it works great for the most part, but I'm running into a few problems:

     

    1. I have to hit reset once for FinalGROM99 to show up in the menu (not a big deal, but I'm curious as to why this might be)

     

    2. Some of the games aren't showing up in the menu. I downloaded the ROM zip that was linked to but games like Tutankham, Video Vegas, Warzone, etc. aren't showing up but many of the others do. I have 9 pages of games, but I should have more than that. Is there a directory structure that needs to be followed or something?

     

    3. There are some multi-lingual entries like the ones for Hunt the Wumpus. I assume those can't be removed because that's how the original rom is?

     

    4. The first three entries in the menu are PC crap like trash, filesystem, and other hidden file garbage. Is there a way get rid of that?

     

    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.


  11. 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?).

    • Like 1

  12. I have a '99 w/ PEB and the usual slotted in and a FlashROM99. Is there some mechanism where I can type in a BASIC prog on a modern machine and get it onto the SD card and somehow have it accessible as an Extended BASIC program?

     

    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.


  13. 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.

    • Like 2

  14. So my question for Ralph: Can I just hardwire the two reset buttons together? That is, have one button that causes both resets to be triggered at the same time.

    Is there some other use case that I would lose if I did this?

     

    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-=.

    • Like 2

  15. I would be wonderful to be able to "map" a real SD to this slot. Would that be possible? Or is that what is being stated here?

     

    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.


  16. Could someone be so kind as to link me to a U.S. seller of SMD switches that would work for the FinalGROM99 ?

     

    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.

×
×
  • Create New...