I've played with the: Compare changes across branches, commits, tags, and more below.
Cant seem to come up with anything that looks relevant.
Does anyone here know how to do this? I would prefer to know for myself rather than having someone just do it for me.
If contributions are only possible by devs, that is fine. I will happily send the driver to a dev for review provided I get some feedback that its either been submitted or it needs revision.
> I would like to submit a skeleton driver to Mame at Github properly. > > I would read the Contributing Guidelines, but there are none. > https://github.com/mamedev/mame/pulls > > I've played with the: > Compare changes across branches, commits, tags, and more below. > > Cant seem to come up with anything that looks relevant. > > Does anyone here know how to do this? I would prefer to know for myself rather than > having someone just do it for me. > > If contributions are only possible by devs, that is fine. I will happily send the > driver to a dev for review provided I get some feedback that its either been > submitted or it needs revision.
All code is subject to critique and revision, as you probably know, you should do as much as you can to make sure your code compiles cleanly against the current Git sources provided at: https://github.com/mamedev/mame
You'll need ROM_LOADs to be logically worked out, if possible, to CPU/SOUND/VIDEO/ETC and each machine should be accessible to launch via MAME provided you have the romsets listed and not crash or hang the emulator. This means providing all the hooks needed to make your entries be recognized by the build system such as the .lst and .flt files in src\mame as well as appropriate .lua files in scripts\target\mame.
> If Git is too much trouble, we have been known to accept code and/or data via email > mentioned here: > https://wiki.mamedev.org/index.php/Submitting_Source_Code > > All code is subject to critique and revision, as you probably know, you should do as > much as you can to make sure your code compiles cleanly against the current Git > sources provided at: https://github.com/mamedev/mame > > You'll need ROM_LOADs to be logically worked out, if possible, to CPU/SOUND/VIDEO/ETC > and each machine should be accessible to launch via MAME provided you have the > romsets listed and not crash or hang the emulator. This means providing all the hooks > needed to make your entries be recognized by the build system such as the .lst and > .flt files in src\mame as well as appropriate .lua files in scripts\target\mame.
Please don't encourage people to submit drivers via loose files. Making a pull request is straightforward and doesn't create a major pain in the ass for the devs like loose files do.
TrevEB, I would encourage you to Google for "github pull request", minus the quotes, and start there. The very first link should be a page on Github's own Help page entitled "About pull requests", which explains pretty much exactly how to go about creating and submitting a pull request. You seem to be under the mistaken notion that MAME requires some sort of special procedure for submitting changes, when in reality submitting pull requests is how a huge number of open-source projects operate.
But in general, make sure it builds, links and validates, make sure the code isn't gross, try to aim for where we're taking the project so you aren't writing legacy code (plenty of modernisation and cleanup commits to see examples), open a pull request, and follow up on feedback.
As I noted, it is only a skeleton. Roms are validated and crc checked. No code per say has been written, no specific mame drivers have been selected. That is all beyond my capabilities.
If this driver was included in Mame, it would only identify and validate the roms.
Do I need to also include the roms with the driver? What about documentation? In this particular case, both items are easily obtained. But maybe I am doing someone a favor by including them?
So if someone were to dump a previously unknown set, what would be the standard process.
I did provide driver, roms and docs to the dumping union over 6 months ago and for whatever reason that went nowhere.
Have you looked at any of the modern skeleton drivers, like the glass TTYs that AJR keeps adding? They don't do much more than document ROMs and allow you to view the disassembly in the debugger. Documentation goes in comments. Once again, there are plenty of examples in drivers that do nothing.
We do need the ROMs, and there are a variety of ways to make sure we get them.
What do you mean by a "previously unknown set"? A different program running on a supported system, or a completely new system? In either case, you add a machine definition and open a pull request, and supply us with ROMs and any other supporting materials so that anyone interesting in working on it in the future has as much to work with as possible.
Obviously it won’t be playable for some time but it would be part of the whole and providing assistance to those that need to diagnose their board. And it has graphics so it would be possible to see gameplay minus the trippy laserdisc images.
Sadly my driver writing skills are weak. Actually part of the problem is the existing rom dumps are not named properly so I need to study the schematics or find a decent picture of the board.
In the meantime I found some interesting history on the game.
It seems that uploader has also posted some higher quality videos. That's a cool article, by the way. Star Rider is probably, along with Freedom Fighter and Cube Quest, one of the most technically complex Laserdisc games there is. Actually, Freedom Fighter even runs on mostly the same hardware as Star Rider except for the LD player being different (due to its non-linear video playback). I'm curious (since I don't know a whole lot about how drivers work)... if a Star Rider driver ever does become a thing, about how hard would it be to have it load the Freedom Fighter ROMs as well?
>Actually, Freedom Fighter even runs on mostly the same hardware as Star Rider except for >the LD player being different (due to its non-linear video playback). I'm curious (since I >don't know a whole lot about how drivers work)... if a Star Rider driver ever does become a >thing, about how hard would it be to have it load the Freedom Fighter ROMs as well?
Assuming Freedom Fighter uses same hardware setup exactly like Star Rider, they could both be in same source file. If there are any slight hardware differences of the two games, then expect both games to have their own source file.
For somewhat simple example and linking to unofficial source mirror
Different games and some use the laser disc player system Pioneer LDV1000
The laser disc player system bios rom is supported in these other source files beginning with 'ld' acronym for laser disc that can be found in other source directory
Each laser disc player system might have its own unique bios rom which is why they are in the src/devices/machine section of the source code.
If Star Rider and Freedom Fighter use a laser disc player not yet supported, then the bios rom(s) from particular laser disc player system will need to be dumped and laser disc player system also emulated.
With that part, the next thing needed is have roms from a pcb (if any are used with a particular laser disc game) also need to be dumped and the pcb hardware also needing to be emulated. And the last part is the laser disc be video data be captured and fortunately there might be progress with that area. (see Domesday threads in News forum)
Here is Moogly's 12/23/18 post that provides info of what else needs to be done.
The Freedom Fighter proto version runs on modified Star Rider HW, using the Philips 22VP931 laserdisc player insted of the Pioneer PR-8210A. 22VP931 is also used in Firefox which is already emulated. The non-proto version runs on a dedicated boardset, with the same LDP. Both rom dumps are available but none emulated so far. There was a preliminary Star Rider driver running in Daphne decades ago.
There's something weird I noticed about Freedom Fighter on Star Rider hardware, actually. The game mostly uses sampled sound effects with some occasional typical PSG ones (like when you enter one of the three doors after taking out a tank). Does the hardware even have any dedicated sample playback hardware? I'm pretty sure Star Rider never did anything like that.
And a fun fact: The dedicated version, from what I can gather by looking at the ROMs, uses totally different sound effects compared to the prototype one.
> There's something weird I noticed about Freedom Fighter on Star Rider hardware, > actually. The game mostly uses sampled sound effects with some occasional typical PSG > ones (like when you enter one of the three doors after taking out a tank). Does the > hardware even have any dedicated sample playback hardware? I'm pretty sure Star Rider > never did anything like that.
Star Rider has no PSG. The sound board has a 6809 driving two DACs via 32*8 FIFOs. The playback rate is controlled by a PTM.
Williams was big into what we'd now call "soft synths" as early as Defender. The music in Spy Hunter is a dedicated 68000 driving an 8-bit DAC, for instance.
There you go - a driver that shows nothing, but has a pile of I/O in the right places, and some comments on address decoding, etc. Yes, I know I wrote "Start Rider" in the comment at the top of the file.
Old thread for those that weren't visiting MW back at the time. Just to mention that with that thread being 5 years earlier, this was before MAME and MESS officially merged to become MAME even though MAME already incorporated MESS source code into MAME around that time. And since then Apple II floppy diskette preservation is well underway with lots of 5.25 floppy diskettes of Apple II products being rescued/preserved.
>Yes, I know I wrote "Start Rider" in the comment at the top of the file.
Don't worry. According to Joey, the photocopier will catch a few of those typos and correct them for you.
>The Freedom Fighter proto version runs on modified Star Rider HW, using the Philips 22VP931 >laser disc player instead of the Pioneer PR-8210A. 22VP931 is also used in Firefox which is >already emulated. The non-proto version runs on a dedicated boardset, with the same LDP.
Thanks with the info and also fortunately Matt Ownby's blog is around since that will get another round of future visits later now that Vas's initial work is underway in MAME source code.
Man, I just re-read this blog post and I couldn't believe that I had written it. PCB pics and schematic pics? I usually just toss some random words together on my blog posts hehehe.
As far as Star Rider is concerned, I did get it partially emulated a few years ago. Everything except for the expander and the sound board was working properly.
I documented a ton of info about the game which would provide someone a massive shortcut if they want to work on emulation:
Vas. Thanks man. I appreciate it. If you ever need a bit of help designing an arcade or a kitchen, I’ll return the favor. Architecture is what I do. Writing code, not so much.
Hopefully soon I will fire up the Artwork project again for one special title.
You're welcome. I'll keep hacking on the driver slowly when I've got time.
Are you in a position to dump the master clock generator PAL (82S123 32*8 BPROM at U114 on VGG board), and the colour translation PALs (82S137 1024*4 BPROMs at U10 and U11 on VGG board)? We're going to need them for proper emulation.
edit: Also need a dump of the horizontal address mapping PROM at U74 on the VGG board (appears to be 6349 512*8 with one address line tied low).
> > Star Rider has no PSG. The sound board has a 6809 driving two DACs via 32*8 FIFOs. > > The playback rate is controlled by a PTM. > > Does it use one of the standard Midway sound boards? (sounds like a Turbo Chip Squeak > -- see audio/midway.c)
No, it's not that. It's closer to a Williams pinball sound board. The board can support three FIFOs/DACs plus a TMS5220, but one FIFO/DAC and the TMS5220 are unpopulated. The software can also control the mix level for the first two DACs.
> > > Star Rider has no PSG. The sound board has a 6809 driving two DACs via 32*8 > FIFOs. > > > The playback rate is controlled by a PTM. > > > > Does it use one of the standard Midway sound boards? (sounds like a Turbo Chip > Squeak > > -- see audio/midway.c) > > No, it's not that. It's closer to a Williams pinball sound board. The board can > support three FIFOs/DACs plus a TMS5220, but one FIFO/DAC and the TMS5220 are > unpopulated. The software can also control the mix level for the first two DACs.
Interesting. The Squawk & Talk (Discs of Tron) is somewhat like that, but not quite. I think it used a 6802, but it did have a 5220.
Oh yeah, Matt, I've been meaning to ask you two questions about Freedom Fighter. I assume you'd be able to answer them. What's the startup sequence like (there's no footage of the game booting up yet), and would you have any non-closeup photos of the PCB? I'd just be curious to see an actual photo of it in full.
Previous 
Index 
Next 
Threaded 
Submitting driver to github?
Reply
[Re: 
I subsequently acquired a full Star Rider arcade game to help finish this emulation but got distracted making Dexter 