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

[Zonie]

No, I am not. I was using my C64 until I got my first PC in 1990, however.

 

What I was trying to say, the C64 was a perfect gaming machine as it was.

 

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

Are you from Europe?

[kool kitty89]

No, I am not. I was using my C64 until I got my first PC in 1990, however.

 

What I was trying to say, the C64 was a perfect gaming machine as it was.

 

I wasn't really trying to imply anything by the Europe comment, just a bit curious (I mean, such would be much more common in that case), It's into totally surprising though, I mean the C64 was a very popular platform in the US, it just seems like it was a bit more unusual for it to remain one's mainstay game system into the early 90s, unless of course one was a late adopter and/or focused more on the budget titles. (which is pretty much what happened with my family)

 

However, one other thing int eh case of Europe was that the "video game" market, and "computer game" market were (especially with the latter referrign to PC games more and more), for the most part, much more separated than in the case with Europe in the 80s and early 90s. Such that, in the context of this discussion, of a commercial game console, the C64, as it was, doesn't mesh entirely with that market from a business point of view. That's what lead me into that tangent about the C64 GS, followed by the Amiga. (admittedly, that doesn't have much to do with a good 1990 console though as the C64 was most definitely not a good basis for a newly released console in 1990; '86 being a better time for that; hence the Amiga comments)

[Multijointed Monster Maker]

I like the idea of consolized Atari Lynx.

 

Handheld Atari Lynx specs-

 

cpu: 3.58Mhz 6502

resolution: 160x104

colors: 16 out of 4096

ram: 16 kB

 

Console Atari Lynx specs-

 

cpu: 3.58Mhz 65816

resolution: 256x224

colors: 256 out of 32876

ram: 128 kB

[Inky]

I'd grab a handful of random chips, plug A TV into it, shake it up, and hope for the best.

[kool kitty89]

I like the idea of consolized Atari Lynx.

 

Handheld Atari Lynx specs-

 

cpu: 3.58Mhz 6502

resolution: 160x104

colors: 16 out of 4096

ram: 16 kB

 

Console Atari Lynx specs-

 

cpu: 3.58Mhz 65816

resolution: 256x224

colors: 256 out of 32876

ram: 128 kB

 

The Lynx has 64 kB of DRAM in it, not 16 kB, which is good since that's the only memory the CPU can access directly (data had to load from ROM into RAM -due to the console originally being designed to load from tape iirc) Also, it's a 65C02.

 

Going console and with a 65816, you could probably go up to at least 256 kB. (it is DRAM after all, and shared memory)

But for the display, I'm not sure how the chipset would have handled higher resolutions (or higher color depth), not sure if higher clock speeds would have been possible -which should have helped for some things. Sound hardware would need to be beefed up though, simplest is probably adding a Yamaha FM synthesis chip. (various available, several in the low-cost range)

 

 

