NAOMI / AW possible ROM Emu project....

Good job OzOnE!

for game bookkeping and settings only, BIOS settings stored in serial eeprom connected to 315-6146 MCU

here is my "small" collection
https://mega.co.nz/#!pI81GQoZ!clXqFn8k59rkx0EUCRf5ATcuOEU28v75zOtROHhybMs

it differs for cart types, in newer M4-type it can be up to 20MB/s according to settins of G1-DMA read delay register.

I've told you many times - almost all Naomi games is not encrypted, but carts have protection
how it works:
case 1 - game set DMA offset with "decrypt" bit on and read some data, and later use it for work or even simply compares with etalon data (so dumb yeah)
case 2 - game write using PIO some encrypted/packed data to cart internal buffer and read back unpacked/decrypted data

about PICs and NET DIMMs...
in MAME romset you can found dumps of many Naomi's PICs, so scenario is:
- find any PIC16 and program it with any firware form MAME you like
- take any GD-dump/rip of Naomi game, decrypt it if it is encrypted
- encrypt it with key from your PIC
- upload dump via net to DIMM, have fun

oh, Sixtoe is kinda out of business, System16 even says Naomi2 have 2xSH4 CPU LOL

except very few games like HOTD2 they doesnt need special BIOS, and happily works with latest version.
BUT, if you want to use DIMM-BD you'll need rev.D or later, for M4-type carts you'll need latest rev.H BIOS

 

Excellent, thanks for the info p1pkin, this is the sort of stuff I'm after.

That giant photo collection is perfect!
I can use them to get a basic count of how many carts use their own G1 bus chip etc. (some info on the Guru's site, but it's much nicer see them all visually).
It has already helped me to see which pins connect from the X76F100 EEPROM to the FLEX.

It's sounding more and more like I might even get GD images to work once I can get cart support working. This is good.

I've read the MAME sources where it reads and decrypts the image file from the GD disk (filename taken from the PIC).
After that point, the DIMM registers seem to work in a fairly basic way similar to a cart. So, there's hope it won't be too impossible to emulate.

I've read that some games have protection code too (like you say), which checks some parts of the DIMM / Cart data to make sure it's still encrypted.

I've just added the registers to the FPGA for the Cart, Board ID EEPROM, DIMM board, COMM board.
These are just the regs though ofc, none of the good stuff is being handled as yet.

I never realized the EEPROM on the 315-6146 was the main EEPROM.
I see there's another chip as well (IC69) which I think is connected to the SH4, so I thought that might be the main one?

The notes in the MAME course (from ElSemi) say that the "the main board eeprom is read through port 0x1F800030"...
Is that a typo? (too many zeroes?) I was trying to figure out if that's in the G1 / ROM / Flash address space, or via the 315 chip / Maple bus?

I've also just bought another faulty NAOMI board to have a go at repairing it, or use it for parts. It was cheap anyway (£15).
At the same time, I bought a Virtua Tennis cart (£25, not too bad), and a GD SCSI cable for £7 to help me connect to a DC GDD.

Now I can wait for the cart to arrive.
Hopefully it will plug in on the underside of the board, which will still let me use the test clip, and save me a lot of grief.

OzOnE.
P.S. When my pinout notes are more complete, I'll release it on here.
I've basically worked out 90% of the pinouts for the three white connectors CN1, CN2, CN3, and which pins connect via the Flex FPGA.

 

In all emulators including MAME gd-games emulated as carts (and this accidentally works). also they doesnt have any protection checks, DES-encryption is all the prot SEGA did for Naomi GDs.
about DIMM - only old basic info from Elsemi about registers is available, and afaik no one continued research. so how really DIMM works, its registers, commands, etc is still unknown.

well, kind of main EEPROM with serial number connected to SH4 PDTRA port (and can be readed using 0x1F800030 internal SH4 register), other one with BIOS settings connected to 315-6146.
there is one more very little known fact - on old "metal cage" Naomi s/n EPPROM was not 93C46, but X76F100, and thats why old revisions of BIOS, like A-C or special one for HOTD2, wont work on newer plastic Naomi.

very interesting!
I'll be waiting )

 

Ahh, if they just load it like a cart, then that's perfect.

I read on Guru's page or in the MAME source that some GD games needed "patch data" or something, so I assumed they might be doing protection checks?
If most games are just loaded into RAM as a raw image, then it might be enough to just emulate the cart regs then.

Very good info, p1pkin. I didn't find anything about the PDTRA port before, but I'll have a quick look in the datasheets now (just to gain some knowledge).

Here's a quick "preview" of the NAOMI connector pinouts...

Small print: This is to be considered a Work-in-progress, and the pinouts are not 100% confirmed.
(although, I spent about four days testing them with a multimeter, and I tried to double-check everything.)
"If it doesn't say Micro Machines, it's not the real thing".
"Not available in shops"...



I think the cart data / address bus on CN3 could be traced quite easily on the cart itself.
The pinouts for CN3 and the Flex can then be updated, which would pretty much complete the connector pinouts.

