Figuring out how the Sega DS-16 interfaces with the Genesis.

Not sure tbh.
I just assumed that was the main power switch?

Easiest way is just to measure the voltage on pin 6 of the 555 and see if it changes.

OzOnE.
P.S. Any sign of the IDE adapters yet?
Super snail-mail though, so I very much doubt they'll be there yet?

 

Oooh, photos. Thanks!

A tiny bit blurry, but should be enough to get some parts of it done.

btw, I personally think it's fine to say "EPROM" instead of "Mask ROM". Everyone knows what it means, and I say "EPROM" as a general rule as well.
http://www.youtube.com/watch?v=FDFMCvqCoL4

I'll see if I can get some of the schematic done.

 

IDE adapters? You sending me something? Better discuss that by PM.

Anyways. I'll be working on my own schematic of it when I get bored in case you can't get one made. Some of the traces go under the parts making it hard to see where they end. I can trace them with my multimeter to know for sure where they go. I'll definitely see if it works interfacing through the cart slot only probably later this evening. I won't do anything to the unit itself. I'll do it through hacked together patch cables. If it still works then that will be good. Be useful then for other systems without the expansion ports like model 3 Genesis maybe and something else like say a Wondermega. I assume a model 3 will have all the same wires needed to interface. If not then oh well. Still be good for systems with a CD attached. Hell, if it works with a model 3 then if someone makes a new board they could have a new case formed and have it house a model 3 inside to make a complete all in one unit.

 

Sorry, that post was a replying to jp, but you posted the photos just before.
I sent him some DC IDE adapters a few days ago.

I can send you some too, but they've been a bit of a pain to solder.
The soldering itself isn't too bad, but I realize that I made the clearance between the soldermask and pads far too small.
They were prototype boards too, so this tends to cause shorts when soldering.

I'll see if I can put some more together though. I got some more GD connector samples from Molex.

Mr SWAT has just started experimenting with the IDE adapters now, and he apparently has a basic block driver running for Dreamshell.
I think this means that he has simple raw access to a HDD / CF, but the filesystem stuff isn't attached yet.

There are quite a few people with the adapters now (well, when they all arrive at their destinations.)
cybdyn and BlueCrab will have some as well soon, so I'm hoping for good things from them.

It might mean that an FPGA based DC GD emulator won't be necessary.
Maybe only a BIOS Flash mod + patched BIOS will be required?


Just made a start on the DS-16 schematic too...

The white chips (RB1 to RB7) are just 100-ohm resistor arrays.
The -3 version means that each resistor inside is isolated (see "Schematics" on page 3)...
http://www.mouser.com/ds/2/414/890-8525.pdf

If you get chance, could you possibly match up the part numbers with the board labels?
ie. IC20 = 74HC161P or whatever.

Or, I can wait until you can get some high-res photos.
I have the last photos under Paint Shop Pro now, but still hard to see exactly where the signals go.

As APE said though, the important chips are the address decoding / counters.
It looks like these are IC20, 21, 22, so it's best to start tracing signals from those first, especially if one of them goes to the /Cart CS signals.

I'll reply to PM now.
OzOnE.

 

OK. I have all the IC chips numbered out. Number listed below goes to the white number in the photo.



1: 17805
2: PC74HC245P 845110T Hnn9249PC
3: PC74HC245P 845110T Hnn9249PC
4: PC74HC245P 845110T Hnn9249PC
5: PC74HC245P 845110T Hnn9249PC
6: PC74HC245P 845110T Hnn9249PC
7: PC74HC245P 818500T Hnn9223PC
8: PC74HC245P 818500T Hnn9223PC
9: PC74HC245P 845110T Hnn9249PC
10: PC74HC245P 845110T Hnn9249PC
11: PC74HC245P 845110T Hnn9249PC
12: PC74HC245P 845110T Hnn9249PC
13: PC74HC245P 845110T Hnn9249PC
14: HD74HC14P 2M16
15: HDD74HC02P 2L15
16: PC74HC00P 836480T Hnn9245PD
17: HD74HC251P 3A1T
18: PC74HC161P 757500T Hnn9223PA Y
19: NE555C 840
20: HD74HC138P 2M4T
21: HD74HC138P 3B36
22: HD74HC138P 2M4T

