Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - Do CRAM accesses require an external slot?

Reply to topic
Author Message
  • Joined: 24 Sep 2018
  • Posts: 66
Reply with quote
Do CRAM accesses require an external slot?
Post Posted: Fri Sep 28, 2018 3:40 pm
The rule for accesses to normal VRAM is that one cues up the read or write, then it will actually happen when the VDP next has an available opportunity — an 'external slot'. Those can as far apart as 16/171ths of a line, during the main part of the display, but they're a lot more frequent for most of retrace.

What's the rule for CRAM? It strikes me that:

The necessary read bandwidth when drawing the display is, very naively, double. The VDP puts out four tiles width of graphics data in every 16 of its access windows. So that's 32 pixels in 16 access windows. Which is 32 random palette lookups in 16 access windows.

But, obviously, it's a tiny area, in its own address space, because it's not DRAM.

So what are the rules for writing to CRAM? I can guess at least three possibilities:


  • it's the same as writing to the VDP registers — no need to wait for an external slot;
  • it may be faster, but programmer access uses the same underlying logic for addressing and address incrementing as VRAM so it's built on top of the same mechanism — you need to wait for an external slot;
  • it's actually less available than VRAM — it has a similar external slot mechanism, but they're even less frequent.


I guess that the second one is most likely, but does anybody have a definitive answer?[/list]
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14685
  • Location: London
Reply with quote
Post Posted: Fri Sep 28, 2018 4:32 pm
I think the rule is that writes take precedence over reads, so you get visual noise (the written value replaces the read value). Thus mid frame writes must be carefully timed to be offscreen or otherwise hidden.
  View user's profile Send private message Visit poster's website
  • Joined: 24 Sep 2018
  • Posts: 66
Reply with quote
Post Posted: Fri Sep 28, 2018 5:39 pm
Maxim wrote
I think the rule is that writes take precedence over reads, so you get visual noise (the written value replaces the read value). Thus mid frame writes must be carefully timed to be offscreen or otherwise hidden.


An option I didn't even think of; this makes perfect sense. I'd be curious to know how wide the noise is — do you destroy a single pixel of output, a column's width, something else? — but I guess it doesn't really matter.

Thanks!
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14685
  • Location: London
Reply with quote
Post Posted: Fri Sep 28, 2018 6:53 pm
Actually I suspect the read bits OR together, because the noise seems to look less colourful than if it just took precedence. One byte written gives one pixel of noise.

Actually my "Ono" game tries to write to the palette very fast during active display, and reportedly some of the colours don't show properly - I'm not sure why.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Oct 01, 2018 8:38 am
Maxim wrote
Actually my "Ono" game tries to write to the palette very fast during active display, and reportedly some of the colours don't show properly - I'm not sure why.


I investigated this a couple years ago - I'm sure you remember we found out we need to wait at least 26 cycles between writes to VRAM (or to CRAM, as they pass thru the same VDP)
  View user's profile Send private message Visit poster's website
  • Joined: 24 Sep 2018
  • Posts: 66
Reply with quote
Post Posted: Mon Oct 01, 2018 2:45 pm
sverx wrote
Maxim wrote
Actually my "Ono" game tries to write to the palette very fast during active display, and reportedly some of the colours don't show properly - I'm not sure why.


I investigated this a couple years ago - I'm sure you remember we found out we need to wait at least 26 cycles between writes to VRAM (or to CRAM, as they pass thru the same VDP)


Does that imply that they do require an external slot after all?

I guess you should be able to see it if so on real hardware — the CRAM dots would be aligned to the external slot locations.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14685
  • Location: London
Reply with quote
Post Posted: Mon Oct 01, 2018 5:35 pm
I guess you could make a test program which writes to the palette every 26 cycles and see if the noise is aligned vertically. It also means you have an upper limit of 8 palette writes per line.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Oct 02, 2018 8:23 am
from what I read somewhere (but I don't remember exactly where!) the VDP clock isn't even exactly 1.5 times the CPU clock so you won't get that alignment easily at all.
  View user's profile Send private message Visit poster's website
  • Joined: 24 Sep 2018
  • Posts: 66
Reply with quote
Post Posted: Tue Oct 02, 2018 2:49 pm
sverx wrote
from what I read somewhere (but I don't remember exactly where!) the VDP clock isn't even exactly 1.5 times the CPU clock so you won't get that alignment easily at all.


If I'm just seeking to verify whether CRAM dots are always aligned with external slots, as a proxy for whether CRAM writes occur only upon external slots, couldn't I just write CRAM data as quickly as possible and not worry about alignment? For the sake of the test, I don't actually care what ends up in CRAM.

That's a completely academic question; I don't actually have real hardware to test on.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Oct 02, 2018 3:07 pm
TomHarte wrote
couldn't I just write CRAM data as quickly as possible and not worry about alignment?


sure, but any write that is too close to the previous will make that never happen, thus your speed should be limited to at least 26 cycles.

-:
  outi      ; 16 cycles
  jp nz,-   ; 10 cycles
  View user's profile Send private message Visit poster's website
  • Joined: 24 Sep 2018
  • Posts: 66
Reply with quote
Post Posted: Tue Oct 02, 2018 3:12 pm
sverx wrote
TomHarte wrote
couldn't I just write CRAM data as quickly as possible and not worry about alignment?


sure, but any write that is too close to the previous will make that never happen, thus your speed should be limited to at least 26 cycles.


Right, I just meant for the sake of verifying whether external slots are when CRAM writes occur.

Slightly digressive question: my most relevant prior experience is on the MSX, which has essentially the same distribution of external slots (they're different in the border, but still one every sixteen during pixels), but the received wisdom is 27 cycles between writes rather than 26.

That's because there's a setup cost* after every byte is transmitted to the VDP before it even begins waiting for a window. So there's a bit of extra delay for that — otherwise the necessary delay would be just 32/1.5 ~= 21.33 cycles.

I guess the Master System must be a tiny bit faster at getting ready to write?

* 2us per the data sheet, but clearly not exactly that for the 27 number to work.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Oct 02, 2018 3:19 pm
TomHarte wrote
but the received wisdom is 27 cycles between writes rather than 26. [...] I guess the Master System must be a tiny bit faster at getting ready to write?


The received wisdom here is either 28 or 29 cycles, depending on which tech doc you're reading. But testing showed that it's 26 - we still have to find a single occurrence of failure at that rate.
  View user's profile Send private message Visit poster's website
Reply to topic



Back to the top of this page

Back to SMS Power!