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

[Kamahl]

Well, remember I do know of a trick that lets you work with a pseudo-linear bitmap in RAM that can be loaded into VRAM directly without converting it to tiles (it involves autoincrement abuse). It can also be used to double the pixels vertically without raster effects and without doubling the required transfer bandwidth (although in that case both tilemaps get used).

EDIT: more facts, to transfer an entire 256×192 image to VRAM with that method I'd need two frames in NTSC. In PAL I'd only need one, which can lead to some interesting results for demoscene...

Demo or GTFO

[Sik]

lolno, too busy doing other stuff =P Though I can give the details later if anybody is interested. It'll require somebody that understands how to program the VDP to get how it works though, or otherwise you'll end up with baseless speculation...

Also from #projectmd:

<Soojiin> http://emuconsoleexploitnews.blogspo...pc-engine.html

That definitely wouldn't have been possible without amazing technology not available 20 years ago and let's not forget about the BIOS! *shot*

[Kamahl]

Come to think of it... is there even a SNES demo/homebrew scene?

[sheath]

Except because then you'll have to pause the game to do any PCM playback =/ (remember the 68000 only gets interrupts from the VDP)


Yes, but it wouldn't have hidden all the issues with timer inaccuracy anyways (the timers don't loop, so by definition they need to be restarted each time and the inaccuracy adds up). Drivers using the Z80 only for PCM just use busy loops...

The quotes attributed to me should be from somebody else. I'm not smart enough to talk about interrupts and other assembly technobabble.

That X68000 game looks freaking amazing! Here's hoping X68000 emulation improves in functionality, I will never own an actual unit. The grace extended to me by my wife for collecting is stretched to its limit with fifteen consoles and an 8ft tall 3.5ft wide book shelf full of games.

Back on topic though, I do think the Z80 was a good addition to the Genesis, just an under utilized one. I think there is a valid argument out there that if the Genesis hadn't had backward compatibility with the SMS there might have at least been resources spent better on more color RAM and the VDP might have been taken an entirely different direction. All the same, whoever said that a YM2612 plus PSG = soundgasm was 100% correct.

[TmEE]

Come to think of it... is there even a SNES demo/homebrew scene?

Some people try to make something but are not getting anywhere...

[sheath]

Yet the only way to get any PCM playback on the MD... (stupid Sega for thinking that the DAC on the YM2612 was enough)


I should make you listen to more bad FM music then. May want to target Activision and Ubisoft too.

Well, EA is personally responsible for bad FM music on the Genesis, Activision and Ubisoft as we know them today were only sparks in EA and Sony's loins at the time. Akklaim already got theirs through economic warfare or I would have named them too. And again, I know the Z80 came in handy for sound engines at the very least, I was just playing with the topic.

[Sik]

Come to think of it... is there even a SNES demo/homebrew scene?

I'm still waiting for Project SNES. That literally went nowhere...

Well, EA is personally responsible for bad FM music on the Genesis, Activision and Ubisoft as we know them today were only sparks in EA and Sony's loins at the time. Akklaim already got theirs through economic warfare or I would have named them too. And again, I know the Z80 came in handy for sound engines at the very least, I was just playing with the topic.

I just wanted to murder their current shareholders =|

[Kamahl]

I'm still waiting for Project SNES. That literally went nowhere...


I just wanted to murder their current shareholders =|

Activision + Blizzard merge = Worst think to ever happen. I WANT MY LAN MULTIPLAYER BACK ACTIVISION!

On topic: Is there any way to get nice platforming action on the PCE with parallax scrolling? Like I said before it seems to be the only genre that gets really hurt from the lack of a second layer.

And how the heck are these games possible:



Most games for the PC98 run at 10fps or something.

[kool kitty89]

Except because then you'll have to pause the game to do any PCM playback =/ (remember the 68000 only gets interrupts from the VDP)

