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

[Stef]

To do it right, you clearly need to do something akin to Stef's four channel mixer - mixing into a buffer. Otherwise, you're stuck with the 32K limit. You're going to use more Z80 time mixing different pitches, so you won't be able to reach as high a sample rate as fixed pitch. The work comes in trying different methods to see what is powerful enough to be useful while not slowing the sample so much as to be useless. One thought is to have tables for each pitch, where the entries are what you add to the sample pointer for each sample period.
...

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.

One alternative to scaling samples for a variable rate multi-channel player would be to use more than one DAC and do simple variable rate playback (rather than scaling+mixing to a common sample rate).
The only option for that on the MD (without external hardware additions) would be using the PSG as a DAC with volume modulation (or multiple DACs using multiple channels, but quality would be pretty poor using 4-bit unsigned logarithmic PCM rather than using 2 or 3 channels to approximate higher res samples -like on the ST, but poorer due to the greater limits of the SN76489).

I don't think any games used the PSG in that manner (3 channel hack, let alone variable sample rate). The only example I know using the PSG for samples at all is AfterBurner II and that apparently only uses 4-bit logarthmic (single PSG channel) formatted samples at 3 kHz, though with 2 sample playback channels (dedicated SFX/Speech and music channels) and it sounds surprisingly good for such a poor output method and low bitrate. (12kbps)

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.

