Page 2 of 3
Posted: Wed Sep 05, 2012 2:45 pm
by KanedaFr
Gens
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)

Posted: Wed Sep 05, 2012 3:13 pm
by oofwill
Does everdrive support 64Meg games?
This site says Super street fighter II is supported, (40Meg?)
Posted: Wed Sep 05, 2012 3:18 pm
by slobu
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.
Posted: Wed Sep 05, 2012 3:40 pm
by oofwill
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
Thanks anyway for responding me

Posted: Wed Sep 05, 2012 4:28 pm
by slobu
@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.
Posted: Wed Sep 05, 2012 5:47 pm
by oofwill
I'm not very easy with bankswitching but i thought all games > 2Mo use bankswitching.
I have this idea since all games>2Mo i have opened have 2 proms and chip like 74ls139... for bankswithing?
Posted: Wed Sep 05, 2012 6:44 pm
by Chilly Willy
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.
Posted: Wed Sep 05, 2012 11:33 pm
by greatkreator
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.
Posted: Thu Sep 06, 2012 12:03 am
by ammianus
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.
Posted: Thu Sep 06, 2012 7:50 am
by Stef
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)

Posted: Thu Sep 06, 2012 1:33 pm
by bgvanbur
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.
Posted: Thu Sep 06, 2012 4:52 pm
by elusive
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?
Posted: Thu Sep 06, 2012 5:13 pm
by oofwill
I used to build cartmod with lion king PCB (3Mo, 2 eproms) and this works really great with those pcb and 37c322 (4Mo) eproms.
It seems to me only thing is to redirect /OE input and A20 address (pin 32) to B9 pin (cartidge connector)
Posted: Thu Sep 06, 2012 5:48 pm
by Chilly Willy
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?
Posted: Thu Sep 06, 2012 8:26 pm
by Eke
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.