"Let's make GD ROM emulation happen" Facebook group.

I think it is easy the fpga will only list the files in the SD card and then will alter an already created image that is present in the SD card to inject the list

 

Easy huh

Well yeah it can be done relatively easy by letting the menu read a file, and you will just wright, on the fly, all those names. The file should be located then probably at the end of the “disk”.



I dislike the method of making a program on windows with its own table of contents list (although in the beginning this would be really easy), since FAT32 is quite easy (have used it a lot), the only thing that sucks about it is if you want to read the previous blocks.

 

power down is not good cause it happens quite fast.
i think good info should be in source for hdd fro ps2 ata driver. maybe i find exatly this "SLEEP " cmd...

 

about menu - in best case i prefer use menu like DreamShell. i asked SWAT yet, he can help.

 

The easiest place to get the command info is from the ATA8 draft spec:

http://www.t13.org/documents/UploadedDocuments/docs2006/D1699r3f-ATA8-ACS.pdf

But to save you the time, the official command code for SLEEP is 0xE6 (note that some old code uses 0x99, but this code is technically retired since ATA-4, although it's still widely supported).

Note that this is an ATA command, not a packet command - so it has to go into the command byte field in the task file.

 

I know the ATA commands quite well from the Doctor V64 HDD project, but modern drives don't need a command to spin down or anything.
99% of drives park the heads automatically. It's only because most OS'es have files open that need to be closed properly and buffers flushed that we have a Shutdown button tbh.

I might have missed something here though - what would be the idea of sending the SLEEP / power-down command when the GDI will be streaming most of the time?

@jp - FAT32 in itself is easy enough, but I don't like the idea of having to follow the cluster chains on the FPGA as it could slow things down a bit.
Also, some of the DC accesses will be less than the cluster size, so you'd have to read in say 4K at a time, then skip to the correct "sector" offset (or load, then dump the excess).

EDIT: Actually, that was rather stupid of me - we're not constrained by any sort of OS, so we can still read whichever "sector" we like.
The only thing to keep track of is which cluster the chosen sector is within. It will work much better if the whole cluster and file / folder entry tables can be cached somewhere.

Dreamshell would be an excellent choice for the menu. It doesn't take too long to load, and should load even faster once the GD Emu is up to full speed.
All the code needs to do is access some extra registers via the G1 port. It can already do FAT32 parsing ofc, so all it really needs to do is to set the start offsets for each "track" in the GDI once you've chosen a game.

I think I could handle a very simple menu system for the DC, but my limited coding skills won't extend to making it look pretty or anything.

Come to think of it - I don't think it would be too hard to make a "template" GDI which just loads the menu binary.
You could just use any "standard" 3-track GDI TOC, then replace 1ST_READ.BIN with the menu (basically, normal CD-R type methods, but in a GDI).

CDI / CD-R ISO / MIL-CD support will follow later ofc, but I love the idea of running pure unmodified GDI's for now.

I looked into the Maple bus spying yesterday, but realized that the existing code is designed to directly talk to a controller, so it sends out the query commands to it first.
We'd need to modify that just to spy on the response packets if we want to capture the button presses.

I'm looking for a reasonably straightforward MCU core for my FPGA now, to help get my board running.
Trying to print debug strings to the serial port without using C is a PITA. It's not much fun doing it in Verilog, so I'm not even going to bother. lol

After cybdyn's success, it has really spurred me on to try again.
It proves now that it definitely can work, and there were no great security hurdles in the end (not so far anyway).

I'm sure some games will need to read the subcode data ("RAW" tracks) for copy protection, but I think cybdyn has some interim support in place for this already.
Once the code for handling the GDD commands is fleshed out a bit more, the DC should be oblivious to the FPGA, and will just think it's an original disk.

OzOnE.

 

That was pretty much what I said earlier, but since the question was asked about how to shutdown the drive cleanly, I answered it.

 

Yep, no probs mate. I saw your earlier post.

Don't see the need for a sleep command personally, unless the drive isn't being accessed for a long time (which is unlikely on the DC).
Just wondered if there was another specific reason that I'd missed?

 

Oh dear. I had a brain-fart moment the other day...

I started wondering exactly how the NAOMI accesses the ROM carts / DIMM board, then did a bit of testing on the real hardware.

The NAOMI I bought last year had it's GPU removed, but I grabbed it anyway to have a play.
I did intend on stealing a Holly chip from a DC and resoldering it to the NAOMI, but I don't think it's worth the effort.

(The NAOMI board isn't looking too good anyway, and I didn't want to be messing with BGA reballing kits.)

Anywho, the other day I traced some signals from the (missing) Holly chip and found that the G1 port bus goes pretty much directly to the Altera FLEX FPGA.
I then found the info in the MAME source about how the NAOMI accesses the ROM / DIMM packs via the G1 bus.

Accessing a ROM pack looks to be a far simpler mechanism than the DC uses for the GD drive.

So, I thought I might as well branch off in the NAOMI direction while cybdyn works on the DC / GD side. What do you guys think?
I will of course be helping cybdyn as much as I can in the mean time.

Would there be any major interest in a ROM emu for the NAOMI?
(I'll be concentrating on ROM packs for the time being, but it could possibly be extended to emulating the DIMM board in the far future.)

I'm now trying to source a working ROM pack and NAOMI (that isn't too expensive), but I should be able to get a lot of info from the MAME sources for now.

Any info on the board that I find I will be documenting and eventually releasing.
There doesn't seem to be much direct info on the NAOMI hardware itself apart from in sources like MAME or other emus.


OzOnE.

 

I saw today that I guy sold the dimm board kit with the naomi plus the hacked CF card rom adapter for $1500 here in Brazil, imagine what people would pay around the world.

I believe there would be major interested if this could be worked out. I keep visiting naomi discussions threats around the internet and it seems there's a big fan base that would love it.

 

I think there would be some interest. I don't have a NAOMI kit myself but I do believe people would be interested in it. The motherboards are fairly cheap compared to complete systems and the GD drive itself. If there was some way to read a CF card cheaper than an original GD drive or DIMM board then interest in this classic arcade system should skyrocket thus driving up the price of the boards and other IO needed to drive it. That could be a problem...

 

no. most people think its for BIOS protection, so if you place modified bios - Naomi wont boot at all because of this Altera.
all DMA/PIO/protection tasks do the cart itself.

AW bios probably will hang at cart access atempt.
Naomi wont boot too, because it needs EEPROM with serial number on SH4's PDTRA, plus many other things.

in general - FORGET ABOUT NAOMI, even if you somehow boot the BIOS after logo it hang because of 2x small rams.
if you dont beleave me - compile MAME with DC ram/vram/aram sizes in naomi.c driver and see it by yourself.

but AW on DC looks more or less possible with gd-emu. but there are few problems/tasks must be solved:
1. bios is 128Kb flash chip, and code have checks is it really flash and is it writable
2. 128Kb SRAM after bios
3. coin buttons in G2 area at 0x00600280 in SH4 adress space.
4. AW uses the same controller as DC (from "how it woks" point of view) but the buttons is shuffled, imo not a big problem

well and the cart itself, but if you guys manage to emulate gdrom it is not problem too, coz AW cart is much much simplier than gd, and simplier than Naomi carts.

add: and btw, if someone want to gain a bit of money - AW Flash-Cart will be really good and not too hard to do idea

usually 3x-5x less price

 

Sounds about right from what I've seen in these areas.

 

Right, I've created a new thread so as not to pollute this thread with the NAOMI / AW stuff....
http://www.assemblergames.com/forums/showthread.php?48293-NAOMI-AW-possible-ROM-Emu-project

As I say, I will still be helping cybdyn with the DC GD Emu stuff whenever I can.

OzOnE.

 

I do have a CF card reader for my Naomi and AtomisWave games. All of them are on CF card. ^^

 

If Dreamshell can read GDROMS...
Or trying to make a usefull tool for all version windows, automatic creates a compressed CD-ROM Dreamcast with a custom boot compatible.
After we do that, we can chosse....
60 ghz
70 ghz
PAL
NTSC
JP
Name of the CD
And a few extras

The old tools can´t work ok on x64 well.

Update:
The Japanese Cake website make a GD-ROM Read only to extract all the game files, to make a new Boot.
But i like to see someone compressed the files and make them read without lossing the content quality.

 

???

 

Great progress so far! You guys are making stuff happen that naysayers said can't.

Suggestions, questions and requests:
Is USB HDD support going to be an option in the final version? Please don't add IDE/CF support as this dieing technology, as is getting very hard to find for cheap, and years later it will be difficult to replace. SD support is nice, but it makes it annoying for collectors to hold many games on hard to label/easy to loose devices. I am also looking for a child friendly design/menu, so my 4 year old can just start a game without options(and without ruining my DC discs).

Additionally, If I donate can my donation be used towards a purchase price of a final product?

 

i plan use IDE, SD, USB OTG (host / device) and ARM MCU + FPGA. better add all, easy dont use, than solder additional wires)))

 

You have another customer here!