custom co-processor chips like the SVP?

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

Moderator: BigEvilCorporation

KanedaFr
Administrateur
Posts: 1139
Joined: Tue Aug 29, 2006 10:56 am
Contact:

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

MintyTheCat wrote:
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?
68k use the /AS signal to tell there is a valid address value on the adress lines, right ?
When the extra CPU receives this signal, it could so define if the 68k is "talking" to him (and so active its data line and disable ROM chip /ce) or to the ROM (and so desactive its data line and enable ROM chip /ce).
How does the CPU say to 68k "hey man! come on! I set all you need on data lines!" ? ;)
I think you need to use /dack, no ?

If yes, what if it takes some times to get the data ready ? does 68k hang or simply wait anytimes needed ? what about interrupts ?

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

Post by MintyTheCat » Tue Nov 05, 2013 6:31 pm

KanedaFr wrote:
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 !
Rest assured, we are working to make it a viable option for MD Developers to use UMDK Version 2. It will also be affordable.

We have been working with Prophet and hope to make a release some time next Year. We are also going to add MIDI Support too.

I feel that this will be perfect for the modern MD Developer given the ability to trace, single-step and interrogate the MD during execution.

Please support Prophet and his UMDK as it has tremendous potential.

KanedaFr
Administrateur
Posts: 1139
Joined: Tue Aug 29, 2006 10:56 am
Contact:

Post by KanedaFr » Wed Nov 06, 2013 8:28 am

I'll support any genny dev related project, like I did since the beginning.
But I'll never forget some people (like me!) are not ready to spend 75$ or more for a "dev cart".

If it needs to spend too much $$$ to dev on Genny, a lot of people won't ever try.
if you're able to supply what it needs to start without even spend a cent, some will take some hours, days, weeks then months to develop the next Sonic ;)
I'm not saying umdk must be free of course !
Prophet made something great releasing the full source and schematic of umdk1 and it's exactly what I'll looking for...it's only missing a "umdk for electronic dummy" which could be done by someone else, letting prophet working on something more interesting.

I hope you understand my goals ;)

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

Post by MintyTheCat » Wed Nov 06, 2013 9:54 am

KanedaFr wrote:I'll support any genny dev related project, like I did since the beginning.
But I'll never forget some people (like me!) are not ready to spend 75$ or more for a "dev cart".
Let's see: that's GBP 46.60 or €55.53 - I still work in British Pounds as I'm British :D

I suppose that it really comes down to how long you are prepared to extend you develoment cycle - I have less time than Money so $75 is not an issue to me personally. What's more, one can use UMDK as a generic FPGA DevBoard so the investment for some evens out and as such is worth while.
KanedaFr wrote: If it needs to spend too much $$$ to dev on Genny, a lot of people won't ever try.
I'd agree that initially there should be little up front Costs to developing but what about the Developers who find themselves taking it seriously? Given that most of us work 40-70 Hours a Week in our 'proper Jobs' how many of us are in a position to devote perhaps four times as much time and effort into MD Development? Being able to single-step, memory-dump at will, trace, etc. all serve to facilitate the development process. I know that prior to this I would have to often write a fair amount of test code to get an 'Answer' to many of my Questions. It is fun but it comes at the expense of being able to work on the whole.
KanedaFr wrote: if you're able to supply what it needs to start without even spend a cent, some will take some hours, days, weeks then months to develop the next Sonic ;)
A Sonic Hack maybe but you'd need to exert considerable effort to realise a wholely new Sonic Game for the MD.
KanedaFr wrote: I'm not saying umdk must be free of course !
Prophet made something great releasing the full source and schematic of umdk1 and it's exactly what I'll looking for...it's only missing a "umdk for electronic dummy" which could be done by someone else, letting prophet working on something more interesting.
Yes, indeed UMDK is Hardware, Software and Firmware and costs some Cash for the physical Components such as the FPGA, Level-Shifters, Connectors, etc.

Prophet has indeed done that but he has also done the same for UMDK version 2 - which is substantially more powerful and feature rich.

If your prime interest is Hardware then yes one would need to understand the Hardware Design for UMDK v1 and UMDK v2 but if you simply wished to use it for MD development then this is actually not necessary as you are simply using the DevBoard - like you would use any other DevBoard for the AVR, PIC, ARM, PPC, etc. to execute the Code that you assemble, link, compile, etc.

