Comparison of 4th generation ("8/16-bit") system hardware

[Kamahl]

Until you realize other sprites are most likely using that palette too =P (and until you realize you hit the limit of the map and the player starts going up and eventually overlaps with the HUD)

Well you'd have to design the game around it . You could just make the hud cover the entire bottom of the screen (or top), and then there's no problem.

[Sik]

Yuu Yuu Hakusho Gaiden already does that then.

[Kamahl]

Yuu Yuu Hakusho Gaiden already does that then.

Why? There's really nothing in the bottom hud that needs more colors.

[Sik]

¯\(°_o)/¯

Dunno why they did that, but they did (maybe the backgrounds eat up more colors than we think?). It becomes blatantly obvious in Genecyst, which can only show one set of palettes (either what's above or what's below, depending if you have raster effects enabled or not).

[Kamahl]

Hahaha, that's just awesome. The bottom screen has 3 colors + the main character sprite colors. It's the perfect example of NOT needing extra colors and yet it's the one game that does.

[tomaitheous]

For the MD it's exactly the same situation as for the PCE, the color output is affected only where the writes happen. If all the writes happen during hblank then you wouldn't see the garbage (it'd be off-screen). The only difference is that the MD would display the color being written, while the PCE would display the last color that has been shown (also for the MD it isn't that bad, it's just tiny dots on screen).

The SNES is worse, it outright garbages the display.

If you're trying to do transparency effects or such, then the color window is what you use on the SNES (a special defined are for color math).

Yeah, the PCE and the MD are similar in that if you do all the updates in hblank, then you're ok. The MD artifacts show up as dots while the PCE artifacts show up as horizontal strip artifacts. The MD dot artifacts are also delayed while the PCE artifacts are not (from a relative viewpoint. I think there's a 8 pixel difference between what the VDC outputs and what the VCE outputs). The VDC is like the VDP of the Genesis, on the PCE. It's connected to the VCE via a digital pixel data bus (9bit). The cpu has priority over the pixel data bus, which is why the VCE won't/can't read from the pixel bus when the cpu is accessing any VCE register (color or not. Reading or writing). In the artifacting demo, I don't even update colors for the artifacts (except for the green color). I just do a useless reg update to cause the distortion. The cpu write will hold the address line active of the VCE (on the bus) for a number of cycles, not just the single write cycle. This is why is shows up as small lines (about ~5 wide). The Txx dma instructions hold the destination address for the entire transfer, so you'll get a solid line for the whole thing (I have a demo somewhere where I use it to make pseudo laser sprites).

