Jump to content
IGNORED

It's 1990, your designing a game system, what would you do?


Recommended Posts

It depends what you mean by "1990 PC" and what you mean by "play" in respect to Doom.

 

By spring of 1989, up to 33 MHz versions of the 386DX were available and 20 and 25 MHz 486DX's were as well, and by spring of 1990, so was the 33 MHz 486DX. THe question comes for what kind of PCs were those used in, for 1990 probably only high-end workstation PCs had 486s, maybe the 20 MHz 486 would have been in some higher end home/buisness PCs as well. (either custom assembled machines or commercial ones) I'd say the 33 MHz 386DX was probably goign to be the best youd get for any common, mid-range home or buisness PC in 1990, and probably higher-end of mid-range at that. (unless, of course, you had a slow 386 machine you were then upgrading)

 

More likely for a mid-range PC would have been a slower 386, possibly a fast 286 or a perhaps 386SX. (which took a huge performance hit compared to the DX) Fast 286s would be struggling with Wing commander and Wolfenstein3D, slow to mid 386DXs could handel those OK (but I think a 33 MHz 386DX was needed to play both at full speed and optimum settings), but a 33 MHz 386DX was the bare minimum requirement for Doom, and would likely only be playable in low detial mode and reduced screen size, probably a little worse than the 32x version, better than the SNES, maybe about like the 3DO version does.

 

However, given the 3DO had a 12 MHz ARM 60 and a GPU to aid with texturing (and a fixed point matrix coprocessor, but I'm not sure they took advantage of that, assuming it could be useful for raycasting), that would most definitely put a 12 MHz ARM3 at a disadvantage, unless of course, the 3DO port is very poorly optimized, doesn't make any use of the coprocessor or hardware texture rendering and goes all software, or if the ARM3 in crazyace's consoel had a cache too and/or was faster than 12 MHz. With both on similar speed busses and no caches, the ARM3 (or ARM250) would be only about 70% as fast as the 3DO's ARM60.

It should have been easily able to handle games like Wing Commander and Wolf3D, but perhaps struggle a bit with soem more detailed 2D games, Jazz Jackrabbit for instance on PC (albeit the mod player in that also took up a fair amount of CPU resourse), it could probably manage alright, and have a good deal more variety in game types than the mainly 2D oriented platforms.

 

Now, if a 26 MHz rated ARM3 was a possibility, using 1/2 clocked memory (and a cache), you'd have somethign a fair bit more powrful than the 3DO's CPU (in fact, it would have made a lot more sense to use on the 3DO itsself given the memory conflicts with GPU and how much a cache would have helped), but I'd immagine that would have been more expensive by a good amount. Again, in 1990, there was no ARM250, so no cachless lower cost version available anyway, so you're stuck with a 4 kB cache and the related cost. (granted to 250 has the IOC1, VIDC1a and MEMC1 chips integrated, so not a low cost bare bones alternative like the ARM60 -but a great embedded option for using the Archemedes hardware -but not until 1992)

The earliest ARM3s available iirc were in mid 1990 and were 26 MHz rated models with 4 kB unified cache. (the ones used on the Archemedes 540)

 

However, with 512 to 1024 kB of shared DRAM, ROM cart interface only and such, that might make for a console under $300 in 1990. With CD drive you can probably forget about it. (but I never saw that as a suggestion anyway, and it was I who brought it up with the Sega CD anyway)

 

In fact, with a slim base unit profit (or none) and with cheap DRAM (so common speeds (probably no more than 80 ns FPRAM), the console might have been posible to sell at $200 if the CPU and cusom chips didn't exceed ~$70-100 per unit, assuming the hardware was purchased (or licenced) from Acorn+ARM.

Link to comment
Share on other sites

Hmm, interesting, the ARM250 would seem to have been the ideal choice for such a design (cost wise), but I don't think that was available until 1992. (a 12 MHz, cacheless ARM3 would have been a good alternative prior to that, but I don't know of ARM offering such -something equivelent to the ARM60, but earlier -just th ebare core in a package)

Of course, if you need the added performance of the cache, none of this matters anyway, you'd go for the full ARM3. (which should be a good bit more expensive)

 

Would a 12 MHz ARM3 really be able to render SNES/MD (or Amiga) level 2D with software rendering alone? Even Sega's 32x was fairly limited for 2D capabilities, barely able to match the SNES in some respects for straight 2D games. (and even then it often relied on Genesis hardware for some things) I could see it being roughly comperable to early VGA games on mid-range 386 PCs (like 20-25 MHz -not talking SX of course).

 

I expect it would be able to match the Megadrive pretty well for 2D - it would be a different system, no sprite flickering , more timeouts if the screen had too much happening ( like the Amiga or ST or PC ) Handling the 4 layers plus sprites of the SNES would be more difficult - but to balance that things could be done that would require the SuperFX chip on the SNES.

I'd think of it like a faster A1200 or Falcon, a 12MHz Arm2 ( or Arm3 ) should be nearly twice as fast as the 68020/68030 found on those systems. It should also vastly outperform the 386PC's due to the local memory graphics ( one of the bigger limitations of VGA ) Cache/No cache is interesting - at this stage and clock the memory speed was still keeping up with the CPU speed.

 

 

The Archimedes video hardware didn't offer any graphics acceleration did it? (no blitter or such, but possibly some simple things like scrolling or line fill -iirc VGA offered soem minimal assistance -and the 32x's VDC offered line fill if nothing else)