I'm pretty sure that if the Lynx could have been adapted into a home console they'd have tried it though. It was a pretty low cost design for that market, so would have fit pretty well in line; if decently high resolutions were possible (at least 256x192, 320x224 would be nice) and the hardware was powerful enough to make smooth games at that then it could be a good idea for the time; probably at a fair disadvantage to the SNES and Genesis (with some trade-offs), but definitely at a cost advantage. Otherwise an ST derived console (with the BLiTTER) would probably have been better -though a bit weal for 1990. (the Panther was not a good option in the cost range they wanted -with a dual bus design and at leat 64 kB of SRAM, maybe it would have been nice, but that's way past the cost range Atari wanted for it -granted contemporary consoles had that much SRAM, and more -perhaps not as fast rated though)

[Multijointed Monster Maker]

I like the idea of consolized Atari Lynx.

 

Handheld Atari Lynx specs-

 

cpu: 3.58Mhz 6502

resolution: 160x104

colors: 16 out of 4096

ram: 16 kB

 

Console Atari Lynx specs-

 

cpu: 3.58Mhz 65816

resolution: 256x224

colors: 256 out of 32876

ram: 128 kB

 

The Lynx has 64 kB of DRAM in it, not 16 kB, which is good since that's the only memory the CPU can access directly (data had to load from ROM into RAM -due to the console originally being designed to load from tape iirc) Also, it's a 65C02.

 

Going console and with a 65816, you could probably go up to at least 256 kB. (it is DRAM after all, and shared memory)

But for the display, I'm not sure how the chipset would have handled higher resolutions (or higher color depth), not sure if higher clock speeds would have been possible -which should have helped for some things. Sound hardware would need to be beefed up though, simplest is probably adding a Yamaha FM synthesis chip. (various available, several in the low-cost range)

 

 

I'm pretty sure that if the Lynx could have been adapted into a home console they'd have tried it though. It was a pretty low cost design for that market, so would have fit pretty well in line; if decently high resolutions were possible (at least 256x192, 320x224 would be nice) and the hardware was powerful enough to make smooth games at that then it could be a good idea for the time; probably at a fair disadvantage to the SNES and Genesis (with some trade-offs), but definitely at a cost advantage. Otherwise an ST derived console (with the BLiTTER) would probably have been better -though a bit weal for 1990. (the Panther was not a good option in the cost range they wanted -with a dual bus design and at leat 64 kB of SRAM, maybe it would have been nice, but that's way past the cost range Atari wanted for it -granted contemporary consoles had that much SRAM, and more -perhaps not as fast rated though)

 

What exactly is the pixel fill rate for the atari lynx?

[malducci]

I like the idea of consolized Atari Lynx.

 

Handheld Atari Lynx specs-

 

cpu: 3.58Mhz 6502

resolution: 160x104

colors: 16 out of 4096

ram: 16 kB

 

Console Atari Lynx specs-

 

cpu: 3.58Mhz 65816

resolution: 256x224

colors: 256 out of 32876

ram: 128 kB

 

You realize that the '816 requires twice the ROM/RAM speed as the 65c02 even though both are 3.5mhz, right? It has a multiplexed address and is the stupidest thing ever (that they didn't release a full pin package version without the over head and need for faster rom). It's one of the reasons why the SNES cpu runs as slow as it does. ROM speed costs.

 

I would personally take Rockwell's R65C02 (over the plain 'c02) at twice the speed (7.159mhz) than that regular ol' '816 at half speed. You could even add onto Rockwell's design like Hudson did (and mitsubishi did). The 65CE02 or clone of would have been an excellent choice too.

[kool kitty89]

You realize that the '816 requires twice the ROM/RAM speed as the 65c02 even though both are 3.5mhz, right? It has a multiplexed address and is the stupidest thing ever (that they didn't release a full pin package version without the over head and need for faster rom). It's one of the reasons why the SNES cpu runs as slow as it does. ROM speed costs.

 

I would personally take Rockwell's R65C02 (over the plain 'c02) at twice the speed (7.159mhz) than that regular ol' '816 at half speed. You could even add onto Rockwell's design like Hudson did (and mitsubishi did). The 65CE02 or clone of would have been an excellent choice too.

 

Huh, that's something I didn't know. That goes for RAM too, right? Still, that doesn't explain why the SNES runs THAT slowly, especially since it runs at only 2.68 MHz when accessing DRAM and often ROM as well. (ROM can be either 2.68 or 3.58 -I think switching to 3.58 MHz ROM on some games contributed to reduced slowdown too) Unless they decided to go with fairly slow DRAM, like 180-200 ns (for that 2.68 MHz value), had they gone with 100 ns DRAM (which should be reasonable for 1990), I don't see why the CPU couldn't have been clocked at 4.3 or perhaps 5.37 MHz (from the 21.48 MHz master clock) -along with the variable speed bus. (for slower/cheaper ROMs) The SNES isn't even 1/2 the speed of the PC Engine or MD, and the latter had to use double the data lines for ROM as well. (granted neither of those used plain DRAM for main memory -the MD used PSRAM and the PCE used SRAM)

 

Hmm, did the 8086/8088 have that same problem?

 

They could have gone with a faster 65C02 derivative and implemented a bankswitching scheme to extend the address bus, either with external logic or integrated in a custom CPU package. (I believe did that for the PC-engine, with a 21-bit address) At very least they should have allowed separate ROM/RAM bank selection rather than having to treat ROM as secondary storage, not directly accessible by the CPU. (I assume due to the original intention of the console being cassette based)

 

IIRC the 65C02 family didn't get some of the enhancements of the '816 which facilitated more efficient use of high-level languages like C, though that wouldn't have been too much of a problem with the Lynx existing in a time where games were programmed primarily in assembly language. (it wasn't until the next generation that coding in C became a major factor for game consoles)

