Advantages of SNES hardware vs. Genesis hardware

Quote:

---

Originally Posted by kool kitty89

Hmm, interesting. The line buffers don't span an entire screen's width of pixels, I assume (NOT like the 7800/Panther/Jaguar), but are shorter, more limited buffers. (otherwise it seems like there'd be a lot more potential flexibility there)

---

It has to be a full 320 pixel line buffer. All of the sprite tile data is read in before the line output is started and you can fill an entire line with sprites. I was originally rather surprised that they weren't doing all their rendering to the line buffer; however, I think they would need two line buffers to make that work so that they could render the next line during active display while reading from the current buffer.

Quote:

---

Originally Posted by kool kitty89

With that much buffering, it seems like optimizing around cheap, commodity FPM DRAM would have made a lot of sense over the VRAM they used. (at 16-bits wide it should have had similar peak bandwdith to the dual port 8-bit VRAM, but cheaper)

---

I'm not intimately familiar with the timing of FPM DRAM, but I'm not sure you could get the same actual throughput without requiring longer sequential reads.. With the serial port of the VRAM, you can setup a new address while still reading data from the previously setup address. This allows the VDP to read a byte every cycle except for during refresh (and external access slots). The only restriction is it has to read data in 4-byte chunks. This is conveniently the same size as a single tile row. Less conveniently, it's the size of two name table entries which is why vscroll resolution is limited to 2-columns. If you can do address setup and two sequential reads in the span of 4 cycles, I can see how word-wide FPM would work.

There's no way fpm dram could be used for the VDP, it's just too slow for random accessing, reading tiles and nametables from all different addresses would kill the sequential dram advantage.. the only way would be to use separate memories: one for tiles and another for tables, that way seq. accesses could be abused somewhat

Quote:

---

Originally Posted by Mask of Destiny

It has to be a full 320 pixel line buffer. All of the sprite tile data is read in before the line output is started and you can fill an entire line with sprites. I was originally rather surprised that they weren't doing all their rendering to the line buffer; however, I think they would need two line buffers to make that work so that they could render the next line during active display while reading from the current buffer.

---

Ah OK . . . yeah, double buffering would be needed (which 7800/Panther/jaguar do dual line buffers).

I guess it's just a 320x6-bit line buffer.

Quote:

---

I'm not intimately familiar with the timing of FPM DRAM, but I'm not sure you could get the same actual throughput without requiring longer sequential reads.. With the serial port of the VRAM, you can setup a new address while still reading data from the previously setup address. This allows the VDP to read a byte every cycle except for during refresh (and external access slots). The only restriction is it has to read data in 4-byte chunks. This is conveniently the same size as a single tile row. Less conveniently, it's the size of two name table entries which is why vscroll resolution is limited to 2-columns. If you can do address setup and two sequential reads in the span of 4 cycles, I can see how word-wide FPM would work.

---

Hmm, in H32 (with VDP at 10.74 MHz for RAM accesses), that would seem pretty doable by late 80s FPM DRAM standards. You'd need 3 cycles for the first read (random access) and then a page-mode read in 1 cycle, though you might manage a random access in 2 cycles, given RC times of some 80-120 ns DRAMs of the time. (in which case you wouldn't need FPM access at all, same thing for PSRAM -actually the MD's main RAM is fast enough for that too)

For H40 with a 13.4 MHz clock, it would be a good bit tougher, but the 3+1 cycles per 32-bit read should still have been doable, but you'd almost certainly need FPM access for that case, unless you went to 70 ns DRAM (which might not have been cheaper than VRAM, if available at all) or certain faster examples of 80 ns DRAM. (actually, those 64kx16-bit 80 ns Toshiba FPM DRAMs Sega used in the Sega CD, SVP, and 32x fit the bill for that too, with an unusually low 135 ns RC time)
See:
http://www.datasheetarchive.com/dl/S...ns-0078695.pdf
(more typical RC times for 80 ns RAS DRAMs is 150 ns though, which would be just short of what H40 needs)

If you used a 32-bit bus, you could get that 4 bytes per 4 cycles throughput/latency easily with really cheap/slow DRAM, but that would mean another 16 data lines on the VDP. (and enough DRAM chips to provide that width . . . not sure if 16-bit wide 256 kbit DRAMs were available, so it might have meant using 128 kB instead of 64 kB to be practical, and 32-bit wide 1meg DRAMs weren't generally available either, so switching to a single DRAM later on wouldn't be simple)

Using page mode would have made more sense with the speeds and RAM capacities involved, unless you were doing a different design centered around a shared main bus for everything, albeit then FPM AND 32-bits wide might make more sense and have more vairable features to allow less VDP time and more CPU time. (with contention) Hmm, even without page-mode access, you could have something like a 32-bit wide Amiga-ish arrangement. (and double the bandwdith over OCS would add a lot of potential . . . more than AGA actually implimented too -with similar bus sharing to OCS/ESC, it should have allowed for 2 playfields up to 6-bits each, or 1 all the way up to direct 12-bit color, plus double the blitter width too, and should have been doable in the late 80s too -would have made more sense than Miner's high-res and VRAM-centric Ranger chipset)



Then again, Sega might have had particularly attractive pricing advantages on that VRAM . . . or just an initial stockpile related to the arcade (so more a short-term advantage), and still cheaper than using SRAM in any case. (like PCE and SNES did)

Maybe some time to market advantages too, though I'm not sure optimzing a DRAM controller and interface for 16-bit wide FPM access would have been much worse than optimzing for VRAM. (SRAM obviously would be easier though . . . using PSRAM for main RAM also probably saved R&D time/overhead compared to implimenting another DRAM controller and possibly a bus latch to avoid 68k wait states -ST/Amiga style; though, on the latter note, having a latch for the 68k along with a 1/2 bandwidth interleaved DMA mode for the VDP would have been pretty nice)

Considering memories were 150ns or at best 100ns in 1989, no way they could pull out -80 chips.. Even so it's just too slow for the amount of shit the VDP is pouring out.
On each 8 clocks (8pixels) you need to read 2 nametable words and 2 tiles (BG+FG). This alone weights 20 memory accesses:

Plane A tableword: random access with 1 consecutive byte [Type 1 access]
Plane B tableword: random access with 1 consecutive byte

Tile indexed by tableword A: random access with 3 consecutive bytes [Type 2 access]
Tile indexed by tableword B: random access with 3 consecutive bytes

How much time does each kind of access take considering 80ns impossible rams at 1989?

Type 1:
Data valid after 80ns from RAS,
VDP needs time to latch the data (lets consider a split 10ns here, but it's much more) 10ns
Now you need to bring CAS high, prepare address+1 10ns (Tcp)
Bring it low again and wait for data valid which is about 30ns
Latch data: 10ns
Precharge (deassert) RAS: 40-60ns, depends on model
TOTAL time for Type 1 (nametable accesses): 180ns.
However the VDP doesnt run at 100MHz so forget about 10ns split times, at best it could run at 4x times the pixel rate: so minimum slices are 25ns minimum.. meaning that it would take the VDP 275ns to make the above access...

Type 2:
Data valid after 80ns from RAS,
Latch data: 10ns,
CAS precharge + prep address increment: 10ns,
Page access: 30ns,
Latch data: 10ns,
CAS precharge + prep address increment: 10ns,
Page access: 30ns,
Latch data: 10ns,
CAS precharge + prep address increment: 10ns,
Page access: 30ns,
Latch data: 10ns,
Precharge (deassert) RAS: 40ns.
TOTALS: 280ns.. considering the 4x pixel clock burden (~25ns slices minimum): 475ns

We need 2 accesses of each type for 8pixels: 2x275ns + 2x475ns: 1500ns
Time it takes the VDP to draw 8 pixels: 64 x 25ns (gives off ~10MHz clock): 1500ns

You are right on time with H32 and impossible memories and an impossible VDP running at 40MHz... without 68k accesses slots or refreshes. Don't even try it on H40...
As I stated before regular dram can't be used with it. Not unless you parallelize shit.

With those constraints, it would be impossible with 80 ns DRAM too, or PSRAM even, so the 100/120 ns DRAM context is irrelevant.

Those single consecutive byte cases really kill the 16-bit wide DRAM thing in particular, let alone FPM accesses.
Doing 2 separate 8-bit banks/busses using DRAM would make more sense in that context (of the VDP bus being 16-bits wide rather than 8-bit) . . . though then you're kind of just simulating VRAM; still might have been cheaper though. (shouldn't be much impact on VDP pin count either, sicne you need the same 16 data lines and rather few added address lines given the multiplexed nature of DRAM) Except, unlike VRAM, you don't have as flexible use of memory as one shared chunk, and any operations that actually need the bandwidth/speed of using both VRAM buses simultaneously for the same block of data would fail too. (unless you mirrored all data in both banks, so wasting 1/2 the RAM space . . . so not really worth it)

So yeah, not really practical, at least for the way the MD VDP works. (a totally hypothetical design more specifically designed around the peculiarities of DRAM is another matter though :p)
And, again VRAM should still have been a significantly cheaper alternative to SRAM.



On a separate note though, there's got to be more to DRAM control logic than that . . . I tried sorting out how you could get close to technical peak speeds of such old DRAMs with practical clock rates of the time, but much of it came down to needing a really high clock rate. The thing is, the Atari ST and Amiga managed 250 ns and ~280 ns random access cycle times on 120/150 ns DRAM using 8/7.16 MHz chipsets in 1985. (iirc early ST models "cheated" and made do with 150 ns in some cases, going well out of spec though) The Atari Lynx's Suzy was managing 250 ns random access cycle times and 125 ns page-mode cycle times in 1989.
That-is unless the DRAM controllers in those are actually running much faster than that.

And if you want to go for imaginary/non-yet-existent memories and higher clock speeds, the Jaguar used (at the time low-end) 80 ns FPM DRAM and a 26.599 MHz clock with 5-cycle (187.9 ns) random read/write cycle times and 2-cycle (75.2 ns) page mode cycle times.




Edit: also with the "random access and consecutive bytes" is referring to the random access (implcit) followed by X number of consecutive bytes, right?

Ie: for name table reads "random access with 1 consecutive byte" refers to a 16-bit word access? (I assume so since name table data is 16-bits wide)



Hmm, wait . . . with 16 cycles, assuming a 2x pixel clock VDP rate (10.74 MHz, 93.1 ns in H32) being the constraint for 8 pixels (5.37 MHz dot clock, 8 clock ticks, 1.4897 ns), and considering the sort of timing seen on the Atari Lynx using 120 ns FPM DRAM, this still seems like it would actually work in real-world contexts. Being conservative, you'd have 3 cycles (279 ns -identical to Amiga DRAM cycle time) for each 16-bit name table read, then 3+2 cycles for the tile data read, so 3+3+3+2+3+2= 16 cycles total. For H40, with the same 16 cycles (but at 13.42 MHz), that doesn't seem totally out of the question still either, with page-mode cycle times being slower than the Lynx's 125 ns (at ~149 ns), but random read cycle times would need ~223 ns rather than the 250 ns of the Lynx (or ST).

I'll let you two fight out whether an FPM DRAM setup could be made to work, but I would like to clarify that the Genesis VDP never does what's Jorge describes as a "Type 1" read. It always reads 4 consecutive bytes (except for external reads, but those take 4 cycles to read a single byte anyway). This means that it reads 2 name table entries at a time which is why vertical scroll is limited to 2 column resolution. It seems likely to me that VRAM was simply the cheapest way to get the bandwidth they needed. They don't really take advantage of the dual port nature of the RAM so price/bandwidth seems to be the only reason to use it (well apart from supply/time to market constraints I suppose).

I could almost be certain that the SAM port is used for tile reading, but it's been a while since I poked on the bus

Quote:

---

Originally Posted by Jorge Nuno

I could almost be certain that the SAM port is used for tile reading, but it's been a while since I poked on the bus

---

The SAM port is basically all it uses. The only thing the PAM port is used for is external access (i.e. 68K reads/writes and DMA writes) and that is never done in parallel with use of the SAM port. It actually can't use both at the same time because it never reads more than 4 sequential bytes so the address lines are always busy setting up the next SAM read.

Quote:

---

Originally Posted by Mask of Destiny

I'll let you two fight out whether an FPM DRAM setup could be made to work, but I would like to clarify that the Genesis VDP never does what's Jorge describes as a "Type 1" read. It always reads 4 consecutive bytes (except for external reads, but those take 4 cycles to read a single byte anyway). This means that it reads 2 name table entries at a time which is why vertical scroll is limited to 2 column resolution. It seems likely to me that VRAM was simply the cheapest way to get the bandwidth they needed. They don't really take advantage of the dual port nature of the RAM so price/bandwidth seems to be the only reason to use it (well apart from supply/time to market constraints I suppose).

---

OK, then it's more like I was first thinking . . . aside from the more specific problems with actual DRAM controller cycle times and DRAM control signal timign requirements. (which is something I know a little about, but it's kind of unclear . . . namely the above issue of how the likes of the ST/Amiga/Lynx seemingly get away with the timign they do with the DRAM thy used without higher clocked DRAM controllers -unless the DRAM controllers ARE clocked higher than the 7.16/8 MHz system clocks, like dobule that at least . . . Lynx uses a 16 MHz system clock iirc, but all the programmable logic in Suzy seems to be 8 MHz with 125 ns cycle times)

But yeah, the serial access speed of VRAM is pretty nice. Pretty nice general comparison with a datasheet showing a bunch of VRAM, DRAM, and PSRAM chips alongside eachother: http://www.datasheetarchive.com/dlma...A852000-30.pdf (including the TC51832SPL-10/-12 used in some MDs)
Albeit the MD VDP doesn't make particularly heavy use of the potential 30/40 ns serial read/write cycle time. Actually, that kind of makes the way the 3DO does rendering make less sense. (like Saturn VDP1, it does linear pixel reads and nonlinear writes -for rotated/warped quads- so you wouldn't get a good benefit from the high bandwidth serial port . . . that and the Cel isn't fast enough to really take advantage of that speed either . . . still good for scanning and cleaing the framebuffer though, but seems like kind of a waste)
Tthat performance would work really well for flat shaded 3D (high speed line filling), and it probably fits particularly well with the way Atari Games used the TMS34010 in the Hard Drivin' arcade boards. ;) (granted, any sort of 3D with emphasis on linear rendering like that -ie typical 3D rasterizers- would work well with VRAM -PSX, Jaguar, etc)

Hmm, given the way the MD uses VRAM, the SNES and PCE VDPs wouldn't be that far off from having similar advantages in using that. They're bitplane based, but given the tiles are 8-pixels wide (8 bits per plane), you'd still do byte width squential accesses anyway. ;) (actually, given the 16-bit wide SRAMs actually used -iirc- that would imply they're reading pairs of 8-bit wide bitplane chunks at once anyway -which would also explain the packed-planar tile format used)