Another possibility in the case of mixing to the YM DAC alone might be limiting it to a single variable-pitch channel with additional channels being fixed rate to minimize overhead and SRAM buffer space needed. (doing a single PCM channel only would obviously be much easier in general since you could just change the playback rate to control pitch, but that's limited to 1 channel -unless you use the PSG; even so, it seems very few games even attempted to do a single channel MOD player like that)

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

What ADPCM format did you use for your player?

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.

[Black_Tiger]

I forgot to address one of the PCE's other issues with BGs: BG priority can't be handled on a per-tile basis. So, on top of having a single hardware BG layer, that layer can't have individual tiles display on top of sprites, unlike the MD and SNES. (I don't think the

Like with most other things that aren't aren't supported through hardware traditionally, there are work arounds. Many platformy PCE games like Popful Mail and Drac X place and invisible sprite with priority over other sprites just before a sprite passes across a section of tiles that it needs to disappear beheind.

The invisible tile color (#0?) priority trick can also be used to put sprites behind tiles in various ways.

[Kamahl]

So... No one knows how many colors you can update per scanline on the PCE?

[tomaitheous]

So... No one knows how many colors you can update per scanline on the PCE?

Writes are 7 cycles a byte. Color updates are two bytes. So 14 cycles per color to update. The block transfer instruction needs 17 cycles to initially setup. A give scanline is 455 cpu cycles in length. So about 29-30 colors can be updates in a scanline's length. But this will leave a solid color line across the screen where ever that update happens, because the VCE can't read from the VDC's digital pixel bus while the cpu is accessing any VCE registers; it outputs the last color it had access too (which could be border color (sprite color #0) or BG color #0 depending on where you started the transfer/delay). The dma instruction would be holding the VCE address lines for the whole transfer, making it a solid line.

I used that distortion to make this effect here:

Thought I purposely didn't use the dma instruction. I used manual cpu writes to make gaps between the artifacts.

What is this idea you had, anyway?

[Kamahl]

Writes are 7 cycles a byte. Color updates are two bytes. So 14 cycles per color to update. The block transfer instruction needs 17 cycles to initially setup. A give scanline is 455 cpu cycles in length. So about 29-30 colors can be updates in a scanline's length. But this will leave a solid color line across the screen where ever that update happens, because the VCE can't read from the VDC's digital pixel bus while the cpu is accessing any VCE registers; it outputs the last color it had access too (which could be border color (sprite color #0) or BG color #0 depending on where you started the transfer/delay). The dma instruction would be holding the VCE address lines for the whole transfer, making it a solid line.

I used that distortion to make this effect here:

Thought I purposely didn't use the dma instruction. I used manual cpu writes to make gaps between the artifacts.

What is this idea you had, anyway?

Damn that's a shame, the best I can come up with still needs 64 colors per scanline, and they can only be updated in 14 colors bursts.
If you could update 128 colors during hblank you could fake a bitmap:
Make 3 tiles tile like this:
[1][2][3][4] [5][6][7][8] [9][10][11][12]
[1][2][3][4] [5][6][7][8] [9][10][11][12]
[1][2][3][4] [5][6][7][8] [9][10][11][12]
[1][2][3][4] [5][6][7][8] [9][10][11][12]

[] represents 2 pixels, the numbers are palette entries from a single palette.

So you repeat those 3 tiles all over the screen (where you want the bitmap), every 3 tiles uses a different palette.
every 2 scanlines you replace 128 colors (if you could that is), cutting the tiles in 4 vertically. (on the scanline before, you'd prepare the instructions to replace the colors)
That effectively gives you a half res bitmap on screen.

With that, I'd be much easier to do software rendering. Just waste 1 frame doing whatever calculations are needed and store the bitmap in ram (a 128x56x4 bitmap would fit on the standard PCE ram).
On the next frame, use half of the screen to do any game related calculations, and then on the other use the "bitmap effect" to display the result of what was calculated on the frame before.
First scanline calculate the "instruction batch", second scanline update the colors. And keep doing that till everything's drawn.

The result would be a half-res, 30fps, 16 color mode-7 effect (which is just as good as the one on Pier Solar except for the lack of dithering).

If I can come up with a way that only needs 16 colors (by making some wierd tiles or something), then it works.

EDIT: Forgot about the distortion effect... damn

[evilevoix]

Come on, you all miss the PCE thread . Let's bring back the glory with even more friends. Make sure to bring plenty of fuel for the flamethrowers, no flameshields allowed.

Note that I also said "system" so home computers are valid discussion material.

List:
- Mega Drive (and SVP, and Sega CD, but not 32X)
- PC Engine (and CD addon, all system cards)
- SNES (including on-cart chips)
- Neo Geo (including Neo Geo CD)
- Amiga (OCS/ECS)
- Sharp X68000
- Atari-ST (including STE)
- PC-9801 (VM version, the one supported by nearly every game)
- Lynx
- Philips CDi ()

Ok, lets start with a Mega Drive related question.
Is it possible to set one of the background layers (like B) on the genesis as a sort of "shadow tilemap" layered on top of the other one (like A) in order to double the amount of colors on a single tile?
I'm assuming yes but the stuff I've read never made it very clear.
Would that take up too much memory? Every tile would essentially need to be doubled, leaving less room for sprites.
I'm wondering if something like this could be used to double the amount of background colors on a Top-Down RPG.

Also the PC Engine is totally an 8 bit system that could never compete with the genesis, I mean just look at the games the library speaks for itself. Compare the Legendary Axe with Alien Soldier, Alien Soldier is so much better and the PCE could never do it. Unless you have the Arcade Card because of the new bios. The system needed all those bios upgrades just to compete.

• 8 Bit indeed, the U.S. releases left a lot to be desired. I am a huge Neo Geo fanboi so I will go with that followed closely but the Sega Genesis then SNES. CD-I has to be at the bottom. Legendary Ax rules, I love that game.

Oh, and on a serious note, the PC Engine CD would have beaten the crap out of the Neo Geo if it had only gotten the super 32-bit double speed BIOS upgrade.

A part of me died the day the canceld the TG16, i really wanted it to rule the world

[Kamahl]

8 Bit indeed, the U.S. releases left a lot to be desired. I am a huge Neo Geo fanboi so I will go with that followed closely but the Sega Genesis then SNES. CD-I has to be at the bottom. Legendary Ax rules, I love that game.

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.

(And the library is obviously no indication of what it can actually do, lazy game after lazy game of SHIT)

EDIT: Ok, bitmap mode (for Mode-7) on the PC Engine:
Make 256 tiles that are split vertically in half, (similarly to the previous, only with only 2 colors), doing all possible 2 color combinations from 16 possible choices.
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)
Example:
A tile like [1|2] is equal to a tile [3|4] if there's a palette that replaces colors 1 and 2 with colors 3 and 4.

The choices are actually 15 colors, but it's easier to understand and calculate like this .

Now, have a 256 byte table in memory, each of those bytes represents a tile (or color combination).
Grab two 4bit pixels from the bitmap stored in memory (a single read). Use that read to go to the table and find the right tile/palette.
Place the tiles in order, the result is a stretched picture. 2x horizontally and 4x vertically.

To scale the image horizontally, just use 512px wide mode.
To scale the image vertically, use the scanline trick from the previous idea.

Done. Bitmap mode on the PCE. There's a problem for displaying sprites now, but this is more for "airship" type crap than a full game .

EDIT 2: Come to think of it, a bitmap in memory isn't even needed. As each resulting pixel is calculated (well, 2 pixels actually), just place the corresponding tile. Yey it's even better .

[TmEE]

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.

This I have explored and it did not result in anything useful, quality was like 4bits at best :/

[Sik]

So, the PCE also has issues while updating color RAM during active scan? Weren't we bashing the MD and the SNES for their inability to do the same without breaking the output?

[Kamahl]

Weren't we bashing the MD and the SNES for their inability to do the same without breaking the output?

Just the MD as far as I recall . The problem is that we (as in everyone) though changing even 1 color on the MD caused garbage (Jorge Nuno says this is false and I believe him). You can change 1 or 2 colors on the PCE without garbage for sure, a few games do that.

[Sik]

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.

[Kamahl]

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.

Well the PCE at the very least can change 1 color without garbage, Magical Chase does it on the first stage to fake a background layer.
And wow, another area in which the SNES sucks . Although the SNES doesn't really need it with the gradient drawing capabilities and the nice amount of palettes.

[Sik]

Well the PCE at the very least can change 1 color without garbage, Magical Chase does it on the first stage to fake a background layer.

On the MD you can change like 2-3 colors in hblank usually. Maybe you can cram in one more color with DMA, and you can change more colors by disabling display in hblank (at the expense of reducing the ability to draw sprites).

And wow, another area in which the SNES sucks . Although the SNES doesn't really need it with the gradient drawing capabilities and the nice amount of palettes.

The problem is that this happens with anything you write to video memory, not just CRAM, and the SNES definitely needs it to do linescrolling and to make window clipping even remotely useful. Also it's needed for translucency effects not involving planes (e.g. the shield in Contra 3).

[Kamahl]

On the MD you can change like 2-3 colors in hblank usually. Maybe you can cram in one more color with DMA, and you can change more colors by disabling display in hblank (at the expense of reducing the ability to draw sprites)

4 colors per scanline can be extremely useful, in just 4 lines you get an extra palette. If you have 1 palette being used for the main character sprite, you can now use an entirely different palette for anything that's displayed above or below that sprite. Good for HUDs.

The problem is that this happens with anything you write to video memory, not just CRAM, and the SNES definitely needs it to do linescrolling and to make window clipping even remotely useful. Also it's needed for translucency effects not involving planes (e.g. the shield in Contra 3).

So on the SNES everything must be done during hblank right?

[Sik]

4 colors per scanline can be extremely useful, in just 4 lines you get an extra palette. If you have 1 palette being used for the main character sprite, you can now use an entirely different palette for anything that's displayed above or below that sprite. Good for HUDs.

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)

So on the SNES everything must be done during hblank right?

Yes, pretty much. I think there are only very few exceptions to this rule.