Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

ralphb

Members
 View Profile  See their activity

  • Content Count

    828

  • Joined

  • Last visited

  • Days Won

    1

Posts posted by ralphb

  4. Posted

    As for the problem with the "QI" console, now I cannot even get the system to boot up with the FG99 inserted. My other "QI" system is mounted on MDF so I will have to pull it down this afternoon.

     

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

  5. Posted · Edited by ralphb

    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.

     

    post-35214-0-54857700-1511523789.png

     

    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!

    • Like 9

  9. Posted

    Welp, yup. I have now tried two different "QI" boards with both old and "QI" power supplies, and also swapped the GROM port posts just to be sure. The problem appears to be the "QI" boards.

    I am kind-of bummed as this has been my main non-F18A system and it is beige. Ah, well. It would be interesting to figure out what the problem is.

     

     

    I tracked this down before when I was cleaning up incorrect values on my copy of the original non-QI schematic. I'm not aware of any other missing signals on a QI's GROM port, except for two:

    Pin #4: CRUCLK-

    Pin #6: CRUIN

    Both lines seemed to retain the same, small resistor values between boards as they terminate at pins 22 (CRUCLK.A-) & 33 (CRUIN) respectively on the console I/O side port.

    I wish I could assist tracking it for you as I have most of my non-QI boards weeded out, but alas, I haven't got ahead enough on hobby finances to take the FG99 plunge. :(

     

    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.

  10. Posted

    after looking at this, it has no program header..so it won't load on the finalgrom unless possibly with only this single grom on a card..

     

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

    • Like 3

  13. Posted

    It lets you run your title to a good stopping point before you save, then backs up all of VRAM except the screen plus scratchpad (so breakpointing right before the screen is drawn is good). That lets you skip the prescan. It's just a normal 16k copy cart (which is why we lose the screen - 16k VRAM and 16k ROM... though I think there's an option to skip the disk buffers instead...) Anyway, then the emulator runs until the GPL interpreter hits its main loop, and then it saves.

     

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

  14. Posted

    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.

    • Like 1

  16. Posted

    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.

    • Like 1

  17. Posted

    To run an XB program from a cart I guess you would need to hook into XB after the system is initialized and right before the "command prompt" is shown. From the hook you would jump a machine code or GPL program that restored the scratch pad, 32K and VDP memory from a memory dump of the XB program and then returned to XB (or possibly executed a RUN command). I don't know how to do that and whether it's possible.

     

    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.

  19. Posted

    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

    • Like 5

  22. Posted · Edited by ralphb

    Wouldn't it be possible to patch an XB image to restore the XB program from additional ROM banks into 32K, and then start the interpreter?

     

    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

  23. Posted

    Basic and XB programs cannot be converted to cart format.

     

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

  24. Posted

    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.

  25. Posted

    The repository on whtech /Cartridges/FlashROM99/Classic_Carts.zip is full of 16k and 8k carts that are functional on the FlashROM99. So "NOT 32K" doesn't make a 100% sound discriminator. I'm failing to find a reference to it, but I thought Ralph said that FlashROM99 will fill its 32k of SRAM with repetition of 8k or 16k rom images.

     

    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.

    • Like 5
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...