NAOMI / AW possible ROM Emu project....

Thanks, kuze.

@Brainwash - yeah, I'm wondering if loading a GD image as if it were a cart would still work the same?

I know the disks get fully transferred to the Net DIMM first, so it's possible that it will just run like a cart?
That will need to assume that the game doesn't try to access the other parts of the DIMM board though (network, EEPROMS etc.).

I'm making some good progress on the Eagle schematic.
I haven't yet added the Holly chip to the diagram, as it would be a lot of work and I don't think it's necessary for the G1 bus experiments.

Interestingly, the 27C160 BIOS EPROM on the NAOMI is only used in Byte-wide mode, so the upper 16 bits aren't connected at all (same as on the DC).

OzOnE.

 

BrainTRASH. ;-)

And that's how it works : acting like a cart, hence the need of the NetDIMM. The CF works the same way : upload the CF content to the DIMM and then play. And the Netboot too.

 

Oh Sh1t, sorry. lol

That was a genuine typo with your name.

I've just bought my first NetDIMM board for testing.
It was only £35 Buy It Now, so I couldn't resist (they have a few more btw, but are in the UK).

More progress on the NAOMI schematic stuff...

I now see that most of the G1 bus signals pass through the BIOS socket, so that's a perfect / cheap way to connect a small FPGA board.

I've found almost all of the important G1 control signals now, it should be straightforward to isolate the on-board FLEX FPGA, and tap into the few other signals...



As you can see, the "AD" signals on the G1 bus can be multiplexed.
The BIOS is connected in pretty much the same way as on the DC.

The Flex chip also sits on the G1 bus, and is written / read using the same control signals as the GD drive on the DC (/CS0, /CS1, /DACK etc.)

When the Holly is accessing the BIOS / NV SRAM (/ROMCS or /FMCS AND /G1_RD), the G1_AD8 to G1_AD15 signals become part of the address (along with the upper address signals).
The data is then transferred a byte at a time via G1_AD0 to G1_AD7.

When the Holly is accessing the Flex FPGA, it asserts /G1_CS0 and /G1_CS1 (these are used as the IDE "chip selects" on the DC).
The upper address bits G1_RAL8,9,10 are then used to access the registers inside the Flex chip (again, like an IDE / GD device).
The data is transferred a 16-bit Word at a time using G1_AD0 to G1_AD15.

(Pretty sure it needs some of the upper address bits for accessing other registers in the Flex chip too, but I'll confirm this when my NAOMI arrives.)

The Holly can also do DMA accesses from the cart / DIMM by asserting the /G1_DACK (DMA Acknowledge) signal.
So, a PIO access (/CS0 or /CS1 asserted), or a DMA access (/DACK asserted) enables the upper bus transceiver (IC58S) to allow the full 16-bit data to go from the Flex chip / cart to Holly (when /G1_RD is Low).

(A DMA transfer is initiated by the Flex chip by asserting G1_DREQ. The Holly chip then prepares for the transfer and asserts /G1_DACK. A 16-bit word of data is then transferred on every /G1_RD pulse).

The important signals we need are on IC60S on the underside of the board.
The easiest way to mod this will be to remove that chip, then solder a few wires to the pads. The rest of the signals will come from the BIOS EPROM socket.

The Flex chip will need to be disabled though. This would like mean isolating the /CS0, /CS1, /DACK signals to the Flex (by cutting a few tracks, or lifting some pins).

I'm hoping the FPGA will still take care of access to the battery-backed SRAM while the above pins are isolated.
If not, then that could be taken over by the new FPGA as well.

Does anyone know what the battery-backed SRAM is for on the NAOMI main board?
Is it just for the "DIP switch" type settings and usage stats, or does it contain other scary and important stuff?

OzOnE.
EDIT: Another benefit of the new board will be to change the BIOS image whenever you wanted.

btw, I haven't finished the lower-right part of the diagram yet. It's some address decoding for the NV SRAM by the looks of it.

 

"Achievement 1 Unlocked!!"

Finally got my NAOMI to run a different BIOS image from the Flash on the DE1 board...

This is great, because it proves that my connections are good.

I can now write two different BIOS images into Flash and switch between them.
It's running the Japan BIOS fine atm, but I don't have any games to try, only the test menu stuff.
(should be possible to load a BIOS from SD into Flash, but that will take a fair bit of coding)

I did have two data pins swapped at first, but my code allows me to switch to "SPY" mode, so I could see what the original BIOS chip was doing.

(notice I said "BIOS" image - nowhere close to running game carts yet!)

I also received my "Net" DIMM today, but in my ultimate ignorance of the NAOMI World - it's not a net bootable version.
It wasn't even described as a NET DIMM, so it was my own wishful thinking...

http://www.ebay.co.uk/itm/160963307406?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649

It was cheap though, so not bad for a GD DIMM, and for experimenting.

Does anyone know if the NAOMI stays on a blank screen if there's no security PIC in the DIMM board, and / or no GD drive connected?


Net step is to hook up the few extra signals for the FLEX chip / cart access, so I can then spy on what it's doing and compare to the MAME logs.

I tried to get a photo of DE1 connected to the NAOMI earlier, but I can't find the stupid micro-USB cable for my camera.
Just charging my phone now, so I'll post a photo in a mo (it's not very exciting, just an IC test clamp on the BIOS socket).


