G1-ATA Devices

[|darc|]

Success with a SATA adapter! Only one left in stock at the moment...
http://www.amazon.com/gp/product/B000ZLM9IA

I'm using an old 120GB 2.5" Fujitsu SATA hard drive, with the jumper on the adapter board set to slave.

Код:

Starting G1 ATA test program...
g1_ata_scan: found device with LBA48: 234441648
Looking for first partition...
Reading 1024 blocks by DMA!
DMA read took 65 ms (8.065969 MB/sec)
Reading 1024 blocks by PIO!
PIO read took 155 ms (3.382503 MB/sec)
Both buffers matched!

Sonic Adventure (NTSC-US) runs great!

https://www.youtube.com/watch?v=-UifB6JWYHc

[OzOnE]

Well done, [darc].

Strangely, I was just watching your vids, 'cos somebody posted it on the Dreamcast House Of Talent FB group. lol

Glad to see it can work with SATA adapters, as the cheaper ones can normally only be set to Master and not Slave.

Nice vids btw. I was just admiring your Sony PVM too.

OzOnE.

[|darc|]

(04.06.2014 02:40)OzOnE писал(а):  Well done, [darc].

Strangely, I was just watching your vids, 'cos somebody posted it on the Dreamcast House Of Talent FB group. lol

Glad to see it can work with SATA adapters, as the cheaper ones can normally only be set to Master and not Slave.

Nice vids btw. I was just admiring your Sony PVM too.

OzOnE.

Haha, that was me who posted it in Dreamcast House of Talent!

Oh, and that's a Sony BVM--even better than the PVMs! Just got it about 2 weeks ago, it's only 14" but it's going to be used as a monitor on my workbench for console work. It's so gorgeous!

[OzOnE]

oic. LOL

Makes sense now - I thought it was a bit quick after you uploaded the vid.

Nice monitor.

I just rescued our last 14" CRT TV from the skip a few weeks ago - glad I did, as they never quite got there with reproducing the CRT "look" on modern displays.

I ordered one of those same SATA adapters from Amazon btw.
Will be good for testing on DS RC2 now that you've confirmed it working.

Now I just need to find or buy a spare SATA HDD.

OzOnE.

[SWAT]

Good job with SATA adapter. You are lucky as I and hoped ))
I also order it for yourself But I see, the speed in DMA noticeable worse than on Native IDE (up to 4 MB/s less)... And PIO mode too, but not much (there may be a delay in requests).
Your adapter based on Marvell 88SA8052, maybe another adapters on this chip and slave support can be success.

BTW, for this game (and part 2) you can use DMA transfer, just setup checkbox for it on settings page of this application.
It's can be work even better. Yeah, really better
Very sorry that I have not been able to do DMA support for all games, I still do not know the reason for not works it in most games, so while I added this option.

[wallace]

g1ata v2

  ide1.jpg (Размер: 142.81 Кб / Загрузок: 102)

  ide2.jpg (Размер: 144.56 Кб / Загрузок: 93)
докучи, залепил sd поближе к serial

  sd1.jpg (Размер: 168.09 Кб / Загрузок: 91)

  sd2.jpg (Размер: 171.59 Кб / Загрузок: 85)

[zolwikwkurwik]

I see some harcore DC case raping there
What about that AV+serial hole?

[wallace]

Yes, dc case has suffered
for av + serial I installed db25 female connector

[cybdyn]

платы g1-ide adv.
http://s018.radikal.ru/i515/1406/77/797ed35c12de.jpg

[OzOnE]

Hi,

I'm just trying out Dreamshell 4.0.0 RC2.2, and it's great!

I see a lot of things have been tidied up and improved.
Really nice job, guys.

I'm just trying to find a spare HDD for testing atm. I'm sure I have one somewhere. lol
I have a few that I can try (I received the same SATA adapter as [darc] is using.)

@SWAT - could you possibly write a short list of what each different custom BIOS does atm?
eg...

sd_loader_with.bios...
Boot DS from SD = Yes.
Boot DS from IDE = No.
Boot DS from BIOS (Romdisk) = No.
Run GDI in IP.BIN mode = Yes.
Run GDI in Direct mode = No.
Stock Syscalls intact = Yes.


The different BIOS images can be a bit confusing atm.
I've now Flashed back to sd_loader_with.bios, and can run things like Ferrari F355 fine from SD in IP.BIN mode (RC2.2 on SD card).

I also tried Flashing using ds_core_rd.bios and see it now boots without the GD drive plugged in at all - superb!
But, does this still run GDI games from SD or IDE?

I've been thinking about how to crack the HOLLY protection too...

Have you found out exactly how it blocks the G1 access yet?
ie. does it seem to block PIO or DMA control signals, or just disable the port altogether?
I'm guessing the BIOS must still be accessible after the G1 gets locked out, so maybe it's just disabling the G1 /CS1 + /CS0 signals?