You already know what's in the dummy cart so I won't bother with that. I did some tracing and found something interesting yet again. Expansion ports pins A29 and B29 are listed as carrying audio. These go and hook to pins B1 and B3 on each cart slot. There's no logic chips or anything between them. They just all hook to all the slots. Expansion B29 goes to slot B1 and expansion A29 goes to slot B3. Any ideas about that? No one seems to know what these 2 pins do on the cart slot.

EDIT: I FIGURED IT OUT!!! I KNOW WHAT CART SLOT PINS B1 AND B3 DO NOW!!! They are for audio mixing. See what Sega Retro has to say about this:

So these pins are useless since we won't be using a 32X on top of it. I don't think any pirate carts used it either so they are not needed.

Now I know where the 4 mystery pins go on the cart slot. B1 and B3 are for stereo directly from a cart, B21 goes to expansion port B23, and B31 is a mystery address line that goes to the Sega ASIC chip.

 

That's great, thanks.

Making some progress now. I'm just making a "Megadrive" library for the cart / exp ports.
(I actually prefer the name Genesis now, but hey, what can you do? )

Yep, a lot of cart consoles have audio input pins. That's mainly what the opamp in the N64 is for.
Not many games use them though.

If you're making a new DS-16 schematic, you could always hook those audio pins to all slots.
The "proper" way would be to buffer them with opamps, but there's unlikely to be a 32X or something in enough slots to load the audio signals down.

We should be able to get save carts working too.

OzOnE.

 

Oh, CART_B31 goes to the /TIME signal.

Not sure yet if this is a chip select for an RTC (Real-Time Clock)?
Pretty sure it's a /Chip Select line, as it's next to the other chip selects.

(/FDC is interesting. Floppy Drive Controller. hmmm)

http://emu-docs.org/Genesis/mega1.png

 

Thinking about making the cancelled floppy drive expansion now? LOL

And getting SRAM games working would be awesome. Added bonus if flashcarts work too. The world would tremble at the sheer awesome might of 6 Mega Everdrives running in tandem. LOL

 

Nah, it's just interesting that the chip select is still labelled on the schematics.

More progress...



I see that the individual /Cart CE and /Cart OE signals do indeed come from the 74HC138 address decoders.

IC22 handles the /CE (Chip Enable) signals, and IC21 handles the /OE (Output Enable) signals.

The binary inputs to the ABC pins on IC21 and IC22 will be the "cart number" value.
The 74HC138 decoders ensure that only the selected cart slot receives it's /CE and /OE signals.

I suspect the cart number is also connected to IC20, whose outputs I would guess go to the enable pins on the 74HC245 bus transceivers.

The PCB layout is coming along.
The library I made for the cart connectors might not have the correct spacing yet, but I wanted to get the basics down first.
All the details on the layout can be easily tweaked later on.

btw, did I mention I started a project a few weeks ago for a "universal" cart emu?
The idea was to use cheap $40 boards from China to emulate carts for a few different consoles (Mega Drive, Snes, N64, 8-bit stuff).

I found that the coding to get SDRAM working on the Mega Drive is a proper pain because I don't think it's random access time will be fast enough.
So, I bought some different FPGA boards which have SDRAM, SRAM, and Flash on (still cheap). I haven't had chance to look at it again recently.

This will be a super-ghetto cart if I do get it working. It's just a cheap way to play a few games, so maybe won't have save game support initially.
In theory, the Flash memory should work fine on the Mega Drive, but I haven't hooked up a new board yet (or figured out a straightforward way to program the Flash).

As always, I don't know if I'll ever get around to finishing these projects.
I'm intent on working on the Naomi atm. The DS-16 stuff is still fun to do though.

OzOnE.

 

OK, just finding out that the forum attachments have a finite limit.

Tried to update the first image. Oh well, external links it is then...



OzOnE.

 

If you need help tracing the lines on the connector for the dummy cart to the main board I can do that. From what I can see most of the lines on the board are tied together for the 6 cart slots. Looks like the logic chips are just used as interrupts for the game carts that aren't currently being accessed by the CPU. I may be wrong though...

 

!TIME signal (B31) on cartridge port is indeed an additional chip select, it goes low for read/writes in the $a13000-$a130ff range and is traditionally used by a few games for bankswitching (Sonic 3 for example uses it to enable SRAM access). Most likely, this is used here to switch between the 6 extra connectors from boot software by latching data bits (D0-D2 ?) when !TIME is asserted.

!FDC is similar signal on expansion port, it goes low for read/writes in $a12000-$a120ff range and is used to access Mega CD internal registers from Mega Drive side.