OzOnE.

 

I did say, it's not particularly exciting at this stage. Good progress though...

btw, I don't own a "physical" Japan version BIOS chip.

 

Nice progress, especially enjoyed the pictures! Since you can now flash the bios, that certainly opens doors

 

I did try running the Dreamcast BIOS on it just for a laugh == blank screen.

Although, I can now upload a modified BIOS to the board, or spy on what it's doing.
It might even be possible to run a patched DC BIOS on it, but again, not much point.

What I can already see is that the "ROM Test" option in the BIOS seems to be sending commands directly to the Flex chip.

I'd like to see more photos of some cart board PCB's if anyone has them to hand?
This would help tell me if the majority of them have their own controller which sits on the G1 but, or if the Flex chip is doing most of the work.

There are some cart pics on the Guru's page.
It looks like the Sega and Namco carts with the smaller control chips use the CN3 connector...
http://members.iinet.net.au/~lantra9jp1/gurudumps1/naomi/171-7919ab.jpg
http://members.iinet.net.au/~lantra9jp1/gurudumps1/naomi/namco1_bottom.jpg

The Actel carts with the (higher?) encryption and big control chips appear to only use CN1 (G1 bus), and don't really touch CN3 (Flex bus)?

I have a few carts on my watch list though, so I can take a closer look soon.

OzOnE.

 

Oops, not to worry.

Most of the info on the carts is on the Guru's site.
It shows which carts use a protection IC etc.

Just need to work out which pin disables the onboard Flex chip, and we'd have another milestone checked off the list.

I'm soldering the extra wires for the cart emu now.
It needs 5 wires on the top (to logic chips mainly, so the pins are quite easy to solder to), and only 3 wires on IC60S underneath.

May need to lift the 3 pins on IC60S, but much just be a case of removing the config EEPROM for the Flex chip.
All the G1 bus commands will then be routed to the FPGA board, and I can attempt to start loading a game image.

OzOnE.

 

Here's a short capture of the NAOMI writing to the ROM offset regs, and reading the data via PIO.

No data yet ofc, so it all reads as 0xFFFF, and the ROM BOARD TEST in the BIOS shows all zeros....



The ROM_OFFSET is being set to 0xAXXX XXXX.
The setting of the top bits is described in more detail here by ElSemi...

http://mamedev.org/source/src/mame/machine/naomibd.c.html

I haven't hooked up the few DMA control pins yet, and need to confirm that I can disable the Flex chip.
I also need to check if it reads the firmware ID from the Flex, and possibly emulate the NV SRAM as well.

EDIT: Judging by the above capture, the cycle time for PIO accesses is around 620ns (50MHz sample rate, so 20ns per sample). That's quite slow.
Most of the games will be using DMA transfers though, so it will be interesting to see how fast that is.
It's probably on par with the DC GD drive rate (16.6MB/s), but could turn out to be even faster?

OzOnE.

 

Afaik the battery backup is for high scores and setup info, removing it just resets it and gives you a messasge to reconfigure it.

 

Ok, cool. Thanks.

I think the supercap works in combination with the coin cell too (supercap takes over during coin cell replacement).
I realized last night that the AICA is responsible for the real-time clock, but I think they're using the same supply for the NV SRAM.

It looks like it will be possible to disable the onboard Flex chip just be removing it's config EEPROM (8-pin DIP).
So, might only need a plug-in module for the BIOS, and 8 wires soldered to a few chips (IC59, IC60S, one wire to IC29).

The FPGA can take over NV SRAM duties temporarily as well. I'm only interested in getting it to boot first.
I'll also need to hook up to the real Secure Serialflash on the game cart (when I get hold of one), which holds the board ID.

Found out a bit more about the cart compression / encryption. I forgot all about these other files in the MAME source for a day or two...
http://mamedev.org/source/src/mame/machine/naomim1.c.html
http://mamedev.org/source/src/mame/machine/naomim2.c.html
http://mamedev.org/source/src/mame/machine/naomim4.c.html

I'm hoping I can use an unencrypted game image for now, even if it isn't patched for protections.
Then I can worry about the encryption stuff once the basics are running.

