> Star Rider decodes manchester/philips codes beyond just the picture number from the
> video signal. During the racing track segments there is a bunch of schlop toward the
> bottom of the screen that it decodes, probably as a way to workaround small memory
> sizes of the era (similar to how MACH 3 put target data in the audio stream).
Makes sense, and from the screenshots where you can see the normally masked-off screen areas on the cabinet the data is very clearly present, but as it's been years since I've seen a real Star Rider cabinet I'm going off of memory and flyer images on this one. Sounds like Williams and Gottlieb took somewhat different approaches to the same problem.
> I have
> not emulated the decoder for this and it will probably take me a little while to come
> up with a decent solution for the in-game stuff. Should be very doable though.
Interesting - so the decoder is in hardware? I guess that makes sense if there's no image processing done in software other than graphic generation for genlock... And since the video expander would also need to be tied in somewhere that's understandable. Neat approach on Williams' part, though.
> Also, I have not touched the sound PCB and will probably put that off since it
> probably is not required to play the game
Well, maybe not *required*... But it would definitely be a nice-to-have. Just saying 
> Also need to code up some trickery to make the video expander work.
This is the one I was *really* curious about. From what I remember of reading a description of how it worked (again, years ago), it basically did pans of the frame to simulate turning into curves, etc. From what I recall, it was pretty much an entirely analogue process (e.g., no framebuffer), with the exception of being told what to do digitally.
> Other than that, I believe I am on the downhill slope
Glad to hear it. Very much looking forward to seeing where your progress leads, regardless of where that may ultimately end up in terms of emulation.
> > Out of curiosity, how close to the other Williams rug-pattern hardware of the era
> is
> > Star Rider?
>
> I am not too familiar with the other hardware. But I do know that most of them were
> designed to completely halt when the blitter chips were active; star rider does not
> do this, but instead raises FIRQ when the blitter is active.
Interesting. I wonder if that's to allow for the multiple levels of video muxing (LD read, video expander transforms, genlock) going on.
> Seems like the blitter chips were "hard-coded" to handle a vertical resolution of 256
> pixels (240 visible perhaps), with each pixel being one nibble (16 colors), so I
> would imagine every Williams game that uses them must be 256 pixels tall with 16
> colors (someone can confirm that if they want). The width is variable.
>
> Like other williams games, Star Rider heavily relies on many PIA6821's and M6809's.
> If a problem needed to be solved, the solution was apparently to throw more PIA6821
> and M6809's at it until it was fixed
Sounds like the 'use what we've got on the shelf, then make it work' approach vs. outright new design for specific components of the game.
Thanks for taking the time to reply, by the way. The insight into it is definitely appreciated.
|
Index 
Flat 
Re: Star Rider VideoGraphicGenerator timers finally solved after many hours :)
Reply
