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

Get a pillow, dude, you're dreaming.

There's absolute no way of this happening.

Now doubting of Cybdyn skill's since he already proved that here but this isn't doable.

 

Didn't think so. I know the Naomi has more system RAM that a retail Dreamcast so that is out the window without massive reconstruction of each game. Not sure on the Atomiswave but it probably goes the same route.

 

I've been looking into the AW vs NAOMI vs DC stuff recently.
I know the idea has been looked at many times, but the basic conclusion is - if you want a NAOMI, buy a NAOMI.

The only way to upgrade the RAM on the DC is to of course add the extra chips.
Hooking up to the extra /Chip Select pins (BGA balls) on the HOLLY is nearly impossible without designing a new board though.

Most of you may remember LeGIT's findings in this thread...
http://www.assemblergames.com/forum...-Sega-Dreamcast-System-RAM-16MB-amp-JTAG-hack

But, a very interesting point about the NAOMI and AW ROMs is that they are accessed via the G1 bus!

They essentially use the exact same register addresses that the GD does, but they are for setting offsets for accessing the "files" inside the ROM packs / DIMMs instead.
The file data is then DMA'd into RAM in a similar way to the GD drive...
http://cah4e3.wordpress.com/2009/07/26/some-atomiswave-info/

EDIT: the idea being that the GD Emu FPGA could be made to emulate those addresses, and the ROM data loaded from SDRAM or Flash.

The Altera FPGA on the NAOMI is likely handling the DMA transfers from the ROM / Net DIMM board, and the decryption for the PIC etc.

The SEGA 315-6146 is apparently the Maple-to-JVS chip, which has a Z80 based core.
(the best summary is in this source)...
http://mamedev.org/source/src/mame/machine/mie.c.html

So, apart from the extra RAM, the NAOMI and AW are still very similar to the DC from an architecture point of view.
It's been hard enough just getting the GD Emu working though, and we're still not quite there yet.

Modifying any of these consoles (in hardware) to run games for other hardware is pretty pointless tbh.
It's just not economical, but it IS fun to examine the hardware, and have a think about the possibilities.

A working NAOMI motherboard can be bought on eBay for around $100, so not too bad.
That's minus the PSU / GDD / DIMM board / controls / carts though, so the costs can stack up.

Out of interest - has anyone ever seen the full schematics for the NAOMI or AW, or tried running the NAOMI / AW BIOS on a Flash-modded DC?

Right, I'm hooking up the DE1 to the DC again today.
It's taken me a few days just to remember where I left off, get some adapters soldered, and make sure I had the correct cables etc.

Anything I do discover will be shared with cybdyn first, then I'll try to keep you guys updated on here.

OzOnE.

 

Alright I have shared my vhdl files which I have written about the fat32 filesystem in combination with the 4dat SD interface with cybdyn. I'm pretty sure this will be a great asset.

 

Is it possible to create a VVMU (Virtual Virtual Memory Unit) on the SD card or HDD for more save files with this mod?

 

With this mod it's absolutely not possible - this one solely replaces the gdrom driver -,but there are already mods out there that can do this. Although with a few additional lines this could be an feature, but at the momebt I doubt the fpga is able to handle this - I guess that after a full gdrom interface with some decent filesystem, eg fat32, there will be not that much space left, unless you choose a more expensive fpga.

 

i'm not sure about VMU, but DC mem card is quite possible. need solder 2-wires between fpga and one of four Joy ports.

 

Thanks for sending cybdyn the SD code, jp, it will be a great help!

Just out of curiosity, what sort of input does the FAT32 part need for selecting files?
Does it just work by assigning each file / folder entry a number, and does it have something like a Wishbone interface?