As you rightly pointed out before p1pkin, the older carts use the Flex chip, but many carts have their own chip (Actel etc.),
which inhibits the Flex chip and takes over it's functions.

An interesting note is that the SH4 Mode / serial pins are connected to the end of CN1.
CDDA audio can also be input via CN2, and JP1 is used to change from the internal 33.868MHz AICA master clock to the external input.

The FLEX chip only appears to have G1 address bits 20:15 and 10:8 connected.
This could give an insight into the address ranges it can decode.

Some of the FLEX outputs go to a mux (IC66 in that diagram I posted before).
Not 100% on why it's used yet, but it seems to switch between using /ROMCS or /FMCS as the Write Enable for the onboard FLASH chip (not soldered)?

I think it's just used as a master Write Enable register, since it also inhibits the Chip Select on the NV SRAM.

OzOnE.

 

You dont need to get a scsi cable to conect a DC GD-rom to a no net dimm there are unpopulated pads for a connector and some resistors on the dimm board. The connector can be salvaged from a broken DC

 

I did think about doing that, and I have some connectors from Molex, but I didn't like the idea of the connector sticking up above the DIMM unit.
(The shorter version of the connector is apparently obsolete / unavailable.)

I know it's a cosmetic thing, and might be handy, but I'll probably be selling the DIMM unit again if I get the cart emu working.

Have you seen any photos of a board after someone has done this mod?
I'm wondering what the recommended resistor values are etc.

I bought the SCSI II cable really just to get the connectors, so I could hook up to a GDD using one of my DC-to-IDE adapters.

OzOnE.

 

I just bridged the resistors with wire Ill see if I can dig mine out and take a pic.

 

this link is to a post by mrsporty who also did this mod http://www.sega-naomi.com/forum/viewtopic.php?t=1311&highlight=

 

not GD but Cart, "patch data" (trojaned from carts game data for protection requests) was used then pack/encryption algos was unknown

I saw one spanish (or portuguese ?) forum, there was TONS of Naomi (and not only) games patched/hacked for Net-Dimm, but sadly can't remember name of that forum.

 

Oooh, I'm definitely doing that now. Can't be a bad thing I suppose, even for resale?

I thought I'd seen that somebody tried it before, it had to be MrSporty. lol
He did a nice little guide too.

Bridging the resistors is probably be fine....
The DC has them because the BIOS and Flash are 5V, so it limits the current to the Holly chip (even though the G1 bus is apparently 5V tolerant?).
All GDD's I've seen are 3.3V anyway, so should be OK.

Thanks, anks.
I'll post pics too if I get it working.

Damn, I'll need to buy a GD game as well now. lol
hmmm, Sports Jam is cheap.

 

This is also good news.
Do you think I'll have to worry about any security stuff for most carts, or just use the unpacked data directly?
What about the on-cart buffer? Is it necessary to do anything special with that?

I'm sure I saw that site last week, but I didn't bookmark it.
I might be getting confused with AW images though.
Can't find it atm. I'll have a look later.

Although, I don't think I can use a CF adapter, as I had a non-netbooting DIMM, is that correct?

 

A few notes about the DIMM board GD connector mod...
(for my own piece of mind, I like to know what everything does. hehe)...

R20 = /G1_WR
R21 = G1_IORDY
R22 = G1_INTRQ
R23 = G1_AL9
R24 = G1_AL10
R25 = /G1_CS1

R16 = G1_AL8
R17 = /G1_CS0

#B, Top = G1_DREQ
#B, Middle = /G1_RD
#B, Bottom = /G1_DMACK

#A, Bottom = /G_RESET (pretty sure it will need this bridged for reliable operation, it resets the drive).

(do not short these!)...
PC20 = Smoothing cap for 3V3.
PC22 = Smoothing cap for 12V.

Resistor packs are for the data bus bits obviously.
I personally think it's fine just to bridge all of the resistors with wire, but don't take my word for it.

OzOnE.

 

Regarding the cart versus GD loading theme.

I have seen a user on ebay who sells Ikaruga and Under Defeat naomi bootlegs on carts. This fellow is infamous for his hardware mods (I believe he is one of the guys who was involved with getting atomiswave running on naomi initially). Ikaruga and Under Defeat only came out on gdrom, so I always assumed he got them onto a dimm cart and was somehow able to dump and sack a different cart and replace the roms with the corresponding dimm cart romdata.

 

Interesting.

I was always assuming that the BIOS loads most of the "EPR" code on the cart itself into RAM first, then executed? (big guess)
So, further accesses were then done by the EPR code? (this was my assumption anyway.)

That's why I thought there must be DIMM specific or cart specific code, depending on the type of game?

I can trace a lot of stuff under the MAME debugger ofc, but it's quite time consuming to understand exactly what's going on.

There is some code in the MAME source to handle some DIMM stuff, but the real DIMM board regs don't seem to be directly implemented?
It just handles the addresses through functions like "board_setup_address()" and "board_get_buffer()"?

