|
Star Rider VideoGraphicGenerator timers finally solved after many hours :)
#321753 - 02/10/14 07:03 AM
|
|
|
Star Rider's Video Graphic Generator (VGG) board is responsible for creating most (all?) of the timers used by the game and the system they came up with is extremely wacky and confusing but also kind of a neat idea. It's kinda like someone writing really "clever" C code that does something cool but which impossible to maintain because no one else understands it and the guy who wrote it won't understand it either in 6 months.
I've been slowly working my way through all of the VGG schematics and have "solved" a large part of it but I put off trying to understand the timers as long as possible due to the unpleasantness of the task. I've reached a point where I could not proceed without understanding them, so here I am.
Check out the results at: http://my-cool-projects.blogspot.com/2014/02/star-rider-vgg-timers.html
|
|
|
|
Re: Star Rider VideoGraphicGenerator timers finally solved after many hours :)
[Re: Matt Ownby]
#321808 - 02/11/14 01:18 AM
|
|
|
Very cool stuff!
How did you get the readouts of the cycles? Did you Trojan a board or was it synced to some kind of meter? Getting RAS and CAS could not have been easy!
|
|
|
|
Re: Star Rider VideoGraphicGenerator timers finally solved after many hours :)
[Re: Rygar9]
#321809 - 02/11/14 01:27 AM
|
|
|
> Very cool stuff!
>
> How did you get the readouts of the cycles? Did you Trojan a board or was it synced
> to some kind of meter? Getting RAS and CAS could not have been easy!
Basically, via emulation for now. I got a dump of the PROM (U114) from Phil Bennett and wrote a little C program to exercise it, while emulating the 12 MHz clock source.
In the (near) future, I hope to get a logic analyzer capture from the real hardware. Hopefully it is very close 
UPDATE: Warren Ondras made a capture for me from real hardware last night and I added it to my blog. It matches my emulated version perfectly
Edited by Matt Ownby (02/11/14 03:40 PM)
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9714
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Star Rider VideoGraphicGenerator timers finally solved after many hours :)
[Re: Matt Ownby]
#321832 - 02/11/14 06:18 PM
|
|
|
> UPDATE: Warren Ondras made a capture for me from real hardware last night and I added
> it to my blog. It matches my emulated version perfectly
That's unbelievably cool. Nice work!
|
|
|
|
Re: Star Rider VideoGraphicGenerator timers finally solved after many hours :)
[Re: R. Belmont]
#321849 - 02/12/14 01:55 AM
|
|
|
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.
|
|
|
|
Re: Star Rider VideoGraphicGenerator timers finally solved after many hours :)
[Re: R. Belmont]
#321859 - 02/12/14 08:08 AM
|
|
|
> > UPDATE: Warren Ondras made a capture for me from real hardware last night and I
> added
> > it to my blog. It matches my emulated version perfectly
>
> That's unbelievably cool. Nice work!
Thank you, sir. I appreciate the encouragement!
|
|
|
|
Re: Star Rider VideoGraphicGenerator timers finally solved after many hours :)
[Re: Rygar9]
#321860 - 02/12/14 08:16 AM
|
|
|
> 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.
|
|
|
| casm |
|
Cinematronics > *
|
|
|
|
|
Reged: 08/27/07
|
|
Posts: 668
|
|
|
|
|
|
Send PM
|
|
|
Re: Star Rider VideoGraphicGenerator timers finally solved after many hours :)
[Re: Matt Ownby]
#321950 - 02/14/14 01:00 AM
|
|
|
|
|
|
Re: Star Rider VideoGraphicGenerator timers finally solved after many hours :)
[Re: casm]
#321979 - 02/14/14 06:28 PM
|
|
|
|
|
| casm |
|
Cinematronics > *
|
|
|
|
|
|
Reged: 08/27/07
|
|
Posts: 668
|
|
|
|
|
|
Send PM
|
|
|
Re: Star Rider VideoGraphicGenerator timers finally solved after many hours :)
[Re: Matt Ownby]
#321985 - 02/14/14 07:52 PM
|
|
|
> And even further!
>
> http://my-cool-projects.blogspot.com/2014/02/star-rider-13-feb-2014.html
*Jaw drops*
So is it safe to say that at this point it's largely a case of hooking up the inputs and feeding in the video? I realise that there's probably more to do than just that, but seeing the hardware pass POST is just awesome.
Out of curiosity, how close to the other Williams rug-pattern hardware of the era is Star Rider?
FWIW, this has been on my LD most-wanted list for years, along with Interstellar Zangus. Wasn't holding my breath on either one, but this is really fantastic to see Now if a Zangus boardset would just surface...
|
|
|
|
Re: Star Rider VideoGraphicGenerator timers finally solved after many hours :)
[Re: casm]
#321989 - 02/14/14 09:30 PM
|
|
|
> > And even further!
> >
> > http://my-cool-projects.blogspot.com/2014/02/star-rider-13-feb-2014.html
>
> *Jaw drops*
>
> So is it safe to say that at this point it's largely a case of hooking up the inputs
> and feeding in the video? I realise that there's probably more to do than just that,
> but seeing the hardware pass POST is just awesome.
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). 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.
Also, I have not touched the sound PCB and will probably put that off since it probably is not required to play the game
Also need to code up some trickery to make the video expander work.
Other than that, I believe I am on the downhill slope
>
> 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.
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
>
> FWIW, this has been on my LD most-wanted list for years, along with Interstellar
> Zangus. Wasn't holding my breath on either one, but this is really fantastic to see
> Now if a Zangus boardset would just surface...
Cool!
|
|
|
| casm |
|
Cinematronics > *
|
|
|
|
|
|
Reged: 08/27/07
|
|
Posts: 668
|
|
|
|
|
|
Send PM
|
|
|
Re: Star Rider VideoGraphicGenerator timers finally solved after many hours :)
[Re: Matt Ownby]
#321991 - 02/14/14 10:27 PM
|
|
|
> 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.
|
|
|
|
Re: Star Rider VideoGraphicGenerator timers finally solved after many hours :)
[Re: Matt Ownby]
#322003 - 02/15/14 03:06 AM
|
|
|
Very good progress. I don't understand anything about it but it must be very satisfying when you finally figure something out and see it boot for the first time. I guess that holds true with emulating anything. It must be a "Holy sh*t, I got it" moment
I know we won't see it in Daphne but hopefully someone can use your work for MAME one day.
It's also nice to know your team has captured video of the non emulated games.
Thanks for sharing your findings.
|
|
|
|
Re: Star Rider VideoGraphicGenerator timers finally solved after many hours :)
[Re: Antny]
#322036 - 02/15/14 05:36 PM
|
|
|
> It must be a "Holy sh*t, I got it" moment
I don't know about anyone else, but for me it's usually a bit of an anti climax.
Things are hard when you don't know how they should work, once you have figured it out then it's easy.
|
|
|
|
STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: Matt Ownby]
#322248 - 02/19/14 06:51 PM
|
|
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: Matt Ownby]
#322250 - 02/19/14 07:43 PM
|
|
|
|
|
Stiletto |
|
They're always after me Lucky ROMS!
|
|
|
|
|
|
Reged: 03/07/04
|
|
Posts: 6472
|
|
|
|
|
|
Send PM
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: Matt Ownby]
#322251 - 02/19/14 08:36 PM
|
|
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: Matt Ownby]
#322258 - 02/19/14 09:31 PM
|
|
|
Awesome. Congratulations.
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: Matt Ownby]
#322260 - 02/19/14 09:47 PM
|
|
|
Very impressive Matt. I haven't seen that in a loooong time. I hope to be able to play it again one day.
BTW, you said all (most?) disc have been ripped. Are they in a form that MAME would accept?
Kudos to you for all your hard work. Please keep us informed of the continuing progress, it is very exciting.
|
|
|
| casm |
|
Cinematronics > *
|
|
|
|
|
|
Reged: 08/27/07
|
|
Posts: 668
|
|
|
|
|
|
Send PM
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: Matt Ownby]
#322261 - 02/19/14 10:09 PM
|
|
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: Antny]
#322269 - 02/20/14 12:14 AM
|
|
|
> BTW, you said all (most?) disc have been ripped. Are they in a form that MAME would
> accept?
Yeah, they are mostly lossless AVI's (huffyuv codec). The chd tool can convert them to CHDs. We worked pretty closely with Aaron Giles while he was highly motivated to work on the laserdisc stuff.
But like I said, while it is nice to have these, it would be nicer to have raw ADC captures of the voltage coming out of of the back of the laserdisc player (or even better, the voltage level from the disc itself but one thing at a time).
|
|
|
| gregf |
|
Ramtek's Trivia promoter
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 8599
|
|
Loc: southern CA, US
|
|
|
|
Send PM
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS
[Re: Matt Ownby]
#322270 - 02/20/14 12:20 AM
|
|
|
Very good progress there.
iirc I believe Camelot miniature golf course (Anaheim Hills area of Orange county) had this for awhile back in 1985, but I was addicted to playing Atari Marble Madness back then and that was only game I played whenever dropping by Camelot in mid 1980s.
|
|
|
| Stiletto |
|
They're always after me Lucky ROMS!
|
|
|
|
|
|
Reged: 03/07/04
|
|
Posts: 6472
|
|
|
|
|
|
Send PM
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: Matt Ownby]
#322271 - 02/20/14 01:07 AM
|
|
|
> > BTW, you said all (most?) disc have been ripped. Are they in a form that MAME would
> > accept?
>
>
> Yeah, they are mostly lossless AVI's (huffyuv codec). The chd tool can convert them
> to CHDs. We worked pretty closely with Aaron Giles while he was highly motivated to
> work on the laserdisc stuff.
>
> But like I said, while it is nice to have these, it would be nicer to have raw ADC
> captures of the voltage coming out of of the back of the laserdisc player (or even
> better, the voltage level from the disc itself but one thing at a time).
And a system that can be duplicated, so you can get multiple rips from multiple players around the world. And do some sort of audio/video "averaging" between rips to get as pristine as possible.
It's early days still, but I can't wait.
- Stiletto
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: Matt Ownby]
#322276 - 02/20/14 02:46 AM
|
|
|
> > BTW, you said all (most?) disc have been ripped. Are they in a form that MAME would
> > accept?
>
>
> Yeah, they are mostly lossless AVI's (huffyuv codec). The chd tool can convert them
> to CHDs. We worked pretty closely with Aaron Giles while he was highly motivated to
> work on the laserdisc stuff.
>
> But like I said, while it is nice to have these, it would be nicer to have raw ADC
> captures of the voltage coming out of of the back of the laserdisc player (or even
> better, the voltage level from the disc itself but one thing at a time).
Sorry my ignorance but, isn't there a data track recorded in the laserdiscs? If so, is it recorded in these AVI's? How's that done? Anyway, I think everybody would like to see these rips added to Mame, even if just as a stopgap solution.
Oh, by the way, thanks you very much for your work in Daphne. It was an unbelievably cool thing being able to play Dragon's Lair 2 again, after playing it during just one summer in a beach arcade.
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: Ramirez]
#322277 - 02/20/14 02:56 AM
|
|
|
> Sorry my ignorance but, isn't there a data track recorded in the laserdiscs? If so,
> is it recorded in these AVI's?
Data can be encoded in non-visible display lines or in one of the four audio channels, none of which is a separate track (in the CD usage of the term).
How these are stored in the AVI is another question.
Edited by smf (02/20/14 03:01 AM)
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: Stiletto]
#322280 - 02/20/14 03:23 AM
|
|
|
>(or even better, the voltage level from the disc itself but one thing at a time).
The voltage level from the disc is rather boring as it's just on or off.
I have a vague recollection that some discs had the PWM modulation done digitally and some were analogue. For the latter sampling from the laser pickup could be less accurate than sampling after the PWM demodulation.
And you're still gambling that you can decode the video digitally better than your laser disc player.
|
|
|
| Quantum Leaper |
|
OCRer and Monkey Typist for Galaxy Game
|
|
|
|
|
|
Reged: 03/08/04
|
|
Posts: 198
|
|
Loc: Orion spiral arm of the Milky Way
|
|
|
|
Send PM
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: Matt Ownby]
#322293 - 02/20/14 07:29 AM
|
|
|
> http://my-cool-projects.blogspot.com/2014/02/star-rider-19-feb-2014.html
>
> Colors are still messed up, expander isn't coded up yet, various other graphical
> issues, but dangit, it works!!!
It's looking like I might finally get to play one of my favorite games again, since my friend bought the game before I could from Aladdin’s Castle. It wasn't so bad when my friend bought it, could still play it, but when he moved away it stunk. I will never forget when I got through all the tracks, there was only like 8 or 9 tracks, if I remember correctly. I still remember they had a Star Rider contest and I won a record {electric dreams}(vinyl) and some tokens, I thought it was better than what I got with the Tron contest, I came in third (last since 4th place did show of the finals) on that one and all I got was 10 bux in tokens and a bag for the tokens which I think I still have somewhere (not the tokens but the bag).
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9714
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: ]
#322327 - 02/20/14 11:21 PM
|
|
|
> And you're still gambling that you can decode the video digitally better than your
> laser disc player.
Considering some of the players in question predated comb filters, I'm willing to bet JD could make a better decoder.
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: R. Belmont]
#322329 - 02/21/14 12:09 AM
|
|
|
> > And you're still gambling that you can decode the video digitally better than your
> > laser disc player.
>
> Considering some of the players in question predated comb filters, I'm willing to bet
> JD could make a better decoder.
Plus, the decoder can be refined in the near or far future as long as it has good source data to work with.
Decoding isn't mandatory either; the video signal can be output again to a PC capture card or TV, etc.
The possibilities are endless
|
|
|
| casm |
|
Cinematronics > *
|
|
|
|
|
|
Reged: 08/27/07
|
|
Posts: 668
|
|
|
|
|
|
Send PM
|
|
|
Re: Star Rider's steering mechanism
[Re: Matt Ownby]
#322337 - 02/21/14 03:11 AM
|
|
|
Hey Matt - apologies for posting this here rather than on your blog, but we're trialling a new web filter at work and it's completely broken my (and everyone else's) ability to successfully post to blogspot, which means that I can't reply there.
Anyway: I think I may be about to attempt to explain this very poorly, but I'm going to give it a shot regardless.
There is a pattern in the output of your C program. However, that pattern isn't a numeric progression in a linear sense; rather, it's related (at least to my eye) to the holes in the opto-plate on the handlebar.
Take a look at the photo on DLP of the opto-plate located here. If you compare the progression of the holes on the plate with the binary output, it makes sense that the binary runs the way that it does based on the position of the handlebar. Same applies for the test mode (where it may be easier to see the distinction).
Not sure if that makes sense or not, but from the standpoint of being able to see not only absolute left, right, and centre but to also determine the amount of tilt to apply throughout the complete mechanical range of motion, it's pretty slick. There's virtually no chance of a duplicated or false reading, even under fast side-to-side movement of the handlebar - basically, every position is absolute.
Hm... Does anyone happen to know how many degrees of sweep there are lock-to-lock on the handlebar? I'm going to guess either 96 or 128, which would (potentially) give either 1.5 or 2 degrees of motion per bit, respectively. Not bad for the time at all.
|
|
|
| drewcifer |
|
One bad Mutha-(shut yo' mouth!)
|
|
|
|
|
Reged: 07/01/04
|
|
Posts: 428
|
|
Loc: Sweden
|
|
|
|
Send PM
|
|
|
Re: Star Rider's steering mechanism
[Re: casm]
#322356 - 02/21/14 10:57 AM
|
|
|
What you're describing is what's commonly referred to as a "Gray code" (http://en.wikipedia.org/wiki/Gray_code - they even have a section about position encoders ).
I've never seen Gray codes on an arcade controller before though. Pretty cool!
/Andrew
|
|
|
| Stiletto |
|
They're always after me Lucky ROMS!
|
|
|
|
|
|
Reged: 03/07/04
|
|
Posts: 6472
|
|
|
|
|
|
Send PM
|
|
|
Re: Star Rider's steering mechanism
[Re: drewcifer]
#322358 - 02/21/14 11:15 AM
|
|
|
> I've never seen Gray codes on an arcade controller before though. Pretty cool!
I have.
- Stiletto
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: R. Belmont]
#322360 - 02/21/14 11:55 AM
|
|
|
> Considering some of the players in question predated comb filters, I'm willing to bet
> JD could make a better decoder.
Surely you'd want to make the same type of filter as the laser disc player had that the game ran on?
|
|
|
| drewcifer |
|
One bad Mutha-(shut yo' mouth!)
|
|
|
|
|
|
Reged: 07/01/04
|
|
Posts: 428
|
|
Loc: Sweden
|
|
|
|
Send PM
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: ]
#322361 - 02/21/14 12:00 PM
|
|
|
> Surely you'd want to make the same type of filter as the laser disc player had that
> the game ran on?
Yeah, and since the cabs often supported multiple players, capturing the raw signal is the way to go, since a different set of filters can be coded up for each player and plugged in as needed.
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: ]
#322366 - 02/21/14 01:09 PM
|
|
|
> > Considering some of the players in question predated comb filters, I'm willing to
> bet
> > JD could make a better decoder.
>
> Surely you'd want to make the same type of filter as the laser disc player had that
> the game ran on?
Depends on what filters were in the monitor too.
OG.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9714
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: Matt Ownby]
#322372 - 02/21/14 03:01 PM
|
|
|
> Plus, the decoder can be refined in the near or far future as long as it has good
> source data to work with.
>
> Decoding isn't mandatory either; the video signal can be output again to a PC capture
> card or TV, etc.
>
> The possibilities are endless
Right. I like the flexibility
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9714
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: ]
#322377 - 02/21/14 06:28 PM
|
|
|
> Surely you'd want to make the same type of filter as the laser disc player had that
> the game ran on?
Sure, but I was replying to your statement:
And you're still gambling that you can decode the video digitally better than your laser disc player.
In plain English: I think it's absolutely *possible* to decode NTSC better than many of the original players and monitors did. I said nothing about if it's desirable to do so in MAME. (I imagine we'd default to looking exactly as shitty as hardware, while Daphne will likely use the best possible decoder all the time).
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: R. Belmont]
#322378 - 02/21/14 06:35 PM
|
|
|
> I said nothing about if it's desirable to do so in MAME. (I imagine we'd default to looking exactly as shitty as hardware,
I want it to look like dog shit. Somebody ask Mooglyguy if he can emulate dog shit.
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: R. Belmont]
#322380 - 02/21/14 07:09 PM
|
|
|
> In plain English: I think it's absolutely *possible* to decode NTSC better than many
> of the original players and monitors did. I said nothing about if it's desirable to
> do so in MAME. (I imagine we'd default to looking exactly as shitty as hardware,
> while Daphne will likely use the best possible decoder all the time).
Perhaps, perhaps
All this talk about capturing the raw voltage signal has got me thinking about my last (failed) attempt.
I bought a 12-bit 15 MHz analog->digital IC made by TI to get my feet wet, and tried to write this to an SD card using an FPGA. Making the FPGA talk to the SD card was quite a chore in and of itself although I was eventually successful. I even had it writing 512-byte blocks to the SD card. The blocking issue was that the SD card's sustained write speed was far too slow to handle the bandwidth I needed (in fairness, they are getting faster constantly).
Were I to attempt this again (and I intend to), I plan on using a 30 MHz ADC instead of a 15 MHz (since I think 15 is too slow to get the full resolution), still probably 12-bit samples, and still using an FPGA, but this time I want to output the data over ethernet to a desktop PC so that I don't have to worry about write bandwidth. (UPDATE: this would require 45 megabytes/s through-put)
I found a site that shows how to use an FPGA to transmit UDP packets which (in theory) would work. I know that UDP packets can be dropped but I am hoping (perhaps ignorantly) that I can contrive a situation where they never _would_ be dropped.
Thoughts on viability of this approach, or suggestions on a more reliable approach?
Edit : Looks like gigabit ethernet is theoretically fast enough, coupled with a solid state drive: http://www.tomshardware.com/reviews/gigabit-ethernet-bandwidth,2321-7.html
Edited by Matt Ownby (02/21/14 07:46 PM)
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: Matt Ownby]
#322384 - 02/21/14 08:10 PM
|
|
|
> > In plain English: I think it's absolutely *possible* to decode NTSC better than
> many
> > of the original players and monitors did. I said nothing about if it's desirable to
> > do so in MAME.
Note that the current video in MAME was decoded from composite to YUV using a fairly sophisticated ATI video capture card. Results aren't likely to get dramatically better, except perhaps with some clever use of DSP/filtering to clean things up.
> Were I to attempt this again (and I intend to), I plan on using a 30 MHz ADC instead
> of a 15 MHz (since I think 15 is too slow to get the full resolution), still probably
> 12-bit samples, and still using an FPGA, but this time I want to output the data over
> ethernet to a desktop PC so that I don't have to worry about write bandwidth.
15 MHz is sufficient to fully capture the NTSC output of the player. (Old broadcast quality gear that captures composite digital uses 14.32 MHz, four times the color subcarrier frequency, and well above the Nyquist rate for a signal with 6 MHz bandwidth tops.)
If we're going a step further back, inside the player, before the modulated signal on the disc is separated into audio and video, then yes, 15 MHz isn't going to be enough. I think it's an 8 or 9 MHz carrier, so a 6 MHz video signal shouldn't bump it higher than 12 MHz or so, right? 24 MHz would cover this. I'm not sure how complicated the demodulation is in a typical player, so I don't know how much purer we could expect this to be.
I definitely support the gigabit ethernet approach, especially if there's any existing FPGA code that would support it. Much nicer than monkeying with SD cards!
Edited by WarrenO (02/21/14 08:11 PM)
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: R. Belmont]
#322385 - 02/21/14 08:29 PM
|
|
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: WarrenO]
#322386 - 02/21/14 08:32 PM
|
|
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: ]
#322388 - 02/21/14 08:46 PM
|
|
|
> >> Sure, but I was replying to your statement:
> >
> > And you're still gambling that you can decode the video digitally better than your
> > laser disc player.
>
> A perfect comb filter won't necessarily help you
> http://www.extron.co.uk/company/article.aspx?id=ntscdb3
Laserdisc video is generally stable enough that a comb filter will function, so a notch filter would look considerably worse.
Composite encoding is a lossy process -- you are overlapping two signals into the same frequency range -- so a "perfect" decoder, even a theoretical one, doesn't exist. It's all about what techniques you decide to implement based on what compromises you decide to make.
And this is exactly why we want to store the un-decoded video... so those choices and compromises aren't baked into the saved data.
But you know all of this... I just like to talk about it.
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: Olivier Galibert]
#322392 - 02/21/14 09:16 PM
|
|
|
> Depends on what filters were in the monitor too.
Well the NTSC decoding wouldn't be in the laser disc player anyway.
It's either in the monitor, or on the arcade board.
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: WarrenO]
#322393 - 02/21/14 09:23 PM
|
|
|
> And this is exactly why we want to store the un-decoded video... so those choices and
> compromises aren't baked into the saved data.
Sure. To clarify:
"And you're still gambling that you can decode the video digitally better than your laser disc player."
Was purely aimed at decoding the PWM data, i.e. sampling before the PWM demodulation or afterwards.
I was expecting the laser disc to be outputting NTSC not RGB, so wasn't even considering comb/notch filter when I wrote the original comment. I should have re-read what I originally wrote before replying
I'm not sure that an uncompressed sample of the laser disc would be practical for use in MAME though (whether it's sampled from the laser pick up or after the PWM decoding).
Edited by smf (02/21/14 09:27 PM)
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9714
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: ]
#322395 - 02/21/14 10:44 PM
|
|
|
> > I definitely support the gigabit ethernet approach, especially if there's any
> > existing FPGA code that would support it. Much nicer than monkeying with SD cards!
>
> SATA might be interesting too.
>
> http://www.ecs.umass.edu/ece/tessier/gorman-fpt13.pdf
Agreed, SATA to a decent SSD is likely to sustain high transfer rates better than an SD card. But wired GigE to a desktop machine with the same SSD should work as well.
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: R. Belmont]
#322400 - 02/22/14 01:50 AM
|
|
|
>But wired GigE to a desktop machine with the same SSD should work as well.
I'm not sure an SSD is going to be big enough. But sequential writing on a SATA hard drive should be way fast enough.
Writing data directly is going to be more predictable as you're not going through all those abstraction layers and dealing with an OS that might need to do something else.
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: ]
#322402 - 02/22/14 02:31 AM
|
|
|
> > But wired GigE to a desktop machine with the same SSD should work as well.
>
> I'm not sure an SSD is going to be big enough. But sequential writing on a SATA hard
> drive should be way fast enough.
>
> Writing data directly is going to be more predictable as you're not going through all
> those abstraction layers and dealing with an OS that might need to do something else.
agreed, however after some brief googling, it seems that driving SATA directly is an extremely complicated and underdocumented proposition. Plenty of companies seem eager to sell kits in the thousands of dollars that are up to the task with plenty of marketing babble that tells me nothing about whether it would actually work.
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: Matt Ownby]
#322403 - 02/22/14 02:44 AM
|
|
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: R. Belmont]
#322418 - 02/22/14 11:28 AM
|
|
|
> > Plus, the decoder can be refined in the near or far future as long as it has good
> > source data to work with.
> >
> > Decoding isn't mandatory either; the video signal can be output again to a PC
> capture
> > card or TV, etc.
> >
> > The possibilities are endless
>
> Right. I like the flexibility
And it's only gonna need a 2 TB Hard drive per game
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: ]
#322488 - 02/23/14 10:41 PM
|
|
|
> > Plenty of companies seem eager
> > to sell kits in the thousands of dollars that are up to the task with plenty of
> > marketing babble that tells me nothing about whether it would actually work.
>
> http://www.altera.com/education/webcasts/videos/videos-sata-soc-solutions-40nm.html
Pretty cool, but from what I saw it was still $1500 to get the board and then an unknown amount to buy the IP from a partner vendor.
I can't help but think that it would be significantly cheaper to rig up some kind of "striped" SD card solution (ie maybe have 4-6 SD cards rated for 45+ MB/s write speed and just take turns writing 512-byte blocks to each one). I said I was done with SD cards, but I did have a proof of concept working, and it doesn't make sense (to me) to spend thousands of dollars making SATA work just because it's a neat idea. I mean, once the data is safely on a PC's hard drive, no one cares how it got there...
Am I missing something here? (ie is there a SATA solution to be had for under $500)
|
|
|
|
Re: STAR RIDER 19 FEB 2014 PROGRESS :)
[Re: Matt Ownby]
#322490 - 02/23/14 11:33 PM
|
|
|
> Pretty cool, but from what I saw it was still $1500 to get the board and then an
> unknown amount to buy the IP from a partner vendor.
I thought there was an open source one.
You'd probably be better off begging for a sample chip off them and designing your own board.
|
|
|
Index 
Threaded 
Star Rider VideoGraphicGenerator timers finally solved after many hours :)
Reply
[Re: 
