custom co-processor chips like the SVP?

For anything related to cart (SRAM, SF2 mapper, audio, CD mode 1, ...)

Moderator: BigEvilCorporation

foobat
Very interested
Posts: 92
Joined: Fri Sep 14, 2012 1:06 pm

Post by foobat » Fri Dec 14, 2012 1:26 am

What's the point of all that nonsense? At what point are you not really using the Megadrive/Genesis anymore? IMO this is just like taking a perfectly good gun and strapping plastic "modern warfare" crap to it

RayR
Newbie
Posts: 6
Joined: Fri Dec 07, 2012 4:57 am

Post by RayR » Fri Dec 14, 2012 1:39 am

To each his own. It's all good. Some hardware engineers enjoy creating things and some software engineers enjoy coding for those new inventions. It's like souping up a car, or upgrading an audio amplifier. It's a challenge to do something different and maybe learn along the way. The journeys the destination.

tinctu
Very interested
Posts: 97
Joined: Tue Oct 30, 2007 8:28 pm

Post by tinctu » Fri Dec 14, 2012 8:26 am

15 FPS NTSC...
Well you can use ARM or DSP as matrix processor / GPU. So you will be able make realtime 3D graphics faster. You will use it for fast math. And VDP for output graphics data... So no prerendered or precalculated 3Ds. But realtime 3Ds...

Chilly Willy
Very interested
Posts: 2593
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Fri Dec 14, 2012 7:02 pm

We played 6 FPS games on the old 8-bit systems... and were THANKFUL!! :lol:

Damn whippersnappers today spoiled with their 180 FPS 1,000,000 polygons per frame "games". They whine ago how slow it goes and how poor the image is... :wink: :lol:

Mask of Destiny
Very interested
Posts: 572
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » Fri Dec 14, 2012 7:07 pm

You can get 60fps with the direct color mode trick. Horizontal resolution isn't very high (~190 pixels IIRC), but you'll be able to use a lot more colors.

I'll be honest, part of me agrees with foobat here. Once you have a 200MHz ARM core and an audio DSP, the genesis hardware seems a bit superfluous. However, if others find it fun who am I to judge?

Chilly Willy
Very interested
Posts: 2593
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Fri Dec 14, 2012 8:23 pm

Mask of Destiny wrote:You can get 60fps with the direct color mode trick. Horizontal resolution isn't very high (~190 pixels IIRC), but you'll be able to use a lot more colors.
The resolution is exactly half the regular resoultion: instead of 320, you get 160 pixels; instead of 256, you get 128. You can actually display in the overscan areas, which you can't do normally on the Genesis, but the overscan area is normally not visible, so it's nothing to brag about. :D

Anywho, I'm trying to work on a CD demo that shows what you can do with direct color dma mode.

I'll be honest, part of me agrees with foobat here. Once you have a 200MHz ARM core and an audio DSP, the genesis hardware seems a bit superfluous. However, if others find it fun who am I to judge?


Meh - it's all wishful thinking anyway... there's like 0% chance of this thread ever producing anything. If someone really wishes to do something like mentioned, get the MegaEverdrive and learn to program FPGAs. 8)

I'll probably get one after xmas.

Toddo
Interested
Posts: 12
Joined: Thu Sep 12, 2013 5:08 am
Location: Australia

Post by Toddo » Wed Oct 30, 2013 6:52 am

Possibly a RISC or small transformation calculator on the cart. Or maybe just have an extra 68000 plug in the side to perform a similar function to say... the MegaCD.
-Chill dude, the 68k can handle it.

User avatar
MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Sat Nov 02, 2013 10:31 am

Yes, this topic is of such importance that I'd personally open up another Forum Category for it :D

I suppose that for certain types of Games it would be immediately beneficial to have a very fast Map Generator based on the User's action the Block would generate any changes that needed to be applied to the Tile-Map.

Another useful facility (as I was being asked by a Team developing a Shmup for another Platform and had to answer this): "how does the Game handle Angles and the Maths, do you have a decent Math Engine or anything? - short answer: "no.". But if there was a known Address in Cart Space that you simply give the current coordinates and end up with the coordinates that you'd need converted into Tile-Map and Tile-Set updates then you'd have the same result.

I can also see a DSP being used for audio and any math work too - Level-Shifters are not as much of an issue to design with as some are implying and indeed UMDK and the Everdrive are Examples of this being solved.

I can see a genuine benefit in having extra processing power to handle the 'State' activities with the 68K being slaved and merely being the 'doer' - makes good sense.

However, the main importance in order to gauge how best to gauge the MD's performance is to write Code for the MD that reaches those limits and then be in a better position to determine which types of Resources would improve the performance of the MD for your particular application, be that for an RPG Game or for a Beat 'em Up.

I think that there should be a group focus on realising Designs with additional Hardware used on the MD as for a start it will enable many Questions to be answered in the process.

I shall start to think...

User avatar
KanedaFr
Administrateur
Posts: 1116
Joined: Tue Aug 29, 2006 10:56 am
Contact:

Post by KanedaFr » Mon Nov 04, 2013 10:02 am

I saw nowhere HOW you will "connect" with an embedded DSP/CPU/whatever ...
What will be the best way to get ROM + CPU on the same board ?