If you really wanted to get into writing Firmware then you would need to install the Tools to generate Logic from the VHDL but most Developers will not want to do that and would simply use the Board for their own Projects.
KanedaFr wrote:I hope you understand my goals ;)
I can understand your Goals, kaneda, but I also appreciate that there are many MD Developers out there who would fervently welcome modern Debug Features and being able to single-step, dump MD Memory, trace, trigger on conditions, etc. and the < $75 entry point is not too bad at all for what one could achieve with it and how much sooner the Results could be seen.

In essence: it would completely change how most of us develop Software for the MD and being able to develop directly on the real Hardware will always beat any Emulator. Being able to connect Probes and other Test-Equipment to get accurate Timing-Data and all manner of other Facets will quickly out weigh the benefits of developing under an Emulator.

Plus, should you wish to 'add extra Hardware' to the MD then UMDK would help you to realise such a Goal - it has Gates available that could be used to form further Components or provide an Interface into another Board that could contain other Hardware, etc.

prophet36
Very interested
Posts: 234
Joined: Sat Dec 13, 2008 6:58 pm
Location: London, UK
Contact:

More to life than money!

Post by prophet36 » Wed Nov 06, 2013 12:57 pm

There's a lot of focus on money here, so I just want to make it absolutely clear that at least for me, money is irrelevant.

Everything that is UMDKv2 is freely available on one or another copyleft licence: the schematics, the PCB layout, the VHDL, the firmware, the host-side software, everything. And it's designed so that it's possible to construct at home by someone with a bit of skill with a soldering-iron and no special tools.

I've invested many weeks of my time and hundreds of dollars of my own money in the project in one way or another, but my motivation remains solely to make something cool. I've agreed to make up a few boards for people to play with and hopefully aid their efforts to write a MegaDrive game (and perhaps emulator writers would find the nanosecond-resolution arbitrary-length bus-tracing useful), but I have absolutely no interest in turning it into a commercial product. If someone else wants to take my design and make a commercial product from it, good luck to them: they have my blessing.

That said, I'm not entirely sure about the $75 guess. The component cost looks something like this:

$10 for PCBs
$11 for the LX9 FPGA
$2 for the 16MiB SDRAM
$4 for the USB interface
$3 for the level-shifters
$1 for the config memories
$1 for passives & connectors
Total: $32

KanedaFr
Administrateur
Posts: 1139
Joined: Tue Aug 29, 2006 10:56 am
Contact:

Re: More to life than money!

Post by KanedaFr » Wed Nov 06, 2013 3:20 pm

Well....don't get me wrong, I'm not only talking money, I'm talking easy access to dev product hard or soft.
With the free-to-download files available on your site, it's clear you fillfull the needs ! ;)
Again, I made all I can to make Genny developement easy so it's also my goal to make Genny hardware dev easy.

prophet36 wrote: That said, I'm not entirely sure about the $75 guess.
Oh no, at that time, I only have Everdrive's price in mind...which is a huge price (from my point of view) and difficult to get his hands on !

The component cost looks something like this:

$10 for PCBs
$11 for the LX9 FPGA
$2 for the 16MiB SDRAM
$4 for the USB interface
$3 for the level-shifters
$1 for the config memories
$1 for passives & connectors
Total: $32
:shock: nothing more to say !
I thought FPGA meant 100$ (like the snes quickdev16).... it seems i was wrong !
wow...woooow....wooooooooooooooooow !!!!
:shock:

I pre-order one now !

KanedaFr
Administrateur
Posts: 1139
Joined: Tue Aug 29, 2006 10:56 am
Contact:

Post by KanedaFr » Wed Nov 06, 2013 3:29 pm

MintyTheCat wrote: I'd agree that initially there should be little up front Costs to developing but what about the Developers who find themselves taking it seriously? Given that most of us work 40-70 Hours a Week in our 'proper Jobs' how many of us are in a position to devote perhaps four times as much time and effort into MD Development? Being able to single-step, memory-dump at will, trace, etc. all serve to facilitate the development process. I know that prior to this I would have to often write a fair amount of test code to get an 'Answer' to many of my Questions. It is fun but it comes at the expense of being able to work on the whole.
you got a point....I sure spent too much of my small free time to tools update than pure dev...
I can understand your Goals, kaneda, but I also appreciate that there are many MD Developers out there who would fervently welcome modern Debug Features and being able to single-step, dump MD Memory, trace, trigger on conditions, etc. and the < $75 entry point is not too bad at all for what one could achieve with it and how much sooner the Results could be seen.