The comment at the top of naomigd.c mentions the DIMM board registers, but I can't see any code for handling direct commands?

If it's a cart rom, it uses things like...

void naomi_rom_board::board_setup_address(UINT32 address, bool is_dma)
{
rom_cur_address = address & 0x1fffffff;
}

And if it's a GD (DIMM), it uses things like...

void naomi_gdrom_board::board_setup_address(UINT32 address, bool is_dma)
{
dimm_cur_address = address & (dimm_data_size-1);
}

I can also see where it loads the GD images like a standard disk image, but not how it handles the DIMM regs?
DISK_IMAGE_READONLY( "gdl-0039", 0, BAD_DUMP SHA1(ffc7f6e113ad69422a4f22f318bdf9b1dc5c25db) )

I'll still have to get my head around this, 'cos the cart and DIMM registers are different, so you'd expect GD images not to work via cart reg access?

Right, I'll do some more debugging tests on MAME to see what's happening.
At this stage, it probably is just easier to get carts working first.

I need some captures from the read hardware to see what typical accesses look like.
Also need to see how interrupts from the cart / Flex are handled, and if it even needs interrupts or not?
(I've seen ints triggering at the start of some cart reg accesses, but it didn't look normal?)

OzOnE.

 

These GD to cart conversions are "common", yeah.

 

I remember demolish fist for the atomiswave running on naomi , it would cool to do the same for the dreamcast but does the dreamcast even have enough memory?

 

Yep, looks like the DC has exactly the same amount of RAM as the AW.

The problem is, the AW has extra custom chips which would need to be emulated, as well as a Flash BIOS and other differences.
EDIT: Then again, if they got the games running on the Naomi, then they must have patch a fair amount of stuff to stop it looking for the AW hardware?

p1pkin kindly pointed these out on the other thread....

The G1 bus chip is used to access the carts in a similar way to the NAOMI Flex chip.
That wouldn't be too bad, as it's virtually the same as what I'm working on now.

The chip on the G2 bus would not be as simple to get working on the FPGA (not with my programming skills at least).

I'm not sure if the AW stuff would be worth the effort atm, but it is something I want to explore if I'm successful with the Naomi.

I'm still awaiting the cart / IO board / SCSI cable.
I thought the order was all taken care of on Sunday, but yesterday the seller e-mailed me for my phone number. arrrggh! lol

OzOnE.

 

Did some more testing last night, and found the rest of the pinouts (apart from one. lol).

CN2, pin B4 has a wider trace, and goes to an internal PCB layer, so it's quite likely to be a clock signal?
I haven't found where it goes yet, but I'll hunt it down eventually.

I've confirmed the NC (No-connection) pins as well. It was much easier after I removed the white connectors from the dead board.
The white connectors are nice press-fit ones, so are actually more reliable than soldered ones (in theory)...
http://www.omron.com/ecb/products/pdf/en-xh3.pdf

The connectors can be unclipped and the "pins" part carefully prised of the board.



I'm pretty confident about the G2 port signals on CN2 now. You can see where a few of the IRQ's and external request signals are broken out.
All it needs now is to confirm which pins on the Flex FPGA / cart bus are the data and address lines.

I have a hunch that a few of the signals on CN3 (maybe including A28?) are for disabling the Flex chip so the cart can take over?
It might be that B3 or A5 on CN1 does that, since it's on the G1 bus? B3 seems to be a Write Enable for the NV SRAM though.

Or, the Flex chip doesn't normally get disabled at all, and the DIMM / cart module just sits on the G1 bus along with everything else (much more likely).

What I'll do tonight is to trace the pinouts of filter board / "JAMMA" side connectors CN25 and CN26.
Shouldn't take long at all, since most of the pins are for power or obvious stuff like the RGB signals etc.

OzOnE.

 

Yeah, that's where I stop understanding things. What do the custom chips in the atomiswave hardware do? For years, I had thought there was some kind of custom sammy graphics card, but if multiple atomiswave games are successfully running on a naomi 1 (which they are), then how different can the architecture really be?

 

The chip nearest the cart connector on the AW has the registers in for accessing the carts.
It's basically just a few registers which are set via the G1 bus to set the cart rom addresses...
http://mamedev.org/source/src/mame/machine/awboard.c.html

The other chip is on the G2 bus (like the modem port on the DC), and from what p1pkin says, handles the coin mechs / hoppers etc.
I haven't yet found the G2 stuff in the MAME sources?

The architecture on the NAOMI is the same from the point of view of the CPU / GPU / AICA, and has plenty enough RAM ofc.
The problem is that the NAOMI doesn't have the same cart register layout as the first Sammy chip, and doesn't have the custom Sammy chip on the G2 bus.

It might be possible to get the AW ROMs to load into the Naomi like a "normal" bootleg cart, but the game might then be looking for the G2 bus chip?
I looks like a lot of work went into getting the AW ROMs to work though (pretty sure this isn't fake, as it's been confirmed by a few people now)...
http://www.youtube.com/watch?v=kdMgcGfdy0I

OzOnE.