Multijointed Monster Maker

I cheated a little bit. A hardware 7.16 Mhz 6309 doesn't really exist, but a 3.58 Mhz 6309 does. A 7.16 Mhz version was supposed to be released, but Motorola and Hitachi had a lawsuit over the chip and it was discontinued early. At least with emulation via FPGA, you can clock it to higher speeds than it originally was. If I can't find a 6309 FPGA core, than I'll go with a 6809 core instead. I prefer the 6309 to the 65816. It's design is a bit more flexible. After programming an SNES for a long time, the 65816 starts to give you a headache.

He He!!! I wanted to keep the waveforms simple, but use frequency modulation + detuning + reverberation to make instruments more lush sounding. I probably will allow channels to modulate the echo delay parameters so you can create phasing/flanging sounds too.

6309 is a slightly upgraded version of 6809. Well, actually it's based on Neo Geo's sprite system where every sprite is a tall stack of 16x16 tiles with separate attributes per 16x16 tiles, with a joining bit that places next sprite 16 pixels to the right of the last one. To create a background, join 22 16x256 sprites together and the background coordinates are controlled by the coordinates of the left most sprite, since the rest just follow the coordinates of the last. There can be up to 112 sprites per line, so there can be up to 5 layers. It's just enough memory for each channel to have it's own 8-bit 256 sample instrument.

What I'm trying to do is come up with the perfect early-90s style 2D game machine. CPU: 6309 @ 7.16 Mhz Memory: 64 kB work ram 64 kB video ram 8 kB sprite attributes 512 bytes color ram 4 kB audio ram video: resolution: 336 x 224 sprites: 224 112 per scanline sizes 16x16 to 16x256 join sprites together with join bit colors: 32768 256 at once 16 per 16x16 sprite block transparency audio: channels: 16 wavetable 256 samples per instrument cross channel frequency modulation dual echo/delay/feedback buffers output: 8-bit 56kHz stereo hardware features: DMA @ 3.58 Mbps (7.16 million pixels per second) affine graphics blitter @ 4.77 million pixels per second (7.16 / 3 * 2) RLE graphic decompressor @ 4.41 million pixels per second (7.16 / 13 * 8 ) active display V-RAM accessing These are not randomly thought out numbers. I drew pictures of circuitry, made memory map lists, and counted cycle usage of the video and audio chips to make sure these technical specifics are possible and actually make sense.

Wow, those are really expensive!

I am currently designing a custom computer-on-chip game system, and I have some very important questions. 1) Where do I find FPGAs? I can't seem to find them anywhere. 2) What kind of media storage would I use to store the games on? 3) When I'm finished with the system, how would I program it?

Here is something else: Good hardware: ability to make changes to your game without rewriting graphic driving code Bad hardware: constantly needing to rewrite graphic driving code everytime a change to your game is made

This could get into a good detailed discussion. It can be defined in different ways for different kinds of people. For some, good hardware means good graphics or good "specs" or good perceived power. Others can define it as how easy to program is it or how much untapped potential the system has. Sometimes technical specs are overwelmingly misleading, and leave out conditional limitations, where a system can do X and it can do Y, but it can't do X and Y at the same time. On the contrary, sometimes the technical specs are underwelmingly misleading, where they don't take into account tricks around limitations and make the system appear weaker than it actually is.

I was drawing a (not so detailed) diagram of the circuit for the VDP core, and I realized the VDP needs to be 28 Mhz not 14 Mhz. Eventhough it access it's V-RAM at 14 Mhz, it needs to buffer the pixels to it's scanline buffer at 4x the pixel rate. This can also make designing the hardware a little easier because the VDP can now use an 8-bit bus for v-ram and color-ram. The currently planned technical specifics are: *336x224 screen resolution *168 sprites (sizes range from 16x16 to 16x256) *horizontal sprite joining *84 16x16 sprites per scanline *32768 colors *256 colors at once *16 colors per 16x16 sprite block *64 kB V-RAM + 512 bytes Color-RAM *transparency It doesn't use hardware backgrounds, but it can be implemented by joining together 22 16x256 sprites.

If I'm using 63C09s, I'd clock it at 3.58 Mhz, and forget about dual processing. The free VHDL 6809 core sounds interesting though. I might use that because I'm trying to get the most out of as minimum hardware as possible.

I'm almost finished planning out the specifications and memory map of a homebrew video game system. The VDP will be clocked at 14.32 Mhz, using a 7.16 Mhz pixel clock rate. For convenience, I plan on using either a 7.16 Mhz 63C09 or dual 3.58 Mhz 63C09s. However I'm not quite sure if 63C09s are capable of running at 7.16 Mhz. Some people say the maximum speed is about 7 Mhz, while others claim it's around 5 Mhz. Who's right?