I doubt it would be able to handel a mode-7 style layer at 60 Hz as the SNES can in hardware. Of course, speed of various things would depend on the resolution and color depth used too. A 320 wide display at 8-bit color depth would be needed to approximate th edetail in a lot of MD and, especially SNES games, 4-bit depth could probably look fairly close to soem MD games too, but in either case, the game is likely going to suffer slowdown with software rendering.

I'll have to think about Mode7 at 60Hz - something similar could be done ... after all the Falcon managed a mode 7 effect (

) Also in terms of sprites you could make a much more accurate streetfighter or mortal kombat as there would be no 256 pixel limit on sprites in a line.

 

However, goign CPU alone has the advantages of flexibility, and with a bitmapped display driven by a fairly powerful CPU it would be much better at 3D than either of the contemporaries, with stock hardware at least. Same for software driven scaling effects and such. (though it would be at a disadvantage in cases playing to the strengths of mode 7 -granted sprites won't scale on the SNES -other than an object generated as the mode 7 tile)

Yup - software scaling on sprites would be a big win in moving a lot of the Sega style driving games.. ( PowerDrift or Outrun )

 

I'm not sure how competitive it would be agains the custom coprocessors on the cartridge of the others though, but probably fairly competitive in those cases too. And, of course, assumign there's a decent amount of RAM (say 512 kB of shared memory), that would be a big advantage as well, especially for ports from computers. (wolf3D must have taken a ton of work to work on 128 kB in the SNES)

No matter how fast the custom cartridge is - the limit would be the transfer to the VDP. With this machine - as video comes from ram you could have a card with a 3D accelerator in and just point VIDC to the cartridge memory :)

 

Also, the 256 line tall resolution, would be for 50 Hz only right? For 60 Hz, it would make more sense to clip to 240 or 224 lines, with no more than 224 lines usually visible in 60 Hz on most TVs. (in 50 Hz, even with a fair bit of overscan, you could afford a fair bit more than 256 lines too as far as TVs go, iirc usually around 272 lines or slightly fewer are visible)

Of course, you could clip the screen further in specific cases, namely for added performance in graphically intensive games -and/or drop to lower resolution. (with usual overscan, you can clip a 320x240 screen to 288x216 before it really starts getting noticable on many TVs)

Probably 224 lines would make sense, for NTSC TV's

 

So, would such a system be cartridge based, CD, or perhaps magnetic disk based? (probably not the latter due to piracy issues)

 

A 1x CD drive could easily add $100 to the price ~1990, money that could easily contribute to using an ARM3 with a Cache, possibly a faster model (like 24 MHz core with 12 MHz bus), and more RAM. (1 MB would be nice) Of course, with sufficient RAM, a lot of data could be stored at fairly high compression on ROM carts, reducing cost there. (decompressing and loading games into RAM instead of running much of the program from ROM)

For 1990 I would think a cartridge - the aim would be to compete with the Genesis , SNES , PC Engine and NeoGeo.

 

 

There are disadvantages to this Arm system - but the interesting thing is that it was a real product - and for a console it would cost a lot less than it did in a computer :)

Link to comment
Share on other sites

It depends what you mean by "1990 PC" and what you mean by "play" in respect to Doom.

 

By spring of 1989, up to 33 MHz versions of the 386DX were available and 20 and 25 MHz 486DX's were as well, and by spring of 1990, so was the 33 MHz 486DX. THe question comes for what kind of PCs were those used in, for 1990 probably only high-end workstation PCs had 486s, maybe the 20 MHz 486 would have been in some higher end home/buisness PCs as well. (either custom assembled machines or commercial ones) I'd say the 33 MHz 386DX was probably goign to be the best youd get for any common, mid-range home or buisness PC in 1990, and probably higher-end of mid-range at that. (unless, of course, you had a slow 386 machine you were then upgrading)

 

More likely for a mid-range PC would have been a slower 386, possibly a fast 286 or a perhaps 386SX. (which took a huge performance hit compared to the DX) Fast 286s would be struggling with Wing commander and Wolfenstein3D, slow to mid 386DXs could handel those OK (but I think a 33 MHz 386DX was needed to play both at full speed and optimum settings), but a 33 MHz 386DX was the bare minimum requirement for Doom, and would likely only be playable in low detial mode and reduced screen size, probably a little worse than the 32x version, better than the SNES, maybe about like the 3DO version does.

