Megadrive: Custom-Cartridge including extra capabilities

Want to create a team or share a project ?

Moderator: Mask of Destiny

gasega68k
Very interested
Posts: 141
Joined: Thu Aug 22, 2013 3:47 am
Location: Venezuela - Caracas
Contact:

Post by gasega68k » Mon Nov 24, 2014 10:02 pm

With a resolution of 224 x 192 in H32 mode (like Starfox SNES) or 288 x 192 in H40, you can transfer the buffer in 2 frames, ie we would have a maximum of 30fps.

For the design of this cartridge is better to use Sram, and also are not very expensive:

128KB(64kx16)
http://www.digikey.com/product-detail/e ... ND/4234580

256KB(128kx16)
http://www.digikey.com/product-detail/e ... ND/4234584

512KB(256kx16)
http://www.digikey.com/product-detail/e ... ND/4691814

For resolutions that I have proposed above, a buffer less than 32K would need. 288 x 192 = 27648 bytes (55296/2, 4 bit color).

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

Post by Chilly Willy » Tue Nov 25, 2014 1:05 am

Also remember that using a frame buffer and helper hardware for rendering allows for Direct Color DMA screens. You would need 198x224x2 = 88704 (max of 224 lines) for H40 mode, or 161x224x2 = 72128 for H32 mode, per buffer. The main limitations here are the reduced resolution (160 or 128 wide), and the constant DMA over much of the frame, leaving less time for the 68000.

Frankly, I see DCD mode as more viable on the ARM version of the cart than on the FPGA version. Not that the FPGA version wouldn't be capable, you'd just need a bit more work in the FPGA to make the mode as useful... like making a small RISC core inside the FPGA to act as a processor while the DMA holds off the 68000.

The SCD was ideally suited for DCD mode. It has dual banks of ram that can be flipped between the two sides, the banks are big enough for a full frame (plus some extra), and the separate faster CPU can work while the MD side is mostly frozen due to DMA. You'd want a copy of that kind of setup on the cart to make DCD mode shine.

gasega68k
Very interested
Posts: 141
Joined: Thu Aug 22, 2013 3:47 am
Location: Venezuela - Caracas
Contact:

Post by gasega68k » Tue Nov 25, 2014 4:50 am

Using the "Direct Color Dma" and with the help of a "ARM" chip, the best kind of games would be the style of Doom or Duke Nukem 3D, or even fully 3D games based on polygons with textures (half-life? ). :)

I do not know how this ARM will be compared for example with the GBA, using an ARM7 with 16mhz and still is able to handle a Duke Nukem at a good speed.

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

Post by Chilly Willy » Tue Nov 25, 2014 5:30 am

gasega68k wrote:Using the "Direct Color Dma" and with the help of a "ARM" chip, the best kind of games would be the style of Doom or Duke Nukem 3D, or even fully 3D games based on polygons with textures (half-life? ). :)

I do not know how this ARM will be compared for example with the GBA, using an ARM7 with 16mhz and still is able to handle a Duke Nukem at a good speed.
The ARM chip I posted a link to earlier is 125 MHz. These days, it's hard to get one lower than about 50 MHz. :)

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

Post by Chilly Willy » Tue Nov 25, 2014 8:49 am

Oh, one more thing I think needs to be pointed out here - the carts need to be compatible with the CD and 32X. UMDK is good, but specifically states it's not compatible with the CD. In fact, it suggests it might damage the CD or the board. So UMDK is good for a developer cart, but can't remotely be considered for a commercial game. At least not without redoing the FPGA code to eliminate the conflict.

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

Post by MintyTheCat » Wed Nov 26, 2014 12:30 am

Chilly Willy wrote:Oh, one more thing I think needs to be pointed out here - the carts need to be compatible with the CD and 32X. UMDK is good, but specifically states it's not compatible with the CD. In fact, it suggests it might damage the CD or the board. So UMDK is good for a developer cart, but can't remotely be considered for a commercial game. At least not without redoing the FPGA code to eliminate the conflict.
UMDK as target hardware for a commercial game has never been a consideration for a commercial game - it is a Development Tool.
UMDK Fanboy

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

Post by Chilly Willy » Wed Nov 26, 2014 2:03 am

MintyTheCat wrote:
Chilly Willy wrote:Oh, one more thing I think needs to be pointed out here - the carts need to be compatible with the CD and 32X. UMDK is good, but specifically states it's not compatible with the CD. In fact, it suggests it might damage the CD or the board. So UMDK is good for a developer cart, but can't remotely be considered for a commercial game. At least not without redoing the FPGA code to eliminate the conflict.
UMDK as target hardware for a commercial game has never been a consideration for a commercial game - it is a Development Tool.
Sorry, I'm thinking of another thread that was like this one. Someone was asking about an FPGA or fast ARM cart, and I brought up the MegaEverDrive as an example of an existing FPGA cart, and someone badgered me about, asking why I even mentioned the MED when the UMDK was completely open source and free to use for commercial games while you'd have to cut some kind of deal with KRIKzz to use the MED for a commercial game.

