Jump to content

SpiceWare

+AtariAge Subscriber
  • Content Count

    16,951
  • Joined

  • Last visited

  • Days Won

    10

SpiceWare last won the day on October 10 2017

SpiceWare had the most liked content!

Community Reputation

6,665 Excellent

About SpiceWare

  • Rank
    Draconian
  • Birthday 11/09/1966

Contact / Social Media

Profile Information

  • Custom Status
    Medieval Mayhem
  • Gender
    Male
  • Location
    Planet Houston

Recent Profile Visitors

91,430 profile views
  1. I hadn't looked into it before, but the PETSCIIBOTS account does link to buzz_clik. After checking a few posts I've followed this account as well, thanks!
  2. My dad talked to them, nobody else has reported this issue. They had him get a roll of automotive adhesive, and said to reinstall the plates but do not attach the cover for 72 hours to let the adhesive set. If the 72 hours was in the original instructions we missed it. I'll report back on the results after we've redone them and waited for the 72 hours.
  3. These cool PETSCII robots are periodically posted on Twitter.
  4. An example would be the holiday cart Stella's Stocking. It uses 264 scanlines due to the divisible by 4 requirement of @supercat's Better-Than-Pitfall-II music routine that's used for the menu music. All the games used 264 scanlines to prevent screen jitter/jump when transitioning between the menu and a game. BTP2 - note: need to turn off Developer mode in Stella Stay Frosty: Grandma's Revenge
  5. Thanks! We've been going back & forth via email since early May and wrapped it up last week. After my initial research into Battlezone I posted the following topic in the 2600 Programming forum to show people how to use Stella's Debugger to analyze VSYNC. Numerous values get reset with the 2nd write to VSYNC, which makes it a little bit tricky to analyze. I quite liked the Draconian cameos as well 😁
  6. @ckrtech's done up a video looking into some of the problem games.
  7. For those interested in the results of @ckrtech's research:
  8. It's out and I'd love to play it, but still no PS5
  9. Main question is can a function be moved in memory and still work. Copying the function would be fairly easy as the functions' located at &function. Size of function not sure, perhaps there's a predefine like __func__, which returns the function's name as a char[], or just copy a block of memory large enough that you know it'll get the entire function. Running the relocated function would be easy - use a function pointer.
  10. You're welcome! That's a good idea, though I don't know how you would go about it. FLASH/ROM starts at 0x0 RAM starts at 0x40000000 The driver is the first 2K or 3K of both ROM and RAM.
  11. With DPC+ using the custom ARM code is not required. I did a quick test of DK Arcade and it's running 6507 code in bank 0, which suggests its not using ARM code (or using so little that's its been fully tested and doesn't trigger the bug). From DPC+ARM - Part 6, DPC+ Cartridge Layout, emphasis added: Correct. Do note that the risk of a crash is only on the original Harmony and Melody boards. If you're making a new game you know it'll only be built with a new Melody board, so you could leave it in Mode 2 and just let people know it could crash on an older Harmony.
  12. All the drivers use MAM mode 2 for driver itself for performance reasons. The driver code is running in RAM, which does not trigger the bug. The game's C code runs from Flash memory (the "ROM"), so can trigger the MAM bug with the older Melody/Harmony. The random crashes had become a major issue when working on Stay Frosty 2 and Frantic, I was almost ready to abort those projects when we figured out the issue. From the errata sheet, no longer at the link but quoted here: In DPC+ projects the game's code sets MAM 1 to prevent the crashing. From Stay Frosty 2: #define MAMCR *(unsigned char*)0xE01FC000 int main() { MAMCR=1; // partially disable cache due to hardware bug that can crash game switch (SUB) { // ... run function by 6507 code } MAMCR=2; // reenable cache, speed needed for DPC+ driver and it doesn't trigger the bug return 0; } In BUS, CDF, and CDFJ the driver's code sets MAM to 1 before it calls main(), so the games code no longer changes it. .set MAMBASE, 0xE01FC000 /* Memory Accelerator Module (MAM) address */ /* Disable MAM (due to bug executing code from Flash with MAM enabled) */ ldr r2, =MAMBASE mov r3, #1 str r3, [r2] /* Jump to user code */ mov lr, pc mov pc, #CSTART As of CDFJ+ the driver no longer sets MAM because the bug is not a factor in the newer boards. I think, but am not sure, that @johnnywc has a one-off build of the CDFJ which does not change MAM to 1.
  13. @Random Terrain's bB pages has a section on kernel_options and a Kernel Options Chart that should help.
×
×
  • Create New...