In essence: it would completely change how most of us develop Software for the MD and being able to develop directly on the real Hardware will always beat any Emulator. Being able to connect Probes and other Test-Equipment to get accurate Timing-Data and all manner of other Facets will quickly out weigh the benefits of developing under an Emulator.

Plus, should you wish to 'add extra Hardware' to the MD then UMDK would help you to realise such a Goal - it has Gates available that could be used to form further Components or provide an Interface into another Board that could contain other Hardware, etc.
thanks for taking the times to give me your point of view, it seems I missed a very important point...
Perhaps because I'm still on my old way to dev and wasn't able to see a "modern" way.... :oops:

letoulousain
Interested
Posts: 42
Joined: Fri Sep 24, 2010 11:32 pm
Location: toulouse

Post by letoulousain » Sun Nov 09, 2014 12:20 am

doragasu wrote:I have a lot of experience developing systems with Texas Instruments DSPs, both fixed and floating point. Unfortunately, I'm almost new to Megadrive scene and I have near to no spare time. But definitely, I'd love to develop a DSP enabled cartridge if someone was willing to use it.

BTW, does the Megadrive have an audio analog input in the cartridge port? I don't remember having seen the pins when I had a look to the cartridge pinout. A DSP would be extremely useful also to improve music and sfx.
Your proposal is very interesting. :D
I need a faster chip*, compatible sgdk, and a sound chip with its own memory. Think you can make it compatible with sgdk (TI dsp) ?

*with Gens 15Mhz, my projet is perfectly smooth.
thanks to Stef SGDK

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

Post by Chilly Willy » Sun Nov 09, 2014 4:59 am

We've seen some FPGA stuff mentioned. Let's look at a few other choices...

Slow DSP: Zilog Z893x3

Fast DSP: TI TMS320C206

Super Fast Microcontroller: NPX ARM9

Slow DSP - you're basically remaking the SVP. Fast DSP - you're making a FAST SVP. Super fast microcontroller - you're making something like the DPC+ carts for the Atari 2600.

Given the state of ARM compilers and the (low) cost of ARM microcontrollers, that is probably the best bet for a low-cost accelerator cart of the Genesis. You could have it decoding mp3/aac/ogg audio and playing it through PWM while still having the power to do 3D math and render polys. More power than the 32X, but worse graphics since you're still relying on the internal video.

letoulousain
Interested
Posts: 42
Joined: Fri Sep 24, 2010 11:32 pm
Location: toulouse

Post by letoulousain » Sun Nov 09, 2014 9:58 pm

Chilly Willy wrote: Given the state of ARM compilers and the (low) cost of ARM microcontrollers, that is probably the best bet for a low-cost accelerator cart of the Genesis. You could have it decoding mp3/aac/ogg audio and playing it through PWM
Your solutions are interesting. Before ordering prototyping, I want to be sure this is a good choice. I need a SGDK compatible system: How to make it compatible with ARM technology SGDK ?
The ARM chip, which you mentioned (Speed 125 MHz), is not it too fast for the VDP (limited to a maximum of 19 Mhz) ?

french: Vos solutions sont intéressantes. Avant de commander le prototypage, je veux être sûr de choisir la bonne solution, pour obtenir une meilleure vitesse d'exécution, et une parfaite restitution sonore des musiques MP3. J'ai besoin d'un système compatible SGDK: Comment rendre compatible SGDK avec la technologie ARM ? La puce ARM, que vous avez mentionné (Speed 125 MHz), n'est-elle pas trop rapide pour le VDP (limité à un maximum de 19 Mhz) ?
thanks to Stef SGDK

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

Post by Chilly Willy » Mon Nov 10, 2014 12:51 am

Sgdk doesn't support any of these, but it would be easy enough to make a plain gcc cross-compiler for ARM. You need more than just a chip to make a cart like this... just look at the UMDK cart to get an idea of what it takes to make a cart like we talk about in this thread.

As far as clocking the chip goes, that ARM chip generates a bunch of internal clocks (including the main 125MHz clock), and can be PLL locked to a multiple of an external clock.

It has some internal flash rom you'd want to put some boot code in, but you'd mainly want some external SRAM to hook to it to hold the main code and data. It has an external bus controller that gives you eight banks of up to 16MBytes each for things like rom, ram, and memory mapped IO.