I'd say what ruined a lot of SNES games is the SNES's hard-to-navigate hardware that forced developers to be less experimental. From the 8 and 16 bit generation the SNES had the second worst graphic loading schemes. NES - cartridge loading Genesis - 3.35 Mhz DMA loading, loads during active display PCE - CPU loading, loads during active display SNES - 2.68 Mhz DMA loading, v-blank only SMS - CPU loading, v-blank only For the SNES, everything that involves using tiles or sprites have to fit within the small amount of time where the CPU is allowed to access the V-RAM before the PPU takes control of it. I can't even imagine the issues the SMS programmers dealt with.

common misunderstandings: -the CPU does not draw sprites and backgrounds onscreen. -Gameplay speed and CPU speed are not the same thing. -Not all games are well programmed. Not even games from popular companies like Capcom and Konami. -CPU "bitness" is unimportant when determining CPU speed. -The speed at which the CPU addresses external memory is more important than the Mhz speed. -Using 32-bit values in places where only 16-bits are needed does not make you an "epic programmer." -If you find an optimization on one CPU, don't expect it to work on another.

Finally a REAL sega fansite! I got so tired of Melf and Joe Redifer turning the Sega Genesis into a totally gay system. All Joe and Melf ever did was make up fake technical shit about the Sega Genesis and Super Nintendo, (stuff that could be proven wrong by JUST PLAYING A FREAKING GAME) and trolling anyone who disagrees with them. The next time you visit Sega-16, tell both Joe and Melf I can kick both of their asses at 65816 ASM, and they should get rid of their inflated egos. They can't even get 100 sprites onscreen without loads and loads of slowdown. What a bunch of morons!

It's ironic that people are making RPGs on the Sega Genesis, while I'm trying to make action games on the Super Nintendo. I find it sad that nobody even tried to make a Gunstar Heroes game on the SNES. Everybody kept complaining about everything causing slowdown without even trying in the first place. Stop blabbering about unexplored territory, and just explore it for once!!! Programmer - "Duh, I'm not going to do it because it will cause slowdowns"

Demons Crest: People think this game is so impressive when it does nothing special on a technical level. Gameplay isn't anything special. Linear levels, walking enemies that don't have their own individual character, bosses that just stand there and throw projectiles.

Something I don't like about published games is that most developers just followed the crowd instead of striving for the next best thing. My homebrew mentality is to break the status quote, and use different programming methods and tricks that were never used in published games. However, I can't help being bored after programming for a long time, whereas liscensed developers can sit on their butt all day programming without taking a break for socializing.

Any dumb ignorant retard who says that the Snes can't handle more than 4 objects onscreen at one time without slowdown, when every SINGLE game made for the system PROVED it wrong. That includes the entire internet.

The Sega Genesis would be my favorite console, if only Sega (and fanboys) weren't so arrogant, and didn't let out hundreds of incorrect technical facts people take the bible. "The Snes can't scroll backgrounds as fast as the Genesis" A screen of background map on the SNES takes 2kB (32x32 tiles * 2 bytes per tile = 2048 bytes). It can upload 6kB of data during v-blank via dma. That means the Snes can scroll the background at a speed of 3 SCREENS PER FRAME!

Question about ROM reverse engineering. Why were programmers obsessed with loops, even when they knew that the 65816 is bad with loops? In 1996, 32-meg carts were largely available, but programmers kept using loops like crazy.

That's pretty much describes me with the Sega Genesis.

I've been trying for a few years, and I still haven't created a single good sound. I know how FM synth works so don't post a stupid "introduction to FM synthesis" webpage. I just want to know a safe way of creating a good sounding instruments with ease. How do I get rid of the flatness and the scratchiness that's been plaguing every sound I make? What carrier to modulator frequency ratio would you recommend?

I find the majority of programmers who worked on Super Nintendo to be stupid and unimaginative. I even find SNES platformers to be a step down from NES. Whenever a type of gameplay element required some sort of special sprite or background usage, the NES programmers JUST DID IT, without worrying about cpu power. On the SNES, they tried to avoid those kinds of gameplay elements because they were afraid they will cause slowdown, without even trying in the first place, regardless that the Snes had more cpu power and faster cpu > ppu updating than the NES. Sometimes I wonder if those guys even knew what a DMA was, since they never even used it.

http://www.youtube.com/watch?v=SMrnxUF93HA If Mode-7 only allows 1 background, how was I able to get 2 layers? Anybody who can answer this question correctly will receive the superpower of turning homeless people into ninjas.

The problem with samples is they're random. When I find an easy way to program the SPC700, I'll program an Snes tracker with a few intentional quirks. I'd limited every instrument to 32 samples long and force the composer to rely on his creativity, and hardware features like pitch modulation and echo delay (which could also do phasing in my tracker) to make good sounding instruments.