[malducci]

Huh, that's something I didn't know. That goes for RAM too, right? Still, that doesn't explain why the SNES runs THAT slowly, especially since it runs at only 2.68 MHz when accessing DRAM and often ROM as well. (ROM can be either 2.68 or 3.58 -I think switching to 3.58 MHz ROM on some games contributed to reduced slowdown too) Unless they decided to go with fairly slow DRAM, like 180-200 ns (for that 2.68 MHz value), had they gone with 100 ns DRAM (which should be reasonable for 1990), I don't see why the CPU couldn't have been clocked at 4.3 or perhaps 5.37 MHz (from the 21.48 MHz master clock) -along with the variable speed bus. (for slower/cheaper ROMs) The SNES isn't even 1/2 the speed of the PC Engine or MD, and the latter had to use double the data lines for ROM as well. (granted neither of those used plain DRAM for main memory -the MD used PSRAM and the PCE used SRAM)

 

It goes for anything on the bus. The 65816 is missing the upper address lines, so externally you only have 64k of address lines. To overcome this, the multiplexed the upper address lines on the data bus. So what would normally be 1 complete memory cycle, is now 1/2 + 1/2. 1/2 the memory cycle you take the data bus and store it in a simple register latch (external or on the die/package), then on the second 1/2 cycle you use the 16 address lines of the normal 6502 pins and the 8 from the latch to form a 24bit address line, you then read in the contents from the data bus. But the problem there in lies, you need memory to respond at 1/2 memory cycle or twice the speed of a normal memory cycle.

 

The 65816 on the snes is custom. It's not stock. It has another memory layout ontop of the existing memory layout/system. It facilitates somethings, and hinders performance in other situations. You use long addressing more often. Anyway, if the cart itself had ram mapped to second half of the external address range - you could turn on the CPU to 3.58mhz mode and access that ram at full speed. But that still doesn't fix the whole DP (re-termed from ZP) address range. It's still going to get a penalty since it's in original ram. DP are the 65x address registers.

 

But anyway, a 3.58mhz 65816 requires a little faster than 139ns memory. A 65xx at 3.58mhz only requires a little faster than 279ns memory.

 

Hmm, did the 8086/8088 have that same problem?

 

The original x86/x88 had so many other problems - this would be the least of them. Instruction times are incredibly slow. But I don't remember it having a multiplexed address bus (it has a bank system, but that's different). Other MCU types do though, but are like that for small pin package format.

 

They could have gone with a faster 65C02 derivative and implemented a bankswitching scheme to extend the address bus, either with external logic or integrated in a custom CPU package. (I believe did that for the PC-engine, with a 21-bit address) At very least they should have allowed separate ROM/RAM bank selection rather than having to treat ROM as secondary storage, not directly accessible by the CPU. (I assume due to the original intention of the console being cassette based)

 

Internally or externally handled, I don't think it doesn't makes a that big of a different. Only that the mechanism/system exists. On the PCE, you're saved the trouble of having to write to a memory mapped port in the cpu's logic address range. The registers are on the CPU itself, and you you can transfer between Acc and the MPR (8k page register) like you would the SP(stack pointer) and X register. It's convenient and a little faster, but you're not swapping memory in and out for single bytes fetches and such. So the over head is tiny to non existent in most cases. Hardwiring writes to right before the int vector range for MMU external regs would be just as good. You only need 8 bytes for eight 8k pages.

 

IIRC the 65C02 family didn't get some of the enhancements of the '816 which facilitated more efficient use of high-level languages like C, though that wouldn't have been too much of a problem with the Lynx existing in a time where games were programmed primarily in assembly language. (it wasn't until the next generation that coding in C became a major factor for game consoles)

 