User avatar
MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Tue Nov 05, 2013 12:42 pm

KanedaFr wrote:I saw nowhere HOW you will "connect" with an embedded DSP/CPU/whatever ...
What will be the best way to get ROM + CPU on the same board ?
Do you have any Hardware development experience, Kaneda?

I am more into Real-Time Software/Embedded myself but I have seen enough Hardware over the Years to see how it would be feasible.

There would be a few options open but essentially there would be some kind of Bus on the PCB connecting the extra Processor (CPLD, DSP, uC, etc.) to the MD's Memory-Map. We'd then use Memory-Mapping to 'talk' to the extra Processor. The Code running on the MD would read/write to some location and the Hardware on the PCB would detect that it was 'talking to the Processor' - hence Memory-Mapping.

The ROM Space used to hold the Program's/Game's Image is a piece of Memory like any other - be that RAM, ROM, CPLD, FPGA, anything you fancy it is all Memory. The task would be to allocate a large enough Memory Space for the Image.

I'd look at something like UMDK as most of this is already possible:

http://www.makestuff.eu/wordpress/categ ... ts/umdkv2/

The Author is working on another version of the Board that incorporates a more powerful FPGA. For production simply transfer the Logic that you develop into Hardware Blocks - worst-case use a CPLD.

Does that make sense?

User avatar
KanedaFr
Administrateur
Posts: 1116
Joined: Tue Aug 29, 2006 10:56 am
Contact:

Post by KanedaFr » Tue Nov 05, 2013 2:00 pm

I'm trying to expend my hw experience ;)
it's why I asked how you plan to do it....

I understood memory mapping but I don't see
- how you will handle adress/data lines going from cart pin to CPU and ROM (don't remember the exact term : bus contention ?)
- if you need to react to the /as signal (on CPU)...and so use /dtack. Because ROM don't care about /as and /dtack ....

I also read you need to handle /time and I didn't still understand why...

So Minty, ready to put a µLinuc on a cart ? ;)

User avatar
TmEE co.(TM)
Very interested
Posts: 2317
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Tue Nov 05, 2013 2:35 pm

MD cartslot gives no bus mastering capability, cart is slave to MD and other way is not possible. You can make your hardware do whatever you want, as long as MD side can do whatever it wants.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

User avatar
MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Tue Nov 05, 2013 2:43 pm

KanedaFr wrote:I'm trying to expend my hw experience ;)
it's why I asked how you plan to do it....
Yes, that's a good idea.
KanedaFr wrote:I understood memory mapping but I don't see
- how you will handle adress/data lines going from cart pin to CPU and ROM (don't remember the exact term : bus contention ?)
- if you need to react to the /as signal (on CPU)...and so use /dtack. Because ROM don't care about /as and /dtack ....
Firstly:

1. The Extra-Processor will be running at a faster Rate than the VDP, 68K and the Z80. As such, we can permit interleaving without upsetting the MD's State. However, we may not actually need to 'take direct control' of the MD's Address Pins and Data. Instead the Code executing on the 68K 'requests' actions to be performed by the Extra-Processor by writing some Commands into a Memory-Mapped Block that the 68K and the Extra-Processor can see: the 68K would have read/write access with the Extra-Processor having only read.

As such, the 68K would be slaving the Extra-Processor as a 'Co-Processor', ok?
KanedaFr wrote:- if you need to react to the /as signal (on CPU)...and so use /dtack. Because ROM don't care about /as and /dtack ....
I do not quite understand what you are trying to say here, Kaneda - could you elaborate further, please?
KanedaFr wrote:I also read you need to handle /time and I didn't still understand why...

So Minty, ready to put a µLinuc on a cart ? ;)
Which Signal is that and do you know what its Purpose and Rate is?

I am no Hardware Developer but if I can appreciate some of the details then I am quite sure that there are Hardware Developers who could do this.

As Examples: Pro Action Replay 2, Everdrive, UMDK.

Why have you not acknowledged UMDK, Kaneda?

User avatar
MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Tue Nov 05, 2013 2:45 pm

TmEE co.(TM) wrote:MD cartslot gives no bus mastering capability, cart is slave to MD and other way is not possible. You can make your hardware do whatever you want, as long as MD side can do whatever it wants.
Indeed, hence the MD slaving the Extra-Processor and communicating with it using some Memory-Mapped Locations to issue Commands and another block to read Status.

User avatar
KanedaFr
Administrateur
Posts: 1116
Joined: Tue Aug 29, 2006 10:56 am
Contact:

Post by KanedaFr » Tue Nov 05, 2013 6:06 pm

MintyTheCat wrote:Why have you not acknowledged UMDK, Kaneda?
What do you mean by this ?
I talked a lot with prophet when he released UMDK1, but I was a real noob at that time. There is now much more things I'm able to understand but I'm not a pro yet ;)

UMDK1 is the perfect example of what I would like to understand and make myself.
But the problem with this one is that is use the /reset line to avoid bus contention....which I would like to avoid

About UMDK2, it's much difficult to understand for me... and too expensive !
Last edited by KanedaFr on Tue Nov 05, 2013 6:14 pm, edited 1 time in total.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest