Star Wars code/mathbox re-assembly project

[Mitchell Gant]

The cat's out of the bag on this now, good job as it was getting a bit smelly being in there for over a year now.

I've been looking at how Star Wars really works and thought I'd have a go at making a crude webpage to record my efforts so that other folks could have a look at it, and maybe even have a go at pushing knowledge even further. As reverse engineering any game code is somewhat frowned upon I was reluctant to go public with it, but on the other hand there may be as many as 5 people who are actually interested in any of this stuff...

After meeting Alpha1 at Revival, I took notice of a comment he made about making UKVAC text on a vector screen, so I spent a while altering the Star Wars attract screen logo to a crude UKVAC drawing and changed the scrolling text, using the software tools I've made to allow assembly of altered Star Wars code.

https://www.facebook.com/pages/ukVac/137395616361911

Take a look here for my findings so far:

http://www.wardclan.f9.co.uk

There are NO direct ROM images stored there, and don't expect any to ever be uploaded.

It's my first attempt at HTML, so don't expect anything pretty, really it's just a way of logging what I've done. As I find out more I'll slowly keep updating the page.

Changing the attract logo was interesting. The green text part was simple, just find the ASCII data starting at address $E145 and change it, but set bit 7 of the last character to flag the end of the line. The large blue 'Star Wars' graphic was a little harder though, and showed the rather strange way it's been coded.

There's a function at $611E that copies a 2K chunk of data from ROM at $CEDE to vector RAM at a fixed address of $2800. This data is the vector drawing instructions for the Star Wars logo, but rather than one set of lines it appears to be about six different segments, with the 'ST'of STAR WARS being the first chunk.

When that attract screen is shown, there's a function at $D9FA that then fills vector instructions to zoom, colour and call vector subroutines for each of the six logo chunks. Why it's done this way I have no idea, I suspect it may be to get the logo large enough on the screen?

When I changed the logo to 'UKVAC' I made one call to one drawing chunk and disabled the other 5 calls. It did need to be zoomed in larger though, and it also seems to corrupt where the 'INSERT COINS' and 'GAME OVER' text is positioned for a few seconds.

I question why they didn't just design in a larger vector ROM and do away with the copying vector data from main game ROM to vector RAM. I guess they thought 4K vector ROM was enough and 12K of vector RAM would be more useful when the hardware was designed, which would be way before the software for the attract screen was made.

Here's hoping that someone else out there will be able to start making their own altered or new code additions too.

What's not shown on the webpage is the Windows realtime sound effects/music editor that I'd stalled on developing, from not knowing enough about Windows Direct sound buffers. Not sure whether I'll ever be able to complete that one, now I'm focussing on other areas.

 

[Alpha1]

You are awesome dude. Additionally your website is a really good read

I'll embed the pic here. We need this running on a _real_ Star Wars machine at an event this year

For sure!

Alpha12013-05-22 11:51:44

 

[guddler]

Definitely going to have a nose tonight - can't for now as my head is elsewhere and needs to stay there...

 

[trm]

This is really, really cool stuff.

I've been reading your website and writing some AVG functions to draw simple shapes and it's excellent! I found a couple of glitches in the AVG tool and was wondering whether you're interested in bug reports?

Nothing major - after a period of time, lots of loading vector source (I didn't realise the app allowed interactive editing initially

), sometimes the Vector Data window doesn't reflect the last loaded Vector Source and remains showing an earlier version. And sometimes a final CNTR 40 causes a medium intensity grey line to be drawn from the final vector end point to -500,-500. Removing the final CNTR stops the line appearing.

These aren't frequent and I'm having a bit of trouble reproducing them but I can certainly try and document the process if you want to look into it, but no crashes and no lost work so it's definitely very usable.

The next request might be a bit cheeky - would you mind providing the IDA database for download so I can walk through the disassembly in IDApro, view the tables & trees? I can completely understand if you don't fancy this, and thank you for the HTML disasm already!

cheers

tim

 

[ColinD]

Uber cool work... !!!!

Jed Margolin refers to the x and y pot inputs from the yoke as originally coming from the pokeys and the values had to be centered from time to time as the pokey readings drifted or were jittery.... he says that even though the pots now go through a to d convertors, the pokey fix code is still in use and re centers from time to time.... can that be confirmed and is it possible to disable it ???
ColinD2013-05-22 17:43:19

 

[Mitchell Gant]

Uber cool work... !!!!

Jed Margolin refers to the x and y pot inputs from the yoke as originally coming from the pokeys and the values had to be centered from time to time as the pokey readings drifted or were jittery.... he says that even though the pots now go through a to d convertors, the pokey fix code is still in use and re centers from time to time.... can that be confirmed and is it possible to disable it ???

It looks like some of the joystick routine is at $F18D, but what it does exactly I can't tell. Some sort of averaging buffer code maybe? It's tempting to just disable all that and use the A/D values directly as it's probably plenty good enough to not jitter about all over the place like POKEY results would. Though it doesn't look like a simple case of just removing that subroutine.

One thing I should point out is that the code is not all easily relocatable yet. What I mean by that is that if you remove a few lines of code somewhere (certainly low down in memory) and assemble, then it breaks the code, which means that some portions of the disassembly expect code/data to still be at fixed addresses. I've tried to fix what I can, but there is still more work to do.

One easy way to work around this is to remove what you want, then just before the next subroutine insert an 'ORG $XXXX' directive to force the assembler to put the following code back to where it originally was.

 

[BigBaz]

Nice

 

[DaveAS]

Oh, this is some amazing work. Very cool project.

Of course, the ultimate grail would be writing a vector ROTJ game.

 

[ColinD]

Uber cool work... !!!!