I think a 12MHz ARM2 ( In some articles the ARM3 wasn't that much faster clock for clock than the ARM2, even with the cache ) would match a 33MHz 386DX PC at Doom. Also the screen could be set to 160 pixel mode 256 colour - so the 'windowed' PC version would be full screen ( like the jaguar version ) - and double buffering rather than copying to VGA memory would also be a big saving.

 

However, given the 3DO had a 12 MHz ARM 60 and a GPU to aid with texturing (and a fixed point matrix coprocessor, but I'm not sure they took advantage of that, assuming it could be useful for raycasting), that would most definitely put a 12 MHz ARM3 at a disadvantage, unless of course, the 3DO port is very poorly optimized, doesn't make any use of the coprocessor or hardware texture rendering and goes all software, or if the ARM3 in crazyace's consoel had a cache too and/or was faster than 12 MHz. With both on similar speed busses and no caches, the ARM3 (or ARM250) would be only about 70% as fast as the 3DO's ARM60.

It should have been easily able to handle games like Wing Commander and Wolf3D, but perhaps struggle a bit with soem more detailed 2D games, Jazz Jackrabbit for instance on PC (albeit the mod player in that also took up a fair amount of CPU resourse), it could probably manage alright, and have a good deal more variety in game types than the mainly 2D oriented platforms.

This is a 1990 comparision - the 3D0 was 93 onwards... I'm really thinking of this as a comparision to SNES / Genesis , with the added 3D capabilities :)

 

Now, if a 26 MHz rated ARM3 was a possibility, using 1/2 clocked memory (and a cache), you'd have somethign a fair bit more powrful than the 3DO's CPU (in fact, it would have made a lot more sense to use on the 3DO itsself given the memory conflicts with GPU and how much a cache would have helped), but I'd immagine that would have been more expensive by a good amount. Again, in 1990, there was no ARM250, so no cachless lower cost version available anyway, so you're stuck with a 4 kB cache and the related cost. (granted to 250 has the IOC1, VIDC1a and MEMC1 chips integrated, so not a low cost bare bones alternative like the ARM60 -but a great embedded option for using the Archemedes hardware -but not until 1992)

The earliest ARM3s available iirc were in mid 1990 and were 26 MHz rated models with 4 kB unified cache. (the ones used on the Archemedes 540)

ARM3 would be nice - It might even be possible to cost reduce earlier if it's a console rather than a low volume computer range.

 

However, with 512 to 1024 kB of shared DRAM, ROM cart interface only and such, that might make for a console under $300 in 1990. With CD drive you can probably forget about it. (but I never saw that as a suggestion anyway, and it was I who brought it up with the Sega CD anyway)

 

In fact, with a slim base unit profit (or none) and with cheap DRAM (so common speeds (probably no more than 80 ns FPRAM), the console might have been posible to sell at $200 if the CPU and cusom chips didn't exceed ~$70-100 per unit, assuming the hardware was purchased (or licenced) from Acorn+ARM.

Yes - 1MB of DRAM would actually compared well to the cost of all of the different rams found in the SNES or Genesis.

 

I think I'll have a look to see if there are any youtubes of doom style games running on old ARMs.

Link to comment
Share on other sites

The SNES's PPU is either 5Mhz with two 8-bit data buses, or a 10-Mhz with one 8-bit data bus. If Nintendo used a 20-Mhz PPU with an 8-bit data bus, they could've had 32 8x8 tiles of rotatable and scalable sprites accross the screen, and there can be daul "Mode7" layers, or 4 bgs with tile-per-offset scrolling.

Link to comment
Share on other sites

If we're talking about a system *released* in 1990, then I'd just start with the Genesis, which was $200 at the time.

Upgrade the graphics chip to something closer to the System16 arcade version. It doesn't need to be the same chip, just closer.

If there's still money left, then substitute a YM2151 sound chip instead of the YM2612.

If there's still money left (doubtful), upgrade RAM to 128KB and/or CPU speed to 10MHz (I don't know which would be more useful).

Basically take a Genesis and move it closer to arcade specs, as budget allows. Probably wouldn't gain that much except maybe the graphics improvement.

But this would be a bad idea - $300 was a lot of money for a console, even $200 was a tough sell.

 

 

If we're talking a system designed in 1990 to release around 1992-93, then that's a hard question. That seems like it was a bad time to release a console. Sega/Nintendo were already established, people weren't easily impressed with sidescrollers anymore, 3D wasn't ready yet, CDROM was expensive, and full motion video sucked.

Edited by gdement
  • Like 1
Link to comment
Share on other sites

I expect it would be able to match the Megadrive pretty well for 2D - it would be a different system, no sprite flickering , more timeouts if the screen had too much happening ( like the Amiga or ST or PC ) Handling the 4 layers plus sprites of the SNES would be more difficult - but to balance that things could be done that would require the SuperFX chip on the SNES.

Hmm, I don't see why the MD would be that much easier to match; approximating it in 16 colors would be esier, but to meet or exceed color detial on either console, you'd at least need to use an 8-bit paletized graphics mode. The SNES only has 1 4-plane BG mode, Mode 0, but it's almost never used as it's 4-color tiles only. Mode 1 offers 3 BG planes and is fairly often used, but one of those planes is also limited to 4-color tiles. (the other 2 using 16 color tiles) Mode 2 is another very commonly used one, 2 16-color tile layers with the ability to scroll each tile separately (so cool paralax effects), that mode is the most like what the MD does I believe. (especially comparing the MD in 256 wide resolution mode)

The SNES can push more sprites per line without flicker or dropout as well as having a larger master palette and more numerous subpalettes (16 subpalttes opposed to 4), as well as more display modes, but for typical games, the actual graphics used aren't that different. (mainly in color used -or resolution if you compare MD games using the common 320 pixel wide mode) Visibly at least, as there are a lot more technical differences between the systems otherwise. (like the SNES using planar graphics -except mode 7- and the MD using packed pixels)

 

What did you mean by "timouts" in the context of PC and Amiga? (would that refer to dropping frames or slowdown?)

 

No matter how fast the custom cartridge is - the limit would be the transfer to the VDP. With this machine - as video comes from ram you could have a card with a 3D accelerator in and just point VIDC to the cartridge memory :)
True, but I think that was much more an issue on the Genesis than the SNES. (very restrictive DMA limitations of the VDP, hence the major clipping for Virtua Racing to increase vblank time) I think the SNES has the limitation of a maximum of 32 kB for a single tilemap set, so any approximated bitmap (which would need to be assembled of tile cells) would have to fit into 32 kB. (probably one reason for the clipped Super FX games, especially the 256 color ones like Doom, Dirt Trax, and Stunt Racer FX -Star Fox and Vortex used 16-color tile modes)

 

For 1990 I would think a cartridge - the aim would be to compete with the Genesis , SNES , PC Engine and NeoGeo.

I wouldn't even bring Neo Geo into this, that's another issue entirely. (and they might have been better off going CD from the start given the huge cost of cartridges)

Anyway, by 1990, PCE had already been shifting to CD as its main media too, at least in its successful Japanese market. However, I didn't see any claim for this to cater to the Japanese market specifically, so for 1990, CD's probably not goign to be preferable in any case. (provisions for a CD upgrade might be a good idea though -such as to minimize cost and hassle of such an upgrade unit)

 

 

I think a 12MHz ARM2 ( In some articles the ARM3 wasn't that much faster clock for clock than the ARM2, even with the cache ) would match a 33MHz 386DX PC at Doom.

Looking at real world examples though, the ARM2 wasn't commercially available above 8 MHz as far as I can see, and lower-rated ARM3s weren't there either at the time. (from the history/development articles I see online, it looks like the ~26 MHz ARM3 was the first produced, along with a couple similarly rated versions, followed by a 33 MHz version a bit late and the integrated ARM250)

 

I suppose they could have introduced a lower end/cheaper version (like the ARM60 was later on) for such purposes, or the core could have been licenced and produced as such as well. This is assuming that there weren't faster ARM2s available, otherwise, those should be fine for this purpose.

 

Also the screen could be set to 160 pixel mode 256 colour - so the 'windowed' PC version would be full screen ( like the jaguar version ) - and double buffering rather than copying to VGA memory would also be a big saving.
Hmm, low detail mode in PC doom already does 160 pixels wide (ever pixels is repeated as a pair for the 320 wide display, so effectively 160 wide other than taking up the same space in video RAM), going for a smaller window is done independently from the low/high detail setting. (32x, Jaguar, 3DO, and SNES all use double wide pixel rendering too iirc) At maximum screen size on pC, you actually loose the status bar ;). (having the big status bar does indeed reduce the screen wondow size by quite a bit)

As for double buffering, isn't that a limitation of using VGA mode 13h? (doesn't "mode X" allow for double or tripple buffering in VGA RAM? -not to mention various resolutions, 320x240 obviously being a popular choice, no more 13h non-square pixels to deal with)

 

