tag:blogger.com,1999:blog-48670247302313137422024-03-13T21:15:46.635+01:00CD-i BitsRandom musings and info bits about the CD-i related activities of CD-i Fan, the author of CD-i Emulator.CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.comBlogger42125tag:blogger.com,1999:blog-4867024730231313742.post-72542810863053347342023-12-10T23:45:00.002+01:002023-12-11T17:27:08.936+01:00CD-i Emulator 0.6.0 and beyond<p>Today I have released the seventh and probably last beta
release of CD-i Emulator version 0.5.3, which is now in maintenance mode as all
development has shifted to version 0.6.0.</p><p></p>
<p>Even though it is still called beta, this can be considered
a "stable" release. It is only a very small change from the previous
beta release of this version which has been out since April 2023 with no major
issues reported.</p>
<p>The same cannot be said for the current state of version
0.6.0; many structural changes have been made and it is more than likely that
this will result in regression issues relative to version 0.5.3-beta7.</p>
<p>It will probably take some time to get these issues ironed
out and in the meantime today’s release can provide the fallback position.</p>
<p>I will try very hard to keep all the configuration files (especially
<b>cditypes.rul</b> and the files in the <b>sys </b>directory) compatible with both versions.</p>
<p>I do not want to repeat the 0.5.3 "many betas"
pattern with the new version; after the needed stabilization work a formal
non-beta release should follow relatively quickly.</p>
<h2>Highlights</h2>
<p>As hinted above, version 0.6.0 will be a massive update,
basically all the work done after the version 0.5.3-beta5 release in March 2019
(which was not intended as a public beta but leaked anyway; it has since been
made available on my website).</p>
<p>Here are some highlights of the coming version 0.6.0:</p>
<p>- The three-minute time limit between player resets is gone.
Therefore, there are no longer separate "limited" and "unlimited"
editions. Consequently, it is no longer needed to activate the program and it
will be available free of charge.</p>
<p>- Archived disc image files (<b>zip</b>, <b>7zip</b>, <b>gzip</b>, <b>bzip2</b>, etc)
can now be emulated directly; they will be unarchived to a temporary directory
as needed. This features utilizes <b>libarchive</b> for reading the archive files.</p>
<p>- Infrastructure has been put in place for CD-i player and
CD-i disc "art" images to be shown at startup, based on hashing the
disc label sector. The initial release will ship with a basic collection of art
files, in a future version these art images could be downloaded automatically. I
am working with “The world of CD-i” to leverage their comprehensive collection
of cover art images. This feature uses <b>zlib</b>, <b>jpeglib</b>, <b>giflib </b>and the MAME <b>png </b>code to support various image formats.</p>
<p>- The Philips CD-i 604, Philips FW380i, Grundig CD-i 110E
and Bang & Olufsen Beocenter AV5 CD-i player systems are now supported
(with some limitations). These are all variations of existing Philips players
so the changes for this were relatively small.</p>
<p>- The Philips Model BO Videosynthesizer Prototype system (<b>boproto</b>) is
now supported as an OS-9 system; ROM and disc image files for it are already
publicly available from Jorne / MrMii6's Coffee Fueled Retro website at <a href="https://www.cfretro.net/philips-bo-prototype/">https://www.cfretro.net/philips-bo-prototype/</a>.
This needed support for some new chips and a SCSI device hack but was very fun
to do.</p>
<p>- There is a new ROM version identification system based on
ROM tags as described in my previous <a href="https://cdibits.blogspot.com/2021/03/cd-i-roms.html">CD-i ROMs</a> blog post. This replaces the error-prone minor version detection system based on module
versions used before and also adds some validation to the detection process.</p><p></p>
<p>- There is a new <b>CD-i Type </b>program that can produce ROM
information directly from the ROM files that previously could only be produced
by <b>CD-i Link</b>. This program is also capable of collating a collection of such
ROM information files into various forms, including an HTML table format that
will be made accessible via a new “CD-i ROMs” page at the CD-i Emulator website
<a href="https://www.cdiemu.org/">https://www.cdiemu.org/</a>.</p>
<p>Note: Only ROM information files will be made available, not
the actual ROM files themselves, comparable to e.g. the redump website <a href="http://redump.org/">http://redump.org/</a> for disc images.</p>
<p>- The CD-i Type program can also produce a
"datfile" for CD-i ROMs called <b>cdiroms.dat</b> which will also be made
available via the website. With the availability of this file, it will become
possible to use ROM managers such as ClrMamePro, RomCenter and RomVault to
check CD-i ROM file collections.</p>
<p>- The above ROM managers will put ROM files inside folders
or archives, which is now also supported by CD-i Emulator inside the <b>rom
</b>directory.</p>
<p>- ADPCM audio decoding has been improved by keeping
intermediate results with bigger precision and changing the rounding. Many technical
details can be found on Discord around this message: <a href="https://discord.com/channels/675054061665386544/676505089103495187/1094786111408189502">https://discord.com/channels/675054061665386544/676505089103495187/1094786111408189502</a>
</p>
<p>- All sources are now maintained in a git repository, making
for easier maintenance, and paving the way for a future source release on GitHub.</p>
<p>- All documentation files now have proper file extensions (e.g. <b>RELNOTES.txt</b>),
making it easier for non-technical users to find and open them.</p>
<h2>Further work</h2>
<p>Some more work that might be done in later 0.6.x releases,
not in any particular order or priority:</p>
<p>- Modification of the <b>Help > Report</b> menu option to
automatically create a GitHub issue.</p>
<p>- Support for CUE files which would allow disc images to be
split into<span style="mso-spacerun: yes;"> </span>separate files (typically
one per track) as often done by disc dumping programs or archive sites. Each
track file could have a different format, for example MODE2/2352 for the CD-i
track and WAV or MP3 for audio tracks.</p>
<p>- Support for CHD version 5 files (the current version);
currently CD-i Emulator only supports up to version 4 CHD files.</p>
<p>- Support for ROM sets (e.g. for specific player
configurations or for testing) in subdirectories based on the existing folder
and archive support.</p>
<p>- Graphical UI version of CD-i Link to make CD-i ROM
downloading easier for users unfamiliar with the command line.</p>
<p>- Graphical UI support for more CD-i Emulator settings, esp.
the CD-i player model and/or ROMs to use in case you have more than one, again
mainly intended for users unfamiliar with the command line.</p>
<p>- Finishing support for CD-i 60x floppy drives; possibly
also adding support for CD-i 180 and CD-i 615 floppy drives (they use different
controllers).</p>
<p>- Adding disc and audio emulation for the Sony and Kyocera CD-i
players, which means handling more variants of the RCHIP disc controller
already supported for the Philips CD-i 370 and Goldstar GPI-1200M players.</p>
<p>- Adding proper support for the RTC functions of 32K
NVRAM chips as used in more high-end players; currently the date and time
is not correctly read from these chips.</p>
<p>- Support for loading and saving of NVRAM files directly
from the hard disc (this requires partial high-level emulation of the /nvr
driver).</p>
<p>- Completion of OSD support for the B&O Beocenter AV5
player. I have one of those now, so that should make it somewhat easier.</p>
<p>- More support for the various I2m boards, right now they do
not even boot.</p>
<p>- Support for save/restore of player state snapshots.</p>
<p>- Creation of a pure command-line version of CD-i Emulator, useful for
regression tests and rendering high-quality videos of sessions recorded with
the existing input recording/playback functionality. You would not be able to
directly control the CD-i player, only control emulation from the debug
command prompt.</p>
<p>- Creation of an SDL version of CD-i Emulator, paving the
way for future ports to systems other than Windows. This version would not have
a GUI to control emulation, you would again need to use the debug interface for
that. For more information about SDL, see <a href="https://www.libsdl.org/">https://www.libsdl.org/</a>.</p>
<p>- Creation of basic ports to systems other than Windows
using SDL. Envisioned target systems include Linux, MacOS, iOS and Android.
Especially the latter two present challenges because they do not have an easy way
to create a debug interface except via the network.</p>
<p>Basic research and sometimes partial implementation have
been done for all of the above.</p><p>As you can infer from the above, the primary goal of the
version 0.6.x releases is not to improve the core emulation performance or
quality, though some enhancements and bugfixes have been and will continue to
be made and support for some new supported exotic players might also be added.</p><p></p>
<p>Rather, the primary goal will be to improve the user
interface and experience, both for emulation (CD-i Emulator) and ROM extraction
(CD-i Link) and collation (CD-i Type).</p>
<h1>Roadmap</h1>
<p>The primary goal of the 0.5.x releases was always to get a
basic CD-i emulator working, which I feel has been more then accomplished by
now.</p>
<p>In my mind the primary goals for the coming minor releases
are:</p>
<p><b>0.6.x </b>– Improve user interface and experience</p>
<p><b>0.7.x </b>– Fix Digital Video cartridge emulation issues</p>
<p><b>0.8.x </b>– Fix as many other emulation issues as possible</p>
<p><b>0.9.x</b> – Do whatever still needs to be done for a...</p>
<p><b>1.0.x</b> – Reasonably complete CD-i Emulator!</p>
<p>When the <b>1.0.0</b> milestone is reached, I will do a source
release on GitHub. It would be nice if that could be done some time in 2025
because that would be twenty years after the first public release in 2005, a
nice round number.</p>
<h2>Future work</h2>
<p>Some things that I would still like to do that might go
after that, but also (partially) before if I get the itch:</p>
<p>- Complete ROM-less CD-i emulation, requiring high-level
emulation of most of the CD-RTOS operating system, in effect adding a
high-level "CD-RTOS coprocessor" to the emulated system.</p>
<p>- Better support for title developers and reverse engineers.
A more graphical UI debugger, video DCP and pixel inspection, data tracing,
etc.</p>
<p>- Add chip access collation to support better documentation of
SLAVE/IKAT command variation between versions.</p>
<p>- Validate processor emulation by producing instruction traces
that can be downloaded into and validated on actual hardware, including timing
information (cycle counts)</p>
<p>- Enhance CD-i Emulator for use as a hybrid OS-9 development
system like “os9exec”, useful for running OS-9 binaries like the C compiler and
other tools.</p>
<p>- Finish and release CD-i file conversion programs; right now
they are a hodge-podge of just what I personally needed and not functionally or
even technically complete in any way.</p>
<p>- Create a CD-i file viewer program. This should allow
viewing of the contents of any CD-i related file, from disc images down to
disassembly. In many ways this would be a "lite" version of an
emulator because it would have all the format decoding (but no exact chip
emulation).</p>
<p>- Enhance the existing CD-i File program to support extracting
the contents of any CD-i related file, in essence the command-line version of the
CD-i file viewer.</p>
<p>- Create a CD-i disc image building program, ideally based on
title development support (e.g. partial disc images) integrated into CD-i Emulator.</p><p>- Create a CD-i disc image editing program based on both of the above.</p>
<p>And whatever else may come up!</p>
<h2>Discussion</h2>
<p>If you would like to reach out to discuss features or their priority,
the <b>#emulation</b> channel of the Philips CD-i Discord server at <a href="https://discord.gg/TKPejTfw6D">https://discord.gg/TKPejTfw6D</a> is the
right place.</p>
<p>You can also use the CD-i Emulator issue tracker on GitHub
at <a href="https://github.com/cdifan/cdiemu/issues">https://github.com/cdifan/cdiemu/issues</a> to suggest features.</p>
CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com0tag:blogger.com,1999:blog-4867024730231313742.post-59403923204992988752023-12-10T23:15:00.001+01:002023-12-10T23:15:37.687+01:00 Announcing CD-i Emulator version 0.5.3-beta7 for Windows<p>A new beta release of CD-i Emulator is now available from the Downloads section of the CD-i Emulator website at <a href="https://www.cdiemu.org/downloads/">https://www.cdiemu.org/downloads/</a>.</p><p>Release notes can be found in the RELNOTES file included in the download; a summary as well as the full version is available from the Release Notes section at <a href="https://www.cdiemu.org/relnotes/">https://www.cdiemu.org/relnotes/</a>.</p><p>This version of CD-i Emulator is the seventh and probably last beta release for version 0.5.3, which is now in maintenance mode as all development has shifted to version 0.6.0 for which a first public beta release is expected soon.</p><p>Relative to the previous version 0.5.3-beta6 release only a few bugfixes and small enhancements have been made; see the Release Notes for details.</p><p>Note to would-be crackers of this version (you know who you are):</p><p>I really would prefer it if you didn't. There is really no need!</p><p>As with all previous beta versions, using a Mono-I CD-i system ROM (also called BIOS) will give you unlimited emulation functionality; this is the same ROM file needed for the MESS/MAME CD-i driver.</p><p>Saving the contents of the CD-i NVRAM to a file is still supported.</p><p>To obtain unlimited emulation functionality with a different CD-i system ROM file, please buy the still available unlimited edition of version 0.5.2. Activating this on your PC will also unlock the unlimited emulation functionality of this beta version.</p><p>If you have bug reports or feature requests please use the GitHub issue tracker at <a href="https://github.com/cdifan/cdiemu/issues">https://github.com/cdifan/cdiemu/issues</a>; as of right now no CD-i Emulator source code is on GitHub but eventually there will be.</p><p>For comments, questions and discussion you can use the #emulation subforum of the Philips CD-i Community Discord server reachable at <a href="https://discord.gg/TKPejTfw6D">https://discord.gg/TKPejTfw6D</a>. I am known there as CD-i Fan (cdifan).</p><p>You can also reach me via e-mail using <a href="mailto:cdifan@gmail.com">cdifan@gmail.com</a>, but this will not involve the larger CD-i community and is hence discouraged.</p><p>If you like my work and/or would like to support future development, you can also send me a donation. You can send PayPal payments to <a href="mailto:payment@cdiemu.org">payment@cdiemu.org</a> or use one of the following websites:</p><p><a href="https://www.buymeacoffee.com/cdifan">https://www.buymeacoffee.com/cdifan</a></p><p><a href="https://ko-fi.com/cdifan">https://ko-fi.com/cdifan</a></p><p>As of right now you can also still buy the unlimited edition of version 0.5.2, but in the future this will no longer be possible. Go to the Payments section of the website and get an original serialized version while you still can!</p><p>Have fun emulating your favorite CD-i titles!</p><div><br /></div>CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com0tag:blogger.com,1999:blog-4867024730231313742.post-9872806320034093502023-04-07T22:00:00.000+02:002023-05-13T21:15:03.987+02:00 Announcing CD-i Emulator version 0.5.3-beta6 for Windows<p>A new beta release of CD-i Emulator is now available from the Downloads section of the CD-i Emulator website at <a href="https://www.cdiemu.org/downloads/">https://www.cdiemu.org/downloads/</a>.</p><p>Release notes can be found in the RELNOTES file; a summary is available from the Release Notes section at <a href="https://www.cdiemu.org/relnotes/">https://www.cdiemu.org/relnotes/</a>.</p><p>This is the sixth beta release for version 0.5.3. It is hugely out of date with the current development version 0.6.0; the only reason for its release is to get a working version available again.</p><p>The only major change is that emulation speed throttling has been fixed for modern machines so games running at unplayable speeds should be a thing of the past.</p><p>Note to would-be crackers of this version (you know who you are):</p><p>I really would prefer it if you didn't. There is really no need!</p><p>As with all previous beta versions, using a Mono-I CD-i system ROM (also called BIOS) will give you unlimited emulation functionality; this is the same ROM file needed for the MESS/MAME CD-i driver.</p><p>This beta version also has the NVRAM save functionality enabled, and before the built-in beta date limit expires a new beta release for version 0.6.0 should be available.</p><p>To obtain unlimited emulation functionality with a different CD-i system ROM file, please buy the unlimited edition of version 0.5.2 which is still available at <a href="https://www.cdiemu.org/payments/">https://www.cdiemu.org/payments/</a>.</p><p>Activating the unlimited edition on your machine will also unlock the unlimited emulation functionality of this beta version.</p><p>If you like my work and/or would like to support future development, you can also send me a donation. You can send PayPal payments to <a href="mailto:payment@cdiemu.org">payment@cdiemu.org</a> or use one of the following websites:</p><p><a href="https://www.buymeacoffee.com/cdifan">https://www.buymeacoffee.com/cdifan</a></p><p><a href="https://ko-fi.com/cdifan">https://ko-fi.com/cdifan</a></p><p>Have fun emulating your favorite CD-i titles!</p>CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com0tag:blogger.com,1999:blog-4867024730231313742.post-59288685230919024452021-03-27T23:06:00.000+01:002023-05-13T21:14:50.021+02:00CD-i ROMs<p>Most currently existing CD-i emulators use so-called
low-level emulation for the system software. This means that to perform their
emulation function they need copies of this software.</p><p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal">The CD-i system software is typically stored in read-only memory
(ROM) chips inside the CD-i player; the only known exceptions to this are the
PCI/ISA CD-i boards from I2m / Philips that have their system software loaded
from the hard disk of the host system. <o:p></o:p></p>
<p class="MsoNormal"></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://1.bp.blogspot.com/-G9DeXxtfSE8/YF5eTu34VWI/AAAAAAAAAUY/x20cUlZMGMAsizQLO9PiyOWTAwLP0YySgCLcBGAsYHQ/s200/cdi210c11-rom.gif" style="margin-left: auto; margin-right: auto;"><img alt="ROM picture" border="0" data-original-height="64" data-original-width="200" height="64" src="https://1.bp.blogspot.com/-G9DeXxtfSE8/YF5eTu34VWI/AAAAAAAAAUY/x20cUlZMGMAsizQLO9PiyOWTAwLP0YySgCLcBGAsYHQ/w200-h64/cdi210c11-rom.gif" width="200" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;"><b>Philips CD-i 210 F3 ROM 1.1</b></td></tr></tbody></table><br /><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://1.bp.blogspot.com/-dK2-2VSYHK4/YF5eTmH5OVI/AAAAAAAAAUc/2dSMvbAofB0cd333RR25J6ond2C07dBoACLcBGAsYHQ/s200/cdi210c15-rom.gif" style="margin-left: auto; margin-right: auto;"><b><img alt="ROM picture" border="0" data-original-height="71" data-original-width="200" height="71" src="https://1.bp.blogspot.com/-dK2-2VSYHK4/YF5eTmH5OVI/AAAAAAAAAUc/2dSMvbAofB0cd333RR25J6ond2C07dBoACLcBGAsYHQ/w200-h71/cdi210c15-rom.gif" width="200" /></b></a></td></tr><tr><td class="tr-caption" style="text-align: center;"><b>Philips CD-i 210 F3 ROM 1.5</b></td></tr></tbody></table><br /><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://1.bp.blogspot.com/-pR579hPtnIM/YF5eT7L7nuI/AAAAAAAAAUg/ItZlsgH_tuw-N1q_X7elKXtxyT6Gc7VaQCLcBGAsYHQ/s200/beoav5a19-rom.gif" style="margin-left: auto; margin-right: auto;"><img alt="ROM picture" border="0" data-original-height="67" data-original-width="200" height="67" src="https://1.bp.blogspot.com/-pR579hPtnIM/YF5eT7L7nuI/AAAAAAAAAUg/ItZlsgH_tuw-N1q_X7elKXtxyT6Gc7VaQCLcBGAsYHQ/w200-h67/beoav5a19-rom.gif" width="200" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;"><b>B&O Beovision AV5 ROM 1.9</b></td></tr></tbody></table><p class="MsoNormal"><b>ROM types and sizes<o:p></o:p></b></p>
<p class="MsoNormal">The typical CD-i player contains 512KB of system ROM which contains the CD-RTOS operating system based on Microware
OS-9/68000 version 2.4. This system ROM contains the core system software
including the OS-9 kernel, CD‑RTOS file managers, drivers for the specific CD-i
player hardware, as well as system startup programs. The core system software
typically takes less than half of the ROM, the rest is taken up by code and
resources (e.g., images, fonts) for the player shell and usually some utility
modules. On some of the later Philips players the system ROM is so full that
niceties such as the CD+Graphics decoder <span face="Calibri, sans-serif" style="font-size: 14.6667px;">“</span><span face="Calibri, sans-serif">cdgr</span><span face="Calibri, sans-serif" style="font-size: 14.6667px;">”</span> or the Service Shell <span face="Calibri, sans-serif" style="font-size: 14.6667px;">“</span>sv<span face="Calibri, sans-serif" style="font-size: 14.6667px;">”</span> have been omitted.</p><p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal">Notable exceptions to this are the Sony IVO players which
have 1MB of system ROM, although only a little over 835KB of that is used.
The core system software takes less then 200KB of this, the remainder of the
ROM is again filled with code and resources for the player shell. <o:p></o:p></p>
<p class="MsoNormal">Most CD-i Digital Video Cartridges (DVCs) contain 128KB of additional
ROM with CD-RTOS file managers and drivers to support the MPEG playback
functions. Little over half of this ROM is typically used, it varies somewhat
with the hardware generation. Some cartridge versions also contain some utility
modules as well. <o:p></o:p></p>
<p class="MsoNormal">Professional or authoring players typically have other additional ROMs, usually located on some kind of (removable) extension
board. For example, the CD-i 182 unit contains an additional 64KB of ROM with
drivers for the floppy drives and other hardware in this unit. Extension boards
for this unit have sockets for additional ROM chips but I have never seen them
filled. <o:p></o:p></p>
<p class="MsoNormal">In contrast to this, the CD-i 605 extension board contains
512KB of additional ROM to support the Ethernet and SCSI controllers and
other hardware on the board, and it is mostly filled. <o:p></o:p></p>
<p class="MsoNormal">The CD-i 615 and CD-i 670 use another extension board which
also contains 512KB of ROM with support modules for their additional
hardware, which in this case includes IMPEG digital video. <o:p></o:p></p>
<p class="MsoNormal"><b>Dumping ROMs<o:p></o:p></b></p>
<p class="MsoNormal">A low-level CD-i emulator needs access to the contents of
these ROMs, which must be obtained from the hardware using a pro<span style="font-family: inherit;">cess called </span><span style="font-size: 14.6667px;">“</span><span style="font-family: inherit;">dumping</span><span style="font-family: inherit; font-size: 11pt; line-height: 107%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;">”</span><span style="font-family: inherit;">.</span></p><p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal">All CD-i system ROMs are standard ROM chips that can be
read out by a ROM dumping device. These devices can be custom made hardware,
but an off-the-shelf EPROM programmer device can also be used. For this to
happen the ROM chip typically needs to be removed from the CD-i player, which
means opening the player and often requires desoldering the ROM chip. <o:p></o:p></p>
<p class="MsoNormal">However, the contents of these ROMs are also accessible from
inside the CD-i player (that is after all their primary function), so they can
also be dumped using software. This is typically done over the serial port as most
consumer players have no other easily accessible output port (theoretically the
ROM contents could also be dumped over the audio or video outputs but that has
so far not been necessary). <o:p></o:p></p>
<p class="MsoNormal">Early 2005 I wrote a program called <span face="Calibri, sans-serif" style="font-size: 14.6667px;">“</span>CD-i Link<span face="Calibri, sans-serif" style="font-size: 14.6667px;">”</span> that uses the built-in download function of most CD-i players to download a
small <span face="Calibri, sans-serif" style="font-size: 14.6667px;">“</span>CD-i Stub<span face="Calibri, sans-serif" style="font-size: 14.6667px;">”</span> program into the CD-i player so that memory can be
scanned for ROMs and their contents can be dumped via the serial port. If the
player has no such download function, a <span face="Calibri, sans-serif" style="font-size: 14.6667px;">“</span>CD-i stub<span face="Calibri, sans-serif" style="font-size: 14.6667px;">”</span> disc can be used
to start the stub program.<o:p></o:p></p>
<p class="MsoNormal">The system ROMs of all CD-i players encountered so far can
be dumped this way, with one exception: the Sony IVO-V10/V11 players. These
players do not have a regular serial port accessible from the outside. Fortunately,
they do have a service port that supports serial communication although it needs
to be accessed directly from the system board which in this case does mean
opening the player and doing a little soldering.<o:p></o:p></p>
<p class="MsoNormal"></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://1.bp.blogspot.com/-pAAHE0FCHrs/YF5eqxHbQtI/AAAAAAAAAVE/iGJNk2i19JcsvvoPKEZy38who2qAXTu0wCLcBGAsYHQ/s600/ivov11.jpg" style="margin-left: auto; margin-right: auto;"><img alt="open player picture with soldered wires" border="0" data-original-height="450" data-original-width="600" height="300" src="https://1.bp.blogspot.com/-pAAHE0FCHrs/YF5eqxHbQtI/AAAAAAAAAVE/iGJNk2i19JcsvvoPKEZy38who2qAXTu0wCLcBGAsYHQ/w400-h300/ivov11.jpg" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;"><b>Sony IVO-V11 player with service switch and serial cable</b></td></tr></tbody></table><p></p><p class="MsoNormal">In addition to the CD-i system ROMs, which are accessible
from the main 68000 CPU, CD-i players and digital video cartridges often
contain microcontroller and/or signal processing chips that have their own ROM. Dumping this can be complex, in some cases the chips need to be “decapped”
or a special test or manufacturing mode needs to be used in order to read out
the ROM contents.<o:p></o:p></p>
<p class="MsoNormal">Fortunately, CD-i Emulator does not use low-level emulation
for these chips and hence does not need dumps of their ROMs. Other emulators
may need these dumps now or in the future, but it is not relevant to the rest of
this article and I will ignore such ROMs below.<o:p></o:p></p>
<p class="MsoNormal"><b>ROM versions<o:p></o:p></b></p>
<p class="MsoNormal">There are several brands of CD-i players, and typically multiple
player models and versions within each brand. Even nominally identical players will
sometimes contain different ROM versions. <o:p></o:p></p>
<p class="MsoNormal">The intended scenario for using CD<span face=""Calibri",sans-serif" style="font-size: 11pt; line-height: 107%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;">‑</span>i<span face=""Calibri",sans-serif" style="font-size: 11pt; line-height: 107%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"> </span>Emulator is that a user
dumps the ROMs from his own CD<span face=""Calibri",sans-serif" style="font-size: 11pt; line-height: 107%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;">‑</span>i player using CD<span face=""Calibri",sans-serif" style="font-size: 11pt; line-height: 107%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;">‑</span>i<span face=""Calibri",sans-serif" style="font-size: 11pt; line-height: 107%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"> </span>Link and then proceeds to
use these ROM files with the emulator. For this reason, it is important that
CD<span face=""Calibri",sans-serif" style="font-size: 11pt; line-height: 107%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;">‑</span>i<span face=""Calibri",sans-serif" style="font-size: 11pt; line-height: 107%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"> </span>Emulator supports as many ROM versions are practical. <o:p></o:p></p>
<p class="MsoNormal">In practice, CD<span face=""Calibri",sans-serif" style="font-size: 11pt; line-height: 107%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;">‑</span>i ROM files can also be found on the
Internet and many CD<span face=""Calibri",sans-serif" style="font-size: 11pt; line-height: 107%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;">‑</span>i<span face=""Calibri",sans-serif" style="font-size: 11pt; line-height: 107%; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"> </span>Emulator users obtain them this way. These files are
however still copyrighted, and their distribution is not legally allowed.<o:p></o:p></p>
<p class="MsoNormal"><b>ROM detection<o:p></o:p></b></p>
<p class="MsoNormal">So how does any emulator deal with this bewildering variety
of ROM versions? It will need to detect what hardware is expected by a
particular ROM, assuming the emulator supports that hardware. <o:p></o:p></p>
<p class="MsoNormal">CD-i Emulator uses rule-based detection to determine the
CD-i player type and the expected hardware based on the contents of the ROMs.
The detection is driven by a rules file with conditions on the OS-9 modules
contained in the ROMs. Doing it this way means that the detection is generally
tolerant of ROM variations, which was important early on because it was unclear
what kinds of ROMs were out there. <o:p></o:p></p>
<p class="MsoNormal">For an explanation and the current contents of the rules
file used by CD-i Link and CD-i Emulator see the CD-i Types section of my website at <a href="http://www.cdiemu.org/cditypes/" target="_blank">www.cdiemu.org</a>.<o:p></o:p></p>
<p class="MsoNormal">For a different approach, the MAME emulator uses detection based
on hashes (checksums) of the ROM files, which means that it only works with
specific ROMs (actually, MAME does not so much “detect” ROM versions
as well as “verifies” them, its source code contains lists of ROM hashes
that are accepted by specific emulation drivers). <o:p></o:p></p>
<p class="MsoNormal"><b>Refining ROM detection<o:p></o:p></b></p>
<p class="MsoNormal">Some CD-i users have been collecting CD-i ROMs for many
years now. It has become apparent that many more versions of CD-i system ROMs exist than initially expected. Therefore a better way of cataloguing ROMs instead of just by main player type is
needed. Also, as more ROMs became available holes were uncovered in the
detection rules used by CD-i Emulator. These holes usually resulted in mis-detecting
the player version, although the emulation would often still work as the
hardware variations were minor or non-existent.</p><p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal">In January of this year, I made an attempt to fix some mis-detection issues based on information supplied by rosewood of <a href="https://retrostuff.org" target="_blank">retrostuff.org</a> and I also tried refining the detection rules to differentiate between ROM versions. The latter quickly became
unwieldy, but it turned out that there is a much better way. <o:p></o:p></p>
<p class="MsoNormal"><b>ROM tags<o:p></o:p></b></p>
<p class="MsoNormal">The low-level tests of many players display ROM ID and ROM release
information as well as ROM checksums, and newer player shells display some of
this information in the copyright screen as well. Could this information
be used for ROM detection?<o:p></o:p></p>
<p class="MsoNormal">Pointed in the right direction by rosewood, I found out that this “ROM tag” information is stored in a
consistent, documented, way across all Philips and Philips-based CD-i ROMs
which makes it easy to extract that information for detection purposes.<o:p></o:p></p>
<p class="MsoNormal">From the CD-i 220 phase 1 and CD-i 350/360 service manuals
(these are both Mini-MMC players):<o:p></o:p></p>
<p class="MsoNormal"></p><div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-Y0dztIU33P4/YF5fEcFgq5I/AAAAAAAAAVM/Fha6cSQJvxgjKdTuH5Lc1NHXNmTM_tSVwCLcBGAsYHQ/s314/mimimmc-svc1.png" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img alt="5.1.8 Release number, position and checksum storage" border="0" data-original-height="314" data-original-width="300" height="277" src="https://1.bp.blogspot.com/-Y0dztIU33P4/YF5fEcFgq5I/AAAAAAAAAVM/Fha6cSQJvxgjKdTuH5Lc1NHXNmTM_tSVwCLcBGAsYHQ/w265-h277/mimimmc-svc1.png" width="265" /></a> <a href="https://1.bp.blogspot.com/-Ii2decrHxlQ/YF5fLzKwxrI/AAAAAAAAAVQ/WlnC1fR91askjQdA6sFys9no1J8oYhKUgCLcBGAsYHQ/s300/minimmc-svc2.png" style="margin-left: 1em; margin-right: 1em;"><img alt="5.1.9 How is the checksum calculated?" border="0" data-original-height="166" data-original-width="300" src="https://1.bp.blogspot.com/-Ii2decrHxlQ/YF5fLzKwxrI/AAAAAAAAAVQ/WlnC1fR91askjQdA6sFys9no1J8oYhKUgCLcBGAsYHQ/s16000/minimmc-svc2.png" /></a><br /><br /></div><br /><br /><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div>Information for the Mono-I players can be found in
the CD-i 210 phase 1 and CD-i 220 phase 2 service manuals:</div><div><p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"></p><div class="separator" style="clear: both; text-align: left;"><a href="https://1.bp.blogspot.com/-AuhMRuABucI/YF5futcs1CI/AAAAAAAAAVc/_GGZH36dzBQAEdmq9weKFipQrYQCkhuFACLcBGAsYHQ/s387/mono1-svc.png" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img alt="5.2.8 RELEASE NUMBER, ID AND CHECKSUM STORAGE" border="0" data-original-height="387" data-original-width="300" height="320" src="https://1.bp.blogspot.com/-AuhMRuABucI/YF5futcs1CI/AAAAAAAAAVc/_GGZH36dzBQAEdmq9weKFipQrYQCkhuFACLcBGAsYHQ/w248-h320/mono1-svc.png" width="248" /></a><a href="https://1.bp.blogspot.com/-9diuNjmvRAE/YF8fYKFUrDI/AAAAAAAAAV8/oYZsbva9BckUTuTsaRpAeXZLFQtyk8MPgCLcBGAsYHQ/s300/mono1-svc2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img alt="5.2.9 HOW IS THE CHECKSUM CALCULATED?" border="0" data-original-height="213" data-original-width="300" src="https://1.bp.blogspot.com/-9diuNjmvRAE/YF8fYKFUrDI/AAAAAAAAAV8/oYZsbva9BckUTuTsaRpAeXZLFQtyk8MPgCLcBGAsYHQ/s16000/mono1-svc2.png" /></a><br /><br /></div></div><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><blockquote style="border: none; margin: 0 0 0 40px; padding: 0px;"><div style="text-align: left;"> Note: The information about the last 1024 bytes<br /> is incorrect for Mono players!</div></blockquote></blockquote><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div>This information was dropped from later service manuals, but
it turns out to be valid (with suitable modifications) for all Philips and
Philips-derived CD-i system ROMs, included the additional ROMs used in
extension boards and digital video cartridges.</div><div><p></p><p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal">The ROM ID and ROM release bytes are stored in BCD
(binary-coded-decimal) with an implied decimal point. Some low-level tests render these bytes directly (e.g., <span style="font-family: courier; font-size: x-small;">12</span>), others include the decimal point (e.g., <span style="font-family: courier; font-size: x-small;">1.2</span>).<o:p></o:p></p>
<p class="MsoNormal">So far, the only CD-i system ROMs found to <i>not</i> contain ROM
tags are those from the Philips CD-i 180, Sony IVO and Kyocera Pro players.<o:p></o:p></p>
<p class="MsoNormal"><b>Copyright screen<o:p></o:p></b></p>
<p class="MsoNormal">CD-i players with the 2<sup>nd</sup> Philips player shell
display the ROM ID and release numbers in the copyright screen in the format</p><p class="MsoNormal" style="text-align: center;"><b style="text-indent: 0.5in;">1</b><i style="text-indent: 0.5in;">AA</i><b style="text-indent: 0.5in;">5</b><i style="text-indent: 0.5in;">BB</i><b style="text-indent: 0.5in;">-2</b><i style="text-indent: 0.5in;">CC</i><b style="text-indent: 0.5in;">4</b><i style="text-indent: 0.5in;">DD</i><b style="text-indent: 0.5in;">-3</b><i style="text-indent: 0.5in;">EE</i></p><p class="MsoNormal" style="text-indent: 0.5in;"><o:p></o:p></p>
<p class="MsoNormal">where <i>AA</i> is the system ROM ID and <i>BB</i> is the system ROM release.
The other numbers are not important for ROM version detection but are
interesting nonetheless, <i>CC</i> is the SERVO chip version (Mini-MMC, Mono-I, and Mono-II players) or the extension ROM release (CD-i 615 / 670 players) or 00 (other players), <i>DD </i>is the SLAVE/IKAT version, and <i>EE</i> is
the player shell “ps” module edition.</p><p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://1.bp.blogspot.com/-1bclxb6dsRI/YF5gB-81znI/AAAAAAAAAVk/zsqQ6Tock9MOmpynOioQYqFUHY6ZEv17wCLcBGAsYHQ/s768/cdi210c15-cpr.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="560" data-original-width="768" height="233" src="https://1.bp.blogspot.com/-1bclxb6dsRI/YF5gB-81znI/AAAAAAAAAVk/zsqQ6Tock9MOmpynOioQYqFUHY6ZEv17wCLcBGAsYHQ/w320-h233/cdi210c15-cpr.png" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;"><b>Philips CD-i 210 F3 </b><b>copyright screen for ROM 1.5</b></td></tr></tbody></table><o:p></o:p><p></p>
<p class="MsoNormal">Some non-Philips CD-i player shells display some of this information in a different format, e.g., the Digital Video System DVE-100 player shell “vs” uses the format</p><p class="MsoNormal" style="text-align: center;"><b style="text-indent: 0.5in;">1</b><i style="text-indent: 0.5in;">AA</i><b style="text-indent: 0.5in;">2</b><i style="text-indent: 0.5in;">BB</i><b style="text-indent: 0.5in;">-3</b><i style="text-indent: 0.5in;">CC</i><b style="text-indent: 0.5in;">4</b><i style="text-indent: 0.5in;">DD</i><b style="text-indent: 0.5in;">-5</b><i style="text-indent: 0.5in;">EE</i></p><p class="MsoNormal" style="text-indent: 0.5in;"><o:p></o:p></p><p class="MsoNormal">where <i>AA</i> is again the system ROM ID and <i>BB</i> is the system ROM release. The <i>CC</i> and <i>DD</i> numbers are hardware related, and <i>EE</i> is the player shell “vs” module edition.</p><p class="MsoNormal"><b>ROM tag complications</b></p>
<p class="MsoNormal">As described by the service manuals, the ROM tag information
is always stored in the last four visible bytes of each CD-i ROM chip. But
there are some complications not described in those manuals.<o:p></o:p></p>
<p class="MsoNormal">The Maxi-MMC CD-i players (CD-i 601) and the analog digital video boards
(22ER9141) use two 8-bit wide ROM chips to provide the main CPU with 16-bit
wide ROM data. In the case of such a ROM chip pair, each of these ROM chips
contains its own ROM tag information. All such pairs encountered so far have
the same ROM release byte with the ROM ID bytes differing by one (e.g., 10:11
or 20:21). In these cases, the CPU will see two interleaved ROM tags in the
last eight visible bytes of the ROM space.<o:p></o:p></p>
<p class="MsoNormal"><b>Underdumping <o:p></o:p></b></p>
<p class="MsoNormal">On the Mini-MMC and Maxi-MMC boards, the last 1024 bytes of
the system ROM are not accessible by the CPU; the video registers of the VSC video
chips are located there as described in the service manual. On these boards,
the ROM tag is in the last four bytes just before the 511KB mark, and the rest of each ROM is considered empty (full of FF bytes) for checksum calculation purposes. <o:p></o:p></p>
<p class="MsoNormal">As only 511KB is available from within the CD-i player, the current CD-i Link program will “underdump” these ROMs (i.e., it will omit the last 1024 bytes).<o:p></o:p></p>
<p class="MsoNormal"><b>ROM ID and release values <o:p></o:p></b></p>
<p class="MsoNormal">From the information gathered so far, it appears that
Philips has assigned the ROM ID bytes in such a way that they almost exactly
correspond to the player model / phase combinations. Within a single combination,
there can be multiple ROM releases, but these are almost always of the form 1<i>n</i>
(e.g. 1.<i>n</i>).<o:p></o:p></p>
<p class="MsoNormal">For digital video cartridges, the ROM ID bytes are always 10:11
(22ER9141) or 10 (22ER9956), and the ROM release bytes indicate the cartridge
type as described in the Interactive Engineer 96/05 article <i>Which DV
cartridge is in a 605? </i>that can be found here: <a href="http://www.icdia.co.uk/iengineer/">http://www.icdia.co.uk/iengineer/</a>.<o:p></o:p></p>
<p class="MsoNormal"><b>Detection using ROM tags<o:p></o:p></b></p>
<p class="MsoNormal">Over the last two months I have extended the rule-based CD-i detection
logic used by both CD‑i Link and CD‑i Emulator to use the ROM tag
information for player type and ROM version detection. There appears to be some
logic to the ROM ID values but it is not exact, so the ID-based detection is
still rule-based although the ROM version detection is totally automated. <o:p></o:p></p>
<p class="MsoNormal">To reflect the ID and release information, a new naming
convention for CD-i ROMs has been defined, and together with rosewood I have been gathering information for a “ROM catalogue” (see the section <b>Datfiles </b>below).<o:p></o:p></p>
<p class="MsoNormal">As an example of the new detection rules, the following is
now included in the rules file:<o:p></o:p></p>
<div style="margin-bottom: 0in; text-align: left;"><span style="font-family: "Courier New"; font-size: 10pt; line-height: 107%;">cdi220a??.rom: Philips CD-i 220 F1
system ROM ?.?<br /></span><span style="font-family: "Courier New"; font-size: 10pt; line-height: 107%;"><span style="font-size: 13.3333px;"> </span><span style="font-size: 13.3333px;">{511K} #$26 ::cdi220a.rom</span></span></div><div style="margin-bottom: 0in; text-align: left;"><span style="font-family: "Courier New"; font-size: 10pt; line-height: 107%;"><span style="font-size: 13.3333px;"><br /></span></span></div>
<div style="margin-bottom: 0in; text-align: left;"><span style="font-family: "Courier New"; font-size: 10pt;">cdi220a.rom: Philips CD-i 220 F1
system ROM<br /></span><span style="font-family: "Courier New"; font-size: 10pt; line-height: 107%;"><span style="mso-tab-count: 1;"> </span>csd_220
minimmc.brd</span></div>
<p class="MsoNormal">The first rule says that any ROM with a ROM tag at 511KB
that has a ROM ID byte with value hexadecimal 26 is a CD-i 220 F1 system ROM, with
the specific version in the ROM release byte. The <span style="font-family: "Courier New"; font-size: 13.3333px;">::cdi220a.rom </span>part means that the ROM must conform to the generic cdi220a.rom detection rule that is specified just below
it, which uses the existing module-based detection syntax.</p><p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal">The conformation requirement ensures that both detection
types remain in sync.<o:p></o:p></p>
<p class="MsoNormal"><b>ROM file names<o:p></o:p></b></p>
<p class="MsoNormal">I have extended the previously somewhat ad-hoc ROM file names
to include the ROM tag information.<o:p></o:p></p>
<p class="MsoNormal">Special logic included in the detection engine will replace
the question marks in the ROM name <span style="font-family: "Courier New"; font-size: 10pt; line-height: 107%;">cdi220a??.rom</span> and its description above with the ROM release
byte, so that a ROM with ROM ID 26 and ROM release 11 will be recognized as <span style="font-family: "Courier New"; font-size: 10pt; line-height: 107%;">cdi220a11.rom</span> with description <o:p></o:p>“Philips CD-i 220 F1 system ROM 1.1”.</p>
<p class="MsoNormal">In addition to these “short names” a “full name” has also
been defined that includes the ROM ID and ROM checksum in the filename. The
above-mentioned CD-i 220 F1 ROM happens to have checksum E620, which means that
its full name is <span style="font-family: "Courier New"; font-size: 10pt; line-height: 107%;">cdi220a11-26-E620.rom</span>.<o:p></o:p></p>
<p class="MsoNormal">For cases where two 8-bit ROM chips are used together, both
interleaved ROM tags are added to the full name. E.g., the 22ER9141 F2 VMPEG
digital video cartridge has ROM IDs 10 and 11; version 4.1 of this interleaved ROM
has the full name <span style="font-family: "Courier New"; font-size: 10pt; line-height: 107%;">vmpega41-10-11-FFD9-4BA9.rom</span>. <o:p></o:p></p>
<p class="MsoNormal">Full ROM information also includes the CRC32, MD5 and SHA-1
hashes of the ROM contents (for a 511KB ROM file, the additional 1024 empty FF bytes are included in these hashes even though the actual ROM file does not have
those bytes). These three values will now also be displayed by CD-i Link. <o:p></o:p></p>
<p class="MsoNormal"><b>CD-i Type<o:p></o:p></b></p>
<p class="MsoNormal">A new <i>CD-i Type</i> command-line program has been created
to manage collected ROM information. This program can be used to list ROM
information just like CD-i Link does, but it can do so without the hassle of dumping
the ROM.<o:p></o:p></p>
<p class="MsoNormal">Using CD-i Type, the example ROMs mentioned above would be
listed as: <o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom: 0in; margin-left: 0in; margin-right: -.5in; margin-top: 0in; margin: 0in -0.5in 0in 0in;"><span style="font-family: "Courier New"; font-size: 8pt; line-height: 107%;"><span style="mso-spacerun: yes;"> </span>File<span style="mso-spacerun: yes;"> </span>Addr<span style="mso-spacerun: yes;"> </span>Size<span style="mso-spacerun: yes;">
</span>Type<span style="mso-spacerun: yes;"> </span>Description<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 0in; margin-left: 0in; margin-right: -.5in; margin-top: 0in; margin: 0in -0.5in 0in 0in;"><span style="font-family: "Courier New"; font-size: 8pt; line-height: 107%;">------------------ -------- ------ ------------------
------------<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 0in; margin-left: 0in; margin-right: -.5in; margin-top: 0in; margin: 0in -0.5in 0in 0in;"><span style="font-family: "Courier New"; font-size: 8pt; line-height: 107%;">cdi220a.rom<span style="mso-spacerun: yes;">
</span>00000000<span style="mso-spacerun: yes;"> </span>511K cdi220a11.rom<span style="mso-spacerun: yes;"> </span>Philips CD-i 220 F1 system ROM 1.1<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 0in; margin-left: 0in; margin-right: -.5in; margin-top: 0in; margin: 0in -0.5in 0in 0in;"><span style="font-family: "Courier New"; font-size: 8pt; line-height: 107%;">cdi220a.rom<span style="mso-spacerun: yes;">
</span>00000000<span style="mso-spacerun: yes;"> </span>511K cdi220a.mdl<span style="mso-spacerun: yes;"> </span>Philips CD-i 220 F1 player<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 0in; margin-left: 0in; margin-right: -.5in; margin-top: 0in; margin: 0in -0.5in 0in 0in;"><span style="font-family: "Courier New"; font-size: 8pt; line-height: 107%;">cdi220a.rom<span style="mso-spacerun: yes;">
</span>00000000<span style="mso-spacerun: yes;"> </span>511K minimmc.brd<span style="mso-spacerun: yes;"> </span>Mini-MMC board<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 0in; margin-left: 0in; margin-right: -.5in; margin-top: 0in; margin: 0in -0.5in 0in 0in;"><span style="font-family: "Courier New"; font-size: 8pt; line-height: 107%;">cdi220a.rom<span style="mso-spacerun: yes;"> </span><span style="mso-spacerun: yes;"> </span>00000000<span style="mso-spacerun: yes;">
</span>511K cdi220a11.tag<span style="mso-spacerun: yes;"> </span>{511K} ID:
26 Rel: 11 Sum: E620<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 0in; margin-left: 0in; margin-right: -.5in; margin-top: 0in; margin: 0in -0.5in 0in 0in;"><span style="font-family: "Courier New"; font-size: 8pt; line-height: 107%;">cdi220a.rom<span style="mso-spacerun: yes;">
</span>00000000<span style="mso-spacerun: yes;"> </span>512K cdi220a11.crc<span style="mso-spacerun: yes;"> </span>CRC: FC623645<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 0in; margin-left: 0in; margin-right: -.5in; margin-top: 0in; margin: 0in -0.5in 0in 0in;"><span style="font-family: "Courier New"; font-size: 8pt; line-height: 107%;">cdi220a.rom<span style="mso-spacerun: yes;">
</span>00000000<span style="mso-spacerun: yes;"> </span>512K cdi220a11.md5<span style="mso-spacerun: yes;"> </span>MD5: D669D26A9E7228DF18E84E380F6CA6AF<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 0in; margin-left: 0in; margin-right: -.5in; margin-top: 0in; margin: 0in -0.5in 0in 0in;"><span style="font-family: "Courier New"; font-size: 8pt; line-height: 107%;">cdi220a.rom<span style="mso-spacerun: yes;">
</span>00000000<span style="mso-spacerun: yes;"> </span>512K
cdi220a11.sha1<span style="mso-spacerun: yes;"> </span>SHA1:
7DC5D62CE1686E45F2B68AA3943FE50BC47C71A7<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 0in; margin-left: 0in; margin-right: -.5in; margin-top: 0in; margin: 0in -0.5in 0in 0in;"><span style="font-family: "Courier New"; font-size: 8pt; line-height: 107%;">------------------ -------- ------ ------------------
------------<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 0in; margin-left: 0in; margin-right: -.5in; margin-top: 0in; margin: 0in -0.5in 0in 0in;"><span style="font-family: "Courier New"; font-size: 8pt; line-height: 107%;">vmpega.rom<span style="mso-spacerun: yes;">
</span>00000000<span style="mso-spacerun: yes;"> </span>128K vmpega41.rom<span style="mso-spacerun: yes;"> </span>Philips VMPEG digital video cartridge
ROM 4.1<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 0in; margin-left: 0in; margin-right: -.5in; margin-top: 0in; margin: 0in -0.5in 0in 0in;"><span style="font-family: "Courier New"; font-size: 8pt; line-height: 107%;">vmpega.rom<span style="mso-spacerun: yes;"> </span><span style="mso-spacerun: yes;"> </span>00000000<span style="mso-spacerun: yes;">
</span>128K vmpeg.dvc<span style="mso-spacerun: yes;"> </span>Philips
VMPEG digital video cartridge<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 0in; margin-left: 0in; margin-right: -.5in; margin-top: 0in; margin: 0in -0.5in 0in 0in;"><span style="font-family: "Courier New"; font-size: 8pt; line-height: 107%;">vmpega.rom<span style="mso-spacerun: yes;">
</span>00000000<span style="mso-spacerun: yes;"> </span>128K vmpega41.tag<span style="mso-spacerun: yes;"> </span>{128K} ID: 10:11 Rel: 41 Sum: FFD9:4BA9<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 0in; margin-left: 0in; margin-right: -.5in; margin-top: 0in; margin: 0in -0.5in 0in 0in;"><span style="font-family: "Courier New"; font-size: 8pt; line-height: 107%;">vmpega.rom<span style="mso-spacerun: yes;">
</span>00000000<span style="mso-spacerun: yes;"> </span>128K vmpega41.crc<span style="mso-spacerun: yes;"> </span>CRC: 3685382E<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 0in; margin-left: 0in; margin-right: -.5in; margin-top: 0in; margin: 0in -0.5in 0in 0in;"><span style="font-family: "Courier New"; font-size: 8pt; line-height: 107%;">vmpega.rom<span style="mso-spacerun: yes;"> </span><span style="mso-spacerun: yes;"> </span>00000000<span style="mso-spacerun: yes;">
</span>128K vmpega41.md5<span style="mso-spacerun: yes;"> </span>MD5:
9694C466F9B65C1990A81B7A6280546B<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom: 0in; margin-left: 0in; margin-right: -.5in; margin-top: 0in; margin: 0in -0.5in 0in 0in;"><span style="font-family: "Courier New"; font-size: 8pt; line-height: 107%;">vmpega.rom<span style="mso-spacerun: yes;">
</span>00000000<span style="mso-spacerun: yes;"> </span>128K vmpega41.sha1<span style="mso-spacerun: yes;"> </span>SHA1:
1D9C040B4FE974F5EB600C6F80797F40B45EFCF1<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-right: -0.5in;">CD-i Type is also capable of taking this information from informational text files produced by the new CD-i Link as well as itself, so that it is not
necessary to ship around ROM files to catalogue them.</p><p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal">The individual 8-bit ROM files from a ROM pair are not recognizable
by OS-9 module rules because they contain only half of each module. Instead, CD-i
Type uses the rules file to recognize them by their ROM tags and/or checksums. <o:p></o:p></p>
<p class="MsoNormal"><b>Overdumping <o:p></o:p></b></p>
<p class="MsoNormal">Although CD-i digital video cartridges contain 128KB of ROM, the sockets containing the ROM chips appear to have an unused address line. This is probably the reason that the ROM contents appear duplicated in the
CD-i player address space, causing “overdumping” by the current version of
CD-i Link. The resulting ROM files are 256KB even though the actual ROM
contents are only half that. <o:p></o:p></p>
<p class="MsoNormal">The new CD-i Link will avoid overdumping by detecting the duplication;
as a bonus this will make the dump operation faster.<o:p></o:p></p>
<p class="MsoNormal"><b>Fixing ROM dumps <o:p></o:p></b></p>
<p class="MsoNormal">There are some issues with existing CD-i Link ROM dumps
(overdumping, underdumping) and there can also be issues when ROMs are dumped
with a ROM dump device (pair splitting, byte swapping). The CD‑i Type
program can “fix up” these issues when instructed to do so with the <span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;">-fixuproms</span>
option (it will also rename ROM files in this case).<o:p></o:p></p>
<p class="MsoNormal">To correct overdumped digital video cartridge ROM files,
the CD-i Type program discards the duplicate data. <o:p></o:p></p>
<p class="MsoNormal">To correct underdumped 511KB ROM files, the CD-i Type
program adds the missing 1024 empty FF bytes.<o:p></o:p></p>
<p class="MsoNormal">To compensate for pair splitting, the CD-i Type program interleaves
the separate ROM files into the proper interleaved file usable by CD-i emulators.
For completeness, the reverse operation of splitting interleaved ROM files is
also available with the <span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;">-splitroms</span> option.<o:p></o:p></p>
<p class="MsoNormal">Finally, to correct for byte swapping, the CD-i Type program
swaps the bytes in ROM files if it detects them being swapped as indicated by a
swapped ROM tag. <o:p></o:p></p>
<p class="MsoNormal"><b>Untagged ROMs<o:p></o:p></b></p>
<p class="MsoNormal">Untagged ROM versions can still be identified by checksums
although there are no ROM IDs or clearly discernible ROM release numbers. The
actual ROM chips in fact often include that checksum on the ROM labels. For
this reason, the full name for these ROMS includes the checksum, for example <span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;">pro1000s-986D.rom</span>
for the Kyocera Pro-1000S CD-i player.<o:p></o:p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://1.bp.blogspot.com/-YZ3jlV248Eo/YF8whJSbUXI/AAAAAAAAAWE/vROESglPBh8GswOB-_BbVQ75BNAKknb5gCLcBGAsYHQ/s100/pro1000s-rom.gif" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img alt="ROM picture" border="0" data-original-height="97" data-original-width="100" src="https://1.bp.blogspot.com/-YZ3jlV248Eo/YF8whJSbUXI/AAAAAAAAAWE/vROESglPBh8GswOB-_BbVQ75BNAKknb5gCLcBGAsYHQ/s16000/pro1000s-rom.gif" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Kyocera Pro-1000S ROM<br /></td></tr></tbody></table><p class="MsoNormal"><b>Datfiles</b> </p>
<p class="MsoNormal">The final function of the CD-i Type program is cataloguing a
set of ROM (information) files in the form of an XML “datfile” bundling all the
information in a single file.<o:p></o:p></p>
<p class="MsoNormal">With the availability of such a “datfile” for CD-i ROMs it
will become possible to use ROM managers such as ClrMamePro, RomCenter and
RomVault to check CD-i ROM collections. <o:p></o:p></p>
<p class="MsoNormal">I worked with rosewood in figuring out the best way to format the CD-i ROM information into datfile entries for general use without losing information; the new “short name” and “long name” formats were tuned for this.</p><p class="MsoNormal">Typical resulting datfile entries for the above example ROMs would be:</p><p class="MsoNormal"><o:p></o:p></p>
<div style="margin-bottom: 0in; text-align: left;"><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;"><span style="mso-tab-count: 1;"> </span><game
name="cdi220a11" board="Mini-MMC"><br /></span><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;"><span style="mso-tab-count: 2;"> </span><description>CD-i
220 F1 system ROM 1.1</description><br /></span><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;"><span style="mso-tab-count: 2;"> </span><manufacturer>Philips</manufacturer><br /></span><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;"><span style="mso-tab-count: 2;"> </span><rom
name="cdi220a11-26-E620.rom" size="524288"</span></div><div style="margin-bottom: 0in; text-align: left;"><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;"><span> </span><span> </span><span> </span>crc="FC623645"</span></div><div style="margin-bottom: 0in; text-align: left;"><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;"><span style="mso-tab-count: 3;"> </span><span style="mso-tab-count: 2;"> </span>md5="D669D26A9E7228DF18E84E380F6CA6AF"<br /></span><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;"> sha1="7DC5D62CE1686E45F2B68AA3943FE50BC47C71A7"/><br /></span><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;"><span style="mso-tab-count: 1;"> </span></game></span></div>
<p class="MsoNormal">and</p><p class="MsoNormal"><o:p></o:p></p>
<div style="margin-bottom: 0in; text-align: left;"><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;"><span style="mso-tab-count: 1;"> </span><game
name="vmpega41" board="VMPEG"><br /></span><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;"><span style="mso-tab-count: 2;"> </span><description>VMPEG
digital video cartridge ROM 4.1</description><br /></span><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;"><span style="mso-tab-count: 2;"> </span><manufacturer>Philips</manufacturer><br /></span><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;"><span style="mso-tab-count: 2;"> </span><rom
name="vmpega41-10-11-FFD9-4BA9.rom" size="131072"</span></div><div style="margin-bottom: 0in; text-align: left;"><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;"> crc="3685382E"<br /></span><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;"> md5="9694C466F9B65C1990A81B7A6280546B"<br /></span><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;"> sha1="1D9C040B4FE974F5EB600C6F80797F40B45EFCF1"/><br /></span><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;"><span style="mso-tab-count: 1;"> </span></game></span></div>
<p class="MsoNormal">With this input, the above ROM managers will put each ROM file
inside a folder or archive using the short name while the ROM file inside will
use the full name.</p><p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal">For example, the following ZIP files would be produced using
maximum compression: <o:p></o:p></p>
<div style="margin-bottom: 0in; text-align: left;"><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;">Archive:<span style="mso-spacerun: yes;"> </span>cdi220a11.zip<br /></span><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;"><span style="mso-spacerun: yes;"> </span>Length<span style="mso-spacerun: yes;">
</span>Method<span style="mso-spacerun: yes;"> </span>Size<span style="mso-spacerun: yes;"> </span>Cmpr<span style="mso-spacerun: yes;">
</span>Date<span style="mso-spacerun: yes;"> </span>Time<span style="mso-spacerun: yes;"> </span>CRC-32<span style="mso-spacerun: yes;">
</span>Name<br /></span><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;">--------<span style="mso-spacerun: yes;"> </span>------<span style="mso-spacerun: yes;">
</span>------- ---- ---------- ----- --------<span style="mso-spacerun: yes;">
</span>----<br /></span><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;"><span style="mso-spacerun: yes;">
</span>524288<span style="mso-spacerun: yes;"> </span>Defl:X<span style="mso-spacerun: yes;"> </span>230291<span style="mso-spacerun: yes;">
</span>56% 2021/03/14 00:04 fc623645<span style="mso-spacerun: yes;">
</span>cdi220a11-26-E620.rom<br /></span><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;"><o:p> <br /></o:p></span><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;">Archive:<span style="mso-spacerun: yes;"> </span>vmpega41.zip<br /></span><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;"><span style="mso-spacerun: yes;"> </span>Length<span style="mso-spacerun: yes;">
</span>Method<span style="mso-spacerun: yes;"> </span>Size<span style="mso-spacerun: yes;"> </span>Cmpr <span style="mso-spacerun: yes;"> </span>Date<span style="mso-spacerun: yes;">
</span>Time<span style="mso-spacerun: yes;"> </span>CRC-32<span style="mso-spacerun: yes;"> </span>Name<br /></span><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;">--------<span style="mso-spacerun: yes;"> </span>------<span style="mso-spacerun: yes;">
</span>------- ---- ---------- ----- --------<span style="mso-spacerun: yes;">
</span>----<br /></span><span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;"><span style="mso-spacerun: yes;">
</span>131072<span style="mso-spacerun: yes;"> </span>Defl:X<span style="mso-spacerun: yes;"> </span>42344<span style="mso-spacerun: yes;">
</span>68% 2021/03/14 00:04 3685382e<span style="mso-spacerun: yes;">
</span>vmpega41-10-11-FFD9-4BA9.rom</span></div>
<p class="MsoNormal">Notice that the CRC-32 of each ROM file inside the ZIP
archive matches the CRC-32 values listed above; this is by design as the exact
same algorithm is used.</p><p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal">Given the above information, the ClrMamePro ROM manager is in
some cases also capable of “fixing up” the issues with ROM dumps
mentioned above. In an ideal world, it would not be necessary to use the command-line
CD-i Type program for this but that is not currently the case.<o:p></o:p></p>
<div style="text-align: left;">To avoid confusion, both CD-i Type and CD-i Emulator will be
extended to support this new folder/archive way of storing ROM files inside the <span style="font-family: courier; font-size: medium;">rom</span> folder.</div><p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><b>Release timing<o:p></o:p></b></p>
<p class="MsoNormal">The new and updated CD-i programs will be released together with
the new CD-i ROMs datfile <span style="font-family: "Courier New"; font-size: 9pt; line-height: 107%;">cdiroms.dat</span>; at that time, the CD-i Emulator
Home website at <a href="http://www.cdiemu.org/">http://www.cdiemu.org</a> will
also be extended with a CD-i ROMs page that contains the collected information in
browsable form.<o:p></o:p></p>
<p class="MsoNormal">The actual ROM files themselves are copyrighted and will not
be available.<o:p></o:p></p>
</div><div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-fQPI7xdiTOg/YF5hL4CGQ5I/AAAAAAAAAVs/sFwaRysxSno94udoK8UXHu8epu7931LzgCLcBGAsYHQ/s110/byebye.gif" style="margin-left: 1em; margin-right: 1em;"><img alt="Dimo says hi" border="0" data-original-height="98" data-original-width="110" src="https://1.bp.blogspot.com/-fQPI7xdiTOg/YF5hL4CGQ5I/AAAAAAAAAVs/sFwaRysxSno94udoK8UXHu8epu7931LzgCLcBGAsYHQ/s16000/byebye.gif" /></a></div><br />CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com0tag:blogger.com,1999:blog-4867024730231313742.post-7911480803284182762021-03-11T21:22:00.002+01:002023-05-13T21:15:12.156+02:00Why is CD-i emulation hard, or isn't it?<p><span style="font-family: inherit;">Recently, it has been argued on Reddit, Twitter and elsewhere
that CD-i emulation in MAME is difficult and why this is unlikely to improve in
the foreseeable future.</span></p><p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family: inherit;">The main reasons given (paraphrased) are that</span><o:p></o:p></p>
<p class="MsoListParagraphCxSpFirst" style="margin-left: 0.25in; mso-add-space: auto; mso-list: l0 level1 lfo1; text-indent: -0.25in;"><!--[if !supportLists]--><span style="font-family: inherit;"><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;">a)<span style="font-size-adjust: none; font-stretch: normal; font: 7pt "Times New Roman";">
</span></span></span><!--[endif]-->there are different hardware implementations of
the CD-i platform, and</span><o:p></o:p></p>
<p class="MsoListParagraphCxSpMiddle" style="margin-left: 0.25in; mso-add-space: auto; mso-list: l0 level1 lfo1; text-indent: -0.25in;"><!--[if !supportLists]--><span style="font-family: inherit;"><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;">b)<span style="font-size-adjust: none; font-stretch: normal; font: 7pt "Times New Roman";">
</span></span></span><!--[endif]-->applications do not directly interact with that
hardware but are mediated by the BIOS, therefore</span><o:p></o:p></p>
<p class="MsoListParagraphCxSpLast" style="margin-left: 0.25in; mso-add-space: auto; mso-list: l0 level1 lfo1; text-indent: -0.25in;"><!--[if !supportLists]--><span style="font-family: inherit;"><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;">c)<span style="font-size-adjust: none; font-stretch: normal; font: 7pt "Times New Roman";">
</span></span></span><!--[endif]-->hardware access patterns look identical across
the entire library of applications.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family: inherit;">The conclusion from this is that</span><o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left: 0.25in; mso-add-space: auto; mso-list: l0 level1 lfo1; text-indent: -0.25in;"><!--[if !supportLists]--><span style="font-family: inherit;"><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="mso-list: Ignore;">d)<span style="font-size-adjust: none; font-stretch: normal; font: 7pt "Times New Roman";">
</span></span></span><!--[endif]-->an emulator developer cannot “more clearly infer
certain subtleties of the hardware functionality”.</span><o:p></o:p></p>
<p class="MsoNormal"></p><p class="MsoNormal" style="-webkit-text-stroke-width: 0px; color: black; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decoration-color: initial; text-decoration-style: initial; text-decoration-thickness: initial; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"><o:p></o:p></p><p></p><p style="-webkit-text-stroke-width: 0px; color: black; font-style: normal; font-variant-caps: normal; font-variant-ligatures: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decoration-color: initial; text-decoration-style: initial; text-decoration-thickness: initial; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"><span style="font-family: inherit;"><b>Note:</b><span> </span>This article uses the term “<i>BIOS</i>” for what I have called “<i>CD-i system ROM</i>” in the past. The latter is more descriptive, but the former appears to be what many other emulators use.</span></p><p class="MsoNormal"><span style="font-family: inherit;">Some parts of the CD-i hardware are custom chips for which not
much or only very skimpy documentation is available, some reverse engineering is
therefore required. But is it really hard?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family: inherit;">One of the ways to reverse engineer hardware is to look at
the software that uses it. There are various ways of doing that, the classic MAME
way is to look at the access patterns and the code immediately surrounding
that. If you have a sufficient variety of accessing code, you will ultimately
develop a good (emulated) approximation of the original hardware, by a sometimes lengthy process of trial and error. If this is
your goal, the fact that all accesses go through the BIOS can indeed be a
problem.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family: inherit;">But is having such a good approximation actually necessary
to have a working emulator? If every application can directly access the hardware, as typical for most consoles, certainly. But this is not the case
for CD-i!</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family: inherit;">The fact that all CD-i specific hardware access is through
the BIOS is actually an opportunity when viewed in the right light. It is not
necessary to develop a generic “good” approximation of the hardware, the only
thing that is needed is an approximation “good enough” for the BIOS!</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family: inherit;">Now, this goes against the stated goals of the MAME project which
is actually *not* to produce a working emulator but to document the hardware
legacy. From mamedev.org, right at the top:</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left: 0.5in;"><i><span style="font-family: inherit;">MAME’s purpose is to preserve
decades of software history […] by documenting the hardware and how it
functions. The source code to MAME serves as this documentation. The fact that
the software is usable serves primarily to validate the accuracy of the
documentation.</span></i><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family: inherit;">Seen in this light, so-called “high-level emulation”
(emulating the visible effects of hardware instead of the actual inner
workings) is akin to blasphemy: it goes against the entire philosophy of MAME.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family: inherit;">My own goal in developing CD-i Emulator was never to “<i>document
the hardware</i>”, though. It was to have a good enough emulation to <i>actually
play CD-i discs</i>. For this, it is technically not even necessary to emulate
*any* existing CD-i specific hardware, as CD-i is basically a software API standard.
If you have a correct implementation of that standard you are done (there are
of course some complications).</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family: inherit;">It is interesting to note that CD-Ice, the first ever
(public) CD-i emulator, did exactly this. The author used his knowledge of the
CD-i specification (Green Book) to implement the API from scratch using his
source code for “Rise of the Robots” as a working sample. Although often treated
as a single-game emulator, this is not in fact correct as his emulator ran many
other games as well.</span></p><p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family: inherit;">The Green Book states that CD-i players run the CD-RTOS
operating system using an “68000-family processor”. This is therefore the minimum
amount of *actual* hardware that needs emulation, and it’s exactly what CD-Ice
did. All other parts were implemented based on the specification and not on actually
existing hardware.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family: inherit;">Going the full HLE route like CD-Ice did has its own
problems of course, mostly because CD‑RTOS incorporates significant parts of the
OS‑9/68000 operating system and a full emulator would therefore need to implement
that as well. Some features such as multitasking and interrupts can be
particularly hard to tackle with a full HLE strategy. Using full HLE also
reintroduces the “many access patterns” issue but on a different level. Since you
are emulating the (software) interface against which developers work directly,
you can only get it “good enough” by throwing lots of applications against it.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family: inherit;">For all these reasons, I chose a different approach
for CD-i Emulator. Knowing that fully implementing CD-RTOS would be hard, I
wanted to use the existing BIOS software. This meant that I would have to emulate
some hardware, <i>but only to the extent that the BIOS uses it</i>. And I would
not just stare at access patterns and the immediately surrounding (disassembled)
BIOS code but take a more holistic approach as described below. Of course, it
also meant that I would need to emulate all the hardware versions, which in
retrospect has been more work than expected but not intrinsically hard.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family: inherit;">All the CD-i specific hardware accesses done by the BIOS are
located in OS-9 driver modules which together are less than 20% of a typical BIOS
(counted by module size in bytes). And significantly more then half of that is
the video driver, mostly taken up with drawing code that is totally
uninteresting from the emulation point of view. All in all, only about 5% of
the BIOS is concerned with accessing CD‑i hardware, which is about 25KB of
68000 machine language, i.e. less than 10 000 lines of machine code.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family: inherit;">The interesting thing about these drivers is that their service
interface is specified in the Green Book. Starting from this documented
interface you can infer at a high level what the hardware is supposed to be doing
as a consequence of all the device register accesses done by the BIOS. Actually
figuring out the functions of the individual device bits does require
disassembling the drivers and tracing their logic and dataflow but with a symbolic
disassembler that is doable.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family: inherit;">Most drivers are (much) less than 2KB of machine language,
meaning that the path between the documented software interface and the to-be-emulated
hardware is typically less than a few hundred or so lines of machine code. This
is not hard to trace through.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family: inherit;">The only driver size exceptions are the Video driver and the
CD+Audio driver. The <i>video </i>driver totals about 65KB of machine code but
as said above most of that drawing code not relevant for hardware emulation.
Moreover, the video hardware is actually fully documented starting from the
Mono-I hardware revision which uses the Motorola MCD212 VDSC chip. Earlier hardware
revisions utilize two Philips SCC66470 VSC chips that are also documented and a
back-end processor that is technically undocumented but whose functional
aspects follow completely from the VSC documentation and the Green Book specifications.
So the Video driver is not a major hurdle.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family: inherit;">That leaves the CD+Audio driver, arguably the most complex
driver of the entire CD-i system. The size of this driver module varies
somewhat with the actual chipset used (about 18KB for CDIC, 26KB for DSP and 20KB
for CIAP, in all cases excluding downloaded microcode). There is some uninteresting
stuff such as EDC/ECC error correcting code in there but most of this driver is
actually relevant to emulating the hardware. This driver is therefore the
single biggest stumbling block to good CD-i emulation, and it shows in the
kinds of bugs and issues that CD-i emulators have.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family: inherit;">The fact that the CD+Audio hardware actually has three different
versions (in Philips hardware alone, non-Philips players use yet another few versions)
makes proper emulation of all player models more work but not much harder, it
helps that the actual drivers are descended from each other. Once you have a
good understanding of <i>cdapdriv</i> (CDIC), it is not that hard to understand
<i>dspdriv</i> (DSP) or <i>ciapdriv</i> (CIAP): the major structure is the
same, only the details of driving the hardware differ.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family: inherit;">All of the above is predicated on understanding drivers, i.e.
*software*, not *hardware*. It therefore goes somewhat against the grain for
MAME which has traditionally followed a hardware-centric view. Also, a
relatively deep understanding of the Green Book and parts of OS-9 is required.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family: inherit;">Given those prerequisites I would not say that CD-i emulation
is hard. It is a lot of work, sure; getting a good emulation requires deep study
of a few thousand lines of 68000 assembly language. But very doable.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family: inherit;">The approach used by CD-i Emulator as outlined above also
explains why I am not interested in non‑HLE emulation of the various
microcontrollers and DSP chips. It serves no purpose in playing CD-i discs:
getting good HLE emulations of these chips so the BIOS can do its thing is enough.
As a not insignificant side bonus to this, no chip decapping or other exotic
hardware exercises are required for this approach.</span></p>CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com1tag:blogger.com,1999:blog-4867024730231313742.post-73598949589521428732018-05-21T02:33:00.001+02:002018-05-21T02:33:50.666+02:00CD-i updateOver the last few days I did some CD-i website updates.<br />
<br />
On the CD-i Emulator website <a href="http://www.cdiemu.org/">http://www.cdiemu.org</a> I added lots of hardware pictures taken in August of last year. These include an extensive series about my (then) new 180/181/182 authoring player set and some overview pictures of the FW380i player and my E1/E2 emulator hardware. I have many more pictures of the internals of those emulators but these still need adding. I also added some more serial number information, especially from the DV cartridges. Some of the pictures of those appear to be mixed up a bit and will need sorting out.<br />
<br />
I also started creating a Books section to list all my hardcopy documentation, as part of an effort to scan some of it to create digital versions where needed, but that is not yet online.<br />
<br />
The end goal here is to get everything that could possibly be needed by a CD-i title developer online in a single place. This effort started in July 2017 when I took over editorial maintenance of the ICDIA website at <a href="http://www.icdia.co.uk/">http://www.icdia.co.uk</a> from Devin. We had decided that the CD-i Emulator site was not the right place to put general CD-i documentation and the ICDIA site seemed a much better fit. And Devin was looking for a new ICDIA editor anyway, so... <br />
<br />
As my first action on the ICDIA website I added the CD-i Full Functional Specification (Green Book). It had already been online for years but was not very easy to find. Next followed some more Microware OS-9 documentation (in particular the Allen-Bradley set) that was also already online, and today many service manuals (repair instructions including board and circuit diagrams) were added.<br />
<br />
A start has also been made with adding authoring documentation, but much more of that still needs to be added. My hard disk contains a number of raw scans from last year that still need to be processed and put online. In particular, this includes the CD-I System Libraries Technical Reference Manual that contains C bindings for all the CD-i specific CD-RTOS functions described in the Green book; this information is an absolute must to have for any serious developer.<br />
<br />
Devin has been sitting on a complete set of CD-i Technical Notes for developers for a long time; this needs to be scanned and put online also (so far he has only done a very limited subset of it). These notes document many intricacies of the CD-i system and can be very insightful for title developers<br />
<br />
It has now been a very long time since I put anything on this blog, but this does not mean that CD-i related software development has stopped. However, it has slowed down considerably. Below is a very short (and unordered) list of my CD-i development related activities in the 7 years since I last posted here; most of these I will probably expand on in the future.<br /> <br />- handling of CD-i Emulator beta time limit expiry<br />- emulation and deconstruction of The 7th Guest for the 20th anniversary edition<br />- leveraging CD-i Emulator code for a homebrew project<br />- investigation of possible Android and SDL ports of CD-i Emulator<br />- restructure of CD-i Emulator video decoding for flexibility and performance<br />- investigation of current status of Microware CD-i build tools<br />- investigation of existing OS-9 ports of the GNU C/C++ compiler<br />- investigation of restructuring CD-i Emulator MPEG decoding to fix buffering issues<br />- substantive efforts at ROMless emulation for CD-i Emulator (promising but not finished)<br />- reaching out in an attempt to collect more CD-i player ROMs<br />
<br />
Regarding the last item, from the Philips consumer player line I’m still missing ROMs from the CDI 210/00, CDI 210/60, CDI 220/80, CDI 380/00 and CDI 740/20 players. If anybody has one of these players, please contact me.<br />
<br />
I’m also interested in more exotic players like the Philips CDI 602, CDI 604, CDI 610, CDI 611 and of course a number of non-Philips players, in particular the Bang & Olufsen BeoCenter AV5. For some of these there are possible acquisition routes, but it requires bugging people about them and that can only be done some much.<br />
<br />
Last year I also acquired a Kyocera Pro 1000S player that so far hasn’t given up its ROM contents (the player is incredibly densely packed internally, but there appears to be a serial extension port that could be usable), and I’m also still looking for the SONY IVO player ROMs. If nothing else works, it should be possible to play out the ROM contents of these players as audio.<br />
<br />
There are also many future projects that I’m still interested in; a new one as of today is getting the built-in service tests of the Mini-MMC and Mono-I players working as documented in the service manuals. These tests need a special Service PCB connected to the serial port that has only three buttons (TEST, YES, NO) and an 8-position 7-segment LED display. Part of these tests is probably run by the SLAVE processor, but ROM contents for this processor have recently become available from the MESS dumping efforts so there appears to be a possible route. It would require implementing 6805 processor emulation but that shouldn’t be that hard, this is a relatively simple and well-documented 8-bit microprocessor.<br />
<br />
Having made a promising start with ROMless emulation (in particular, mostly working C++ versions of the video and pointer device drivers and a good setup to start developing C++ versions of the kernel and remaining drivers and file managers), it appears worthwhile to pursue this path as well. It would make the (apparently) holy grail of CD-i emulation a possibility (no need for copyrighted player ROM contents, just the disc images) and would open up a path to re-releasing CD-i titles on other platforms without ROM rights issues (several title rights-owners have contacted me about this in the last few years). If done right (which I’m trying), it would even allow a rebuild of the CD-RTOS software from the C++ versions by compiling them with an OS-9 C++ compiler (GNU C++ comes to mind). Of course, this would not be the “authentic” CD-i experience but it would allow playing of supported titles (eventually, this should be most of them).<br />
<br />
It would also be interesting to make more progress towards an SDL port of CD-i Emulator. The main structural barrier to this has already been removed; the CD-i video emulation used to be hardcoded for producing 24-bit Windows-compatible RGB format. This has now been replaced by more generic pixel-format-parameterized pixel generation code that can efficiently produce any RGB format fitting in 32 bits, as required by SDL; in the process also achieving some decoding performance improvement (in particular, more optimized region processing). A faceless SDL emulation (no GUI) should now not be very hard anymore; at some point an SDL-based GUI or perhaps a native Android / iOS / MacOS GUI could then be added.<br />
<br />
So there’s still lots of work to do…CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com1tag:blogger.com,1999:blog-4867024730231313742.post-34586486604327248462011-11-07T01:26:00.002+01:002011-11-07T01:47:14.316+01:00JNMS and Maxi-MMC updatesThis weekend I fixed some disc emulation issues for the JNMS and Maxi-MMC boards. I had previously erroneously identified these two boards but they are different.<br /><br />The JNMS board is the one in the CDI 180 player (also called the JNMS player). It is not used in any other player and contains a CDIC (CD Interface Controller) chip but no SLAVE processor.<br /><br />The Maxi-MMC board is the one in the CDI 601 and 602 players. From the emulation point of view it is virtually identical to the Mini-MMC board used by the CDI 605 player, but it has a different CDIC chip version. Both boards contain a SLAVE processor.<br /><br />The link between the JNMS and Maxi-MMC boards is the CDIC chip: both turn out to have the same older CDIC chip version that differs in a few details from the version used on the Mini-MMC and Mono-I boards players (I described these differences in the earlier “CD-i 180 disc playing” post).<br /><br />I noticed the JNMS / Maxi-MMC link from the CD-i player type table in the July 1996 issue of The Interactive Engineer (it’s on the ICDIA site); turns out I had misinterpreted the Board column on page 4 (there’s also an error there: the 601/602 certainly do not have the 180 board!).<br /><br />After noticing this I did some testing and it turns out that the CDIC modifications needed for the 180 also work for the 601, including the TOC reading problem.<br /><br />I have yet to find a way to get chip version information from the CDIC chip itself, so for the time being I’ve keyed the differences on the SLAVE software version. The 180 has no such chip, the 601 has version 1.x where the 605 has version 3.x. For now I’ve assumed that version 2.x also uses the older CDIC chip, but that may be wrong (the 602 or 604 might be interesting test cases).<br /><br />Having done that, I did some more digging into the TOC read issue. It turns out that the 601 ROM performs CRC validation on the subcode Q data from the lead-in area (which is where the TOC is stored), and CD-i Emulator didn’t provide a valid CRC (no other ROMs I’ve seen so far validate this in software). The ROM even has compensation for shifts of between 1 and 7 bits in the incoming subcode Q data, probably because of some hardware timing issue.<br /><br />I also noticed a bug in the ROM: it always uses the first sector buffer because it takes the current buffer bit from the wrong memory location. Not that this really matters because the TOC data is repeated multiple times; half of the repetitions will always land in the first buffer anyway. The bug is fixed in the 605 ROM.<br /><br />Generating a valid CRC turned out to be straightforward (it’s just a simple CRC-CCITT calculation), but the ROM wouldn’t recognize it! After some head scratching I focused on the ROXL instruction (Rotate Left with Extend) used in the validation code. It is quite an esoteric instruction; could it be that there was an emulation bug here? It turns out that there was indeed; during rotation the contents of the X flag where put in the wrong bit. After fixing this the ROM properly recognized the data and the TOC reads became just as quick as other player models.<br /><br />In search of version information for the CDIC chip I looked at the emulations and found one potential point of interest: the release number displayed by the service shell. This is a special GUI shell that performs some service functions; you can get to it by inserting a specially wired test plug into input port 1.<br /><br />After some digging I found that the service shell obtains this number from the SLAVE processor, so it probably does not directly correspond to a CDIC version. The number does appear to differ from other version numbers, though, at least on my two 605 players.<br /><br />The service shell obtains this number using two special I$SetStt calls into the CDIC driver; extending CD-i Link to remotely perform these same calls was easy. The new <b>-cds[tatus]</b> option can now be used to make the special calls. Here's some representative output of the <b>-cds A3</b> option:<br /><br /><code>CD status A3000000 -> A3320000</code><br /><br />Extending CD-i Link with remote OS9 calls is actually a fairly easy way to perform some information and tracing actions; I will probably use it for sorting out other dangling issues in the near future. When possible, this technique avoids the problems of writing a fullblown memory-resident trace module.<br /><br />A new public beta release of CD-i Emulator that has full JNMS and Maxi-MMC support (among other things) is scheduled before the end of this year; there are still a few other issues that need sorting out first. This release should also have better support for the PCDI board used by several portable players, including the CD-i 370.<br /><br />The major player holes still remaining are the Sony IVO-10/11 players, the Kyocera player, the Bang&Olufsen TV/player combi and of course the I2M board. There is some perspective for all of these but they are not high priority; except for the latter I expect all of them to be minor hardware variations of existing boards.<br /><br />The I2M board has the interesting feature that it has multiple "ROMs" downloaded from the PC software (which is available for download from ICDIA); it also has a very different way of reading from CD as this is handled by the PC. As a consequence of this, audio is probably also handled differently. I have this board booting to a blue screen where it hangs on host communication.CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com1tag:blogger.com,1999:blog-4867024730231313742.post-50279814069202439752011-10-11T00:57:00.008+02:002021-02-08T11:30:08.166+01:00SCSI support and a big surpriseLast week I added SCSI disk support for the CD-i 60x extension board to CD-i Emulator. It took somewhat longer then I expected, though. This was mostly because the DP5380 SCSI controller chip exposes most low-level details of the SCSI protocol to the driver which means that all of these details have to be emulated.<div><br /></div><div>The emulation ended up to be a more-or-less complete software implementation of the parallel SCSI-2 protocol, including most of the low-level signaling on the BSY, SEL, ATN, MSG, C/D-, I/O-, REQ and ACK lines. This is all implemented by the new CScsiBus class representing the SCSI bus that connects up to 16 instances of the CScsiPort class that each represent a single SCSI-2 bus interface. I was able to mostly avoid per-byte signaling of REQ and ACK if the target device implementation supports block transfers, a big performance win.</div><div><br /></div><div>The new CCdiScsiDevice class emulates the DP5380 controller chip, working in conjunction with the CCdiScsiRamDevice and CCdiScsiDmaDevice classes that emulate the 32 KB of local extension SRAM and the discrete DMA logic around it that are included on the CD-i 60x extension board.</div><div><br /></div><div>The CD-i 182 extension uses a compatible SCSI controller chip but a different DMA controller and has no local extension SRAM. I have not yet emulated these because I have almost no software to test it. </div><div><br /></div><div>The new CScsiDevice class implements a generic SCSI device emulating minimal versions of the four SCSI commands that are mandatory for all SCSI device types: TEST UNIT READY, REQUEST SENSE, INQUIRY and SEND DIAGNOSTIC. It implements most of the boiler-plate of low-level SCSI signaling for target devices and the full command and status phases of SCSI command processing, allowing subclasses to focus on implementing the content aspects of the data transfer phase.</div><div><br /></div><div>The CScsiFile class emulates a SCSI device backed by a file on the host PC; it includes facilities for managing the SCSI block size and the transfer of block-sized data to and from the backing file.</div><div><br /></div><div>The CScsiDisk and CScsiTape classes emulate a SCSI disk and tape device, respectively, currently supporting a block size of 512 bytes only. Instances of these classes are connected to the SCSI bus by using the new<br />-s[csi]d[isk][0-7] FILE and -s[csi]t[ape][0-7] FILE options of CD-i Emulator.</div><div><br /></div><div>The CD-i 60x extension board normally uses SCSI id 5; the built-in ROM device descriptors for SCSI disks use SCSI ids starting at zero (/h0 /h1 /h2) while the built-in device descriptor for a SCSI tape uses SCSI id 4 (/mt0). This means that the useful options with the 60x are -scsidisk0, -scsidisk1, -scsidisk2 and -scsitape 4.</div><div><br /></div><div>I've added the new dsk subdirectory to contain disk images; tape images have no standard location as they are mostly intended for bulk-transfer purposes (see below).</div><div><br /></div><div>Inside the CD-i player this leads to the following response to the built-in inquire command: <pre>$ inquire -i=0<br />vendor identification:"CDIFAN CDIEMU SCSIDISK "<br /> <br />$ inquire -i=4<br />vendor identification:"CDIFAN CDIEMU SCSITAPE "</pre> where the "CDIFAN " part is the vendor name and the "CDIEMU SCSIXXXX " part is the product name.</div><div><br /></div><div>In the previous post I described a 450 MB OS-9 hard disk image that I found on the Internet. After mounting it with<br />-scsidisk0 mw.dsk I got the following output: <pre>$ free /h0<br />"MediaWorkshop" created on: Feb 17, 1994<br />Capacity: 1015812 sectors (512-byte sectors, 32-sector clusters)<br />674144 free sectors, largest block 655552 sectors<br />345161728 of 520095744 bytes (329.17 of 496.00 Mb) free on media (66%)<br />335642624 bytes (320.09 Mb) in largest free block<br /> <br />$ dir -d /h0<br /><br />Directory of /h0 23:49:36<br />ASU/ AUDIO/ CDI_BASECASE/ CINERGY/ CMDS/<br />COPY/ CURSORS/ DEFS/ DEMOS/ ENET/<br />ETC/ FDRAW/ FONTS/ FontExample/ ISP/<br />LIB/ MAUI/ MAUIDEMO/ MENU/ MWOS/<br />NFS/ README_CIN README_MWS SCRIPT/ SHARE/<br />SHIP/ SYS/ T2D_RUNTIME/ TEMP/ TEMPMARK/<br />TEST/ USR/ VIDEO/ abstract.txt bibliographic.txt<br />bkgd.c8 bkgd.d cdb cdb1 cdb2<br />cdi_opt_install chris_test cin copyright.mws copyright.txt<br />csd_605 custominits_cin delme dos/ file<br />font8x8 get globs.mod go go.mkfont<br />inetdb ipstat kick1a_f.c8 kick2a_f.c8 mtitle<br />mws net new_shell new_shell.stb scratch<br />screen startup_cin thelist </pre>You can see why thought it was a MediaWorkshop disc, but on closer inspection this turned out to something quite different. Some basic scrutiny lead to the hypothesis that this is probably a disk backup of someone from Microware working on early development of the DAVID (Digital Audio Video Interactive Decoder) platform. There are various surprises on the disk which I will describe below.</div><div><br /></div><div>Anyway, I wanted to transfer the contents to the PC as a tar archive, similar to the procedure I used for my CD-i floppy collection. After starting CD-i Emulator with a -scsitape4 mw.tar option this was simply a matter of typing the following into the terminal window: <pre>tar cb 1 /h0</pre> This command runs the "tape archiver" program to create a tape with the contents of the /h0 directory, using a tape blocking size of 1 (necessary because my SCSI tape emulation doesn't yet support larger block sizes). The resulting mw.tar file on the PC is only 130 MB, not 450 MB which indicates that the disk is mostly empty. At some point I might use an OS-9 "undelete" program to find out if there are additional surprises.</div><div><br /></div><div>Extracting the mw.tar file was now a simple matter of running the PC command <pre>tar xvf mw.tar</pre> This produced an exact copy of the OS-9 directory structure and files on the PC.</div><div><br /></div><div>Many of the directories on the hard disk are clearly copies of various distribution media (e.g. CDI_BASECASE, CINERGY, CURSORS, ENET, FONTS, ISP, MWOS, NFS). The contents of the ENET, ISP and NFS directories at first appear to match some of my floppies, including version numbers, but on closer inspection the binaries are different. Running some of them produces "Illegal instruction" errors so I suspect that these are 68020 binaries.</div><div><br /></div><div>The SHIP directory contains some prerelease RTNFM software; the readme talks about PES which is a type of MPEG-2 stream (Packetized Elementary Stream). Various asset directories contain versions of a "DAVID" logo.</div><div><br /></div><div>The CMDS directory contains working versions of the Microware C compiler, identical to the ones I already had and also many other programs. It also contains some "cdb" files (configuration database?) that mention the 68340 processor.</div><div><br /></div><div>The contents of the CMDS/BOOTOBJS directory produced a first surprise: it contains a subdirectory JNMS containing among others files named "rb1793" and "scsijnms". Could this be floppy and SCSI drivers for the CD-i 182 extension, as it contains with a 1793 floppy drive controller (the CD-i 60x uses a different one) and the player has a "JNMS" serial number?</div><div><br /></div><div>Well, yes and no. Disassembly of the scsijnms file proved it to be compiled C code using an interface different from OS-9 2.4 drivers, so I suspect this is an OS-9 3.x driver. In any case, I cannot use it with the stock CD-i 180 player ROMs. Bummer...</div><div><br /></div><div>And now for the big surprise: deeply hidden in a directory structure inside the innocently named COPY directory is the complete assembly source for the VMPEG video driver module "fmvdrv". At first glance it looked very familiar from my disassembly exercises on the identically-named Gate Array 2 MPEG driver module "fmvdrv", which is as expected because I had already noticed the large similarity between these two hardware generations.</div><div><br /></div><div>The source calls the VMPEG hardware the "IC3" implementation, which matches CD-i digital video history as I know it. The Gate Array MPEG hardware would be "IC2" and the original prototype hardware would be "IC1". Furthermore, the sources contain three source files named fmvbugs1.a to fmvbugs3.a whose source file titles are "FMV first silicon bugs routines" to "FMV third silicon bugs routines". The supplied makefile currently uses only fmvbugs3.a as is to be expected for a VMPEG driver.</div><div><br /></div><div>The fmvbugs1.a source contains some of the picture buffer manipulation logic that I've so far carefully avoided triggering because I couldn't understand it from my disassemblies, and this is now perfectly understandable: they are workarounds for hardware bugs!</div><div><br /></div><div>As of two hours ago, I have verified that with a little tweaking and reconstruction of a single missing constants library file these sources produce the exact "fmvdrv" driver module contained in the vmpega.rom file directly obtained from my VMPEG cartridge.</div><div><br /></div><div>In general these sources are very heavily commented, including numerous change management comments. They also include a full set of hardware register and bit names, although no comments directly describing the hardware. This should be of great help in finally getting the digital video emulation completely working.</div><div><br /></div><div>All of the comments are English, although a few stray words and developer initials lead me to believe that the programmers were either Dutch or Belgian.</div><div><br /></div><div>Disassembly comparisons lead me to the conclusion that careful undoing of numerous changes should result in exact sources for the GMPEGA2 driver module "fmvdrv" as well. I might even do it at some point, although this is not high priority for me.</div><div><br /></div><div>The disk image containing all of these surprises is publicly available on the Internet since at least 2009, which is probably someone's mistake but one for which I'm very grateful at this point!</div>CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com0tag:blogger.com,1999:blog-4867024730231313742.post-4805257117235988732011-10-05T00:37:00.003+02:002011-10-05T00:46:51.031+02:00CD-i floppy inventoryLast weekend I future-proofed my CD-i floppy collection. A bit to my surprise, all floppies except one turned out to be perfectly readable (nearly twenty years after they were last written!). Luckily, the one exception was a backup copy so I didn’t lose any contents.<br /><br />I had originally intended to use the borrowed CDI 182 unit for this (it has two floppy drives). The primary motivation for this was that my unstowed CDI 605 could not read beyond track zero of any floppy, but after giving the matter some thought I decided to try my other CDI 605 first, the primary motivation for this being speed (see below). It turned out that this 605 could read the floppies perfectly, including the three 38U0 format ones that gave problems on the 182 unit. Microware has defined a number of OS-9 disk formats for floppies, the 38U0 one supposedly being the “universal” 3.5" format (there is also a 58U0 “universal” 5¼" format).<br /><br />The problem with the “universal” formats is that track zero can be (and on my floppies, is) in a different density which makes it a bad fit for most tools, both on CD-i and PC. It also means that only 79 tracks are used for data storage, giving a raw capacity of 79 × 2 × 16 × 256 = 632 KB. The 3803 format used by all my other CD-i floppies uses all 80 tracks and consequently has 8 KB more of raw storage for a total of 640 KB (these are both double-density, double-side formats (DS, DD) with 16 sectors of 256 bytes per track like nearly all OS-9 disk formats).<br /><br />Before unstowing my other CDI 605 (it was nearly at the bottom of a 150 cm stowed equipment stack) I tried reading the floppies with my trusty old Windows 98 machine which still has floppy drives. I could not quickly find a DOS tool that handled the 256 byte sectors (not even raread and friends), although I suspect that Sydex’s TELEDISK product would have handled it just fine. I also tried Reischke’s OS9MAX which should handle all OS-9 formats under the sun according to its documentation. The demo version ran under MS-DOS and gave me working directory listings, even for the 38U0 floppies, but it does not support actually reading the files and I am somewhat doubtful about the current availability of the paid-for full version (even apart from cost concerns).<br /><br />Why did I decide to use the 605? It was not a question of reading the disks (the 182 did this mostly fine) but of handling the data thus read. The 182 unit has a SCSI connector but I have no drivers for it (yet) and dumping my full floppy collection over the serial port did not really appeal to me for speed and reliability reasons (it could have been done, of course).<br /><br />The 605 player has a SCSI connector and includes drivers for it so I could have just connected it to the SCSI disk in my E1 emulator and copied the floppies to hard disk (I would still have needed to transfer them to my laptop which would have been a two-step process via the Windows 98 PC as I have no SCSI connection on my laptop).<br /><br />Instead I used the BNC network connector of the 605 to directly transfer floppy images to my laptop (it needs a network switch supporting both a BNC connector and the modern RJ45 connectors, but luckily I have two of those, even if they are only 10 Mbit/s). Starting up the network environment of the 605 took only two OS-9 commands at the command shell prompt:<br /><pre>ispmode /le0 addr=10.0.0.120<br>mbinstall</pre>After this I could just ftp in to my laptop where I ran ftpdmin, a very minimal ftp server program, and transfer floppy disk images directly:<br /><pre>ftp 10.0.0.110<br>bin<br>put /d0@ floppy.dsk</pre>(where /d0@ is the raw floppy device, for 38U0 I used /d0uv@, both are built-in for the 605).<br /><br />The transfers ran at the maximum speed of the floppy drive (way below the 10 Mbit/s network speed), and the resulting .dsk files are perfectly readable using the –v option (virtual disk) of Carey Bloodworth’s os9.exe program even though that program was originally written for Tandy Color Computer OS9/6809 floppies (the floppy disk format was not changed for OS-9/68000 which is at the core of CD-i’s CD-RTOS operating system).<br /><br />For easy access I also created a “tar” format archive of each floppy on a RAM disk:<br /><pre>chd /d0<br>tar cvf /r768/floppy.tar .</pre>and ftp’d those to my laptop as well (the /r768 device is a 768 KB variation of the /r512 built-in 512 KB RAM disk device of the 605 player).<br /><br />I ended up with the following collection of unique floppy disk images:<br /><ul><li><strong>605h3</strong> - 605 H3 Driver Update (1 floppy)<br /><li><strong>605upd</strong> - 605 Driver Update (1 floppy)<br /><li><strong>bcase</strong> - Basecase Tests (1 floppy)<br /><li><strong>eboot41</strong> - Emulation Boot Diskette (1 floppy)<br /><li><strong>eburn41</strong> - Emulation and CDD 521 Boot Diskette (1 floppy)<br /><li><strong>inet</strong> - CD-I Internet Installation Disk - V1.3 (1 floppy)<br /><li><strong>nfs</strong> - OS-9/68000 Network File System V.1.0 (1 floppy)<br /><li><strong>os9sys</strong> - OS-9 System Diskette (1 floppy)<br /><li><strong>pubsoft</strong> - OptImage Public Domain Software (2 floppies)<br /><li><strong>pvpak</strong> - OptImage Preview Pak Installation Disk (1 floppy)<br /><li><strong>ubridge</strong> - OS-9 UniBridge Resident Utilities (3 floppies)<br /></ul><br />The <strong>605</strong>* and <strong>eb</strong>* floppies are mostly interesting for CD-i 605 or E1 emulator owners, but the <strong>bcase</strong> floppy contains a set of CD-i standard conformance test programs that.<br /><br />The <strong>inet</strong> and <strong>nfs</strong> floppies contain a full set of Internet software including Telnet and FTP servers and clients and an NFS client (all except the latter are also in the 605 ROMs).<br /><br />The <strong>os9sys</strong> floppy contains a full set of Professional OS-9 programs and is my original source for most of the OS-9 CD-i disc that I described earlier (most of these are not in ROM on any CD-i player that I’ve seen so far).<br /><br />The <strong>pubsoft</strong> floppies contain miscellanous utilities such as bfed, du, kermit, umacs and vi, most of which can be obtained elsewhere, some CD-i specific utilities such as da (CD-i disk analyzer) and iffinfo (CD-i IFF file dumper) as well as library source files for the CD-i IFF file library.<br /><br />The <strong>pvpak</strong> floppy contains preview software for CD-i images that will preview CD-i IFF files from an NFS-mounted host file system directory.<br /><br />The <strong>ubridge</strong> floppies are the goldmine (and also the 38U0 format ones) as they contain a full set of native Microware C compiler/assembler/linker/debugger software for OS-9 complete with CD-i header files and libraries and C runtime startup sources. Both the srcdbg and sysdbg debuggers are included as well as the rdump utility for dumping ROFF (Relocatable Object File Format) files.<br /><br />Unfortunately, most of the above software except for the pubsoft contents is copyrighted property of Microware (now Radisys) or OptImage (a former Philips/Microware joint venture) which means that I cannot distribute it, even though they could be very useful to CD-i homebrew developers. For that the hopefully soon-to-be available GCC cross-port will have to be enough...<br /><br />While investigating all of the above I also stumbled upon a 450 MB OS-9 hard disk image for MediaWorkshop. The os9.exe program recognizes it just enough to say that it does not support it so I have no real idea about its contents except the obvious.<br /><br />To remedy that problem I’m in the process of adding SCSI disk support to CD-i emulator so that I can use the SCSI support in the CD-i 605 ROMs to mount the disk image and look at it. This should also allow the CD-i 180 to boot from a SCSI disk if I ever find drivers for it (a possible path to that has just appeared, we’ll see...).CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com0tag:blogger.com,1999:blog-4867024730231313742.post-71102406276070612752011-09-30T23:49:00.002+02:002023-05-13T21:15:26.653+02:00CD-i 180 experimentationEarly this week, <a href="http://www.cdinteractive.co.uk/forum/">CDinteractive.co.uk forum</a> user <a href="http://www.cdinteractive.co.uk/forum/profile.php?mode=viewprofile&u=9">Erroneous</a> came by and we spent an interesting evening taking apart our CDI 18x units and figuring out serial ports.<br /><br />Whereas my set consists of a CDI 180/37 and a CDI 181/37 unit, his set is the full 180/181/182 ensemble with the added bonus of supporting 220V power. I was not previously aware that such units even existed, but it turns out he has a 180/20 + 181/20 + 182/00 combination.<br /><br />I’ve taken some photographs from his set, both intact and in various dismantled states, and these can be found <a href="http://www.cdiemu.org/site/hw/erroneous/">here</a> on the <a href="http://www.cdiemu.org/">CD-i Emulator</a> website. Nothing particularly surprising except for the small size ROM in the 182 unit, it’s only a pair of 27C512 chips which hold 32 KB each for a total of only 64 KB!<br /><br />Erroneous sold me his spare CD-i 180 remote unit and serial port adapter so I now have a mostly functioning CD-i 180 set. Unfortunately, it turns out that my 180 CD drive unit has problems so I cannot play actual discs, but the set works fine using the E1 Emulator.<br /><br />It turned out that his set, however, has some defect in the 181 MMC unit which prevents it from reading discs, either from the 180 CD drive or from the E1 Emulator. Using my 181 and his 180 and 182 units we managed to get a fully working set, albeit running on mixed 120V / 220V wall power!<br /><br />Because at first we couldn’t get a working command prompt on the serial port of his 182 unit, he undertook to solder a spare DB9 connector to the 181/182 interconnection bus, based on the pinout of the serial adapter which attaches to that same bus (which matches the pinout I had previously figured out by tracing the circuit board). This gave output but not a working command prompt either.<br /><br />It finally turned out to be a feature of the OS9 System Disk that we were using; it boots properly when you select “Floppy Application” from the “System” menu, but it’s final step starts a command prompt for the /term device and it turns out there is no such device in the 180 player. It has three (!) serial port devices but they are named /t0, /t01 and /t2 (see below) whereas the 60x players for which this disk was apparently intended do have a /term device. On the 180, avoiding the startup script by choosing “System” / “CD-RTOS” works fine however.<br /><br />When we figured this out, we could get a command line prompt on either serial port, the ROMs are smart enough to select the device where a terminal is actually connected.<br /><br />We confirmed that the serial I/O chip in the 182 unit is indeed an 68681 chip as I previously suspected, which supports two serial port devices of which only one has a connector on the outside of the unit. The connected device is supported with the /t0 device name, the unconnected one uses /t01. In addition to the 68070 built-in serial port this means that the 181+182 combination actually has three serial ports, but the usual hardware setup makes only one of them accessible at a time (connecting the units uses up the interconnection bus which means that the serial adapter cannot be connected at the same time).<br /><br />At this point, it was getting late and Erroneous departed for home, graciously allowing me to temporarily borrow his 18x set for some more experimentation and dumping.<br /><br />When the serial port allowed me to take look inside the running 180 player, it turned out that the four ROMs that I previously dumped were not in fact co-located in the address space. The “system” ROM pair lives at $180000 as expected but on Maxi-MMC it is only 256 KB; the other 256 KB ROM pair lives at $700000 (I’ve called it the “asset” ROM because it contains only a font and pictures). Leaving out the asset ROM inside CD-i Emulator gives a working player but without any background images or buttons, just the text over a black background. You can still start a CD-i application of play a CD-Audio disc, though...<br /><br />Another small factoid is that the 182 ROM contains a single picture ps_child.dyuv that at first appears to be a revised version of the identically-named one in the 181 ROM, but both pictures are bitwise identical except for the module edition number and CRC. Weird...<br /><br />Dumping the ROMs of Erroneous’s 181 set turned up nothing new; they are bitwise identical to the ones from my own unit (not really surprising as both units have big “1.1” stickers on the back which signifies the “final” ROM update that all Philips 18x players received shortly before the market introduction of CD-i).<br /><br />Having the 182 unit ROMs I have now extended CD-i Emulator to also support the two additional serial ports, even though the second of these is not usable on the actual player! The floppy controller and the parallel and SCSI port remain for the future.<br /><br />Later this week I also took apart my new CD-i 180 remote unit, which can be used over infrared but also supports a cable connection (I’ll need to make my own cable). Pictures of this are on my site <a href="http://www.cdiemu.org/site/hw/cdi180rem.htm">here</a>. I suspected that the interconnection would use the I<sup>2</sup>C protocol and this indeed turned out to be the case. The unit contains another 84C21 mask-programmable microprocessor labeled “REMOCON Ver. 2.0” and its I<sup>2</sup>C SDA and SCLK pins are more or less directly connected to the cable connector, which also has RESET, GND and +5V power connections. This should allow me to connect any home-brewn pointing device over I<sup>2</sup>C.<br /><br />From a bit of running system and driver inspection I also found out some more details about the bus locations of the floppy and SCSI controller chips in the 182 unit. There are two surprisingly empty ROM sockets on the SCSI extension board that are probably intended for SCSI driver and application software; except for booting support the other ROMs contain none of this.<br /><br />With the information learned so far I have expanded the cditypes.rul file with CD-i 180 ROM recognition and put it in the <a href="http://www.cdiemu.org/cditypes">CD-i Types</a> section of the site.<br /><br />Having two working floppy drives also allowed me to review my CD-i floppy collection and most of those appear to be perfectly readable; they may yet turn out to contain something interesting.CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com0tag:blogger.com,1999:blog-4867024730231313742.post-49442718577760990732011-09-24T23:36:00.002+02:002023-05-13T21:15:36.807+02:00CD-i 180 disc playingAfter a few hours of tweaking I’ve gotten CD-i 180 disc playing working in CD-i Emulator. Most of the time was spent on basic disassembly of the driver, which is very similar to the CD-i 605 version (but missing some features such as multi-session support and seek delay). Not very surprising as both players use the same CDIC chip, although they are supposedly different versions.<br /><br />The problems were really quite trivial but there are of course complications...<br /><br />The first problem turned out to be a memory map issue. On all CD-i players that I’ve encountered so far, a memory map chunk size of 128 KB works fine because memory from different devices (whether general purpose RAM or device-specific memory such as NVRAM and CDIC local memory) never lives inside the same 128 KB chunk of address space. On the CD-i 180 this is not true, as can be seen from the following fragment of maximmc.brd:<pre>$00300000 cdic.dev level=4<br>$00310000 nvr.dev</pre>My code silently overwrote the CDIC mapping with the NVR mapping which meant that any access to CDIC local memory terminated in a bus error. Needless to say, this was not conducive to disc playback. Simply lowering the memory map chunk size to 64 KB fixed this problem.<br /><br />Next it turned out that during initialization the cdap18x driver wants to do some kind of data transfer to address $320001, possibly DSP parameters or something, and there was no device there yet. This was easily fixed also.<br /><br />At this point the disc play got started but the interrupt routine ignored all interrupts. After inspecting the driver it turned out that the CD-i 180 expects an additional status bit to be set in the DBUF register that was never used on other CD-i players with a CDIC. Still easy to fix.<br /><br />Now the interrupt routine started trying to process the sector but it got bus errors in two places. It attempted to read the FILE selection register, which other CD-i players never did, and it took the buffer index bits (these specify the DMA buffer the hardware used from the sector) from a previously unimplemented register that I’ve dubbed DSEL for now. Easy fixes galore...<br /><br />After this one sector got properly transferred to memory but an unending stream of interrupts hung up the player. It turns out that the CD-i 180 ROMs don’t read the CDIC XBUF register that CD-i Emulator used to clear the interrupt. Generating and clearing the interrupt from the DBUF register fixed that also, and now the disc actually started playing!<br /><br />Of course I did some tests next and there are currently three known problems:<br /><br />- Reads of the disc table-of-contents (TOC) take ages, probably because the ROMs are checking for or waiting on some flag or data byte that CD-i Emulator currently doesn’t provide. This should not be very hard to fix.<br /><br />- Audio playback from memory doesn’t work, the symptoms are very similar to those of the audio sync issues that occurred during the MESS collaboration in 2009. This may be a hard problem to crack.<br /><br />- And finally the most hairy issue: the CDIC emulation modifications break other players. The breakage is often subtle but very definitely there so I will have to do some careful juggling to get it working on all players, if necessary by explicit version checking but I hope to avoid that. The hardware should not be that dissimilar, really...<br /><br />On the serial port and pointing device front, I’ve found someone who has a surplus serial port interface and an infrared remote. He also has a complete CD-i 180 set (including the CDI 182 unit) and I’m looking forward to extracting the ROMs from that one also.<br /><br />He also took apart his mouse and it seems to be a fairly standard Amiga design which means that it should not be very hard to manufacture a replacement.<br /><br />I’ve been looking into making a small PIC-based interface for PS2 and/or CD-i peripherals and it may still come to that but it seems to be not as necessary as I thought.CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com0tag:blogger.com,1999:blog-4867024730231313742.post-68507488272041686882011-09-24T02:02:00.002+02:002023-05-13T21:15:46.877+02:00CD-i 180 internalsIn the previous post I promised some ROM and chip finds. Well, here goes. To understand some of the details, you'll need some microprocessor and/or digital electronics knowledge, but even without that the gist of the text should be understandable.<br /><br />The CDI 181 MMC unit contains the so-called Maxi-MMC board that is not used in any other CD-i player. Its closest cousin is the Mini-MMC board that is used in the CD-i 605 and CD-i 220 F1 players (a derivative of it is used in the CD-i 350/360 players).<br /><br />The Mini-MMC board uses two 68HC05 slave processors for CD and pointing device control (they are usually called SERVO and SLAVE). The Maxi-MMC board does not have these chips, but it does have two PCF80C21 slave processors labeled RSX and TRANSDUCER that perform similar functions.<br /><br />From their locations on the board I surmise that the RSX performs CD control functions; I know for sure that the TRANSDUCER performs only pointing device control. The latter is connected to the main 68070 processor via an I<sup>2</sup>C bus (I've actually traced the connections); I'm not completely sure yet about the RSX.<br /><br />In order to emulate the pointing devices in CD-i Emulator, I had to reverse engineer the I<sup>2</sup>C protocol spoken by the TRANSDUCER chip; this was mostly a question of disassembling the "ceniic" and "periic" drivers in the ROM. The first of these is the low-level driver that serves as the common control point for the I<sup>2</sup>C bus; the second is the high-level driver that is instantiated separately for each type of pointing device. The ROMs support three such devices: /cdikeys, /ptr and /ptr2, corresponding to the player control keys and first and second pointing devices (the first pointing device is probably shared between the infrared remote sensor and the left pointing device port). Both pointing devices support absolute (e.g. touchpad) as well as relative (e.g. mouse) positioning.<br /><br />Note that there is no built-in support for a CD-i keyboard or modem (you could use a serial port for this purpose).<br /><br />However, knowing the I<sup>2</sup>C protocol does not tell me the exact protocol of the pointing devices, which therefore brings me no closer to constructing a "pointing device" that works with the two front panel MiniDIN-9 connectors. Note that these connectors are physically different from the MiniDIN 8 pointing device connectors used on most other CD-i players. According to the Philips flyers, these connectors have 6 (presumably digital) input signals and a "strobe" (STB) output signal. From the signal names I can make some educated guesses about the probable functions of the signals, but some quick tests with the BTN1 and BTN2 inputs did not pan out and it could be too complicated to figure out without measurement of a connected and working pointing device.<br /><br />There is, however, also an infrared remote sensor that is supposed to expect the RC5 infrared signal protocol. This protocol supports only 2048 separate functions (32 groups of 64 each) so it should not be impossible to figure out, given a suitably programmable RC5 remote control or in the best case a PC RC5 adapter. I've been thinking about building one of the latter.<br /><br />There is also a third possibility of getting a working pointing device. Although the case label of the front MiniDIN 8 connecter is "CONTROL", the Philips flyers label it "IIC" which is another way of writing "I<sup>2</sup>C", although they don't give a pinout of the port. It seems plausible that the connector is connected to the I<sup>2</sup>C bus of the 68070, although I haven't been able to verify that yet (the multimeter finds no direct connections except GND, so some buffering must be involved). If there is indeed a connection, I would be able to externally connect to that bus and send and receive the I<sup>2</sup>C bus commands that I've already reverse engineered.<br /><br />If even this doesn't work, I can always connect directly to the internal I<sup>2</sup>C bus, but that involves running three wires from inside the player to outside and I'm not very keen on that (yet, anyway).<br /><br />Now, about the (so far) missing serial port. There is a driver for the 68070 on-chip UART in the ROMs (the u68070 driver which is accessible via the /t2 device), and the boot code actually writes a boot message to it (CD-i Emulator output):<br /><pre> PHILIPS CD-I 181 - ROM version 23rd January, 1992.<br>Using CD_RTOS kernel edition $53 revison $00</pre>At first I thought that the UART would be connected to the "CONTROL" port on the front, but that does not appear to be the case. Tonight I verified (by tracing PCB connections with my multimeter) that the 68070 serial pins are connected to the PCB connector on the right side (they go through a pair of SN75188/SN75189 chips and some protection resistors; these chips are well-known RS232 line drivers/receivers). I even know the actual PCB pins, so if I can find a suitable 100-pins 0.01" spaced double edge print connector I can actually wire up the serial port.<br /><br />Now for the bad news, however: the ROMs do not contain a serial port download routine. They contain a host of other goodies (more below) but not this particular beast. There is also no pointing device support for this port, contrary to all other players, so connecting up the serial port would not immediately gain me anything, I still need a working pointing device to actually start a CD-i disc…<br /><br />There are no drivers for other serial ports in the ROMs, but the boot code does contain some support for a UART chip at address $340001 (probably a 68681 DUART included in the CDI 182 unit which I don't have). The support, however, is limited to the output of boot messages although the ROMs will actually prefer this port over the 68070 on-chip device if they find it.<br /><br />As is to be expected from a development and test player, there is an elaborate set of boot options, but they can only be used if the ROMs contain the signature "IMS-TC" at byte offset $400 (the ROMs in my player contains FF bytes at these locations). And even then the options prompt will not appear unless you press the space bar on your serial terminal during player reset.<br /><br />However, adding a -bootprompt option that handles both the signature and the space bar press to CD-i Emulator was not hard, and if you use that option with the 180 ROMs the following appears when resetting the player:<pre> PHILIPS CD-I 181 - ROM version 23rd January, 1992.<br><br>A-Z = change option : <BSP> = clear options : <RETURN> = Boot Now<br><br>Boot options:- BQRS</pre>As specified, you can change the options by typing letters and pressing Enter will start the boot process with the specified options.<br /><br />From disassembling the boot code of the ROMs I've so far found the following options:<br /><br />D = Download/Debug<br />F = Boot from Floppy<br />L = Apply options and present another options prompt (Loop)<br />M = Set NTSC Monitor mode<br />P = Set PAL mode<br />S = Set NTSC/PAL mode from switch<br />T = Set NTSC mode<br />W = Boot from SCSI disk (Winchester)<br /><br />It could be that there's also a C option, and I've as yet not found any implementations of the Q and R options that the ROMs include in the default, but they could be hidden in OS-9 drivers instead of the boot code.<br /><br />Once set, the options are saved in NVRAM at address $313FE0 as default for prompts during subsequent reboots, they are not used for reboots where the option prompt is not invoked.<br /><br />Options D, F and W look interesting, but further investigation leads to the conclusion that they are mostly useless without additional hardware.<br /><br />Pressing lower-case D followed by Enter / Enter results in the following:<pre>Boot options:- BQRSd<br>Boot options:- BDQRS<br>Enter size of download area in hex - just RETURN for none<br>called debugger<br><br>Rel: 00000000<br>Dn: 00000000 0000E430 0007000A 00000000 00000000 00000001 FFFFE000 00000000<br>An: 00180B84 00180570 00313FE0 00410000 00002500 00000500 00001500 000014B0<br>SR: 2704 (--S--7-----Z--) SSP: 000014B0 USP: 00000000<br>PC: 00180D2E - 08020016 btst #$0016,d2<br>debug: </pre>One might think that entering a download size would perform some kind of download (hopefully via the serial port) but that is not the case. The "download" code just looks at location $2500 in RAM that's apparently supposed to be already filled (presumably via an In-Circuit Emulator or something like it).<br /><br />However, invoking the debugger is interesting in itself. It looks like the Microware low-level RomBug debugger that is described in the Microware documentation, although I haven't found it in any other CD-i players. One could "download" data with the change command:<pre>debug: c0<br>00000000 00 : 1<br>00000001 00 : 2<br>00000002 15 : 3<br>00000003 00 : </pre>Not very userfriendly but it could be done. The immediate catch is that it doesn't work with unmodified ROMs because of the "IMS-TC" signature check!<br /><br />Trying the F option results in the following:<pre>Boot options:- BQRSf<br>Boot options:- BFQRS<br>Booting from Floppy (WD 179x controller) - Please wait </pre>This, however, needs the hardware in the CDI 182 set (it lives at $330001). I could emulate that in CD-i Emulator of course, but there's no real point at this time. It is interesting to note that the floppy controller in the CD-i 605 (which I haven't emulated either at this point) is a DP8473 which is register compatible with the uPD765A used in the original IBM PC but requires a totally different driver (it also lives at a different memory address, namely $282001).<br /><br />Finally, trying the W options gives this:<pre>Boot options:- BQRSw<br>Boot options:- BQRSW<br>Booting from RODIME RO 650 disk drive (NCR 5380 SCSI) - Please wait<br>Exception Error, vector offset $0008 addr $00181908<br>Fatal System Error; rebooting system</pre>The hardware is apparently supposed to live at $410000 and presumably emulatable; it's identical or at least similar to the DP5380 chip that is found on the CD-i 605 extension board where it lives at $AA0000). <br /><br />Some other things that I've found out:<br /><br />The CDI 181 unit has 8 KB of NVRAM but it does not use the M48T08 chip that's in all other Philips players, it's just a piece of RAM that lives at $310000 (even addresses only) and is supported by the "nvdrv" driver via the /nvr device.<br /><br />In the CD-i 180 player the timekeeping functions are instead performed by a RICOH RP5C15 chip, the driver is appropriately called "rp5c15".<br /><br />And there is a separate changeable battery inside the case; no "dead NVRAM" problems with this player! I don't know when the battery in my player was last changed but at the moment it's still functioning and had not lost the date/time when I first powered it on just over a week ago.<br /><br />The IC CARD slot at the front of the player is handled like just another piece of NVRAM; it uses the same "nvdrv" driver but a different device: /icard. According to the device descriptor it can hold 32 KB of data, I would love to have one of those!CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com0tag:blogger.com,1999:blog-4867024730231313742.post-18600606940074145142011-09-19T04:18:00.005+02:002023-05-13T21:15:54.692+02:00CD-i 180 adventuresOver the last week I have been playing with the CD-i 180 player set. There’s lots to tell about, so this will be a series of blog posts, this being the first installment.<br /><br />The CD-i 180 is the original CD-i player, manufactured jointly by Philips and Sony/Matsushita, and for a score of years it was the development and “reference” player. The newer CD-i 605 player provided a more modern development option but it did not become the “reference” player for quite some years after its introduction.<br /><br />The CD-i 180 set is quite bulky, as could be expected for first-generation hardware. I have added a picture of my set to the <a href="http://www.cdiemu.org/hardware">Hardware</a> section of the CD-i Emulator website; more fotos can be found <a href="http://www.dutchaudioclassics.nl/Philips_CDI-180-Professional_CD-Interactive_system/">here</a> on the <a href="http://www.dutchaudioclassics.nl/">DutchAudioClassics.nl</a> website (it’s the same player, as evidenced by the serial numbers). <br /><br />The full set consists of the CDI 180 CD-i Player module, the CDI 181 Multimedia Controller or MMC module and the CDI 182 Expansion module. The modules are normally stacked on top of each other and have mechanical interlocks so they can be moved as a unit. Unfortunately, I do not have the CDI 182 Expansion module nor any user manuals; Philips brochures for the set can be found <a href="http://www.icdia.co.uk/brochures/authoring_hw/index.html">here</a> on the <a href="http://www.icdia.co.uk/">ICDIA website</a>.<br /><br />Why am I interested in this dinosaur? It’s the first mass-produced CD-i player (granted, for relatively small masses), although there were presumably some earlier prototype players. As such, it contains the “original” hardware of the CD-i platform, which is interesting from both a historical and an emulation point of view.<br /><br />For emulation purposes I have been trying to get hold of CD-i 180 ROMs for some years, there are several people that still have fully operational sets, but it hasn’t panned out yet. So when I saw a basic set for sale on the CD-Interactive forum I couldn’t resist the temptation. After some discussion and a little bartering with the seller I finally ordered the set about 10 days ago. Unfortunately, this set does not include a CDI 182 module or pointing device.<br /><br />I had some reservations about this being a fully working set, but I figured that at least the ROM chips would probably be okay, if nothing else that would allow me to add support for this player type to CD-i Emulator.<br /><br />In old hardware the mechanical parts are usually the first to fail, this being the CDI 180 CD-i Player module (which is really just a CD drive with a 44.1 kHz digital output “DO” signal). A workaround for this would be using an <a href="http://www.icdia.co.uk/brochures/authoring_hw/index.html">E1 or E2 Emulator</a> unit; these are basically CD drive simulators that on one side read a CD-i disc image from a connected SCSI hard disk and on the other side output the 44.1 kHz digital output “DO” signal. Both the CDI 180 and E1/E2 units are controlled via a 1200 baud RS232 serial input “RS” signal.<br /><br />From my CD-i developer days I have two sets of both Emulator types so I started taking these out of storage. For practical reasons I decided to use an E1 unit because it has an internal SCSI hard disk and I did not have a spare one lying around. I also dug out an old Windows 98 PC, required because the Philips/OptImage emulation software doesn’t work under Windows XP and newer, and one of my 605 players (I also have two of those). Connecting everything took me a while but I had carefully stored all the required cables as well and after installing the software I had a working configuration after an hour or so. The entire configuration made quite a bit of mechanical and fan noise; I had forgotten this about older hardware!<br /><br />I had selected the 605 unit with the Gate Array AH02 board because I was having emulation problems with that board, and I proceeded to do some MPEG tests on it. It turns out the hardware allows for some things that my emulator currently does not, which means that I need to do some rethinking. Anyway, on with the 180 story.<br /><br />In preparation for the arrival of the 180 set I next prepared an disc image of the “OS-9 Disc” that I created in November 1993 while working as a CD-i developer. This disc contains all the OS-9 command-line programs from Professional OS-9, some OS-9 and CD-i utilities supplied by Philips and Microware and some homegrown ones as well. With this disc you can get a fully functional command-line prompt on any CD-i player with a serial port, which is very useful while researching a CD-i player’s internals.<br /><br />The Philips/Optimage emulation software requires the disc image files to include the 2-second gap before logical block zero of the CD-i track, which is not usually included in the .bin or .iso files produced by CD image tools. So I modified the CD-i File program to convert my existing os9disc.bin file by prepending the 2-second gap, in the process also adding support for scrambling and unscrambling the sector data.<br /><br />Scrambling is the process of XORing all data bytes in a CD-ROM or CD-i sector with a “scramble pattern” that is designed to avoid many contiguous identical data bytes which can supposedly confuse the tracking mechanism of CD drives (or so I’ve heard). It turned out that scrambling of the image data was not required but it did allow me to verify that the CD-I File converted image of a test disc is in fact identical to the one that the Philips/Optimage mastering tools produce, except for the ECC/EDC bytes of the gap sectors which CD-I File doesn’t know how to generate (yet). Fortunately this turned out not to be a problem, I could emulate the converted image just fine.<br /><br />Last Thursday the 180 set arrived and in the evening I eagerly unpacked it. Everything appeared to be in tip-top shape, although the set had evidently seen use.<br /><br />First disappointment: there is no serial port on the right side of 181 module. I remembered that this was actually an option on the module and I had not even bothered to ask the seller about it! This would make ROM extraction harder, but I was not completely without hope: the front has a Mini-DIN 8 connector marked “CONTROL” and I fully expected this to be a “standard” CD-i serial port because I seemed to remember that you could connect standard CD-i pointing devices to this port, especially a mouse. The built-in UART functions of the 68070 processor chip would have to be connected up somewhere, after all.<br /><br />Second disappointment: the modules require 120V power, not the 220V we have here in Holland. I did not have a voltage converter handy so after some phone discussion with a hardware-knowledgeable friend we determined that powering up was not yet a safe option. He gave me some possible options depending on the internal configuration so I proceeded to open up the CDI 181 module, of course also motivated by curiosity.<br /><br />The first thing I noticed was that there were some screws missing; obviously the module had been opened before and the person doing it had been somewhat careless. The internals also seemed somewhat familiar, especially the looks of the stickers on the ROM chips and the placement of some small yellow stickers on various other chips.<br /><br />Proceeding to the primary reason for opening up the module, I next checked the power supply configuration. Alas, nothing reconfigurable for 220V, it is a fully discrete unit with the transformer actually soldered to circuit board on both input and output side. There are also surprisingly many connections to the actual MMC processor board and on close inspection weird voltages like –9V and +9V are printed near the power supply outputs, apart from the expected +5V and +/–12V, so connecting a different power supply would be a major undertaking also.<br /><br />After some pondering of the internals I closed up the module again and proceeded to closely inspect the back side for serial numbers, notices, etc. They seemed somewhat familiar but that isn’t weird as numbers often do. Out of pure curiosity I surfed to the DutchAudioClassics.nl website to compare serial numbers, wanting to know the place of my set in the production runs.<br /><br />Surprise: the serial numbers are identical! It appears that this exact set was previously owned by the owner of that website or perhaps he got the photographs from someone else. This also explained why the internals had seemed familiar: I had actually seen them before!<br /><br />I verified with the seller of the set that he doesn’t know anything about the photographs; apparently my set has had at least four owners, assuming that the website owner wasn’t the original one.<br /><br />On Friday I obtained a 120V converter (they were unexpectedly cheap) and that evening I proceeded to power up the 180 set. I got a nice main menu picture immediately so I proceeded to attempt to start a CD-i disc. It did not start automatically when I inserted it, which on second thought makes perfect sense because the 181 MMC module has no way to know that you’ve just inserted a disc: this information is not communicated over 180/181 interconnections. So I would need to click on the “CD-I” button to start a disc.<br /><br />To click on a screen button you need a supported pointing device, so I proceeded to connect the trusty white professional CD-i mouse that belongs with my 605 players. It doesn’t work!<br /><br />There are some mechanical issues which make it doubtful that the MiniDIN connector plugs connect properly, so I tried an expansion cable that fit better. Still no dice.<br /><br />The next step was trying some other CD-i pointing devices, but none of them worked. No pointing devices came with the set, and the seller had advised me thus (they were presumable lost or sold separately by some previous owner). The only remaining option seemed to be the wireless remote control sensor which supposedly uses RC5.<br /><br />I tried every remote in my home, including the CD-i ones, but none of them give any reaction. After some research into the RC5 protocol this is not surprising, the 180 set probably has a distinct system address code. Not having a programmable remote handy nor a PC capable of generating infrared signals (none of my PCs have IrDA) I am again stuck!<br /><br />I spent some time surfing the Internet looking for RC5 remotes and PC interfaces that can generate RC5 signals. Programmable remotes requiring a learning stage are obviously not an option so it will have to be a fully PC-programmable remote which are somewhat expensive and I’m not convinced they would work. The PC interface seems the best option for now; I found some do-it-yourself circuits and kits but it is all quite involved. I’ve also given some thought to PIC kits which could in principle also support a standard CD-i or PC mouse or even a joystick, but I haven’t pursued these options much further yet.<br /><br />Next I went looking for ways to at least get the contents of the ROM chips as I had determined that these were socketed inside the MMC module and could easily be removed. There are four 27C100 chips inside the module, each of which contains 128Kb of data for a total of 512Kb which is the same as for the CD-i 605 player (ignoring expansion and full-motion video ROMs). The regular way to do this involves using a ROM reading device, but I haven’t gotten one handy that supports this chip type and neither does the hardware friend I mentioned earlier.<br /><br />I do have access to an old 8 bit Z80 hobbyist-built system capable of reading and writing up to 27512 chips which are 64Kb, it is possible to extend this to at least read the 27C100 chip type. This would require adapting the socket (the 27512 is 28 pins whereas the 27C100 has 32 pins) and adding one extra address bit, if nothing else with just a spare wire. But the Z80 system is not at my house and some hardware modifications to it would be required, for which I would have to inspect the system first and dig up the circuit diagrams; all quite disappointing.<br /><br />While researching the chip pinouts I suddenly had an idea: what if I used the CD-i 605 Expansion board which also has ROM sockets? This seemed an option but with two kids running around I did not want to open up the set. That evening however I took the board out of the 605 (this is easily done as both player and board were designed for it) and found that this Expansion board contains two 27C020 chips, each containing 256Kb of data. These are also 32 pins but the pinouts are a little different, so a socket adapter would also be needed. I checked the 605 technical manual and it did not mention anything about configurable ROM chip types (it did mention configurable RAM chip types, though) so an adapter seemed the way to go. I collected some spare 40 pin sockets from storage (boy have I got much of that) and proceeded to open up the 180 set and take out the ROM chips.<br /><br />When determining the mechanical fit of the two sockets for the adapter I noticed three jumpers adjacent to the ROM sockets of the expansion board and I wondered… Tracing of the board connections indicated that these jumpers were indeed connected to exactly the ROM socket pins differing between 27C100 and 27C020, and other connections indicated it at least plausible for these jumpers to be exactly made for the purpose.<br /><br />So I changed the jumpers and inserted one 180 ROM. This would avoid OS-9 inadvertently using data from the ROM because only half of each 16-bit word would be present, thus ensuring that no module headers would be detected, and in the event of disaster I would lose only a single ROM chip (not that I expected that to be very likely, but you never know).<br /><br />Powering up the player worked exactly as expected, no suspicious smoke or heat generation, so the next step was software. It turns out that CD-i Link already supports downloading of ROM data from specific memory addresses and I had already determined those addresses from the 605 technical manual. So I connected the CD-i 605 null-modem cable with my USB-to-Serial adapter between CD-i player and my laptop and fired off the command line:<br /><code><br /> cdilink –p 3 –a 50000 –s 256K –u u21.rom<br /></code><br />(U21 being the socket number of the specific ROM I chose first).<br /><br />After a minute I aborted the upload and checked the result, and lo and behold the u21.rom file looked like an even-byte-only ROM dump:<br /><code><pre>00000000 4a00 000b 0000 0000 0004 8000 0000 0000 J...............<br>00000010 0000 0000 0000 003a 0000 705f 6d6c 2e6f .......:..p_ml.o<br>00000020 7406 0c20 0000 0000 0101 0101 0101 0101 t.. ............</pre></code>This was hopeful, so I restarted the upload again and waited some six minutes for it to complete. Just for sure I redid the upload from address 58000 and got an identical file, thus ruling out any flakey bits or timing problems (I had already checked that the access times on the 27C100 and 27C020 chips were identical, to say 150ns).<br /><br />In an attempt to speed up the procedure, I next attempted to try two ROMs at once, using ones that I thought not to be a matched even/odd set. The 605 would not boot! It later turned out that the socket numbering did not correspond to the even/odd pairing as I expected so this was probably caused by the two ROMs being exactly a matched set and OS-9 getting confused as the result. But using a single ROM it worked fine.<br /><br />I proceeded to repeat the following procedure for the next three ROMs: turn off the 605, remove the expansion board, unsocket the previous ROM chip, socket the next ROM chip, reinsert the expansion board, turn on the 605 and run CD-i Link twice. It took a while, all in all just under an hour.<br /><br />While these uploads were running I wrote two small programs rsplit and rjoin to manipulate the ROM files into a correct 512Kb 180 ROM image. Around 00:30 I had a final cdi180b.rom file that looked good and I ran it through cditype –mod to verify that it indeed looked like a CD-I player ROM:<br /><code><pre> Addr Size Owner Perm Type Revs Ed # Crc Module name<br>-------- -------- ----------- ---- ---- ---- ----- ------ ------------<br>0000509a 192 0.0 0003 Data 8001 1 fba055 copyright<br>0000515a 26650 0.0 0555 Sys a000 83 090798 kernel<br>0000b974 344 0.0 0555 Sys 8002 22 b20da9 init<br>0000bacc 2848 0.0 0555 Fman a00b 35 28611f ucm<br>0000c5ec 5592 0.0 0555 Fman a000 17 63023d nrf<br>0000dbc4 2270 0.0 0555 Fman a000 35 d6a976 pipeman<br>0000e4a2 774 0.0 0555 Driv a001 6 81a3e9 nvdrv<br>0000e7a8 356 0.0 0555 Sys a01e 15 e69105 rp5c15<br>0000e90c 136 0.0 0555 Desc 8000 1 f25f23 tim070<br>0000e994 420 0.0 0555 Driv a00c 6 7b3913 tim070driv<br>0000eb38 172 0.0 0555 Driv a000 1 407f81 null<br>0000ebe4 102 0.0 0555 Desc 8000 2 cf450e pipe<br>0000ec4a 94 0.0 0555 Desc 8000 1 f54010 nvr<br>0000eca8 96 0.0 0555 Desc 8000 1 17ec68 icard<br>0000ed08 1934 0.0 0555 Fman a000 31 b41f17 scf<br>0000f496 120 0.0 0555 Desc 8000 61 dd8776 t2<br>0000f50e 1578 0.0 0555 Driv a020 16 d0a854 u68070<br>0000fb38 176 0.1 0777 5 8001 1 a519f6 csd_mmc<br>0000fbe8 5026 0.0 0555 Sys a000 292 e33cc5 csdinit<br>00010f8a 136 0.0 0555 Desc 8000 6 041e2b iic<br>00011012 152 0.0 0555 Driv a02c 22 e29688 ceniic<br>000110aa 166 0.0 0555 Desc 8000 8 c5b823 ptr<br>00011150 196 0.0 0555 Desc 8000 8 a0e276 cdikeys<br>00011214 168 0.0 0555 Desc 8000 8 439a33 ptr2<br>000112bc 3134 0.0 0555 Driv a016 11 faf88d periic<br>00011efa 4510 0.0 0555 Fman a003 96 a4d145 cdfm<br>00013098 15222 0.0 0555 Driv a038 28 122c79 cdap18x<br>00016c0e 134 0.0 0555 Desc 8000 2 35f12f cd<br>00016c94 134 0.0 0555 Desc 8000 2 d2ce2f ap<br>00016d1a 130 0.0 0555 Desc 8000 1 1586c2 vid<br>00016d9c 18082 10.48 0555 Trap c00a 6 5f673d cio<br>0001b43e 7798 1.0 0555 Trap c001 13 46c5dc math<br>0001d2b4 2992 0.0 0555 Data 8020 1 191a59 FONT8X8<br>0001de64 134 0.0 0555 Desc 8000 2 c5ed0e dd<br>0001deea 66564 0.0 0555 Driv a012 48 660a91 video<br>0002e2ee 62622 0.1 0555 Prog 8008 20 ec5459 ps<br>0003d78c 4272 0.0 0003 Data 8001 1 9f3982 ps_medium.font<br>0003e83c 800 0.0 0003 Data 8002 1 c1ac25 ps_icons.clut<br>00040000 2976 0.0 0003 Data 8002 1 0a3b97 ps_small.font<br>00040ba0 7456 0.0 0003 Data 8002 1 764338 ps_icons.clu8<br>000428c0 107600 0.0 0003 Data 8002 1 7b9b4e ps_panel.dyuv<br>0005cd10 35360 0.0 0003 Data 8001 1 2a8fcd ps_girl.dyuv<br>00065730 35360 0.0 0003 Data 8002 1 e1bb6a ps_mesa.dyuv<br>0006e150 35360 0.0 0003 Data 8002 1 8e394b ps_map.dyuv<br>00076b70 35360 0.0 0003 Data 8002 1 c60e5e ps_kids.dyuv<br> <br> File Size Type Description<br>------------ ------ ------------ ------------<br>cdi180b.rom 512K cdi000x.rom Unknown CD-i system ROM<br>cdi180b.rom 512K cdi000x.mdl Unknown CD-i player<br>cdi180b.rom 512K unknown.brd Unknown board</pre></code>Of course cditype didn’t correctly detect the ROM, player and board type, but the list of modules looks exactly like a CD-i player system ROM. It is in fact very similar to the CD-i 605 system ROM, the major differences are the presence of the icard and *iic drivers, the absence of a slave module and the different player shell (ps module with separate ps_* data modules instead of a single play module).<br /><br />It being quite late already, I resocketed all the ROMs in the proper places and closed up both players, after testing that they were both fully functional (insofar as I could test the 180 set), fully intending to clean up and go to bed. As an afterthought, I took a picture of the running 180 set and posted it on the CD-Interactive forums as the definitive answer to the 50/60 Hz power question I’d asked there earlier.<br /><br />The CD-i Emulator urge started itching however, so I decided to give emulation of my new ROM file a quick go, fully intending to stop at any major problems. I didn’t encounter any of those, however, until I had a running CD-i 180 player three hours later. I reported the fact on the CDinteractive forum, noting that there was no pointing device or disc access yet, and went to a well-deserved sleep. Both of these issues are major ones and those I postponed for the next day.<br /><br />To get the new player type up and running inside CD-i Emulater, I started by using the CD-i 605 F1 system specification files cdi605a.mdl and minimmc.brd as templates to create the new CD-i 180 F2 system files cdi180b.mdl and maximmc.brd. Next I fired up the emulator and was rewarded with bus errors. Not unexpected and a good indicator of where the problems are. Using the debugger and disassembler I quickly determined that the problems were, as expected, the presence of the VSR instead of VSD and the replacement of the SLAVE by something else. Straightening these out took a bit of time but it was not hard work and very similar to work I had done before on other player types. <br /><br />This time at least the processor and most of the hardware was known and already emulated; for the Portable CD-i board (used by the CD-i 370, DVE200 and GDI700 players) both of these were not the case as they use the 68341 so-called integrated CD-i engine which in my opinion is sorely misnamed as there is nothing CD-i about the chip, it is just the Motorola version of an 68K processor with many on-chip peripherals in remarkably similar to the Philips 68070 in basic functionality.<br /><br />Saturday was spent doing household chores with ROM research in between, looking for the way to get the pointing device working. It turned out to be quite involved but at the end of the day I had it sort of flakily working in a kludgy way; I’ll report the details in a next blog post. <br /><br />Sunday I spent some time fixing the flakiness and thinking a lot about fixing the kludginess; this remains to be done. I also spent time making screenshots and writing this blog post.<br /><br />So to finish up, there is now a series of 180 screenshots <a href="http://www.cdiemu.org/img/cdi180b/">here</a> on the <a href="http://www.cdiemu.org/">CD-i Emulator</a> website as reported in the <a href="http://www.cdiemu.org/whatsnew/">What's New</a> section. A very nice player shell, actually, especially for a first generation machine.<br /><br />I will report some ROM and chip finds including new hopes for replacing the missing pointing device in a next blog post.CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com2tag:blogger.com,1999:blog-4867024730231313742.post-56936004065292364352011-09-04T01:28:00.006+02:002011-09-04T01:33:43.439+02:00MPEG decoding, state save/restore, NRF emulation, ...It's been a while since I wrote anything here, but that doesn't mean that work on CD-i Emulator has stopped. On the contrary, a lot has happened in the last month and describing all of it will take a very long blog post. So here goes…
<br />
<br />Last January an annoying date-checking bug was found which forced me to release beta2 somewhat earlier than anticipated. After that I did no further work on CD-i Emulator. There were various reasons for this, but the most import one was a very busy period at my day job.
<br />
<br />After a well-earned vacation I resumed CD-i related work in early August. First I spent a few days on Walter Hunt's OS-9 port of gcc, the GNU C/C++ Compiler that I found in October of last year. Getting it working on a modern Cygwin installation was interesting and something very different from my usual line of work. The result could be useful for homebrew activities: it's a much more usable C compiler then the Microware OS-9 one and supports C++ as a bonus. I intend to use this for ROM-less emulation validation some day; see also below. The sources need to be released but I haven’t gotten to that stage yet.
<br />
<br />After that I had another go at the Digital Video cartridge emulation. At the point where I left off last year the major stumbling block was the presumed picture / frame buffering logic of the MPEG video driver. When the appropriate interrupt status bits are set the driver starts copying a bulk of status information to an array of device registers and it will sometimes also read from those registers. This is all controlled by several status and timing registers that are also referenced elsewhere and I previously could not get a handle on it.
<br />
<br />My first attempt this time was spending another few days staring at it and tracing it, but this did not gain me much new understanding. Finally I decided to just leave it for now and see how far I could get without understanding this part of the driver. I decided to once again attempt to get "CD-i Full Motion Video Technical Aspects" working.
<br />
<br />This CD-i was produced by Philips to give future Full Motion Video (as the new MPEG playback functions were called at the time) developers a demonstration of the technical capabilities of the new hardware, at a time when this hardware was still in the early beta phase. The CD-i actually contains the compiler libraries necessary for making FMV calls from CD-i applications, as these had not previously been widely distributed.
<br />
<br />It is not a very slick disc visually, being intended for developers, but it demonstrates a number of FMV techniques such as regular playback, playback control including pause, slow motion and single step, freeze frame and forward/backward scan, special effects like scrolling the FMV window, a seamless jump and a sample of overlay effects with the CD-i base case video planes.
<br />
<br />I had previously tried to run this disc on CD-i Emulator, but it always crashed for an unknown reason that I attributed to MPEG device emulation problems. This time I traced back the crash and it turned out to have nothing at all to do with FMV playback but was instead caused by an incorrect emulation of the 68000 instruction "move ea,ccr" which is supposed to set the condition code register (ccr) to the value specified by the effective address (ea). In the processor manual this is classified as a word instruction and I had emulated it as such, which turned out to be wrong as it caused a word write to the full status register which should have been a byte write to the lower eight bits of it which hold the condition codes.
<br />
<br />The problem manifested itself when the application calls the math trap handler for some mundane number calculations, which were naturally supposed to set the condition codes. The value written to the status register inadvertently changed the processor from user to system mode (and also scrambled the active interrupt masking level) which caused an instant stack switch that caused a bus error when the trap handler attempts to return to the application program (the cpu took the return address from the wrong stack and got garbage instead).
<br />
<br />Most CD-i applications probably don't use the math trap handler so the problem went undetected for a long time. Now that it's fixed some other titles have probably started working but I haven't tested that.
<br />
<br />After this, the FMV Technical Aspects application would get to its main menu screen, allowing me to start FMV playback operations. Regular playback worked fine until the end of the video clip, where there turned out to be status bit generation issues that prevented the application from properly detecting the end of video clip condition (the decoder is supposed to send a "buffer underflow" signal, among others, after the end of the MPEG data and my emulation didn't do that yet).
<br />
<br />This was not very easy to fix because of the way that MPEG data buffering and decoding is handled inside CD-i Emulator, which I'll get into below. So it took me some time.
<br />
<br />Regular play working fine, I started worrying about window control. This was the area where I feared the picture buffering stuff, but it turned out that this was easily bypassed. The horizontal / vertical scrolling functions were ideal to test this but it took me some time to get it working. There were bugs in several areas, including my integration of the MPEG video decoding code, which I took from the well-known mpeg2dec package. This code is written to decode a single video sequence and consequently did not handle image size changes without some re-initialization calls at the appropriate times. Failing that, it mostly just crashed (at the Windows application level) due to out-of-bounds video buffer accesses.
<br />
<br />Another issue was the timing of device register updates for image size changes; I turned out to have the basic mechanism wrong and consequently the driver would keep modifying the window parameters to incorrect values.
<br />
<br />Having all of the above fixed, I returned my attention to playback control. So far I can get the video playback properly paused, but I haven't been able to get it properly resumed. For some reason the application resumes the MPEG playback but it doesn't resume the disc playback. Since the driver waits for new data to arrive from disc before actually resuming MPEG playback nothing happens (this is documented as such). The application is presumably expecting some signal from the driver to get into the proper state for resuming disc playback, but I haven't found it yet.
<br />
<br />At this point, it seemed promising to look at other CD-i titles using playback control and the Philips Video CD application is an obvious candidate. Again, regular playback appears to work fine, but playback control (including pause/resume) does not. It turns out that this application uses a different driver call (it uses MV_ChSpeed instead of MV_Pause, probably in preparation for possible slow motion or single step), which never completes successfully, probably again because of device status signaling. Similar issues appear to block playback control in a few other titles I tried.
<br />
<br />I've given some thought to tracing driver calls and signals on an actual player to see what CD-i Emulator is doing wrong, and it appears to be relatively simple, there's just a bandwidth issue because all of the trace output will have to go out the serial port which can go no higher then 19200 baud. Some kind of data compression is obviously needed and I've determined a relatively simple scheme that should be enough (the CD-i player side will all need to be coded in 68000 machine language so simplicity is important!), but I haven't actually written any code for it yet.
<br />
<br />I know there are issues with the proper timing of some video status signals. Things like start-of-sequence, end-of-sequence and start-of-picture-group should be delayed until display of the corresponding picture, at present they are delivered at decoding time, which can be a few pictures early. But that does not really affect the titles I've tried so far, because they do not attempt picture-synced operations. An application like The Lost Ride might be sensitive to thinks like this, though, and it needs to be fixed at some time. Similar issues are probably present with time code delivery. In addition, the last-picture-displayed and buffer-underflow signals are not always properly sent; I'm fixing these as I go along.
<br />
<br />In the process, I decided that the magenta border was getting annoying and tried to fix it. That turned out to be harder then I thought. The MPEG chip has a special border color register that is written by the MV_BColor driver call and it seemed enough to just pass the color value to the MPEG window overlay routines. Well, not so. Again the issue turned out to be timing of decoder status signals, but of a different kind. The driver doesn't write the border color registers until it has seen some progress in certain timing registers related to the picture buffering thing, presumably to avoid visual flashes or something on the actual hardware. Fortunately, it turned out to be easy to simulate that progress, taking care not to trigger the complicated picture buffer code that I so far managed to keep dormant.
<br />
<br />At some point, possibly related to slow motion or freeze frame, I might need to actually tackle that code but I hope to by that time have gained more understanding of the supposed workings of the MPEG chip.
<br />
<br />Looking at the above, you might think that all of the difficulties are with the MPEG video decoding and that is indeed mostly true. I did have to fix something in the MPEG audio decoding, related to the pause/resume problems, and that was the updating of the audio decoder clock. When audio and video playback are synchronized the MPEG video driver uses the MPEG audio clock as it's timing reference, which means that it has to be stopped and restarted when video playback control operations occur. Since I had never before seriously tested this, the audio clock wasn't stopped at all and the video driver obligingly continued decoding and displaying pictures until it ran out of buffered data.
<br />
<br />There is currently just one known problem with the MPEG audio decoding: the audio isn't properly attenuated as specified by the driver. This causes little audio distortions at some stream transitions and when buffers run out. There is also a problem with base case audio synchronization but that is hard to trigger and possibly even not audible in many titles so I'll worry about that much later.
<br />
<br />Above I promised to get into the MPEG data buffering and decoding issue. The basic problem is one of conceptual mismatch: the CD-i decoding hardware gets data "pushed" into it (by DMA or direct device I/O) at the behest of the driver, whereas the MPEG decoding code (based on the publicly available mpeg2dec and musicout programs from the MPEG Software Simulation Group) expects to "pull" the data it needs during decoding. Things get messy when the decoding runs out of data, as the code does not expect to ever do so (it was originally written to decode from a disc file which of course never runs out of data until the end of the sequence). Some obvious solutions include putting the decoding in a separate thread (which given multi-core processors might be a good idea anyway from a performance perspective) and modifying it to become restartable at some previous sync point (most easily this would be the start of an audio frame or a picture or picture slice). Both options are somewhat involved although they have obvious benefits, and it may turn out that I will need to do one of them anyway at some point. For now I've avoided the problems by carefully timing calls into the MPEG decoding code so that enough data to decode a single audio frame or video picture should always be available; the MPEG data stream at the system level contains enough timestamp and buffering information to make this possible (in particular, it specifies the exact decoding time of every audio frame or video picture in relation to the timing of the data stream, thus making it possible to make those calls into the decoding code at a time that a valid MPEG data stream will have already filled the buffers far enough).
<br />
<br />The approach depends on the timing of the MPEG data entering the decoder, which means that it does not handle buffer underflow conditions unless you add some kind of automatic decoding that continues even if no more MPEG data appears, and this is basically what I’ve done. In the end it was just relatively straightforward extension of the automatic decoding already there to handle the fact that MPEG audio streams do not have to explicitly timestamp every single audio frame (the CD-i Green Book does not even allow this unless you waste massive amounts of space in each MPEG audio data sector) and would have been needed anyway to correctly decode the last pictures of a sequence, but that had never been tested before.
<br />
<br />For performance and possible patent reasons I have taken care to edit the MPEG decoding code (placing appropriate #ifdef lines at the right places) so that only MPEG 1 video and audio layer I/II decoding code is compiled into the CD-i Emulator executable. This is all that is needed for CD-i anyway and MPEG 2 video and audio layer III greatly complicate the decoding and thus significantly enlarge the compiled code.
<br />
<br />Being somewhat stymied at the FMV front, I next decided to spend some time on another lingering issue. During testing, I often have to do the same exact sequence of mouse actions to get a CD-i application to a problem point and this is starting to be annoying. Input recording and playback are a partial solution to this but then you still have to wait while the application goes through it, which is also annoying and can sometimes take quite some time anyway. The obvious solution is a full emulation state save/restore feature, which I've given some thought and started implementing. It's nowhere near finished, though.
<br />
<br />During the MESS collaboration I spent some time investigating the MESS save/restore mechanism. If at all possible I would love to be compatible for CD-i emulation states, but it turns out to be quite hard to do. The basic internal mechanism is quite similar in spirit to what I developed for CD-i Emulator, but it's the way the data is actually saved that makes compatibility very hard. Both approaches basically boil down to saving and restoring all the relevant emulation state variables, which includes easy things like the contents of cpu, memory and device registers but also internal device state variables. The latter are of course not identical between different emulators but they could probably be converted if some effort was thrown at it and for a typical device they aren't very complex anyway. The MESS implementation uses an initialization-time registration of all state variables; at save/restore time it just walks the registrations and saves or restores the binary contents of those variables. CD-i Emulator has a somewhat more flexible approach; at save/restore time it calls a device-specific serialize function to save or restore the contents of the state variables. The actual registration / serialization codes are structurally similar in the two emulators (a simple list of macro/function calls on the state variables) but the code runs at different times.
<br />
<br />The real problem is that MESS includes very little meta information in the save files: only a single checksum of all the names and types of registered state variables in registration order. This is enough to validate the save data at restore time if the state variables of the saving emulator exactly match those of the restoring emulator, because there is no information to implement skipping or conversions. This holds between different versions or in some case even configurations of MESS emulators, but it holds even more so between MESS and CD-i Emulator! The meta information could of course be obtained from the MESS source code (relatively simply macro modifications could cause it to be written out) but that would require exact tracking of MESS versions because every version could have its own checksum corresponding to different meta information (in this case CD-i Emulator would need meta information sets for every MESS checksum value it wants to support).
<br />
<br />I want CD-i Emulator to be more flexible, especially during development, so I decided to make full meta information an option in the save file. The saved state of every device is always versioned, which allows the save/restore code to implement explicit conversion where needed, but during development this isn't good enough. With full meta information turned on, the name and type of every state variable precedes the save data for that variable in the save file. This allows more-or-less automatic skipping of unknown state variables and when properly implemented the restore code can also handle variable reordering. At release time, I will fix the version numbers and save full metadata information sets for those version numbers so that the same automatic skipping and handling of reordering can be done even if the metadata isn't in the save file (it probably won't be because of file size considerations, although that may turn out to be a non-issue because save files need to include the full RAM contents anyway which is 1 MB of data in the simplest case without any compression, which is of course an option).
<br />
<br />In addition to all of the above, I made some progress on the ROM-less emulation front. First I spent some time reading up on the internals of OS-9 file managers, because writing a replacement for the NRF file manager (NRF = Nonvolatile RAM File manager) seemed the logical next step. Actually writing it turned out not to be that hard, but there were of course bugs in the basic ROM emulation code. Most of them had to do with handlers not calling into the original ROM, which totally screwed up the tracing code. Some new functionality was also needed to properly read/write OS-9 data structures inside the emulated machine from the ROM emulation code; I wanted to implement this in such a way that compilation to "native" 68000 code remains a future option for ROM emulation modules. And of course the massive tracing described in the previous blog post had to be curtailed because it was impossible to see the relevant information in the morass of tracing output.
<br />
<br />The new emulated NRF stores its files in the PC file system and it currently works fine when you start it with no stored files (i.e., the player will boot). In that case it will write out a proper "csd" (Configuration Status Descriptor) file. However, if this file already exists, the player crashes, although I have so far not found any fault in the NRF code. The origin of the problem probably lies elsewhere; I suspect it has to do with the hidden "player_shell_settings.prf" file. This file is read and written by the ROM bootstrap even before OS-9 is running; it does this by directly accessing the NVRAM memory (the file never changes size and is always the first one in NVRAM). Since the bootstrap accesses of this file do not go through the NRF file manager or even the NVRAM driver they are not redirected by the OS-9 emulation. However, later accesses by the player shell *are* redirected and the player shell does not seem able to handle the file not existing in the PC file system in the case where a csd file already exists. Solutions include extending the emulated NRF to always access this particular file from the NVRAM instead of the PC file system or somehow synchronizing the two locations for the file. The latter is probably the easiest route given the fixed location and size of the file, but the former is also useful as it would provide a full reimplementation of the original NRF that could in principle be compiled to native 68000 code to replace the "original" NRF in ROM (this is where gcc comes in as alluded to earlier, since all emulation code is written in C++).
<br />
<br />In either case, I do not want the file manager to directly access emulated NVRAM although it could do so easily, as there is already an internal CNvramPort interface that provides just such access independent of the actual emulated NVRAM chip. The NRF file manager should instead call the NVRAM driver, which means that I need to implement cross-module calling first. It's not really hard in principle, the design has been done but there are a lot of little details to get right (the most obvious implementation uses at least 66 bytes of emulated stack space on each such call which I find excessive and might not even work; smarter implementations require some finicky register mask management or a "magic cookie" stacking approach, the latter having the best performance in the emulation case but being impossible in the native 68000 compilation case). When cross-module calling is working, I can also have the file manager allocate emulated memory and separate out the filename parsing functions by using the OS-9 system calls that provide these functions (the current emulated NRF does not allocate emulated memory which is arguably an emulation error and has the filename parsing coded out explicitly).
<br />
<br />When everything works correctly with the emulated NRF, I have to find some way of integrating it in the user experience. You could always start over without any NVRAM files, but I'd like to have some way of migrating files between the two possible locations without having to run CD-i Emulator with weird options. Extending the CD-i File Extractor (cdifile) by incorporating (part of) the emulated NRF seems the obvious choice, which would also provide me with some impetus to finally integrate it with the CD-i File Viewer (wcdiview) program that's supposed to be a GUI version of cdifile but so far is just a very thin skeleton barely able to graphically display a single CD-i IFF image file passed on the command line (it doesn't even have a File Open menu) and will often crash. A proper implementation would look like Windows Explorer with a tree view on the left (CD-i file system, real-time channels and records, IFF chunk structure, etc) and a variable content display on the right (raw data view, decoded sector view, code disassembly view, graphical image view, audio playback, slideshow playback, decoded MPEG view, MPEG playback, etc).
<br />
<br />That touches on another area in which I did some work last month: the saving of CD-i IFF image files for each emulated video frame. The motivation for this was to bring full-resolution real-time frame saving into the realm of the possible, as it would write only about 2 x (1024 + 280 x (384 + 32)) = 247 KB of raw CD-i video and DCP data per frame instead of 560 x 768 x 3 = 1260 KB of raw RGB. At least on my PC this has turned out not to be the case, however. The data is written out fine, which is not as easy as it sounds since video line data size can vary with each line because of pixel repeat and run-length encoding, but it's still too slow. That being so, I am not really very motivated to extend the CD-i IFF decoding implementation to actually decode this information. Some kind of compression could be an option, but that takes processor time and makes things even harder and possibly slower. Perhaps using another thread for this would be a solution, on a multi-core machine this should not greatly impact the basic emulation performance nor the debugging complexity as the compression code would be independent of the emulation itself.
<br />
<br />So there is still a lot of work to be done, but it's all quite interesting and will provide for some entertaining evenings and weekends in the coming weeks or possibly months.
<br />CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com0tag:blogger.com,1999:blog-4867024730231313742.post-75943481126564035592010-11-08T01:40:00.003+01:002023-05-13T21:16:02.291+02:00ROM-less emulation progressOver the last two weeks I have implemented most of the high-level emulation framework that I alluded to in my last post here as well as a large number of tracing wrappers for the original ROM calls. In the next stage I will start replacing some of those wrappers with re-implementations, starting with some easy ones. <br /><br />It turns out I was somewhat optimistic; so far I have wrapped over 450 distinct ROM entry points (the actual current number of wrappers is 513 but there are some error catchers and possible duplicates). Creating the wrappers and writing and debugging the framework took more effort then I expected, but it was worth it: every call to a ROM entry point described or implied by the Green Book or OS-9 documentation is now wrapped with a high-level emulation function that so far does nothing except calling the original ROM routine and tracing its input/output register values. <br /><br />Surely there aren't that many application-callable API functions, I can hear you think? Well actually there are, for sufficiently loose definitions of "application-callable". You see, the Green Book specifies CD-RTOS as being OS-9 and every "trick" normally allowed under OS-9 is theoretically legal in a CD-i title. That includes bypassing the OS-supplied file managers and directly calling device drivers; there are many CD-i titles that do some of this (the driver interfaces are specified by the Green Book). In particular, all titles using the Balboa library do this.<br /><br />I wanted an emulation framework that could handle this so my framework is built around the idea of replacing the OS-9 module internals but retaining their interfaces, including all the documented (and possibly some undocumented) data structures. One of the nice features of this approach is that native ROM code can be replaced by high-level emulation on a routine-by-routine basis. <br /><br />How does it really work? As a start, I've enhanced the 68000 emulation to possibly invoke emulation modules whenever an emulated instruction generates one of the following processor exceptions: trap, illegal instruction, line-A, line-F. <br /><br />The emulation modules can operate in two modes: either copy an existing ROM module and wrap its entry points, or generate an entirely new memory module. In both cases, the emulation module will emit line-A instructions at the appropriate points. The emitted modules will go into a memory area appropriately called "emurom" that the OS-9 kernel scans for modules. Giving the emitted modules identical names but higher revision numbers then the ROM modules will cause the OS-9 kernel to use the emitted modules. <br /><br />This approach works for every module except the kernel itself, because it is entered by the boot code before the memory scan for modules is even performed. The kernel emulation module will actually patch the ROM kernel entry point so that it jumps to the emitted kernel module. <br /><br />The emitted line-A instructions are recognized by the emulator disassembler; they are called "modcall" instructions (module call). Each such instruction corresponds to a single emulation function; entry points into the function (described below) are indicated by the word immediately following it in memory. For example, the ROM routine that handles the F$CRC system call now disassembles like this: <br /><br /> modcall kernel:CRC:0<br /> jsr XXX.l<br /> modcall kernel:CRC:$<br /> rts<br /><br />Here the XXX is the absolute address of the original ROM routine for this system call; the two modcall instructions trace the input and output registers of this handler. If the system call were purely emulated (no fallback to the original ROM routine) it would look like this: <br /><br /> modcall kernel:CRC:0<br /> modcall kernel:CRC:$<br /> rts<br /><br />Both modcall instructions remain, although technically the latter is now unnecessary, but the jsr instruction has disappeared. Technically, the rts instruction could also be eliminated but it looks more comprehensible this way. <br /><br />One could view the approach as adding a very powerful "OS-9 coprocessor" to the system. <br /><br />If an emulation function has to make inter-module calls, complications arise. High-level emulation context cannot cross module boundaries, because the called module may be native (and in many cases even intra-module calls can raise this issue). For this reason, emulation functions need additional entry points where the emulation can resume after making such a call. The machine language would like this, e.g. for the F$Open system call: <br /><br /> modcall kernel:Open:0<br /> modcall kernel:Open:25<br /> modcall kernel:Open:83<br /> modcall kernel:Open:145<br /> modcall kernel:Open:$<br /> rts<br /><br />The numbers following the colon are relative line numbers in the emulation function. When the emulation function needs to make a native call, it pushes the address of one such modcall instruction on the native stack, sets the PC register to the address it wants to call and resumes instruction emulation. When the native routine returns, it will return to the modcall instruction which will re-enter the emulation function at the appropriate point. <br /><br />One would expect that emulation functions making native calls need to be coded very strangely: a big switch statement on the entry code (relative line number), followed by the appropriate code. However, a little feature of the C and C++ languages allows the switch statement to be mostly hidden. The languages allow the case labels of a switch statement to be nested arbitrarily deep into the statements inside the switch. <br /><br />The entire contents of emulation functions are encapsulated inside a switch statement on the entry number (hidden by macros): <br /><br /> switch (entrynumber)<br /> {<br /> case 0:<br /> ...<br /> }<br /><br />On the initial call, zero is passed for entrynumber so the function body starts executing normally. Where a native call needs to be made, the processor registers are set up (more on this below) and a macro is invoked: <br /><br /> MOD_CALL(address);<br /><br />This macro expands to something like this:<br /><br /> MOD_PARAMS.SetJumpAddress(address);<br /> MOD_PARAMS.SetReturnLine(__LINE__);<br /> return eMOD_CALL;<br /> case __LINE__:<br /><br />Because this is a macro expansion, both invokations of the __LINE__ macro will expand to the line number of the MOD_CALL macro invokation. <br /><br />What this does is to save the target address and return line inside MOD_PARAMS and then return from the emulation function with value eMOD_CALL. This value causes the wrapper code to push the address of the appropriate modcall instruction and jump to the specified address. When that modcall instruction executes after the native call returns, it passes the return line to the emulation function as the entry number which will dutifully switch on it and control will resume directly after the MOD_CALL macro. <br /><br />In reality, the code uses not __LINE__ but __LINE__ - MOD_BASELINE which will use relative line numbers instead of absolute ones; MOD_BASELINE is a constant defined as the value of __LINE__ at the start of the emulation function. <br /><br />The procedure described above has one serious drawback: emulation functions cannot have "active" local variables at the point where native calls are made (the compiler will generate errors complaining that variable initialisations are being skipped). However, the emulated processor registers are available as temporaries (properly saved and restored on entry and exit of the emulation function if necessary) which should be good enough. Macros are defined to make accessing these registers easy. <br /><br />When native calls need to be made, the registers must be set up properly. This would lead to constant "register juggling" before and after each call, which is error-prone and tedious. To avoid it, it is possible to use two new sets of registers: the parameter set and the results set. Before a call, the parameter registers must be set up properly; the call will then use these register values as inputs and the outputs will be stored in the results registers (register juggling will be done by the wrapper code). The parameter registers are initially set to the values of the emulated processor registers and also set from the results registers after each call. <br /><br />The following OS-9 modules are currently wrapped:<br /><br /> kernel nrf nvdrv cdfm cddrv ucm vddrv ptdrv kbdrv pipe scf scdrv<br /><br />The *drv modules are device drivers; their names must be set to match the ones used in the current system ROM in order to properly override those. The *.brd files in the sys directory have been extended to include this information like this: <br /><br /> ** Driver names for ROM emulation.<br /> set cddrv.name=cdapdriv<br /> set vddrv.name=video<br /> set ptdrv.name=pointer<br /> set kbdrv.name=kb1driv<br /><br />The kernel emulation module avoids knowledge of system call handler addresses inside the kernel by trapping the first "system call" so that it can hook all the handler addresses in the system and user mode dispatch tables to their proper emulation stubs. This first system call is normally the I$Open call for the console device. <br /><br />File manager and driver emulation routines hook all the entry points by simply emitting a new entry point table and putting the offset to it in the module header. The offsets in the new table point to the entry point stubs (the addresses of the original ROM routines are obtained from the original entry point table). <br /><br />The above works fine for most modules, but there was a problem with the video driver because it is larger then 64KB (the offsets in the entry point are 16-bit values relative to the start of the module). Luckily there is a text area near the beginning of the original module (it is actually just after the original entry point table) that can be used for a "jump table" so all entry point offsets fit into 16 bits. After this it should have worked, but it didn't because it turns out that UCM has a bug that requires the entry point table to *also* be in the first 64KB of the module (it ignores the upper 16-bits of the 32-bit offset to this table in the module header). This was fixed by simply reusing the original entry point table in this case. <br /><br />One further complication arose because UCM requires the initialisation routines of drivers to also store the absolute addresses of their entry points in UCM variables. These addresses were "hooked" by adding code to the initialisation emulation routine that changes these addresses to point to the appropriate modcall instructions. <br /><br />All file managers and drivers contain further dispatching for the SetStat and GetStat routines, based on the contents of one or two registers. Different values in these registers will invoke entirely separate functions with different register conventions; they really must be redirected to different emulation functions. This is achieved by lifting the dispatching to the emulation wrapper code (it is all table-driven). <br /><br />Most of the above has been implemented, and CD-i emulator now traces all calls to ROM routines (when emurom is being used). A simple call to get pointing device coordinates would previously trace as follows (when trap tracing was turned on with the "et trp" command): <br /><br />@00DF87E4(cdi_app) TRAP[5812] #0 I$GetStt <= d0.w=7 d1.w=SS_PT d2.w=PT_Coord<br />@00DF87E8(cdi_app) TRAP[5812] #0 I$GetStt => d0.w=$8000 d1.l=$1EF00FD<br /><br />Here the input value d0.w=7 is the path number of the pointing device; the resulting mouse coordinates are in d1.l and correspond to (253,495),<br /><br />When modcall tracing is turned on, this "simple" call will trace as follows:<br /><br />@00DF87E4(cdi_app) TRAP[5812] #0 I$GetStt <= d0.w=7 d1.w=SS_PT d2.w=PT_Coord<br />@00F86EE0(kernel) MODCALL[16383] kernel:GetStt:0 <= d0.w=7 d1.w=$59 [Sys]<br />@00F86D10(kernel) MODCALL[16384] kernel:CCtl:0 <= d0.l=2 [NoTrap]<br />@00F86D1A(kernel) MODCALL[16384] kernel:CCtl:$ => <br />@00F8A460(ucm) MODCALL[16385] ucm:GetPointer:0 <= u_d0.w=7 u_d2.w=0<br />@00FA10A4(pointer) MODCALL[16386] pointer:PtCoord:0 <= d0.w=7<br />@00FA10AE(pointer) MODCALL[16386] pointer:PtCoord:$ => d0.w=$8000 d1.l=$1EF00FD<br />@00F8A46A(ucm) MODCALL[16385] ucm:GetPointer:$ => <br />@00F86D10(kernel) MODCALL[16387] kernel:CCtl:0 <= d0.l=5 [NoTrap]<br />@00F86D1A(kernel) MODCALL[16387] kernel:CCtl:$ => <br />@00F86EEA(kernel) MODCALL[16383] kernel:GetStt:$ => <br />@00DF87E8(cdi_app) TRAP[5812] #0 I$GetStt => d0.w=$8000 d1.l=$1EF00FD<br /><br />You can see that the kernel dispatches this system call to kernel:GetStt, the handler for the I$GetStt system call. It starts by doing some cache control and then calls the GetStat entry point of the ucm modules, which dispatches it to its GetPointer routine. This routine in turn calls the GetStat routine of the pointer driver, which dispatches it to its PtCoord routine. This final routine performs the actual work and returns the results, which are then ultimately returned by the system call, after another bit of cache control. <br /><br />The calls to ucm:GetStat and pointer:GetStat are no longer visible in the above trace as the emulation wrapper code directly dispatches them to ucm:GetPointer and pointer:PtCoord, respectively; it doesn't even trace the dispatching because this would result in another four lines of tracing output. <br /><br />As a sidenote, all of the meticulous cache and address space control done by the kernel is really wasted, as CD-i systems do not need these. But the calls are still being made, which makes the kernel needlessly slow; one major reason why calling device drivers directly is often done. Newer versions of OS-9 eliminate these calls by using different kernel flavors for different processors and hardware configurations.<br /><br />The massive amount of tracing needs to be curtailed somewhat before further work can productively be done; this is what I will start with next. <br /><br />I have already generated fully documented stub functions for the OS-9 kernel from the OS-9 technical documentation; I will also need to generate for all file manager and driver calls, based on the digital Green Book. <br /><br />It is perhaps noteworthy that some kernel calls are not described in any of the OS-9 version 2.4 documentation that I was able to find, but they *are* described in the online OS-9/68000 version 3.0 documentation.<br /><br />Some calls made by the native ROMs remain undocumented but those mostly seem to be CD-i system-control (for example, one of them sets the front display text). Of the OS-9 kernel calls, only the following ones are currently undocumented:<br /><br /> F$AllRAM<br /> F$FModul<br /> F$POSK<br /><br />Their existence was inferred by the appropriate constants existing in the compiler library files, but I have not seen any calls to them (yet).CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com1tag:blogger.com,1999:blog-4867024730231313742.post-29616520634522773312010-10-27T01:45:00.002+02:002010-10-27T02:20:37.893+02:00CD-i Emulator CookbookJust a quick note that work on CD-i Emulator hasn't stopped.<br /><br />I have some wild ideas about ROM-less emulation; this would basically mean re-implementing the CD-RTOS operating system. Somewhat daunting; it contains over 350 separate explicit APIs and callable entry points and many system data structures would need to be closely emulated. But it can be done, CD-ice proved it (although it took a number of shortcuts that I want to avoid).<br /><br />I'm not going to tackle that by myself; my current thinking is to make a start by implementing a high-level emulation framework, tracing stubs for all the calls (luckily these can mostly be generated automatically from the digital Green Book and OS-9 manuals) and some scaffolding and samples.<br /><br />One of the pieces of scaffolding would be a really simple CD-i player shell; one that just shows a big "Play CD-i" button and then starts the CD-i title :-)<br /><br />For samples I'm thinking about a few easy system calls like F$CRC, F$SetCRC, F$SetSys, F$CmpNam, F$PrsNam, F$ID, F$SUser, F$Icpt, F$SigMask, F$STrap, F$Trans, F$Move, F$SSvc (I may not get through the entire list) and a new NVRAM File Manager (NRF).<br /><br />It would be nice to do a minimal UCM with Video and Pointer driver so that the simple CD-i player shell would run, but that might be too much. We'll see.<br /><br />However, it's the new NRF that would be the most immediately interesting for CD-i Emulator users. It would intercept NVRAM access at the file level and redirect it to the PC file system (probably to files in the the nvr directory). This would allow easy sharing of CD-i NVRAM files (e.g. game-saves) over player types or between CD-i emulator users.<br /><br />To allow all of the above and clean up some dirty tricks that were needed for input playback and handling Quizard, I've done some internal restructuring of CD-i Emulator. In particular, I introduced a new "handler" class beneath the existing "device" and "memory" classes (which are now no longer derived from each other but from a common "component" base class). This restructuring isn't finished yet, but it will allow the input and Quizard stuff to become handlers instead of devices (the latter is improper because they shouldn't be visible on the CD-i system bus).<br /><br />The new "module" class (a subclass of handler) will be used to add high-level emulation of OS-9 and CD-RTOS rom modules. I want to preserve the interfaces between the modules and the public data structures as much as possible, because it will allow a gradual transition from "real" to "emulated" modules.<br /><br />To prepare for all of the above I had to do some fairly heavy design, which caused me to properly write down some of the design information and tradeoffs for the first time. This will be invaluable information for co-developers (if they ever materialize), hence the title "CD-i Emulator Cookbook". Well, at present it's more like a leaflet but I hope to expand it over time and also add some history.<br /><br />Pieces of the cookbook will be added to the CD-i Emulator website if I feel they're ready.<br /><br />I've also been giving some thought on a collaboration model for the ROM-less emulation. If there is interest I could do a partial source release that would allow other developers to work on the ROM-less emulation. This release would *not* contain any non-video chipset emulation but it would contain "generic" CD-i audio and video decoding. You would still need to use (part of) a system ROM (in particular the OS-9 kernel and file managers) until enough of the emulation is finished.<br /><br />I'm still considering all this, but I wanted to get the word out to see if there is interest and to show that I haven't abandoned the project.<br /><br />Potential co-developers should start boning up on OS-9 and CD-RTOS. All of the technical OS-9 documentation is online at ICDIA and links to the digital Green Book can also be found.CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com0tag:blogger.com,1999:blog-4867024730231313742.post-50746421903269987892010-10-12T03:35:00.002+02:002010-10-12T03:59:40.981+02:00Release blues and Quizard 1.7Saturday I released CD-i Emulator 0.5.3-beta1. That was a big milestone for me.<br /><br />The Internet didn't seem to feel that way. There was some interest but it was nothing compared to five years ago when the first version came out. Oh well...<br /><br />Sunday a "disc activity" indicator was suggested by a MESS tester. It seemed cool so I added it by coloring the background of the "disc activity" textbox:<br /><br />blue = reading TOC data<br />red = reading CD-audio data (mode 0)<br />yellow = reading CD-ROM data (mode 1)<br />green = reading CD-i data (mode 2)<br /><br />I also wrote a proof-of-concept compatibility report table page for the web site so that I could view the reports entered, so far by a single user only (except myself). It needs more work, I won't tell you the URL yet :-)<br /><br />A few days ago the MESS CD-i programmer requested help in figuring out why the Quizard 1.7 game didn't work and I provided some serial port help. In the process we deduced that the 1993-vintage 68070 datasheets on the Internet all have some of the UART command bits wrong. But I found a few datasheets dated April 1991 which have it right (and so does my 68070 User Manual, luckily, which is dated November 1991). With this fixed in MESS, both emulators produced the same effect: some loading activity and then remaining at a black screen.<br /><br />Now, Quizard is one of those rare CD-i titles that require external hardware, in this case the so-called "CD-i Jamma" board that interfaces a CD-i player to the industry-standard (at one time) arcade enclosure interface. Bas wrote about this board in his Interactive Dreams blog <a href="http://cdii.blogspot.com/2007/06/cd-i-arcade-conversions.html">here</a> and <a href="http://cdii.blogspot.com/2009/11/quizzard-jamma-board-for-cd-i.html">here</a>.<br /><br />Part of the external interface is a "security" option that causes the game not to run unless the proper hardware is present, and this is what was causing Quizard to remain at a black screen.<br /><br />Although it is certainly possible in principle to emulate the external board, including its security features, I was in the midst of releasing CD-i Emulator so I let it go for some time.<br /><br />But today Just Deserts/Harmony/MooglyGuy (the main MESS CD-i developer) posted details about how to "patch" Quizard to avoid the security check and he also posted sufficient details to allow emulation of the arcade case buttons. So I dove in...<br /><br />It took me an hour or two to create a special "quizard" device for CD-i Emulator that patches Quizard as needed and connects to the serial port to give the CD-i title the communications that it wants. For now I simply intercept PC keyboard digits 0 to 9 and pass them to Quizard as "button" information.<br /><br />It works alright: Quizard plays its leader and starts "attract" mode and I can even play a game!<br /><br />The following movie shows only the leader, however:<br /><br /><object width="425" height="344"><param name="movie" value="http://www.youtube.com/v/Yjvb-0WERrI?hl=en&fs=1"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Yjvb-0WERrI?hl=en&fs=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object><br /><br />Note also the green flashing disc activity indicator!CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com1tag:blogger.com,1999:blog-4867024730231313742.post-63148304753766007232010-10-10T00:09:00.004+02:002023-05-13T21:21:23.613+02:00CD-i Emulator 0.5.3-beta1 released!I have just released the new version of CD-i Emulator. It has received very limited pre-beta testing, but that's what public betas are for.<br /><br />I've changed relatively little since the prebeta1 version.<br /><br />The most import change is the addition of the <b>Help</b> | <b>Report</b> menu option that contains a link to the new <a href="http://www.cdiemu.org/report">Report</a> section of the website and will automatically fill in most of the information fields on that form when clicked.<br /><br />Unfortunately, to make this work properly I had to touch most files in the <b>sys</b> directory to add correct player model, extension and digital video cartridge identification.<br /><br />I've also added checksum reporting of DV cartridges, let's find out how complete my current collection is. These checksums will not (yet) trigger an "Unknown ROM" dialog if unknown, but they are posted with compatibility reports.<br /><br />The <b>-writepng</b> option also had to be fixed to support macros in its filename, otherwise each video frame would overwrite the previous one! The macros that I've decided to support for now are <b>$seq$</b>, which produces a 6-digit sequence number and <b>$time$</b> which produces the 6-digit frame time (mmssff).<br /><br />The Release Notes have been modified to include these changes.<br /><br />Use of the input recording/playback functions revealed a number of bugs; I've fixed those and also added more player information recording so that recorded input files contain enough information for compatibility reports (this isn't used yet).CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com0tag:blogger.com,1999:blog-4867024730231313742.post-27934289970846540292010-10-04T00:23:00.005+02:002010-10-04T00:59:28.682+02:00Website updates, bugfixes, compatibility reportsToday I updated the <a href="http://www.cdiemu.org">CD-i Emulator</a> website for the upcoming beta release and fixed some remaining bugs, mainly with input recording/playback.<br /><br />I updated the <a href="http://www.cdiemu.org/relnotes">Release Notes</a> section, put up the hopefully final version of the Full Release Notes, added more screenshots and YouTube embeds and did some miscellaneous text edits. I also updated the <a href="http://www.cdiemu.org/cditypes">CD-i Types</a> section and added a download for it.<br /><br />It was my intention to release tonight, but that didn't happen because the closed pre-beta testers aren't ready yet. I'll give it a few more days.<br /><br />My next project will be updating the <a href="http://www.cdiemu.org/titles">Title Support</a> section of the website; I want to replace the static table with a much more dynamic one that can be expanded and sorted in various ways, based on a database of actual compatibility reports for specific CD-i player ROMs and CD-i titles that could be entered online.<br /><br />I might even accept MESS CD-i compatibility reports to provide a basis for comparison. Users would also be able to "me too" on reports.<br /><br />I would also like to add a "Report Compatibility" option to CD-i Emulator; that would allow automatic filling in of most of the report fields so that entering a compatibility report becomes pretty much a question of clicking only a "compatibility class" button and possibly entering some notes (fields like Reporter could be remembered on the reporter's PC using cookies). It should be easy to add the CD-i Emulator part of this; I might even do it for the current beta if the testers take long enough :-)<br /><br />For crashes or decoding issues, it would also be useful to allow uploading of input recordings. Actually, uploading a "good recording" would be nice even for successful reports. I could even add an "autorecord" setting to CD-i Emulator to make recording easy; the performance hit should be minimal.<br /><br />This would also allow "batch" uploading of compatibility reports at some later time; input recordings contain all of the necessary information except for the compatibility class and notes and these could easily be added with input annotations, which I was planning to add anyway.<br /><br />Unfortunately, uploading a file cannot be automated easily from within CD-i Emulator: the user will have to manually browse for the file. Another way to handle this would be to automatically generate an e-mail compatibility report...CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com0tag:blogger.com,1999:blog-4867024730231313742.post-87791264682966919952010-10-02T12:00:00.005+02:002010-10-02T14:59:04.425+02:00Lucky Luke on YouTubeI have just posted a "proof of concept" demonstration of CD-i Emulator MPEG decoding on YouTube:<br /><br /><object width="410" height="330"><param name="movie" value="http://www.youtube.com/v/8p0MisqAxoA?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/8p0MisqAxoA?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="410" height="330"></embed></object><br /><br />The Philips Media bumper animation is MPEG (audio and video) and so is the audio for the piano sequence. The in-game crash is due to an MPEG sound effect.<br /><br />This is with a Gate Array MPEG AH01 cartridge (22ER9141 F1 AH01); as the cartridge types get newer the decoding starts working lesser and lesser. Later GMPEG cartridges will crash earlier in the gameplay, VMPEG and IMPEG will not play MPEG at all. This is simply because I haven't gotten around to fixing those things yet; there are still major bugs in the buffering of the MPEG data and while that remains unfixed there is no point.<br /><br />The magenta border indicates "beta" quality; it is not that hard to display the proper color (black in this case), but this will remind everyone that it is a work in progress.<br /><br />Many other DVC titles will play their Philips bumper but crash soon thereafter; some others won't even get that far. In some cases this is not even due to MPEG decoding issues but to various "other" reasons for crashing (The 7th Guest is a notorious example).<br /><br />I have also put up a new draft of the upcoming version 0.5.3-beta1 Release Notes on the website.CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com0tag:blogger.com,1999:blog-4867024730231313742.post-77914020009686476612010-10-02T00:19:00.000+02:002010-10-02T00:21:25.776+02:00Release NotesI have just put up a first draft of the Release Notes for the upcoming version 0.5.3-beta1 on the CD-i Emulator website.<br /><br />More info coming...CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com0tag:blogger.com,1999:blog-4867024730231313742.post-82382748997023843652010-10-01T00:39:00.002+02:002023-05-13T21:21:33.530+02:00CD-i Emulator pre-beta releasedI have just released the pre-beta version of CD-i Emulator to my beta test group.<br /><br />This version is intended for quick tests; if nothing drastically happens, the final beta1 release will happen in a few days. <br /><br />In the meantime, I will be writing release notes and updating the <a href="http://www.cdiemu.org">CD-i Emulator</a> web site. The final release notes will appear in the <a href="http://www.cdiemu.org/relnotes">Release Notes</a> section of the web site.<br /><br />I managed to finish the input recording/playback code and also fix a few minor bugs.<br /><br />Bug reports, comments or suggestions about this version should be posted on the closed CD-i Emulator beta Testing Forum.CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com0tag:blogger.com,1999:blog-4867024730231313742.post-35827208074928477522010-09-30T00:34:00.005+02:002010-09-30T01:20:08.859+02:00Finalizing input record/playbackToday I resumed working on the input record/playback code to get it towards its final specification for this beta.<br /><br />I want the record/playback code to be generic, by which I mean:<br /><br />1. Recorded input files must be dumpable (e.g. by cdifile) without having to know intimate details of the recorded devices and messages. This can be achieved by labeling all input channels with name and type and recording the formats of all input message types, which is now mostly done.<br /><br />2. Recorded input files must contain all the information required for faithful playback, which includes things like CD-i player model, DVC cartridge type, extension roms, PAL/NTSC and special startup options and emulated disc insertions. <br /><br />The ideal is that "wcdiemu -playback" will just work without the need to fiddle with emulator options to reproduce the recording environment. This is now also mostly done except for the disc insertions (they are recorded but cannot yet be played back).<br /><br />3. It must in principle be possible to play back on a different CD-i player model or with a different DVC cartridge. This means that the input channel matching must be somewhat "intelligent". The groundwork for this is in place but the actual channel matching is not yet there.<br /><br />All of the above are needed to get the feature usable for extensive compatibility testing, which is a goal of this beta: it should be possible to exchange input recordings that reproduce crashes or rendering bugs, even when they require some time to reproduce. Emulator state snapshots would make this even better, but that is too much work for now.<br /><br />Recorded input files are in IFF format with the following generic structure:<br />- each file contains a single FORM chunk of type INPT (recorded input)<br />- the first chunk inside the FORM is an IVER chunk (version information)<br />- the next chunk inside the FORM is an ICHN chunk (channel information)<br />- the final chunk inside the FORM is an IMSG chunk (input messages)<br /><br />Input messages are recorded in binary format to keep their size small; the first time that a message type is used, the message format string is prepended.<br /><br />The cdifile dumping code will not be released with this beta, there's too much unfinished code in there (i.e. the -dir[ectory] option to display the directory of a CD-i disc image file).<br /><br />I will attempt to finish this tomorrow, but it's just barely achievable...<br /><br />Until then, you'll have to do with this picture:<br /><br /><a href="http://www.cdiemu.org/img/cdiemu-v053b1.gif"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 392px; height: 322px;" src="http://www.cdiemu.org/img/cdiemu-v053b1.gif" border="0" alt="" /></a>CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com0tag:blogger.com,1999:blog-4867024730231313742.post-61101314292694443242010-09-28T00:13:00.003+02:002010-09-28T00:39:51.847+02:00HousecleaningToday I did some housecleaning for the upcoming beta, which I'm still hoping to release before the end of this month.<br /><br />I decided to keep the current somewhat buggy MPEG decoding stuff in the beta, which meant that I had to clean up the MPEG ROM detection logic so that it actually works (until now I always used the -dvc option to explicitly force the DVC model).<br /><br />The MPEG ROM detector will now only use the supplied "dummy" xmpeg.rom file if it cannot find another recognized ?mpeg*.rom file. If it does find such a file, the DVC type will now be displayed in the CD-i Emulator title bar (GMPEG, IMPEG, VMPEG). For GMPEG the AH0x number is also displayed, as the AH00/AH01 cartridges are very different from the AH02/AH03 ones.<br /><br />Some little-known DVC tidbits:<br />- The Philips CD-i 370 uses VMPEG hardware but at a different memory address<br />- The Philips CD-i 615 uses IMPEG hardware but the ROM also contains non-FMV software<br />- The DVS VE-200 and LG GDI-700 use IMPEG hardware but at a different memory address<br /><br />More details on the state of the MPEG emulation will be available in the beta release notes.<br /><br />Earlier I had started using a manifest file to get a newer common controls DLL, thus modernizing the visual "look" of CD-i Emulator somewhat. However, this caused Windows Vista and Windows 7 to stop using "virtual store" redirection of the cdiemu.ini file which broke all settings stuff (including the recently used list).<br /><br />Today I figured out that leaving out the UAC "requested level" entry from the manifest restores the "virtual store" redirection. This is good enough for this beta.<br /><br />I also killed the "file registration" code because it would hijack any existing non-beta registration (this has nothing to do with licensing but with the way Windows finds executables to open certain files).<br /><br />Finally, I added video decode skip validation. This gets a bit technical...<br /><br />In CD-i players, video decoding steals bus cycles and thus slows down the machine. The amount of bus cycles stolen depends on the video mode, pixel repeat settings and, for run-length modes, on the actual data. <br /><br />If the emulation starts to lag behind, CD-i Emulator starts skipping the decoding of video frames. Previously, I used a "worse-case" estimate for the number of stolen bus cycles in this case. However, this introduces problems with input recording and playback: if frame skipping differs (which is almost guaranteed to be the case), the playback will start to "drift" from the recording. Over many frames this will result in an incorrect playback.<br /><br />I coded a "SkipLine" routine that does no actual video decoding like "DecodeLine" but it does decode just enough to accurately determine the number of stolen bus cycles. This routine is now used when the video frame is skipped.<br /><br />The validation consists of running <strong>both</strong> routines when the video frame is not being skipped and ensuring that both "steal" the same number of bus cycles.CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com0tag:blogger.com,1999:blog-4867024730231313742.post-24987530755338123622010-08-01T00:11:00.006+02:002010-08-01T00:42:26.856+02:00Quick status updateIt's been just over a half year since my last posting here. A quick status update...<br /><br />In March I upgraded my trusty old desktop PC to a new laptop with a dual-core Pentium T4300 at 2.1 GHz. In the process of migrating my data I broke my old P-ATA hard disk :-(<br /><br />The breakage was very minor (a broken connector lead) and seemed to be fixable with some soldering, but it took me nearly two months to get around to obtaining the proper cable and connector. Then I quickly made a full copy to a new S-ATA hard disk and breathed a sigh of relief.<br /><br />I did have a backup but it was months old and did not include my most recent CD-i Emulator work, so I really wanted the up-to-date data.<br /><br />However, as Charles commented on my previous entry, Visual Studio 6 has problems working under Windows 7. That demoralized me such that I left it hanging for a few months more. My older CD-i Emulator development builds didn't even work under Win7 :-(<br /><br />Yesterday I finally got around to doing a full restore from the backup disk to my laptop and I also installed Visual Studio 2010 just to take a look at it.<br /><br />Having done that, I realized that I could try building CD-i Emulator again!<br /><br />I just finished doing that, and after finding the single source line that generated the 300+ errors I got on the first build, it appears that I now again have a working development build of the most recent CD-i Emulator, optimistically labeled v0.5.3-beta1. It seems to run like a charm, doing 50/50 frames on non-FMV titles and even 34/50 on my FMV test cases. Wow!<br /><br />Using Visual Studio 2010 means that the minimum system requirement is now Windows XP, as earlier Windows versions are no longer supported as C++ build targets. But I don't think that should really be a problem.<br /><br />At the end of next month it will be five years since the original CD-i Emulator v0.5.2 public release; I'm hoping to release 0.5.3-beta1 before that.<br /><br />Please bear with me...CD-i Fanhttp://www.blogger.com/profile/06713298841073508148noreply@blogger.com0