There are two 65C02's. The original ones WDC put out are missing some instructions. Rockwell later added a few bit set/clear, bit logic against address, and bit test branch. WDC adopted these sometime after and made them official. So you could say there's a ver1.0 and ver 1.1 of the C02. These never made it into the 65816 line. The PC-Engine's 65x variant is based on Rockwells design, but adds more instructions, dma/block transfer instructions of the 65816, and internal registers for mapping in external memory (21 external address range like you said). The PCE HuC6280 also has the beginning of branch relative addressing (for JSR and for JMP), but they limited the operands to 8bit. The 65CE02 extends them to full 16bit which makes them more useful, but this is more computer related coding (you write completely relative based code that can be loaded anywhere in ram) There's also nothing stopping them from making long addressing modes like on the 65816. It just takes one more operand byte for the 3 byte of the PC. About C? Two things really help the 65816 in C. 1) long addressing(indirect, direct, indirect+indexed, direct+indexed). This REALLY speeds up things up for pointers. 16bit index registers VS 8bit ones definitely effects speed too on the C compiler generated code. 2) Stack relative addressing. C is built on passing arguments on the stack and the '816 added SP+index mode just for retrieving this. The 65CE02 has stack relative addressing too. Though, I have to say the second part could be simulated easily in pseudo stacks just fine (and is).

Edited April 1, 2010 by malducci

[kool kitty89]

But anyway, a 3.58mhz 65816 requires a little faster than 139ns memory. A 65xx at 3.58mhz only requires a little faster than 279ns memory.

The PC Engine would need 139 ns (or faster) memory, right?

 

I'm a bit curious how Sega got away with using 150 ns PSRAM for the 68000's memory on some early model MDs with a 7.67 MHz 68k, that seems too slow. (this came up at Sega-16 a while back, though it was also mentioned that later models switched to 120 ns and then 100 ns PSRAM)

 

The original x86/x88 had so many other problems - this would be the least of them. Instruction times are incredibly slow. But I don't remember it having a multiplexed address bus (it has a bank system, but that's different). Other MCU types do though, but are like that for small pin package format.

http://www.cpu-world.com/info/Pinouts/8088.html http://www.cpu-world.com/info/Pinouts/8086.html