This is a 1990 comparision - the 3D0 was 93 onwards... I'm really thinking of this as a comparision to SNES / Genesis , with the added 3D capabilities :)

I was just trying to get a refrence of what Doom might be like, again though the 3DO version may not have been very optimized. (and if all software rendered, it wouldn't be much slower on a 12 MHz ARM2/3 than it was on the ARM60) The 3DO its self is another topic entirely.

 

ARM3 would be nice - It might even be possible to cost reduce earlier if it's a console rather than a low volume computer range.

Yeah, or specifcally produce a lower cost varient as I started to mention above. In that line of though though, with such a console, perhaps the ARM250, or something liek it might have gotten pushed a bit earier too. (whether ARM/Acorn was actually the one creating/marketing the console or some other company 0obviously still with some association with Acorn if the Archimedies chipset was to be used) The most efficient situation would have been if the game company interested (assuming it's not Acorn themselves) directly partnered with Acorn on the endeavour.

 

Yes - 1MB of DRAM would actually compared well to the cost of all of the different rams found in the SNES or Genesis.

That actually came up at Sega 16 on the Genesis. The SNES did use DRAM for main memory (albeit very slow for some reason, 2.68 MHz, even slow than the CPU -it doesn't really make sense to have either clocked so slow really, havign both at 7.16 MHz would have made perfect sense for 1990). And for video memory it was necessary for fast/expensive RAM to be used, I think SRAM on the SNES and definitely VRAM on the genesis (dual ported DRAM), but they ended up using PSRAM for the 68000 and Z80 RAM in the genesis for some reason. (cheaper than SRAM, but a good deal more expensive than DRAM, especially given how exotic PSAM was at the time -I can only guess it was done to save on development time rather than configuring DRAM refresh circuitry -though I though the Z80 had DRAM refresh hardware built-in)

 

As to DRAm in general, cost would be dropping too, going by this: http://phe.rockefeller.edu/LogletLab/DRAM/dram.htm you could start with 128 kB chips in 1990 (8x 4x1Mbit DRAMs) then switch to 512 kB chips later on. (with 2x 16x4Mbit DRAMs)

 

Not so with the Jaguar, of course, with DRAM prices stagnating from 1992 through 1995 and switching to larger DRAM chips not being an option either. (they needed a 64 bit bus, and 2 MB 64-bit DRAM chips wouldn't have been available)

Edited by kool kitty89
Link to comment
Share on other sites

The Megadrive would be easier to replicate because it's only 2 BGs - the SNES has more complexity in the combinations of BGs0-3. Funny - I always seemed to see more flicker on the SNES when I tested sprites per line - it does support more sprites though..

By timeouts I mean slowdown ... As there are no h/w sprites there would be no flickering at all.

 

On both the Megadrive and SNES there was a real limitation on how much data you could transfer to the VDP in a frame.

 

I thought a bit more about Mode7 - the quickest DDA texturer I can think of in ARM code would be 5 instructions/pixel , which would need a 21MHz ARM to run at 60Hz (320x224x8bit) so a 12MHz ARM would have to cheat a bit :)

Link to comment
Share on other sites

Mode 1 offers 3 BG planes and is fairly often used, but one of those planes is also limited to 4-color tiles. (the other 2 using 16 color tiles)

 

Too bad nobody actually used the third layer.

 

Mode 2 is another very commonly used one, 2 16-color tile layers with the ability to scroll each tile separately (so cool paralax effects), that mode is the most like what the MD does I believe. (especially comparing the MD in 256 wide resolution mode)

 

Too bad nobody actually made the tiles scroll seperately.

Link to comment
Share on other sites

If we're talking about a system *released* in 1990, then I'd just start with the Genesis, which was $200 at the time.

Upgrade the graphics chip to something closer to the System16 arcade version. It doesn't need to be the same chip, just closer.

If there's still money left, then substitute a YM2151 sound chip instead of the YM2612.

If there's still money left (doubtful), upgrade RAM to 128KB and/or CPU speed to 10MHz (I don't know which would be more useful).

Basically take a Genesis and move it closer to arcade specs, as budget allows. Probably wouldn't gain that much except maybe the graphics improvement.

But this would be a bad idea - $300 was a lot of money for a console, even $200 was a tough sell.

The Genesis was released in 1989 at $189.99, so not quite $200 an dwas reduced to $150 in 1991. along with the switch to Sonic as pack-in)

 

However, on the topic of improving the Genesis, there's a ton, and it's been discussed in multiple places, but signficantly in this thread on sega-16: http://www.sega-16.com/forum/showthread.php?t=4328&page=16

Soem of the most notable things are: switching to DRAM for main memory (could have gone up to 128 or 256 kB easily and still saved over the PSRAM used originally). Connect the interupt line of the Z80 and/or 68k to the YM2612 for precise timing (and much better, less CPU intensive PCM playback), faster CPU (10 or 12.5 MHz), faster Z80, adding the VDP pixel bus to the expansion port and/or cart slot, add more address space to the expansion slot, add YS to the expansion slot. (one option might just being cloning the cart slot on th eexpansion port -possibly adding the VDP pixel bus to that alone to avoid increasing the cart slot pin count)

 

Then there's the VDP, allow for 8 subpalettes instead of 4, 12-bit RGB instead of 9, and preferably, a 1/2 res 8-bit pixel mode. (accumulation of consecutive pixels to allow 160 pixels across in 16-colors, sort of like GTIA allows -note 8-bit direct RGB could be used if adding enoguh color RAM wouldn't be possible)

