Jump to content
IGNORED

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


Recommended Posts

@kool_kitty: I think the bus on 63 and 6809 chips is shared, leaving the graphics chips to fetch a lot of data without slowing the CPU. That's what the CoCo 3 appears to do.

 

You are right about the specs being too modest in the color and GFX department. I was still kind of retro, or had moved to PC in the 90's, so I'm a bit out of touch on what was possible console wise.

Yeah, IBM compatibles were generally at a disadvantage compared to consoles (and contemporary home computers) prior to VGA+sound blaster+fast CPUs, namely the early 90s (or some games pushing the envelope in '89/90 and requiring powerful systems to play well at the time -like Wing Commander).

 

However, in spite of its age, the Amiga was still pretty competitive with the 4th generation game consoles (TG-16, Genesis, SNES). It seems a bit of a shame CBM didn't attempt to convert it into a game console earlier on... when they did attempt such entertainment platforms it was a bit later and rather botched (especially the CDTV), the CD32 was probably better given the time, but still old and Commodore was falling apart. (and being barred from the US market certainly didn't help)

 

Moving to bitmap / blitter would have been an interesting direction, and with that in mind, I think I would have done chips that blended the two. One feature I think would be necessary is lower resolution bitmaps, with higher resolution sprites. That way, lots of motion, walls, etc could have some potential to occur, without losing the detail. One could stack the sprites up for hud displays and such, while presenting some 3d to the user at a level of detail that keeps action high.

You don't need hardware sprites at all. The Amiga had them, though rather limited, and ended up doing a lot of "sprites" as blitter objects regardless. (PC and Atari ST had no sprites at all, just software rendering, same for several other computer platforms --Some ST models added a blitter though)

 

The term "sprite" is often used to describe objects in non sprite systems (no hardware sprites) used for characters/objects. Such as the enemies in Wolfenstein or Doom. (or Jazz Jackrabbit, Duke Nukem, Commander Keen, etc)

 

With a blitter system (or CPU/software renderer), you have a bimapped display (framebuffer) in which graphics data is manipulated, no characters/tiles or sprites as with many contemporary consoles and several home computers (Atari, C64).

 

Were large capacity serial EEPROM and RAM devices cheap then? If so, adding the pins for dealing with one in the cart, and having a RAM on the system board would be a very interesting addition. Very large scale projects would be possible, loading in key bits over time.

I'm not sure about that... You could always opt for a direct bus connection (or parallel I/O) expansion port (which is what contemporary consoles did via the cart port and/or expansion ports)

If you wanted EEPROM memory cards, you'd need 24-40 pins depending on the bus width and address space you wanted. (probably not more than 28 pins for an 8-bit data connection)

However, it would likely be simplest to put save memory on the cart instead, using the main data bus and a dedicated address range for save memory. Most common at the time was battery backed SRAM, but that was rather costly, EEPROM should be a much more economical option and Sega did end up using that for several Genesis/MD games, the Jaguar used EEPROM exclusively I believe. (Sega also used a SRAM though, and interestingly FeRAM in a couple games, very odd and exotic for 1994/95, I can only surmise that they got some kind of deal for mass market testing of that memory --indeed there seem to have been reliability issues in games like Sonic 3)

 

 

Just got done reading a bit on the Archimedes... Yeah, that's a compelling idea for sure.

 

At TV graphics resolution, that kind of machine would be bad ass. Doing stuff in software gives a lot of flexibility, and where custom chips provide some good experiences, so can libraries.

Yeah, the general idea was discussed with crazyace on the first couple pages of this thread. A stock 8 MHz Archimedes might be a tad weak, his suggestion was for a 12 MHz ARM2/3. The problem comes with ARM2 not being offered above 8 MHz and ARM3 being much faster, and with cache (so more expensive). The ARM 250 would seem ideal (12 MHz system on a chip including the display and audio hardware), but that didn't come until '92.

 

Of course, given that ARM/Acorn wasn't openly licensing hardware yet in 1990, the whole thing revolves around arranging a contract in the first place, and such might facilitate a CPU catered to such anyway (like a slower, cacheless ARM3), or perhaps mitigate cost of a higher performance system by partnering with ARM/Acorn, assuming they were interested in such a venture. (could be a good way to get their product into the US and expand popularity of the ARM architecture in general)

 

For geeky hardware on something like that, stuff it in the cart!!

Heh, yeah, some later on-cart enhancements might have been good, provisions for expansion on the car lines would be important though. (one limiting factor might be having to decide whether to use a full 32-bit bus on the cart due to the higher cost of more pins, or dropping to 16 data lines for carts)

 

Unlike what some contemporaries did for graphics acceleration on cartridge, specifically the Super FX GSU and Sega's SVP, you likely wouldn't be aiming at that as you're system's already based around a fast RISC CPU. ;) However, with only a simple framebuffer/bitmapped display for graphics, hardware graphics support could be what you'd want on cart. Perhaps a blitter or an ASIC that could handle affine texture rendering. (again, that's where having expansion provisions come in handy)

That, or you could opt for an expansion port more specifically aimed at such expansion, and release a separate add-on cart/card/module for such, so only a 1-time cost (possibly pack-in with the first major game to use it).

 

If you did that, perhaps something a bit more than just affine rendering: polygon rasterization along with affine rendering could really have extended its life span and helped to compete with early 5th generation games. (and port of contemporary PC games)

 

For Doom, polygon rasterization would not be useful, but affine rendering certainly would.

Edited by kool kitty89
Link to comment
Share on other sites

  • 4 weeks later...

Here is what I came up with last night.

 

The main cpu is a Hitachi 6309 clocked at 3.58 Mhz when accessing 64kB work ram and audio/video/controller ports, but 1.79 Mhz while accessing cartridge. Using cheaper slower ROMs can boost the ROM sizes ahead of competators without being more expensive. There is no audio cpu or memory, just an OPL3 and a simple 4 channel wave table that plays from the 6309's 64kB work ram. There is a memory mapper to expand the 6309's memory range. There is DMA for v-ram loading at 3.58 MB per second. Even though the 6309 has an 8-bit bus, the cartridge bus is 16 bits wide, so data can be DMAed at 3.58 MB per second dispite having a 1.79 Mhz cartridge bus.

 