The 8086 has data lines multiplexed for the 16 address lines, though on the 8088 only address lines 0-7 are multiplexed. (then there's the additional 4 segment lines) That's how they managed to fit it in a 40 pin DIP.

 

This made me curious as it's often noted that a major reason for IBM selecting the 8088 was due to cost not only of the chip, but associated memory. Now, if it's a similar case as the '816. that would mean the 4.77 MHz 8088 (or 8086) would require 100 ns DRAM (or slightly slower), while a similar, non-multiplexed MCU (including the 68k, obviously) at that speed would only require 200 ns DRAM (or slightly slower). Of course, they also wanted an 8-bit bus for cost reasons and the 68008 wasn't yet available -though cheaper DRAM could have been a trade-off for using a 16-bit bus. (especially since a 4 MHz 68k -or 3.58 MHz one following the 14.32 MHz clock, would still outperform the 4.77 MHz 8088/8086, while only requiring slightly faster than 280 ns DRAM) Then again, even a Z80 could be considered a better choice than the 8088 in some respects... (granted they'd have needed bank switching hardware)

 

Internally or externally handled, I don't think it doesn't makes a that big of a different. Only that the mechanism/system exists.

Yep, either way, pretty much the same effect. The trade-off being a custom package/CPU implementation vs an additional IC on the board. (in the case of the lynx, maybe even one of the A8 MMU designs could have been applicable)

[Multijointed Monster Maker]

I honestly think cpu speed is overrated. When I'm programming it always feels like I have a galaxy of cpu time left within every frame, even with just a few Mhz. Sure things like data compression and some special effects like scaling and rotating sprites, take a lot of cpu time, but that is what the work-ram is there for.

Edited April 2, 2010 by Multijointed Monster Maker

[kool kitty89]

Don't forget PCM playback.

[malducci]

The PC Engine would need 139 ns (or faster) memory, right?

 

Correct, because it runs at 7.16mhz. I typically use 120ns rom/ram. (internal system ram is usually 120ns or 100ns - depends. Guess whatever they had on stock/hand at the time).

 

I'm a bit curious how Sega got away with using 150 ns PSRAM for the 68000's memory on some early model MDs with a 7.67 MHz 68k, that seems too slow. (this came up at Sega-16 a while back, though it was also mentioned that later models switched to 120 ns and then 100 ns PSRAM)

 

The memory bus cycle of the 68k is 4 cpu cycles, not 1 like on the 65x arch. But, IIRC - you still need memory to respond in 2 cycles (unless you stall it with dtack or such). I.e. the data needs to be on the bus by the end of the second cycle. So in theory on the original 68k, you should be able to get away with memory at half the processor speed without any wait states. A look through the data sheets would say for sure though.

 

http://www.cpu-world.com/info/Pinouts/8088.html http://www.cpu-world.com/info/Pinouts/8086.html

The 8086 has data lines multiplexed for the 16 address lines, though on the 8088 only address lines 0-7 are multiplexed. (then there's the additional 4 segment lines) That's how they managed to fit it in a 40 pin DIP.

 

Heh, it is. But what are the timings? It's possible that the address setup time to the latch is less than 1/2 memory cycle or even faster. It just happens that on the 65816, they chose 1/2 memory cycle. They could have achieved it in faster time. 1/4 or 1/8, etc. Register latches were fairly fast and cheap (8bit latches easily in the 20ns range).

 

This made me curious as it's often noted that a major reason for IBM selecting the 8088 was due to cost not only of the chip, but associated memory. Now, if it's a similar case as the '816. that would mean the 4.77 MHz 8088 (or 8086) would require 100 ns DRAM (or slightly slower), while a similar, non-multiplexed MCU (including the 68k, obviously) at that speed would only require 200 ns DRAM (or slightly slower). Of course, they also wanted an 8-bit bus for cost reasons and the 68008 wasn't yet available -though cheaper DRAM could have been a trade-off for using a 16-bit bus. (especially since a 4 MHz 68k -or 3.58 MHz one following the 14.32 MHz clock, would still outperform the 4.77 MHz 8088/8086, while only requiring slightly faster than 280 ns DRAM) Then again, even a Z80 could be considered a better choice than the 8088 in some respects... (granted they'd have needed bank switching hardware)

 

Like I said for the original 88/86, you'd have to look at the external memory timing charts to see what speed ram/rom is required.

Edited April 2, 2010 by malducci

[kool kitty89]

The memory bus cycle of the 68k is 4 cpu cycles, not 1 like on the 65x arch. But, IIRC - you still need memory to respond in 2 cycles (unless you stall it with dtack or such). I.e. the data needs to be on the bus by the end of the second cycle. So in theory on the original 68k, you should be able to get away with memory at half the processor speed without any wait states. A look through the data sheets would say for sure though.

Ah, right, that's how a lot of DMA set-ups on 68k systems (like Amiga or ST) could get away with using half the bus time and not slowing down the CPU. (the Amiga chips could take 50% of the bus time without the 68k taking a performance hit iirc)

[Multijointed Monster Maker]

Don't forget PCM playback.

 

I'm talking about systems that have a second cpu for audio. Most developers took cpu speed litterally as gameplay speed. Look at the average shmup on the Snes and the background usualy scrolls 1 pixel per frame. Then look at the average Sega Genesis shmup, and the background scrolls 2 pixels per frame. Just moving a background at faster speed isn't going add any extra slowdown to the game. And no, when the Super Nintendo is accessing it's 2.68Mhz, it doesn't slow the game to 3/4 it's full speed either. All videogames are fixed at 60 fps, and the cpu is timed with each frame. I've heard one guy trying to make a theory that the reason why Sonic moves slow underwater, is because they switched from the 68000 to the Z80 in that level. It does not work that way. Sonic moves slower underwater because the game physics are, if sonic's y coordinate is greater than waterlevel line, his coordinates will move by half their velocities. It's all mathematically done.

Edited April 2, 2010 by Multijointed Monster Maker

[kool kitty89]

Ah, I was making the PCM comment in context of the Lynx.

 

As for the slowdown, I know the speed of the game isn't directly tied to the CPU, CPU only becomes an issue when it's not fast enough to complete a routine before the frame is up, like what happens occasionally in games like Street Fighter II (to a lesser extent on the PCE and MD/Genesis -though some of that could also be VDP DMA related if too much animation has to be updated). In the case of something like slowdown when a ton of sprites are on screen, like Sonic loosing rings, slowdown is CPU induced. (hence overclocking eliminating it)

 

However, in the context of ROM I mentioned above, there are cases where using 2.68 MHz ROM vs 3.58 MHz accessed ROM can affect slowdown if fetching data from ROM is a limiting factor. (I think there was a discussion arguing that Super Mario Wold Allstars reduced slowdown compared to SMW due to faster ROM on Sega-16 a while ago -though there may have been some other optimizations in that re-release too)

[malducci]

 

However, in the context of ROM I mentioned above, there are cases where using 2.68 MHz ROM vs 3.58 MHz accessed ROM can affect slowdown if fetching data from ROM is a limiting factor.

 

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.

[Multijointed Monster Maker]

Ah, I was making the PCM comment in context of the Lynx.

 

As for the slowdown, I know the speed of the game isn't directly tied to the CPU, CPU only becomes an issue when it's not fast enough to complete a routine before the frame is up, like what happens occasionally in games like Street Fighter II (to a lesser extent on the PCE and MD/Genesis -though some of that could also be VDP DMA related if too much animation has to be updated). In the case of something like slowdown when a ton of sprites are on screen, like Sonic loosing rings, slowdown is CPU induced. (hence overclocking eliminating it)

 

However, in the context of ROM I mentioned above, there are cases where using 2.68 MHz ROM vs 3.58 MHz accessed ROM can affect slowdown if fetching data from ROM is a limiting factor. (I think there was a discussion arguing that Super Mario Wold Allstars reduced slowdown compared to SMW due to faster ROM on Sega-16 a while ago -though there may have been some other optimizations in that re-release too)

 

I'm making a run-n-gun game engine for the Snes, and I just don't get it. Everywhere I look, everybody says the Snes is far too slow to handle intense action games. Some how, I must be doing something different than other programmers, because nomatter what I do, it feels like I have a vast amount of cpu power left. BSNES is supposed to emulate slowdowns, isn't it?

[kool kitty89]

I'm not sure about BSNES, but I know older versions of SNES 9x didn't properly simulat slowdown, I think ZSNES is the most accurate. BSNES is great with its debugging capabilities, but seems a bit clunky for some things...

 

CPU limitations isn't the only cause of slowdowns though, DMA limitations of the VDP can be a big factor, I think that's the reason some games like Street Fighter 2 have clipped screens. (for increased vblank time) I think it's even worse on the Genesis, in 60 hz at least. (50 Hz gives a ton of vblank time)

[Multijointed Monster Maker]

I heard Bsnes is the most cycle accurate.

 

I always wondered what happens when you dma during active screen. Some sources say it puts garbage onscreen, while other sources say it waits till the next v-blank. What is the correct information? If it waits till the next screen, then it directly causes slowdown, if it puts garbage onscreen, then programmers would have to program something to keep track of cycles and force the game to slowdown. My engine doesn't turn the screen on until all dma-ing is finsihed, so if there is too much data that has to be updated, there will be a little flickering at the top of the screen. V-blank is the only part of programming where I worry about counting cycles.

[Ace_1]

A console based off some old arcade boards:

 

-10MHz Motorola 68000 CPU

-Custom 16-bit graphics processor with scaling and rotation capabilities

-Yamaha YM2151 FM sound chip

-VLM5030 PCM sound chip

-3.57MHz Zilog Z80 CPU to control the sound chips

-Cartridges can house custom sound chips(example: Konami wants to port Gradius, they can put in their custom SCC sound chip and the 2 AY-3-8910 sound chips that were used on the original arcade board inside the cartridge)

-2MB of RAM

-Pack-in controllers are like Neo Geo controllers: arcade sticks(but not as huge and with 6 buttons instead of 4)

-2 controller ports(with support for analog controllers like flight sticks)

-RF, Composite, S-Video and RGB outputs with Stereo sound

 

Quite a beast of a console. Just thinking of that makes me want to build one with these specifications.

[kool kitty89]

I heard Bsnes is the most cycle accurate.

 

I always wondered what happens when you dma during active screen. Some sources say it puts garbage onscreen, while other sources say it waits till the next v-blank. What is the correct information? If it waits till the next screen, then it directly causes slowdown, if it puts garbage onscreen, then programmers would have to program something to keep track of cycles and force the game to slowdown. My engine doesn't turn the screen on until all dma-ing is finsihed, so if there is too much data that has to be updated, there will be a little flickering at the top of the screen. V-blank is the only part of programming where I worry about counting cycles.

 

I know there are garbage pixels on the Genesis... hence the flickering sprites to hide that in sonic games suing palette changing for water effects. Not sure about the SNES, I know there's some limitation to it, but for the window layer (the solid color layer, usually the furthest BG, but sometimes used for transparency iirc) raster bar effects seem to work fine, like the sky in Donkey Kong country, but that may have to do with the nature of the window layer too.

In general, mid-screen palette changing would be much less necessary than on the Genesis anyway due to the much greater number of subpalettes. (8 for sprites and BG opposed to 4 shared ones on the genesis -still 1/2 of what the PCE offers though, plus the PCE can modify the screen during active display)

 

 

 

A console based off some old arcade boards:

 

-10MHz Motorola 68000 CPU

-Custom 16-bit graphics processor with scaling and rotation capabilities

-Yamaha YM2151 FM sound chip

-VLM5030 PCM sound chip

-3.57MHz Zilog Z80 CPU to control the sound chips

-Cartridges can house custom sound chips(example: Konami wants to port Gradius, they can put in their custom SCC sound chip and the 2 AY-3-8910 sound chips that were used on the original arcade board inside the cartridge)

-2MB of RAM

-Pack-in controllers are like Neo Geo controllers: arcade sticks(but not as huge and with 6 buttons instead of 4)

-2 controller ports(with support for analog controllers like flight sticks)

-RF, Composite, S-Video and RGB outputs with Stereo sound

 

Quite a beast of a console. Just thinking of that makes me want to build one with these specifications.

 

Heh, most arcade boards didn't have anywhere near that amount of onboard RAM, they used tons of ROM instead, hence the cost of Neo Geo carts and the large amount of RAM supplanting that on the Neo Geo CD.

 

Plus the Z80 would almost certainly be 4 MHz, though a dedicated audio CPU is often unnecessary with proper sound hardware, the added benefit is usually unnecessary, though allowing such to be used as a general coprocessor might be useful. (a few Genesis games did so)

 

But in general, direct arcade board conversion make for horrible home consoles in terms of marketability. The Neo Geo is a testament to this.

 

However, if the hardware is modified some what, even minimally, and the system is optimized to work with much more limited ROM cart sizes, it might be possible, though that would normally require onboard RAM to supplement the lack of ROM, and probably still have games cut-down somewhat due to limitations of the onboard RAM carried and cartidge size. (perhaps with a lot compression you could get decent conversions on 6 MB and smaller ROM carts -that's 48 Mbit)

 

In fact, the Neo geo might have been a good candidate for such, but they opted for a direct home conversion instead which was FAR too expensive.

 

One of the best arcade board at the time to do such with would have been Sega's System-16: an older arcade board which was designed to be more of a mid-range lower-cost system to begin with. So, with a bit of consolidation and alterations to facilitate limited ROM sizes for games (modifications to both hardware AND software -the former mainly added RAM and/or realtime decompression hardware) and uses a YM2151 as well as an ADPCM chip. (you could probably make do without the Z80 coprocessor too) It was more like contemporary consoles than the Neo Ge in that it used dedicated BG planes as well as sprites, but could zoom sprites like the Neo. (that is scale down from and up to normal resolution, but not past that)

For 1990, the newer System-18 might have been a possibility too, though probably wouldn't be anywhere near as cost effective as the System 16. (given the System 18 was from 1989)

[malducci]

 

I know there are garbage pixels on the Genesis... hence the flickering sprites to hide that in sonic games suing palette changing for water effects. Not sure about the SNES, I know there's some limitation to it, but for the window layer (the solid color layer, usually the furthest BG, but sometimes used for transparency iirc) raster bar effects seem to work fine, like the sky in Donkey Kong country, but that may have to do with the nature of the window layer too.

In general, mid-screen palette changing would be much less necessary than on the Genesis anyway due to the much greater number of subpalettes. (8 for sprites and BG opposed to 4 shared ones on the genesis -still 1/2 of what the PCE offers though, plus the PCE can modify the screen during active display)

 

The SNES has a Color Window. You can just update that instead of changing the palette entries mid-screen (can fade the screen down, etc). Not to mention transparency of BG layers to others and sprites. And like you said, more subpalettes means you could just change the map position to another point in a mirror section of the map that has alternate subpalette references. Lords Of Thunder does this on the PCE for the water level, for when the enemy smashes the ground and the water pours into the hole - lowering the level (which is absent on the SegaCD version).

Edited April 4, 2010 by malducci

[Multijointed Monster Maker]

If slowdown is caused by the cpu running out of cycles in one frame, then why doesn't the framerate drop with the gameplay speed, instead of having sprites move by half distance per frame at 60fps?

[carmel_andrews]

somewhat disappointed that no one has mentioned the konix multi system...that definately had possibilities (think of it as a 1990's wii wii)