Jed Margolin refers to the x and y pot inputs from the yoke as originally coming from the pokeys and the values had to be centered from time to time as the pokey readings drifted or were jittery.... he says that even though the pots now go through a to d convertors, the pokey fix code is still in use and re centers from time to time.... can that be confirmed and is it possible to disable it ???

It looks like some of the joystick routine is at $F18D, but what it does exactly I can't tell. Some sort of averaging buffer code maybe? It's tempting to just disable all that and use the A/D values directly as it's probably plenty good enough to not jitter about all over the place like POKEY results would. Though it doesn't look like a simple case of just removing that subroutine.

One thing I should point out is that the code is not all easily relocatable yet. What I mean by that is that if you remove a few lines of code somewhere (certainly low down in memory) and assemble, then it breaks the code, which means that some portions of the disassembly expect code/data to still be at fixed addresses. I've tried to fix what I can, but there is still more work to do.

One easy way to work around this is to remove what you want, then just before the next subroutine insert an 'ORG $XXXX' directive to force the assembler to put the following code back to where it originally was.

Thanks, yes I've hacked code in the past but not to this extent, I'm a bugger for NOP's to pad out to size, but the org is a good choice too..... Guessing there are at least 2 locations used for each x and y then, but don't know 6809. Maybe Jed would help and advise ?? - I'd struggle to defeat the checksums too.... I'm amazed that you've managed to comment much of the code too !!!
ColinD2013-05-24 18:07:04

 

[RGP]

6809 you say?

*rolls up sleeves*

 

[shrunkenmaster]

....there may be as many as 5 people who are actually interested in any of this stuff...

Up to 8 now, it seems

Although it's beyond me, I love this sort of thing (used to love changing text and sprites on C64 games yonks ago) - did you get any further with it?

 

[Zektor]

Excellent work!! I use idapro on car ECU's but not for arcade roms. I do have some nice EPROM
Emulators you can edit live and trace active data ....might be useful for this project.

 

[shrunkenmaster]

Had a little play with this myself - nothing near the level of Mitchell's efforts, but fun being able to change text in a game like the old days

Only changed the first two lines of text - actually found it more difficult to choose what new text to write ...

 

[Mitchell Gant]

Blimey, it's over a year ago since I did this, I really must try and get back to it!

Cool to see someone else has changed text, well done. Did you just change the ROM data or download the assembler and source files and create new ROM data? Be nice to know if anyone else got the code to assemble and run.

Zektor: I've got a Dataman S3 EPROM programmer that does simple ERPOM emulation via a ribbon cable to a plug, but I wasn't aware that there may be more advanced emulators. What sort of stuff do you have then?

I've spent quite a lot of time coding my CPU emulator that I was hoping to use as a better way of experimenting with code changes than the S3, but I think I've reached it's limits and progress has been slowed right down. I'm surprised I got as far as I did with that, it seems to work well with 6502 Asteroids boards, but the 6809 turned out to be much more difficult. It's disappointing when you hit a brick wall.

Perhaps I should just go back to looking at the disassembled assembler source I've got and experimenting with MAME as a debugger.

 

[shrunkenmaster]

I just used a hex editor to change the data. What you're doing is a bit beyond my skill level, but fascinating nonetheless!

 

[Zektor]

I use these

https://www.moates.net/ostrich-20-the-new-breed-p-169.html

They are very fast 921.6k and can used for 2732 upwards. The data tracing is very useful for finding maps. I recently used one in a BMW electronic throttle computer to find the pedal to throttle ratio map when sport mode is selected.....basically by watching each of the maps whilst pressing the sport button to see if the data was active. I use a program called tuner pro which interfaces with the Ostrich. You can build you own definition files and add data conversions, view the data as binary or hex and graphs.

Here you can see a accelerator pedal map I was tracing http://youtu.be/OUDNJH6J2u8

You can also create automatic checksum routines so that you can edit maps without hitting the car into limp home mode.
guddler2014-05-02 10:47:43

 

[guddler]

Thats an interesting device...

Is there any non car related software for it. It's pretty obvious where the target market is for that but what about simple ROM emulation, uploading bin files to the device and running them on the target hardware etc.?

PS: Edited the previous post to make the links clicky...

guddler2014-05-02 10:52:11

 

[Zektor]

Thanks. Yes there is a basic software that comes with it that allows you to upload binary files to the device via USB. Once loaded you can unplug it and it will act as a ROM.

You could just use tunerpro and make an XDF file calling each section a name that relates to the arcade board. You can download tunerpro for free and have a mess around with it. Creating the XDF is a bit tricky but there are examples on the site you can dig into to see how it works, if you understand HEX (which you do ) then it should be fairly straightforward to pick up.

Oh, how do you make links clicky? Zektor2014-05-02 11:06:14

 

[Equites]

I use these

https://www.moates.net/ostrich-20-the-new-breed-p-169.html

They are very fast 921.6k and can used for 2732 upwards. The data tracing is very useful for finding maps. I recently used one in a BMW electronic throttle computer to find the pedal to throttle ratio map when sport mode is selected.....basically by watching each of the maps whilst pressing the sport button to see if the data was active. I use a program called tuner pro which interfaces with the Ostrich. You can build you own definition files and add data conversions, view the data as binary or hex and graphs.

Here you can see a accelerator pedal map I was tracing http://youtu.be/OUDNJH6J2u8

You can also create automatic checksum routines so that you can edit maps without hitting the car into limp home mode.

That's quite cool, I may just pick one these up. I've had success using the Dataman S4 in the past to tinker with maps on some of the classic Toyota's.

 

[Zektor]

I had 2 running together on the v12 as it runs as 2 x 6 cylinders (2 ECU's ) you can link them in tunerpro to upload at the same time...clever stuff.