But my point stands... a collaborative card should be designed to at least not damage any official Sega consoles. It might not work (like the VR cart doesn't work on the Model 3 or Nomad without a hack), but it MUST NOT cause any harm. Ideally, it should work fine with both the CD and the 32X, and if possible the Nomad and Model 3.

A double-bank frame buffer, some generic dram local to the accelerator, and an accelerator (FPGA or MPU), where one bank of the frame buffer is accessible to the Genesis side while the other is accessible to the accelerator, would be compatible with the most consoles.

bastien
Very interested
Posts: 208
Joined: Mon Jun 25, 2007 7:19 pm
Location: Besançon,France
Contact:

Post by bastien » Wed Nov 26, 2014 5:50 am

If you use FPGA and a way for reconfigure it ( JTAG) we can made different configuration files.
Thats the way i use for my custom Flash card ( i share it soon )

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

Post by KanedaFr » Wed Nov 26, 2014 9:06 am

hi,
May I ask you how you intent to "talk" with the additional cpu/ic/whatever ?

Will you lost some space using the upper address available ?
Since you had to support MCD support, it means the MSB just before 0x400000, no ?

When I thougth some times ago about something like this, I remembered how the 68k talks with the z80 :
wait for sub CPU (z80) to be ready
ask for data bus ( not needed in our case ?)
send some commands or write some data for the z80 on the shared memory region
tell the sub CPU (z80) to continue
the sub CPU (z80) will check on the memory what should be done and starts its private job

Is it the way to do in our case ?

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

Post by MintyTheCat » Wed Nov 26, 2014 11:04 am

Chilly Willy wrote:
MintyTheCat wrote:
Chilly Willy wrote:Oh, one more thing I think needs to be pointed out here - the carts need to be compatible with the CD and 32X. UMDK is good, but specifically states it's not compatible with the CD. In fact, it suggests it might damage the CD or the board. So UMDK is good for a developer cart, but can't remotely be considered for a commercial game. At least not without redoing the FPGA code to eliminate the conflict.
UMDK as target hardware for a commercial game has never been a consideration for a commercial game - it is a Development Tool.
Sorry, I'm thinking of another thread that was like this one. Someone was asking about an FPGA or fast ARM cart, and I brought up the MegaEverDrive as an example of an existing FPGA cart, and someone badgered me about, asking why I even mentioned the MED when the UMDK was completely open source and free to use for commercial games while you'd have to cut some kind of deal with KRIKzz to use the MED for a commercial game.

But my point stands... a collaborative card should be designed to at least not damage any official Sega consoles. It might not work (like the VR cart doesn't work on the Model 3 or Nomad without a hack), but it MUST NOT cause any harm. Ideally, it should work fine with both the CD and the 32X, and if possible the Nomad and Model 3.

A double-bank frame buffer, some generic dram local to the accelerator, and an accelerator (FPGA or MPU), where one bank of the frame buffer is accessible to the Genesis side while the other is accessible to the accelerator, would be compatible with the most consoles.
As far as I can tell the only thing that would need to be done to make UMDK compatible with the MCD and 32X would be to change the memory-map that UMDK uses and to restrict it so that the reserved locations used by the MCD and 32X would not be occupied by UMDK Registers. I would have to ask Prophet36 if I am 100% correct here though.
UMDK Fanboy

db-electronics
Very interested
Posts: 89
Joined: Mon Feb 24, 2014 6:04 pm
Location: Kapuskasing, Ontario, Canada
Contact:

Post by db-electronics » Thu Nov 27, 2014 2:46 pm

KanedaFr wrote:hi,
May I ask you how you intent to "talk" with the additional cpu/ic/whatever ?

Will you lost some space using the upper address available ?
Since you had to support MCD support, it means the MSB just before 0x400000, no ?

When I thougth some times ago about something like this, I remembered how the 68k talks with the z80 :
wait for sub CPU (z80) to be ready
ask for data bus ( not needed in our case ?)
send some commands or write some data for the z80 on the shared memory region
tell the sub CPU (z80) to continue
the sub CPU (z80) will check on the memory what should be done and starts its private job

Is it the way to do in our case ?
We could use the #TIME range to implement a set of control registers, backwards compatible with the SSF2 mapper, which would allow the 68k to BUSREQ the hypothetical cart hardware.

Suppose the cart hardware consists of another CPU with its own RAM. Well, that system could live in its own address space, and, when a frame (or whatever other data) needs to be read by the 68k, it could BUSREQ the CPU's RAM which would proceed to be mapped somewhere in the cartridge space (preferrably 0x200000 as it is RAM). The 68k then DMAs what it needs and finally returns the RAM to the cart's CPU.
What does db stand for? Well that's an excellent question...
http://www.db-electronics.ca

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

Post by KanedaFr » Thu Nov 27, 2014 3:09 pm

oh! and on the same, you can talk to the sub cpu writing command on its RAM

I really need to understand how this /time works, it"s some kind of magic for me !

db-electronics
Very interested
Posts: 89
Joined: Mon Feb 24, 2014 6:04 pm
Location: Kapuskasing, Ontario, Canada
Contact:

Post by db-electronics » Thu Nov 27, 2014 3:11 pm

KanedaFr wrote:I really need to understand how this /time works, it"s some kind of magic for me !
Very simple, it's simply a chip-select signal for the address range 0xA13000 -> 0xA130FF very much the same as how #CE is a chip-select for the cartridge in the address range 0x000000 -> 0x3FFFFF.
What does db stand for? Well that's an excellent question...
http://www.db-electronics.ca

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

Post by KanedaFr » Thu Nov 27, 2014 3:48 pm

oooh....
thanks, with this info, I found some interesting posts that I missed
viewtopic.php?t=869
viewtopic.php?t=235

Very interesting...
Hopefully I have some useful hardware to make test ;)

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

Post by MintyTheCat » Thu Nov 27, 2014 4:11 pm

KanedaFr wrote:oooh....
thanks, with this info, I found some interesting posts that I missed
viewtopic.php?t=869
viewtopic.php?t=235

Very interesting...
Hopefully I have some useful hardware to make test ;)
Assuming we do not die (I could get abducted by Aliens in the middle of Berlin...) you will be able to use our Custom-Cart one day. I am writing the Math code as I type this even :)
UMDK Fanboy

Post Reply