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

Asmusr

Members
 View Profile  See their activity

  • Content Count

    4,000

  • Joined

  • Last visited

  • Days Won

    13

Posts posted by Asmusr

  2. Posted

    2 hours ago, Lumpy said:

    I have a FinalGROM cartridge I purchased earlier this year and it has never worked properly. When I first received the cartridge it was not recognized at all when plugged into the port. The only option was TI Basic. This was with the one TI-99 I had at the time, a beige unit with the 1981 startup screen. I have ten other cartridges (XB, TEII, and several TI and Atari games)and they all work fine in this computer. I tried changing the port connector and reloading the SD card with several different images but nothing worked. I contacted the seller and I returned the cartridge to him and he says he replaced it but I still had the same issues with the unit he claims was replaced.

    I then went out and found and purchased three other TI-99/4A computers. Two black and silver units and a V2.2 beige unit with the 1983 startup screen. The two black and silver units display the FinalGROM menus and work with many but not all of the program choices (this is with a PEB and TI 32K installed and running). The V2.2 beige unit displays the initial FinalGROM menu but choosing anything locks up the computer with a blue screen and three vertical lines.

    In all cases the LED on the FinalGROM never comes on nor do either of the reset buttons on the FinalGROM (TI reset or FG reset) work on any of the four computers. I tried to update the AVR and PLD files by copying the files to a blank SD card and powering on but no LED activity and no changes. I checked over the FinalGROM for solder issues but I don't see any problems.

    Any other suggestions I could try? I would really like to get this going but at this point I think there is an issue with the FinalGROM.

     

    You need to talk to @ralphb who developed the FinalGROM. He should be right here.

  4. Posted

    1 hour ago, PeteE said:

    After some thought, I agree with you on this.  The F18A should try to match the horizontal sync timings of the 9918A.  I'm not going to make a F18A version of the demo.

    Well, after some thought I also agree with you 🙂. Because there is more to this demo than just the scanline detection, and everybody should have a chance to see it. But maybe there is a simple fix once we know what the issue with the F18A is. I could image that it's setting the collision flag on every VGA scanline instead of only setting it on even scanlines. Would that break the demo? I set up my F18A machine today for the first time since corona to be able to test it. 

    • Like 2

  5. Posted

    On 12/17/2020 at 7:16 PM, Asmusr said:

    Yes but it won't work even if I remove that line, because my F18A emulation is hacky and calculates one sprite collision flag for the entire screen.

    I discovered that I did actually fix this in the past, so the F18A emulation is also supporting line by line sprite collision detection. 🙂 This means that the demo is now running in js99er in the F18A emulation, but it doesn't work on real hardware. That makes it even more interesting for me to find out why. @matthew180

    • Like 3

  6. Posted

    27 minutes ago, PeteE said:

    I didn't mean that I wanted to push the F18A to the limit, I just wanted people who only have F18A to be able to view it, instead of the demo looking like a garbled mess.

    But if you fix it the next person who make a cool demo for the 9918A will run into the same problems with the F18A. So I still think it's up to Matthew to fix.

    • Like 2

  7. Posted

    57 minutes ago, PeteE said:

    But I'm also thinking a better solution would be to detect F18A and run the GPU to change the registers using the F18A-specific horizontal interrupt.

    I think it's more up to Matthew than you to fix this. Using the F18A capabilities for a demo is fine, but not nearly as cool as making it run on the 9918A. If we went in and really pushed the F18A to the limit, a whole new dimension would be opening.

    • Like 2

  8. Posted

    31 minutes ago, PeteE said:

    The page mapping wraps at the end of the cartridge image for Classic99 and FinalGROM99, for other ROM carts you would repeat the image to fill the ROM.  But it was a mistake, I forgot to mask of the uppermost bit of the angle register when calculating the bank, taking advantage of the last 32 angles are mirrored from the first 32 but with the colors reversed.

    Wouldn't a real cart with a 27C010 (128 KiB) also wrap around?

  11. Posted

    3 hours ago, pixelpedant said:

    A Myst-clone (slideshow) style adventure, for example.  Crazily arduous to develop graphical assets for, using original era tools.  Pretty easy, in the days of Magellan and Convert9918. 

    I don't agree. Drawing a few characters and sprites for a homebrew game is doable for a single developer. Drawing new graphics on a larger scale is still a huge task. Unless you convert existing graphics, which can still be a big task, but then you run into issues with copyright and credits.

    • Like 1

  13. Posted

    5 hours ago, Shift838 said:

    The setup program just creates a carts, disks folder etc.  You can always go in and change it, but if installing MAME via OoeyGUI it does it all for you.  But you can move things around and customize as long as you change the configuration directories and resave the configuration.  Of course copy your carts and disks to those directories.

    It doesn't seem to work if there is a space in the directory name.

  15. Posted

    27 minutes ago, Omega-TI said:

    Here ya go!  Sorry about the size, but I figured you would want all the detail.

    That looks really weird. Instead of solid colors each character appears to have two bands of different colors. I think it would be difficult to use that for anything.

    • Like 1

  17. Posted

    3 minutes ago, pjduplooy said:

    Hi Asmusr

     

    How does one generate a rpk from files?  I would like to make a rpk from the newest Extended Basic G.E.M.

    rpk files are really zip files. Try to rename one and see what's inside it. If you want to create a new rpk you need to edit the layout.xml file to match the ROM and GROM files inside the archive. For more information see https://www.ninerpedia.org/wiki/MESS_cartridge_handling#RomPacK_cartridge_images_.28RPK.29

    • Like 2

  18. Posted

    9 hours ago, Shift838 said:

    OoeyGUI 4.0 auto detect between .rpk and .zip cartridge files.  this is new compared the the last versions.  As @DavidCstated, just put them in your carts folder.

    Thanks, so does that mean it doesn't work if they are not in the carts folder? I usually generate my rpk files in the project folders they belong to.

  25. Posted

    27 minutes ago, Omega-TI said:

     

    That sounds logical, but in the past, the size shown has also been associated with the size of the .BIN image.

     

    For instance:    Example #1:  << CLICK HERE >>

                             Example #2:  << CLICK HERE >> 

    That was to distinguish them from the other files with the same name. I don't think that should be the standard.

    • Like 1
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...