~ OPENSOURCE USB CARTRIGE DEVELOPMENT ~
Well, my idea is to make the whole thing opensource and have a tool that would allow you build a ROM given the base and a series of binary music files (probably in SMPS format) and the chart files (there's already an excellent tool called Feedback that's used for creating GH custom charts, we could convert from that format). There exists a tool created by someone called nineko at my Sonic Retro forums which takes XM files (optimally created with this tool in mind) and converts them to SMPS format. I think it could work, and as I said I'll elaborate much more later and go into detail as to what I was thinking about. I don't want to clutter up this thread with something that's only tangentially related.
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
Woooow great ideas, but I think the cart needs to be developed first, which itself is not very easy...
Btw that SMPS... Thats the sound engine that sonic games use isn't it? Is that legal? (using the sound format/engine from sega?)
And does that PSX2MD supports the guitar? I think the PS controller has a serial interface... It wouldn't be easy to connect directly, maybe a microcontroller between...
Btw that SMPS... Thats the sound engine that sonic games use isn't it? Is that legal? (using the sound format/engine from sega?)
And does that PSX2MD supports the guitar? I think the PS controller has a serial interface... It wouldn't be easy to connect directly, maybe a microcontroller between...
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
If we made the FPGA programmable from the MD (or maybe via USB), it could be updated to add things as they were developed. For example, SSF2 bank selecting could easily be added as an option to the FPGA. How much memory it gave would depend on the RAM used. So the key elements would be:
FPGA - needed for control and goodies
RAM - SDRAM/PSRAM/DDR/DDR2... just something with plenty of space
SD-card slot - necessary storage medium, better than having the CD.
EEPROM - programmable by the MD, used by the FPGA for initial state and GUI/BIOS for MD (may need two EEPROMs depending on the design).
USB - while it could be optional, having USB means you could use it for transferring data from a PC, or even better - hooking up a N64/PSX/PS2/XBox/etc controller via the cheap USB adapters.
If you had a board with those items, anything else can be handled via updates to the FPGA EEPROM. You want SSF2 bank selecting? Add it to the FPGA. You want a graphics coprocessor? Add it to the FPGA. You want DMA 16 channel audio? Add it to the FPGA. You'd only be limited by the number of gates, and as shown earlier, 5K and 10K logic blocks are cheap with the Cyclone III. Once you get above 10K, then the price starts to climb.
FPGA - needed for control and goodies
RAM - SDRAM/PSRAM/DDR/DDR2... just something with plenty of space
SD-card slot - necessary storage medium, better than having the CD.
EEPROM - programmable by the MD, used by the FPGA for initial state and GUI/BIOS for MD (may need two EEPROMs depending on the design).
USB - while it could be optional, having USB means you could use it for transferring data from a PC, or even better - hooking up a N64/PSX/PS2/XBox/etc controller via the cheap USB adapters.
If you had a board with those items, anything else can be handled via updates to the FPGA EEPROM. You want SSF2 bank selecting? Add it to the FPGA. You want a graphics coprocessor? Add it to the FPGA. You want DMA 16 channel audio? Add it to the FPGA. You'd only be limited by the number of gates, and as shown earlier, 5K and 10K logic blocks are cheap with the Cyclone III. Once you get above 10K, then the price starts to climb.
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
But adding features like the graphics co-processor requires extra wiring that is absent from the cartridge port, and probably no one will use it, because it's too specific...
Thats why I'm not designing a cart, but rather a permanent addon that every game will benefit somehow from it. (like that hardware divider that will spy any divu/divs from the rom)
Also how can one update via USB the FPGA configuration, if the USB implementation is also inside the... FPGA? For that there has to be some kind of redundancy...
Thats why I'm not designing a cart, but rather a permanent addon that every game will benefit somehow from it. (like that hardware divider that will spy any divu/divs from the rom)
Also how can one update via USB the FPGA configuration, if the USB implementation is also inside the... FPGA? For that there has to be some kind of redundancy...
Sega doesn't seem to give a shit what we do with the classic Sonic stuff as long as we're not trying to make a profit. Look at how openly the S2B/Sonic Retro forums hack the games and even distribute full disassemblies, not to mention the two Sonic 2 prototypes. Since this would be an open source project (with one of the Creative Commons non-commercial licenses) I don't really think they'll give a shit. The reason I would choose SMPS is because there is an XM to SMPS converter so if you compose an XM with that in mind then it might be easier to get non-Genesis scene people to make music for the game.Jorge Nuno wrote:Btw that SMPS... Thats the sound engine that sonic games use isn't it? Is that legal? (using the sound format/engine from sega?)
Even still, if that is undesirable, we could still use the format but we'd have to code our own replayer that would read that format. Formats are legal to use no matter what.
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
I don't mean something that gives better graphics, just a coprocessor that helps draw, much like the ASIC in the CD. It would draw using only data in the on-cart RAM to the on-cart RAM, then the standard methods of DMAing from cart to VRAM would be used to display it.Jorge Nuno wrote:But adding features like the graphics co-processor requires extra wiring that is absent from the cartridge port, and probably no one will use it, because it's too specific...
Another type of coprocessor that would be handy without any extra lines is one like in the Virtua Racer cart - something that just computed vectors. Some type of fixed point processor for 3D would be very handy as the 68000 wouldn't be very fast with that.
Yes... the chicken and the egg dilemma. Probably best not to worry about reprogramming over the USB.Also how can one update via USB the FPGA configuration, if the USB implementation is also inside the... FPGA? For that there has to be some kind of redundancy...
Why not just develop a whole new system.....I'm not entirely sure what you're trying to achieve here?Another type of coprocessor that would be handy without any extra lines is one like in the Virtua Racer cart - something that just computed vectors. Some type of fixed point processor for 3D would be very handy as the 68000 wouldn't be very fast with that.
From the spec of this cartridge it seems you plug it in and the megadrive is made all but redundant...
You're not achieving anything amazing via the Megadrive itself...just simply bypassing half the hardware and giving it a load of beefed up extras.. ala a 32X mark 2
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
The idea is to start with a cart that gives extra RAM, an SD-card interface, and maybe USB. Anything else would be more for devs who wanted to experiment. You might have seen various things others have done - overclocked CPUs, hacks to the audio circuits, etc. Additions to the FPGA would be the same, but since the FPGA is programmable, you'd be able to share your hacks in a way that most hardware hacks can't be.matteus wrote:Why not just develop a whole new system.....I'm not entirely sure what you're trying to achieve here?Another type of coprocessor that would be handy without any extra lines is one like in the Virtua Racer cart - something that just computed vectors. Some type of fixed point processor for 3D would be very handy as the 68000 wouldn't be very fast with that.
From the spec of this cartridge it seems you plug it in and the megadrive is made all but redundant...
You're not achieving anything amazing via the Megadrive itself...just simply bypassing half the hardware and giving it a load of beefed up extras.. ala a 32X mark 2
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
There aren't that many people using these consoles anymore in any case, and probably 99.999% of the people "using" the Genesis are actually emulating it on a computer. If an add-on were in big enough demand due to some "awesome" new game using it, it could always just be added to one of the emulators to hit most of the users. For example, let's say that a cart was made with only 4MB of RAM to allow larger games that loaded levels off the CD. If a game or two came out using that 4MB RAM cart and people saw how great the games were and wanted to be able to run them, PicoDrive or DGen could EASILY be altered to have 4MB of RAM in the cart location so those games worked with the emulators.
YEAH WHY NOT USE NORMAL USB /FEMALE/ FOR GAMEPADS TOO...
CAN BE THAN PC-MD DATA TRANSFER RELEASED WITH MALE-MALE USB CABLE /but that net cable is not cheap/...
So what about GAMEPADS 2x FEMALE USB /normal PC USB/ + PC 1x Mini-USB /PC DATA like on PRINTER or CAM/???
1./ USB FLASHCART
2./ USB DRIVERS /gamepad ,mouse ,midi keyboard etc.../
and then games with USB support...
CAN BE THAN PC-MD DATA TRANSFER RELEASED WITH MALE-MALE USB CABLE /but that net cable is not cheap/...
So what about GAMEPADS 2x FEMALE USB /normal PC USB/ + PC 1x Mini-USB /PC DATA like on PRINTER or CAM/???
1./ USB FLASHCART
2./ USB DRIVERS /gamepad ,mouse ,midi keyboard etc.../
and then games with USB support...