The VDP is where most of the money goes to. It is 21 Mhz, with an 8-bit 64kB video-ram. It outputs a pixel every 3 cycles giving a resolution of 336x224. Each line of active display is about 1024 cycles long. Long enough for there to be 4 normal backgrounds, or 3 tile-per-offset backgrounds, or 1 "mode 7" background + 1 tile-per-offset background. The oam holds 256 sprites, each with optional rotation and scaling. Sprite patterns can be accessed during h-blank, letting 640 sprite pixels per line or 320 rotating sprite pixel per line.

Link to comment
Share on other sites

Here is what I came up with last night.

 

The main cpu is a Hitachi 6309 clocked at 3.58 Mhz when accessing 64kB work ram and audio/video/controller ports, but 1.79 Mhz while accessing cartridge. Using cheaper slower ROMs can boost the ROM sizes ahead of competators without being more expensive. There is no audio cpu or memory, just an OPL3 and a simple 4 channel wave table that plays from the 6309's 64kB work ram. There is a memory mapper to expand the 6309's memory range. There is DMA for v-ram loading at 3.58 MB per second. Even though the 6309 has an 8-bit bus, the cartridge bus is 16 bits wide, so data can be DMAed at 3.58 MB per second dispite having a 1.79 Mhz cartridge bus.

Using slow ROM would severely cripple performance and not necessarily be that much cheaper (there's a range for faster or slower ROMs, but you hit a baseline eventually, and faster roms drop in price as time goes on)

Recall this from a couple pages ago:

It's doing more than fetching from ROM. 99.99999% of code is running from ROM. Thus, all instructions are slower. There's also the problem that you have to access rom in the higher banks of the SNES memory map layout. All lower rom range is still slow access regardless if you turn on the high speed (could allow you to mix fast and slow roms). Or just mirror the lower range with the higher range, though you half your normal cart space (little bit less because "all ram mode" is in the last few banks). Then you have to start using mappers and such for larger carts.

 

Why not just allow for variable ROM access speeds: that's what the SNES did.

If you really wanted to save on memory costs, it would be good to invest in realtime decompression, like some SNES games used on-cart, but implemented on the base unit instead. Also, it could be good to use more RAM and not deal with realtime decompression, but decompress data into RAM during loading periods: a large block of work RAM could thus come in handy (like 256-512 kB), and with a 3.58 MHz CPU with single cycle accesses, you could still be fine with cheap DRAM as you only need 280 ns latency, so FPM DRAM wouldn't even be necessary. (same DRAM speed as the Amiga) For that matter, ROM would be slow in general too: remember the SNES needed memory clocked at 2x the speed of the CPU due to the multiplexed bus, so all games on the SNES would have faster memory than necessary for your system. (not sure about the MD, but it's 16-bit wide bus adds to cost of carts -pin count on the connector and ICs)

 

And 4 channel software controlled PCM is a bit weak... no audio RAM would be needed anyway if samples could be pulled from ROM. However, I think FM synth supplemented by PCM channels would be nice: I'm partial to dual YM2612s. (which would give you the optional use of 2 channels as 8-bit DACs -and better than what Sega did if you connect the interrupt lines to the CPU)

That or a dedicated IC using DMA audio pulling sampled from ROM or RAM. (if RAM, you could compress the samples in ROM an decompress them when loading to RAM and save ROM space)

 

 

The VDP is where most of the money goes to. It is 21 Mhz, with an 8-bit 64kB video-ram. It outputs a pixel every 3 cycles giving a resolution of 336x224. Each line of active display is about 1024 cycles long. Long enough for there to be 4 normal backgrounds, or 3 tile-per-offset backgrounds, or 1 "mode 7" background + 1 tile-per-offset background. The oam holds 256 sprites, each with optional rotation and scaling. Sprite patterns can be accessed during h-blank, letting 640 sprite pixels per line or 320 rotating sprite pixel per line.

Wouldn't it be more useful/flexible to use a fast blitter and framebuffer display instead? (or a mix of the 2, though having both would likely be inefficient)

Link to comment
Share on other sites

Why not just allow for variable ROM access speeds: that's what the SNES did.

Yeah, you could do that. Variably set sections of the external address range with different programmable wait states. But the SNES didn't do that. The SNES simple divider the external memory address in half. The upper "could" be used for faster memory or rom, but the first half is always in slow mode (which I stated in that reply, you just replied to).

 

 

If you really wanted to save on memory costs, it would be good to invest in realtime decompression, like some SNES games used on-cart, but implemented on the base unit instead.

 

Compression is extremely variable in nature. A few changes can lead to size changes that require restructure and such of the rom layout. Not to mention most advance compression routines are sequential in access and need to be decompressed to a buffer to grab something in a the middle of a block. It is doable, and some SFC carts have gone this route(hardware decompression), but overall I don't think it's worth that much. Not to mention that almost all carts from that era for the 16bit consoles, already use compression. Quite a few schemes too. Adding a hardware decompressor isn't going to improve much, if anything, over those existing cart sizes already.

 

Wouldn't it be more useful/flexible to use a fast blitter and framebuffer display instead? (or a mix of the 2, though having both would likely be inefficient)

 

A blitter is going to require two separate buffers (each the size of the screen width/height). Not to mention access to rom (leaving it to a small ram cache would be a terrible idea, but on a console - you might have to do just that). I.e. wait states and/or interleaved access, etc. There's also the fact that a blitter system requires more CPU involvement. It's not as simple as simply updating a single SAT entry. A blitter can be more flexible, but requires much more cpu involved relative to a raster based video compositer.

Edited by malducci
Link to comment
Share on other sites

 

Why not just allow for variable ROM access speeds: that's what the SNES did.