And, also to clarify, when you say "cycles," you mean VDP cycles as in 10.74 or 13.42 MHz, right?

Just because the cycle time is 1/8MHz or whatever, sometimes the flipflops that make the state machines are clocked on the opposing clock edge, so effectively it's about the same as if the logic worked at 2x speed.

For example consider a simple statemachine that is as follows: (stamemachines run one state per cycle)

state0: (idle state)
RAS = 1;
CAS = 1;
if new memory_access goto state1, else goto state0

state1:
RAS = 0;
CAS = 1;

state2:
RAS = 0;
CAS = 0;
goto state0

All this machine does is cycling RAS and CAS signals (excluding refresh and paged mode, just accesses dram with only random accesses) now you may see or not that it's missing 2 important things:

No signal for address multiplexing, can't use RAS, because the row address need to be stable when it's strobed, can't use CAS because the column address needs to be stable when it's strobed.. however we can take RAS signal and run it through a flipflop clocked on the OTHER edge as the state machine, effectively making a half-clock delay line.

No signal for data capturing, can't use CAS because it's too early, can't use negated CAS because databus will be tristated shortly after.. but as above we can use a half-clock delayed CAS to latch the memory data.


This isn't usually needed when the clock for the memory manager is 2 or 4 times higher, but doing it doesn't hurt anything either as long as setup/hold times and period are respected.