Also, have 2 VRAM banks, if 2x 64 kB banks are too expensive, allow 64 kB to be configured as a single block, or 2 32 kB banks.

Witht he faster CPU, you wouldn't necessarily have to add cost with faster RAM (and especially ROM), but simply clock the CPU faster, rather liek in overclock mods. (this would not reach th full benfits as any memory dependednt operations would be limited by RAM/ROM, but it would speed up a good many other things -as overclockign does -with is stable for preactly ever model and every game up to ~10 MHz and ~12 MHz in many cases; and this is without specifc provisions in the hardware to facilitate such)

 

Finally, elliminating SMS compatibility could have helped a lot, the Z80 really isn't necessary (with the interrupt line connected, the 68k alone would be fine to handel audio, not to mention a faster 68k), plus a fair chunk of the VDP is dedicated to providing SMS compatibility as well (the master System VDP has very little in common with the MD one), so you facilitate a lot of enhancements by omiting that. (especially hose VDP ones) Perhaps even use dual YM2612s too. (and drop the PSG from the VDP as well)

 

 

 

If we're talking a system designed in 1990 to release around 1992-93, then that's a hard question. That seems like it was a bad time to release a console. Sega/Nintendo were already established, people weren't easily impressed with sidescrollers anymore, 3D wasn't ready yet, CDROM was expensive, and full motion video sucked.

You could have gotten fiarly decent 3D (especialy balanced with a lot of 2D scaling plus 3D, pseudo 3D, and pure 2D games). Something like the Jaguar could have been that, even by 1993 had work been more focused and Atari Corp not been so strapped for cache at the time. (like if Flare had founs someone else to work with instead) I mean it wouldn't have been perfect, but the Jaguar design really could have been perfect for an early 5th gen console.

 

