Cdrom ode up for preorder

[dshadoff]

It's important to note a few points about what this is, what it isn't, and why the creator states that he wanted to make such a thing in the first place - because most of this information isn't available in English.

I don't actually have an opinion about this machine because I've never seen one in real life.  This information may change - or reinforce - your current opinion.

Video section:

He said that he wanted to make the PC Engine compatible with newer, digital TVs, because he was worried that CRTs are becoming rarer, and wanted them to continue on.  While this statement may seem to be an exaggeration of today's environment, it will be true in the long term.

Because there is a small but real difference in the scan rate between NTSC and HD (ie. 29.997Hz versus 60Hz), there are some technical compromises which were unavoidable (at least, without changing the clock generator crystal inside the PC Engine).

Because of the frame rate difference, I would assume that there would be a hesitation (apparent frame 'skip') once every several seconds.  I had read about this, and that it was 'reduced', but it's not clear to me how much remains.

The term 'scaler' is an oversimplification.  The image is created in an internal frame buffer and output from there (not a line buffer).  My understanding (although I could be wrong) is that this image is built entirely by bus snooping, including background and sprite, and reconstructing the digital values... not based on scanline output from the PC Engine.  Watching R-Type for sprite flickering would prove this (or disprove).

So in other words, it's hardware emulation.  This has good points and bad points (as we all know).
Good points include:
- may get rid of sprite flicker
- SuperGrafx support can in theory be added (although I don't think that it is)

Bad points:
- may not be 100% accurate
- occasional frame jerk

It would be nice to have this matched with an emulated PC Engine with a tweaked clock rate so that the skipped frames don't occur.


CDROM section:

This is clearly emulation, and he currently has something like 75% compatibility.  This is better than early software emulation efforts (back in the '90's), but not quite where we would all like it to be.

On the other hand, he has modified things he felt were drawbacks.  Because of the way PC Engine software was created, these modifications may reveal latent bugs in the original code which wouldn't show on original hardware, but may show when one small variation is introduced.  Thus, these 'improvements' may reduce overall compatibility.

- Seek time reduced to basically nothing
- data read speed accelerated
- Based on the Youtube videos, I believe that ADPCM playback noise (high-frequency artifacting) has been reduced

And it's the first no-moving-part CDROM hardware replacement available.

On the one hand, I am very impressed at the technical work invested in this product, and how far it has come.  I am of course disappointed that the price is high, but no matter what the price, only a limited number of people would ever buy such a thing, so it's a choice of "high price" versus "not worth anybody's time to invest in its creation".  Given this choice, I would prefer for the device to exist.

...But I'll probably wait for the next iteration before pulling out my wallet.

[ccovell]

My understanding (although I could be wrong) is that this image is built entirely by bus snooping, including background and sprite, and reconstructing the digital values... not based on scanline output from the PC Engine.  Watching R-Type for sprite flickering would prove this (or disprove).

So in other words, it's hardware emulation.

Sorry, I don't think you've got this right.  It is most likely sniffing the pixel bus in the same way that the NESRGB sniffs the PPU pixel bus & palette register writes, and re-builds colour values from the indexes 0-511 that the bus sends out.  It does not "look" into the VDC to get sprite tables, etc.  If the VDC can't display all sprites on a line, it just stops (cause it ran out of cycle time on that scanline) and no external device can reconstruct those lost sprites -- well, unless it halts the CPU and access the VDC and VRAM itself, and that would demolish compatibility.

Anyhow, its creator did explain how it works in general terms here, when he started working on the project: http://forums.nesdev.com/viewtopic.php?f=23&t=13502

[dshadoff]

OK, I see what you mean.

So then it creates a full frame 'buffer' based on the raster scan (although digital values), with its own color table based on bus sniffing (i.e. writes to $080x), and outputs them according to a whole separate timing cycle from the PCE's.  If true, R-Type will still have the flashing sprites when there are 17 on a scanline.

I had never supposed that it "looked into the VDC" however; I believed that it was implementing its own emulated version of the VDC based on more bus snooping (i.e. writes to $0400).  This is also possible, but a bit more work (though maybe not as much as it seems).  Maybe a future device (from him or somebody else) could go one step further and implement the 6280 and 6270, at a clock appropriate for HD.

[ccovell]

Well, something like that, except $080x is the sound hardware, and $040x is the VCE.  :-"

[dshadoff]

Doh !
I've been away from the system too long...