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

[kool kitty89]

Maybe there's some kind of amazing mode mixing you can do in software which only Cliff Lawson Knows about

Really, I'm just kind of interested in whether the whole "how could they release an 8-bit system in the 16-bit era?!" is the usual exageration/missing the point of hardware, and whether whilst underpowered, it was at least better than weaker 16-bit machines.

Seems if there really was no way of increasing resolution without affecting colour count, thats a straight nail in the coffin that the system was never going to be able to beat (maybe with everything else + high resolution and a cheap price it could've survived in an uber budget niche, but with only an early 80s level resolution it wouldn't have ever had a chance)

Yes, uber budget niche and a bit desperate with the computer counterparts failing to really take-hold.

At least it was better than the C64GS . . . also released ridiculously late. (well, the sound was still worse) Odd and ironic that they didn't release an Amiga based console instead. (earlier would have been better, but 1990 still wouldn't have been bad for the Amiga hardware . . . certainly much more sensible than the C64 -and more than the CD32 in 1994 for that matter)

Too bad the flare guys ended up leaving Sinclair after the Amstrad buy-out . . . otherwise the Loki project may have ended up going actually useful game console hardware (along the lines of the Flare 1 or Slipstream) . . . granted, Amstrad certainly still could have licensed the Slipstream/Flare1 after the fact (their agreement with Konix was non-exclusive) and it would have at least made a somewhat decent semi-mainstream class "16 bit" console, though certainly not a MD or SNES killer on the performance end. (more flexible in some respects due to the blitter based architecture, and perhaps still significantly cheaper -depending on the CPU/RAM configuration used, and production volumes, and better at doing 3D/pseudo 3D out of the box -compared to software rendering on the MD or SNES- and decent color too with 256 colors from 4096 -12 bit RGB- as well as 16 color modes -blitter is faster for 256 colors, but the framebuffers and textures take 2x the space in RAM -or ROM if uncompressed)
The Slipstream was also rather dated hardware by 1990 in general . . . it was a mid/late 80s design, and for something targeting a 1990 release, the Flare engineers could have done much better. (and possibly still kept costs low compared to the competition)

But yeah, the GX4000 was not a very capable performer for the time . . . and probably not even a very good budget console either.

If the system was made super cheap and had proper developer support (plus a release a few years earlier), then it might have a chance. Released as it was it sucked.
The Amstrad CPC+ line however (the home computer) could have been great though. Another mismanaged platform.

Given the relatively limited popularity of the CPC in general, and given Amstrad's acquisition of Sinclair, it would have made far more sense to persue a backwards-compatible successor to the Spectrum. (given how simplistic the speccy hardware is, it probably wouldn't have been a big sacrifice to design around compatibility . . . and something on the level of the CoCo III's graphics capabilities along with a 6 or maybe 8 MHz Z80 would have pushed it up enough to make a good low-end ST/Amiga gaming alternative -with weaker color and CPU resource than the ST, but similar sound and hardware smooth scrolling support)

On an interesting side note, the most impressive tech demo I've ever seen is for the regular Amstrad CPC.

On the note of the CPC in general . . . it's really odd how many games used mode 1 rather than mode 0. If it used bitplanes, I could see some sense to it (drawing to 4 160x200 bitplanes could be more of a pain than 2 320x200 planes), but it uses packed pixels, so mode zero would be the fastest to render to (and you could also render things on byte boundaries -2 pixel wide blocks- to keep speed up at the expense of having lower precision scrolling/sprite movement -limited to an 80x200 grid) and obviously with much better color on top of that. (and running at a similar resolution to most C64 and A8 games)

EDIT: I think I know what you meant by the sound hardware being "improved" by DMA on the CPC+:
http://www.youtube.com/watch?v=MavWmgzr2P8#t=22s

Holy shit that music o_o Shame it doesn't sound like that in-game, only in the title screen =(

I've seen mixed (and vague/skimpy) information on the so-called DMA sound . . . and that video doesn't really help anything. (it's not doing anything beyond what's possible via CPU brute force playback on the 3 AY channels -especially telling given the 3 channels with hard L/R/Center configuration -as the AY is wired in the GX4000/CPC+)