As far as how much you can transfer before you see artifacts in hblank, I think probably about 7 colors (7th color would most likely be fringing on the left edge. But that's usually hidden in horizontal overscan). Figuring low res mode, 341 pixels per scanline. 256 pixels are active (the normal default setting, can be set to more or less if so desired). 256/341=0.75. 455 cycles * 0.75 = 341. 455 - 341 = 114 cycles for hblank. Hint is triggered when HDW ends (last pixel of active display width). So it's actually triggered on the scanline before the one you set it to. 114/14 = ~8. The interrupt call is 8 cycles and Txx doesn't need a push of the Acc reg. So that's with tight and optimal written routine. Sloppy routine would probably net something closer to 3-4 colors.

Out of those 256 tiles, only 32 are actually needed, the rest can be replaced with 8 palettes that do the permutations of colors necessary for them. (the number of palettes/tiles can be changed as needed)

That would slow down on the renderer though. 256 tiles isn't a big dent in vram by any stretch.

8x8 tiles. Each tile, first row, would be two sets of 4 pixels. Each 4 pixels would be a single 'pixel'. So a tile would hold 2 pixels. The color of the pixels would be 0-15 or 2^4. 2^4 * 2^4 = 256 different combinations. A single byte to a tilemap LSB would write 2 pixels. The PCE map size can max out at 128x64. To get a 128 pixel wide mode (double low res horizontal), use the 512 pixel display mode. That needs a map width of 64. With an hint routine, you can redivide the map into 64x128. 64x56 size (128x56 pixel map) would allow for double buffering and still have enough room left over for the top part of the map for a far BG graphic (16 lines of the map left is 128 pixels tall in normal mode. 64x56 & 64x56 = 64x112, 128-112=16, 16*8=128 pixels tall). And of course the 56 scanlines would be scaled to something like 112 or 128 (preferably non linear to get that perspective just right) via the hint routine.

Having 256 tiles with only the for row of 8 pixels used, seems kind of wasteful. But you could actually precalculate hues and/or luma into the other 7 rows of those tiles. And use that for a fading effect per scanline, since you have to write the MSB of the tilemap part to the VDC port anyway (this could be made fast and simple). You could also assign subpalettes to those tiles for even more coloring effects, but I can't think of any real good use to this. Also since the map is divided up and setup linearly, it would be as simple as doing a linear bitmap transfer (sequential writes wrap to the next scanline).

BTW, the Pier Solar mode 7 area doesn't run 30fps (or at least from what I saw). Looks like about 10-12fps. And I don't see any way for the PCE cpu to rotate a bitmap and update vram all in a single frame. Even with crazy ass precalculated code. The time it takes to write that many bytes to vram itself wouldn't fit in a single frame even if you used a straight up lda abs,x sta port unrolled loop. 128x56=7168 entries. But that's WORDs, so 14336 bytes. 14336x11cycles = 157696cycles. A single frame is only 119436 cycles. The only way to update faster and fit in a single frame, is to use Txx or embedded opcodes (ST1/ST2). Txx is 7 cycles a byte (for VDC port, else 6 cycles a byte) and ST1/ST2 is 5 cycles a byte to VDC port (store immediate port 1/2). But that's copying from ram (buffer) to VDC port. With ST1/2, game logic and frame update could be on the same frame. I suspect even doing an optimized bresenham algorithm fetch for the rotation (and plenty of precalc'd code) on a small 128x56 bitmap is going to run you at least a few frames. And that assumes the 4bit pixels are stored as bytes. But then again, this isn't particularly my area of expertise.

[Kamahl]

That would slow down on the renderer though. 256 tiles isn't a big dent in vram by any stretch.

True. Takes around 12,5% of vram.

8x8 tiles. Each tile, first row, would be two sets of 4 pixels. Each 4 pixels would be a single 'pixel'. So a tile would hold 2 pixels. The color of the pixels would be 0-15 or 2^4. 2^4 * 2^4 = 256 different combinations. A single byte to a tilemap LSB would write 2 pixels. The PCE map size can max out at 128x64. To get a 128 pixel wide mode (double low res horizontal), use the 512 pixel display mode. That needs a map width of 64. With an hint routine, you can redivide the map into 64x128. 64x56 size (128x56 pixel map) would allow for double buffering and still have enough room left over for the top part of the map for a far BG graphic (16 lines of the map left is 128 pixels tall in normal mode. 64x56 & 64x56 = 64x112, 128-112=16, 16*8=128 pixels tall). And of course the 56 scanlines would be scaled to something like 112 or 128 (preferably non linear to get that perspective just right) via the hint routine.

Pretty much the idea yes.

Having 256 tiles with only the for row of 8 pixels used, seems kind of wasteful. But you could actually precalculate hues and/or luma into the other 7 rows of those tiles. And use that for a fading effect per scanline, since you have to write the MSB of the tilemap part to the VDC port anyway (this could be made fast and simple). You could also assign subpalettes to those tiles for even more coloring effects, but I can't think of any real good use to this. Also since the map is divided up and setup linearly, it would be as simple as doing a linear bitmap transfer (sequential writes wrap to the next scanline).

You're a little over my head here . But a fading effect would look really cool. I thought of it but my idea (with 256 tiles) was to simply store the colors in the remaining palettes and switch as needed.