SRAM games would require !LWR signal to be propagated to individual cartridge ports, some of them use !UWR but they are very rare. And as mentionned above, a very few games (namely Sonic 3, PS4 and Beyond Oasis / Thor) needs !TIME to enable/disable access to SRAM because it shares the same memory area as ROM).

The ports pinouts you posted are actually quite outdated and incomplete, if you are really interested in figuring how this is working, I would suggest getting more accurate pinouts from the recently released Service Manuals (or schematics posted above, it's the same). Most (if not all) pins function are known by now.

 

Thanks, Eke,

Do you think the signal names in post #29 are OK? I took them from the schematics.
As you say, it looks like all the proper signal names are on the diagram.

When I'm naming the actual nets, I'm keeping the names for the Expansion and Cart slots separate.
Most of the cart signals will be shared though ofc.

Might be worth adding the extra logic for the /TIME and /LWR signals too?
Doesn't sound like /LWR used on the DS-16 atm?

(btw, I don't think /TIME is being used either, but sonicdude mentioned it because it is unlisted on some pinout sites.)

No idea why they used quite so many HC245 buffers on that board, but I guess buffering of all signals is a good idea for signal integrity?

OzOnE.

 

The /TIME signal is indeed used. It hooks to one of the chips on the dummy cart. If it is used to activate the SRAM on some games like Sonic 3 then we might be in trouble. Or else it's just a pass-through to the rest of the logic chips on the board. If so then I don't know why having Sonic 3 in the thing makes it blank screen when I switch to the bank the cart is on. Maybe the cart needs additional signals not present on the DS-16 board?

 

Not sure yet. We'll have to get familiar with the different cart types / memory areas, similar to what Eke mentioned.

Is the /LWR signal connected to all the cart slots as well?
Maybe it's just not set up for SRAM games.

By "SRAM", we're talking about battery-backed save game SRAM, correct?
If so - do any other SRAM games work and save OK through the DS-16, or is it only certain carts like Sonic 3 that fail to boot?

OzOnE.

 

there are still quite a few misnamed
S_RES is actually M3 input for Mega Drive and is used to enable Master System (Mark III) compatibility mode, it is definitively not a reset signal
VIDEO is YS output from Mega Drive VDP and is used to indicate when background color is displayed (used by 32x), it'snot a video signal
68k !LDS and !UDS are not output to cartridge port, it's actually !LWR and !UWR which are resp. lower and upper byte write strobe asserted by VDP on CPU memory writes
CLK is actually CPU CLCK (VCLK ~7.6 MHz)
HS_CLK is EDCLK which is External Dot Clock input/output (~13.4 or 10.7 MHz)


Forgeting about !TIME (which is only used by maybe 4 official games), SRAM access is generally decoded using VA21, allowing (mirrored) access to ROM in the lower 2MB area and SRAM in upper 2MB area (4MB in total addressable on cartridge port with /CE0). I do not really know how this device uses cartridge and expansion ports exactly but the expansion port is limited to 256KB direct addressable range (only got VA1-VA17) and has 3 chip select signals (/ROM is asserted for access to the lower 2MB area then RAS2 or CAS2 is asserted for the upper 2MB area, /FDC being asserted similar to !TIME but for $A12000-$A120FF range)

 

I can't test out other SRAM carts as I have none save for my original Sonic 3 cart. (Had that puppy back in 1995 and still have it.) Only other thing I have like that is my Everdrive MD and it won't load from the SD card. It will play a game already flashed to the flash chip as long as the chip doesn't need any sort of saving. I can do a test sometime soon. give me a list of all the games that had a save function in the cart and I can see if any of them work or not. The Everdrive MD emulates all of those saving methods used by the games and my ROM library is complete on the cart. Next best thing for figuring out what works and what doesn't in regards to save games. I can load a save game on the Genesis then try it out through the DS-16 to see what works and what doesn't.

As for Sonic 3, no battery used there. It is static meaning the RAM for the game saves holds charge for quite some time. A few months without power from my own experience. It interfaces through these pins: all of the A side. B4 through B9, B16, B17,B22 through B25,B27,B28,B31, and B32 for cart detect. So Sonic 3 DOES use the !TIME signal.

 

Excellent, thanks Eke,
I'll update my libraries.

It's important to know the proper names, as some of them are inputs rather than outputs.
/UDS and /LDS I probably renamed wrong, as I assumed they were from the 68K.

"/S_RESET" is definitely wrong too - my fault!
The pinout on Gamesx said "/S_RST". A lot of it is labelled wrong. lol

YS I'm somewhat familiar with, as I was doing a homebrew micro project a few months ago which uses a VDP9958 chip.
It's similar to the Mega Drive VDP, but the Sega one is quite a bit more powerful.

Damn, only just saw the "18" address bits on the Expansion port (17 to 1). That's weird.

The DS-16 must be getting the upper address bits via the dummy cart?
I can't see any latches or anything on the DS-16, apart from the 4-bit counter for the cart slot number selection.

Must be via the dummy cart then. I just haven't traced that yet.
(Address bits 17:1 from Exp port are connected through to the bus transceivers at least.)

Good to know the SRAM is normally directly decoded.
Maybe it's just the /WR signals that aren't hooked up on the DS-16?

The fact that the Everdrive MD can't access the SD card also suggests that the /Write signals aren't connected to the slots?
The Everdrive menu obviously needs to write to the SD access registers via the cart slot, so I'm assuming it needs the /Write strobes?

@Eke - are the /UWR and /LWR signals are the only /Write strobes on the cart slot?
If so, we'd need to see if one or both of those gets passed to the DS-16 slots.

Is this better?...



I like the idea of keeping the "CPU_" and "AUDIO_" prefixes, as it makes it a bit more readable.
I also got rid of the silly blobs on the pins.

Notice that the "A" pins are on the right-hand side too. This makes more logical sense to my brain.
I had trouble with that when starting the cart emu project. I'll be trying it again soon with the new FPGA board...

It has only 512KB of SRAM onboard, which is perfect for testing small games (and very easy).
I'll have to write to the 2MByte Flash to use larger ROMz though.

OzOnE.

 

Yes, looking at the posted pictures, this is probably what the extra connectors on dummy cart (CN-2) / DS-16 (CN-5) board are used for

Everdrive uses a bunch of signal that normal carts generally do not use, hence why it is not compatible with some clone or emulation-based consoles
Hardware Manual for V2 is available here: http://krikzz.com/pub/support/everdrive-md/everdriveMD-hardware-spec-1.1.doc
From memory, I think it uses !TIME and !UWR,!LWR to access internal control registers, !VCLK for internal clock generation (might have been changed in latter revisions) and !MRES for hard-reset

yes, it wouldn't have make much sense adding others anyway since both signals cover all write access

for example, on expansion slot, you also got !FDWR which is asserted for writes in the !FDC mapped area but it's not even used by Mega CD

Seems fine to me with one exception

B26 is actually !ASEL, not "ARES", it's not a reset signal but an additional "chip select" asserted for read/writes in the lowest 8MB area ($000000-$7FFFFF), hence why it's also labeled !LOWMEM sometimes

Sonic 3 use Ferroelectric RAM which is non-volatile and does not require battery
!TIME is used to enable SRAM access in the 2MB upper region ($200000-$3FFFFF)
writing 1 to $A130xx enables SRAM in this region, writing 0 got you Sonic 3 ROM mirrored in this region

From what I remember, the game enables SRAM on startup then never disabled it again.

So, you could wonder why this was needed since Sonic 3 is a 2MB game and using VA21 to decode SRAM access like with other SRAM games would have been enough ? My theory is that it was done because they initially thought the game would be larger than 2MB or already designed the cart with Sonic & Knuckles lock-on cart in mind. Indeed, S&K lock-on relies on the locked game being mirrored in the upper 2MB region (resulting in a 4MB game when locked with Sonic 3)

 

Oh, /ARES was a typo. I'll fix it.

Great info, Eke. Thanks again.

I've sent my recent Eagle schematics of the DS-16 to sonicdude, so we can both work from the same one.
Just need to see which signals are shared across the cart slots, then hook up the logic stuff.

Once it's finished, we can look at adding improvements to the design so it can handle things like Sonic 3 and the Everdrive MD.

(sorry if this is OT, but it's kind of related)...

I'm just starting to port my old MD cart emu code onto the new board.
I say "port", but all I really need to do is to reassign the pins, then write the cart image data to SRAM instead.

All it does it load an image from the SD card as raw sectors, dump it into SRAM, then releases /MRES to allow the game to run.
I've been meaning to get around to this for a while, 'cos it didn't work properly with SDRAM (too slow at 50MHz believe it or not, and too much hassle to increase the clock speed).

I'm expecting my Naomi cart to arrive today though, so I'm bound to get sidetracked.

OzOnE.