Of course it has all sorts of goodies like timers and dma channels and whatnot. Just download the manual from the Digikey page and read through it.

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

Post by MintyTheCat » Tue Nov 11, 2014 5:16 pm

I like the idea of having some extra hardware addressable through memory-mapped ports. In theory one would be able to say "perform some kind of operation on this data and let me know when you are done". Running some kind of light-weight Scheduler running on the ARM or what not would then change status and/or raise an interrupt once done. As fas as the software executing on the MD would be concerned the data would merely be there when it needed it. As such, one could have the ARM/uC/DSP/what ever handle all the heavier maths and simply allow the MD software to consume the data.

I am very interested in augmenting a standard MD Cartridge with extra processing capabilities. It also makes good sense to me to have some kind of Open-Source/Community project in order to develop a kind of next-gen MD Cartridge.

Of course it is very easy to add extra sound hardware to the Cartridge.

When all is said and done it comes down to your intentions and interests: for me personally, I choose to use the MD's VDP otherwise I count it as 'cheating' :D
UMDK Fanboy

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

Post by MintyTheCat » Tue Nov 11, 2014 5:20 pm

Chilly Willy wrote:Sgdk doesn't support any of these, but it would be easy enough to make a plain gcc cross-compiler for ARM. You need more than just a chip to make a cart like this... just look at the UMDK cart to get an idea of what it takes to make a cart like we talk about in this thread.

As far as clocking the chip goes, that ARM chip generates a bunch of internal clocks (including the main 125MHz clock), and can be PLL locked to a multiple of an external clock.

It has some internal flash rom you'd want to put some boot code in, but you'd mainly want some external SRAM to hook to it to hold the main code and data. It has an external bus controller that gives you eight banks of up to 16MBytes each for things like rom, ram, and memory mapped IO.

Of course it has all sorts of goodies like timers and dma channels and whatnot. Just download the manual from the Digikey page and read through it.
I feel that it better to come up with some kind of Specification/Requirements list for a custom MD Cart.

To augment that I would then consider putting together Demos that demonstrate the facilities to kind of 'inspire' and inform Developers but it all makes perfectly good sense to me in this day and age.

Indeed, looking at the Action-Replay Carts and UMDK is a good place to start.
UMDK Fanboy

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

Post by Chilly Willy » Tue Nov 11, 2014 6:49 pm

Yes, a spec sheet would allow anyone to make a compliant cart without needing the exact same parts. If one were to use an ARM mcu, you'd need to specify what level (7 or 9 probably) and if there were to be any required extras (like built in DMA channels or timers). You'd need to specify a minimum amount of ram and where it was mapped. Things like that.

I think most people wouldn't consider it "cheating" as long as it only uses what is available on the cart edge. No jumper cables or the like. You know, like half the SNES carts with their extra coprocessors inside. A Genesis cart with an ARM chip inside is basically a SNES cart with the FX2... but much MUCH faster. 8)

I think the recent port of Wolf3D for the MD shows there's still a decent amount of life left in the MD VDP. Not to mention, a cart like we describe could make better use of the direct color dma mode, like my CD demo times a thousand. :D

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

Post by MintyTheCat » Tue Nov 11, 2014 8:36 pm

Chilly Willy wrote:Yes, a spec sheet would allow anyone to make a compliant cart without needing the exact same parts. If one were to use an ARM mcu, you'd need to specify what level (7 or 9 probably) and if there were to be any required extras (like built in DMA channels or timers). You'd need to specify a minimum amount of ram and where it was mapped. Things like that.

I think most people wouldn't consider it "cheating" as long as it only uses what is available on the cart edge. No jumper cables or the like. You know, like half the SNES carts with their extra coprocessors inside. A Genesis cart with an ARM chip inside is basically a SNES cart with the FX2... but much MUCH faster. 8)

I think the recent port of Wolf3D for the MD shows there's still a decent amount of life left in the MD VDP. Not to mention, a cart like we describe could make better use of the direct color dma mode, like my CD demo times a thousand. :D
I was actually thinking more along the lines of system requirements first of all before hardware was considered.

Yes, so long as the MD's VDP is not bypassed it is fine for me but we are all different in our opinions of what constitutes 'cheating' :D
UMDK Fanboy

Post Reply