|
Star Rider emulation progress
#320663 - 01/21/14 12:04 AM
|
|
|
In order to provide support for Star Rider for my Dexter project, I've been spending a lot of effort reverse engineering Star Rider's PIF board (the board that controls the laserdisc player), including disassembling almost all of the ROM program (at least, I think it's almost all hehe). Not wanting to lose/forget what I've learned, I've put it all up on a wiki page for now. Hopefully, it will help to someday fully understand this fascinatingly complex game's hardware ![](//www.mameworld.info/ubbthreads/images/graemlins/smile.gif)
Star Rider page here: STAR RIDER WIKI PAGE
|
|
|
|
newsd (nt)
[Re: Matt Ownby]
#320664 - 01/21/14 12:24 AM
|
|
|
|
|
Re: Star Rider emulation progress
[Re: Matt Ownby]
#320665 - 01/21/14 01:14 AM
|
|
|
Really cool! Thanks for your work!
|
|
|
|
Re: Star Rider emulation progress
[Re: Rygar9]
#320669 - 01/21/14 04:04 AM
|
|
|
Nice Matt, thanks for dissecting it. I'm assuming after reading a few previous posts that there's no chance that this could make it into a new Daphne. Would begging help?
|
|
|
|
Re: Star Rider emulation progress
[Re: Antny]
#320679 - 01/21/14 04:04 PM
|
|
|
> Nice Matt, thanks for dissecting it. I'm assuming after reading a few previous posts > that there's no chance that this could make it into a new Daphne. Would begging help?
It could make it into a new Daphne, but since I am working on Dexter instead, it would be literally years (or never) before it happened... which is why I am documenting my work so someone else can move faster if they so choose.
|
|
|
gregf |
Ramtek's Trivia promoter
|
|
|
Reged: 09/21/03
|
Posts: 8632
|
Loc: southern CA, US
|
|
Send PM
|
|
|
Re: Star Rider emulation progress
[Re: Matt Ownby]
#320698 - 01/22/14 12:35 AM
|
|
|
>but since I am working on Dexter instead,
Good luck with remaining work with that.
Although, I started with IBM computers (home computer use) in early 1980s and the CGA or ASCII games then, that's good Apple II diskette preservation work that you blogged about from a few years ago. It reminds me of the 1980s era when Central Point Software and Canada's based Quaid software company names were meaningful during the 1980s.
|
|
|
|
Re: Star Rider emulation progress
[Re: gregf]
#320703 - 01/22/14 01:11 AM
|
|
|
> > but since I am working on Dexter instead, > > Good luck with remaining work with that. > > > Although, I started with IBM computers (home computer use) in early 1980s and the > CGA or ASCII games then, that's good Apple II diskette preservation work that you > blogged about from a few years ago. It reminds me of the 1980s era when Central Point > Software and Canada's based Quaid software company names were meaningful during the > 1980s.
It scares me that people actually read the crap I write ![](//www.mameworld.info/ubbthreads/images/graemlins/smile.gif) But I appreciate it!! ![](//www.mameworld.info/ubbthreads/images/graemlins/smile.gif)
Maybe when (yes when) I ship Dexter, I will revisit the Apple ][ diskette preservation stuff. The copy protection used by Broderbund fascinates me and I'd love to preserve it before all original disks are lost forever. I am a little mystified why people are content to only have cracked images preserved when technology exists today to preserve the original copy protected images and make the emulators be able to boot them and play them. I guess what I am saying is I'd love to have some documentation that explains exactly how the copy protection worked instead of just "It's some nibble counter that you nop out here, etc..." *end rant*
Too many awesome projects that I _could_ work on... I'd love to do this stuff full time and quit my day job
|
|
|
gregf |
Ramtek's Trivia promoter
|
|
|
Reged: 09/21/03
|
Posts: 8632
|
Loc: southern CA, US
|
|
Send PM
|
|
|
Re: Star Rider emulation progress
[Re: Matt Ownby]
#320711 - 01/22/14 05:48 AM
|
|
|
*accidently veers off of the Star Rider topic* ![](//www.mameworld.info/ubbthreads/images/graemlins/tomato.gif)
>>Although, I started with IBM computers (home computer use) in early 1980s and the >>CGA or ASCII games then, that's good Apple II diskette preservation work that you >>blogged about from a few years ago.
>But I appreciate it!!
I didn't know about the laser disc project before so I started looking at the beginning page to see how Dexter started.
>Maybe when (yes when) I ship Dexter, I will revisit the Apple ][ diskette preservation stuff.
I haven't followed the Apple II progress in MESS other than reading RB's hardware card support over the past year. It does appear the software list (hash file) is up and running so your preserved floppy diskette images should be able to drop in. Whether images run in MESS is another thing....in case apple2.c file might need to be updated again to handle diskette images (copy protection etc.)
-- /src/mess/drivers/apple2.c
MCFG_SOFTWARE_LIST_ADD("flop525_list","apple2")
/hash/apple2.xml
Apple II 5.25 disks --
>The copy protection used by Broderbund fascinates me and I'd love to preserve it before >all original disks are lost forever. I am a little mystified why people are content to >only have cracked images preserved when technology exists today to preserve the >original copy protected images and make the emulators be able to boot them and play >them. I guess what I am saying is I'd love to have some documentation that explains >exactly how the copy protection worked instead of just "It's some nibble counter that >you nop out here, etc..."
MESS preference would be support for original diskettes if they can be found and hopefully if the images are still readable. MESS does support cracked versions in case an original diskette can not be located or if the 'crack' is a unique variation.
There have been differences with some viewing only originals should be supported in MESS, but cracked images should be supported as a backup measure in case an original diskette can't be located.
|
|
|
|
Re: Star Rider emulation progress
[Re: Matt Ownby]
#320715 - 01/22/14 08:57 AM
|
|
|
> It scares me that people actually read the crap I write > But I appreciate it!! > > Maybe when (yes when) I ship Dexter, I will revisit the Apple ][ diskette > preservation stuff. The copy protection used by Broderbund fascinates me and I'd love > to preserve it before all original disks are lost forever. I am a little mystified > why people are content to only have cracked images preserved when technology exists > today to preserve the original copy protected images and make the emulators be able > to boot them and play them. I guess what I am saying is I'd love to have some > documentation that explains exactly how the copy protection worked instead of just > "It's some nibble counter that you nop out here, etc..." *end rant* > > Too many awesome projects that I _could_ work on... I'd love to do this stuff full > time and quit my day job
Poke me on IRC about the Broderbund apple2 stuff; I have a working RWTS18 discferret flux decoder, though it has to be manually hacked to skip the garbage before the first sector at the track gap. I've corresponded with Roland Gustafsson about it, but he didn't have access at the time to the source code used for originally mastering the disks and producing that 'sync hider garbage' used as (and in addition to custom-by-title sector headers) a per-title key.
LN
|
"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
|
|
R. Belmont |
Cuckoo for IGAvania
|
|
|
Reged: 09/21/03
|
Posts: 9717
|
Loc: ECV-197 The Orville
|
|
Send PM
|
|
|
Re: Star Rider emulation progress
[Re: gregf]
#320737 - 01/22/14 10:41 PM
|
|
|
> I haven't followed the Apple II progress in MESS other than reading RB's hardware > card support over the past year. It does appear the software list (hash file) is up > and running so your preserved floppy diskette images should be able to drop in. > Whether images run in MESS is another thing....in case apple2.c file might need to be > updated again to handle diskette images (copy protection etc.)
Our ability to currently run a properly dumped protected original is sketchy at the moment. I have long-suffering plans to rewrite all the Apple II floppy stuff, but my eyes glaze over every time I look at OG's modern floppy stuff. I just don't speak PLL ;-)
|
|
|
|
Re: Star Rider emulation progress
[Re: R. Belmont]
#320738 - 01/22/14 11:16 PM
|
|
|
> > I haven't followed the Apple II progress in MESS other than reading RB's hardware > > card support over the past year. It does appear the software list (hash file) is up > > and running so your preserved floppy diskette images should be able to drop in. > > Whether images run in MESS is another thing....in case apple2.c file might need to > be > > updated again to handle diskette images (copy protection etc.) > > Our ability to currently run a properly dumped protected original is sketchy at the > moment. I have long-suffering plans to rewrite all the Apple II floppy stuff, but my > eyes glaze over every time I look at OG's modern floppy stuff. I just don't speak PLL > ;-)
Its a phase locked loop to line up the flux timing. if you're "flux-ifying" a 'cooked' apple .d0 or .p0 file (converting it from a bunch of in-order sectors back to original address marks and data marks with proper timing) you mostly don't have to worry about the pll other than getting the bitcell size right.
LN
|
"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
|
|
|
Re: Star Rider emulation progress
[Re: R. Belmont]
#320741 - 01/23/14 12:01 AM
|
|
|
> Our ability to currently run a properly dumped protected original is sketchy at the > moment.
I seem to remember reading that there was at least one manufacturer that had copy protection that relied on physically damaged media. I think the disks had holes punched through certain spots (tracks?) using a laser. The protection involved having the software try to read from that damaged spot while loading. If the read was successful, then the disk was an illegal copy.
I'm not sure if there's a way to "properly dump" something with deliberately damaged media.
|
GroovyMAME support forum on BYOAC
|
|
|
Re: Star Rider emulation progress
[Re: krick]
#320755 - 01/23/14 02:21 AM
|
|
|
> > Our ability to currently run a properly dumped protected original is sketchy at the > > moment. > > I seem to remember reading that there was at least one manufacturer that had copy > protection that relied on physically damaged media. I think the disks had holes > punched through certain spots (tracks?) using a laser. The protection involved having > the software try to read from that damaged spot while loading. If the read was > successful, then the disk was an illegal copy. > > I'm not sure if there's a way to "properly dump" something with deliberately damaged > media.
This doesn't seem like a blocking issue to me. The drive would report _something_ back whether the disk is damaged, or even missing from the drive entirely. The copy protection would simply rely on getting what it expects back from the disk drive controller which could be provided via emulation if some kind of standard is agreed upon to represent this.
|
|
|
RATMNL |
Patron Saint of the Totally F*cked
|
|
|
Reged: 02/02/13
|
Posts: 425
|
Loc: 026, NL
|
|
Send PM
|
|
|
Re: Star Rider emulation progress
[Re: Lord Nightmare]
#320757 - 01/23/14 03:21 AM
|
|
|
> Its a phase locked loop to line up the flux timing. if you're "flux-ifying" a > 'cooked' apple .d0 or .p0 file (converting it from a bunch of in-order sectors back > to original address marks and data marks with proper timing) you mostly don't have to > worry about the pll other than getting the bitcell size right. > > LN
Wow. Most of the time I 'sort of' get what everybody's talking about, but you sir, just blew my mind.. maybe even made it sort of explode... I dunno... yet.
X
|
"Those voices in his head might not be real, but they have really good ideas!"
|
|
Stiletto![Administrator Administrator](//www.mameworld.info/ubbthreads/images/adm.gif) |
They're always after me Lucky ROMS!
|
|
|
Reged: 03/07/04
|
Posts: 6472
|
|
|
Send PM
|
|
|
Re: Star Rider emulation progress
[Re: RATMNL]
#320776 - 01/23/14 06:41 AM
|
|
|
> Wow. Most of the time I 'sort of' get what everybody's talking about, but you sir, > just blew my mind.. maybe even made it sort of explode... I dunno... yet.
LN does that. ![](//www.mameworld.info/ubbthreads/images/graemlins/awe.gif)
- Stiletto
|
|
|
|
Re: Star Rider emulation progress
[Re: RATMNL]
#320781 - 01/23/14 07:54 AM
|
|
|
> > Its a phase locked loop to line up the flux timing. if you're "flux-ifying" a > > 'cooked' apple .d0 or .p0 file (converting it from a bunch of in-order sectors back > > to original address marks and data marks with proper timing) you mostly don't have > to > > worry about the pll other than getting the bitcell size right. > > > > LN > > Wow. Most of the time I 'sort of' get what everybody's talking about, but you sir, > just blew my mind.. maybe even made it sort of explode... I dunno... yet. > > X
Definitions: .do file = "cooked" (containing nothing but raw sector data) Apple2 disk dump with the sectors in Apple2 DOS3.3 order (0, 7, 14, 6, 13, 5, 12, 4, 11, 3, 10, 2, 9, 1, 8, 15) and no metadata
.po file = "cooked" Apple2 disk dump with the sectors in ProDOS order (0, 8, 1, 9, 2, 10, 3, 11, 4, 12, 5, 13, 6, 14, 7, 15) and no metadata
flux = the positive or negative magnetic charge (i.e. its up or down direction and its relative strength) on any specific part of a diskette; data is stored by the distance between 'flux reversals' where the flux crosses the 0 line and becomes positive or negative from being negative or positive respectively.
GCR = Group Code Recording, a scheme for encoding data onto a diskette using a specific arrangement of flux reversals; a variant of GCR is used to encode data on apple2 diskettes
address mark = a string of (on apple2: GCR) encoded by flux reversals which comes at the beginning of a sector which consists of a fixed header/preamble, the sector's number, the track number, and a checksum code to ensure that the sector and track numbers were read correctly; note that .do and .po files do not store this data, it is implied by the position of the data within those files!
data mark = a string of (on apple2: GCR) encoded by flux reversals which comes after the address mark and consists of a fixed header/preamble and the sector's data, plus a checksum code to ensure that the sector data was read correctly. note that .do and .po do not store the checksums, they are assumed to be correct.
"flux-ifying" = an invented term for the process of taking a .do file or .po file and converting it back to the analog or digital-timing-delta flux waveform which would have represented it on a disk. This is an inherently lossy process due to lack of track and sector metadata from the .do and .po file formats
PLL = Phase locked loop, one of several ways of adjusting the timing window for where you expect a flux transition to happen in a flux stream/waveform, and when you do see one, adjust your expectation slightly for the next one. if you don't see one, do nothing. If you see a flux transition where you didn't expect to see one at all, ignore it, but (optionally) adjust the PLL expectation as well. A good PLL is an important part of reading data from a diskette in most systems due to drive speed variations, dirt, and other noise, by rejecting noise and spurious transitions from where they should not be occurring. A bad PLL can make reading data from a disk much much harder than it should be. The apple2 does NOT USE A PLL in the real system.
bit-cell or bitcell: the expected length of the shortest possible flux transition interval for a given disk or format. i.e. if a disk shows flux states of NNNNNNPPPPPPNNNNNNPPPPPPPPPPPPPPPPPPNNNNNN (where N is negative and P is positive oriented magnetic fields) and the actual data is 0 for no flux change and 1 for yes flux change (i.e. NRZ 'non return to zero' encoding), the data extracted from this will be 1 1 1 0 0 1 with a bit-cell size of 6 Additional diagram:
NNNNNNPPPPPPNNNNNNPPPPPPPPPPPPPPPPPPNNNNNN = magnetic flux direction -.....1.....1.....1.....0.....0.....1.....- = extracted bits ~~___~~~___~~~___~~~___~~~___~~~___~~~___~~ = PLL window (~ = bit expected, _ = reject)
LN
|
"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
|
|
|
Re: Star Rider emulation progress
[Re: R. Belmont]
#320782 - 01/23/14 08:43 AM
|
|
|
> > I haven't followed the Apple II progress in MESS other than reading RB's hardware > > card support over the past year. It does appear the software list (hash file) is up > > and running so your preserved floppy diskette images should be able to drop in. > > Whether images run in MESS is another thing....in case apple2.c file might need to > be > > updated again to handle diskette images (copy protection etc.) > > Our ability to currently run a properly dumped protected original is sketchy at the > moment. I have long-suffering plans to rewrite all the Apple II floppy stuff, but my > eyes glaze over every time I look at OG's modern floppy stuff. I just don't speak PLL > ;-)
Shouldn't be a problem, there's no PLL in the apple 2 :-P
I'm still working on the floppy doc, it's just a bad time of the year, work-wise. There are two problems with the apple 2. First is how to handle the state machine in a predict/commit fashion. But in practice that should not be a problem, I think. The second, more annoying, is that the nibble format, the one used for protections, is a pile of crap.
Theorically the nibble format is a direct image of what's on the floppy. In practice you can't fit it in a floppy. A floppy track is build of sectors with non-data zones called gaps separating them, protecting them from each-other. Wozniak, being the insane genius we all know, decided to automatically size the gaps to make them maximal for the real clock rate and floppy rotation speed you have. So formatting goes "write the track with way too big gaps, check if the first sector got overwritten, since it did reduce the gap size and try again until it works". The first iteration of that loop writes iirc around 1.3 times the normal track size.
Guess what the nibble format includes? You got it, it's the version with the way too big gaps. So you have to remove part of the gap data (they are ffs, easy to see, theorically) so that it fits, but since it's a format for protections you have to be sure what was there and what was added by the stupid format. That currently stopped me.
OG.
|
|
|
|
Re: Star Rider emulation progress
[Re: krick]
#320788 - 01/23/14 11:48 AM
|
|
|
> > Our ability to currently run a properly dumped protected original is sketchy at the > > moment. > > I seem to remember reading that there was at least one manufacturer that had copy > protection that relied on physically damaged media. I think the disks had holes > punched through certain spots (tracks?) using a laser. The protection involved having > the software try to read from that damaged spot while loading. If the read was > successful, then the disk was an illegal copy. > > I'm not sure if there's a way to "properly dump" something with deliberately damaged > media.
Flux dump would still be fine - holes in the disk would show up the same ways as unmagnetised surface.
|
|
|
|
Re: Star Rider emulation progress
[Re: krick]
#320789 - 01/23/14 11:51 AM
|
|
|
> > Our ability to currently run a properly dumped protected original is sketchy at the > > moment. > > I seem to remember reading that there was at least one manufacturer that had copy > protection that relied on physically damaged media. I think the disks had holes > punched through certain spots (tracks?) using a laser. The protection involved having > the software try to read from that damaged spot while loading. If the read was > successful, then the disk was an illegal copy. > > I'm not sure if there's a way to "properly dump" something with deliberately damaged > media.
The (unreleased?) game "zoid" (by one of the futurama writers, and from this zoidberg was named!) for apple2 is like this, uses a pinhole in the disk media.
|
"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
|
|
|
Re: Star Rider emulation progress
[Re: Matt Ownby]
#320792 - 01/23/14 12:13 PM
|
|
|
> This doesn't seem like a blocking issue to me. The drive would report _something_ > back whether the disk is damaged, or even missing from the drive entirely. The copy > protection would simply rely on getting what it expects back from the disk drive > controller which could be provided via emulation if some kind of standard is agreed > upon to represent this.
The hole in a disk protections work best if they force you to write to the disk & expect the write to fail only in the hole. I'm pretty sure that exists, so specifying where the media is damaged is going to be necessary for that.
|
|
|
R. Belmont |
Cuckoo for IGAvania
|
|
|
Reged: 09/21/03
|
Posts: 9717
|
Loc: ECV-197 The Orville
|
|
Send PM
|
|
|
Re: Star Rider emulation progress
[Re: Stiletto]
#320810 - 01/23/14 06:16 PM
|
|
|
> LN does that.
And it's why we love him
|
|
|
|
Found an Easter Egg in the ROM
[Re: Matt Ownby]
#320975 - 01/27/14 12:35 AM
|
|
|
I've now got the PIF board fully emulated (unfortunately it's all I've got emulated) and I have been able to step through a bunch of the code that had me stumped before.
I just stumbled upon an Easter Egg in the code in the form of a guy's name: Rich Witt. I assume he worked for Williams and wrote this ROM program. Anyone know anything about him? I had a hard time figuring out it was a person's name because in order to decode it, I had to clear the high bit before doing an ASCII lookup. (The apple2 uses this 'non-standard' ASCII also which gave me the idea that it might be ASCII in the first place and try to parse it)
I've updated my wiki page with a bunch more info that I didn't have when I made my original post (and will continue to do so).
|
|
|
Stiletto![Administrator Administrator](//www.mameworld.info/ubbthreads/images/adm.gif) |
They're always after me Lucky ROMS!
|
|
|
Reged: 03/07/04
|
Posts: 6472
|
|
|
Send PM
|
|
|
Re: Found an Easter Egg in the ROM
[Re: Matt Ownby]
#320978 - 01/27/14 01:44 AM
|
|
|
|
|
Re: Star Rider emulation progress
[Re: Matt Ownby]
#321052 - 01/28/14 09:11 PM
|
|
|
just updated my wiki page again. Disassembly is very close to being 100% complete. I am probably done with this for now.
|
|
|
R. Belmont |
Cuckoo for IGAvania
|
|
|
Reged: 09/21/03
|
Posts: 9717
|
Loc: ECV-197 The Orville
|
|
Send PM
|
|
|
Re: Star Rider emulation progress
[Re: Matt Ownby]
#321106 - 01/29/14 06:18 PM
|
|
|
> just updated my wiki page again. Disassembly is very close to being 100% complete. I > am probably done with this for now.
Nice work!
|
|
|