It's sounds a bit better than yerzmyey's Spectrum sample tracker tunes http://www.youtube.com/watch?v=j4aEHXpRaUg but given those are all done on a 48k 3.5 MHz speccy, there's obviously room for improvement with the 4 MHz and (more importantly) 128k CPC+.

If it DID have DMA sound, you'd think they'd at least use it in-game for limited drums/sfx/etc.

[Sik]

If it DID have DMA sound, you'd think they'd at least use it in-game for limited drums/sfx/etc.

Unless it completely sucked up CPU time, or the samples ate up too much memory to be feasible. I mean, if games with the 64k memory outright removed all sound because of lack of memory and needed 128k (and that's just for square waves), I'd imagine that using samples in-game was just taking it to a stretch.

[evilevoix]

How in gods name can a wave be square? I am trying to follow along guys but I'm losing you.

[TrekkiesUnite118]

It's a pure digital sound wave. Where it's either on or it's off, there is no in between like you have with a Sine wave.

[evilevoix]

Oh I get it. Its one static sound such as a bleed or bloop and you cannot modify that sound.

[Sik]

How in gods name can a wave be square? I am trying to follow along guys but I'm losing you.

Second one

[Thenewguy]

If it DID have DMA sound, you'd think they'd at least use it in-game for limited drums/sfx/etc

Not really, there were only a literal two or three games even made specifically for the GX4000, most games on the system were 464 ports which didn't even use the hardware scrolling or hardware sprites!

From what I've seen, Fluff is the only GX4000/PLUS game designed for the hardware, attempting to push the hardware, in existence, and that was only made by one guy in under 3 months.

At least it was better than the C64GS . . .

Yes, significantly better, double the number of hardware sprites, 15 colour hi-res sprites instead of three colour low res sprites, sprite magnification, no 8X8 pixel 4 colour limitation, 4096 colours in the master pallete instead of 16, considerably faster CPU, 32+ colours onscreen simultaneously instead of 16?, similar resolution etc

Really, they're not comparable at all, the GX4000 isn't even a consolised version of anything, its not an Amstrad CPC, and the Amstrad Plus machines were designed and released simultaneously with it.

it would have made far more sense to persue a backwards-compatible successor to the Spectrum.

LOL, that would've been pretty interesting, just adding an Asic like chip to the Spectrum, I guess you'd be increasing the resolution over the GX4000, but decreasing the amount of background colours per 8X8 pixels, the clash would be gone due to the sprites and I guess i'd be easier to add colour with sprite overlays here and there than to try to make the resolution/detail look better the same way.

Its a shame Sinclair didn't just chuck a decent graphics chip with hardware scrolling, and the standard 8 3-colour sprites on a line feature into the Spectrum hardware and release it as a successor in 1985. Instead we got the POS 128k Spectrum putting the machine on life support for 5 years as it limped along begging for someone to put it out of its misery

something on the level of the CoCo III's graphics capabilities along with a 6 or maybe 8 MHz Z80 would have pushed it up enough to make a good low-end ST/Amiga gaming alternative -with weaker color and CPU resource than the ST, but similar sound and hardware smooth scrolling support

I'm not really up on this, but shouldn't the GX4000 be better for 2D games than the Atari ST in all aspects bar resolution as it is anyway?

I mean, the STs cpu is significantly better, but for 2D games its mainly being used up for scrolling and sprites, whilst the GX4000 does that in hardware (and its hardware sprites don't really seem that bad), Atari ST has a total of 16 onscreen colours? half as much as the GX4000 (and both seem to do interrupts pretty easily), the sound chips are the same, but GX4000 has DMA (don't really have details to know how useful that actually is).

For 2D GX4000 should have a better framerate and better scrolling than the Atari ST, it should have double the onscreen colours, similar sized sprites and numbers, and better sound, at the cost of (background) resolution.

For 3D the ST would be significantly better.

Or am I looking at this completely wrong?

[kool kitty89]

Yes, significantly better, double the number of hardware sprites, 15 colour hi-res sprites instead of three colour low res sprites, sprite magnification, no 8X8 pixel 4 colour limitation, 4096 colours in the master pallete instead of 16, considerably faster CPU, 32+ colours onscreen simultaneously instead of 16?, similar resolution etc

Isn't it a 4x8 cell limit in multicolor mode? (and 8x8 in high-res) That's definitely the case for the A8. (character cells are 4x8 in 160 pixel width mode -and 8x8 in 320 and 2x8 in 80 . . . in other words, 40 columns in all character modes)

LOL, that would've been pretty interesting, just adding an Asic like chip to the Spectrum, I guess you'd be increasing the resolution over the GX4000, but decreasing the amount of background colours per 8X8 pixels, the clash would be gone due to the sprites and I guess i'd be easier to add colour with sprite overlays here and there than to try to make the resolution/detail look better the same way.

I was thinking more like the CoCoIII's simple bitmap graphics with hardware scrolling and no sprites. (and 16 colors from 64 -6-bit RGB) So better for games than the SAM Coupe, and much earlier. (and by Amstrad/Sinclair themselves)

And it wouldn't really be adding an ASIC either, but building onto the rudimentary ASIC (the ULA chip used for video/interfacing/etc) and perhaps integrating some of the minor discrete logic chips of the older Speccy. (very similar to what Tandy did with the GIME -except Tandy had to build onto 3rd party off the shelf hardware rather than an existing in-house design) -And unlike the CoCo, the Speccy already did get a good game sound chip as standard in the 128. (and, honestly, the AY chip is even better for sample playback than the Tandy's 6-bit DAC in a variety of cases -though I'm not sure what sort of timer/interrupt support the Speccy ever got -one of the interesting features of the CoCo 3 was an interval timer/counter tied to the h-sync rate, making sample playback in games a lot more practical)

The Loki project seems to have been far more ambitious than what I described (and the Flare 1 certainly ended up as such) . . . maybe a decent follow-on design, but definitely not good for a timely, low cost speccy successor.

Its a shame Sinclair didn't just chuck a decent graphics chip with hardware scrolling, and the standard 8 3-colour sprites on a line feature into the Spectrum hardware and release it as a successor in 1985. Instead we got the POS 128k Spectrum putting the machine on life support for 5 years as it limped along begging for someone to put it out of its misery

Again, I think software sprites would have been enough (especially with a 6-8 MHz CPU). Software scrolling is a MASSIVE drain on CPU resource (you need to totally redraw the screen every frame -even using choppy 8-pixel wide segments doesn't change that), and hardware scrolling wouldn't just mean fast/smooth screen scrolling, but also MUCH more CPU resource for software rendering. (especially since most games of the time involved a single large scrolling BG and relatively few and/or small sprites)

For the same reason, the ST would have been massively more capable for many common game types with basic hardware scrolling support (even with the planar bitmap). Hell, the real-world performance advantage of the Amiga would have been even less apparent had than been the case. (probably the single biggest technical flaw in the ST in hindsight, at least for the European market -chunky pixel graphics and simple Mac-style DMA sound were other relatively simple/low-cost hardware possibilities that would have gone a long way . . . and integrated DMA sound may have actually been cheaper with the PSG removed -and replaced by a simple PIA chip -which Atari already had in substantial quantity for the A8- or perhaps a VIA or CIA -and also omitting the 2nd ACIA, but I digress )

I'm not really up on this, but shouldn't the GX4000 be better for 2D games than the Atari ST in all aspects bar resolution as it is anyway?

RAM would also be a big issue (ST could have much more detail and animation) and software rendering capabilities could be advantageous in some cases too. (especially games not using scrolling -either fixed-screen or pseudo 3D type forward scrolling racers/rail shooters/etc).

Level design, size, and complexity could also be limited by RAM.

For 2D GX4000 should have a better framerate and better scrolling than the Atari ST, it should have double the onscreen colours, similar sized sprites and numbers, and better sound, at the cost of (background) resolution.

I'm not sure how the GX4000 palette system works, but assuming it's 2 16 color palettes (a la SMS), then it's most definitely NOT double the colors since you're limited to 16 colors per tile (for char modes) or layer (for bitmaps).
An actual 32 color bitmap would either need 8-bits per pixel (chunky) or 5-bits if using bitplanes, both using even more screen memory than 4-bits (8-bit obviously much more so), and I rather doubt either of those is what the GX4000 did.


But, if nothing else, the resolution, animation, and detail in ST games would be major advantages for 2D games in general. (albeit, some workarounds for smooth scrolling -like pre-shifted tiles/sprites- use up more of the ST's RAM with redundant graphics, so some of the animation advantage would be lost in those cases)

Those (along with the color) are probably the most "16-bit" looking aspects of the ST's library in general. (color, animation, resolution, complexity, and detail)

[Thenewguy]

Isn't it a 4x8 cell limit in multicolor mode? (and 8x8 in high-res)

Yeah, I tend to lazily over simplify things as a character flaw.

They're 4X8 but the pixels are double size on 1 axis, meaning its a square which takes up an 8x8 pixel size

Again, I think software sprites would have been enough (especially with a 6-8 MHz CPU). Software scrolling is a MASSIVE drain on CPU resource (you need to totally redraw the screen every frame -even using choppy 8-pixel wide segments doesn't change that), and hardware scrolling wouldn't just mean fast/smooth screen scrolling, but also MUCH more CPU resource for software rendering.

But then without the hardware sprites you still have colour clash issues and/or single colour characters against single colour backdrops, just adding hardware sprites and hardware scrolling to Spectrum would've made it very respectable for the mainstream market in 1985 IMO

Trying to muck about with improving the clash, and colour placement in the background, instead of simply overlaying sprites on top would be difficult if you wanted to keep compatibility wouldn't it?

RAM would also be a big issue

Ah, OK, I'm still always overlooking a lot of this stuff, I can never tell whether systems can play anything straight from ROM, or whether they have to load all the data into system RAM and play from there.

I guess that is even more of an issue than the resolution then, and the two together really do kill the system stone dead, 64k of RAM often wasn't even enough for the CPC (though I guess before they were wasting a lot of memory for their software scrolling method?)

I'm not sure how the GX4000 palette system works, but assuming it's 2 16 color palettes (a la SMS), then it's most definitely NOT double the colors since you're limited to 16 colors per tile (for char modes) or layer (for bitmaps).

I think its just the standard CPC graphics modes (16 colour low resolution, or 4 colour high resolution) with the 16 15-colour sprites overlaid on top using their own selection of 15 colours.

Doesn't the Atari ST just make software sprites out of the background? (ie they just share the 16 colours with the background, they don't have their own palette) leading to 16 colours onscreen?

I'm probably very much in over my head in these kinds of discussions tbh.

[Kamahl]

Doesn't the Atari ST just make software sprites out of the background? (ie they just share the 16 colours with the background, they don't have their own palette) leading to 16 colours onscreen?

Yes.

[Chilly Willy]

The ST has no sprites, just a single background. That background is 16 colors, but the ST has a DMA channel reserved for the palette, so those 16 colors can be changed on any/every line via DMA. The most common thing you see in ST games is using the DMA to change the palette for a status bar at the top or bottom of the screen. Wolf3D for the Atari ST does that. It also changes the palette on every line for static images, like the title or menu screens.

[Thenewguy]

Yeah, that's kinda' what I thought, GX4000 can change the palette, as well as the Mode midscreen too, but I don't know whether it has to miss a few lines every time it interrupts (ie it possibly can't change every line)

Like i said before, for every piece of technical information I understand, there probably one piece that I don't, or have misconstrued

[kool kitty89]

But then without the hardware sprites you still have colour clash issues and/or single colour characters against single colour backdrops, just adding hardware sprites and hardware scrolling to Spectrum would've made it very respectable for the mainstream market in 1985 IMO

Again, I was suggesting increasing the actual color depth of the framebuffer . . . so no longer just 1-bit color (plus cell attributes), but full-screen 4-bit color allowing 16 colors ANYWHERE on screen. (the specific suggestion was to use 6-bit RGB -like the CoCo III and SMS- which would probably be more realistic for an on-chip color DACs at the time -for a low cost oriented ASIC; case in point with the CoCo III)

And, assuming packed pixels (like the CoCo III), software rendering would be less problematic than on the ST too, since you'd get fairly decent sprite positioning/granularity by working on byte boundaries (so 2 pixel wide blocks), and even on nybble/pixel boundaries you'd still have less overhead (for bit manipulation) than with bitplane graphics. (plus, masking is simpler too -no need for a formal bitmask, just treat zero as transparent -so sprite pixels would be 15 colors plus the reserved transparent/no-write values)

You need more screen memory for higher color depths like that, but 128k would have been good for that too. (which was also what the CoCo III had out of the box -expandable to 512k)

OTOH, you COULD take the old speccy graphics directly and add hardware sprites and such, but not only would that tend to look worse (and 16 color bitmap graphics), but it very well may take up much more chip space than enhanced bitmap support. (sprite logic -and especially line buffers- usually aren't trivial)

Ah, OK, I'm still always overlooking a lot of this stuff, I can never tell whether systems can play anything straight from ROM, or whether they have to load all the data into system RAM and play from there.

Oh . . . right. actually I overlooked that issue in this case. (got too caught up on the computer comparison) ROM could be a mitigating factor on the GX-4000, but it would require large ROMs and uncompressed graphics. (and still other considerations like overhead to copy sprite/BG graphics into RAM as needed -unless sprites could be pulled straight from ROM too)

I guess that is even more of an issue than the resolution then, and the two together really do kill the system stone dead, 64k of RAM often wasn't even enough for the CPC (though I guess before they were wasting a lot of memory for their software scrolling method?)

Hmm, not sure about software scrolling (since it uses chunky pixels, I assumed it usually used simple software scrolling via full-screen redrawing -using an 80x200 grid on 8-bit boundaries for minimum overhead), and that shouldn't add to RAM usage.
However, I also remember something about limited hardware scrolling/offset support too (also limited to byte boundaries -so an 80 pixel wide grid), but I'm not sure of the specifics.

As for RAM constraints in general, there's the significant issue of screen memory: in all full 320x200 (mode 1) or 160x200 (mode 0) games, it takes 15.625 kB just for single buffering, and double that for double buffering (compared to under 16k for double buffered 256x192 on the speccy). That's an even bigger problem on the BBC micro and Electron, at least at higher resolutions and/or higher colors. (RAM is even more limited, and the 160x256 8 color mode takes 20 kB single buffered . . . though using a larger boarder -at the expense of garbage in said boarder- would cut back on that)

Doesn't the Atari ST just make software sprites out of the background? (ie they just share the 16 colours with the background, they don't have their own palette) leading to 16 colours onscreen?

Yes, that's exactly what I was suggesting. (except for using packed/chunky pixels rather than bitplanes -to reduce overhead for software rendering; though, again, scrolling if the real killer for CPU overhead, so hardware scrolling would matter much more than chunky vs planar bitmaps)



The CoCo 3 really is a good example of a relatively simple, but generally capable games-friendly 8-bit computer graphics architecture for the time (even more so if you cut out the character modes and some of the resolution and color depth modes -and, in the speccy's case, the logic would be built more around the old Spectrum video ULA chip rather than the Motorola VDG).
If not for the sound limits of the CoCo 3, it would have made a pretty damn good game platform for the mid/late 80s (or even into the early 90s as a budget platform) . . . the Speccy 128k had that area covered though. (so, a speccy with a CoCo 3 style graphics and CPU update along with Speccy 128k sound could have been ideal -and a 6 or 8 MHz Z80 very likely would have been cheaper than a 2 MHz 6809 too)

[sheath]

I thought this came up in this group, probably in some random thread. I am being told I am wrong over at ASSEMblergames that the PCE Arcade Card was using ROM (not RAM) but it functions just as fast as the PCE's RAM. Can anybody illuminate the topic or point me to a document that can?

[Chilly Willy]

The Arcade Pro has both rom and ram - the rom has the BIOS, and the ram is for loading from the CD. The Arcade Duo has only ram - it was designed to take advantage of the BIOS already in the PCE Duo, so it only needed the ram.

EDIT: Whoopsi! Other way around on the Arcade Duo... sorry about that. Here's a good site for PCE info, including the Arcade cards:
http://archaicpixels.com/index.php/Arcade_Card