Running the statemachine at 2x clock would give and making the same latency between signals:

state0: (idle state)
RAS = 1;
MUX = 0;
CAS = 1;
DReady = 0;
if new memory_access goto state1, else goto state0

state1:
RAS = 0;
MUX = 0;
CAS = 1;
DReady = 0;

state1.5:
RAS = 0;
MUX = 1;
CAS = 1;
DReady = 0;

state2:
RAS = 0;
MUX = 1;
CAS = 0;
DReady = 0;

state2.5:
RAS = 0;
MUX = 1;
CAS = 0;
DReady = 1;
goto state0

As you can see, the statemachine is about twice as bigger, wasting more area and power. However it does respond faster to the processor memory access, the delay between signal memory_access to RAS low is half of the original state machine.

Quote:

---

Originally Posted by kool kitty89

And, also to clarify, when you say "cycles," you mean VDP cycles as in 10.74 or 13.42 MHz, right?

---

Yes. The VDP feeds SC (serial port clock) with MCLK/5 for H32 and mostly MCLK/4 for H40 (though it switches back and forth during hsync to get the pulse timing correct or something like that). Pretty much everything the VDP does seems to be driven off that same clock signal.

Thanks for the clarification, this is really interesting stuff.

It also seems like the clock rates in the ST, Amiga, and Lynx also ended up being more convenient for matching DRAM timing parameters too. (pulses of "just right" length for a lot of that, rather than bing just short and needing another cycle to reach the parameters, thus going over what a slower clock might have done faster ;))
8/16 MHz is also perfect for much of the timing used for typical 120 ns DRAM too. (and 7.16 MHz fits really well with 150 ns)