BTW, the Pier Solar mode 7 area doesn't run 30fps (or at least from what I saw). Looks like about 10-12fps. And I don't see any way for the PCE cpu to rotate a bitmap and update vram all in a single frame. Even with crazy ass precalculated code. The time it takes to write that many bytes to vram itself wouldn't fit in a single frame even if you used a straight up lda abs,x sta port unrolled loop. 128x56=7168 entries. But that's WORDs, so 14336 bytes. 14336x11cycles = 157696cycles. A single frame is only 119436 cycles. The only way to update faster and fit in a single frame, is to use Txx or embedded opcodes (ST1/ST2). Txx is 7 cycles a byte (for VDC port, else 6 cycles a byte) and ST1/ST2 is 5 cycles a byte to VDC port (store immediate port 1/2). But that's copying from ram (buffer) to VDC port. With ST1/2, game logic and frame update could be on the same frame. I suspect even doing an optimized bresenham algorithm fetch for the rotation (and plenty of precalc'd code) on a small 128x56 bitmap is going to run you at least a few frames. And that assumes the 4bit pixels are stored as bytes. But then again, this isn't particularly my area of expertise.

With the extra ram of the CD system you can store a 128x56x8 bitmap without problems, that should help optimize things a lot. Would 15 fps be possible then?
Also what about a mode-7 effect that only scales (in perspective)? That should be possible no?

[kool kitty89]