I don't yet know enough to know if there is such a thing as an "unencrypted" / uncompressed game cart?
If the NAOMI will boot at least something, then that's all I need atm.


@splith - do you possibly know, or can test whether the screen stays blank when the security PIC and / or GD drive is unplugged from the DIMM board?
Mine is non-netbooting, so I can't test the network side of things.

OzOnE.

 

I don't have anything to contribute, but I'm checking this thread daily

I haven't bought a naomi myself as Naomi always seemed like a pain to use since the games come in all different kinds of formats requiring different hardware, some of that hardware requires certain bios revisions, and on top of that, some games require certain bios regions only. Anything that can make the process of running any naomi game on any naomi system is of keen interest. (AW on DC sounds cool too if that is still being considered, I'm confused on the actual atomiswave ram specs now based on the conflicting information)

 

Yeah, I'm just finding that out too. lol

It has quite a few different quirks, and I noticed there are many different types of IO boards and options.

The advantage of switching between any BIOS image quickly should be quite good.
If it only needs say 8 different images total, then it would be practical / cost effective to fit all of them into a 16MB Flash.

I think we've established that the basic AW specs are exactly the same as the DC (apart from the custom chips of course)...

DC / AW...
Sys RAM: 16MB
GPU RAM: 8MB
AICA RAM: 2MB


NAOMI 1...
Sys RAM: 32MB
GPU RAM: 16MB
AICA RAM: 8MB

NAOMI 2...
Sys RAM: 32MB
GPU RAM: 32MB
"Model data" RAM: 32MB
AICA RAM: 8MB


The System16 site has the AtomisWave listed with the same RAM specs as the NAOMI 1, and even with 16MB of extra "Graphic Memory".
I'm certain that is wrong now, but don't hold the above specs as gospel.


After a fair bit of searching, I haven't found any info saying the GD DIMM board shouldn't boot without a PIC / GD drive plugged in.
So, I did a bit of cleaning of the connectors with IPA, and it's finally booting to the logo / test screen now.

The DIMM's themselves test fine, and just says GD DRIVE: BAD obviously.
Must have been some dirt and grime in the connectors before?

With the DIMM board plugged in, but no GD controller daughterboard, it just gives the "Bad communication to option board" error.
With the controller plugged in, I get the proper GD ROM SYSTEM part on the logo.

Another gotcha which I've just read is that the non netbooting DIMM board can't support a CF adapter - is this correct?
Bit of a shame if it doesn't, but will make me even more determined to get the FPGA thing going.

I'm taking my time with it, 'cos I'd rather not kill the new NAOMI if possible.
It's taken me a few years to finally bite the bullet and buy into the arcade side of things.

I might try making an adapter from the DIMM board to a DC GD drive.

I still have the source code for security PIC, which is great.
It even simulates the excellent "NAOMI PIC Dumper" under Proteus VSM on Windoze.