If you really wanted to save on memory costs, it would be good to invest in realtime decompression, like some SNES games used on-cart, but implemented on the base unit instead. Also, it could be good to use more RAM and not deal with realtime decompression, but decompress data into RAM during loading periods: a large block of work RAM could thus come in handy (like 256-512 kB), and with a 3.58 MHz CPU with single cycle accesses, you could still be fine with cheap DRAM as you only need 280 ns latency, so FPM DRAM wouldn't even be necessary. (same DRAM speed as the Amiga) For that matter, ROM would be slow in general too: remember the SNES needed memory clocked at 2x the speed of the CPU due to the multiplexed bus, so all games on the SNES would have faster memory than necessary for your system. (not sure about the MD, but it's 16-bit wide bus adds to cost of carts -pin count on the connector and ICs)

 

And 4 channel software controlled PCM is a bit weak... no audio RAM would be needed anyway if samples could be pulled from ROM. However, I think FM synth supplemented by PCM channels would be nice: I'm partial to dual YM2612s. (which would give you the optional use of 2 channels as 8-bit DACs -and better than what Sega did if you connect the interrupt lines to the CPU)

That or a dedicated IC using DMA audio pulling sampled from ROM or RAM. (if RAM, you could compress the samples in ROM an decompress them when loading to RAM and save ROM space)

 

 

If Snes game ROMs are twice as fast as the cpu, then I guess it would be alright if we just clock the 6309 at 3.58 Mhz while accessing cartridges, unless it is possible to overclock the 6309 at 5.37 Mhz, or use variable ROM accessing speeds between the normal 3.58 Mhz and the overclocked 5.37 Mhz. I've heard people overclocking 6309's at 5 Mhz, I'm not sure about 5.37 Mhz, but it is close.

 

Let me refraise that part about the audio. There is no secondary cpu dedicated to "changing notes" like the Z80 in the Genesis. There is an OPL3 and an extra 4 channel PCM chip. I never said the 4 PCM channels were software controlled.

Link to comment
Share on other sites

If Snes game ROMs are twice as fast as the cpu, then I guess it would be alright if we just clock the 6309 at 3.58 Mhz while accessing cartridges, unless it is possible to overclock the 6309 at 5.37 Mhz, or use variable ROM accessing speeds between the normal 3.58 Mhz and the overclocked 5.37 Mhz. I've heard people overclocking 6309's at 5 Mhz, I'm not sure about 5.37 Mhz, but it is close.

Again, there's also the option of variable ROM speed depending on the game, like allowing the CPU to access at 1.79 MHz, 3.58 MHz, and possibly some in between speeds (depending on the master clock used).

 

Let me refraise that part about the audio. There is no secondary cpu dedicated to "changing notes" like the Z80 in the Genesis. There is an OPL3 and an extra 4 channel PCM chip. I never said the 4 PCM channels were software controlled.