The SMS can, that's why the HUD in the 8-bit Sonic games sometimes disappears behind the scenery. On the downside, sprites don't have priority (the NES is the opposite, sprites have priority but the tilemap doesn't)

If there's no priority control for sprites on the SMS, what determines the order in which sprites are drawn when they overlap?

Welcome back. Trolled you there for a while .
Speaking of the CD-i, I wonder how good the hardware on that thing is. Audio is SNES quality (8 channel ADPCM), it has 1mb of ram which isn't bad, and the processor isn't bad either. I can't find any information on the VDP other than the amount of colors onscreen and resolution. No idea if it's any good.

This was brought up before, see: http://www.sega-16.com/forum/showthr...773#post390773

I'm not sure of the speed possible, but it does have hardware blitter functionality and does use chunky pixels (4 or 8-bit), so it would probably be better at 3D than any of the systems in question. (except maybe the Sega CD or 16 MHz x68000)

Honestly i still don't see how to handle all that efficiently. As soon you have variable pitch you have to potentially adjust bank register at any time (and so lost ~90 cycles in you loop)... I guess the final output rate cannot be higher than 11 / 12 Khz with 3 channels in this case, and even 11/12 Khz would be difficult to obtain.

Why would you need to change banks at any time rather than regular intervals? Couldn't you maintain a constant sample (and data) rate for every sample in ROM, but then scale the samples (and vary loop times for looping samples) after they've been buffered into Z80 RAM?

If you did want to mix samples that actually used different data rates, but didn't care about note quality pitch control, perhaps limiting sample/data rates of samples to regular steps (like 4, 8, 16, kHz, etc) and interleaving the samples and using simple integer scaling to match the output rate.

I did some tests with PSG to do fast 3 ch mixing for really the quality wasn't that good, not really surprising as we have only 16 volume level and in a log manner.
It didn't sound too bad for AF2 because we expect voices to be somewhat distorted in this environment but in another context really the quality is not good enough to work with. For acceptable quality you have to uses DAC.
I though about another way : uses FM channel as DAC by setting very high frequency and playing with 7 bits TL (log) volume, i never tested it but i'm not sure it would really work.

Can you at least get better quality than 4-bit PCM? (or if the added step sizes facilitated it, it might be more efficient -in terms of bitrate and SNR- to use a rudimentary 4-bit ulaw like scheme to map 4-bit samples into the 3xPSG channel amplitude range, or just a 4-bit per sample format mapped to PSG values as close to linear as possible -but then you'd definitely get no better than 4-bit PCM quality)

Given what Tiido mentioned about the YM2612 volume modulation route, PSG is probably a better option if anything.

Yeah, only one channel with variable pitch is a bit limitating for MOD player Anyway maybe we can't do more on Z80.

The idea would be several channels (ie 2 or 3) with fixed pitch playback (for SFX, percussion, etc) and 1 channel for playing notes with a sampled instrument. (obviously something that can't be produced with 4-op FM adequately)

Doing just 1 channel at all (with no mixing) is a lot simpler to do notes with since you can just vary the sample rate and loop times without scaling. (as such, Chilly Willy's CVSD player could easily be configured for playing at variable rates up to 24 kHz)

See it as DPCM as i'm using a fixed delta table, though as i'm using high playback rate (22 khz) the delta table is adjusted to take that in account and the resulting quality is pretty good compared to original sample.

Ah, so it's a bit like the format used in SMPS (but presumably with a different delta table more optimized for the high sample rate on top of the 8-bit range limit -or possibly limited to 7-bit output to better optimize for adding 2 channels to 8-bits).


On the issue of SMPS, does anyone know what the maximum supported sample rate was for PCM and 4-bit DPCM? (or for GEMS . . . or any info on EA's engine for that matter)

[Sik]

If there's no priority control for sprites on the SMS, what determines the order in which sprites are drawn when they overlap?

Their order in the sprite list.

[tomaitheous]

You're a little over my head here . But a fading effect would look really cool. I thought of it but my idea (with 256 tiles) was to simply store the colors in the remaining palettes and switch as needed.

Which part did you have trouble with? I also didn't describe the precalc'd hue/luma thing fully. A line of every tilemap would only point to row 0 of every tile associated on that tilemap line. So when you go to do you Hint routine, you basically set the Y position of the tilemap every 8 pixels to get the alignment right. But what I was mentioning was, is that you could use the lower 3 bits of the Y offset to select which row of pixels every tile on that whole scanline is referencing. Thus you could make gradients going in both directions. You could also assign different subpalettes for horiztonal effects via color changes but the resolution in steps would be little bit coarse (equiv to 2 pixels in 128 double wide mode).

If there's no priority control for sprites on the SMS, what determines the order in which sprites are drawn when they overlap?

The order they appear in the sprite table. I'm glad the PCE doesn't have the SMS mode (assuming I could only choose one mode).

With the extra ram of the CD system you can store a 128x56x8 bitmap without problems, that should help optimize things a lot. Would 15 fps be possible then?
Also what about a mode-7 effect that only scales (in perspective)? That should be possible no?

I could write it and find out, but I'd feel more comfortable picking the brain of coders that tweak these kind of routines in their sleep (rotation, 3D, on limited systems, specifically 65x would help, etc) Yeah, just doing the scaling perspective isn't much of a problem, but where's the fun in that? I've already done it via Hint Y scale routine demos before. Doing a X scale on top of that wouldn't be hard.

Speaking of scaling: http://www.pcedev.net/demos/scaling/title_scale_3.zip <- nothing is optimized (the scaling routine) and the chunky to planar converter is sloooow. But it was fun to write.

[Black_Tiger]

Speaking of scaling: http://www.pcedev.net/demos/scaling/title_scale_3.zip <- nothing is optimized (the scaling routine) and the chunky to planar converter is sloooow. But it was fun to write.

Holy crap! Is that really "on the fly" scaling?

[tomaitheous]

Holy crap! Is that really "on the fly" scaling?

Yeah, but it's not optimized to show off anything. I just wrote the core scaling code to tweak/work with that specific title screen sequence part. I had planned on going back and optimizing it for a smoother frame rate in the scaling part.

[TmEE]

The order they appear in the sprite table. I'm glad the PCE doesn't have the SMS mode (assuming I could only choose one mode).

What's so bad with that ? Or what alternative would be better (besides linked lists like MD has) ?

Regarding palette updates, you can do 3 updates in HBL on MD with artifacts not being on active scan. When you disable VDP in HBL you could update most of the 64 colors at cost of no sprites

[Sik]

When you disable VDP in HBL you could update most of the 64 colors at cost of no sprites

So hblank lasts over 30.77% of a scanline? =S

EDIT: wait, nevermind, not all 64 colors... but still doesn't make much sense. Assuming H40 mode (since H32 is slower), you can fill CRAM 3 times in a single scanline (3.25 to be more exact). I really doubt hblank is near 1/3 of a scanline.

[TmEE]

There is 420 pixels on a scanline in total, 390 pixels in 40H res, and 30 in 32H res(wider). HBL forms a good chunk of the active line.