Jump to content

Multijointed Monster Maker

  • Content Count

  • Joined

  • Last visited

Posts posted by Multijointed Monster Maker

  1. I am guessing that a 6309 is somewhat comparable to an '816 (65816, WDC version)...given the clock speed you mentioned


    If not, why not use a 20 mhz version of the '816 (which has a 6502 native mode built in) and emulate some other processors via fpga (i.e 6809, z80, TMS etc etc)


    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.


    And did you notice the quoting is having trouble getting the author right? Odd...



    He He!!!



    But 256 samples really isn't very good. You either need really short instruments (no base drums), or really low sample rates. Having 2:1 or 4:1 ADPCM for the channels means you can have higher sample rates and/or better sounding base instruments.


    The hardware support for music isn't really needed, but would be nice. :)


    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.

  3. Sounds interesting. Did you mean 6809? That was big at the end of the 8-bit era... a very nice chip indeed.


    6309 is a slightly upgraded version of 6809.


    Does the graphics have two layers? That's important for platformers in particular. Otherwise, the graphics sound good.


    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.


    The audio might need a little more thought. Given how little memory you can devote to the samples, perhaps hardware ADPCM decompression would be appropriate. One thing I can think of now that would have helped systems back then would be hardware support for tracker format music. For example, maybe you could have hardware support for playing 8 channel/31 instrument MOD format files. Think of it like display lists for the sound instead of video. Maybe not MOD format directly, but something that you could convert a MOD into easily.


    It's just enough memory for each channel to have it's own 8-bit 256 sample instrument.

  4. What I'm trying to do is come up with the perfect early-90s style 2D game machine.




    6309 @ 7.16 Mhz





    64 kB work ram

    64 kB video ram

    8 kB sprite attributes

    512 bytes color ram

    4 kB audio ram





    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







    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.

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

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

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



    It doesn't use hardware backgrounds, but it can be implemented by joining together 22 16x256 sprites.

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

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

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

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

    • Like 1

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

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

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

  15. Every time I experience a rabid fanboy or fangirl, I like the system they are in love with that much less. Eventually the sheep move on to something else, the signal to noise ratio improves, and after 5-10 years I get a chance to enjoy the system again. I have experienced this with the Atari 2600, every product Nintendo has every released, the Saturn, and the Dreamcast.


    As the internet has grown to be a major disseminator of information, I've been burned out from marketing, over-hype, payola reviews, and childish rantings about every system and game released in the least decade.


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

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

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

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

  • Create New...