Megadrive: Custom-Cartridge including extra capabilities
Moderator: Mask of Destiny
-
- Very interested
- Posts: 141
- Joined: Thu Aug 22, 2013 3:47 am
- Location: Venezuela - Caracas
- Contact:
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).
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).
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
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.
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.
-
- Very interested
- Posts: 141
- Joined: Thu Aug 22, 2013 3:47 am
- Location: Venezuela - Caracas
- Contact:
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.
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.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
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.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.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
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.
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
UMDK as target hardware for a commercial game has never been a consideration for a commercial game - it is a Development Tool.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 Fanboy
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
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.MintyTheCat wrote:UMDK as target hardware for a commercial game has never been a consideration for a commercial game - it is a Development Tool.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.
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.
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 ?
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 ?
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
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.Chilly Willy wrote: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.MintyTheCat wrote:UMDK as target hardware for a commercial game has never been a consideration for a commercial game - it is a Development Tool.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.
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.
UMDK Fanboy
-
- Very interested
- Posts: 89
- Joined: Mon Feb 24, 2014 6:04 pm
- Location: Kapuskasing, Ontario, Canada
- Contact:
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.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 ?
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
http://www.db-electronics.ca
-
- Very interested
- Posts: 89
- Joined: Mon Feb 24, 2014 6:04 pm
- Location: Kapuskasing, Ontario, Canada
- Contact:
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.KanedaFr wrote:I really need to understand how this /time works, it"s some kind of magic for me !
What does db stand for? Well that's an excellent question...
http://www.db-electronics.ca
http://www.db-electronics.ca
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
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
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
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 evenKanedaFr 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
UMDK Fanboy