SpritesMind.Net

Hello all,

there has been some discussion surrounding the topic of there being a more powerful MD cartridge with extra capabilities for a while now.

[Features]

1. large amount of ROM available for Game ROM
2. extra Math hardware to give the MD extra processing power
3. additional Audio channels

I thought that I would pull things together and start the ball rolling.

First question would be what extra capabilities one would want on a custom-cart?

[Questions]

1. what is the available amount of current available when running on the various models of the Megadrive?

...more later...

<ToDo: add the rest of the info, plan, etc.>

One thing you mentioned in the other thread is important - whatever is done MUST be low power. The cart slot doesn't source much power.

Another point - if this is going to be at least an SVP open-source replacement sort of thing, you need at least enough ram to hold a frame of data or two. The SVP includes 128KB of DRAM for that. I'd suggest 1 or 2 MB of ram to hold not just the output frame, but also input textures and/or vertexes.

Having a 16-bit codec hooked to the audio inputs on the cart port would be great for extended audio. The codec could be independent (for a plain DSP design), or part of the DSP or MCU (for a more featured chip). This goes along with the increased ram size to allow putting compressed samples or songs into ram.

Sure, textures and samples and songs could be left in rom, but then you have slow accesses to rom that hold off the 68000 every time you want to access something. Better to have the DSP/MCU convert to/from ram for higher speeds and no/little contention with the 68000.

Preferably, there would be some FPGA that I could reprogram, maybe even by uploading precompiled vhdl code within a Genesis rom. That would open up the exciting possibility of games that extend themselves purely in software.

Do we have a clear idea on how much current is safe to draw from the cartridge slot?

This is obviously an important consideration in designing an expansion.

Hi,

whilst many questions need to be raised I cannot help but think that many of you chaps are concentrating on the low-level details before working on the requirements.

I shall update the Thread with some ideas for requirements but please feel free to put forward capabilities that a cart should provide.

Some basics:

1: Maths processing: the 68K is pretty useless at multiplication and division (I never use div and mul personally on the 68K). Being able to pass a table of coordinates and have the 'Math Hardware' calculate all the new coordinates and to handle angles, etc would be an improvement.

Scaling and Graphic transformation would be useful and would mean that the WRAM or ROM memory address of the source is given for the graphics to be scaled and then expect the scaled graphics to appear at another address somewhere would be a way to use that facility.

Math processing, graphic scaling and transformation are all 'Math activities' in my book.
When you work with DSPs you try to turn as much as you can the data into 'work' for the DSP to process which lends itself to equations and tables. This could be applied to MD Games using the cart.

2: Audio/Music: what would be cool to add musically? A large Wave-Table Synthesiser, PCM? What would be cool? Rule out Physical modelling for now. More FM Channels is more than doable and it is pretty cheap too.

So, if anyone has ideas about what to add at this stage to the Requirements that they feel would be cool and useful as capabilities please let us know.

Let us consider such topics as clock-frequencies and power usage in the Specification - for now we need to work on the WHAT as opposed to the HOW, ok?

Cheers,

Minty.

Chilly Willy wrote:One thing you mentioned in the other thread is important - whatever is done MUST be low power. The cart slot doesn't source much power.

Another point - if this is going to be at least an SVP open-source replacement sort of thing, you need at least enough ram to hold a frame of data or two. The SVP includes 128KB of DRAM for that. I'd suggest 1 or 2 MB of ram to hold not just the output frame, but also input textures and/or vertexes.

Having a 16-bit codec hooked to the audio inputs on the cart port would be great for extended audio. The codec could be independent (for a plain DSP design), or part of the DSP or MCU (for a more featured chip). This goes along with the increased ram size to allow putting compressed samples or songs into ram.

Sure, textures and samples and songs could be left in rom, but then you have slow accesses to rom that hold off the 68000 every time you want to access something. Better to have the DSP/MCU convert to/from ram for higher speeds and no/little contention with the 68000.

Yes, and I would not like to have to use an extra power supply connected to the cart either so a Power figure would need to be found for an unexpanded Megadrive.

Memory is substantially cheaper 20+ years on. When the Specification is undertaken it will be necessary to consider the types of memory to use and how much of each. It may be a good idea to consider developing a cart that is expandable which would allow a small amount of Game ROM to be used or indeed a larger amount depending on the Game's needs.

