I have plans for some very ambitious projects which might not ever happen. If they do, they definitely won't happen anytime soon. However, since I don't quite know all the features and limitations I'd be working with, I have no idea if any of my plans are at all feasible. Although I ask right now mostly to satisfy my curiosity and give some ground to my ideas, I might actually put the answers given into practice some time in the future. I'll spoiler them into categories so they're easy to keep track of. Spoiler: SRAM What is the maximum size of SRAM? How feasible would it be to store artwork, code, music, etc. within it? A hardware only bug I ran into earlier suggests that it might possible to run code directly from SRAM just by enabling it and jumping into its' address space, but that leads to my next concern... Why are we supposed to only use the odd bytes? It makes running code and loading assets directly from it more difficult, since it'd be cut up between bytes and would have to be written to a buffer space before it could be used. It also cuts the effective maximum size of SRAM in half... Spoiler: Sega CD Is it possible to boot Mode 2 games from Mode 1? Or would you have to boot the Sega CD Bios, then load it from there? Is it even possible to boot into the Sega CD bios itself from Mode 1 without keeping an on cart copy of it? Spoiler: 32X Is it possible to make a 32X "enhanced" game that can take full advantage of the peripheral when it's connected, but will still run without it? A quick look suggests that they have different headers, but I don't know how much of it is needed on the 32X side; it might be possible to abuse unused/unnecessary data in both headers to make it boot in both scenarios. Spoiler: Misc Is there a way to detect what type of controller is plugged in? It'd be great to tell the difference between a 3-button controller, 6-button controller, mouse, etc. from software. Is there a way to make two Mega Drive carts talk to each other? The closest thing I can think of is using Sega CD SRAM as an in between, but that's clunky and could result in lost data if it's overwritten between cart swaps. It'd likely be much easier to just tell users to merge their SRAM with an external tool (which is likely what I'll end up doing for this), but a way to do it using only hardware would be really neat. Is there a way to get a game to talk to the internet? Obviously, retro channel is down and was only supported by a fairly outdated emulator, and this thing probably isn't worth the effort to buy and setup, but a reasonable alternative could really open things up.
Not much I can answer but the MAXIMUM Size for the SRAM would very between 8kb or 32kb as far as my knowledge goes. And yes it is technically possible to get the Megadrive on the interwebz by using some sort of code, obviously this was proven and used by Sega Channel, Sega Meganet, X Band Network, and well retro channel but that was communicating with a plugin but overall I rather go with plugin comunicatting since manufacturing hardware for an internet port on the sega genesis is hard although I don't know about the serial port on the model 1 genesis.
Correct me if I'm wrong. The SRAM is usually about a kilobyte. I don't know about SRAM, but RAM is readable and writable, so you can store anything there that can fit and even read code from it. The limitations, besides the size of the space, is that the data has to come from somewhere. It can either come from the cart, or be produced by some code. I assume you can do the same with SRAM, though I don't know any practical uses for it, unless you want to save some self-modifying code. My guess about the 32x thing is that it's possible since the 32x cartridges don't hold anything special, but it would be way easier just to create two versions. That way you can save development time and cartridge space. My guess for this is no, since the controllers send no other information through the cable than just the button inputs, and it's up to the game to interpret them. You could just let the player select their controller if you're going to make the game differ depending on the controller used. I think you are confusing SRAM with cartridge space. SRAM is just to store saved games and stuff. If you want cartridge space beyond 4MB, you're going to either have to make use of bank switching, in which you change where in the cartridge the data is read from mid-game, or just make a Sega CD game. Merging two cartridges wouldn't work because the cartridge data is copied to the console's memory before the game starts and the cartridge is already capable of holding more data than the console can store. You will have to use a custom emulator or emulator plugin to be able to connect a game to the internet.
I'm aware that SRAM is usually small, but I'm trying to push the limits. The absolute maximum that can be supported by emulators, flash carts, etc. is what I'm hoping to find out. As for me appearing to misuse it, I understand your concerns, but I can't explain my reasoning without giving the idea away...
So you do mean SRAM? Okay. It just seemed odd that you'd be asking this stuff about SRAM. According to this, the max is 32kb. From what I know, using two connected cartridges would work because you could just move the data to RAM, though it would probably be easier to add another battery to one cartridge than mod a cartridge to connect to another or mod a Sonic & Knuckles cartridge to support a battery. The only issue is that I don't know the limits of the SRAM locations you can load from. Also, you can read code from SRAM by just moving it to RAM.
The SRAM usually is either odd or even bytes only to save manufacturing costs, however even+odd SRAM is not only possible, but also supported and was used by some games. There is no theoretical limit to SRAM, but going with the common setup you hit issues going above 2MB. You could always bankswitch SRAM in cart so you can bypass the limit. Regen as a notable example supports whopping $400 bytes of it. This fact does mean, you can run code from SRAM but you probably shouldn't. SRAM is likely going to be slower memory and able to degrade on production cartridge, so really avoiding unnecessary reads and writes is a good idea. Standard 3-button controller does not support any controller detection whatsoever, so you gotta trust your users use one when programming. However 6-button pads and other nonstandard crap pretend to press left, right, up and down at the same time, which can be used to detect them since that button combination is reasonably impossible. I have a tutorial that supports 3 and 6 pads + EA and SEGA 4 way adapters with both types of controllers, so if you wanna learn how many hoops you have to jump through to read them, you are welcome to have a look. Only way you can make 2 physically separate carts talk to each other is through system RAM, VRAM, CRAM, VSRAM and Z80 RAM. This requires you to hotswap carts which is a terrible idea, but if your 68k is running code in RAM, in theory there should be no crashing happening. Interestingly, you can abuse this with Mega Everdrive to dump ROMs - in theory.
Well, there was a link cable which was only used by Zero Tolerance. Interestingly enough, not even Sega Retro has much information about it, but a quick Google search reveals someone that does: http://www.sega-16.com/2009/12/sega-gear-zero-tolerance-link-cable/.
Alright, let's answer a few of these! Mode 2 games generally can't be booted from Mode 1. The reason is functional, as the memory maps are different. Anything that anticipates Mode 2's memory maps will break or read garbage and fail. that being said, if you built a game with a consideration of dual-booting, it *could* be possible. Most aren't really built that way, though, so you'll run into problems there. You can pull the BIOS data from the BIOS, and in fact, it's strongly recommended you do exactly that when doing Mode 1 implementations. Ensures maximum compatibility, and just requires you keep aware of how to detect BIOS versions and compensate for the deviations. Of note, there is a Mode 2 Cart Boot mode that exists, but it's not universally present in BIOS iterations, and it's effectively undocumented publicly. I've got a ton of notes on it, but I've just not had the time to sit down and write up the info on it. It's unlikely this mode was ever meant to be used in production, based on the evidence. It's nor related to your questions, but I thought it would be an interesting and fun additional note to add. You can make a 32x-enhanced game that runs without the 32x. It's just a royal pain. You basically have to build the entire game using variable-offset absolute references and carefully-considered relative references so that it can handle both banked operation and unbanked operation fine, and have the offset variables set during the 32x initialization routine. It's a royal pain in the ass, but it's not impossible, per se. Controller detection is actually covered in the Genesis Software Manual from the infamous Rex Sabio dumps that have been floating around for the past decade or so. Check out Addendum 1 and the control port memory layout and control to make sense of that mess. It may be confusing to get into, but with some persistence, I know you'll be able to make sense of it. There are such things as link cables, though they were rarely used. While you could go with any number of potential solutions for such a link-up, and given access to manufacturing resources, you'd have *a lot* of custom options, the simplest and most accessible method to link two MD units together would be nineko's mentioned method, the Zero Tolerance link cable. With that, you're effectively using the cart port as a data port, and sending sync data between units to keep things on both units operating as close to in-sync as possible. You don't have much data rate, and it's not duplex, but with the proper primary-secondary setup and persistent switching, syncing can work. Or, if you're just using it to dump data from one to another, that's certainly possible, too. Just depends on the setup. Getting a game to talk to the Internet would be possible, though given current hardware availability limitations, the external data processing would probably be best-done through a similar method to console linking. you would need to probably involve a computer, as you would need something to receive the data and then transmit it over the Internet. There were various modems available in the past for the MD, but availability is generally scarce, and modems would be problematic to make work, as dial-in Internet services are dwindling (at least here in the US; there might be some popularity still in other countries). Would be better to have an MD to computer cable and handle communications that way with a software program on the computer acting as the translator and interface medium. Obviously, that would depend on having cables made, writing your own program, and other various joys, but it's possible to do. Hope that covers a fair bit of your questions. SRAM is more flaky, and I'd prefer someone who plays with it more often than I do handle explaining those.
With a Mega EverDrive, using the USB interface and a small computer program for internet connectivity would be fairly trivial to setup, but data rates aren't amazing and you have to write a lot of net code to make sure things sync up and you dont end up breaking anything because someone's console decides to troll you and crash or send malformed data. Of course, the carts cost 150€ so its hard to convince many people to get them...
I believe SRAM for the MegaDrive hits about 2MB or so when you start running into problems. I could be wrong on that, so if I am, please correct me.
True. There's also the problem that Mega Everdrives are generally not healthy for your systems due to their voltage handling, which is disappointing. Not to be an alarmist, but extended use of the Mega Everdrive can cause accelerated wear on your console and its hardware as well as the cart itself, as the cart is designed with 3V3 hardware and just overdrives it with 5V rather than doing proper voltage conversion. A disappointing error in design, but one that should be noted for those conscious of care and maintenance of their consoles long-term. It's not something that will necessarily take a serious toll on occasional use, but extended, persistent use will likely create problems. Just throwing out that information. Netcode for the MD in general is going to have piss-poor data rates. There's just no really speedy bus interfaces to tap into without basically MitM'ing the cart or expansion port, and even then, would need to basically do onboard processing outside of the MD's hardware to get better rates. And doing such a solution would be costly and require manufacturing. tl;dr If you need high data rates for your netcode, that shit's not going to work on hardware short of hardware hacks or custom-manufactured solutions.
It's been a while since I've done anything controller-related, but IIRC the "controller detection" in the official software manuals is absolute garbage, and will explode if you press two opposing keys down in an emulator. You might think this is some edgecase that should never be accounted for, but those exact same manuals say you shouldn't ignore it, since it *is* possible on hardware. Ages ago, I wrote a joypad library that supported hotplugging 3/6-button controllers and the multitap, and it autodetected them using more-foolproof methods: Code: ; sub_112A: Joypad_Read: joypad_setTHandTL 1,1 ; Setting bit 5 here is harmless for 3-button and 6-button, but needed for Multitap move.b (a1),d1 ; We'll use this read-out to determine if there's actually a controller plugged into this port joypad_setTHandTL 0,1 ; First, we'll check for Multitap here move.b (a1),d0 andi.b #%00001100,d0 ; These bits will be 00 if a 3-button or 6-button is connected bne.s Joypad_Read_MultitapOrInvalid ; They will be 11 instead if either a Multitap is connected, or nothing's connected at all ;Joypad_Read_Normal: move.b #(1<<6)|(0<<5),HW_Port_1_Control-HW_Port_1_Data(a1) ; Mark bit 6 (TH) as an output nop nop nop nop ; Read typical 3-button info ;joypad_setTH 1 ; ?1CBRLDU ; These two were done earlier (by Joypad_Read) ;joypad_setTH 0 ; ?0SA00DU joypad_setTH 1 ; ?1CBRLDU move.b (a1),d1 andi.b #%00111111,d1 ; Get 3-button's 'C', 'B', 'R', 'L', 'D', 'U' values ; 6-button info begins here joypad_setTH 0 ; The readout for this should be ?0SA0000 (a 3-button can produce this too, however) ; While we're here, let's get 3-button's 'S' and 'A' values move.b (a1),d0 add.b d0,d0 add.b d0,d0 andi.b #%11000000,d0 ; Get 3-button's 'S' and 'A' values or.b d1,d0 bsr.w Joypad_StoreInput joypad_setTH 1 ; Read Mode/X/Y/Z ; The readout for this should be ?1CBMXYZ move.b (a1),d1 andi.b #%00001111,d1 ; Get 6-button's 'M', 'X', 'Y', 'Z' values joypad_setTH 0 ; Check for 6-button controller ; The readout for this should be ?0SA1111 (a 3-button cannot reproduce this; it produces ?0SA00DU instead) move.b (a1),d0 andi.b #%00001100,d0 beq.s .not6button move.b d1,d0 bsr.w Joypad_StoreInput bra.s .tickControllerCount .not6button: clr.w (a0)+ ; Store blank MXYZ inputs .tickControllerCount: ; Check if we need to update any more controllers subq.b #1,d5 ; tick controller count bcc.s .notDone addq.l #4,sp ; Don't update any more controllers .notDone: ;rts ; End of function Joypad_Read_Normal ; ||||||||||||||| S U B R O U T I N E ||||||||||||||||||||||||||||||||||||||| Joypad_Read_Invalid: rts ; End of function Joypad_Read_Normal ; ||||||||||||||| S U B R O U T I N E ||||||||||||||||||||||||||||||||||||||| Joypad_Read_MultitapOrInvalid: andi.b #%00001100,d1 ; Missing controllers return nothing but $FF, but Multitap must have these bits set to 0 bne.s Joypad_Read_Invalid ;Joypad_Read_Multitap: I never released the thing because I couldn't test it on hardware (and also because Natsumi beat me to the punch), so maybe take this with a grain of salt.
Yeah... I forgot to mention the garbage-tier of detection, and to just use it as a starting point. Oops. Definitely do make use of Natsumi and Clownacy's info here, as it's a more reliable reference point for practical implementation than the software manual's reference. The amusing thing about the software manual is that for as useful as it is for referencing, it also gets a ridiculous amount wrong. Do double-check your work with runtime to see how it fares and survives. Theory is all good and well, but as many of us can attest, theory and practice often end up with two very different results...
The emulation documents are super useful; thats the way I was able to get my multitap code working. They are unsurprisingly correct more often than the technical documents or even technical updates from SEGA