Sega Dreamcast HDMI Adapter coming soon ..

Definitely.
For something verified working on Dreamcast at first, but I'm certainly interested in a good few boards.
QSB not a necessity.

Great project, more than willing to stump up the money ahead of time.

 

if the price isn t prohibitive i would buy one or two just to test on dreamcast and snes... too bad for the saturn though!

 

But when you start running video cores on an fpga, is that not already emulation? At some point, you're not running on original hardware anymore.

 

Technically you're right, but there's a bit of a nuance to make.
A fpga reproduces the original circuitry in hardware whereas a software emulator reproduces the functioning of the hardware. If the fpga core is good enough, it should be the same as the original hardware.
Also, only the video part is emulated in this case, to allow different video output. The real deal is calculated on hardware.

@OzOnE : Color me interested for your Dreamcast PCB whenever your ready!

 

ok, so perhaps a more fair comparison would be with netlist simulation, or whatever you call it, rather than functional level emulation...

 

@LornFenixNC - Well, both the Super Game Boy and Game Boy Player are essentially have most of the Game Boy chipset(s) minus the LCD and controls. Who knew?

So, I've just this second ordered a Game Boy Player as well, 'cos it should in theory be easier to hook up.

You can't use the controllers via the Game Cube though, so I'll have to hook up a controller to the FPGA then the FPGA in turn will assert the usual Up / Down / Left / Right signals on the GBP.

EDIT: Technically you very likely could still hook up the GBP to the Gamecube, boot the disk as normal, and then use the GC Controllers with direct HDMI from the GBP itself, but that's not as fun as using the GBP completely stand-alone. You might as well just mod the GC with HDMI otherwise.

We'll know soon if this actually works. I know the SGB needs the ~21MHz clock signal from the SNES to work, and I'm pretty sure the GBP will need a similar clock. This is very easy to generate on the FPGA.

The video timing will be different though, so I will likely need to buffer at least one frame of video before outputting it via HDMI with the correct timings. Although (in the case of the GBP at least), all GBA games have a vertical refresh of 59Hz (pretty much the same as NTSC), so it may be possible to just display the GBA output in the centre of the screen with a 480p output etc.

I think I will try it on the GBP first, as it's much easier to solder to than the SGB (he

Anyway, just a bit of fun to try, and I just got a Jap Game Boy Player for only £9.99 delivered.

@Teddy Rogers - there seems to be a fair number of people interested in HDMI mods from what I've seen on YouTube and the forums etc.
Retro has always been a fairly niche thing of course, but it's gaining popularity every month.

I do like emulation too, but people love to game on original hardware, especially if they actually collect carts / disks / hucards etc.
In fact, I think I was one of the first people in school in the mid-90s to discover emulators, and I used to play on them a ton.

There's just something about real hardware though, even if it's a decent core on FPGA, it still "feels" completely different.
Although most emulators for the older machines are superb now, many still have issues with compatibility and graphical glitches etc. (see N64).

The cost of the larger FPGA chips is dropping every year now, and with things like the Xenia emulator appearing, I don't think it will be long before we see things like Xbox 360 cores on a single chip.

@FamilyGuy / All - Just to confirm - I'm not actually taking pre-orders at this time, I'm just trying to gauge if people would be willing at this fairly early stage to attempt the soldering themselves (or ask somebody else to do it), as it's not the easiest of things to solder to the DAC on the Dreamcast / Xbox / PS1 / PS2. I do intend on getting QSBs and / or Flex cables made for those, though.

I was wondering if the tricky soldering would seriously put people off, or if people just wanted some boards ASAP ? lol

OzOnE

 