Is there some way we could maybe brute-force the protection by emulating a BIOS using the FPGA board?
Then, modify a few bytes / words each time, reset the console, then check for G1 access again?

If we could do that in a loop (overnight), maybe we could map out which checksum values seem to work?

With the boot_loader_wsc_bfont.bios, would that allow the very best compatibility with DS if we can pass the HOLLY protection?

Have you made a BIOS yet which completely bypasses the GD syscalls at a low-level, so the RAM-resident loader is no longer required?


Also, I got the design done for the new (simpler) G1 IDE adapter, but it will be a week or so before I can afford to send off for a new batch.
The adapters do away with the need for jumpers and the oscillator module, so it should be a lot easier to use.

People will still need the IDE device set to Slave if the GDD is plugged in though.
The adapter no longer breaks out the CDDA signals either, but I can always get another version made if need be.

I think cybdyn is still working on his G1-Advanced design too, so my simple adapters will be a stop-gap solution until he has his running.


I know that's a lot of info, but I'm having fun playing with Dreamshell again.
If I get the SATA adapter working as well, I'll keep you updated, and might upload a YouTube vid too.

OzOnE.

[zolwikwkurwik]

How much will this cost with all components on board?
What are the differences between this and the simple G1-ATA connection? Will it run Shenmue?

[OzOnE]

Ahh, cybdyn!

That's a strange co-incidence. lol

Sorry, I've been busy again, and hadn't had chance to reply to your last email.

Did you manage to get some of those MCU chips yet?
I can order some if you still need them?

If you're close to getting the G1-IDE Adv boards running, then I might hold off with getting my simple adapter made.
Your design would be a much nicer solution, so I'd rather help you get it made.

Is the Adv adapter intended to be used mainly with Dreamshell, or is it a replacement for the DCIO too?

Yes, I kind of got frustrated with the whole GDEMU / DCIO project for a while, but I may be starting to have a bit of fun with it again.

It was also that there wasn't much I could help you with in the end, 'cos your coding is a different style to mine, and you were / are doing some much more advanced debugging than I can do.

I'd still rather see your projects get released though, as I think it will be a much neater solution in the end.

OzOnE.

---

btw, I may have a non-solder solution for leaving the GD drive in place while attaching an IDE device as Slave.

It's fairly obvious what it is (flex cable), but will take quite a bit of designing to get it working reliably.

The problem is, there isn't much space inside the case for even a 2.5" HDD anyway, and personally I'd rather do away with the GDD altogether.
So, it may not be worth trying to fit the IDE device inside the standard case tbh.

It looks like the G1-IDE Adv will allow the GDD to be removed, which would be the ideal way.

OzOnE.

[cybdyn]

it costs more cheaper compare to gdemu.
simple G1-ATA is a converter G1-bus to IDE. it's cheapest!))) but we still need use something for boot DS

g1-ata(ide)-adv acts like gd-emu, but storage is IDE device.
or at least it can load image w/ DS and then we work like w/ simple g1-ata w/ HDD under DS.
advantage is no need bios mod and option of gd-emulator.

[OzOnE]

Cool

I see now.

How is testing going with the DCIO - are you still looking to release it soon?

Personally, if the Adv adapter is simpler than the DCIO, but only works with IDE devices, I'd be fine with that.

CF / SD cards can start to get expensive when storing many Gigabytes of games on them.
A PATA / SATA HDD would be the best solution for everything IMO.

Not having the USB interface should make it simpler to debug I expect?

OzOnE.

[cybdyn]

can't say about DCIO release. it was/is good for develoment, but for mass production it's not perfect.

g1 adv: for debug i use rs232. but there is usb-otg in the mcu too, but usb1.1, maybe i can use this option.

i dont wanna give advice to stop your new g1-ide (simple)

after i test Adv, i can send you for tests. as i didnt test it in real))) but i think at least it can load DS, then just work as simple g1-ide)))

[SWAT]

OzOnE, about the BIOS firmware, you can read here - http://www.dc-swat.ru/page/dreamshell/firmware/

I do not know what the protection do in hardware, this is should be studied.
The Holly protection we really can bypass, just need to brute force for get the valid checksum. I think this is an 8-bit (at worst 16 bit) checksum/encryption, because in quite a few cases some BIOSes pass protection after modifying. Just need time and desire do it.

I will be very glad if someone do it. Since I'm currently doing something else, almost equally important

[OzOnE]

So, the ideal BIOS to pass the Holly protection would be...

boot_loader_wsc_bfont.bios ?

Would that allow booting the DS core from either SD or IDE too?

Ahh, I think I have a way of testing it...

If I use my DE1 FPGA board and program the Flash chip with boot_loader_wsc_bfont.bios, I could patch whichever part of the code I wanted on-the-fly.

Then, reboot the DC each time (/RESET signal), and have a simple app which tests the G1 access and writes the result back to SD card.

I'll have to solder the extra signals for the DC Flash though (many of them are in parallel with the G1 / IDE adapter of course), but it might not be too bad.