Conversely there's the 3DO, but that took the completely wron buisness model as well as soem unfortunate compromizes with hardware. The biggest problems I can see are the buisness model, having minimal licencing fees on games, high hardware prices and licenced hardware by several makers. Had 3DO been headed by Pannasonic alone (and the 3DO company), using an extreme razor and blade buisness model like Sony, that would have been ideal. (more than the usual razor and blade as that normally means slim or no hardware profits, while sony was eating losses instead, making it up through software licencing and sales) Using a 1x speed drive might have saved a good amount on cost as well. (and not necessarily made for aweful load times either, as a good CD-ROM buffer can help a lot with that -like the CD-Z did, plus effecient organization of data on the discs themselves -especially since early CD gmes took up a small fraction of CDs -streaming audio and video would take up a lot though)

 

Following that are the hardware limitaions, namely GPU and CPU fighting over main RAM and use of quadrilateral primitives. As far as the quads go, they really should have just gone with Triangles, plain and simple. (I know there are soem exceptions, but in most cases and by most people, that's much preferred)

 

For the RAM conflicts, there might be a couple solutions. Firstly, it comes about from the GPU using the main DRAM as the sourse with VRAM as destination and the CPU having no cache. So, the most direct solutions would either be another bank of RAM, or switching to a PU with a cache.

Adding more RAM would obviously add to cost, and splitting up the current RAM could result in soem other complex issues. Looking at VRAM alone, it's 1 MB on a 32-bit bus (I assume 2x 512 kB 16-bit dual ported DRAM chips), and if those are indeed 16-bit chips, you couldn't just split them into 2 separate 512 kB banks and 32-bit wide chips wouldn't be available either, so unless you used a bunch of 128 kB chips instead, that's a no go. (and adding all those chips and taking up that board space is going to cost money)

The DRAM might be doable, I'd assume the used 4x 8-bit 512 kB chips, so if they used 16-bit wide chips instead, that could allow for 2x 32-bit blocks of 1 MB for DRAM. Now, if you dedicated oen of those banks to the GPU, then you're now down to 1 MB of main RAM, but if you allowed one blok to be shared (like the 2MB is now) and 1 MB dedicated to the CPU, that might work out well with the game logic, ai, and such in the dedicated CPU block and additional data and such in the shared block. (I'm not sure how much arranging such would cost though)

 

The simplest solution is just switching to a CPU with a cache, but that's goign to be more expensive, at least compared to the very low-cost ARM60 they used. Perhaps an older ARM3 might be available at reasonable prices by then, even with lower performance, the feature of a cache would be well worth the switch. If the ARM3s were all still on older process chips, they would be using a lot more silicon though, so in that respect, the ARM610 might have been the best option. (unless the ARM3s were cheaper for non manufacturing related reasons -but those wouldn't persist)

 

 

On both the Megadrive and SNES there was a real limitation on how much data you could transfer to the VDP in a frame.

Yes, but as I understand it, MD was mcuh more limiting. (a lot better in 50 Hz though with all those extra vblank lines per frame for DMA time)

 

I thought a bit more about Mode7 - the quickest DDA texturer I can think of in ARM code would be 5 instructions/pixel , which would need a 21MHz ARM to run at 60Hz (320x224x8bit) so a 12MHz ARM would have to cheat a bit :)

30 FPS would be fine though, a lot of prople probably wouldn't notice much if at all. (plus, mose mode 7 stuff -racing games at least) only used th etile for about 1/2 the screen, with normal BG above it. (switching modes on the horizon line)

 

Mode 1 offers 3 BG planes and is fairly often used, but one of those planes is also limited to 4-color tiles. (the other 2 using 16 color tiles)

 

Too bad nobody actually used the third layer.

You mean like Earthworm Jim 2 and Donkey Kong COuntry? :roll: (the far BG layer of each)

 

Too bad nobody actually made the tiles scroll seperately.

Really, I'm not sure of a lot of specific examples on the SNES, but I'm pretty sure Street Fighter 2 demonstrates this. (I'm talking indiviual rows of tiles in th esame BG layer scrolling independently -or individual columns for vertical scrolling stuff, but I'm not sure of examples for that)

It's quite often used for clouds though.

Edited by kool kitty89
Link to comment
Share on other sites

 

You mean like Earthworm Jim 2 and Donkey Kong COuntry? :roll: (the far BG layer of each)

 

Really, I'm not sure of a lot of specific examples on the SNES, but I'm pretty sure Street Fighter 2 demonstrates this. (I'm talking indiviual rows of tiles in th esame BG layer scrolling independently -or individual columns for vertical scrolling stuff, but I'm not sure of examples for that)

It's quite often used for clouds though.

 

The 3rd background layer was hardly ever used by anyone other than Rare, Factor 5 or Virgin.

 

And no, Street Fighter 2 uses line scrolling and that can be done in every mode. The only times I remember tile-per-offset actually being used was the giant zombie turtle boss in Contra: Alien Wars, and the snake boss in Aladdin.

Link to comment
Share on other sites

The 3rd background layer was hardly ever used by anyone other than Rare, Factor 5 or Virgin.

In addition to the few uses as a full background layer, but it's often used for simple overlay graphics too (for status bars and such), Street Fighter II uses it for the health bars, Star Fox uses it for the Star Fox emblem on the title screen, etc.

Link to comment
Share on other sites

The 3rd background layer was hardly ever used by anyone other than Rare, Factor 5 or Virgin.

In addition to the few uses as a full background layer, but it's often used for simple overlay graphics too (for status bars and such), Street Fighter II uses it for the health bars, Star Fox uses it for the Star Fox emblem on the title screen, etc.