That should only be an issue for games using unrestricted V-DMA. If a game avoided VRAM updates mid-game in general or (more realistically) if DMA was interleaved on an every other scanline basis (or similarly regular intervals) with the hblank interrupts slow enough to reasonably fit within the remaining gaps, it should have been possible. (I'm pretty sure this has come up before)
Using the hblank timer, you could get 3.92 kHz, so very close to the common 4 kHz used in MD games (and ST games), though you could obviously opt for other speeds as well. (within practical limits of CPU time)

Of course, if they did remove the Z80, it would have made plenty of sense to implement a simple DMA sound channel for PCM playback (which should have been much cheaper than the Z80 itself).

Yes, but it wouldn't have hidden all the issues with timer inaccuracy anyways (the timers don't loop, so by definition they need to be restarted each time and the inaccuracy adds up). Drivers using the Z80 only for PCM just use busy loops...

Yet somehow even several 68k based sound engines (with Z80 providing only PCM) still managed to have screwed up timing (Capcom's SFII driver being one of the most obvious examples).

Well, remember I do know of a trick that lets you work with a pseudo-linear bitmap in RAM that can be loaded into VRAM directly without converting it to tiles (it involves autoincrement abuse). It can also be used to double the pixels vertically without raster effects and without doubling the required transfer bandwidth (although in that case both tilemaps get used).

EDIT: more facts, to transfer an entire 256×192 image to VRAM with that method I'd need two frames in NTSC. In PAL I'd only need one, which can lead to some interesting results for demoscene...

Wow, that's really neat. Would that 256x192 window be with use of line doubling (effective 256x96 resolution or 128x96 if using doubled or paired pixels for pseudo 8bpp) or a full 256x192 screen? (I'd guess the former given the DMA constraints, and that this is for H32 since H40 would be able to do 256x192 in 1 NTSC frame, or 288x192 even -assuming you've clipped the screen to 192 lines)

With the 2 tilemaps used, are the tiles interleaved every scanline? (if that's the case, you could potentially use 2 different palettes with colors dithered vertically on a scanline basis -uglier in NTSC, but a great exploit for PAL's vertical chroma blending as has been used on the Atari 8-bit for the pseudo 80x96 256 color bitmap mode)

That recording of Geograph Seal is very likely running on a 16Mhz X68000, it's too fast. Although the game is playable on a standard 10Mhz one.

Perhaps playable, but I highly doubt it's very smooth. (and playable is relative -I consider Hard Drivin' and F-22 playable on the Genesis)

