custom co-processor chips like the SVP?
Moderator: BigEvilCorporation
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.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
-
- Very interested
- Posts: 616
- Joined: Thu Nov 30, 2006 6:30 am
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?
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?
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
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.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.
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.
I'll probably get one after xmas.
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Yes, this topic is of such importance that I'd personally open up another Forum Category for it
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...
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...
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Do you have any Hardware development experience, Kaneda?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 ?
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?
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 ?
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 ?
-
- Very interested
- Posts: 2442
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
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
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Yes, that's a good idea.KanedaFr wrote:I'm trying to expend my hw experience
it's why I asked how you plan to do it....
Firstly: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 ....
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?
I do not quite understand what you are trying to say here, Kaneda - could you elaborate further, please?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 ....
Which Signal is that and do you know what its Purpose and Rate is?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 ?
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?
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
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.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.
What do you mean by this ?MintyTheCat wrote:Why have you not acknowledged UMDK, Kaneda?
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.