That could be another option for the new Flex cable adapter too - attach it to the extra pins to allow Flash BIOS mods.

I'm probably getting ahead of myself as usual, but I'll have a think about the Holly testing idea.

OzOnE.

---

Oh, also...

Could I ask which original BIOS version boot_loader_wsc_bfont.bios was based on? Was it a US one?

And could you say roughly which address ranges your code was injected into?

I think the bootloader ones are more important to get working, since most people will be using either SD or IDE.

Booting DS from IDE should be pretty fast now, and allows for it to be updated easier.


Thanks,
OzOnE.

[SWAT]

(09.06.2014 23:43)OzOnE писал(а):  So, the ideal BIOS to pass the Holly protection would be...

boot_loader_wsc_bfont.bios ?

Would that allow booting the DS core from either SD or IDE too?

Yes.

(09.06.2014 23:43)OzOnE писал(а):  Could I ask which original BIOS version boot_loader_wsc_bfont.bios was based on? Was it a US one?

And could you say roughly which address ranges your code was injected into?

Syscalls I get from memory of my console (PAL version).
Fonts from US version. But I think it's not important.
The first 16 KB of BIOS this is a Bootstrap with simple font. After there binary of boot loader. And at offset 0x100000 begin original fonts.
At startup Bootstrap, it's setup some regs and syscalls (only fonts work, other syscalls is dummy), then load and execute Boot loader. At Boot loader startup, it's setup original syscalls from internal romdisk (16 KB memory dump) and begin works...
So it's fully custom BIOS, not hacked original.

[OzOnE]

@SWAT - I know you mentioned this before, but it's given me an idea....

Just as a test, would you be able to write a version of boot_loader_wsc_bfont.bios which asks you to switch back to the stock BIOS chip temporarily?

In other words - it will say "switch back to stock BIOS", then do the 0xa05f74e4 reactivation check (reading from stock BIOS), then say "switch back to SWAT BIOS".

This would let us at least test the custom BIOS with G1 devices.

Do we know if the DC needs to be fully (Hard) reset each time the Holly checksum thing fails?

If not, do you think it would be enough just to keep reading random "chunks" of the BIOS to get it to unlock the G1 port?

So, instead of....

*((volatile unsigned long *)0xa05f74e4) = 0x1fffff;

for(p=0; p<0x200000/4; p++)
x = ((volatile unsigned long *)0xa0000000)[p];

Try a different "size" and start offset each time?

Even if the DC needs to be reset, maybe we can write a simple app to test all different values to see if it can unlock the G1?
As a quick test, it could just attempt to read the MBR on the HDD or something?

Do you know if the protection blocks only DMA access, or does it seem to disable the /CS0 /CS1 chip selects on that port altogether?

I noticed that the BIOS seem to write 0x000042fe to 0xa05f74e4 after it does the unscramble_data() thing too...
http://www.ludd.luth.se/~jlo/dc/security_stuff.c

I can't imagine this locks the G1 port completely after unscrambling a MIL-CD?
Maybe it's just locking it with an arbitrary number so it can be unlocked again later on?

Hmmm, I REALLY want to crack this now.
I wonder if anyone has decapped the HOLLY chip yet?

You did it OK with your sd_loader BIOS, so I'm sure we can do it again.

OzOnE.

[OzOnE]

OK, I've just done a few tests, and found that it does indeed lock out both PIO and DMA transfers...

I modified my old gd.c code so I can press the A button to do the gdrom_activate() thing manually.

I'm only accessing the HDD atm, and I can "fake" an incorrect BIOS checksum simply by flicking the BIOS select switch on my DC during the activate routine.

If I then read back via PIO, all I get is random junk data.
If I try reading via DMA, the DC will freeze completely.

I've just added a timeout to this too...

static inline int gd_wait_status(uint32 mask, uint32 val) {
int count = 200;
while( (*GD_ALTSTAT & mask) != val); // Wait until the status register has the appropriate value.
{
if(count == 0) return -1;
usleep(1000);
count--;
}
return 0;
}


I thought that would stop the DMA from freezing, but it still seems to do it? (I'm preventing it from setting SB_GDST if anything returns -1).
Not a problem though, I can see from using PIO when the checksum fails.

I've also learned a few things...

1. You CAN just re-activate the G1 port without needing to reset the DC.
2. When the HOLLY / BIOS check fails, it does block access to any non-ROM G1 devices (still not sure if it blocks the /CS signals, but doesn't matter).
3. The lockout definitely blocks it from even reading back the IDE status byte.
4. If the check fails, you can re-activate with a correct BIOS, and the port starts working again.

OK... Just added a quick routine to print the contents of a Word from the HDD - if the check fails, then it says "Activation FAILED!".

Now I can play with getting it to activate from a very small chunk of the BIOS instead.
Or, I can try incrementing through data in the BIOS until it passes the check.

If we can get that working, we can simply add that chunk of data to the custom BIOS.

OzOnE.