I find that to be pretty dumb that it was only used for status bars. Why didn't they just set up an IRQ or H-DMA to change it from a status bar to a parallax layer after the last scanline the status bar is visible?

Link to comment
Share on other sites

Not that many games uses it for the status bar anyway, and in many cases they're multiplatform games which don't use more than 2 BG planes anyway. A lot of games simply use sprites for the status displays instead (I'm not entirely sure why they opted for the 4-color Star Fox insignia either rather than building it from sprites -especially as that's what's done in the rest of the game with a lot of overlaid stuff -witht he rest of the game running in mode 2, not mode 1).

 

It's not surprising mode 0 was almost never used, but I'm not sure why more games didn't take advantage from the added detial the 4-color tile layer added with mode 1 compared to mode 2. (more VRAM and/or ROM usage?) For that matter, I wonder why mode 3 wasn't used more, I don't even know of any 2D games using it for in-game stuff. (granted, tiles take up 2x as much space as the 4-bit ones, but I'd think at least soem games could have taken advantage of it's 256 color tile layer -iirc mode 4 had some other problems that limited its use though with the 2nd layer 4-color only, that makes it less desirable as well)

Link to comment
Share on other sites

Console:

GameGen (portable)

Launch Game:

SONMARI!

Add-ons:

Gen 128X - Allows you to play 128 bit games!

Game Flop - A floppy drive! Uselesss!

And...

MiniFridge-Gen - A freakin minifridge!

 

Specs:

64 Megs RAM

128 Meg Hard Drive

No, this isnt a computer.

If this came out, I would piss my pants. With joy.

Price: 150$ for console with no add-ons

Price: 200$ for console with Floppy Drive

Price: 175$ for console plus Mini-Fridge(comes with a FREE DRINK!)

Price: 250$ for console plus 128X

Price: 350$ for console and all add-ons (WITH 2 FREE DRINKS!)

Link to comment
Share on other sites

"as well as matching any 1990 PC at 3D"

 

What was the earliest PC that could run something like "Doom"? Were any PC's in 1990 as powerful as that?

 

Doom didn't come out till 1993 - but I was able to run it on a 386 in a stupidly tiny window :)

'91 isnt it?

 

Anyway here is my system.

Name: Omicron Persie 8 Globulos (Futurama Reference FTW!)

Bits: 128 (suckers) (with attachment to make it OVER 9000! bits)

Game Format: Cartridges shaped like a Brain

Pack-in Game: Allo' Allo' Tournament Fighter

 

-Darren-

Edited by Pyromaniac605
Link to comment
Share on other sites

I'd probably use a good o'le Z80 or some enhanced derivative of that or the 65C816 (like the SNES used) with backward compatibility, and possibly a duplicate memory map to the Apple II or C64 to allow easy porting of it's vast library. As much memory as possible in the price point, with memory expansion capability. A Cartridge slot for games, and some sort of MFM/RLL interface so any PC hard drive or floppy drive could be attached as an add on, as well as a keyboard, PC compatible, of course. Of course, there would need to be a cartridge that you would buy to run the "Disk-OS" type of programs that people would undoubtedly write, and to access the basic commands to format drives, etc.

 

Why all the PC parts? They were relatively cheap and a lot of sources were available for them. Basically I'd make it a closed system unless one bought the "Disk-OS" cartridge, then it would be relatively open like a PC or AppleII was at the time.

 

Thinking back, my C64 was my game console of 1990. Never mind. It was just right.

  • Like 1
Link to comment
Share on other sites

I'd probably use a good o'le Z80 or some enhanced derivative of that or the 65C816 (like the SNES used) with backward compatibility, and possibly a duplicate memory map to the Apple II or C64 to allow easy porting of it's vast library. As much memory as possible in the price point, with memory expansion capability. A Cartridge slot for games, and some sort of MFM/RLL interface so any PC hard drive or floppy drive could be attached as an add on, as well as a keyboard, PC compatible, of course. Of course, there would need to be a cartridge that you would buy to run the "Disk-OS" type of programs that people would undoubtedly write, and to access the basic commands to format drives, etc.

So you're talking about a backwards compatible successor to one of the 8-bit consoles/computers by a 1st part, or a 3rd party approximating compatibility close enough to facilitate easy ports from a popular console? Given the timeline, the latter option wouldn't be that attractive, as the 8-bit systems were aging pretty heavily and many games were ports themselves. Aiming with the capability to port advanced games of the time (from Arcade or newer computers) would have been best, so probably a 68000 based machine in that respect. (and either go the arcade oriented route with emphasis on hardware sprites and tiled background layers, or a blitter based system like the Amiga)

Plenty of other routes if you want to deviate from that though, like Crazyace's proposed Archimedes derivative, which would mean software rendering on a fast (for the time) RISC CPU with relatively little hardware graphics support. (just a bitmap display with multiple resolutions and color depth)

 

 

Thinking back, my C64 was my game console of 1990. Never mind. It was just right.

Are you from Europe? (in North America that would be a bit unusual for the time, but the norm for Europe)

Anyway, that does bring up a interesting idea, a C64 based game console. They tried that of course, but totally messed up, more than Atari's 5200 or XEGS. If CBM had really wanted to release a dedicated game console based on the C64, it would have needed to be incompatible with the C64 cartridges to avoid the problems of lacking a keyboard. Games would be easy to port, but would have to be modified to work without keys. (perhaps good to alloe foe full expansion to a C64 though)

Game controllers could have more than 1 button, and the console should have had a lockout mechanism to allow CBM to regulate (and profit from) 3rd party software. Finally, it would have needed to be released far earlier than the C64GS, 1985/86 would probably be ideal in terms of market conditions.

Such a machine would probably have been pointless in Europe, where 8-bit computers remained the dominant game machines up to the early 90s, but would have made a lot more sense in the US, where consoles really took off again in '86.

 

Going past that, the Amiga could have made a good basis for a game console too. At launch it would have been much too expensive, but by '88 or '89 it might have been practical to release in a stripped down console, again incompatible with the computer counterpart like the C64 example (at least without an expansion unit), so rather like the CD32 as well, just much earlier and cartridge based and probably stripped down to 256 kB. (with games being on ROM cartridges and with no OS loaded to RAM, that shouldn't be quite too limiting, 512 kB might be practical though)

Link to comment
Share on other sites

It's 1990, your designing a game system, what would you do?

 

I'd find out what moronic company hired a 16-year-old to design their next console and short their stock.

 

Well, did any company hire a 16-year old, that your refering too?

 

In 1990, I was 16. I was way underqualified for the job then, and only marginally more qualified now. I don't know what I would have built but I'm pretty sure it would have been a flop.

Link to comment
Share on other sites

It's 1990, your designing a game system, what would you do?

 

I'd find out what moronic company hired a 16-year-old to design their next console and short their stock.

 

Bada bing!

 

 

Well, did any company hire a 16-year old, that your refering too?

 

Woosh!

Link to comment
Share on other sites

To answer the original question - I'd dismember anyone with a butter knife who dared to put Jack Tramiel in charge.

That doesn't make a whole lot of sense in general if you know the proper context of things, but especially given the 1990 date... 1984 perhaps... but that was more warner deciding to ditch atari than Tramiel being the purchaser, either way Morgan wasn't going to get the chance to finish his restructuring of Atari Inc... unless noone offered to buy atari at all.

Link to comment
Share on other sites

To answer the original question - I'd dismember anyone with a butter knife who dared to put Jack Tramiel in charge.

That doesn't make a whole lot of sense in general if you know the proper context of things, but especially given the 1990 date... 1984 perhaps... but that was more warner deciding to ditch atari than Tramiel being the purchaser, either way Morgan wasn't going to get the chance to finish his restructuring of Atari Inc... unless noone offered to buy atari at all.

 

 

I was including his work at Commodore also icon_wink.gif

My point being that it wouldn't matter who was designing or selling a console even in 1990 it would have been suicide putting him anywhere near your company lol

Link to comment
Share on other sites

But wasn't it after Tramiel left that Commodore started running into management problems? Conflicting and unnecessary hardware developments (C128 with the Amiga there, C64GS, etc). Perhaps Jack would have even had the foresight to buy the Amiga corporation outright (something TTL didn't have the resources to do), like with MOS -something it didn't have the re. Though if the Amiga team was as restricted a MOS was as CSG, perhaps that wouldn't have been such a good thing. (granted it wasn't until the Amiga that CSG really started to become a glorified chip vendor for CBM -prior to that, the biggest thing missed out was further development of the 650x architecture, at least they were still developing chipsets, hence the C64)

 

This is getting completely off the topic of the game systems though, except that under Tramiel, I doubt either a C64 or Amiga based game system would have emerged, but considering how much CBM screwed up any such attempts, that point is rather moot.

 

I was including his work at Commodore also icon_wink.gif

My point being that it wouldn't matter who was designing or selling a console even in 1990 it would have been suicide putting him anywhere near your company lol

 

Anyway, in the context of Commodore and 1990, that doesn't make sense either, Jack Tramiel retired from Atari Corp (leaving Sam Tramiel as head of the company), then came back in 1995 after Sam's hear attack and handled the merger with JTS in '96. In the late 1980s and had left Commodore in '84. So the only game systems he was ever involved with at all were the Atari 2600 Jr and 7800 (and Jaguar in the sense that he was there for the discontinuation and liquidation of the company in 1996). I think most of the 2600 Jr and 7800 management was handeled by Mike Katz though, who was certainly qualified for dealing with the game console market. (being involved with Coleco's early systems, the Intellivision, and later handling the launch and first year of marketing for the Sega Genesis -creating the "Genesis Does" advertisements) By the time the Lynx and Jaguar came about, Sam was managing things, and Katz had left for Sega.

All things considered, I think the 2600 Jr and 7800 did pretty well on the market at the time (limited marketing budget, limited game library of the 7800 and heavy competition)

 

So, unless you're talking about Sam Tramiel, I see no reasoning that would suggest Jack Tramiel would be detrimental to a game console. (granted, it wouldn't be a strong point either, but depending on his position I still wouldn't count him out in being part of such a company) If anything, someone like Nolan Busnell would be a bad choice, some the most prominent things he was involved with (atari and Pizza time theater) were extremely unstable while he was managing them, granted, in Atari's case Warner ended up screwing things up too (but not in the same manner he had). Atari Corp was probably a more stable company overall than Atari Inc had been.

Edited by kool kitty89
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...