On some systems the DRAM controller timings were not entirely syncronized with a clock pulse. Expected propagation delays or other fixed delays were incorporated into the design. The Commodore A2630 (68030) CPU board was supposedly like this, hence it's limited overclocking ability even with faster RAMs installed. I've also heard about someone having problems with fast DRAM chips in an 8-bit Atari, because they could respond to an extraneous signal that was never meant to be acted on and was safely ignored by the old slow chips. In a similar vein, the DTACK-GROUNDED boards relied on the 68K CPU outputting the address earlier than what the spec said.

Quote:

---

Originally Posted by bakemono

On some systems the DRAM controller timings were not entirely syncronized with a clock pulse. Expected propagation delays or other fixed delays were incorporated into the design. The Commodore A2630 (68030) CPU board was supposedly like this, hence it's limited overclocking ability even with faster RAMs installed. I've also heard about someone having problems with fast DRAM chips in an 8-bit Atari, because they could respond to an extraneous signal that was never meant to be acted on and was safely ignored by the old slow chips. In a similar vein, the DTACK-GROUNDED boards relied on the 68K CPU outputting the address earlier than what the spec said.

---

Hmm, like the 150 and 120 ns DRAMs used in some of the 65XE and 130XE computers? (the 130XE I have uses 150 ns chips)

The problem is not just the memory.