It's quite hard to find some decent free 4-bit SD code, so I think cybdyn's board will run games quite well with this.
I think we need to get around 10 to 12 MBytes/s for decent performance. With a Class 10 SD card, we might not need to go the IDE port route (although, that wouldn't be too hard).

Got my DC hooked back up now, using some IDE adapters for the GD drive / FPGA.
Just need to find the damned VGA and SCART cables now to hook it up (still tidying this dump of a room, it's taken me a month to stop being lazy. lol).

OzOnE.

 

Why 10-12MB/s ??? the real gdrom uses max 5MB/s i think

 

Well more or less it’s a wishbone structure, some parts are some are not (everything I had done was with the thought to reduce the amount of logic elements, since the “areaâ€￾ of my fpga was quite small, and I did want to spent too much money)

My setup (destroyed it a month ago, to sell that Dreamcast - I hadn’t worked on it for years) : FPGA(ep2c5t144) directly connected to the GDROM drive test points (had separated the power lines by a FET with the intention I could run games through my fpga or GDROM driver, also this made it possible to easily monitor the data send by the GDROM), SD connector, 4 buttons, and a LCD screen.
In my fat32 system I let the user select a gdi file through 4 buttons and a LCD screen. The file and folders are represented through there short filenames (first I had long filenames but it took just to many LE’s) where I let the other processes just make use of the FAD address.

I let the fat32 part keep track of two ram blocks (to speed up the whole process) a file allocation table and the current block of the file. These two blocks are also written independently by my sd interface (in the background).

Back then (2010) I couldn’t find an interface for the SD card at all (written in VHDL). Especially the 4dat interface was impossible to find in any language. So it took me quite an amount hours to read the datasheet and try to fill in all the blank pages (which were only visible for very wealthy people or organizations). But in the end I did succeed, it now has really a great interface and it uses only 336 logic elements, which I think is quite impressive.

To let the loading screens disappear in a split second

 

The Atmel parts do, and so do some of the later STM32s (2xx and 4xx connectivity line series, I think).

 

Well, because the normal DMA transfer rate for the original GDD is actually 16.66MBytes/s peak.

You're probably right though - judging by the loading times and video playback on cybdyn's vids, I think around 5MB/s will do it.
I doubt that the GDD will be streaming at the full rate all of the time, but would be nice to reduce the loading times too.

Looking forward to good things from jp's SD card core.

@jp1357 - are you saying you had GDI's running fine a long time ago? :O

Would love to see some photos of your setup. Sounds great!
Do you have a web site / blog at all?

OzOnE.

 

Well not really (I said intentionally ); only the DMA process and the audio tracks I still had to do, where I believe the latter one still has to be finished by you guys as well.

At that time I was in an unofficially battle with Deunan (he didn’t know it ) but I really wanted to finish it before him, but then he really made some big improvements and I still had to finish the whole DMA and audio part, which I knew truly nothing about. And at that moment I had read already so many freaking PDFs and websites about how to do certain things, and had spent literally hundreds of hours on this project, so I reached the state were I lost the fun and interest of it, because I didn’t wanted to invest more and more time, because I didn’t had that much spare time left anymore and also the whole VHDL part wasn’t really helping. Some of the easiest things are freaking hard to implement in VHDL (consequence some parts are really easy), and I only had around 1000 LE’s left to use… So I was actually in a state where I did not really knew what to do… Solution I threw my DC on my closet.

Until recently where I saw my DC again and thought hey lets sell this one (since it had a few holes in it because of the SD and LCD, and thought I will not finish this project any way – still got no spare time – and I rather keep an untouched Dreamcast) Also those Dreamcasts sell in my country for quite some money, for a working DC, where the looks suck, I can easily get 65 dollars.

But I have no pictures. Hihihi why would I?? It looked damn ugly. I didn’t invested money to make a nice PCB like you guys – it was one big wire thing… So around a month ago I took a scissor and had cut all those wires – I didn’t desolder them because some of those test points were pretty much destroyed these wires were the only thing that still kept a connection between those damaged wires so I closed the DC and on the mail it went

But after a week I actually regretted it and went searching on the net where I reached this topic… But hey I still don't want to finish it, because I'm sure it will cost me way too much time and it will be at the cost of way more important things in my life. But feel free to PM about certain things.. I will gladly help out... if I can.

 

As for DC vs Naomi stuff, I still wanna play Sakura Taisen on my Naomi.

 

@jp1357 - Thanks for the background on your project.

Don't worry about it looking ugly, you haven't seen this DC monstrosity I have just created. lol
I don't yet have a nice all-in-one PCB either, only cybdyn has done that so far.

I know exactly what you mean about the amount of time it takes too.
I was self-employed while attempting the GD Emu project, so had a bit more spare time than somebody working full-time.
Even then, it takes so long to make any progress with stuff like this. I had to learn a lot more about Verilog at the same time.

(I can read VHDL, but personally think it's way over-complex compared to Verilog. That's a whole other thread. )

I spent literally months on it already, so got rather fed up in the end.
I went as far as trying the IDE adapter / software patch method, 'cos I just couldn't get the damned thing to boot games.
Luckily, I found the R4 Dev ISO, which made it SO much easier to get started with DC coding (I generally use Windows, so had to compile the DC stuff under cygwin).

If you're pretty good with a soldering iron, I can send you a DC IDE adapter kit?
It makes it easier to connect to an FPGA board via a standard IDE cable (plus some pin headers for the CDDA and Reset signals).

Good point that cybdyn made about the VHDL / Verilog stuff though - it's definitely best to keep that only for the very low-level stuff, then use an MCU for the higher level control / parsing.
I've yet to find a straightforward CPU core for the FPGA, and had nightmares trying to get a simple NIOS II setup working.

I didn't really want to go the whole route of designing a PCB specifically for the DC either, especially as it wasn't a proven design and would cost a fair bit to get the boards made.
(EDIT: to go the MCU route, I would ideally need to make a new board, or get a decent but simple CPU core running inside the FPGA).

As a funny side story - I might have mentioned before that I've had trouble soldering the IDE adapters?..
Well, it's not as bad as it sounds soldering the DC / GDD connectors, it's that I keep on making other stupid mistakes...

I've just got my DC setup put back together and found a GD drive which still works, then I went to try the IDE adapters I soldered the other day == no boot!
As usual, I'd soldered the damned IDE socket onto the wrong side of the board! LOL

Oh dear. Time to buy some more IDE connectors, as that was my last one.

Eventually, I'll have a setup where I can easily plug in the real GD drive, or the FPGA board, or both (for spying / ripping).

Thanks for your offer of help btw, I think we're going to need it. hehe

cybdyn has a great proof-of-concept now, he just needs to find time to increase the SD speed a bit, and sort out the multi-game / FAT32 support etc.

Again, I personally think CD Audio support is secondary to getting it running well with lots of games.
I'm hoping the DC doesn't do any major CD accesses while an audio track is playing, as that will complicate things quite a bit.

btw, if anyone has any DC coding experience, they may be able to help with a menu system for choosing different game images (I may be being a bit premature here - don't want to put pressure on poor cybdyn. ).

I think I can manage a basic menu system though...
It may be just a case of writing a start-of-GDI value to a "hidden" register on the FPGA (via the G1 port), then resetting the DC to let the BIOS run the game as normal?
A reset button on the FPGA board itself can point it back to the menu image, then reset the DC again (hook up to lid switch maybe?)

OzOnE.

 

Connecting something to the lidopen pin is absolutely useless, that pin is a dead end (if I recollect correctly). How you should isue a lid open is by an interrupt and then state in the error message that the lid is open.
But the dreamcast has a test point on it that can be used as a hard reset.

the DC game menu isn't really easy to make since you should have a variable list. So maybe a list with all the games already in it and then don't show them if they aren't present (which could be achieved by letting the dreamcast access pre-defined addresses such that the gd interface knows how it could respond depending on the game), and then indeed issue a reset??

about the mcu in combination with the fpga is certainly the method, when building, you can achieve the highest speed, but yeah... to me it would be more an achievement if you put in one, looks more impressive (and it can be done, but achieving it is something completely different)

vhdl is know to be a bit harder, you have to have a completely different mindset, and if you write something in vhdl and you follow the rules precisely, you know precisely what happens at what time, which I think is really a big pro.

 

ok, about HDD i remeber one important think - hdd should be stoped properly??? maybe there is aSpecial command in task file ?? so to use hdd we need make special power down mechanosm - like in ps2 w/ buttons , not w/ switch!
also - in ps2 : there is even special IOP module - like poweroff.irx or something , to send to all device pow-off request and chk them before send to pow mcu to off power.

 

My τhoughts about the menu

1) DC power on
2) FPGA Power on
3) FPGA Reads all the GDI Files on SD/HDD etc
4) FPGA Generates a temp GDI(Menu) With all games in a list
5) Load the temp GDI (Menu)
6) Select the game the GDI (Menu) will sent the game to FPGA *
7) FPGA opens the tray programmatically and then loads the game and close the tray.


