MAMEWorld Forums - EmuChat - Re: Star Rider VideoGraphicGenerator timers finally solved after many hours :)

> I agree, unbelievably cool!
>
> Laserdisc games were some of my favorites, I'm glad to see progress made in
> documenting them. They have to be moving into "High risk of being lost forever"
> territory now don't they? Those discs are pushing 30 years old.
>
> Regardless, I remember doing MIPS emulation in my classes, which was fun, but nowhere
> near the level of complexity in what Matt achieved. I love reading about this stuff
> so I can get a better idea of how real emulation is done.

We've captured almost all of the rare/interesting discs that we'd be sad about losing using techniques we've honed over the past 10+ years. So the chance of completely losing them is pretty much gone. However, we are continually refining our capturing technique and our next goal is to capture the raw voltage coming from the laserdisc player's composite port using a analog->digital converter and that is going to take some FPGA knowledge that I don't currently have (but will work to acquire once I am done with my current projects). If we have a complete raw voltage dump of the entire disc, I think it will be pretty safe to say that we will have permanently archived them. Good news is most of my discs I've owned since 1999,2000,2001 are in pretty much the same state they were when I bought them. The advantage of living in a dry climate?

Re: Star Rider, I made a big break through tonight and got the williams "rug" pattern showing up. Video below:

http://my-cool-projects.blogspot.com/2014/02/star-rider-boot.html

The details:
Using the schematics to understand how the video RAM maps to the pixels rendered on the RGB monitor is quite a difficult and slow process.
Total video memory capacity: 384x256 pixels
Total video memory that is addressable by the CPU and blitter ICs: 320x256 pixels
^ - this took me FOREVER to figure out! so hard!!! (and yes, now that I've solved it, it seems kinda obvious when you consider other Williams games, but hindsight is so much clearer)
The video memory is composed of six 8k DRAM chips for a total storage capacity of 49,152 bytes. Each byte contains two pixels, thus giving a total capacity of 98,304 pixels. The video hardware will render 6 pixels every 1 microsecond to the monitor (via a 6 MHz clock). The video hardware also uses the horizontal counters (divided by 2) to keep track of the horizontal position of the CRT gun. The horizontal counters loop from 0-129 which means that horizontal resolution is effectively (129/2 * 6) which is 384. Boom! This took me forever to validate even though I suspected it for quite some time because I had mistakenly calculated the DRAM size as being 2k, not 8k. 98,304 divided by 384 gives us our vertical resolution of 256.
How did I conclude that the addressable video memory is 320x256? I did it by emulating the game far enough to take some screenshots. But it's easier in hindsight. I already knew that the video RAM ranges from 0-0x9FFF so simply dividing 0xA000 by 256 gives 160 bytes per line. And there are 2 pixels per byte, hence 320 pixels per line.
How does the game hardware know where to put these 320 pixels on this 384 pixel line? By the Horizontal PROM, U74, which provides some margins on the left and right side to account for the horizontal blanking/sync non-visible area.