Sega Dreamcast HDMI Adapter coming soon ..

Amazing technical stuff in this thread, but this explanation on how the homebrew/pirate patch works was amazing, I don't think I ever read any explanation about it before, thank you.

 

correct me if i am wrong but if this happens then the other data on the drive will be unaccessible so loading the binary then locking the drive will resault in no access to program/game resources and libs

 

@madsheep you are right, I missed this, actually never looked what genuine Mil-CDs is, and its more like additional video-player as I see, so its indeed will require subsequent disc access.
well, in such case I'm afraid Sega had no choice...

btw, this question was nice reason to put my eye and debugger onto "how real Mil-CDs unlock G1 ATA" ?
unsurprisingly it works different to pirated/homebrew software.
as we remember DC BIOS write into 5f74e4h register ('last checksummed address') 42FEh value before jump into Mil-CD binary.

later in it's code executed such routine:

Code:

8C1DF142  D10C  MOV.L     #h'A0001000, R1
8C1DF144  D20C  MOV.L     #h'8C001000, R2
8C1DF146  D30D  MOV.L     #h'00000C00, R3
8C1DF148  6016  MOV.L     @R1+, R0
8C1DF14A  2202  MOV.L     R0, @R2
8C1DF14C  4310  DT        R3
8C1DF14E  8FFB  BF/S      h'8C1DF148
8C1DF150  7204  ADD       #h'04, R2
8C1DF152  D00B  MOV.L     #h'000000C0, R0
8C1DF154  6316  MOV.L     @R1+, R3
8C1DF156  4010  DT        R0
8C1DF158  8BFC  BF        h'8C1DF154

looks useless, because it copy 'SysCalls' area from ROM (1000h - 3fffh) into RAM, which is already there, then do dummy read of 300h more bytes.
this code is hidden/obfuscated "original Sega's" G1 unlock routine.
which is basically reads data from BIOS 1000h to 42ffh (1 byte more than needed to reach 42FEh address) , this chunk of data have 'correct magic checksum' so G1 ATA will be unlocked after this.

 

Interesting indeed! I just bought a real milcd to have a look at this. I am a bit surprised though because I remember trying to unlock the drive with data stored in ROM located at an address > 0xa0000000 and it did not work. But as soon as I put the same data at 0xa0000000 then it worked. Maybe I did something wrong. I will try again later. Thank for the info

(I think we should talk about this in another thread though ^^)

