Jump to content
IGNORED

Odd effects when converting a 2k cart into a 4k cart


harbaum

Recommended Posts

I have a weird symptom which i don't find any info on.

 

It started with the fact that the color bar cart wouldn't run in the fpga. At one point i noticed that all images that don't work at all were 2k images while the working ones were 4k. So i simply thought i'd make a 4k image of them by appending the same 2k image two times. The result at least does something. For simplicity i thought i just use stella to make sure my new 4k image actually works.

 

But to my surprise there's a difference. The 2k color bar cartridge from

http://atariage.com/forums/topic/226582-color-bar-demo/

works perfectly in stella. But once i expand it to 4k by either copying the same image to times or by prepending 2k of 0xff the displayed color bars are different. This seems to be related to PAL/NTSC video.

 

Why does a 2k cartridge expanded to 4k behave differently? The original 2k cart is auto detected as NTSC and displays the full NTSC color range. The 4k image when auto detected in stella displays the PAL palette. When forcing it to NTSC the full NTSC palette is being displayed but the whole display flickers.

 

Odd ...

Edited by harbaum
Link to comment
Share on other sites

But once i expand it to 4k by either copying the same image to times

Don't know about this without being able to see your doubled up ROM, but

by prepending 2k of 0xff the displayed color bars are different

that will cause Stella to believe the ROM includes RAM. 2K cartridges only contain ROM while anything 4K or larger might contain RAM so Stella will analyze the ROM image for signs that it includes a space for RAM. The convention in ROM dumps is to fill RAM space with the same value - this bit of code from Stella is used to detect the presense of SuperChip RAM (an extra 128 bytes of RAM):

 

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
bool Cartridge::isProbablySC(const uInt8* image, uInt32 size)
{
  // We assume a Superchip cart contains the same bytes for its entire
  // RAM area; obviously this test will fail if it doesn't
  // The RAM area will be the first 256 bytes of each 4K bank
  uInt32 banks = size / 4096;
  for(uInt32 i = 0; i < banks; ++i)
  {
    uInt8 first = image[i*4096];
    for(uInt32 j = 0; j < 256; ++j)
    {
      if(image[i*4096+j] != first)
        return false;
    }
  }
  return true;
}
The reason that's looking at 256 bytes, and not 128, is the cartridge port does not contain a Read/Write line so extra RAM is often implemented by repurposing an address line as the Read/Write line. The repurposed address line means the RAM shows up twice, one range is used for reading while the other for writing. Edited by SpiceWare
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...