NAOMI / AW possible ROM Emu project....

OK, I created this new thread to look into the possibility of doing an FPGA-based Cart ROM emulator for the NAOMI and / or AW.

I didn't want to pollute the GD Emu thread with this stuff, so I've re-pasted my last post here.

Here is the start of the idea...
http://www.assemblergames.com/forum...Facebook-group&p=705815&viewfull=1#post705815

And here is my last post in that thread (moved here instead)...


I agree, it's pretty pointless trying to run NAOMI stuff on the DC unless someone can make crippled versions of the game (to reduce the RAM usage etc., which is likely a futile and pointless task).
As we know, even if the extra RAM could be added to a DC, the spare address pins can't be reached without precision drilling or a board redesign (again, fairly pointless).

I'm not saying any of this stuff is easy, but I enjoy the discovery as much as the rare successes.
I haven't owned a working NAOMI or AW before, but I love the arcade hardware, and I'm trying to get into that area a bit more.

However, it does sound like the AW is much closer to the DC hardware.
(I know, when you hear someone say "closer", it does sound newb, but some of this stuff isn't as impossible as some people think, just very difficult and time consuming).

EDIT: Oh I see - AW has 16MB VRAM, and 8MB Sound RAM. Forget the whole AW on DC idea then.

EDIT2: Still not sure about the exact AW specs. The info in the MAME source seems to suggest it does only have 16MB Sys / 8MB VRAM / 2MB Sound RAM?
Almost impossible to find photos of the AW mainboard itself. I've tried all over Google Images, including on AG.
Anything I do find seems to have had the photos removed?...
http://www.neo-geo.com/forums/showth...consolizing-it

Could anyone possibly point me in the direction of some AW main PCB photos, or post some new ones?
If the AW really does only have the same amount of RAM as the DC, then all these specs must be wrong?...
http://en.wikipedia.org/wiki/Atomiswave
http://www.system16.com/hardware.php?id=812
http://wiki.arcadeotaku.com/w/Sammy_Atomiswave


I'm learning more about the NAOMI now, and have seen that most of the carts do indeed do the decryption on the cart itself.
Most of the carts have a fairly large ASIC on there.

The question is - now that many carts have been decrypted for use on emulators etc., does that mean that the connectors on the NAOMI are expecting unencrypted data?
That would make a cart emu within realistic reach.

As far as I can tell, there are no proper schematics available for the NAOMI?

I've been reading a lot of the MAME sources to see how the regs on the NAOMI works, and I'm slowly piecing together how the hardware is mapped out.

With a bit of multimeter work, I've started tracing the signals of interest from the Holly chip to the FLEX FPGA and BIOS etc.
The Holly pinout was taken from the DC VA0 schematics though, so some of the pin numbers are difficult to read...


IC57S

1. DIR from HOLLY, pin 126 (/G1RD).
2. D0 (G1_D0) from HOLLY pin 11.
3. D1 (G1_D1) from HOLLY pin 10.
4. D2 (G1_D2) from HOLLY pin 124.
5. D3 (G1_D3) from HOLLY pin 9.
6. D4 (G1_D4) from HOLLY pin 230.
7. D5 (G1_D5) from HOLLY pin 231.
8. D6 (G1_D6) from HOLLY pin 125.
9. D7 (G1_D7) from HOLLY pin 232.
10. GND
11. B: D7 - FPGA 157
12. B: D6 - FPGA 33
13. B: D5 - FPGA 130
14. B: D4 - FPGA 111
15. B: D3 - FPGA 129
16. B: D2 - FPGA 7
17. B: D1 - FPGA 138
18. B: D0 - FPGA 136
19. /OE from IC59 (LVC08), pin 11.
20. VCC


IC58S

1. DIR from IC60S (LVC32), pin 3.
2. D8 (G1_RAD8) from HOLLY pin 13.
3. D9 (G1_RAD9) from HOLLY pin 120?
4. D10 (G1_RAD10) from HOLLY pin 14.
5. D11 (G1_RAD11) from HOLLY pin 15.
6. D12 (G1_RAD12) from HOLLY pin 16.
7. D13 (G1_RAD13) from HOLLY pin 131.
8. D14 (G1_RAD14) from HOLLY pin 17.
9. D15 (G1_RAD15) from HOLLY pin 18.
10. GND
11. B: D15 - FPGA 114
12. B: D14 - FPGA 124
13. B: D13 - FPGA 24
14. B: D12 - FPGA 135
15. B: D11 - FPGA 142
16. B: D10 - FPGA 149
17. B: D9 - FPGA 145
18. B: D8 - FPGA 125
19. /OE from IC59, pin 11.
20. VCC


/G1CS0 from HOLLY pin 21 goes to FPGA pin 23, and IC59 (LVC08A AND gate) pin 1 "1A".
/G1CS1 from HOLLY pin 136 goes to FPGA pin 22, and IC59 (LVC08A AND gate) pin 2 "1B".
IC59 (AND gate) pin 3 output "1Y" goes to

/G1ROMCS from HOLLY pin 12 goes to IC59 pin 3, and BIOS PROM (IC27) pin 11.
/G1FMCS from HOLLY pin 20 goes to FPGA pin 158.
/G1RD from HOLLY pin 126 goes to IC57S pin 1.
/G1WR from HOLLY pin 134 goes to FPGA pin 123.

G1_INTREQ from HOLLY pin 135 goes to IC50S (LVC32A OR gate "3Y" output) pin 8.
(pin 9 "3A" is tied to GND, and pin 10 "3B" comes from FPGA pin 143, so G1_INTRQ effectively comes from FPGA pin 143)

G1RAL9 from HOLLY pin 132 goes to FPGA pin 29, and to Slow 104K SRAM (IC29) pin 24.

G1MRA13 from HOLLY pin 129 goes to BIOS EPROM (IC27) pin 37 ("A12").
G1MRA18 from HOLLY pin 19 goes to BIOS EPROM (IC27) pin 2 ("A17").


You can see that the BIOS EPROM and battery-backed SRAM are mapped to the G1 bus pretty much like the DC.
(It can be assumed that the rest of the address pins connect to the BIOS EPROM / SRAM as well.)

The FLEX FPGA is on the G1 bus (like in the MAME sources), and does the address decoding and PIO / DMA stuff for accessing the cart bus / DIMM board.

If it is the case that the NAOMI itself is expecting unencrypted ROM data (after the cart has done the decryption), then we could be onto something.
As I say, I thought I might as well look into this as I already have a NAOMI with it's Holly chip removed.

If nothing else comes of it, I think it will be good to document some of this hardware stuff.

At the moment, I'm looking for a NAOMI emulator which has a decent debugger (like MAME), or outputs the logs for the G1 port accesses.
I've tried running a few games (Jambo Safari etc.) under MAME, but I don't think that game is bootable?

I sent a message to Kale for a bit more info, and I'll be trying some bootable games on MAME today to see what info I can grab...
http://mamedev.emulab.it/kale/?tag=naomi

Just downloading Street Fighter Zero 3 now.
EDIT: Damn, it's a GD game. Looking for a ROM instead.

OzOnE.

 

Will a ROM emu also be able to save the highscores on said emulator? Something that really bothers me with the NAOMI design is that highscores and unlockables only stay saved until the cartridge is removed of the mainboard. And personally for me one of the important things for an arcade game is the competition element of beating an other players highscore.

 

Still looking into a lot of stuff, but it should be possible to emulate the serial EEPROM on the game carts too.

Do you know if the scores are still held on the cart once it's plugged back in again?

 

Sorry, but, I don't understand.
I already have a CompactFlash reader for all my Naomi and AtomisWave (carts and GD-ROM) games. Are you trying to achieve something similar?

 

nope, AW have exactly the same memory sizes as DC, memory map in MAME is wrong, better read Guru-readme, or look here
http://imageshack.us/photo/my-images/580/4gb0.jpg/
as you can see even PCB layout looks like DC, plus two "Sammy Romero" chips

Almost all Naomi carts contain unencrypted data, except few newer M4-type like Radirgy Noa, MBAA, ShootingLove etc.
MAME/Demul romsets have dumps exactly as it is on the cart roms, not touched/modified/hacked/etc, and they works without problems, coz cart interface and all known protections/encryptions is REd and emulated already.

there are no any schematics for Naomi/2 or AW

why you are so sure ?
carts, DIMM, comm.board and few custom gameboards - all of them uses G1 bus, but have different registers in 5f70xx area.
so if Altera does address decoding (for hardcoded devices and registers/addresses) it will limit flexibility and expandability of system.

as I say - only M4 carts have encrypted data, and decryption does Xilynx Spartan chip on cart PCB.
also DIMM board contain gamedata in DES-encrypted form, and have its own SH4 CPU for decryption and other purposes.

its something on yours side - tryed CrazyTaxi, JamboSafari on MAME 150 x64 - both boots ingame, but of course slow as hell

 

Ahh, finally a photo of the board. Thanks, p1pkin!

Yeah, I was trying to estimate the number of SDRAM chips on the AW from the MAME source notes.
It looked like there were chips on the underside, but didn't look like 16MB VRAM.

Thanks for clearing that up. I thought something was amiss.

That's a good point too.
I'm not sure how much of the address decoding / DMA stuff is done on the FLEX chip, but it does look like the G1 bus extends to the cart connectors as well.

It's difficult to trace all the signals without a working NAOMI or any carts, but it looks like the main "chunk" of signals to one the cart connectors (CN3) was the main data bus for the cart.
But, many of the signals on CN2 look like an extension of the G1 bus, so could be for the "program" ROM on the cart (overlay to the main BIOS??).

I'm only just starting to look into this, so my knowledge is very hazy at this time.

So far, it looks like many of the G1 control signals go only to the FPGA, so that would suggest that the FLEX may be where the ROM offset / DMA stuff resides?

I've tried Dynamite Baseball under MAME 150b (non-x64 version, running on Windows 7 x86), but it always crashes with this after a few seconds?...

"File: src/emu/screen.c, Line 441


Expression: m_type == SCREEN_TYPE_VECTOR || visarea.min_y < height


This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information."


I'll try Crazy Taxi, but it ideally needs to be a ROM pack image...

It may be that cybdyn's GD Emu will work with a Net DIMM board as well, but the idea of emulating carts on the NAOMI is
because it sounds like it has more chance of success than going for full GD emulation again.

ie. the ROM carts appear to be reasonably less complex than the Net DIMM board / GD drive.
It's also nice to think that this will lessen the impact on the GD / CF market if successful.

OzOnE.

 

Oh, just saw your post, Braintrash...

The idea is to produce a ROM (cart) emulator that will either attach to the normal cart connectors, or emulate / bypass the FLEX chip as well by soldering directly to some points on the board.
The G1 bus needs around 28 signals though, so the later method would be like a big modchip.

This is unlikely to remove the need for the Net DIMM / CF / GD stuff for people who want to play those games, but it will offer a much cheaper way of running the carts (loaded via SD).

I think that emulating the Net DIMM will be a huge stretch, as it would be more than just a case of "bolting on" cybdyn's GD emu directly to the cart connectors.

The problem is finding the balance between providing more people with access to the games / preserving the system, and affecting sales of carts or other hardware.
This question has been brought up a few times with the DC and other "backup" systems, but the arcade market is quite different, and I wouldn't want to step on any toes.

What do people think in general about the possibility of a NAOMI cart Emu?
There will always be some people who dislike the idea, but I'm hoping it's not a major taboo or something?

(might be jumping the gun a bit here, but thought I'd pose the question).

OzOnE.

 

OK, got Crazy Taxi (ROM) running under MAME 150 now.

The problem was that I was using the MAMEd (debug) version.

Should be able to capture some interesting stuff from it now.

OzOnE.

 

@Braintrash - are you talking about the AW to NAOMI conversions, or something else?

ie. Is there already a CF card method for the AW, or is this all on NAOMI?

 

you might be interested in more...

http://www.flickr.com/photos/48137857@N06/10294532704/
http://www.flickr.com/photos/48137857@N06/10294631775/

http://www.flickr.com/photos/48137857@N06/10294538174/
http://www.flickr.com/photos/48137857@N06/10294638846/

 

@Ozone : I have a Naomi 2 (but works on Naomi too; pun intended) with a NetDIMM and a Compact Flash reader. It works just like a GD-ROM excepted that instead of a GD-ROM I connected a Compact Flash reader. It works for Naomi 1, Naomi 2 and AtomisWave games, wether the games were originally on carts or on GD-ROM.

There is no CF card method for the AW, but since all games are being converted to play on CF on a Naomi, it's not a great loss. And you already have so many bootlegs on AW...

 

Superb! Thanks, beharius!

What is that wire mod on the underside of the board? I've seen it on Google Images as well?

@Braintrash - oic. Thought it might be on a NAOMI / 2.

I guess there isn't so much call for an emu on the AW then? Maybe an actual Flash cart is the way to go?

I'll still try to get the AW stuff running on a DC if I can, will be fun to play around with for a while.
I've actually just Flashed my DC with the AW BIOS just to see what happens, but it hangs of course (black screen).

Just trying to decipher the AW Macronix Flash stuff, and trace what it's doing at startup under MAME.
MAME is running the AW BIOS OK, and showing the "cart missing" error, then cycling through the test patterns.

Would be great to get the DC booting to this point with the AW BIOS.

OzOnE.

 

probably not, if I not mistaken GD for DIMM have SCSI interface.

"converted" heh, lets call things by their real names - hacked and bootleged to work on Naomi

yep, exactly as I thinking. bios starts G1 DMA and wait for IRQ or/and status forever.

 

OK, "hacked and bootlegged" then.

Nice if it works OK, but I do like the idea of keeping the game data in it's original state where possible.
(hence the fact that I've always wanted a solution for the DC which uses raw GDI's instead of MIL-CD rips.)

The AW BIOS on the DC was just a quick experiment to see if it did anything at all.

I was trying to see which regs were being accessed under MAME earlier.
It doesn't look like it was accessing the G2 area at all, but did write to the usual "magic checksum" reg at 0x5f74e4.

As far as I understand it, the NAOMI GD drive is pretty much a standard DC drive with an extension board?
It uses "SCSI 2" type plugs / cable, but is really just the same IDE / ATAPI device (with the usual custom Sega SPI commands).


I need to study the MAME source for the AW info, but I'm determined to see what can be done regarding modifying a DC mobo.

cybdyn messaged me earlier though, and the DC GD emu is a priority atm.
We're currently looking to use an ARM MCU for the new version of the board, probably with both SD and IDE interfaces.

I tried searching for a relatively straightforward MCU core for the FPGA, but it looks like way too much hassle to get it running.
There are some open-source cores available, like the OR1200 project, but an ARM chip makes more sense as it already has a decent USB / SPI / Ethernet interface and lots of GPIO pins.


OzOnE.

 

I think this is a cool idea and I'm watching with interest

 

That photos are not mine. I own 3 AW systems, none has that chip under the board. There are some mainboard revisions, not all same...
A Unibios would be cool for the AW.... And an external memory device(sd or hdd) to load games from. Bootleg games are very cheap, around $40 including shipping, but that mod would be cooler... One day maybe chinese can do some multi in 1 cartridges...

 

Thanks for the photos anyway - so hard to find any on the Web.

I'd love to be able to modify the AW BIOS so it loads directly from HDD / SD, but we'd probably come up against the same problems as the DC BIOS.
The AW BIOS does the same "checksum" type thing when it boots. It transfers a large chunk of the BIOS across the G1 bus, and the Holly chip unlocks G1 ROM access.

Still don't know exactly how this process works, but it's a real PITA to figure it out.
There could be a way to brute force it, or see if the protection can be passed by padding out the custom BIOS with random bytes?

The problem is not knowing exactly which signals it does block when it's locked.

Although, the AW BIOS is tiny (only 64KB), so all it really seems to be doing is loading the whole EPR part of the cart into RAM, then executing that.
The EPR is the main part of the game's program code, which then accesses the rest of the cart (MPR).

Reading direct from CF or IDE HDD is easy with one of my adapters, so it's worth me trying to write a small routine which replaces the AW ones.

If anyone with more DC coding experience would like to help with this, please let me know, especially if you can read SH4 assembly very easily.

Making progress with the DC GD emu though - last night, I bought an STM32F4 Discovery board.
This is an ARM running at up to 168MHz, and directly supports 4-bit SDIO and apparently supports CF cards too.

There is an open-source IDE called CooCox, which looks amazing.
It has a repository where people can upload code examples, then you can download them directly inside the software.

Need to message back cybdyn now to see if he can buy one too. He can then transfer his previous code onto the ARM chip.

OzOnE.

 

OK, still working on the NAOMI side of things...

I've mapped out all of the G1 bus pinouts on the Holly chip now (most of which go directly to the FLEX FPGA).

The pin numbers were taken from the VA0 schematics. I'm super grateful to l_oliveira for posting them.

I had to map the signal names to the BGA pin numbering under Excel so I can trace the circuit with the multimeter.
(the DC Hardware manual only gives the signal names, and not the pin numbers, so I had to go by the VA0 schematics).

Some of the numbers on the schematic are hard to distinguish (eg. 0,5,6,8), but the pinouts seem to check out so far with regards to their positions on the BGA and relation to my previous notes.

(image is quite big, so I'll just link to it)...
http://tinypic.com/r/dvsh2q/5

Many of the G1 bus control signals go via the logic chips on the board, so it should be possible to connect an external FPGA to it.

Almost all of the G1 address / data bus signals go via the BIOS chip and / or FLEX FPGA / SRAM.
A good way to connect to most of the bus signals would be a plug-in board which fits in the BIOS EPROM socket.

I have my first working NAOMI on it's way to me now, and if all goes to plan we could be emulating cart games at some point in the future.
Not sure if GD games could be done as well at this stage, as the Net DIMM probably has all sorts of extra control stuff to sort out before the NAOMI accesses the RAMs,

Some people might think I'm dreaming for attempting this - I say, challenge accepted!

I will document as much as I can, and will probably need to start a partial schematic under Eagle soon.

OzOnE.

 

Awesome work ozone, thanks for the status updates! Looking forward to seeing how the DC / Naomi / AW stuff develops

 

Think the NetDIMM as a flash cart. The GD-ROM is read to the NetDIMM which then allow the Naomi to read the game like if it was a cart.