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

lovewiibrew: i remember what i did say to you about sending alpha to you as tester)) i dunno how, but what it comes we talk about))

 

@cybdyn - I know your idea of redirecting the syscalls was a good suggestion, but a few weeks ago I didn't think I would ever manage to get as far as writing my own DC code. :smile-new:

It's fine if you are already experienced with the DC and want to try. For me though, this is my first ever attempt at DC coding.

In the last hour, I'm starting to get somewhere with accessing a CF card via direct G1 port connection...
So far, I can display the "Identify Device" data on screen, but this is just PIO.

I've added some code for setting up and doing a DMA, but it just freezes the DC?
The problem could be because the CF card is asserting an interrupt afterwards (and the Stock BIOS int routines are kicking in), so I've tried disabling ints on the card?

Does anyone know a simple / cheap of debugging on the DC itself? I can't do it on an emulator of course because this is all hardware.

Also, I'm not sure of the best place in DC RAM where I should DMA the data to?
At the moment, I'm writing it to the usual location where IP.BIN is loaded (0x0C008000) - would this be overwriting my GD-Debug app though?
Maybe I should write it nearer to the end of RAM?

I'm running the DS "bootloader with BIOS" and starting my app from DS. I wonder where DS loads the app before running it?

btw, I still need to plug the GDD in to get DS to boot. Then, I unplug it and plug my CF card in.

Something I did realize is that they are both IDE devices - so, if you set the CF card / HDD to "Slave" then it should be possible to have the GDD plugged in at the same time!
I will test this later 'cos I'll need to modify my code. Having both devices plugged in might complicate the syscall redirection later on though. :concern:


Still coding.
OzOnE.

 

i just notice, that almost all i hear from your new ideas - i went around the same way , but you make it in real now. so it's more advanced than just-talking as me)))

maybe - there is AllocMem is like syscall too? or beter ask to Swat. so you can allocate mem where you need in free area))

so your dc driver can read data after "Identify Device" comand? if so, it sounds cool!

what if you cut int line and pull it to 3.3v through 10kohm on your board? or you need use int in other case?

 

@cybdyn - Well, the Identify Device command appears to work and shows a partial CF serial number / model on-screen, but there are corruption issues with both PIO and DMA?...

I had a bit more success yesterday - it's not working properly yet, but I managed to DMA directly from CF into DC memory (via the G1 port!)...

I can print a small part of memory to screen now too (probably quite easy for most software guys, but I NEED to learn more about pointers etc!)

For some reason though, the first chunk of bytes is fine but after that it gets corrupted? Interestingly, a small part of the on-screen text / font gets filled with a white bar while doing the DMA?

So, I separated the DMA from the on-screen hex print and it's definitely the DMA that's getting corrupted. The on-screen print works fine every time (same data).
It's very annoying because the first part of memory matches the CF card contents perfectly?

I don't know if Kallistos is doing any DMA stuff in the background, or accessing the BIOS / Font ROM at the same time?
It could be because I'm running the CF card at 5V and hoping the on-board resistors will protect the DC? I'll try it with 3V3 - maybe one of these cards will work at 3V3?

I'm currently doing the DMA from CF directly to 0x8C008000. It could be interfering with the debug app itself?
The interrupts don't seem to be a problem now, it works the same whether the drive int is enabled or not?

btw, Thanks, @cybdyn - I forgot that I'm using an OS (KOS), and I probably need to do a "malloc" for the DMA :redface-new:. I'll try that next. :encouragement:

OzOnE.

 

Never mind, I think it's working now!

I don't know why, but if I test the status of the DMA transfer, it just gets stuck?...

*SB_GDST = 0x00000001; // Start the DMA !
// while ((*SB_GDST & 0x00000001) == 1); // Wait until DMA transfer finished (polling for now).

This reg starts the DMA when you write a 1 (auto-resets?). If you read it though, it should return the status of the DMA (1=="DMA in progress").
I'm assuming I'm suppose to mask it with 0x00000001, and not just 0x01? *SB_GDST is defined as a (*uint32) pointer.

Basically I'm pretty sure it WAS the Font ROM access that was causing the corruption...

Originally, I had the above check of *SB_GDST reversed (0 instead of 1), so it wasn't waiting for the DMA to finish at all.

So, in my main loop, it was printing the "ATA Status reg:" value to screen during the G1 DMA (doh!)...
I knew from the DC programming bible that you can't access the G1 port and Font ROM / BIOS ROM / FLASH at the same time ('cos they're on the same bus).
The Font ROM was being accessed for printing to screen, and this was screwing up the G1 "GD" DMA.

It still seems to freeze when checking the *SB_GDST, so I just skipped the check and added a small delay after doing the DMA.
This gives enough time for the DMA to finish before I start printing to screen again (using the Font ROM stuff).

The small section of data that I can view looks perfect every time now. :victorious:

It's still early days yet, but...

