Connecting IDE disks & ISA (network) card to Dreamcast

[abs]

I noticed a post on the Hardware section of this forum.

Unfortunately I do not speak Russian, though google translate helps me understand it sometimes, so I thought it would be best to post a comment here and add a link on the other forum for anyone interested.

The original posting discussed the DCEXT board which allows connecting an IDE drive and an ISA card (ie network card) to the Dreamcast, complete with code to run under NetBSD.

Obviously if the hardware can be driven by NetBSD then code can be written to drive it under other Operating Systems, but since I'm mainly a NetBSD-head and the code there is already written and works I'll cover that in this post

The patch to add support for the DCEXT board to NetBSD 5 is at: http://www.ceres.dti.ne.jp/tsutsui/netbs...t-5.0.diff

I've just updated it to apply against the HEAD of the NetBSD tree (-current) and the updated version is at: http://sync.absd.org/dreamcast/dcext-cur...07-29.diff

To build a version of NetBSD with this patch on a POSIX host (NetBSD, Linux, etc)

• Download NetBSD source. Easiest would be tarfiles which include anoncvs setup
• Apply the patch "patch < dcext-current-2012-07-29.diff"
• Build tools. Run "./build.sh -m dreamcast tools". This builds a complete cross compiler & any other tools needed to build NetBSD. The first 20 lines of output will list targets dirs
• Build kernel. Run "./build.sh -m dreamcast kernel=DCEXT". This will leave a netbsd.bin in .../sys/arch/dreamcast/compile/DCEXT/netbsd.bin
  

I don't have a DCEXT board (would love one tho , but I've built a sample kernel which anyone should be able to boot at: http://sync.absd.org/dreamcast/netbsd-DCEXT.bin.gz and a full iso image with root on gdrom at http://sync.absd.org/dreamcast/netbsd-dr...EXT.iso.7z

Currently the code will unconditionally try to attach the dcext, so it at least makes it very obvious the driver is present

Booting without the hardware should give you output similar to (image from gxemul):


If anyone has made a board and would be willing to test boot the above image, please let me know how it goes!

Thanks

[shadow]

Well done! Thank you for your efforts!

[cybdyn]

ABS: if it's not too hard to do, can you add some strings to code for read ATA registers and print them out to screen.
as for me for - it's very useful in our stage of developing.

[abs]

(30.07.2012 00:31)cybdyn писал(а):  ABS: if it's not too hard to do, can you add some strings to code for read ATA registers and print them out to screen.
as for me for - it's very useful in our stage of developing.