Update: it works with address>0xa0000000 - I was just not doing the unlock correctly (was putting in a05f74e4 (data_size -1) instead of (data_start_offset + datat_size - 1). Anyway, got my MILCD today, time to have a look at this weird CD format..

 

First I saw that this project was still alive and I got excited. Then I saw all the pictures including the QSB mockup and got super hyped. Then when I saw the work being done on the new DC motherboard, I had to make an account just to say: OzOnE and co, you guys are heroes. Can't wait for the HDMI boards to be ready! I'll be keeping an eye on this thread for pre-orders

 

Thanks, Crystal Shyps.

The main board and flex cables are basically done, but a batch of 21 flex cables that were supposed to be sent to me got held up by customs in Canadialand unfortunately (no idea why).

I'm just waiting for those to get re-delivered, and I can do the last bits of testing.

I have made some good progress on the On-Screen Display system and the DC controller handling though.

I got a tiny bit carried away, and the OSD block now supports proper "Genesis style" graphics blocks with 64 on-screen colours, but each palette entry is true 24-bit with a proper alpha channel for transparency.

Since we are looking to eventually add "WiFi" support for dial-up DC games (via the current servers being run for a handful of games), I thought I might as well use an ESP8266 WiFi module to control the OSD and FPGA anyway.

Here's a short demo vid of the OSD and controller working.

It can also do smooth scrolling in both the horizontal and vertical directions for the whole OSD window, but no tiles outside of the window (yet).

https://drive.google.com/file/d/0B1grqFdAErsrZnhxcW5MTnkxS0U/view?usp=sharing


So, the boards are nearly ready to go, and StoneAgeGamer has offered to front the cost of the first batch of boards, so they will likely be the sole seller of the boards in the US for a while too. We do of course have a few sellers in mind for the UK / Europe at the same time too.


Things like the "WiFi" support may happen a lot later on, as there's a fair bit of work to do on that yet.

It will basically require another custom flex cable (should be fairly cheap) which plugs into the spare header(s) on the HDMI / FPGA board, and then a small connector will come from the original DC modem (modded to have it's modem chip removed). The FPGA will then "emulate" the modem chip registers, and then pass the data to / from the ESP WiFi module directly.

I know it's been a very long road, but we'll hopefully have more news soon.

Regards,
OzOnE.

 

@OzOnE, I think you're my geek soulmate.

 

Just a tiny bit? You seem to have a lot of spare RAM to spend on such features.

Neat, now the OSD in my own project looks a bit lame

*sigh* Yet another thing that I really should learn more about - the Wii doesn't offer as convenient access to the digital AV as the Gamecube.

 

Excellent !

 

@Unseen - thanks.

(and FamilyGuy / zouzzz etc. )

Well, I was going to use the ZPU core and a similar OSD method, but then I thought I'd have some fun with it. hehe

It's only using 16KB of Block RAM for the OSD window.
It uses the same "nibble per pixel" as the Genesis tiles, and the tiles are drawn "in-place" atm, so only confined to the OSD window.

16KB is enough RAM to do 128 pixels wide, and 128 lines tall (32 tiles wide by 16 tiles tall, as there are 4 bytes per tile "row", but 8 rows for each tile).

We're using the Cyclone III EP3C10 atm, which only has around 50KB of on-chip RAM, so I could easily double that resolution without needing to zoom the image or use proper tile tables, but I didn't want to go too overboard at this point, as we'll probably need the extra RAM blocks for the WiFi / DC modem stuff I'm working on.

(the extra RAM is also good for SignalTap obviously. I can debug the code with HDMI on the Cyclone V GX dev board, but it's a pain if you can't use SigTap in-place with it hooked up to a Dreamcast.)

I'll probably end up adding the proper background / sprite table stuff soon, since that won't use up too much more on-chip RAM.

I didn't want to use an external framebuffer RAM on the HDMI board, as it was all about getting the lowest latency possible, and keeping the board size / cost down etc.

If I do add the background and sprite stuff, people could then write / port Genesis style games in C on the ESP module that would run on the HDMI itself.

Also, the tile-based stuff is obviously a great way to save on extra RAM blocks, since you'd only need two or three bytes to represent where the tiles and sprites should be on the screen, and that would also allow for tons more tiles in 720p or whatever.


I know what you mean about the flex cable stuff though - it wasn't me who designed that, it was the talented Mr [RDC].

I tried to do my own design on Cadsoft Eagle, but while the chip part was easy enough, doing the actual flex cable layout was a huge pain. lol

I've since installed Altium Designer (well, I had it installed for many months), but I finally took the plunge and forced myself to try to pick it up. I'm glad I did, as I'm already managing to place components and route stuff just fine, and it's WAY more helpful than Eagle's crappy routing tools.

Also, the latest version of Altium finally has some proper import tools for Eagle etc., so I can work on stuff under Eagle while I'm still learning Altium, then import the designs into Altium. (I still haven't started using the Library editor on Altium yet, but it's supposed to be very good too.)


That's why both Mr [RDC] and I decided to try routing an entirely new motherboard for the Dreamcast as well.
It just so happened when I mentioned my work on the GPU pinout (and reversing of some of the glue logic and all of the connector pinouts on the NAOMI) that he'd also done some work on the DC stuff previously. hehe

In only about a week or so, he'd already bought the three main revisions of Dreamcast mobo (VA0, VA1, and VA2.1), stripped them down, photographed them in hi-res, confirmed every single component, pinouts and differences against the other versions, then made all new re-drawn PDF schematics for each version (based on the old VA0 schematics that l_oliveira posted around 2010).

So yeah - I couldn't do half of this stuff recently without the help of [RDC]. He's scarily efficient and multi-talented. hehe

OzOnE.

 

Anywho, I will try to keep this thread updated more often.

Sorry it's been a while, but I was hoping that the flex cables would arrive recently, so I could do some in-place testing with the OSD etc.


While I'm waiting for the cables to get re-sent, I've been messing with the Genesis core on the DE1 FPGA board (written by the equally amazing Mr Grégory Estrade).

I'm seeing if I can translate things like the YM (FM) chip core to Verilog so I can make sense of it easier, then reduce the precision down to 9 bits instead of the 12 or 14 bits it's using atm.

It's definitely overkill to use that many bits tbh (the YM chip core was written by somebody else, and they left comments in the code about it using a lot of bits).

So, you can only enable ONE FM channel out of the six atm, otherwise it will just take up all of the logic on the DE1's FPGA (EP2C20, with 20,000 Logic Elements).

If I can shrink down the logic quite a bit, I want to build some mini Genesis consoles based around a cheap-ish (£40) FPGA board, so that people can enjoy a "clone" system which actually has decent sound for once. lol)

I could load the ROMs into SDRAM via an ESP module too, and / or add a proper cart socket.
Hopefully it could then compete with those crappy AtGames clones (which won't be too difficult tbh. lol)

The Sega Radica wasn't so bad though - at least the audio sounded quite good after you fix their screw-up with the resistor placement etc.

Failing that, I've just ordered 10 of the YM2612 chip from AliExpress.

I've had one of the original chips (from my Mega Drive) hooked up to the DE1 board before, and it worked perfectly.
The ones from AliExpress might turn out to be fakes, but I don't really care as long as they sound OK.

The Genesis core only needs around 12,000 Logic Elements if you don't include any of the YM chip core, so it should be possible to use a slightly cheaper board for that too.


Anyway, yeah. This is why it takes me so long to get any projects finished. lol


Definitely still working on the HDMI stuff as a priority, but my hands are tied atm with waiting for those flex cables.

I could just hook up the HDMI board to the DC again, I guess, but I want to test it as a whole "kit" of course, as I'm sure there will be other issues that need sorting out (like how to hook up the ESP module etc.)

The only obvious place for the ESP WiFi module is between the GD drive and the joypad board inside the DC, so that the cable routing is easy, and the WiFi antenna gets a fairly unblocked "view".

There's also the separate microUSB UART thingy that will need to be placed next to the HDMI board at the back of the DC (and another very small hole / notch cut out for the socket.

That will be for programming the ESP module, and for people working on writing mini games for it etc.

The C code side of things will be open-source, and it's really easy to program it using the Arduino IDE with the ESP8266 support plugins installed.

OK, enough of my rambling.

I know a lot of this is hard to visualize atm, but we don't really want to reveal pics of the real custom flex cable just yet, and it will make a lot more sense soon.

(actual "dial-up via WiFi" support may take months to figure out yet, but it will mean not having to use the Raspberry Pi + USB modem, nor other stuff to play the online games. It will all just work via the WiFi module in the DC itself.)


Oh, and there's the slight possibility still of being able to add support for online multi-player "Netplay" by compressing the Dreamcast (or any other console)'s video output to MJPEG, then sending it via the Interwebz.


Plus, I'll probably be adding audio support to the OSD thingy, so people can send sound effects etc. via the HDMI output.


Only problem now is...
"Do you think you can do all that bullshit you just said?" (Will Smith - ID4). lol

OzOnE.

 

Oh, and the other reasons I wrote my own OSD core in the end were because...

1. It was fun.
2. It looks pretty neat now.
3. Finding the proper working equation for the alpha blending was "interesting". lol
4. The ESP8266 modules are dirt cheap, fast, very easy to program, only need a few wires to hook up to the FPGA via SPI, and of course allow future WiFi support.

5. Most of all though - many of the available open-source "soft" processor cores for the FPGA have to have their code compiled under a Linux environment. I know a bit of Linux stuff, and I have Ubuntu on a VM etc., but I tried and failed to get anything to compile easily. It's ALWAYS a royal PITA. lol

I couldn't even get the ZPU core stuff to compile under Ubuntu, as the tools apparently don't support 64-bit Ubuntu. sigh.

Seriously, Linux stuff will never be fully accepted until they make stuff like this more pain-free.
Even compiling for the OR1200 RISC core can be annoying, and it's tripped me up so many times.

Rant over. hehe

OzOnE

 

Just out of curiosity, would there be much difference between doing the "dial-up over WiFi" vs something similar for the broadband adapter? I assume there's not as much motivation for the latter, both because the broadband adapters are harder to come by and since, well, it's easy enough to just wire up an Ethernet cable. Or would the WiFi actually bypass all the bottlenecks of the dial-up modem making the broadband adapter irrelevant?

 

Hmmm, 480p is 720x480 pixels...

With 8x8 pixel tiles, that means 480p could fit 90 tiles across by 60 tiles down.

If we assign just one byte per tile (in the attribute or background table), that would need 5,400 Bytes to fill the whole screen.

The Genesis VDP uses two bytes to define each tile in the Pattern Name Tables though, and that lets it access 2KB of pattern data for each layer (1024 tiles to make up each pattern. I think?)

So, that would mean 10,800 Bytes to store enough of a pattern to fill a whole 480p screen with tiles (at the full resolution).

That could be zoomed 2x though, and give the "retro" look, and then only need 2.7 KB to hold pattern data for the whole screen.

So yeah, it's still doable to store a few nice Genesis style level maps and backgrounds in only a few KB, but that would be limited by the number of tile patterns stored in the other 16KB chunk of RAM etc.

Will be fun to mess with though.

Even the 32x16 tile OSD window looks pretty good when scaled 2x to fit most of the screen.
I just thought it would be cool to see a high-res version of some Sonic 2 levels perhaps.

720p would be possible, but it would use most of the on-chip RAM right away.


OzOnE.

 

@Crystal Shyps - Yep, in theory, the WiFi mod should be WAY faster than the original 33.6K / 56K modem chip, as we obviously won't be limited by the dial-up speed etc.

I don't know yet if any games will have problems with the data arriving at a much faster rate, but the DC should really just be grabbing the Bytes as soon as they arrive (via WiFi).

It would of course be possible to limit the bandwidth via an OSD menu option though, in case some games do have problems.

So, hopefully we won't need to go down the route of implementing the BBA.
Plus, more games support dial-up anyway, so it's a logical choice.

I've already implemented the actual registers in some test code for the DC modem, and I even hooked up the FPGA dev board to a DC modem the other week.

But, I was simply unable to get the damned thing to actually connect.

I was trying to connect to the recommended USB modem that was hooked up to a Rasp Pi 2, and running DreamPi.

I could log in to the Pi directly, and eventually was able to get the online Web page thingy to find the Pi and configure the username etc., but I still couldn't ever get the DC modem to want to dial out.

I had "line voltage inducer" (posh name for two 9V batteries, one resistor, and one cap. lol) hooked up to the modem, since the UK modems require a higher voltage.

I then even tried using a 19 Volt laptop PSU as the inducer, but the modem still refused to dial out.

And then I found that the USB modem on the Pi apparently wasn't sending out the dial tone at all (although both lights were lit after the Pi booted up)?

I don't know how you get the DC modem to do a "blind dial" using the DreamKey (or the US DreamWeb disk, or whatever it's called), but it never tried to dial out at any point.

So then I gave up trying, as I wanted to get back to working on the HDMI stuff. sigh

ALL I need is for the stupid DC modem to be able to dial out and connect to the Pi, and then I can start capturing how the games normally access the modem chip registers (and which ones might not be needed at all). Most of the captures and analysis can be done via SignalTap / JTAG once the modem is connecting.


I think the next step is to simply make the acccess for a few of the registers get re-directed to the FPGA (since I can control the /Chip Select to the original DC modem chip separately), then force it to detect a "dial tone" flag at all times.

Once I know which registers are being used during the dialing process, I can then start implementing those regs on the FPGA itself.

Then, we won't need the evil modem chip any more. Muhuwhahahaaaaa!


So yeah, probably not necessary to try to implement the BBA tbh, and that would mean also implementing the G2 bus side of things, which can get even trickier.

I believe that "jj1odm" had trouble getting his BBA clone to work all those years ago, so I didn't fancy that route at all atm...

http://jj1odm.sizious.com/g2bus.html


What the mod will entail is removing the original 33.6K / 56K modem chip from the DC modem completely, then hooking up some wires or another flex cable to the custom Sega chip (I worked out the pinouts for that many years ago, and fixed a few mistakes recently).

The Sega chip handles the G2 bus side of things, and presents a very simple 8-bit data bus that normally connects directly to the modem chip. The bus to the modem chip also includes a /CS (Chip Select), /RD (Read), /WR (Write), and 5 address lines, so it's fairly simple.

That also saves us from having to design a whole new board for hooking up to the G2 port etc.

Plus, there are just SOOO many DC modems around, and I don't think most people would be too bothered about the original dial-up modem chip being removed if they can play the games directly via WiFi instead.

I'm giving away some of my "trade secrets" here, so I'd better stop now. hehe

OzOnE.

 

[rant]
About the Windows/Linux compiling debate, I'd argue that it is Windows that's weird. Nothing is more fastidious than to make C/C++ code work on both Linux and Windows, whereas it's typically trivial to make it work on anything else from Linux to freebsd to minix to osx.

This is especially true when you code in 64bits and the quirks are all different. I personally ended up settinga 64bit Cygwin environment just so I can crosscompile to native Windows binaries. This is just to make some simple C99 code work in 64bits with arrays over 4GB in a platform independent way, and yet it uses a lot of IFDEF too.

I honestly suspect this might be on purpose.
[/rant]

P.S. you're still my geek crush though.

 

Oh, I agree with that too.

I can only imagine the nightmares of getting code to work on both Windows and Linux, due to the proprietary API BS on Windows etc.

It's just that every time I've tried my hardest to figure stuff out on Linux and get certain things to compile, it's never been straightforward.

Even when doing all the right steps, there are often issues with either the wrong versions of GCC and prerequisites being used (usually too new, 'cos I kept Ubuntu updated), or it require some stupid patch. lol

I'm not exactly amazing with C by any means, and even less so with the C++ extensions, but I also wouldn't consider myself a complete noob when it comes to messing with compiler options etc., and yet I still seem to have trouble whenever I'm forced to run Linux to get something to compile.

I do have Cygwin installed as well, but that doesn't always go smoothly, or the guides for setting up the toolchains (for various FPGA soft cores etc.) aren't always geared towards Cygwin specifically.

I dunno. I'll have to think of more examples that I've tried in the past, but it's always been a pain.

Also - another thing that REALLY grinds my gears about the Linux-oriented web pages is how they never seem to include pre-compiled binaries for stuff that would clearly be extremely helpful to a lot of people. Like with some emulators that force you to compile the code, when all I wanted to do is download a binary to give it a quick try. Grrrrrr. lol

Sometimes it's just the sheer lack of proper info on how to fix the common compiler errors, or even worse when people don't seemed to have even tried compiling their own latest code, and it has an obvious (to them) bug in it which causes people no end of problems.

Although, if more command-line stuff was written for both Linux and Win32, I'd be fine with that, as long as it compiled easily on either environment.

Again, I'm no expert on this stuff, but it's funny when I hear people say "Oh, you should move over to Linux completely, it's SO easy to use for the day-to-day stuff, and I've ditched Windows altogether now." lol

Fair enough, I could probably just about get away with doing the usual daily web browsing / eBay / Faceplant / YouTube stuff under Linux, but there's no way it could be easily made to run all of the other software I often use.

(OK, so you can get Quartus for Linux too, but there are tons of other little apps and snippets that I need to run all the time. Plus, I could run Linux under a VM of course, which is what I do anyway.)

It's just not for me tbh - Windows is just so prevalent still that it makes the argument for Linux almost moot for a large number of PC users. I don't hate Linux itself, nor the concepts behind it, I just wish people made compiling stuff easier.

OzOnE.

 

I solely use Linux since 2012, bar the occasional XP VM for discjuggler. That said, I'm a scientist that does a lot of programming and data analysis, I don't rely on proprietary software at all, so Linux is adapted to my personal needs. I'm not saying Linux is perfect and Windows is evil (except that's totally the case, dùh!) but rather that "it's more complicated on Linux" is just a perspective, the opposite is just as true on the other side of the medal.

BTW, to get compiled binaries, you typically use the package managers.

Back on topic now, give us beautiful updates on that HDMI out!

 

A lot of times I've had some source code that I've had to manually download, and didn't come with a binary.

I've done the apt-get thing quite a lot too, and that doesn't always include the binaries either.

btw, is there an option for forcing apt-get to automatically install ALL of the prerequisites for a giving proggy?

You'd think it would pop up with an option to search then download that stuff for you, but that's not always the case.

(there's probably a command line switch for it, but I'm not sure. Please don't say, "no, but you can write a script for that". hehe)

OzOnE.

 

Code:

sudo apt-get install -f

(nothing after the "f", it checks for any unmet dependencies)

Normally when you use apt-get to install a program it will install all of its dependencies. If the above command doesn't fix it, you probably messed up something manually. That said however, if you are installing headers or development libraries in order to link/include them in other programs (e.g. gmp or open mp), then you might need to also install some other library depending on the features you want to use. Normally, the compiler spits some error message to tell you which library you need.

Basically if you stick to Ubuntu/Debian (for convenience), apt-get and a few .deb file downloaded online when you have specific needs should get you a very long way.

A new release format is coming to Ubuntu btw, snappy. It should greatly simplify using programs with different library versions and is very interesting, check it out.