Next thing is to confirm that bigger chunks of data get DMA'd properly, then get it to work as a slave drive while the GDD is still plugged in.
Hopefully then, Mr SWAT can add support for this in DS.

I wouldn't build your hopes up for proper GD syscall redirection any time soon (so no direct GDI support or better compatibility unless someone else codes it).

We also need to get some of those nice IDE adapters made. Can anyone help with the PCB layout?

I don't mind paying for the first few test boards.

Again, this is NOT for the FPGA board, just the G1-to-IDE adapter. The coding / testing is NOT complete, and this is NOT supported in DS (yet).
So, assuming this really is working (and is not just my imagination), consider it in early ALPHA stage. lol

OzOnE.
P.S. In summary, for the non-techies - If this can be made useful in DS or a BIOS patch, it means no more slow SD Cards; just a cheap DC-to-IDE adapter, and FASTER CF Card or HDD access.

 

did you try test DMA with your device(fpga) or directly-conected CF card?

i cant get what you actully do. did you make your code and try manualy activate DMA xfer from direct-connected CF?


dma protocol can be different.

 

Interesting - using an interposer to split the G1 bus to two ports; one for GD-CDROM, and one for IDE-CF.
-You don't even need to have a custom bios for that one (Just a custom loader)

Could you just move the Font ROM to a free chunk of RAM?
(Perhaps using someones else's text-render library?)
You know I SWEAR I've seen a simple app that did just that - it was some sort of MP3 player/ elf loader / FAT directory browser homebrew... or just use KOS... or something...

 

@cybdyn - This was DMA with direct connection of CF card to G1 port. I tried a 2.5" laptop hard drive too, and it works fine.

I basically just took most of the steps described in the DC System / Dev Box guide and added code for displaying RAM on screen too.
So yes, just manually setting the HOLLY registers for DMA, then sending the DMA command itself to the CF regs.

I now have it working so I can set the CF / HDD as Slave and leave the GDD plugged in at the same time.
Unfortunately, if I try to access the GDD after doing a DMA from CF, it freezes? Accessing the GDD before the CF works OK though?
I'll have to figure out what's screwing up the GDD (probably the DRIVESEL register?).

@cybdyn - you have a good point - I haven't tried the new DMA code with the FPGA yet. This is ATAPI though of course, but I might be able to test it easier now (if that makes sense?)

Oh, btw, pretty much all the code you need to redirect the Stock GD syscalls is in the dcload source!

@Melchior, yep, could just use a custom loader like DS or something? I suppose this is easier for most people, but I do like the sound of a BIOS mod.

I'm not too worried about the Font ROM stuff now. I just need to be aware of how (and when) to access it.

I have a feeling I've seen that sort of app too? Would have been around ten years ago though.

Cheers,
OzOnE.
P.S. Fairly drunk atm. I don't know how I manage to type OK? Just had a three-day party for mine and my Dad's Birthdays. :very_drunk:

 

Happy birthdat to you and your father!

... now get sober and keep on working little selfmade engineer!

Ps: You rock!

 

Happy birthday, man

You deserve a big Sonic the Hedgehog cake.

 

Happy Birthday! :congratulatory:

 

Cheers, guys!

I'm almost sober, but I now seem to have a bit of man-flu. :moody:

Good party though. It was raining on and off, so basically ended up being two parties in one. One party upstairs, one downstairs in the garden.

Had my homebuilt 1W RGB laser showing a few graphics on the trees, speakers in the garden (to hell with the noisy neighbours), teenagers inviting gatecrashers, police drive-bys,
beer, cocktails, pizzas, Thai food, lasers, smoke machines, and music ranging from Chemical Brothers to ZZ Top. Great time! :very_drunk: :biggrin-new:

Anyway, just a quickie. I've got the CF to work with the GDD plugged in now. I can read from GDD (PIO atm) and CF (DMA) without problems.

I still need to try a DMA from GDD and I'm messing around with GD syscall ridirection.

tbh, I think it will take me another year to get GDI's booting. So, I'll have to ask SWAT if he can add direct CF / HDD support in DS.

Even if it only runs CDIs for now, it should be a hell of a lot faster than SD Card via the serial port.
btw, does anyone remember if DS only supports CDI because of a major stock BIOS issue, or was it for some other reason?

OzOnE.

 

Personal note: fly to UK for Ozone's party next year.

 

lol. Well, we only had around 35 people, and not everyone around here actually dances (including me), but it was a good one.

A quick project update - I've started adding GD syscall redirection to the test code.
At the moment, I can do a GD syscall (from within my debug proggy) and it redirects back to my ATA routines...

In other words, if a game does a GD syscall (via stock BIOS), I can force it to DMA the sector data from the CF / HDD instead of GDD!

I haven't looked at parsing the TOC or anything else, and I might hit some security stuff later on, but it's a good start.

I've also confirmed that the data is being DMA'd from CF correctly...
I didn't have a good way of comparing large chunks of data, then I realized that I can use the DC to WRITE to the CF card too!

As a test of the ATA routines, I just DMA'd 210 GD sectors (840 CF sectors) into DC RAM, then wrote it all back near to the end of the CF card.
The DC freezes after the DMA Write, but it's not important atm (the DMA itself still works).

On the PC, I then checked that the CF contents matches the original GDI - it works 100% ! :tongue:

No booting of games yet, but I can now take the code to Mr SWAT and see what he can conjure up.

The other bit of news is that a CF card or HDD should work OK as a slave, so the GDD can be left plugged in and no extra crystal is needed on the ATA adapter.
(I'm still trying to sort out the PCB layout btw.)

Again, CDDA streaming from CF / HDD with a simple adapter will NOT be possible unless it's done in software somehow?
The only other possibility is that we can send commands to the GDD purely for playing the CDDA tracks from a disk (kind of defeats the object though!).

I haven't successfully managed to switch back to GDD after reading from CF yet (without resetting the DC), but who cares at this stage? It should be fixable.

IIRC, I can still read from GDD via PIO though, so I should be able to get basic GDD PIO -> CF / HDD DMA ripping to work.

It's starting to get fun again (for the time being). :excitement:

OzOnE.

 

I'm getting excited for this. My offer for beta testing still stands. If I get documentation and the required tools, I could try debugging once it is time for beta tests. Maybe...

 

I don't post much in this thread, but I like coming back to it and seeing the newest updates and progress. This is an exciting project for any DC enthusiast and I want to thank Ozone, cybdyn, and others for the work and research done so far!

 

well while a game being loaded isnt quite possible yet have you tried loading a small program or even your debug console from the CF yet?

 

Same goes for me.

 

I tried booting the IP.BIN directly, but it just freezes? The problem is that the debug app is built under the KOS libraries, and I don't know how to allocate memory, or even which parts of memory are free, or how to directly jump to exec some code?

If I try to load too much at 0x8c008000 (the usual load address for IP.BIN, IIRC), it also freezes because the default location for "text" sections in KOS compiles is at 0x8c010000.
I'll try loading the app near the end of mem then see if I can run the IP.BIN again.

Apparently, the license screen code is at offset 0x300 into IP.BIN, so the idea is to load it into the normal 0x8c008000, then jump to 0x8c008300.

I've tried doing...

void (*go)(int);

...and loads of different things to jump to the code, but it freezes or resets back to DS. I don't know if I'm supposed to save the stack or anything?

It also would be nice if I knew how to jump to the stock bios after enabling the GD redirection. This will need to be done at a point AFTER the stock BIOS has loaded it's own syscall vectors.

It looks like SWAT's "Bootloader with BIOS" Flash is based on version "1_004_01.bios", and I can see where the bootloader has been added. The problem is, my app is way too big to fit into the stock BIOS (around 270KB!).
Ideally, I want to build a raw stand-alone app which doesn't use any of the KOS libraries and all routines are internal. I don't think it will take up much space, it's just the libraries which are bloated.

I also want to get rid of using ROM Fonts. It's still causing tons of problems and corrupting the on-screen stuff (even though the DMA itself is working fine?).

btw, I've also got basic TOC spoofing working. It took a while to figure out that the same command is used to read the low-density and GD TOCs. A parameter is used to select the session - 0=1st session, 1=2nd session (GD etc.).

As expected, if there are two tracks in the low-density area (standard Data + Audio), the first two entries in the GD TOC are left empty so the GD data track starts at entry 3.
The code simply scans through the available sessions and "merges" the two TOCs together (in logical terms).

It looks like the BIOS uses CMD_GETTOC2 most of the time. I don't know what the hell CMD_GETTOC is for though?

So, I can only read sectors from a GD disk via PIO, but I can now display the real GD disk TOC, then enable GD redir (reads from CF!) and display my spoofed TOC. The TOC results are identical!
The spoofed TOC(s) are set up for a standard 3-track GD atm.

Reading from CF is done via DMA, so it hopefully emulates the way a normal game would access the sector data.

I still can't switch back to GDD mode without it freezing though? Oh well, save it for a rainy day.

Does anyone have a really basic code example with it's own (small) font which will compile under Cygwin?

Regards,
OzOnE.

 

Another small update...

I've posted on DCEmulation now, and got a great response from BlueCrab who posted some PSO Patcher code.

I added some parts of the code to mine, so I can now properly jump to the IP.BIN bootstrap (once it's loaded from CF).
Unfortunately, it's not booting, but I've got a Sega Logo again!

The problem is it just reboots after that point? No doubt there are extra bits of redirection code which need to be emulated properly?

Oh well. I suppose it's progress.

I also got the debug code to switch back-and-forth between GDD (PIO) and CF (DMA) reading.
I'll try to rip some sectors from GDD to CF next.

OzOnE.
EDIT: Thanks for thanks everyone!