The Z80 isn't dedicated to that in the Genesis, it's just a general purpose CPU and can even be used for game logic. (the main purpose was supplying backwards compatibility) Likewise, the 68k can (and often does) drive audio, the Z80 is most necessary for audio that heavily uses PCM playback, especially software mixing or decompression. (the latter doesn't seem to have been used often in practice, but homebrew projects show that realtime decompression of PCM streams at ratios of 3:1 or 4:1 with rather high quality are reasonable -8:1 is possible, but more limited) Of course, their whole set-up is hindered by the odd decision to not connect the interrupt line from either CPU to the YM2612, thus hindering PCM playback.

 

As for being software controlled, I assumed such as you didn't mentioned another method, like DMA mixing as with the Amiga, STe, Falcon, or Archimedes. (other systems tend use dedicated MCUs/CPUs for controlling PCM playback often in addition to a DSP) There's also set-ups like the PC-Engine's programmable waveforms, more or less mini wavetable (fixed, very small samples) chip.

 

As for the OPL3, I'm not sure, but I think you might be thinking of the OPL4, but that's not limited to 4 channels, was later, and would be quite expensive. I don't think the OPL3 was even available in 1990.

There were Yamaha FM chips with built-in ADPCM decoding, but those tended to be rather costly to implement and were all straight PCM playback afik, no pitch bending or volume control, and in most cases it was only a single channel. (the Neo Geo's YM2610 is the most notable exception with 7 ADPCM channels, but again, I think it's all straight sample playback unless the Z80 is used for pitch manipulation -but I'm not sure how that would work using compressed sample data- that or simply using tons of samples for different notes, as the Neo Geo used tons of ROM)

 

 

For FM chips of the time, you'd have the YM2151, YM2203, YM2608, YM2610, YM2612, YM3526 (OPL), YM3812 (OPL2), YM2413 (OPLL), and perhaps a couple others like the Y8950. (which was more of a custom chip with additional unnecessary features as well as ADPCM). The YM2151, 2612, OPL, and OPL2 all use 24-pin DIP packages.

 

The YM2608 and YM2610 would likely be out due to cost, though maybe the YM2608 would be a possibility (still costly), both use 64 pin DIP or miniDIP packages. The YM2203 has only 3 4-op FM channels plus 3 SSG channels (square wave with envelope control like the YM2149) plus dual 8-bit I/O ports like the 2149 (and 2608) with a 40-pin DIP.

The OPL and OPL2 are pretty similar, with OPL2 with minor enhancements like added waveforms (OPL is limited to sine), both using more limited 2-op FM, and the OPLL is cut down with only 1 programmable instrument at a time, plus a variety of presets, it also doesn't require an external DAC with an 18-pin narrow DIP. (it's pretty limited though, but not bad if it's supplementing separate PCM audio)

The YM2151 is their earliest single chip FM synth implementation and still one of the more capable chips with 8 4-op FM channels, but mono output and need for an external DAC. The YM2612 has 6 4-op FM channels plus an integrated DAC and direct write mode for channel 6, useful for PCM playback. (again, I'm partial to dual YM2612s with CPU driven PCM playback on the 6th channels, short of using custom sound hardware)

 

If you did go with DMA sound, that generally needs more work RAM and/or access to ROM. (with RAM you don't have to worry about ROM speeds and can compress sampled in ROM and decompress them to RAM)

The SNES opted for an advanced custom sound system using compressed samples stored in dedicated RAM (with no access to ROM), using expensive SRAM, a dedicated 650x derived audio controller CPU (SPC700) and 24 MHz DSP driving 8 ADPCM channels of variable sample rate with interpolation and filtering. (unfortunately, interpolation was forced and thus detrimental to some higher quality samples) You could probably rig up a much simpler, less expensive DMA driven set-up either with dedicated or shared DRAM or even add a second CPU (probably another 6309, but preferably not limited to audio alone): the most cost effective set-up for a pure PCM sound system would be 8 DMA audio channels with variable sample rate (say 8-bit resolution like Amiga/STe) with samples read from DRAM (even 512 kB should be cheaper than the SNES's SRAM alone) or possibly shared main memory (which may cut into CPU time).

 

Although, Ricoh also had a decent 8-channel PCM based sound chip (used in the Sega CD, FM Towns, and Sega's System 18 and 32 arcade boards) which may be of interest.

It's off the shelf, not sure about cost though, but roughly comparable for handling most kinds of sound used on the SNES: no interpolation (double edged sword) and no compression, so more memory necessary, but DRAM should be usable, perhaps shared memory, 4-bit stereo panning, pitch, and volume control though using a somewhat uncommon sound format (mix of signed and unsigned data).

Depending on cost, it might be cheaper to go with a simple CPU/MCU driven DAC array. (DMA audio would probably be simpler/cheaper as long as you invested in designing the chip, less flexible than CPU driven audio in some respects)

 

Or again, you could mix PCM and FM: if you ended up with too few PCM/DMA sound channels (ie 4 or even 2) supplementing with an off the shelf chip could help, the YM2413 would likely be the cheapest for FM, though quite simple.

 

 

 

 

But that's all just sound related (except the comment about dual CPU, which could come in handy for software rendering and some other effects). For video, I think a blitter+framebuffer type system would be really useful, especially with some key features like affine line rendering to facilitate scaling/rotation/warping effects, and texture mapping obviously. (the Sega CD's graphics ASIC catered to that) 256 color rendering with variable resolution would probably be good, perhaps a 16-color mode if it was faster for some things. (direct conversion of 4-bit to 8-bit indexed chunky pixel grahpics would be good -saving memory -actual compression of on-cart data would be going a step further, probably most useful for loading between levels/stages) A 12-bit master palette would probably be good enough, though 15-bit would be nice. (18-bit or high probably unnecessary)

You'd definitely want a full 256 color display and decent sized master palette if you wanted to take advantage of the PC game market as suggested earlier.

 

 

I'm still partial to the overall flexibility of crazyaces's suggested Archimedes derivative, but that assumed you could get a license or partnership with Acorn at the time when the ARM CPU wasn't even on the open market iirc. (let alone the Archimedes chipset) It seems fairly feasible that, if not a direct partnership, a licensing agreement might be forthcoming as a game system wouldn't be in direct competition, plus the Archimedes' market was limited to Europe anyway. (in favor of a partnership would be proliferating the new CPU design, possibly opening up strong 3rd party markets for it as well as moving a product into North America and expanding their market in general -the stronger the partnership, the more risk involved for Acorn, of course)

 

 

I like the idea of a more common CPU and powerful, flexible blitter as well though. (one of my early posts in the thread was related to the Sega CD in general, possibly drop the CD drive, add a simple VDC controlling a framebuffer for the ASIC to render into, add necessary I/O hardware, and expand RAM a bit: audio if nothing else)

Link to comment
Share on other sites

Eventhough OPL3 is technically an FM synth, I don't categorize it as such. It's the only FM synth that can use square wave carriers and modulators, and that really adds a lot to the harmonic content to the instruments than the other plain vanilla FM synths. The OPL3 should stand on its own because of that. The OPL3 actually sounds like a synth. I can't believe Yamaha never included square waveforms in their fm synths from the start. I always thought of FM synth as a joke as the only alternative to PCM, Yamaha kept milking.

Link to comment
Share on other sites

Eventhough OPL3 is technically an FM synth, I don't categorize it as such. It's the only FM synth that can use square wave carriers and modulators, and that really adds a lot to the harmonic content to the instruments than the other plain vanilla FM synths. The OPL3 should stand on its own because of that. The OPL3 actually sounds like a synth. I can't believe Yamaha never included square waveforms in their fm synths from the start. I always thought of FM synth as a joke as the only alternative to PCM, Yamaha kept milking.

 

Well that depends doesn't it? It's only 2 operator FM synth without pairing and you can create a square wave with 2 sine operators with 4-op FM and have 2 more operators to use as well. (but in 4-op mode, the OPL3 might be more useful)

Relatively few games seem to really take advantage of the OPL3 though, or SB-16's higher quality digital sound either. (the best sound would not be from an actual SB-16, but some 3rd party compatibles or later, backward compatible creative cards -the SB-16 has crappy analog circuitry, though not as bad as the early SB cards)

 

You also get stereo panning, of course, compared to OPL/OPL2 or YM2151, but 2x YM2612s would be more capable overall I think. (12 4-op FM channels vs a max of 6 4-op plus 6 2-op for the OPL3) Except for cases where using the OPL3's added waveforms in addition to 4-op synth. A single OPL3 would beat a single YM2612, of course, unless you needed the direct DAC mode the 2612 offers.

Of course, the YM2612 was available earlier too. (and is certainly more capable for most things than the OPL2 or OPL -not to mention OPLL, in spite of the fewer channels)

 

But again, I don't think the OPL3 would have even been available at the time, so of the other choices: the lower cost ones mainly being the OPL/OPL2/OPLL, YM2612, and possibly the YM2151, the YM2612 is the only one with stereo support or the direct 8-bit DAC mode (and only the 2612 and 2413 don't need external DACs). If you don't care about stereo, the YM2151 is the best (though I'm not sure how inexpensive it was) and OPLs are rather weak with 2-op FM and all 3 need DACs; the OPLL is rather weak in general. (not too bad as a simple supplementary chip to go with some PCM channels -though one of the others would be even better -again I rather like the dual YM2612 set-up with 2 optional DAC channels)

Link to comment
Share on other sites

Hey, I just found that something which a lot of people are suggesting here - an early 90s console based on PC hardware - actually existed, in Japan:

 

FM Towns Marty

Looks interesting. I can't get past that name, 3 words that make no sense next to each other.. I guess it means something to the Japanese.

The setup looks very much like our first PC, which was sadly underpowered for most games I played on it. The 386SX-16 sucks, 386DX-25MHz would be my pick but I don't know what those cost.

Edited by gdement
Link to comment
Share on other sites

Hey, I just found that something which a lot of people are suggesting here - an early 90s console based on PC hardware - actually existed, in Japan:

 

FM Towns Marty

Looks interesting. I can't get past that name, 3 words that make no sense next to each other.. I guess it means something to the Japanese.

The setup looks very much like our first PC, which was sadly underpowered for most games I played on it. The 386SX-16 sucks, 386DX-25MHz would be my pick but I don't know what those cost.

 

The Wikipedia explanation for the first two-thirds of the name makes sense:

 

"The name "FM Towns" is derived from the codename the system was assigned while in development, "Townes"; this was chosen as an homage to Charles Hard Townes, one of the winners of the 1964 Nobel Prize in Physics, following a custom of Fujitsu at the time to codename PC products after Nobel prize winners. >The e in "Townes" was dropped when the system went into production to make it clear that it was to be pronounced "Towns" rather than "Tau-Ness", and the "FM", which stood for "Fujitsu Micro[computer]".[citation needed]"

 

I still don't get the "Marty" part.

 

The two most powerful consoles of their generation... how does Marty stack up against Neo Geo? Just from a cursory examination of their specs, seems like the Neo has the better color palette while the Marty has lots of other advantages such as the faster 32-bit processor, higher resolution and more memory.

Edited by mbd30
Link to comment
Share on other sites

The FM Towns was more than a PC though, it was PC compatible (to soem extent) and used a 386SX CPU, but had a TON of custom graphics hardware as well as a YM2612 (FM chip used in the Genesis and several arcade games) and 8-channel Ricoh PCM synth chip also used in several Arcade arcade games and the Sega CD. (Silpheed on the Sega CD is one of the better examples of that combo -granted it had the Genesis's 3 channel PSG too)

 

It was very expensive for a console (granted a lot of stuff was pricier in Japan, but think 3DO) and really more of a high-end competitor to the SNES, PC Engine, and Mega Drive (and Neo Geo). (some put it in with the 5th gen consoles as it uses a 32-bit CPU) There's also conflicting info on the release date, namely 1991 vs 1993. (more Japanese sites seem to agree with 1993) Regardless, the FM Towns computer was released in 1989.

 

If you're looking for a PC based console, there's Tandy's Video information system http://en.wikipedia.org/wiki/Tandy_Video_Information_System

 

If you wanted a PC based architecture that would facilitate straight ports of PC games, it would probably need an embedded VGA chipset and a CPU fast enough to handle software rendering fairy well. A fast 286 probably wouldn't be able to keep up (though probably a fair bit more cost effective than a 386SX -especially a 25 MHz 286), in the early 90s, the best power for reasonable cost would probably be an AM386, IBM 386SLC, or slightly later Cyrix 486SLC (the latter 2 using smaller packages with 16 bit data and 24-bit address buses, but onboard caching compared to none on the AM386). 486s would be too expsnesive and you'd have to get a good deal one one of the others to really have any chance at good price compeition. All of that is far less cost effective than going with a custom graphics architecture (be it blitter or sprite/tile based) or using software rendering with low-cost RISC cpu. (by the time with 486SLC was out, the very low-cost ARM60 was available -and Acorn had produced the ARM250 system on a chip)

 

But this was originally in the context of 1990, and not all of that would have been available: though a company could have approached Acorn with such a proposal to use the ARM CPU. (the PC idea really isn't that cost effective) Even later on with 3D coming in, prior to 3D acceleration you'd be well behind cost/performance of RISC designs. (by the mid 90s you have the MIPS R3000, Hitachi SH2, ARM7, going higher there's R4200/4300 and R4600, then the power PC 603 all aimed at the embedded market and all with higher cost/performance ratios than most contemporary X86 CPUs) The AM5x86 was probably the lest expensive x86 CPU with reasonably performance, but still probably a fair bit lower cost/performance. (and Cyrix's 5x86 would have probably been more expensive than embedded RISC CPUs of comparable performance)

 

 

Now, back to 1990: for PCs there were 2D accelerators starting to become popular for windows, but I don't think many games took advantage of that hardware. (so it makes the point a bit moot)

 

 

 

Of course, the discussion differs entirely if you're talking about a console being developed IN 1990 or FOR 1990. (the Jaguar had the main portion of its design laid down on paper in 1990, granted that was an ambitious and advanced design being built on a limited budget -a simpler design would have been less long term, particularly with more funding, but still probably no less than a year -unless you go with the software rendering and 3rd party chip/partnership idea - or take the Acorn chipset directly)

Edited by kool kitty89
Link to comment
Share on other sites

 

Well that depends doesn't it? It's only 2 operator FM synth without pairing and you can create a square wave with 2 sine operators with 4-op FM and have 2 more operators to use as well. (but in 4-op mode, the OPL3 might be more useful)

Relatively few games seem to really take advantage of the OPL3 though, or SB-16's higher quality digital sound either. (the best sound would not be from an actual SB-16, but some 3rd party compatibles or later, backward compatible creative cards -the SB-16 has crappy analog circuitry, though not as bad as the early SB cards)

 

You'll need more than 2 modulators. Here's a chart showing a square built from sinewaves - http://www.fly.net/~ant/bl-synth/4.harmonics.html

 

For really high frequency, two carriers might cut it - but that's still kinda sloppy for a square waveform. But 18 channel OPL3 chip is more capable than the 2612 (although you need some macros to really get the most out of the opl3). The fact that you can modulate with the other waveforms is nice, among some other features. 18 channels sound like a lot, but you can divide the 2612 into 12 2op channels (if you don't use channel six for direct DAC writes). The opl3 has a feature where you can freeze a carrier (there's 36 carriers total on the chip) in place and use the volume control as a DAC (a PC pinball game did this). Not the best DAC output, but still interesting.

Link to comment
Share on other sites

The two most powerful consoles of their generation... how does Marty stack up against Neo Geo? Just from a cursory examination of their specs, seems like the Neo has the better color palette while the Marty has lots of other advantages such as the faster 32-bit processor, higher resolution and more memory.

 

Actually I'd say the other way around: the Neo Geo's main advantage is memory (in terms of massive, fast ROMs -or DRAM in the Neo CD) The FM towns has a decent amount of RAM though. (the rendering mechanisms differ too -the Neo Geo is all sprite of course)

The FM Towns definitely has more colors, depending on the video mode used. (several indexed modes using 24-bit entries -true color master palette- but I'd imagien the highcolor mode is direct 15-bit RGB only) Higher resolution is also supported, but as a games console, I'd imagine it would stick to TV resolutions.

The Neo also supports hardware sprite zooming while the FM Towns has to use software scaling I believe. (though it still manages some of the best home ports of Galaxy Force and Thunder Blade prior to the Saturn versions)

 

Wiki's FM towns page provides a bit more info on the video than the marty article http://en.wikipedia.org/wiki/FM_Towns (granted the high res modes aren't useful for TV display -I don't think interlace was normally used either)

 

The X68000 would probably have been much more cost-effective to repurpose as a console.

 

 

You'll need more than 2 modulators. Here's a chart showing a square built from sinewaves - http://www.fly.net/~ant/bl-synth/4.harmonics.html

Maybe my understanding is too limited, but that looks like it's simple additive synthesis using sine waves not FM.

 

For really high frequency, two carriers might cut it - but that's still kinda sloppy for a square waveform.

If you want pure square waves you could use a PSG too, the Genesis has a SN76489 derivative embedded in its VDP (as did the SMS, the SG-1000 had it discrete), but that's not useful for FM synth using those waveforms. (just additive synth, or straight square waves) Of course, several yamaha chips have SSG channels built-in (SSG refering to square wave+envelope control such as the AY-3-8910/YM2149, so better than the SN76489). The OPN family, except for the OPN2 (YM2612) have the 3 SSG channels liek the YM2149: that's the YM2203 (3 added 4-op FM), YM2608 (6 FM, 6 rhythm, 1 ADPCM), YM2610 (4 FM, 6+1 ADPCM, used in Neo Geo). Again, those wouldn't be useful for actual FM synth though.

 

Is the OPL3's Square wave limited to plain square or variable pulse width?

 

But 18 channel OPL3 chip is more capable than the 2612 (although you need some macros to really get the most out of the opl3). The fact that you can modulate with the other waveforms is nice, among some other features. 18 channels sound like a lot, but you can divide the 2612 into 12 2op channels (if you don't use channel six for direct DAC writes). The opl3 has a feature where you can freeze a carrier (there's 36 carriers total on the chip) in place and use the volume control as a DAC (a PC pinball game did this). Not the best DAC output, but still interesting.

The OPL2 also featured FM synth with more than just sine, right? (but not square -didn't OPL3 also feature logarithmic sawtooth?) Are all of Yamaha's chips outside the OPL family limited to sine only for modulator waveforms?

 

The YM2612 can really be used as 12 independent 2-op FM voices? (is it limited to 5 4-op channels only with channel 6's direct write mode, or 10 2-op channels) Did any other 4-op yamaha chips support 2-op modes like that? (YM2151, others in the OPN faimly, etc)

 

Interesting on that carrier freezing feature, can multiple carriers be frozen (and would that improve quality)? How would that method compare to using the square wave channels of a YM2612 or SN76489? (usually using all 3 square wave channels, preferably taking proper advantage of the log based volume -compared to linear on POKEY or the NES's square/pulse channels -there's PWM too, but that's more processor intensive)

 

Does the OPL3 have built-in timers like the YM2612 (and an IRQ line) which could facilitate PCM timing. (something that oddly wasn't done on the Genesis -and has been brought up by several programmers on Sega-16)

Edited by kool kitty89
Link to comment
Share on other sites

You'll need more than 2 modulators. Here's a chart showing a square built from sinewaves - http://www.fly.net/~ant/bl-synth/4.harmonics.html

Maybe my understanding is too limited, but that looks like it's simple additive synthesis using sine waves not FM.

 

Kinda. All amplitudes add (amplitudes are signed, so they subtract too). Anyway, the chart shows using just two sinewaves, in comparison to using 3 or 4. Two doesn't really cut it IMO, especially for mid range (and lower) frequencies.

 

If you want pure square waves you could use a PSG too, the Genesis has a SN76489 derivative embedded in its VDP (as did the SMS, the SG-1000 had it discrete), but that's not useful for FM synth using those waveforms.

 

PSG is limited in range for the SN76489 variant. With 10bit precision, you're limited in range before you start getting out of tune frequencies (which is most SMS games have a limited frequency range for notes/music compared to the NES). If you wanted a square output with finer control, adding sinewaves from multiple carriers on the FM chip would be better (which I believe TmEE does for some of his square lead stuff).

 

 

Is the OPL3's Square wave limited to plain square or variable pulse width?

 

50% duty cycle. But it has more than just square waveform support (saw and something else too).

 

The OPL2 also featured FM synth with more than just sine, right? (but not square -didn't OPL3 also feature logarithmic sawtooth?) Are all of Yamaha's chips outside the OPL family limited to sine only for modulator waveforms?

 

Hmm. I don't remember specifically about the OPL2 waveforms. I want to say it had more than just sine, but I can't specifically recall.

 

The YM2612 can really be used as 12 independent 2-op FM voices? (is it limited to 5 4-op channels only with channel 6's direct write mode, or 10 2-op channels) Did any other 4-op yamaha chips support 2-op modes like that? (YM2151, others in the OPN faimly, etc)

 

Yes. See the algo's here - http://www.smspower.org/maxim/Documents/YM2612#page3 . Algo #4 sets up as two 2-op modes in a single channel.

 

Interesting on that carrier freezing feature, can multiple carriers be frozen (and would that improve quality)? How would that method compare to using the square wave channels of a YM2612 or SN76489? (usually using all 3 square wave channels, preferably taking proper advantage of the log based volume -compared to linear on POKEY or the NES's square/pulse channels -there's PWM too, but that's more processor intensive)

 

IIRC, it's better than 4bit linear PCM (it's either 8 or 7 bit non linear PCM). I'll have to track down the game and record some samples from DOSBOX to see.

 

Does the OPL3 have built-in timers like the YM2612 (and an IRQ line) which could facilitate PCM timing. (something that oddly wasn't done on the Genesis -and has been brought up by several programmers on Sega-16)

 

Not that I know of. It's mostly used in PCs, which already have a ~20khz timer.

Edited by malducci
Link to comment
Share on other sites

Kinda. All amplitudes add (amplitudes are signed, so they subtract too). Anyway, the chart shows using just two sinewaves, in comparison to using 3 or 4. Two doesn't really cut it IMO, especially for mid range (and lower) frequencies.

It may not be good as a direct replacement for a square wave, but it's an interesting sound in its own right.

 

PSG is limited in range for the SN76489 variant. With 10bit precision, you're limited in range before you start getting out of tune frequencies (which is most SMS games have a limited frequency range for notes/music compared to the NES). If you wanted a square output with finer control, adding sinewaves from multiple carriers on the FM chip would be better (which I believe TmEE does for some of his square lead stuff).

AY-3-8910 (and related Yamaha YM2149 and other chips with SSG) have a wider range, right? (12-bit)

 

 

50% duty cycle. But it has more than just square waveform support (saw and something else too).

...

Hmm. I don't remember specifically about the OPL2 waveforms. I want to say it had more than just sine, but I can't specifically recall.

If wikipedia's descriptions are accurate, the other added waveforms (in addition to square and saw) for the OPL3 are camel sine and alternating sine.

For the OPL2, the waveforms listed are sine, half sine, absolute sine, and quarter sine. (I assume the OPL3 has those available as well) I believe the OPL is only sine, and OPLL is similar to OPL2, but cut to 1 user programmable instrument at a time. (and 15 presets)

 

Yes. See the algo's here - http://www.smspower.org/maxim/Documents/YM2612#page3 . Algo #4 sets up as two 2-op modes in a single channel.

OK, but that configuration would still limit those 2x 2-op voices together for that FM channel when using the hard panning stereo or controlling volume, right? For the YM2151 or YM2203, the stereo would be a non-issue. (those are mono only)

 

IIRC, it's better than 4bit linear PCM (it's either 8 or 7 bit non linear PCM). I'll have to track down the game and record some samples from DOSBOX to see.

For the AY-3-8910/YM2149, I've heard that proper conversion taking advantage of all 3 channels and the non-linear (logarithmic) volume could allow (approximate) 8-bit resolution sample playback. (Crazyace mentioned that in the context of the ST in particular -and commented that it definitely could do better than a 4-bit linear DAC like in POKEY -though I'd imagine using a single YM2149 channel would sound worse -or playback not fully optimized for the log-based volume; though for POKEY you have timers and an IRQ line to help with PCM sample timing)

 

Not that I know of. It's mostly used in PCs, which already have a ~20khz timer.

Yes, but in that context the point is already moot as all implementations on the PC should be for Soundblaster Pro/16 and compatible cards which already have dedicated DACs for PCM playback and a microcontroller (with ADPCM decoding).

Though if the OPL2 has a similar carrier hold feature that could have been useful for Adlib cards. (rather than using PWM on the PC speaker) But both the OPL2 and OPL3 require external DACs too, so maybe it would be possible to write directly to that. (though I think the Yamaha DACs used a serial data input, so that wouldn't be so straightforward)

Edited by kool kitty89
Link to comment
Share on other sites

Kinda. All amplitudes add (amplitudes are signed, so they subtract too). Anyway, the chart shows using just two sinewaves, in comparison to using 3 or 4. Two doesn't really cut it IMO, especially for mid range (and lower) frequencies.

It may not be good as a direct replacement for a square wave, but it's an interesting sound in its own right.

 

Algo #7 allows for a finer resolution square wave implementation. But you're right, two channel method is different enough from a normal unmodified sinewave for sharper frequency response like normal square wave.

 

 

AY-3-8910 (and related Yamaha YM2149 and other chips with SSG) have a wider range, right? (12-bit)

 

I don't know.

 

Yes. See the algo's here - http://www.smspower.org/maxim/Documents/YM2612#page3 . Algo #4 sets up as two 2-op modes in a single channel.

 

OK, but that configuration would still limit those 2x 2-op voices together for that FM channel when using the hard panning stereo or controlling volume, right? For the YM2151 or YM2203, the stereo would be a non-issue. (those are mono only)

 

Yes. Stereo panning is limited to the "channel", not the carriers. But you still have ADSR, master volume control, and frequency period (notes) over each one, so it's still equivalent to, two audio channels. You can take it further and have 4 channels per "channel". But you'd only have sine as the output (you still have ADSR, master volume, period control). Sine by itself is kinda bland, but you could technically have up to 24 plain sinewave channels just for the FM chip if you wanted (Algo #7). Would have been great if more waveforms were selectable. It would make that option *much* more useful.

 

 

Yes, but in that context the point is already moot as all implementations on the PC should be for Soundblaster Pro/16 and compatible cards which already have dedicated DACs for PCM playback and a microcontroller (with ADPCM decoding).

Though if the OPL2 has a similar carrier hold feature that could have been useful for Adlib cards. (rather than using PWM on the PC speaker) But both the OPL2 and OPL3 require external DACs too, so maybe it would be possible to write directly to that. (though I think the Yamaha DACs used a serial data input, so that wouldn't be so straightforward)

 

Well, having an external DAC vs an internal DAC is irrelevant. Either way, all channels are put together with an ADDER (and possibly clipped), before being sent to the DAC. The hardware could have been made to pass direct writes to the internal data register (the channel sample buffer) if it's internal or external, because it would be added in, in place of the original channel sample hold/buffer.

Link to comment
Share on other sites

Yes. Stereo panning is limited to the "channel", not the carriers. But you still have ADSR, master volume control, and frequency period (notes) over each one, so it's still equivalent to, two audio channels. You can take it further and have 4 channels per "channel". But you'd only have sine as the output (you still have ADSR, master volume, period control). Sine by itself is kinda bland, but you could technically have up to 24 plain sinewave channels just for the FM chip if you wanted (Algo #7). Would have been great if more waveforms were selectable. It would make that option *much* more useful.

Does the OPL3 have an algorithm using the individual carriers/operators as separate voices? (like algo 7 in the YM2612) Or the OPL2 for that matter. (less useful, but still more than just sine -1/2, 1/4, and absolute sine)

Link to comment
Share on other sites

Yes. Stereo panning is limited to the "channel", not the carriers. But you still have ADSR, master volume control, and frequency period (notes) over each one, so it's still equivalent to, two audio channels. You can take it further and have 4 channels per "channel". But you'd only have sine as the output (you still have ADSR, master volume, period control). Sine by itself is kinda bland, but you could technically have up to 24 plain sinewave channels just for the FM chip if you wanted (Algo #7). Would have been great if more waveforms were selectable. It would make that option *much* more useful.

Does the OPL3 have an algorithm using the individual carriers/operators as separate voices? (like algo 7 in the YM2612) Or the OPL2 for that matter. (less useful, but still more than just sine -1/2, 1/4, and absolute sine)

 

Yes. Both OPL2 and OPL3. It's additive synthesis, but if you treat the carriers separately in that mode, then it's the same as separate channels (the reverse is also true for systems like the PCE where they can do additive synthesis by combining 2 or more channels in unison). In other words, it's additive synthesis because you use it as such - else it's not.

 

Here are some docs:

http://www.gamedev.net/reference/articles/article447.asp

http://www.oplx.com/opl3/docs/ymf262.pdf

 

For OPL3, you'd define a channel as 2op mode, then use all 4 operators as single channels (and select from 8 waveforms).

 

OPL2 waveforms:

         WaveForm 0: Sine                WaveForm 1: Half-Sine
         ³ /~\                           ³ /~\         /~\
         ³/   \       /                  ³/   \       /   \
        Ä/ÄÄÄÄÄ\ÄÄÄÄÄ/ÄÄ                ÄÅÄÄÄÄÄÁ-----ÁÄÄÄÄÄÁÄ
         ³      \   /                    ³
         ³       \_/                     ³

        WaveForm 2: Abs-Sine            WaveForm 3: Pulse-Sine
         ³ /~\   /~\                     ³ /~|         /~|
         ³/   \ /   \ /                  ³/  |        /  |
        ÄÅÄÄÄÄÄÁÄÄÄÄÄÁÄÄ                ÄÅÄÄÄÁ-------ÁÄÄÄÁÄÄÄ
         ³                               ³
         ³                               ³

OPL3 extended waveforms:

         WaveForm 4: Sine - even periods only
         ³ /~\                     /~\
         ³/   \                   /   \
        ÄÅÄÄÄÄÄ\ÄÄÄÄÄÂ-----------ÁÄÄÄÄÄ\ÄÄÄÄÄÂÄ
         ³      \   /                   \   /
         ³       \_/                     \_/

        WaveForm 5: Abs-Sine - even periods only
         ³ /~\   /~\               /~\   /~\
         ³/   \ /   \             /   \ /   \
        ÄÅÄÄÄÄÄÁÄÄÄÄÄÁ-----------ÁÄÄÄÄÄÁÄÄÄÄÄÁÄ
         ³
         ³

        WaveForm 6: Square
         ³-----¿     Ú-----¿     Ú-----¿     Ú-
         ³     |     |     |     |     |     |
        ÄÅÄÄÄÄÄ|ÄÄÄÄÄ|ÄÄÄÄÄ|ÄÄÄÄÄ|ÄÄÄÄÄ|ÄÄÄÄÄ|ÄÄ
         ³     |     |     |     |     |     |
         ³     À-----Ù     À-----Ù     À-----Ù

        WaveForm 7: Derived Square
         ³          |\                |\
         ³         |  \              |  \
        ÄÅ--__ÄÄÄÄ|ÄÄÄÄ~~-----__ÄÄÄÄ|ÄÄÄÄ~~-----
         ³    \  |              \  |
         ³     \|                \|

Link to comment
Share on other sites

  • 4 years later...

I personally think moving away from sprite+tile based systems and going for a more flexible (blitter or CPU) approach is a good direction to move in.

 

Exactly. You just cannot design a console specifically for 2D scrolling games with some sprites... It's 1990 not 1980... I am not quite sure but something like Atari Jaguar might be the answer.

Link to comment
Share on other sites

Basically, the X68000. Or a less-neutered version of Sega's current (at the time) arcade hardware than the Genesis turned out to be.

 

Something X68000-like, at any rate. Carts. Expandability. 12MHz+ CPU. 4MB RAM. Should be able to crank out some primitive but playable 3D.

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...