These days there are many Audio and Video CODEC ICs around and some are not at all expensive (assuming licenses are inclusive). there should be a happy partition between how much time a Games Console spends handling Audio, Video, decompression, sprite handling, etc. Although it will vary for each Game one could not really expect too much time of the main Processor to be consumed by the Audio Hardware.

All in all, it is useful to consider more modern approaches to MD Game Hardware I feel.

Hello

I have read the original thread and this one. And love the ideas being thrown around and would really like to see a real piece of hardware come about.

There has been much discussion on audio for this cartridge. Just my two cents but what about a time period appropriate and Sega like choice? I know it might be becoming harder to find but what about the Yamaha YMF278? It has 6 channel FM plus 24 channel PCM. Or a more modern Yamaha YMU762 (MA3) I know this is a mobile chip and again I am not sure if it is in production but specs look nice 16 channel, four operator FM plus 8 channel PCM or ADPCM.

It would also be nice to see this device compatible with the 32X as to use any hardware audio and hopefully much extended ROM memory abilities.

Thanks and have a great day everyone.

Ok, chaps, I need some ideas for useful math oriented operations that should be included in the custom-cart.

Ideas thus far:

1. Floating-Point support - 68K has none.
2. Multiply and Divide operations - 68K is laughably poor at this - 176 cycles is it?
3. Vector and Matrix operations.
4. Trigonometry.

Useful operations for working with the Megadrive:

1. Decompression of Graphic data.
2. Sprite-Attribute Table Entry formatted results.
3. Manipulations involving Tile-Sets and Tile-Maps formatted to MD native format from given source format(s)/etc.


Any ideas, anyone?

Cheers,

Minty.

What about a framebuffer ? The pseudo-SVP would translate everything to a tile-rendered scene.
Just like the original SVP come to that.

ob1 wrote:What about a framebuffer ? The pseudo-SVP would translate everything to a tile-rendered scene.
Just like the original SVP come to that.

That is a very good thing to add - good idea.

I have not programmed the 32X - are there any links to descriptions as to how the Framebuffer is to be used or how it works?

It's just enough ram to hold a frame (or two) worth of data. In this case, it wouldn't be an ACTIVE frame buffer. You'd still need to DMA it to vram. The SVP includes 128KBytes of DRAM for a frame buffer. I'd suggest that as a minimum amount.

I recently made some current consumption measurements on the NTSC Virtua Racing cart.

viewtopic.php?t=1931

This should, in my opinion, be the maximum amount of current one should design for at the cartridge port for a new and powerful cart. Just for fun, I also measured the current consumed by a Mega Everdrive and it was significantly higher than VR - voltage regulators are getting heavily taxed...

Other problems to look at are:
-Cost - forget about an FPGA because they're simply too expensive to make any serious mass produced cart
-5V tolerance - there are flash carts (and even new physical releases) out there which operate 3.3V parts out of spec, you NEED level converters to interface to modern parts
-RAM - without an FPGA to implement an SDRAM controller you're likely using SRAM and affordability quickly rolls off after 512KB

Overall, sounds like a very interesting challenge!

db-electronics wrote: I think the purpose of this discussion is to find an affordable solution to increased processing power in a releasable and manufacturable physical cart.

I agree, for Developers to use a custom-cart it would have to be affordable and have useful resources all the while staying within the constraints of the Megadrive for factors such as allowable current when used with the various Megadrive models.

But indeed progress is being made

There are two things at play here: cost and performance.

Cost - a cart as we are beginning to describe needs to be an affordable physical means of releasing a game. To be very clear, I don't mean this in the sense of a soft release but in the sense of a hard release - cartridge with shell and case and so on. I'm not ready to pay more than about US$100 for a physical Genesis release so I use that number as my own personal guideline. As a public discussion, it's important we determine what cost is acceptable. I'm very familiar with electronics and plastics manufacturing - I just know this cost is achievable with the right hardware and plastics providers.

Performance - MintyTheCat has already included a "wishlist" of sorts at the beginning of this thread which important performance indicators such as:

• Floating Point Support
• Multiply and Divide
• Vector and Matrix Operations
• Trigonometry

I'll add to that list by saying a custom-cart absolutely needs to take advantage of the audio input lines on the cartridge port.

Just so I understand the scope of the project better: the idea is to build a cart with a lot of helper functions? There's not, for example, an additional CPU on the cart?

As for having a frame buffer, isn't there a problem with copying the whole frame buffer to the VDP because DMA is too slow to do the whole screen in 1/60th (or even 1/30th) of a frame?