Running direct logic on an FPGA is not "emulation" as we traditional know it.
There is usually no translation of opcodes from the original hardware to a different CPU for example (unless the FPGA is running emulation on a "soft"-CPU, in which case it's "cheating". )

Although, as FG says, the accuracy / compatibility of the core depends on how well the logic was written / translated from the original hardware. That normally comes down to how much documentation and proper schematics / logic / register / programming manuals are available for said original hardware.

There are more really good cores appearing all the time though, and we now have nice super-stable cores for things like the VIC-20, C64, Speccy, Beeb, Master System, Genesis / MD (I added somebody's audio core to it. 2-player split-screen mode not quite finished yet), Atari Jaguar (not sure if it has sound yet?), MSX, PC Engine, Game Boy, TRS-80, Apple II, 8086 / 486 PC , Vectrex, Classic Mac, Amiga (now with AGA support and FAST CPU cores), Oric, NES (open-source core not 100% finished), NeoGeo (yes, really), Oric, Colecovision, Atari 2600 / XE / XL etc., and then lots of arcade cores like Pacman, Galaxian, Pengo, Donkey Kong, Frogger, 1942, Space Invaders etc. etc.

Some of the cores need a bit of work to add support for things like audio, on-screen display, and easy loading of ROMs from SD card etc.
A lot of the earlier cores are working 100% already (or near enough to it that you'd never notice the difference).

For the simpler arcade stuff that has good documentation and / or very simple logic, they can be implemented with 100% accuracy.
Aside from that, the main thing that makes it different is not having to translate opcodes for different CPUs like normal software emulation does. You can also have the exact same video output timings, or add scan-doublers or pretty much whatever you choose.

You can see I'm quite supportive of the FPGA stuff. hehe
It's just that the original retro hardware won't last forever, and FPGAs will definitely be the future of retro gaming IMHO.

As FG said, running just enough of the video core to get an image output should keep the rest of the original hardware intact (as far as the CPU and other timings etc.).

In the case of the Genesis and SNES, the video core will very likely still need a bit of external RAM because they both use 64KB of VRAM (the FPGA used on the HDMI board only has around 52KB of on-chip RAM blocks.)

That could be solved by doing the rest of the RAM as logic, and the cores might just squeeze in.

Or, I could do enhanced versions of the boards with a larger FPGA on.
The issue there is that the Cyclone III I'm using is one of the few chips left that isn't BGA...

Doing the PCB layout for a BGA chip would be quite tricky, and I don't think it's something I could manage any time soon tbh.
Our "talented man in the US" said he might be willing to attempt it at some point in the future though.

So, I guess would be easier just to slap some SRAM or SDRAM on a future revision of the HDMI board for machines required a video core.

A while ago, I did some tests on an unfinished SNES PPU core that I found online btw.
I hooked the FPGA board up to a real SNES, and got some sort of output on the screen.
I then realized that the author hadn't yet implemented reading of the VRAM, but the rest of the PPU code looks pretty solid.

I do intend on having another look at the SNES and Genesis video stuff as a priority, and hopefully finishing the SNES video core and adding the CPU etc.

There was also a project (many) years ago which implements most of the SNES SPC700 audio chip too...



For that core, he is running the SPC700 CPU section as emulation in a NIOS-II soft-CPU core though, so it would be better to finish a true "logic" SPC core for that. There's no reason why that couldn't be hooked up to the PPU and CPU cores after that.

There are a few other full SNES cores out there, but they are all closed-source AFAIK...



For the Genesis video core, that's working very well apart from the 2-player spit-screen (high-res) mode.
I did some work on that before and managed to get the backgrounds to display normally, I just need to sort out the sprites.

To hook that up to a real Genesis would still need 64KB of RAM for the VRAM, then about 40 or so wires.
I supposed that never stopped people doing 40-wire modchip installs on certain consoles though? lol

This is the same thread where I also hooked up the YM audio core from "Shaho"...
http://gendev.spritesmind.net/forum/viewtopic.php?f=2&t=1327

The YM audio core is HUGE though, 'cos they went way overboard with the audio mixing precision.
It doesn't even fit alongside the rest of the Genesis core on my DE1 dev board. lol

I could only fit one or two channels of YM audio alongside Torlus' Genesis core, so in the end I simply hooked up a real YM chip until I can reduce the size of the YM core.

Anywho, I know I'm rambling as usual, but I do love all this stuff.
This was just a small demonstration of how good the FPGA cores are getting now.

The other advantage of course is that you can hook up practically any peripheral or controller to any of the different cores.
That's assuming you have the willing to bolt some bits of code together, and do a bit of soldering / debugging.

OzOnE.

 

I'm ready to preorder and solder anything bar bga whenever you're ready!

FG

 

so this project could end to be a full multi-core "Hardware Emulator"? not only the video part of the consoles then this will be a masterpiece

 

damn i am starting to drool everywhere....

 

@OzOnE

Thanks for a very educative reply for someone who knows very little of this stuff. A common problem in emulators seems to be accurate timing especially in hardware with multiple cpus. Is this easier to accomplish with fpga? Sounds like this would be a good way to go in terms of hardware preservation.
Seems also like a hdmi solution is the way to go eventually with retro stuff.

Would this handle switching resolutions better than eg framemeister?

 

@AhmedXyz - Yes, in general it's a lot easier to get accurate timings on in FPGA logic, but only if you have decent enough documentation / schematics / programming guides to deduce the logic as closely as possible to the original.

Some of the old chips used various tricks to re-use certain registers and all sorts to try to keep costs down.
In those cases, it can take a lot of debugging to figure out what's actually going on.
In most cases though, there's only so many ways you can implement things.

You can think of the bulk of the work being done inside the original chips as just a large bunch of counters, plus a lot of combinatorial logic.

eg. There will generally be an "X" counter for the current pixel position across the screen, a "Y" counter for the current line, then it's a case of implementing how each specific chipset addresses VRAM (or main RAM) to draw the tiles / backgrounds / sprites on the screen.

It really is all just a ton of counters (stored as "registers" / Flip Flops), basic binary maths, and logic equations at the end of the day.

If we had proper schematics of the internals of each original chip, we would in theory be able to make a 100% accurate FPGA core for them, but sadly it's not always the case. Most machines only came with programming manuals, and those don't always tell you the exact timings or slight quirks that a machine might have (not to mention some of the unique edge cases and manufacturing bugs that might have had work-arounds / patches in certain games.)

EDIT: The Atari Jaguar core (coded by Gregory "Torlus" Estrade) was a rare case where it was translated mainly from the original Jaguar netlists released by Atari. So, the custom Tom and Jerry chips are in theory identical to the originals, it's only the 68000 core that then had to be added (68K cores are VERY accurate now).

So, it's down to the skill of the FPGA coder as to how good the cores are really, and how much info we have on the chip internals.

Having said that, there are generally fewer factors to worry about when implementing a retro FPGA core compared to coding a traditional software emulator on a PC / modern console / phablet.

Of course, quite a few old chips have been de-capped an analysed at a low level now, but it's only recently that the 6502 / 6510 and the NES PPU have been fully analysed (stunning work btw)...

http://visual6502.org/JSSim/index.html

http://www.qmtpro.com/~nes/chipimages/visual2c02/

The other advantage with FPGAs is that you're not bound by having to follow the timing of one main CPU or graphics card.
You can genuinely have multiple "chips" / logic running in parallel, and they can have completely different clock speeds and timings (like a lot of arcade hardware).

As regards resolution switching, that still hasn't been fully explored nor tested for the N64 / GC and other machines yet.
In theory, I should eventually be able to make the switch seemless, without the HDMI link and TV loosing sync for a few seconds.

The N64 does switch from 480i to 240p all the time. The difference in timings is actually fairly subtle, but the code would need to ensure that there are no "gaps" in the sync or clocks to the HDMI chip.

For most machines I will be doing line-doubling to 480p / 576p, and that should in theory ensure seemless switching (as long as the console / computer doesn't take too long between resolutions).

You can do other tricks though, like generating extra sync pulses if the video signal from the console is lost or "late" for a short time.
Most consoles only switch resolution when the cart / disk first boots though, or when it gets into the main game, so it shouldn't be a problem.

Again, I could have stuck an SDRAM chip on the board, but it would have added latency.
I discussed this at length with [RDC], and we decided that for the sake of cost and board complexity, we would do as much as possible without needing SDRAM.

(If I spent extra time getting the SDRAM stuff working, it would have taken so long to debug that the project might never have got this far tbh.)

At least this way, you will be getting the purest most direct digital video signal from the HDMI port on the majority of machines, and with ZERO (perceptible) added lag.

That brings me to the point of up-scaling...

Now, I know a lot of people will immediately ask "Does it do 720p or 1080p up-scaling??" - Well, no, not at the moment.

The reason is because "up-scaling" is generally completely pointless for most older machines - you can't really add any extra pixels or detail to the original image, and any further processing would either be a false sharpness filter, or it would be adding things which weren't there to begin with.

kevtris even mentioned in one of his vids that the main reason to justify "1080p" output on his Hi-Def NES boards is by adding support for things like Super Eagle scaling. Without that, the "1080p" output would be fairly pointless, because it can't really improve the original low-res blocky character of the NES video output.

Personally I don't really like the look of the Eagle filters, but it's something that I could actually add to my HDMI firmware at a later date.

If you think about something with a low-res screen like the original DMG Game Boy, it only has a resolution of 160x140 pixels. If you then "up-scale" that to a 1080p TV / monitor panel res (1920x1080 pixels), all it means is that it will be drawing each of the relatively huge Game Boy pixels using multiple "TV pixels".

That's why the current gen of HDMI board will be outputting the purest direct video resolution it can, or at least just a simple line-doubled 240p / 288p / 480i / 576i to 480p or 576p.

Modern TVs all have to "up-scale" a lower-res input to the native panel res anyway, and most now do a very good job of it, as long as the input isn't from a terrible Composite, RF, or other analog input.

I realize that a lot of modern TVs have a reputation of doing quite a bad job of displaying SD content too, but that's usually from an analog source - trust me, pixel-perfect noise-free 480p or 576p via HDMI can look superb on 95% of modern TVs.

However, I'm also working on a scaler solution that will work a bit like the popular GBS-82x0 scaler boards, but has two HDMI inputs, VGA input, Component, Composite, and an analog RF tuner. Initially it will "up-scale" and spit out either 720p or 1080p via HDMI, but I eventually want to add an analog DAC to that as well.

The scaler board itself has already been tested, and worked with every retro console I've tried so far.
(N64, GC, Dreamcast, Atari 130XE, C64, MSX, 3DO, and even Intellivision and 2600 via the RF tuner.)

The idea is that it will form a relatively cheap solution for switching multiple inputs from retro machines, but will also be perfect for outputting to HDMI for capture cards and modern TVs. The eventual RGB output board will be great for displaying on CRT / LCD monitors too.

I will of course be adding a scanlines option to that, even for the HDMI output.

Oh, and did I mention that the scaler board also has an IR remote control, nice on-screen menus, on-board 9 Watt stereo audio amp, and even a USB socket on it, and can playback full 1080p MKV movies.

So yep, a lot of work to do yet. My brain is starting to melt. lol

btw, I am very concious that so-called "feature creep" is the killer of too many a project, so I'm trying to keep things as simple as possible.

I do intend on adding scan-line support for the HDMI board, but for now it might have to be enabled via some simple switches.

Adding an on-screen menu would take a while to debug, and would also require a method for control.
That would mean hooking up to the controller / joystick port on each type of console / computer, so we also decided against that for the first version of the board.

The board is intended to be as "plug and play" as possible (but not in the Windows Vista sense. lol)

OzOnE.

 

@madsheep - this HDMI board was never really intended to emulate full systems, especially since we were trying to keep the board as small as possible (without going the BGA route), and not having external RAM onboard atm.

It should be able to run something like the Atari 2600 core, possibly a 48K Speccy, 32K Beeb, or a simple video core.
(I was thinking about putting some Easter Eggs on there. hehe)

A full multi-system retro FPGA board is my other-other project.

I already had a few prototypes made up, and they are working fine apart from a screw-up on my part with the SDRAM layout (as with all prototypes, it's always the seemingly "simple" stuff that gets screwed up on the first run.)

My project is meant to be a much more affordable version of something similar to the MiST, FPGAarcade, or Turbo Chameleon 64 boards (they are quite expensive IMHO)...

http://lotharek.pl/product.php?pid=96

http://amigaworld.net/modules/news/article.php?storyid=6798

https://icomp.de/shop-icomp/en/shop/product/Turbo_Chameleon_64.html

Now I'm thinking of just doing a MiST clone, because they do have a lot of nice cores running already, including the Amiga (now with AGA), Atari ST, Atari 8-bit, C64, Master System, PC Engine, NES, and now even the Acorn Archimedes (which I have great memories of)...

https://code.google.com/p/mist-board/wiki/CoreStatus

The fact that it has an ARM chip onboard for controllers and on-screen menus might be considered "cheating" a little bit, but it does free up a lot of debugging time, and somewhat simplifies the FPGA cores. It also makes loading from SD card a hell of a lot simpler.

So, I'll likely be making a MiST clone board with HDMI on, and it will be a lot cheaper than €199.99.

I have most of the board layout done already, I just need time to finish it after I've got the ball rolling with the HDMI project.

OzOnE.

 

Hey OzOnE, great work so far! Can I make a request for your scaler board? Can you add analog 15KHz RGBHV input to the VGA port and have it support 240p/480i over this connector? Some consoles and arcade boards use 15KHz RGBHV but most monitors don't support it. It would be perfect for a couple projects I plan on doing.

I have also seen some TV's and upscalers that work with 240p/480i/576i over HDMI lately. I think it is more common than previously thought.

 

Hi, MonkeyBoyJoey,

I've been meaning to test that actually - I was wondering just last night if the VGA input would accept a 15KHz signal (as well as Composite Sync on the Hsync pin).

It's something I need to test really, as I know a lot of people will be wanting 15KHz RGB input support.

You can get a version of the board with a SCART socket on it, and it even has a footprint (on the board I have) for a SCART connector where the Composite inputs currently are.

The scaler chip can definitely handle 15KHz RGB input, it just may need a firmware tweak to allow it via the VGA input (or allow switching between YPbPr and RGB via a Component input, with sync on other pins).

I do like the layout of this particular board though, as it has the dual HDMI input as well as every conceivable analog input (apart from an actual SCART socket).

If it can handle 15KHz RGB via the VGA socket, then I think most people would be happy if a simple SCART-to-VGA adapter was included.

What I do know is that it appears to work great with 240p / 288p / 480i / 576i / 480p / 576p input on everything I've tested so far.

It apparently also supports everything from 480i up to 1080p on both the Component and HDMI inputs, and all of the common PC resolutions up to 1080p via the VGA input.

I'm still waiting for another board to arrive from China which will simplify the connection from the scaler to one of the HDMI boards.
(I was testing the scaler before with a 7" 800p TFT panel, but that's now currently sat in a box in a storage container. lol)

EDIT: btw, I can't guarantee that things like 30Hz drop-shadows will look correct on the scaler yet. It depends on whether I can get the firmware SDK to compile, and how much tweaking it will need. I don't think I can add scan-line gen support to the scaler firmware itself either, so that will be an external option on the HDMI (and eventual VGA) boards.

OzOnE.

 

Would it be possible to use a Headset or Micro USB plug as a option to plug a remote into the board to allow the user to set up Upscale, scan lines, ect. instead of a IR remote or more knobs and stuff poking out of the case. just a random thought...

 

AFAIU, the remote would be for a dedicated upscaling box that would take analog inputs and spit out hdmi.

The consoles internal HDMI-out would have jumpers or the like on the PCB, you could then do your own switch.

 

Correct.

I'm probably causing a bit of confusion here, but the scaler is a separate project, and will include it's own IR remote.

But yes, an IR remote could be applicable to the HDMI board too, if I add that functionality.
For the time being though, things like scan-lines will be enabled on the HDMI board via simple switches.

I do want to add things like on-screen display to the HDMI board eventually, but I'm looking to just get some of the kits out to you guys sooner rather than later. An OSD would just complicate things tbh, as there are so many different machines to cater for.


So, the HDMI board mod will be (in most cases)...

Console / Computer -> internal HDMI board -> TV, monitor, or capture card via HDMI.


And the scaler will be...

Console / Computer -> internal HDMI board -> Scaler board (or analog input) -> HDMI board + VGA board -> TV, monitor, or capture card.

For the scaler board, I will be able to add control of scan-lines and other stuff (on the HDMI / VGA output side) via the same included remote. That's just a case of adding one or two extra wires.

Again, the scaler is a separate project to the HDMI board, but the HDMI board can (and will) be used for the scaler board's output.

(It's not a requirement to use the scaler for basic HDMI output from moddable consoles either. It's just an extra project that will be great solution for using multiple consoles with modern TVs and / or capture cards. It will also be possible to add multiple HDMI outputs for simultaneous TV viewing and capture.)

OzOnE.

 

@OzOnE

thanks for the update and clarifications on those projects, i thought at first, the scaler would be on the HDMI board. I wonder how NES HDMI will look like on tv without scaler (and machines before that). i guess if you choose the correct ratio, it will respect the original resolution but will look "small" on big tv with black borders and if go for fullscreen, the tv will upscale by itself, and loose some quality... Am I right ?

 

Would love to put my name down for a Dreamcast board (no QSB needed), as well as an N64 and Gamecube one further down the line.