Progress on Emu

Dark · Post by **Dark** » Thu Sep 29, 2005 7:14 pm

Hello y'all,

As u can all see, i'm new here, and i'm starting to be a pain in the ass right away: when will te emulator be available for sale? The site says "Available Beginning of September 2005" and september is nearing its end! Anyway, i'd really appreciate to see something about the status of the project...

And as for the MPEG part of the emulator, the digital video cartridge, you may find it a good idea to find an (possibly open-soure, thus free) MPEG rendering DLL, so that you don't have to write te decoding code yourself, this could save u a lot of trouble i guess. I don't have any example DLL's (yet), but i'll be on the look out for them.

Also, i was wondering, in what language is the emulator been written? C? VB (i doubt that, but still an option)? Delphi? I may be able to contribute to the project... At least i'd like that...

Anyway, enough bogus for today, I hope to see some answers soon

collect-o-maniac · Post by **collect-o-maniac** » Fri Sep 30, 2005 12:23 am

dark...its available now...go grab yourself a download

cdifan · Post by **cdifan** » Fri Sep 30, 2005 12:30 am

I have no intention of writing my own MPEG decoding stuff, there's perfectly good stuff already available for that. But it needs to be integrated in the emulator looking like a chipset that the ROMs understand, and that is going to involve a lot of reverse-engineering work.

The emulator is written entirely in C++ without templates, assuming only an ANSI C library (no C++ iostreams, STL, etc).

Dark · Post by **Dark** » Sat Oct 01, 2005 9:09 pm

Hmm, possibly you don't have to reverse engineer the MPEG library you use, whatever type/brand u use.

My vision, correct me if i'm wrong, is that you should be able to write some kind of "bridge" between a MPEG decoding module, and the emulator, that "converts" chipset commands of the emulator, to API calls for the MPEG decoding DLL, and where neccesary, back to chipsets responses, or skip that, and just use the output of the decoding module.

If I can, I would like to help you with thinking this out, and implementing this into the emulator, mail me if you're interested: pimvelders [at] gmail {dot} com

cdifan · Post by **cdifan** » Sun Oct 02, 2005 12:47 am

Your vision about the "bridge" is mostly right, except that you probably don't appreciate the complexity of the task. In fact, most of the CD-i emulator fits this "bridge" description!

There's not one but at least three MPEG chipsets to consider (Gate Array, VMPEG, IMPEG), and it seems that Gate Array has sub-versions as well. I don't know how similar the three are, if it's like the CD chipsets (also three of those so far) then not very! One or possibly two of the chipsets use a Motorola MCD250 chip, for which documentation might perhaps be available (I haven't found it yet), but the other(s) use custom Philips silicon. So there's going to be a fair amount of reverse engineering of the chipset interfaces to be done; luckily I've done quite a lot of that already for the CD chipsets and am starting to get the hang of it

Also, the MPEG playing is more tightly integrated into the CD-i system then you seem to think; all the chipsets expect to receive the decoded MPEG picture(s) back in CD-i memory (there's 512K of it specially reserved) from where they are then displayed using overlay hardware and there's probably a lot of signaling involved in this. I could perhaps skip the backdelivery to memory but the overlaying and signaling needs to be done anyway, so the memory route is probably the easiest one anyway.

It's not a question of just "playing" the MPEG either, there's pause/continue, seek, slowmotion, etc. And then there's the MPEG data delivery, which uses memory polling by the driver.

In short, it's not simple. I'll keep your offer in mind, though.

KuroNeko · Post by **KuroNeko** » Sun Oct 02, 2005 1:43 pm

Would you need to emulate all types? If the objective is to make CDi software playable without a hardware player (as those are breaking down and not reparable), supporting just one type like VMPEG or IMPEG would be enough, wouldn't it?

Or do these carts have a BIOS file like CDi players and there are therefor legal restrictions?

Neko

cdifan · Post by **cdifan** » Sun Oct 02, 2005 3:30 pm

You've hit it right on the head. They have ROMs just like the players themselves, so I think the legal issues are the same. Luckily there's less versions of these cartridges then there are of the players...

And my objective is really to emulate all CD-i hardware, not just one particular configuration. Of course, when you've done one, the others typically aren't that difficult anymore; most of the player compatibility work was done since last April...

Post by **Devin** » Sun Oct 02, 2005 4:09 pm

cdifan wrote:You've hit it right on the head. They have ROMs just like the players themselves, so I think the legal issues are the same. Luckily there's less versions of these cartridges then there are of the players...

And my objective is really to emulate all CD-i hardware, not just one particular configuration. Of course, when you've done one, the others typically aren't that difficult anymore; most of the player compatibility work was done since last April...

I wonder who owns the legal material or ROM on the Digital Video Cartridge, would this be exclusively Philips?

The problem with the CD-i Players ROM is the fact that it uses OS9 which is still property of Microware. Perhaps the Digital Video Cartridge (DVC) is a different matter which could possibly ease the way to a licensed version of the DVC ROM!!

Post by **Bas** » Sun Oct 02, 2005 4:17 pm

can you also get this 'DVC ROM' using the nullmodem cable?

cdifan · Post by **cdifan** » Sun Oct 02, 2005 5:25 pm

You will get it if you use CD-i Link and your player has a DV cartridge; look for a file ?mpeg*.rom...

I have no idea about the rights situation.