http://www.assemblergames.com/forums/showthread.php?19454-Sega-Naomi-Security-Pic-Dumper
(If anyone wants the code again, just let me know and I'll re-upload it).

Many months ago, someone on here asked me to help make a multi-game security PIC, but I never finished the code.
I'm a tad more motivated now that I have the real hardware in front of me. lol

The idea was to tag an LCD onto the security PIC, so you could choose the correct response sequence for each GD game.
This is something else that could be added to the FPGA, and would actually make a neat way of choosing the cart images too.

Does anyone in the UK / Europe have any cheap NAOMI carts they wouldn't mind selling?
They're proving pretty rare on eBay UK atm, and I really need one for testing.

Thanks in advance,
OzOnE.

 

OK, here's the PIC dumper project. I hold no credit whatsoever for it.
A lot of work was done by others to disassemble and understand this code.
All I did was start adding some LCD code to it...

https://mega.co.nz/#!nxxU3TjB!M4g5-k9l7vxnCwQ1hLnbK0Dh1ARa04GkEDBpFqtakIE

If you want to simulate the security PIC + dumper PIC, you need a copy of Proteus VSM.
None of the multi-game security response selection stuff has been added yet, and due to me starting to add the LCD stuff it is UNTESTED!

I also forgot all about the following pages. Very handy info...
http://wiki.pcbotaku.com/wiki/NAOMI_security_PIC
http://debugmo.de/2008/05/pah-security/

Mainly applies to GD / CF / netboot games though, so I'm still after a cart for testing.

OzOnE.

 

Seems to be nicely going on. I'm quite impressed.
Now, if you can make Sakura Taisen run on Naomi, that'll be ace.

 

I've never really played any Japanese titles tbh.
Funny enough, I'm not much of a gamer these days, but I love retro machines and the technical stuff.

I never really liked the whole Animé thing much either, but I'm starting to get drawn in by the powerful tractor-beam that is Japan. lol
After seeing NAOMI games like Giga Wing and Initial D being played on a proper CRT (YouTube), it's very compelling...

http://www.youtube.com/watch?v=Ohp1T51vNAk
http://www.youtube.com/watch?v=XzaG8Q3qfac

(Initial D is a NAOMI 2 title though isn't it?)

I did have a Saturn for a few years too, but never had a video cable for it, so it unfortunately got thrown out. (sorry, Sega fans, it'll never happen again. ).

Just found another NAOMI Gotcha!...

Sounds like a standard cart ROM board will only work with a BIOS version D or below? (bottom of PDF page 16)...
http://wiki.arcadeotaku.com/images/f/f0/Naomi_GD-ROM_Service_Manual.pdf

If that's true, I really must keep that in mind.
I can't quite believe they would remove the cart ROM loading code from newer BIOS's though, so I may be reading it wrong?

OzOnE.

 

I don't have any first hand experience, but that idea doesn't seem logical. For instance, Sega discontinued GDrom manufacturing and naomi (and DC) gd roms as a distribution model in 2007 - various naomi games continued to be released in 2007 and 2008 (maybe a few even later) such as illvelo and akatsuki blitzkampf and these were released on cartridge format.

Although, taking a look at an auction for akatsuki right now, the description says you will need bios revision H to play the cartridge... Maybe that means sega took out the cartridge support for bios version E and later as they figured things would be on GDRom indefinately... and then put in support again later - perhaps with additional security features for the later cartridge releases?

 

That's what I was thinking - I can't see them removing cart support from later revisions.

GD's / CF's do seem popular with collectors though, but will be interesting to find out for sure.

It can't be due to lack of space in the BIOS ROM either, it's huge (up to 2MBytes).

I think you're right.
Certain games might need a certain BIOS type, but I would guess that carts would still run on later versions?

OzOnE.

 

Don't worry. BIOS revisions on Naomi were just for adding features, but they never took off previous ones AFAIK.
So far, the best choice is to use the latest BIOS which play everything while an earlier BIOS might not play the latest titles.
You can play the first ever Naomi released cart game on the very last Naomi BIOS released, no worry.

 

Excellent, thanks.

That makes things a bit easier.

I finally soldered the last few signals last night. It wasn't difficult or anything, I was just busy "researching" NAOMI info on the Web. (ie. watching YouTube vids of "dogs with eyebrows" mainly. lol)
Today I'm intending to just spy on the transfers to see what the interrupt is doing etc.

Unfortunately, due to the use of the test clip on the BIOS socket, I can't fit the DIMM board in to do any testing.
It wouldn't have helped much anyway, since I don't have a GD drive hooked up either.

I'll have to use that BIOS adapter board that I started, so I can use flat IDE cables underneath a cart.
Or, when I do get hold of a cart, it should plug into the underside of the motherboard?

I think the ROM test in the BIOS menu only uses PIO modes anyway.
DMA modes are simple though. If you look at the capture in post #29, just imagine the same process, but with a few extra control signals...

NAOMI CPU allocates a space in RAM for the data chunk...
NAOMI CPU writes an address to the DMA start offset regs on the cart...
NAOMI CPU writes a DMA count value to the cart in units of 0x20 (32) Bytes...
NAOMI CPU sets the "DMA Start" flag in the Holly chip to trigger the transfer...

Cart asserts the DMA_REQ signal which goes to the Holly chip...
Holly chip prepares for the DMA transfer then asserts the /DMA_ACK signal...
Holly chip strobes the G1 /RD signal to the cart, and a Word of data is transferred from the cart into RAM.
(The address in the cart is usually set to auto-increment).
Once the DMA count has been reached, I believe the cart likely asserts the Interrupt (the Holly also has an internal G1 Interrupt).
That's it! The chunk of data has been transferred.

So, it's hardly any different to a PIO transfer, just that the Holly takes over control of the process instead of the CPU.
Although, the transfer rate is usually set much faster than for PIO of course.


It turns out that the guy who sent me the security PIC dumper is somebody I know quite well. My memory is terrible. lol
We're now looking to finish the "universal" PIC project by adding an LCD.

The LCD routines shouldn't mess with the main security access stuff at all.
Usually, the chip will be working as before, and will only write to the LCD when you press the menu buttons to choose a game.

It will likely need a bigger PIC chip though, so all the responses and DES keys can be crammed in there.
I'm not sure I can warrant the expense of using GD disks though, so it will be a bit of a side project.

Still waiting for some cheap carts to appear on eBay, but I've found a seller who has a few for around £20 each.
He also has some faulty NAOMI's for only £15 each. Tempting.

OzOnE.