* How to tell to the fpga what game to load (i dont know if this solutions can be done)
1) The temp GDI(Menu) reads special files that make the FPGA to understand which game to load!
2) Connecting the FPGA to the serial port of dreamcast and start a communication

 

jp - I meant to just have a separate switch on the GD Emu board itself, which will eventually replace the GD drive anyway.

It would be nice to be able to enter the game menu when a button combo is pressed, but that would require a memory-resident patch (something I wouldn't have a clue about).
Or, a better way to do it is to hook up a few wires to the Maple bus so the FPGA can read the controller buttons. There is already working source code available for that as well.

@madsheep - nice idea, but would be quite complex to generate a menu GDI on the FPGA (even with an MCU core).

Actually, selecting the start offset of a GDI on the FPGA isn't too difficult - you can simply write to some unused registers via the G1 port (or send a "magic" value to a normal register).
No serial port needed, it can all be done via the G1 port and some regs.

FAT32 parsing from a DC menu should be relatively straightforward as well, but a pain to follow the cluster chains on the FPGA alone while streaming the actual game data.
It's easier just to make a Windoze proggy to write the GDI images onto the SD / CF / HDD consecutively, then write very simple file table with the filenames / TOCs / track start offsets.

Hmmm, Maple bus idea is interesting. I must try that.

I currently have my DE1 connected to the DC again.
It loads IP.BIN (license screen), then seems to be loading 1ST_READ.BIN, but still getting stuck after a SET_MODE packet command.

It does show that my SD card controller is likely working OK, otherwise the IP.BIN checks would fail, and it wouldn't be reading the PVD from the GDI track to find the 1ST_READ.BIN offset.

Slowly working through it again with cybdyn's help.

OzOnE.

 

The safest and most general way to do it is to use the ATA SLEEP command - this will flush all the buffers, park the heads, spin the disk down and then generate an interrupt. For some reason the STANDBY command is allowed to generate an interrupt before the drive is actually in standby (yes it's stupid - but the spec allows it and some drives from brain damaged manufacturers actually implement it this way).

Having said this, if you are just reading from the drive then with modern hardware just killing the power is not a problem - they are designed to drive the heads to the parking position when the power fails (often using the energy stored in the spindle to do it).