Testing with real hardware is great but you should invest in a flash cart only if you need it.
If you use SGDK and no special hardware trick, it's not needed TO START.
Be sure it won't be money wasted
I say that but I remember the first time I tried my first demos on real hardware :
I made an awful mistake with shadow/hilight on one and totally misunderstood the window plane on another (after months of work)
The normal Everdrive seems to have a built-in limitation so, say, if you purchased a popular RPG homebrew around 64 it would not play. The Mega Everdrive has been seen running huge mods to Mortal Kombat so the hardware limitation may be lifted in that version.
If you are developing 64meg games then you'll probably have to make your own bankswitch scheme. Whether any flash cart will support your own bankswitch format is, er, unknown.
Another aspect of testing 64meg ROMs is that some products do not check their own limitations and may overwrite critical firmware code. I have personally bricked an "MD Station MD Lite" portable GOAC this way.
If you're talking about Pier solar, i've already my classic edition
To be clear, i want to do a 64meg rom by using a bankswitch beetween 2 * 27c322 prom.
I've built a test cart but i have to burn my 2 * 27c322 every time to test on real hardware, that's why i wanted to find an easier way to test my program
For the rest, i'm not good enough to understand what you're talking about
@oofwill: I think you managed to get what little information I had in that post.
The bottom line is 64meg games require bankswitching which may not be implemented by the flash cart. Unlike NES titles I don't *think* bankswitching was used much in Genesis games. I may be wrong though.
It's games bigger than 4MB that use bank switching. Any bank switching is in the cart, so you'd have to handle it yourself, and doing any kind of bank switching other than the standard mapper would prevent your code from working on emulators.
While a CD probably would be cheaper than a flash cart, SCDs only read CDRs, not CDRWs, so you'd need to burn a new CDR for every single test you did, quickly negating the savings. You COULD do early testing on an emulator and just final tests on real hardware, but the SCD is much more complex than the MD, making it a bad choice to START on when first getting into MD programming. So a flash cart is still the best bet for someone getting into MD programming.
KRIKzz creates great things for acceptable price.
I recommend his creatures.
I have Mega EverDrive MD currently. It works very well for my sega mega drive game development.
Even on mac os x.
P.S. My ROMs fly in into Sega from my IDE with speed of light.
KanedaFr wrote:Gens
...
I say that but I remember the first time I tried my first demos on real hardware :
I made an awful mistake with shadow/hilight on one and totally misunderstood the window plane on another (after months of work)
Some hardware restrictions are not enforced by the emulators, for example accessing unaligned memory locations works (*differently) on emulators but will crash real hardware.
It is true that emulators does not handle many restrictions you have on the actual hardware but if you use a C compiler it already limit the number of mistakes you can do. By using SGDK library you are also very robust against real hardware, I am always pleased to see that after a long development and tests period on emulators that my program work on the first try on the real hardware (it was the case for my "bad apple" video demo)
Chilly Willy wrote:While a CD probably would be cheaper than a flash cart, SCDs only read CDRs, not CDRWs, so you'd need to burn a new CDR for every single test you did, quickly negating the savings. You COULD do early testing on an emulator and just final tests on real hardware, but the SCD is much more complex than the MD, making it a bad choice to START on when first getting into MD programming. So a flash cart is still the best bet for someone getting into MD programming.
The SCD is still quite cheap. I have been doing SCD development for almost 2 years now and just finishing up my second spindle of 50 CDs (reminds me that I need to buy more). I do most of my testing with Gens. Then when after major changes, I try it on Fusion too. After it works on the emulators then I try it on real hardware and on a new project I might use a few CDs to debug something inconsistent between hardware and emulators but on an established project it typically works as expected on the first CD. I do agree the SCD is harder because it is another layer to learn.
Chilly Willy wrote:It's games bigger than 4MB that use bank switching. Any bank switching is in the cart, so you'd have to handle it yourself, and doing any kind of bank switching other than the standard mapper would prevent your code from working on emulators.
While a CD probably would be cheaper than a flash cart, SCDs only read CDRs, not CDRWs, so you'd need to burn a new CDR for every single test you did, quickly negating the savings. You COULD do early testing on an emulator and just final tests on real hardware, but the SCD is much more complex than the MD, making it a bad choice to START on when first getting into MD programming. So a flash cart is still the best bet for someone getting into MD programming.
Some 3 - 4 MB games use bank switching as well (World Series 95, Mortal Kombat 3, etc). WS95 is a 3 MB game, so I'm assuming the board takes 2 2MB eproms. Would you be able to use that with 4 MB eproms or no?
elusive wrote:Some 3 - 4 MB games use bank switching as well (World Series 95, Mortal Kombat 3, etc). WS95 is a 3 MB game, so I'm assuming the board takes 2 2MB eproms. Would you be able to use that with 4 MB eproms or no?
Uh, why would you use bank switching on a game SMALLER than the space you have available? Not to mention, I've never seen bank switching code in emulators other than the standard mapper... are you SURE those games use bank switching?
Some 3 - 4 MB games use bank switching as well (World Series 95, Mortal Kombat 3, etc). WS95 is a 3 MB game, so I'm assuming the board takes 2 2MB eproms. Would you be able to use that with 4 MB eproms or no?
What you call bankswitching is a simple address decoding logic which select ROM chip upon address lines asserted by the console. There are no ROM banks but different chips and no switching but simple chip selection so technically it's not bankswitching
Bankswitching is when a single memory mapped area can be assigned to different ROM pages and this is usually handled by more complex logic or dedicated hardware.