That looks much too fast to be just a 16 MHz 68k system. (maybe an emulator or '030 based system)

Back on topic though, I do think the Z80 was a good addition to the Genesis, just an under utilized one. I think there is a valid argument out there that if the Genesis hadn't had backward compatibility with the SMS there might have at least been resources spent better on more color RAM and the VDP might have been taken an entirely different direction. All the same, whoever said that a YM2612 plus PSG = soundgasm was 100% correct.

Yes and no. The problems are that it was rather wasteful and hack-ish in implementation (some changes -like a faster Z80 clock mode and decent bank switching- could have made it far more valuable in the system) as well as the alternate possibilities if that same (or less) cost was put into other hardware (like a simple DMA sound circuit like in the Mac, or even better with something more like the Amiga -multiple channels with hardware mixing, high res variable sample rate suitable for notes, hardware looping, etc).
Albeit similar can be argued over the SMS compatible block of the VDP eating up valuable silicon which could have been put towards higher res color DACs and more CRAM. (like 8 palettes from 12-bit RGB -though the opposite argument there would have been to efficiently build onto the SMS architecture rather than an all new VDP with tacked-on compatibility)

Well, EA is personally responsible for bad FM music on the Genesis, Activision and Ubisoft as we know them today were only sparks in EA and Sony's loins at the time. Akklaim already got theirs through economic warfare or I would have named them too. And again, I know the Z80 came in handy for sound engines at the very least, I was just playing with the topic.

This already came up in my PC music thread, but this isn't really a fault of EA specifically, but more the North American video game industry on the whole (from arcade to computers to consoles) where the vast majority of composers were unfamiliar with the techniques being implemented fairly commonly in Japan and Europe for electronic music (especially for FM -lacking things like reverb effects among other things) with a few exceptions. (Wacky Racers is one of the best examples on PC -though it still lacked PCM in the music as many DOS games oddly tended to)

EA's sound engine itself may actually be pretty good (the PCM driver definitely seems above average -I wonder if any compressed formats are supported) and a few examples from really capable composers for FM. (there were a lot of other capable composers who did well with other formats -be it the MT-32, various sample based cards or the Amiga, Ensoniq synths, or even older sound chips like the SID, but for some reason had problems making good use of Yamaha FM chips -perhaps in part due to the available tracker software or midi drivers)

[Sik]

That should only be an issue for games using unrestricted V-DMA. If a game avoided VRAM updates mid-game in general or (more realistically) if DMA was interleaved on an every other scanline basis (or similarly regular intervals) with the hblank interrupts slow enough to reasonably fit within the remaining gaps, it should have been possible. (I'm pretty sure this has come up before)
Using the hblank timer, you could get 3.92 kHz, so very close to the common 4 kHz used in MD games (and ST games), though you could obviously opt for other speeds as well. (within practical limits of CPU time)

The hblank interrupt doesn't trigger during vblank =P (also interrupting the 68000 like that, and to access a pretty slow piece of hardware, is asking for massive slow down in the game)

Yet somehow even several 68k based sound engines (with Z80 providing only PCM) still managed to have screwed up timing (Capcom's SFII driver being one of the most obvious examples).

Don't forget bank switching... And they may have added the samples and checked for overflow instead of using a look-up table, making things worse performance-wise. That, and general lack of Z80 expertise, the Z80 is much slower than it seems...

Wow, that's really neat. Would that 256x192 window be with use of line doubling (effective 256x96 resolution or 128x96 if using doubled or paired pixels for pseudo 8bpp) or a full 256x192 screen?

256×192 on screen, of course. Doubling them vertically isn't needed, but it reduces the amount of pixels to render with the 68000 and also reduces the amount of data to be transfered to VRAM.

The idea here basically is that two consecutive pixels in the vertical axis are guaranteed to be always at the same distance (2 bytes in this case). That can help a lot when optimizing software rendering routines, leading to a huge speed up.

(I'd guess the former given the DMA constraints, and that this is for H32 since H40 would be able to do 256x192 in 1 NTSC frame, or 288x192 even -assuming you've clipped the screen to 192 lines)

No, it still won't fit in one NTSC frame in H40, that'd require 59 lines and NTSC only has 36 li-- Wait, forgot that since we're talking about 256×192 that we can cut some lines at the top and the bottom to get extra blanking time. That gives us 68 lines total. Then yes, it'd fit in a single NTSC frame...

With the 2 tilemaps used, are the tiles interleaved every scanline?

Yes.

Take into account you don't need to have every other line transparent. You could e.g. use a different horizontal scroll value instead. This can be used to display a background with the tilemaps. Moreover, this can be exploited to do double buffering without eating up extra space in VRAM (so you store two buffers in the space of one!).

That looks much too fast to be just a 16 MHz 68k system. (maybe an emulator or '030 based system)

Well, Kawasaki Superbike Challenge on the MD does achieve similar framerates on hardware that doesn't support bitmaps. It has less polygons, but if you consider not having to convert from bitmap to tiles and the higher speed, it does seem possible for a 16 MHz 68000 to do it.

[Kamahl]

Setting the emulator to 16Mhz gives the same performance as in that video. At 10Mhz there's slowdown but the game's playable (in the same way starfox is playable).

EDIT: Also, the game is WAY better than StarFox, except for the small problem of me not being able to figure out what to do (I kill all the targets, and then the game just leaves me there, killing things), but killing enemies by jumping on them is extremely fun.

[kool kitty89]

Activision + Blizzard merge = Worst think to ever happen. I WANT MY LAN MULTIPLAYER BACK ACTIVISION!

How about the Origin+EA merger (or EA becoming a conglomerating megacorp in general)?

On topic: Is there any way to get nice platforming action on the PCE with parallax scrolling? Like I said before it seems to be the only genre that gets really hurt from the lack of a second layer.

Careful art design, tactful use of linescroll (and sprites), some use of dynamic tiles where appropriate (and within practical memory limits), and good use of color and smooth animation to push the strengths of the system. (not to mention lack of slowdown )

And how the heck are these games possible:
http://www.youtube.com/watch?v=M31t7UQv-V8
http://www.youtube.com/watch?v=rV1mOfeJi9o

Most games for the PC98 run at 10fps or something.

The PC98 was at least better of than ST and EGA PC games since it used packed pixels (unlike the PC88) and a better palette than either (more so over EGA). I think it was limited to fairly high resolutions though (sort of like the PC88) with no less than 640 pixels wide and I think 200 or 400 vertical, but that made for nice still screens and most action games seem to have used paired pixels for a pseudo 320x200 8bpp screen (with "strippy" dithering and/or double wide 16 color pixels) so effectively like rendering in 320x200 VGA. (but without the modest hardware acceleration)

How fast those games played also depended heavily on what CPU was used. (like PCs, PC98 got a continual flow of faster x86 models) If those games were recorded off fast machines or emulators, that wouldn't represent the normal range of capabilities from the time of the games releases. (unlike the PC8801 which had a very narrow range of commercially released models -4 MHz Z80, 8 MHz Z80, and 8 MHz V50 -embedded V30 derivative, and I don't think many games were made for the latter -it has a Z80/8080 emulation mode so it would run most games like the 8 MHz Z80 models would)

The hblank interrupt doesn't trigger during vblank =P (also interrupting the 68000 like that, and to access a pretty slow piece of hardware, is asking for massive slow down in the game)

OK, missed that before (I think the previous discussions were in the context of omitting the Z80 with it being implicit that added timers would be present -or using the YM timers).
As for slow hardware, would writing to the YM DAC be any worse than volume modulation on the ST's YM2149?

Don't forget bank switching... And they may have added the samples and checked for overflow instead of using a look-up table, making things worse performance-wise. That, and general lack of Z80 expertise, the Z80 is much slower than it seems...

That and vblank bus contention leading to many missed writes if not compensated for (a major issue with animation heavy games like SFII -except the samples sound just as distorted in the sound test as in-game, unlike some other examples where the sound test has even playback).

One solution to address both the contention and bank switching overhead would be to buffer chunks of samples into Z80 RAM before mixing and playback (so not switching banks to read every other sample for a multichannel player and reading samples from RAM in vblank).
The drawback there would be the added complexity of managing the buffer(s) and overhead for copying samples to SRAM (and the space used in SRAM for said buffering -and a higher minimum needed for higher sample rates to avoid shortages of samples in vblank, more so for PAL or if clipped for more vblank time).

256×192 on screen, of course. Doubling them vertically isn't needed, but it reduces the amount of pixels to render with the 68000 and also reduces the amount of data to be transfered to VRAM.

The idea here basically is that two consecutive pixels in the vertical axis are guaranteed to be always at the same distance (2 bytes in this case). That can help a lot when optimizing software rendering routines, leading to a huge speed up.

Could you also exploit this for the Sega CD's ASIC rendering (say if you wanted to halve vertical resolution without reducing screen size or wasting VRAM/DMA bandwidth with doubled pixels)?
The ASIC natively renders in cell order, so you wouldn't need (or want) the pseudo linear framebuffer aspect, but the line doubling ability would be very useful (even if sacrificing 2 tilemaps to do so).

Well, Kawasaki Superbike Challenge on the MD does achieve similar framerates on hardware that doesn't support bitmaps. It has less polygons, but if you consider not having to convert from bitmap to tiles and the higher speed, it does seem possible for a 16 MHz 68000 to do it.

Maybe if it was really optimized (and had relatively simplistic game logic), but it still seems unlikely that that video is on a 16 MHz 68k. (it's got roughly Star Fox -or Star Fox 2- level graphics . . . then again, the SFX had the added overhead of planar bitmaps and tiles -and no SFX games rendered in mode 7, so we don't even have that to compare unfortunately)

If is IS on 16 MHz 68k, that implies the MCD should have been capable of similar or better quality 3D. (better with tactful use of the ASIC -especially for texture mapped polygons- and with careful use of both 68000s -like offloading most of the game logic and AI to the MD CPU with the CD doing the 3D math and rendering)

On another note Geograph Sealactually looks a lot like Starfox's art design and color use (including the 2D backgrounds).








Edit:

Setting the emulator to 16Mhz gives the same performance as in that video. At 10Mhz there's slowdown but the game's playable (in the same way starfox is playable).

Interesting, I wonder if that's accurate to real hardware.

EDIT: Also, the game is WAY better than StarFox, except for the small problem of me not being able to figure out what to do (I kill all the targets, and then the game just leaves me there, killing things), but killing enemies by jumping on them is extremely fun.

If you find jumping Flash more fun than Star Fox, then yes . . . but I'm not sure that would be the case for meas I love Star Fox. (I'm pretty sure I'd like Geograph Seal too though, unless the controls are broken )
And then there's Star Fox 2 (very different feel, but I like it more than the first one or 64 -except for multiplayer and it handles the different game modes a lot better than SoulStar -or Star Fox assault for that matter ).

[Sik]

EDIT: Also, the game is WAY better than StarFox, except for the small problem of me not being able to figure out what to do (I kill all the targets, and then the game just leaves me there, killing things), but killing enemies by jumping on them is extremely fun.

Check the video you posted, it gives it away. Once you've destroyed all targets you need to look for the boss.

[Sik]

One solution to address both the contention and bank switching overhead would be to buffer chunks of samples into Z80 RAM before mixing and playback (so not switching banks to read every other sample for a multichannel player and reading samples from RAM in vblank).

This is pretty much the only decent way to mix samples, assuming you don't force the samples to be in the same bank (Skitchin' does sample mixing but it requires all samples to be in the same bank).

This reminds me, I need to add buffering to Echo to reduce bank switching and thereby get much more speed =P

The drawback there would be the added complexity of managing the buffer(s) and overhead for copying samples to SRAM (and the space used in SRAM for said buffering -and a higher minimum needed for higher sample rates to avoid shortages of samples in vblank, more so for PAL or if clipped for more vblank time).

Even worse, you need to predict when vblank starts to know when to buffer. Not much worth the effort.

It also depends on the sample rate. For example, at Echo's sample rate, there's a sample every about 1.5 scanlines. NTSC vblank has 36 scanlines, so that'd be 24 samples to buffer. Missing a few samples due to vblank really isn't going to be much of an issue. PAL has larger vblank, but if you don't want the game to slow down on any system you'll optimize it for NTSC's blanking time anyways, right?

Could you also exploit this for the Sega CD's ASIC rendering (say if you wanted to halve vertical resolution without reducing screen size or wasting VRAM/DMA bandwidth with doubled pixels)?
The ASIC natively renders in cell order, so you wouldn't need (or want) the pseudo linear framebuffer aspect, but the line doubling ability would be very useful (even if sacrificing 2 tilemaps to do so).

Probably not the way you're expecting. For this trick to work the bitmap 68000 side must be that, a bitmap, it can't be stored as tiles. Moreover, pixels are stored by column, not by row. And like I said, each pixel is 2 bytes away from each other - this is because DMA works on words, so you need four consecutive pixels horizontally (VDP pixels I mean). Not sure if there's a way to fool the ASIC into rendering into a suitable way.

Maybe if it was really optimized (and had relatively simplistic game logic), but it still seems unlikely that that video is on a 16 MHz 68k. (it's got roughly Star Fox -or Star Fox 2- level graphics . . . then again, the SFX had the added overhead of planar bitmaps and tiles -and no SFX games rendered in mode 7, so we don't even have that to compare unfortunately)

The SFX was also quite weak for starters =/

If is IS on 16 MHz 68k, that implies the MCD should have been capable of similar or better quality 3D. (better with tactful use of the ASIC -especially for texture mapped polygons- and with careful use of both 68000s -like offloading most of the game logic and AI to the MD CPU with the CD doing the 3D math and rendering)

Not better since the MCD 68000 is slower (12.5 MHz), but it should have been able to pull off quite some good 3D, especially using the framebuffer mode where you avoid the complexity of dealing with nibbles.

[Kamahl]

Careful art design, tactful use of linescroll (and sprites), some use of dynamic tiles where appropriate (and within practical memory limits), and good use of color and smooth animation to push the strengths of the system. (not to mention lack of slowdown )

Would be an interesting challenge, there was that Sonic game that used dynamic tiles but it ended up looking worse than just simply having a single layer.

The PC98 was at least better of than ST and EGA PC games since it used packed pixels (unlike the PC88) and a better palette than either (more so over EGA). I think it was limited to fairly high resolutions though (sort of like the PC88) with no less than 640 pixels wide and I think 200 or 400 vertical, but that made for nice still screens and most action games seem to have used paired pixels for a pseudo 320x200 8bpp screen (with "strippy" dithering and/or double wide 16 color pixels) so effectively like rendering in 320x200 VGA. (but without the modest hardware acceleration)

How fast those games played also depended heavily on what CPU was used. (like PCs, PC98 got a continual flow of faster x86 models) If those games were recorded off fast machines or emulators, that wouldn't represent the normal range of capabilities from the time of the games releases. (unlike the PC8801 which had a very narrow range of commercially released models -4 MHz Z80, 8 MHz Z80, and 8 MHz V50 -embedded V30 derivative, and I don't think many games were made for the latter -it has a Z80/8080 emulation mode so it would run most games like the 8 MHz Z80 models would)

They run like that on the standard PC-9801VM, assuming accurate emulation. And they're running full res too, at least Rude Breaker is.

Interesting, I wonder if that's accurate to real hardware.

Vys uses real hardware to record his videos, I'd say that means emulation is pretty accurate .

If you find jumping Flash more fun than Star Fox, then yes . . . but I'm not sure that would be the case for meas I love Star Fox. (I'm pretty sure I'd like Geograph Seal too though, unless the controls are broken )
And then there's Star Fox 2 (very different feel, but I like it more than the first one or 64 -except for multiplayer and it handles the different game modes a lot better than SoulStar -or Star Fox assault for that matter ).

I've actually never played Jumping Flash, this game seems to think that I should! Oh and the controls are quite clever. Just the arrow keys, Z and X. When you double jump, you automatically start looking down, no need to adjust the camera or anything. Really clever. A double tap of the X key switches weapons, while holding it fires. Oh and the FM music is SOOO good in this game, there's no point in even using midi output. The Stage 3 music barely sounds like FM, the drums are so powerful and the instruments so well chosen it might as well be PCM.

Maybe if it was really optimized (and had relatively simplistic game logic), but it still seems unlikely that that video is on a 16 MHz 68k. (it's got roughly Star Fox -or Star Fox 2- level graphics . . . then again, the SFX had the added overhead of planar bitmaps and tiles -and no SFX games rendered in mode 7, so we don't even have that to compare unfortunately)

If is IS on 16 MHz 68k, that implies the MCD should have been capable of similar or better quality 3D. (better with tactful use of the ASIC -especially for texture mapped polygons- and with careful use of both 68000s -like offloading most of the game logic and AI to the MD CPU with the CD doing the 3D math and rendering)

On another note Geograph Sealactually looks a lot like Starfox's art design and color use (including the 2D backgrounds).

Would also be an interesting demo, 3D on the Sega-CD.