Sorry - I missed your reply until now (I was expecting a subscription email notification on the thread and it didn't come through)

I've rebuilt the DCEXT kernel with ATADEBUG and ATADEBUG_MASK=0x78 which should give relatively insane levels of debug output. I suspect it will be more useful with a serial console

I assume you only really need the Kernel, but I've put an iso image with root filesystem up just in case.

• http://sync.absd.org/dreamcast/netbsd-DC...BUG.bin.7z
• http://sync.absd.org/dreamcast/netbsd-dr...BUG.iso.7z
  

How is it going - do you have a NetBSD boot message with it probing the board?

[cybdyn]

i haven't got this adaptor g2->ide, it can be tested by MYX))

[OzOnE]

Hi, all,

This is my first post here. I think I firstly need to say a huge THANKS to SWAT for his work on Dreamshell.

I'm only just starting to appreciate how difficult and time consuming it is to debug this stuff. Also well done on getting ISOs to boot!

OK, where do I start? I'm not sure if anyone has seen the efforts of us guys over at assembergames?...

http://www.assemblergames.com/forums/sho...roup/page8

We're still trying to find a solution for replacing the GDD with CF or HDD...

Originally, I was trying to get an FPGA to replace the GDD natively. This would allow GDI images to boot and the DC wouldn't be able to tell the difference.
I got quite far with that, but could never get it to boot past the SEGA license screen?

So, with @cybdyn's suggestion, I started looking into the actual GD syscalls...

(@cybdyn has done some great work with getting the Playstation based consoles to boot from his FPGA board. In time, we're hoping we can emulate the DC GDD and others too.)

First, I added a Flash BIOS upgrade to my DC and I'm now running DS "Bootloader with BIOS" so I can quickly test my code via SD Card under DS.
This was a big step for me, and DS makes it MUCH easier to debug code. (Thanks again, SWAT!).

Anyway, to cut a long story short, I currently have a CF card connected DIRECTLY to the G1 port.
The IDE-to-CF adapter is set as Slave, so I can now leave the GDD plugged in at the same time.

I'm currently able to DMA data from the CF card into DC RAM, and I can even DMA raw binary files from CF into memory and run those too.
This also works with a full-sized (or laptop) hard drive.

(The DC PSU could probably handle a small capacity 3.5", but I wouldn't want to push it too far).

I haven't got DMA to work from the GDD yet, but I can still read from a GD via PIO mode (and switch between GD PIO and ATA DMA).

So, @SWAT - would it be possible for you to add support for this in DS at some point?

I can send you the code as it is, although there are a few issues to sort out still (eg. it gets stuck if you try to poll for the end-of-DMA, so I need to add a delay instead).

The netBSD code is interesting too. If most of the routines are in place for PIO, I might try to add the G1 DMA routines to it.

@abs - I could send you some code too? The routines for DMA are probably much simpler than for the G2 bus.

Oh, I've also tried adding GD syscall redirect stuff to the code. I have spoofed a GD TOC and it appears to read the same as a real GD TOC.
I've tried loading a 1ST_READ.BIN from CF, then starting the IP.BIN Bootstrap1, but the DC will either show the license screen then reboot, or just a black screen?

@SWAT - you no doubt know more about the syscall stuff. I'm excited to talk to you about the code etc.

Regards,
OzOnE.
EDIT: Forgot to mention - I had to solder the IDE cable directly to the test pads on my DC for now. I did start doing a basic PCB layout for some G1-to-IDE adapters, but I've been busy with the code instead of finishing the PCB.

[cybdyn]

Ozone - welcome on the DC-SWAT. after my success with ps1, i decide start developing on new pcb , and add DC support to scheme. cause it has simple ATA-style IF.
now i've almost done with scm, and soon i plan start to routing it tj get PCB file for making board. but "soon" is very relative mention, so you can make what-you-want first, good luck!

[SWAT]

Hi OzOnE! Plz attach your source to the next message and i try implement it.
For more info i recommended to view source code of the lxdream, example - http://www.lxdream.org/hg/lxdream/file/8...test/ide.c

[abs]

I've been chatting to the original author of the NetBSD/dreamcast patches for the DCEXT and he has been generous enough to search for and share his memo on the hardware changes he made to the DCEXT to get it working:

- it's better to have external 5V power source
(rather than using Vcc from DC)
- Vcc and ground lines might be weak and needs more capacitors
- DC connector P9 should be NC and P12 should be GND
- IDE P1 (reset) needs some power on reset signal
- CPLD P50 (interrupt) should be connected to DC P13, not P8
- ISA IRQ lines should have pulldown
- It's better to ISA IRQ 5,9,10,11 rather than 3,4,6 etc
- ISA A14 and A15 in the patern might be swapped? (not sure)

---

(12.08.2012 23:28)OzOnE писал(а):  The netBSD code is interesting too. If most of the routines are in place for PIO, I might try to add the G1 DMA routines to it.

@abs - I could send you some code too? The routines for DMA are probably much simpler than for the G2 bus.

I'm happy to look at any code, though I never managed to get or make a DCEXT board... :/

[OzOnE]

OK, I think for this project to get any further, I have attached the current CF / HDD code...

http://www.filedropper.com/gddebug22-8-12ozone

EDIT: I just realized that I'm hijacking this thread. Please let me know if this should be moved, or if a new thread should be created.

@abs - no DCEXT adapter is needed! You just need to solder an IDE cable to your DC's G1 port. (details below).
The GDD needs to be left plugged in to get the DC to boot, then the CF / HDD needs to be set to Slave mode.

Usual disclaimer - the above code is not booting any images yet!
I can boot to the first part of Crazy Taxi (PAL GDI) bootloader, but it gives an AICA_DRV -1 error.

I'm guessing this is because it can't find the AICA_DRV file in the image, but it could be something else? SWAT says this error showed up quite a bit?

It could be that I'm trying to boot native GDI's and there is some extra protection in the stock BIOS, or stuff that needs initializing first?

You can try loading a CDI with this, but we need to confirm that my TOCs are correct (I don't think the CDI one in my code is correct atm).

A big problem for me is not having any debug output from the DC once the game image is started.
I can't seem to get serial output working after booting from SD, and I don't really want to boot from CD-R every time.

The DMA routines are fairly straightforward (info taken from the DC System Guide), but I still can't get it to poll for the end of a DMA without freezing?
So, I've had to add some big delays in the DMA routines to ensure the current DMA has completed.

I haven't tried using interrupts in case the stock BIOS has attached routines to ints already. (the idea being to boot a GDI leaving most of the stock stuff intact).

I attempted to add some stuff for grabbing the start FAD of the binary (1ST_READ.BIN etc.) from the GDI image.
This is unfinished though, so you need to specify the start FAD of your binary in the code (there are a few examples in there).

The image itself is simply copied directly onto my CF card using your favourite hex editor (WinHex etc.) - no filesystem!!

To calc the start LBA on the CF / HDD, I'm simply multiplying the GD FAD by 4 (due to the difference in GD / ATA sector sizes).
So, if "track03.iso" normally starts at FAD 45150, it needs to be copied onto CF / HDD starting at LBA 180600.

I compiled the gd debug code under DC Dev ISO R4 / Cygwin.
To try loading IP.BIN and a binary, you'll need to compile GD debug to load into high memory...

To do this under Cygwin / KOS, I just modified the environ_dreamcast.sh script (before compiling) like this...

export KOS_LDFLAGS="${KOS_LDFLAGS} -ml -m4-single-only -Wl,-Ttext=0x8cd00000"

The resulting binary will of course need to be loaded and run from the correct offset on the DC (using dc-load or the DS console etc).

In my case, I just added an app xml to create a new icon on the DS desktop.
See this post...

http://dcemulation.org/phpBB/viewtopic.p...3#p1032933

For the CF / HDD connection, I just cut one end off a 40-pin IDE cable, stripped and tinned every wire, then soldered them to the DC G1 port test pads.
If you fancy a bit of soldering, here is a diagram....



If you give this a try it is AT YOUR OWN RISK! blah blah blah.

btw, I've set the GD debug app to load 16 sectors (32KB) at a time simply so it will load all of IP.BIN into DC RAM.
Then, (after you've modified the code for the correct start FAD) press start, and it will load 1ST_READ.BIN at 0x8c010000 (directly after IP.BIN).

I can't really explain more than that or this post would be even bigger. (it will make more sense once you read through the code).

I'm no expert programmer, so there will be many silly mistakes and very rough code.

It would be great to get some extra brains on this.
I can't wait to start booting GDI's from HDD.

OzOnE.

[SWAT]

Thanks! I try to implement it in DS.

[ValeraK]

(23.08.2012 08:43)SWAT писал(а):  Thanks! I try to implement it in DS.

Swat is a wiring diagram for standard G1 IDE devices can be connected via a CD-Rom or hard drive are the Problem only with software support...

[SWAT]

I want to write software to run not only images, but also to support the IDE in the DS with a normal file system, as well as the launch of the images from file system. As well as SD.

[OzOnE]

Excellent, this is great news, SWAT!

You can see the DMA routines are simple enough. If you can get polling to work for end-of-DMA, then it should be straightforward to replace your low-level SD card routines with the IDE ones.

Or, if you can get G1 DMA interrupts working (to show end-of-DMA) without interfering with the stock BIOS stuff, the DMA stuff should work fine.

Oh, btw, I did have it working so I could switch between IDE / ATA (DMA) and back to GDD (PIO), but I don't think it's working in the current code. I'll take a look at it.

Also, it still froze the DC when WRITING back to the CF card. It would be great to fix this because we could do fast GD ripping.

Ideally, we eventually want to use a HDD for storing all the images and this should be a straight swap from CF. Hell, in theory even a Blu-Ray ROM drive or writer could be connected.

The good thing is, the IDE cable can be soldered fairly easily. Just remember to always strip / twist / tin your wires, but then trim the tinned ends down to ~2mm.
Also a good idea is to add very small blobs of new solder to the test pads before soldering the wires.

I'm stuck with the PCB layout for the G1-to-IDE adapter. If anyone can help, I've started on a basic layout here...

http://www.assemblergames.com/forums/sho...post599131

The idea is to make a cheap adapter for everyone so it will be plug-and-play. It should also allow the GDD to be plugged directly into the PC (with a custom driver).
The IDE adapter shouldn't even need a Flash BIOS mod, just a small loader on a CD-R (like DS).

I must admit, @cybdyn was right in suggesting a direct connection. I just thought it would be way too difficult (for me) to set up the DC dev environment and start messing with KOS.

btw, if anyone is thinking about portables - please note that it doesn't look like removing the GDD is possible without a custom BIOS. The stock BIOS still checks for the GDD and freezes if it doesn't find it (even if the CDDA clock is input to the DC).

Thanks again, SWAT. We look forward to any new updates.
Please let me know if you need any help or for me to explain some of my crappy code.

OzOnE.

[OzOnE]

Oh, here's some extra info on connecting the IDE cable...

I just chose whichever Ground pad was closest, but you can basically choose whichever Ground is easiest.

But, the P.GND pins are meant to be used for Power Ground. So, naturally these should be connected to your CF / HDD power GROUND return.

The DC PSU could probably handle 1Amp or so on the 12V line for spinning up a 3.5" drive. Any more than this then it might explode.

A standard laptop 2.5" drive only requires 5V and around 600mA, so should work fine.

A CF card generally only needs a couple of hundred milliamps at most, so is fine. My CF card is 5V, and seems to be working OK.

btw, it's not confirmed whether the HOLLY is fully 5V tolerant, but the G1 port has some series resistors to help with this.
AFAIK, the VA0 boards had a 5V BIOS, so it's probably OK. Again, this is all at your own risk.

EDIT: I just checked the VA0 schematics and realized that the VA0 5V BIOS is connected directly to the HOLLY.
It looks like the resistors on the G1 port were just for limiting the current to the GDD (it uses 3.3V logic).

In other words, it should be fine to use a 5V CF / HDD and the resistors offer some extra protection.

Код:

IDE/ATA...          DC G1 port...
1. /RESET           A2
2. GND              A8
3. DD7              A4
4. DD8              A5
5. DD6              B4
6. DD9              B5
7. DD5              A6
8. DD10             A7
9. DD4              B6
10. DD11            B7
11. DD3             A9
12. DD12            A10
13. DD2             B9
14. DD13            B10
15. DD1             A11
16. DD14            A12
17. DD0             B11
18. DD15            B12
19. GND             B8
20. Key             (NC)
21. DMARQ           A14
22. GND             A13
23. /WR             B14
24. GND             B13
25. /RD             A15
26. GND             A18
27. IORDY           B15
28. CSEL            (NC)
29. /DMACK          A16
30. GND             B18
31. INTRQ           B16
32. /IOCS16         (NC)
33. DA1             B17
34. /PDIAG          (NC)
35. DA0             A19
36. DA2             B19
37. /CS0            A20
38. /CS1            B20
39. /DASP           (/ACTIVE LED)
40. GND             A21/B21


DC G1 port POWER...

A1/B1 = 3V3
A3/B3 = 5V
A25/B25 = 12V

A24,B24 = P.GND (Power Ground)

A8,B8,A13,B13,A18,B18,A21,B21 = GND


DC G1 port CDDA pins...

A17 = CD_EMPH (Emphasis)
A22 = CD_BCK (Bit Clock)
A23 = CD_SD (Serial Data)

B22 = CD_LRCK (Left / Right Clock)
B23 = CDDA_CLK (33.8688MHz master clock INTO AICA!)

OzOnE.

[OzOnE]

Thanks, SI{AY!

Does anyone know how to get serial debug output working under KOS?

There seem to be a few different ways of doing it (dbgio / conio / scif write etc.)
I've tried the standard dbgio and conio methods, but neither of them work? (no data output)

I'm booting to DS with the SD card adapter attached. My USB-to-serial adapter is connected in parallel with the SD card (DC TX pin to USB serial RX pin).
I know the USB adapter is working because I can see the junk on the PC side while the SD card is booting.

I've tried removing the SD card once my app is running, but there is still no serial output from the DC after that point?
It's definitely not working while my app is running as I've tested it with my o'scope.

I can't see any other way of debugging this IDE adapter without proper debug output. Please help!

OzOnE.

---

@SWAT - My best guess about the End-of-DMA problem is that KOS is blocking register reads or something?

It looks like KOS wants you to attach a handler if you want to use the End-of-DMA interrupt.

This is what the Maple shutdown code does...

/* Hook the neccessary interrupts */
maple_state.vbl_handle = vblank_handler_add(maple_vbl_irq_hnd);
asic_evt_set_handler(ASIC_EVT_MAPLE_DMA, maple_dma_irq_hnd); asic_evt_enable(ASIC_EVT_MAPLE_DMA, ASIC_IRQ_DEFAULT);

Supposedly, you would need to use the "ASIC_EVT_GD_DMA" event code instead and add a simple handler?...

http://gamedev.allusion.net/docs/kos-cur..._evts.html

The problem is, would the interrupt handler interfere with the stock BIOS stuff once the image / binary is booted?
It would be nice to stop using KOS completely and do every at low-level. Is this what you do with your SD bootloader?

It's a bit strange that I can't just test for "SB_GDST == 0" for DMA completion?

OzOnE.

[OzOnE]

OK, I've realized that the Dreamcast coders cable normally drives the CTS pin too.
I've tried grounding this pin after the debug app is loaded, but still no joy (tried many different methods in the code).

I used to have a coders cable about ten years ago, but I leant it to somebody and I never got it back.

Oh well, I'll keep trying. It looks like it might need to go back to booting from CD-R after all.

OzOnE.

[cybdyn]

i think - before use serial for dbg - first you need initialize it , set features like mode, baud and etc. maybe some example exist in the internet.
also you need some SW to handle recieved data from COMx (my usb->serial sit on COM3) most easy way is terminal.

also i start learn more about SD card IF and start write AHDL code for my *board* on my offical work. dont know when but i plan connect with DC too. maybe after that i can share any real files or information.

*- http://s48.radikal.ru/i119/1208/c7/b8fe271837ad.jpg

[cybdyn]

also i heard in DCDBSysArc990907E.doc about some magic register or code for properly performing DMA by g1.

[OzOnE]

I've tried initializing the serial port in many different ways, but it doesn't seem to work after loading my app from DS?
Maybe it's the way the SCIF is initialized for the SD Card, or something KOS is doing?

That's a very nice looking board, cybdyn. Much neater than my efforts.

AFAIK, the "secret code" for DMA transfer is basically this...

*SB_GDAPRO = 0x8843407F; // Set DMA transfer range to the system memory area.

The upper 16-bits is the magic code 0x8843 (which stays the same apparently?).
The other bits set up the memory protection range for the DMA (the HOLLY will generate an error interrupt if the DMA falls outside this range).

The DMA transfer itself appears to be working fine though, it's just that I can't poll for the end-of-DMA without it freezing?
I'm 82% sure this is a protection or mutex problem with KOS.

I'm now trying to strip down the app to the bare essentials without KOS (simple CF bootloader and GD redirection).
The app is quite bloated with unused KOS stuff (SPU,PVR,BBA etc.)

I will keep trying to get serial to work. I'll probably need to stop using the SD card and DS though.

@cybdyn - Good luck with your board. I hope I can help out with the DC stuff.

I've abandoned the FPGA for a while. Even though this syscall stuff isn't quite working yet, it's still easier to program in C than trying to debug the Verilog code.

@SWAT - Are you planning on soldering an IDE cable to your DC, or will you be working on the software for now?
Also, may I ask if you wrote your bootloader using any libraries or KOS? (I'm guessing the routines are all internal?).

OzOnE.