tag:blogger.com,1999:blog-12357145626320875422024-02-23T02:13:52.177+11:00Retro PortsThis blog chronicles my progress porting various retro games to other retro platforms. The goal in each project - at least when targeting a new CPU - is to effectively replicate the original graphics and the original code line-by-line, to produce a 100% accurate port of the original game.tcdevhttp://www.blogger.com/profile/02245101571269922064noreply@blogger.comBlogger462125tag:blogger.com,1999:blog-1235714562632087542.post-55351071266788668202023-11-06T16:27:00.006+11:002023-11-06T16:31:45.279+11:00And that's probably it for Vulgus!<p>I've decided to put Vulgus to bed.</p><p>After a fruitless session, I've exhausted my interest in finishing the RE. Given that I don't have plans to transcode it at all, the ROI for the remining sections is miniscule.</p><p>The few remaining 'free-standing' variables are flags and timers for spawning various alien types. I could probably stare at it long enough to come up with some sort of meaningful name for them, but I'm not going to.</p><p>The various alien object tables have indeterminate member variables that are almost certainly related to movement, whether they be timers, velocities and/or accelerations, or movement table pointers. I've spent some time trying to nail them down, but the different object table structures for different aliens makes it a nightmare.</p><p>Finally, the data structure used to generate and keep track of the background map is missing a whole heap of values, including pointers and offsets into various tables of meta-data, tile codes and colour palettes. I've tried a few times now to decypher it all, but it just leaves me with a headache.</p><p>I've thought of simple patching/lifting the source for the purpose of generating the full map, but even that seems overwhelming atm. I think I've simply burnt out on Vulgus.</p><p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEjYrOg2my1QFtCVDNVOxCc_6QX4QWJIeVXbWV1_iBAgORx1Pb73y-U7qlrdGwFUjRF7_u-kl1MpzlyG2ZQJDq0hGuhuJuX-jGwsgz-fBqTOagkmo7y2v2QUVbT43zPP2_JnoUAPlgwRoO6zVqgenU_9kOT_RFIiYO5aCanD1F9jzFbDe9WPGa_2Xe4uYILI" style="margin-left: auto; margin-right: auto;"><img alt="" data-original-height="256" data-original-width="224" height="240" src="https://blogger.googleusercontent.com/img/a/AVvXsEjYrOg2my1QFtCVDNVOxCc_6QX4QWJIeVXbWV1_iBAgORx1Pb73y-U7qlrdGwFUjRF7_u-kl1MpzlyG2ZQJDq0hGuhuJuX-jGwsgz-fBqTOagkmo7y2v2QUVbT43zPP2_JnoUAPlgwRoO6zVqgenU_9kOT_RFIiYO5aCanD1F9jzFbDe9WPGa_2Xe4uYILI" width="210" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">That's it for Vulgus... for now at least.</td></tr></tbody></table><br /><p></p><p>I will continue to play it and hopefully (finally) see the titular Vulgus for myself. Part of the quandary I have is that I have no idea how the elements of the final boss look or behave, which makes it difficult to RE the code related to it, and I don't want to spoil the game for myself by cheating or watching a YouTube video.</p><p>Let's see what takes my fancy next...</p>tcdevhttp://www.blogger.com/profile/02245101571269922064noreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-39804805484009349842023-11-06T01:37:00.004+11:002023-11-06T01:44:52.758+11:00You'll want to collect 'E' as well!<p>Another session, another few variables decoded (RE'd). Most of the 'free standing' variables have either been decoded, or I have at least some idea of what they do - just not the specifics. A surprising number of seemingly unused variables in the code; initialised but no cross-references to code that reads them. Setting watchpoints in MAME tends to confirm too.</p><p>There is a timer for spawning the non-firing or 'kamikaze' aliens in the game (spinning star-discs, black blocks etc) which is initialised after every spawning. However the value from which it is initialised is itself never initialised, other than being zeroed at program initialisation time. As a result, the non-firing aliens tend to come thick and fast in the game!</p><p>Related to this; formations (worth big points) consist of either 5 or 6 aliens as specified in a table entry. However the game will 'give up' waiting for 5/6 free slots in the object table after while and just spawn as many aliens as it can given the free slots - which means you may have to kill less aliens to get the bonus formation points! After all these years playing it, I never noticed this!!! 😶</p><p>I've finally detailed the result of missing the letter 'E'. Again, the manual suggests an immediate effect when it appears, however it is when you fail to collect it that something happens. In the case of the letter 'E', without going into excruciating detail because it is a little complicated, missing it increases the frequency for spawning of firing aliens (only). Not that it would be possible to increase the frequency of the non-firing aliens because of the abovementioned feature/bug. And like the letter 'D', at some later stage it becomes a moot point because the area will start with maximum frequency anyway. It has no effect on the big/mega aliens either.</p><p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEjb065P7KDg-Zrfd2iCHvcY-_xitPA1TiKqo3HPM2SSTnKUbJ9Ij22v6AXNX6_YjsB4qV-WVVuy6LAIWou2E4hfMulvcQcVScUT4mGaU1WDFqq1P0w-5fSVgGHfXukog_7-gWKUbNQ7an9GQCogHa4xIM8tU92MQkGjYIZnnPvDV_PYrDfqZj9_9hpReCX-" style="margin-left: auto; margin-right: auto;"><img alt="" data-original-height="256" data-original-width="223" height="240" src="https://blogger.googleusercontent.com/img/a/AVvXsEjb065P7KDg-Zrfd2iCHvcY-_xitPA1TiKqo3HPM2SSTnKUbJ9Ij22v6AXNX6_YjsB4qV-WVVuy6LAIWou2E4hfMulvcQcVScUT4mGaU1WDFqq1P0w-5fSVgGHfXukog_7-gWKUbNQ7an9GQCogHa4xIM8tU92MQkGjYIZnnPvDV_PYrDfqZj9_9hpReCX-" width="209" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Nothing to do with 'E', just eye candy for attention</td></tr></tbody></table><br />Aside from the handful of 'free standing' variables mentioned above, it's mostly variables in the map and object tables that haven't yet been fully RE'd. And these of course relate to the two outstanding areas I mentioned in the last post, namely map generation and alien movement.<p></p><p>TBH I'm at the stage now where I just want to be finished - I'm thinking too much about the next project. However I think if I tackle the alien movement next it'll unlock a lot of the outstanding object variables, if not all. That'll leave just mostly map generation. And it would be nice to write something to display the entire map...</p>tcdevhttp://www.blogger.com/profile/02245101571269922064noreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-85885567708859788402023-11-02T10:26:00.001+11:002023-11-02T10:26:28.445+11:00Parallax Scrolling!?!<p>Another quickie; cracked a few more variables in the last session which revealed an interesting if subtle detail to the game.</p><p>I had previously deduced the meaning of one variable to be the amount by which the background had scrolled left/right (<i>dy</i>), so it could be used to update, for example, the map and objects superimposed on it. Turns out that whilst I was close, I wasn't quite right.</p><p>There are actually two (2) variables updated when the ship is moved left/right; the abovementioned and another variable, updated by a slightly different amount. The <u>other</u> variable is actually <i>dy</i> for the background and ground-based objects and the first variable is <i>dy</i> for airborne objects, such as bullets and aliens.</p><p>What this means is there is a subtle parallax scrolling effect when moving the ship left/right! It is hard to notice when playing, but the effect is that your bullets (and certain aliens) will move left/right slightly less than the background moves.</p><p>[I should note that I use <i>dy</i> for left/right movement rather than <i>dx</i> because the screen is rotated, and the offset is made to the sprite register that is documented as the 'Y' register. Ultimately it's less confusing to reference the hardware than the physical orientation of the monitor, especially if the hardware is used for multiple games, some horizontal!]</p><p>It is getting harder and harder to progress, but I'm yet to finish a session without making at least some progress. A few variables seem to be initialised but never used (like the letter 'S'), but it's not straightforward to prove they're never used. In some cases the best you can do is set a watchpoint in MAME and play the game...</p><p>Here are the areas I have visited but have yet to complete:</p><p></p><ul style="text-align: left;"><li>Background map generation/rendering; the data appears to be packed into blocks of meta-data</li><li>Alien movement; alien movement is all table-driven</li><li>Planet/Area data that affect difficulty; some of them are simple spawn timers or alien types but I haven't decoded every single parameter as of yet</li></ul>I think that's about it.<p></p>tcdevhttp://www.blogger.com/profile/02245101571269922064noreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-14726894778748905952023-10-30T01:31:00.005+11:002023-10-30T01:31:56.774+11:00'S' is for... nothing!<p>Just a quick one... still progressing on Vulgus, chipping away at the unknown variables.</p><p>Indications are that the letter 'S' does... ABSOLUTELY NOTHING! I can't find any cross-references to it in the code, other than initialisation and updating a counter (max=4) when one disappears off-screen. A watchpoint in the MAME debugger doesn't reveal any accesses to the variable either.</p><p>Somewhat puzzling given that the other two letters do affect game play.</p><p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEgKo70NwQHxypklgmWoPvwnWXVL_g6vOEb1SDUCNesmBUjNflbrxQZScHNDu8AHTe3onFAeBUV1ZE0jkphaRnhqQ-6NKVqJ1KATmJOVkDS33xLvv21Lt4qZrPh9Vupn1MyYpPIEVu0Nazg8CEqSUfGBTjChNtFLNYEhq7CX6JswDthtS_V8Wl_v4lZKQW8s" style="margin-left: auto; margin-right: auto;"><img alt="" data-original-height="256" data-original-width="669" height="122" src="https://blogger.googleusercontent.com/img/a/AVvXsEgKo70NwQHxypklgmWoPvwnWXVL_g6vOEb1SDUCNesmBUjNflbrxQZScHNDu8AHTe3onFAeBUV1ZE0jkphaRnhqQ-6NKVqJ1KATmJOVkDS33xLvv21Lt4qZrPh9Vupn1MyYpPIEVu0Nazg8CEqSUfGBTjChNtFLNYEhq7CX6JswDthtS_V8Wl_v4lZKQW8s" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Random Vulgus picture for attention</td></tr></tbody></table></p><p>I've been working on ROMSET #2 in MAME, so I decided to load up ROMSET #1 and see if that had any references to the variable. Took quite some time (two sessions) to get to the point where I could analyse the code in some detail - because of all the jump tables used in the game - but couldn't find any other references. Similarly playing the game didn't trigger the watchpoint.</p><p>I did however notice one difference in game play logic, and there are more. Interestingly ROMSET #1 allows 10-character names in the high score list, whilst #2 is only 3 characters. When I've finished the RE I will go back and analyse the differences in detail.</p>tcdevhttp://www.blogger.com/profile/02245101571269922064noreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-36997830609547924582023-10-23T22:49:00.002+11:002023-10-23T22:49:38.209+11:00It's official, collecting the letter 'D' is good!<p>I haven't posted in a while but I have been making quite a lot of progress on the RE.</p><p>I would say 90-95% of the code has been commented now. Most of the unknowns have to do with the gameplay 'AI' - variables that affect the difficulty of the game, and also a few areas of functionality that I know the exact purpose of, just not the specific mechanics. Those include unpacking background map data, and handling the movement patterns for the aliens.</p><p>The RE is somewhat complicated by the fact that there are multiple object tables; one for enemies that fire, one for enemies that don't fire, and one for the 'large' enemies - and these tables don't have the same structure! 😣 So when commenting the code, I need to remind myself which type of alien the routine is operating on. Quite annoying because they are relatively small, and it would have been perfectly acceptable to use the same structure even if some members were unused.</p><p>But I still seem to be able to make some progress each session; I think I've hit a wall but then make a breakthrough with a few variables. It's just a matter of continuing to chip away here.</p><p>On the subject of collecting 'D' from an earlier post, I can say with absolute authority that it is <b><u>beneficial</u></b> to the player. Here's what the <i>Vulgus</i> manual on <i>Capcom Arcade Stadium</i> on the Nintendo Switch has to say about it:</p><p>"Increases enemy firepower when it appears. Collect it to stop the effect."</p><div>Technically though, it's not about collecting them, but rather not failing to collect them. Each map area starts with a variable denoting the maximum number of enemy bullets allowable on the screen at any one time, with an absolute maximum of 6. Nothing changes when 'D' appears, but failing to collect a 'D' will increase that count by 1. Of course at some point in the game, it becomes a moot point because you'll eventually start the area with the maximum (6).</div><div><br /></div><div><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEgfwAYNzM6XNxFwQGsqCHiOtaC2p3yhbYGNX1kVTWym1DSN9lCsGvt1pbcyQ2sicbdTRhORzXwEQ7wzFRUDstjwqsjWFDXnKdM2L3QvUSy3zoku7czMLajMailTi-v46RSutnJUGX_iloIAQvxfBzh00Qut5lWF46NZGhlUgUyK-uT9oQLR-8b81NDL9bkk" style="margin-left: auto; margin-right: auto;"><img alt="" data-original-height="256" data-original-width="224" height="240" src="https://blogger.googleusercontent.com/img/a/AVvXsEgfwAYNzM6XNxFwQGsqCHiOtaC2p3yhbYGNX1kVTWym1DSN9lCsGvt1pbcyQ2sicbdTRhORzXwEQ7wzFRUDstjwqsjWFDXnKdM2L3QvUSy3zoku7czMLajMailTi-v46RSutnJUGX_iloIAQvxfBzh00Qut5lWF46NZGhlUgUyK-uT9oQLR-8b81NDL9bkk" width="210" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Not a 'D', but here's an 'E' just for attention</td></tr></tbody></table><br />'E' & 'S' are related to other variables which I haven't examined in detail just yet.</div><p>There's also a bonus that appears at 150,000 pts and then again at every 100,000 until the last one at 550,000 pts. After that it doesn't appear again. I need to understand more about the actual bonus at this point - I've never seen it myself and was completely unaware of its existence.</p><p>I've also learned about the titular 'Vulgus' boss enemy which, again, I am yet to encounter in my own gameplay. I'll need to practice a bit more - I'd like to get there without cheating - but I need to get my MiSTer repaired first. That's on the to-do list for the very near future. Or maybe I should install my Vulgus PCB in the lowboy and fire it up!?!</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-50361341535777935002023-10-08T00:07:00.003+11:002023-10-09T00:49:02.538+11:00Slowly taking shape<p>I've reached the point in the RE where the rate of progress is beginning to slow. On the bright side, I've probably commented about 75% of the code thus far, so I have a good idea of how it's all working, if not some of the finer details. What's remaining is mostly entwined with what I call the 'AI', or gameplay logic.</p><p>Last session I was getting a little frustrated with the lack of progress, but a few small gains and then actually taking a step back to look again at the bigger picture improved my perspective somewhat and, as a result, some of the higher level unanswered questions suddenly seemed to click into place.</p><p>I didn't get a chance to work on it again today, but after working out all the hardware sprite allocations I now know what I need to do next; identify how the various aliens are allocated to the different object tables. That should in turn assist in RE'ing some of the remaining variables, and the mystery of the letters!</p><p>More to come on that subject...</p><p><b><span style="color: #ffa400;">UPDATE:</span></b> I'll just tack onto the previous post...</p><p>Really getting into the nitty-gritty now. I have a much clearer idea of object table and sprite allocation after tonight's session. One structure I thought was an object table actually isn't, though I don't really have any idea what it is at this point.</p><p>There's quite a bit of table lookup happening. I'm working on the data structures and routines for the (up to 9) objects stored at $E200, which include the 'normal' smaller aliens buzzing around. I've identified the STATE, TYPE, X,Y and DX,DY structure members, plus what I believe are the TIMER and COUNTER members. Other members I'm still not sure of. I've identified types/routines for two (2) specific aliens now, the others should be relatively straightforward to identify one I work through the code.</p><p>There's quite a bit of table lookup in the logic for handling aliens. This is for both movement and other gameplay-related logic. It's going to take quite a while to work it all out, and perhaps there are sections I never will.</p><p>I can say that collecting 'D' is at least beneficial to the player in one aspect... more I can't say yet.</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-85527077243547101602023-10-05T00:05:00.002+11:002023-10-05T23:48:25.637+11:00Answers and Questions<p>More progress tonight and more questions than answers.</p><p>I started looking at the 'object' data structure used in so much of the code. Byte $00 appears to be the state, and $01-$04 appears to be the (16-bit) object X and Y coordinates. The MSB of the coordinates are copied to the sprite registers. Or so I thought...</p><p>Turns out that is true only for the player bullets, thus far at least. The player bombs have different coordinate data AFAICT. This doesn't bode well for the other objects, and it may well be that each object type has its own data structure. Sigh.</p><p>One interesting discovery... player bullets are rendered as foreground tiles - not sprites! Each bullet can potentially span 6 tiles, so there is a lengthy process of calculating the foreground video RAM address, and a lookup of tile codes just to render a bullet. The bullet object structure stores the address each time it is rendered, so it can be used to wipe the bullet when it is moved/destroyed. Phew!</p><p>And it gets even stranger - it doesn't seem to call these routines in attract mode!?!</p><p>More to come...</p><p><b><span style="color: #ffa400;">UPDATE:</span></b> I was curious about the bullet sprite vs tile issue, so I looked a little further into it...</p><p>During attract mode, the bullets are rendered as sprites, using hardware sprites 4-7.</p><p>During gameplay, the bullets are rendered as foreground layer tiles.</p><p>Here's the kicker though, and this threw me for a bit... when you coin up and start a game, and 'READY' is displayed on the screen - all handled by the 'gameplay' state machine, as opposed to the 'attract mode' state machine - the bullets are also rendered as sprites! As soon as 'READY' disappears, it starts using tiles!</p><p>What's more, you can fire (white) bullets when 'READY' is displayed, but as soon as it disappears, so do all the on-screen bullets! And any subsequent bullets fired are pink!!!</p><p>Why?</p><p>I haven't looked further into it, but I have my theory.</p><p>Firstly, during attract mode and when 'READY' appears, there are foreground tiles in the gameplay area (VULGUS title and READY text), so any bullets rendered as tiles would obliterate those graphics. In attract mode, the (sprite) bullets run behind the title and text, and even behind the score at the top of the screen. In gameplay mode, (fg tile) bullets disappear before reaching the score.</p><p>Secondly, with (only) 24 hardware sprites, I suspect the game designers wanted to make more use of the sprites for enemies and their bullets? Otherwise - why would you do it??? Presumably (I'll deduce this later) the attract mode gameplay screens are explicitly designed to use less sprites than the game uses at its most difficult!?!</p><p>I've never seen anything like this before! 😲</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-31814351357638040682023-10-03T21:42:00.003+11:002023-10-03T21:42:41.798+11:00Vulgus RE progressing a little better than I initially expected!<p>Back from holidays (boo!) and although I haven't posted again, I've made quite a lot of progress over the last couple of weeks.</p><p>First I'll admit I haven't gone back to look at the map decoding - there was plenty to do in the rest of the disassembly that kept me occupied. Some of the aforementioned numerous variables have been identified, though there's quite a lot that I still haven't deduced, as many of them are only used in one or two places, and likely for enemy AI - they're always the most difficult!!!</p><p>Having said that, a huge portion of the code has at least been commented to a degree, if still missing some key elements of data. Aside from the map data, there appears to be a homogenous 16-byte 'object' data structure for every, well, object in the game, from the player ship, to bullets & bombs, and aliens. I've figured a few of those bytes out, and hoping I can focus on the rest now that I'm at home and have access to larger & multiple screens, notepads etc.</p><p>There's a not-insignificant amount of code for a few unobtainable self-test screens, which I've been able to see run via patching a few bytes. They threw me for a bit as I couldn't reconcile what the code was doing with what I've experienced in the game. TBH they're nothing more than a curiosity and not worth in-depth RE.</p><p>Speaking of non-insignificant amounts of code; the 'instructional' sequences showing the point scoring system is quite a chunk in its own right. I've identified the state machine responsible for the attract mode sequences and have documented parts of it, but not all of it.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgLaSHUrC2maWNuJIJJKBvqpPALeT1K7X7S9EkJh1xqWYxLrvqv0-QxU68VzQjfvwhemLxWPf7Rob3D2PRX7d89B1YpwQ0p3KE_Ewkf33yLO6Esl1CsjRZAkAJ9xQVArCpwj5lqsnJkGfUMB8qy3sBg-MgAE8t6cLUbV6jIcKQLTVtodOyE__951IDwh1DU/s256/0000.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="256" data-original-width="224" height="256" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgLaSHUrC2maWNuJIJJKBvqpPALeT1K7X7S9EkJh1xqWYxLrvqv0-QxU68VzQjfvwhemLxWPf7Rob3D2PRX7d89B1YpwQ0p3KE_Ewkf33yLO6Esl1CsjRZAkAJ9xQVArCpwj5lqsnJkGfUMB8qy3sBg-MgAE8t6cLUbV6jIcKQLTVtodOyE__951IDwh1DU/s1600/0000.png" width="224" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Part of the instructional sequence - quite a lot of code required</td></tr></tbody></table><p>My overall impression is that the code isn't exactly the best I've come across; <i>Xevious</i> was far neater and more efficient. There seems to be quite a bit of duplicated code, and routines called from multiple places when you wouldn't expect they would need to be. I think some of the logic is a little hap-hazard in the way it was put together. And the game actually looks a little un-finished, though those more familiar with the game probably won't be surprised to hear that. Aside from evidence in the gameplay, things like branches between different routines that are identical tend to support this theory.</p><p>And finally for this post; there's the debate over whether collection of the letters '<b>E</b>', '<b>S</b>' & '<b>D</b>' actually help or hinder the player. I've found the code that handles this, though I haven't completed the RE so I won't say anything more just yet other than to note that initially, I thought them completely benign! That was because the code that 'collects' them doesn't actually do anything (as opposed to the code that collects the 'POW' pickups). However further analysis revealed that the code actually tallies how many you've <b>MISSED</b>, rather than how many you've collected!!!</p><p>My immediate focus will probably be on deducing all the elements of the 16-byte 'object' data structure - that should help identify some of the outstanding data variables. As I said, I have a few worked out thus far, and have guessed a few others, now it's time to nail them all down!</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-34949527913097158112023-09-23T23:31:00.001+10:002023-09-24T22:45:41.250+10:00Holiday project - Vulgus RE<p>Long time no post!</p><p>Truth is I haven't had the time or the motivation to work on any Retroports projects for the last few months as work and Real Life have both ramped up significantly. The good news is that although work has been a lot busier, I have been working on FPGA design and that has me thinking more about potential projects for MiSTer. But I digress...</p><p>For now, I've brought my laptop away on holidays and needed a non-development project to fill in my down time - usually later in the evening - and have decided to RE <i>Vulgus</i>. <i>Vulgus</i> is perhaps a little lesser known title, Capcom's first arcade game in fact, and although it didn't set the world on fire, it is a sentimental favourite of mine as I played it quite a bit back in the day.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxkGiUfdpep1XebmLu9xt6XhAKxtakr_2CyUNVx1V8Lsitr9bfH8BZm0P5SoC9G2oRsG2Ht-rUnP7LUUfJi4MJYoowpcEiWJfhtEYaesn4lKUsd77Mpo1tbuWi_k3AZFFPNOgg0DSS77sdlYn4vZwKThqUgCXZNrjh4M3JzJ6ENLpiDJ8QedAXfAC6Hm07/s256/0000.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="256" data-original-width="224" height="256" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxkGiUfdpep1XebmLu9xt6XhAKxtakr_2CyUNVx1V8Lsitr9bfH8BZm0P5SoC9G2oRsG2Ht-rUnP7LUUfJi4MJYoowpcEiWJfhtEYaesn4lKUsd77Mpo1tbuWi_k3AZFFPNOgg0DSS77sdlYn4vZwKThqUgCXZNrjh4M3JzJ6ENLpiDJ8QedAXfAC6Hm07/s1600/0000.png" width="224" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">MAME screenshot</td></tr></tbody></table><p>The game is a vertical shoot-em-up and (the game) runs on a single Z80; fixed foreground (character) 2bpp layer, 4-way scrolling background 3bpp layer, and 4bpp sprites. There's a 2nd Z80 for sound, and a pair of AY-3-8910 sound chips. Nothing exotic about that configuration.</p><p>I've spent about 5 nights thus far doing RE and have made reasonable but not spectacular progress. There do seem to be quite a lot of variables and I must admit I've hit the hard stuff a bit earlier than I generally do in these exercises. I've deduced the program architecture, which is remarkably similar to <i>Galaxian</i> and <i>Scramble</i> - almost to the extent that it suggest some sort of prior/shared knowledge. I haven't read the history of Capcom in any detail, but it is interesting how alike they are.</p><p>In a nutshell, the game runs from the VBLANK interrupt, queuing low-priority commands for the background to process - mostly tasks like foreground-layer output and score calculation. The background simply runs in a tight loop waiting to process commands, while the interrupt runs a hierarchy of routines called in sequence via jump tables, with variables keeping track of which routines are to execute next interrupt. Scott (Galaxin/Scramble RE) referred to them as 'scripts', they can also be thought of as 'state machines'.</p><p>After hitting routines in every state that manipulate varying amounts of yet-to-be-deciphered data variables, I decided to turn my attention to the game map. Even that appears to be more complicated than I'd hoped; possibly stored as meta-tiles and decoded on the fly one row at a time. I think I know where the data is stored, I just need to do more work to confirm it.</p><p>In order to assist with the RE of the map, I went back and created the graphics conversion tool that I do for every project, that allows me to render palettes, CLUTs, tiles and video memory. It's not 100% accurate, but close enough; in fact the one layer that is 100% is the background layer! My tool has been hacked from project to project over the years, and was becoming quite unweildy, so I also took the opportunity to tidy it all up and simplify the process a little. The next RE project will be a bit easier again now.<br /><br />Next task is to return to the code and work out a way to render the entire map, as I did for <i>Xevious</i> (although I was far from the first to do that). I'm pretty sure I'll be the first to do it for <i>Vulgus</i> though.</p><p>Whether this effort ultimately results in a transcode is not clear atm. It does have the 16x16 background layer tiles though, which make it a lot easier to port to the Neo Geo, especially with the scrolling.<br /><br /><b><span style="color: #ffa400;">UPDATE:</span></b> some progress with the map decoding/rendering. I think I've identified the tables and live pointers for the map meta-tile data, map tile data and map palette data. There is a distinction between 'planet' and 'area', and I <b><i>think</i></b> you can travserse the entire map 3 times before it resets?!?</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-5948692096092488652023-06-01T17:07:00.002+10:002023-06-02T00:34:56.995+10:00Galaxian star field<p>I've been chipping away at <i>Galaxian</i> as updates come from <b><i>jotd</i></b>. It's all-but-finished now, with a few sounds to implement and/or debug on the Neo Geo, and the mystery of randomly disappearing bombs.</p><p>I've just finished implementing the starfield, although I realise now I made one mistake that I may or may not decide to go back and rectify. The end result would be practically indistinguishable though.</p><p>The starfield in <i>Galaxian</i> (and similar games) is generated in hardware with some rather simple circuitry. A maximal-length LFSR is used to generate - and scroll - the star positions, with some simple combinatorial logic to generate the colours and blinking.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiFEHVe1_ufFzWgwVpJYhk0qaI8ev8wEmWkPjwnmRXImHAYEYmtcBHjMFDOMskUAcbuKhimdWoNVypPEsIlvlloKJGPwTgDjDSbHmXBMApJBWnQX2UmZUu5o4ZoRYo3En389VesjWbButrEuWpQvvnuhAGPPdAbSbRxPuv3rt01UEEqLdWShPt295pCfQ/s640/0001.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="640" data-original-width="448" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiFEHVe1_ufFzWgwVpJYhk0qaI8ev8wEmWkPjwnmRXImHAYEYmtcBHjMFDOMskUAcbuKhimdWoNVypPEsIlvlloKJGPwTgDjDSbHmXBMApJBWnQX2UmZUu5o4ZoRYo3En389VesjWbButrEuWpQvvnuhAGPPdAbSbRxPuv3rt01UEEqLdWShPt295pCfQ/s320/0001.png" width="224" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">The original (MAME's approximation anyway)</td></tr></tbody></table><p>Of course there's no way to replicate that mechanism on the Neo Geo, so I had to come up with a way to implement something similar with sprites. I wanted to be as accurate as possible, and I think I've managed that (almost) except for the blinking pattern (which you couldn't possibly tell anyway).</p><p>The LFSR has a period of 131071 (2^17-1) but is effectively clocked twice per pixel which, given a 256x256 pixel virtual display, causes the starfield to scroll every frame. The combinatorial logic generates 252 stars each frame (which of course just repeats every frame). Star colours are derived from certain bits in the LFSR on that clock.</p><p>The Neo Geo requires just 16 sprites of 16 tiles each to cover a 256x256 pixel area - IOW 256 sprite tiles. The first step was to generate the stars using the same LFSR and render them in the respective Neo Geo tile, taking into account the relative rotations of both the <i>Galaxian</i> and Neo Geo displays. [<i>I've since realised I made a wrong assumption about the orientation of the Galaxian display, which wouldn't be difficult to fix.</i>]</p><p>Once I had the star positions, I had to think not only about the colours, but also the blinking. Fortunately the Neo Geo has an extensive palette which allows up to ~4096 colours on-screen at the one time. This allowed me to use a separate palette entry for each of the 252 individual stars. The only added complication was partitioning the palette entries across those 252 stars. I calculated that each 16-colour palette would be sufficient for one half (left/right) of each sprite. Not 100% efficient use of the palette, but easier to calculate and also code up.</p><p>Now to blinking. No prizes for guessing I used colour-cycling. With a unique palette entry for each star, I can blink any/all stars independently. But what algorithm should I use?</p><p>Although there are only 252 stars, each of the 16 sprites requires 2 palettes (with 16 colours/palette) for a total of 512 palette entries. So I came up with a 9-bit (Galois) LFSR that effectively selects a random palette entry (star) each clock - though not all entries correspond to stars of course. To blink the stars, I needed two (identical) LFSRs, each clocked at the same frequency, but out of phase. The leading LFSR would blank out palette entries, and the following LFSR would restore them. How long the stars are blanked out depends on the phase difference between the two LFSRs.</p><p>I played with them only briefly before coming up with an acceptable solution; the LFSRs are 1/4 of a cycle out of phase, and they're each clocked 4 times per VBLANK. This seems to give a fairly decent emualtion of the starfield in terms of blinking.</p><p>Not that anyone will ever notice any of this!</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxbFxFdAOXLcB6_j3d6A-RvwiKE_FJPnypjzKRouM4eRXl-5Vy3ZCKlOUw_NxKzJGn6khZ0vt5mmMad9DEHwhwU-kuNQ2UN_Cira8mx3OeZMdEOAnPvqC4-n0B0krGawKfKT8NvZgP9amDaJFQn0UEki3B3F8drwG2SmlpxLNoOxjgksEi0ia0-eQGYA/s640/0025.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="640" data-original-width="448" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxbFxFdAOXLcB6_j3d6A-RvwiKE_FJPnypjzKRouM4eRXl-5Vy3ZCKlOUw_NxKzJGn6khZ0vt5mmMad9DEHwhwU-kuNQ2UN_Cira8mx3OeZMdEOAnPvqC4-n0B0krGawKfKT8NvZgP9amDaJFQn0UEki3B3F8drwG2SmlpxLNoOxjgksEi0ia0-eQGYA/s320/0025.png" width="224" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Starfield on the Neo Geo. Can you still tell it's Galaxian?</td></tr></tbody></table><p>If I do go back and change the starfield layout (as mentioned above) I'll update with results. In theory it should generate the exact pattern of the original. Blinking will never be the same though.</p><p><b><span style="color: #ffa400;">UPDATE:</span></b> It took just 2 simple changes to reverse the rotation of the <i>Galaxian</i> screen and re-generate the starfield. However I still can't visually confirm it's the same as the original. But it'll probably stay this way now regardless, as I need to manually render an opaque tile for the display masking sprites. Oh well, I tried...</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-14746832253855828472023-05-20T00:31:00.002+10:002023-05-21T00:29:43.599+10:00Galaxian getting close.<p>More <i>Galaxian</i> (though not a lot) progress and none on <i>Xevious</i> (again).</p><p>I've optimised the OSD layer somewhat and it should be adequate for real hardware (not that I've actually tried it yet). It's doing nothing anywhere near as demanding as <i>Xevious</i>, although I'm yet to implement the scrolling starfield. Having said that, the starfield should be a lot simpler than <i>Xevious</i>, in that I can utilise non-zoomed sprites and use wrap which means a single sprite update each scroll. I'll use colour cycling via palette update to blink the stars so again, not a lot more demanding than what is happening now.</p><p>The game is playable except for the few bugs that remain in the transcode. <b><i>jotd</i></b> is getting very close though, so it isn't too far off being finished. The big challenge for both the Amiga and the Neo Geo is the background 'swarm' sound effect, which changes frequency as you reduce the size of the swarm. I think <b><i>jotd</i></b> is going to take the same approach as will be necessary on the Neo Geo (at least without writing a custom sound driver), namely take a number of samples at different frequencies and play them back at the appropriate time.</p><p>No eye candy because it doesn't really look any different, just plays better.</p><p>Otherwise, no excuse not to get back to <i>Xevious</i> really...</p><p><b><span style="color: #ffa400;">UPDATE:</span></b> another drop from <b><i>jotd</i></b> and it's looking very close now!</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-59549045001906408462023-05-15T01:24:00.002+10:002023-05-15T01:26:41.006+10:00Galaxian looking good now!<p>More incremental progress on <i>Galaxian</i> when I should be doing <i>Xevious</i>. But time has been short and I'm trying to support <b><i>jotd</i></b> as far as possible as he did me during <i>Xevious</i>. He is slowly finding and fixing bugs in the transcode and so it's getting that little bit closer to being finished every day.</p><p>One thing I forgot to mention is that I've implemented all the sounds that <b><i>jotd</i></b> has ripped and added to the core. Almost trivial thus far on the Neo Geo, though I suspect the "swarm sound" may cause some difficulties on the Neo Geo...</p><p>I've implemented the bullets. With plenty of tiles to spare I rendered the bullets in every possible position within the 16x16 grid of the Neo Geo tile. That gives me options if I need to tweak pixel offsets for the nuances of <i>Galaxian</i> hardware.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhaXeSWqEXxLH6tuUzybR9yHb9CLCgKvGpmcJaGv1W95JPMYWJ5WqtgAI1weYPHkW1MrOwby-1SXeSiq2xh_xpXlVaPJhQsIDxcv33LvU-PJG-WeXSQ6YjPeGkV-3LiRKArVeNR8eFbfRg0BNclT6ApJ9-9gOSAmf_v-v0QnyO_bYQq5-1n0to5aON2jQ/s640/0017.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="640" data-original-width="448" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhaXeSWqEXxLH6tuUzybR9yHb9CLCgKvGpmcJaGv1W95JPMYWJ5WqtgAI1weYPHkW1MrOwby-1SXeSiq2xh_xpXlVaPJhQsIDxcv33LvU-PJG-WeXSQ6YjPeGkV-3LiRKArVeNR8eFbfRg0BNclT6ApJ9-9gOSAmf_v-v0QnyO_bYQq5-1n0to5aON2jQ/s320/0017.png" width="224" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Looking pretty accurate now, <br />although the OSD is still a quick hack atm.</td></tr></tbody></table><p>Having just said that, <b style="font-style: italic;">jotd</b> has made the decision to eliminate the above-mentioned hardware nuances (pixel offsets for different sprites) together with the corresponding core code that caters for them. Not much point adjusting sprite coordinates in the core 68K code, only to subsequently reverse them in the OSD layer.</p><p>It's time for me to implement my hacked OSD layer "properly". I'll have to implement dirty tiles and defer the background tile update to the VBLANK ISR as well us tidy up the sprite code.</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-69410238035323167212023-05-10T14:11:00.000+10:002023-05-10T14:11:20.657+10:00Galaxian sprites working<p>Got the sprites working during lunchtime today. Positioning is only a rough approximation atm. When I re-write the OSD layer "properly" I'll make sure it's all pixel-perfect.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgVXvZDcVD4oVdUj8vwDN2nH_1V_2hXdgQnySxN7iDfjLdN9BX2i3Zbi6T7V3fXZvypEa74Srmhb9TRdhQtG_ejn_Uot5_FMvitLNBHcVPb_j1_LxVJhOhv_AL8k6baWsLikuGuZFxrNUCqVj08egBLiSZJOcwXAv2eLe62AicGQGyKKTRVg1OahBVqzQ/s640/0012.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="640" data-original-width="448" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgVXvZDcVD4oVdUj8vwDN2nH_1V_2hXdgQnySxN7iDfjLdN9BX2i3Zbi6T7V3fXZvypEa74Srmhb9TRdhQtG_ejn_Uot5_FMvitLNBHcVPb_j1_LxVJhOhv_AL8k6baWsLikuGuZFxrNUCqVj08egBLiSZJOcwXAv2eLe62AicGQGyKKTRVg1OahBVqzQ/s320/0012.png" width="224" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Tiles and sprites all done!</td></tr></tbody></table><p>They work on the attract screen, but not in-game. It's a transcode issue, not an OSD issue.</p><p>Next is to implement the bullets. I'll have to manually render the tile(s). I've already added palette entries for them.</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-58973919179038266142023-05-09T00:21:00.002+10:002023-05-09T23:35:49.708+10:00Galaxian on the Neo Geo<p><i>Galaxian</i> is coming along nicely! I've only implemented a few very quick hacks to the <i>Xevious</i> OSD layer on the Neo Geo and I can already start and play a game. The tilemap layer is implemented, CLUTs correct, and scrolling working except the offset for the visible display needs tweaking.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEizLn_YMXN1-idg5I3YnasHXTh2O7a78dJfPf_HQFL25n48uJE2V3hdvLERHmoGuIL5mhF-WoPVkS-rbqWfSCwfp2XgS0wgec-tndmKODmhcXZSRn97EHHbkS1TwCDWnLaSRCpkqpsDGMtiZaK7EGJIktZg3Dm_PmIVzqKXcr-HlCgjkQTHPXPwsU_-2Q/s640/0010.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="640" data-original-width="448" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEizLn_YMXN1-idg5I3YnasHXTh2O7a78dJfPf_HQFL25n48uJE2V3hdvLERHmoGuIL5mhF-WoPVkS-rbqWfSCwfp2XgS0wgec-tndmKODmhcXZSRn97EHHbkS1TwCDWnLaSRCpkqpsDGMtiZaK7EGJIktZg3Dm_PmIVzqKXcr-HlCgjkQTHPXPwsU_-2Q/s320/0010.png" width="224" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Can start and play a game (on FREEPLAY)</td></tr></tbody></table><p>Not implemented are the sprites; dive-bombing aliens and bullets & shots. And sound, though it appears <b><i>jotd</i></b> has already ripped the sounds and added a few to the Amiga port. Using NGFX SoundBuilder it wouldn't take a lot of work to add them to the Neo Geo as well.</p><p>An interesting issue with the Neo Geo implementation. On the MVS the BIOS handles coins and you can only query the BIOS as to whether or not there are sufficient coins inserted to start a game. <i>Galaxian</i>, OTOH, reads a raw input port and debounces it over 4 samples. Thus I will need to use the BIOS routines and effectively "pulse-extend" the coin input to allow <i>Galaxian</i> to detect it.</p><p>I'm also considering the possibility of supporting a horizontal monitor for <i>Galaxian</i>... I think it can be done - that'll be interesting!!!</p><p><b><span style="color: #ffa400;">UPDATE:</span></b> Have implemented 'pulse-extend' for the coin input, and can now coin up.</p><p>Have implemented all dipswitch settings except SERVICE MODE and my custom cabinet mode.</p><p>Have implemented <i>Galaxian</i> sprites, but so far I can't get them to appear on the screen!?!</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-36597744722288270102023-05-03T23:41:00.003+10:002023-05-04T23:41:51.265+10:00Xevious, Donkey Kong and now Galaxian on the boil...<p>Still yet to work on <i>Xevious</i> as there is another distraction now - <i>Galaxian</i>!</p><p><b><i>jotd</i></b> is working on a largely programmatically-transcoded version of Scott Tunstell's very comprehensive RE of the arcade <i>Galaxian</i>. He has the game running on the Amiga, sans sprites, already!</p><p>I have updated my tools to rip the graphics and palette, and rendered the Neo Geo tiles. I've created a skeleton project for the Neo Geo, added some stub functions for the OSD functions implemented by <b><i>jotd</i></b>, and it builds. The splash screen displays (using the <i>Galaxian</i> font) but the game resets the Neo Geo as soon as it runs.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDZe48x5ksnCkO8YuT9OzOh0V8u4L-LYqEQ95qWEeoJHBY-fH7HTBHQ4HlZNtxTSS9CroZmp8MQElS52kgXdiyCm25OXmFJejIfYDMLS3S2XNEMZZ5aBeUy0B5LVeauhyj11Uf8RaHTFTsmJVQwAzIFlHvtuRZOTncBE4TzIiDijr_svOYHogcmNcktQ/s640/0000.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="640" data-original-width="448" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDZe48x5ksnCkO8YuT9OzOh0V8u4L-LYqEQ95qWEeoJHBY-fH7HTBHQ4HlZNtxTSS9CroZmp8MQElS52kgXdiyCm25OXmFJejIfYDMLS3S2XNEMZZ5aBeUy0B5LVeauhyj11Uf8RaHTFTsmJVQwAzIFlHvtuRZOTncBE4TzIiDijr_svOYHogcmNcktQ/s320/0000.png" width="224" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Splash screen with arbitrary colours</td></tr></tbody></table><p>I won't be doing a huge amount of work on this in the short term; just enough to get the game running and displaying to give <b><i>jotd</i></b> an idea of how the OSD he has defined is working. Then I'll let him finish off the transcode before I polish it off on the Neo Geo.</p><p><i>Xevious</i> is still beckoning of course...</p><p><b><span style="color: #ffa400;">UPDATE:</span></b> <i>Galaxian</i> may be put on hold. <b><i>jotd</i></b> is using a lot of PC-relative addressing which breaks when I specify .text and .bss sections for the code and data respectively... so it may depend on whether or not he's interested in supporting the Neo Geo...</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-59686251071412017052023-04-28T23:26:00.004+10:002023-04-28T23:26:44.697+10:00Even less Xevious happening...<p>Scool holidays means even less time to work on my projects. Not that I've been particularly motivated lately. <i>Xevious</i> has been a no-go for a few weeks now... it's getting ridiculous now - I need to release a new Beta with better sound before everyone forgets all about it.</p><p>I have done some more work on <i>Donkey Kong</i> though. I think I've finished converting all the tilemap accesses to <b><i>osd_w_vram</i></b> calls. I should now be able to fill out the routine to actually update the Neo Geo sprites, and then remove the call that renders the entire tilemap every VBLANK.</p><p>I'm not too keen on how I did the transcode all those years ago. I was more concerned with mirroring the Z80 register usage than optimising for the 68K registers. Even then I don't think I was entirely consistent. As a result, it's a bit of a dog's breakfast. I've already re-allocated some registers in the routines that I've been updating for vram access.</p><p>When I finish <i>Xevious</i> and start on the transcode in earnest, I'm going to go back to the start and work through all the existing code. There's a few other areas where I diverted from the way the original code works when I really shouldn't have. I want to fix all that up - I'm much happier with the way <i>Xevious</i> turned out, and want to use that as the template for my transcodes going forward.</p><p>This week I'll make a concerted effort to finish off <i>Xevious</i> and release a new Beta, even if it is just the sound. There's really only one last bug that I need to find - spurious <i>Toroids</i> (flying objects?) destroyed when firing continuously.</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-90828672814653409302023-04-16T10:54:00.006+10:002023-04-16T22:23:25.639+10:00Not much Xevious happening...<p>Currently finding it difficult to work on <i>Xevious</i> due to other commitments, but I should have some free time in the coming week and hoping to be able to release a Beta by the end of it.</p><p>In the mean time I've been doing bits and pieces on <i>Donkey Kong</i>, updating all the tilemap accesses so they are done via the OSD layer. Not quite as efficient as simply writing to video ram, but a lot more flexible and allows the choice of either on-the-fly updates or, for example, dirty tile updates during VBLANK. It also makes it much easier to rotate the screen, which I am planning to support on the Neo Geo. I don't think the Neo Geo or Amiga will have anywhere near the performance concerns of <i>Xevious</i> for this transcode.</p><p>Not being "in the zone" for <i>Donkey Kong</i> does makes things a little more difficult. There are things I've done in the code that I am now questioning; things that will take more time to analyse. It has been around 10 years since I touched it last... but I can't afford investing that time until <i>Xevious</i> is done and dusted.</p><p>Regardless of the countless changes, it is still mostly working. I've broken the intro animation where <i>Kong</i> has kidnapped <i>Pauline</i> and climbs the ladder before stomping on the girders - it loops endlessly. But the attract mode demo runs - for a while before rebooting. It's annoying that I can't simply coin up and start a game to test my OSD changes, but it's nothing to be overly concerned about atm.</p><p>Hopefully my next post will be announcing the next beta release of <i>Xevious</i>!?!</p><p><b><span style="color: #ffa400;">UPDATE:</span></b> I fixed the broken intro sequence; I had recently 'optimised' one of the RST routines, not realising that some callers relied on a side-effect (setting the HL register pair). I can coin up and start a game, but there are multiple gameplay issues now.</p><p><br /></p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-74635466520655880332023-04-12T01:16:00.002+10:002023-04-12T01:18:36.714+10:00NGFX SoundBuilder<p>More RE - this time <b><i>Blastar's</i></b> NGFX SoundBuilder Z80 ROM.</p><p>I wanted to learn more about how the Neo Geo sound works in general, and how the SoundBuilder Z80 ROM works in particular. Together with the Neo Geo Development Wiki, the YM2610 (incomplete) datasheet and some sample driver code, I was able to decypher most of it today.</p><p>Pretty neat how <b><i>Blastar</i></b> has designed his driver to cater for most situations. It provides 5 channels of ADPCM allocated in a round-robin fashion for short samples, a 6th channel that can play background sounds (optionally looped) for longer samples or voice/music, and a 7th independent channel (again, optionally looped) that can also play background sounds. On the NGCD, the 7th channel is replaced - seemlessly - with CDDA tracks.</p><p>The way it works is that the driver code itself doesn't need to change, just the data table(s) at the end of the ROM. One for the (optional) eye-catcher, and one for the game sounds. After you insert the samples into the GUI and allocate channels, it produces a Z80 ROM image and accompanying PCM data ROM ready to go for either cart or CD systems.</p><p>Now that I understand how it all works internally, hopefully I can get the sound working in <i>Xevious</i> without any glitches sooner rather than later.</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-44816562597770185792023-04-10T00:35:00.007+10:002023-04-10T00:41:01.045+10:00Sound complications holding up Beta 2 release<p>Been quite a while since my last post. There are a combination of reasons, but primarily it's that work has gone from 1 to 100 and kids' soccer season is in full swing. And I also have to admit that I'm just a little bit over <i>Xevious</i> now.</p><p>However, I have still been working on the next Beta release when I can. The particular issues that remain include sound, and artifacts that only appear on real hardware; so working on either isn't possible during lunchtime at my desk. That hasn't helped matters either.</p><p>I had a theory on the artifacts (aka "sparklies") but that hasn't panned out. I've decided - for now at least - that I can live with them. Nothing that a crappy composite picture won't mask anyway! Maybe sometime down the track when working on other projects I may get another insight?</p><p>The sound isn't proving to be going well either. I re-allocated some of the sounds to make use of ADPCM-B on the cartridge-based systems, and CDDA on the NGCD. This allows me to mix the <i>Solvalou</i> background 'tune' and the <i>Andor Genesis</i> sound. It was also supposed to simplify some of the logic that calculates when to stop certain sounds.</p><p>However it seems to run amok fairly frequently now, sometimes playing sounds when they shouldn't and sometimes muting sound altogether. I'm yet to actually confirm, but I'm fairly certain it's to do with the 68K writing sound commands faster than the Z80 can process them. Of course the arcade code just writes sound commands whenever it needs to, and I have no control over that. It won't be trivial to solve...</p><p>These issues aside, the Beta is all-but-ready for release. A few minor enhancements/fixes that <b><i>jotd</i></b> has discovered during the Amiga port, and I'm well and truly ready to wrap it all up.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_CDwFGpz0nGZBMrQe-jJFViMzerka3zVN082xbRmnj7DW2CPW0JKWp61KqWT42e71w6T5Q7EwLFQzDxCo6JBabNZnC24BARFofdO1C53vfVLx3-LoqaS7AX4W-e18t3XXw4e4NBCHjSwOoNTeEPzP2G2EvNBiXIvH1zpfPEssY_zIqYlLWcw7rIRU8Q/s968/fI28Jf.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="968" data-original-width="687" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_CDwFGpz0nGZBMrQe-jJFViMzerka3zVN082xbRmnj7DW2CPW0JKWp61KqWT42e71w6T5Q7EwLFQzDxCo6JBabNZnC24BARFofdO1C53vfVLx3-LoqaS7AX4W-e18t3XXw4e4NBCHjSwOoNTeEPzP2G2EvNBiXIvH1zpfPEssY_zIqYlLWcw7rIRU8Q/s320/fI28Jf.jpg" width="227" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">NaggyNaggerson created this awesome 'flyer'<br />for the Neo Geo version of <i>Xevious</i></td></tr></tbody></table><p>On other news, I've been working a little on <i>Donkey Kong</i>, mainly during lunchtimes at work when I can't work on <i>Xevious</i> for reasons outlined above. I've eliminated all the old macros that didn't really work the way I want them to now, and it's only a little broken! In the process I replaced all the branch and jump opcodes with the gnu pseudo opcodes that automatically calculate the optimum instruction. Next step is to replace all the video/sprite calls with <b><i>osd_XXXX</i></b> functions.</p><p>Finally, I've been tweaking the <b><i>Xevious</i></b> makefile and project directory structure to accommodate the new sound and ultimately produce a .CHD rather than a .ISO to accommodate the audio tracks. That was a learning exercise in itself. Of course that will need to be carried over to DK as well.</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-39457067448295990302023-03-25T00:24:00.001+11:002023-03-25T00:24:51.394+11:00Scoring differences in Super Xevious, and a 'cheat'?<p>Quite fortuitously I decided to watch a YouTube video of someone playing <i>Super Xevious</i> to see the new objects in action as they were intended - ie. on a non-patched ROM. The video features the score reaching 9,999,990 which is when the game starts to crash...</p><p>Halfway through the player was seemingly stuck on the screen where a series of <i>Garu Zakato</i> (large bombs) explode on the screen, releasing 4 <i>Brag Spario</i>. These <i>Brag Spario</i> circle the <i>Solvalou</i> in a display of celestial mechanics (quite impressive), and the player was trying (fruitlessly) to destroy them whilst trying to evade them. My tactic since 1984 has been to sit near the bottom of the screen, where you have more time to react, and they also promptly disappear before they can circle back (in fact, I didn't even know they circled back until I was testing the transcode in 'invincible' mode, and ventured up the screen!)</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhugR-w16a46Xu78uLA3sbCfc35ZKmMZiC9rTKej-OtFSafLLQGqHHy1xeQjJ0nA2oxJgjSek6V2TYiceXrNy_waSa6P5ixAsRPrRojfXZBuI3PVkkak6rjjWRv8dUdEajPUAfSrCfHJ-8Y9IGHbHaTULzXovP9KOcpOplcPZD-hX5q6cD9dhkYQIQm1w/s703/sxevious%20brag%20spario.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="703" data-original-width="527" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhugR-w16a46Xu78uLA3sbCfc35ZKmMZiC9rTKej-OtFSafLLQGqHHy1xeQjJ0nA2oxJgjSek6V2TYiceXrNy_waSa6P5ixAsRPrRojfXZBuI3PVkkak6rjjWRv8dUdEajPUAfSrCfHJ-8Y9IGHbHaTULzXovP9KOcpOplcPZD-hX5q6cD9dhkYQIQm1w/s320/sxevious%20brag%20spario.png" width="240" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;"><i>Brag Spario</i> circling the <i>Solvalou</i> can't be destroyed...</td></tr></tbody></table><p>I was wondering why the player hadn't worked this out, and then I noticed they had racked up a massive score! Watching closely, I realised that the score was incrementing quite rapidly each time a <i>Brag Spario</i> was shot; they can't be destroyed, but as they circle they can be shot multiple times.</p><p>Checking the code, I noticed each shot was scoring 2,000 points! Wondering why I'd never seen this tactic in <i>Xevious</i> before, I checked the original code - only 500 pts! On EASY setting (as this video seemed to be), on <i>Super Xevious</i> you could earn an extra <i>Solvalou</i> by hitting a <i>Brag Spario</i> just 20 times - easy to do when 4 of them are circling!</p><p>Of course this meant I now had to go through all the scoring in <i>Xevious</i> and compare it with <i>Super Xevious</i>... and found just one other case; <i>Sol Towers</i> have been reduced from 2,000 pts to 1,000 pts.</p><p>I hope I haven't missed any other subtle changes in <i>Super Xevious</i>...</p><p>Today I (also) added support for separate high score load/save for <i>Xevious</i> and <i>Super Xevious</i> on the Neo Geo. It's painful to test on both BRAM and memory card, but all done now.</p><p>Now... sound or sparklies???</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-90154522377756852092023-03-23T10:25:00.004+11:002023-03-23T10:29:00.632+11:00Super Xevious post mortem.<p>I've finished testing the <i>Super Xevious</i> transcode additions.</p><p>I can only say that <i>Super Xevious</i> was a half-arsed, almost apathetic exercise that couldn't have taken more than a week. The main enhancement is the increased difficulty (table entries), and the new objects don't really add much to the gameplay experience at all. In fact, you should actually ignore all of them except the <i>Galaxian</i>.</p><p>*** WARNING: some spoilers here, though they're really not that exciting...</p><p></p><ul style="text-align: left;"><li><i>Galaxian</i>; technically worth 150 pts but you can't actually hit it. Always spawns away from the <i>Solvalou</i>, and will turn away before you can get under it. Shoots at you though.</li><li><i>Jet Taking Off</i>; appears once (area 10). Unique in that it is a flying enemy, but shooting it results in a crater on the ground. You can't get close enough for it to hit the <i>Solvalou</i> before it leaves the screen, Don't shoot it - you have been warned!</li><li><i>Jet</i>; the most pointless addition. Appears once (area 15). Flies down the screen at a random (relatively shallow) angle but is completely and utterly benign. It can't hurt you, and you can't destroy it. What was the point?</li><li><i>Helicopter</i>; appears once (area 14). Don't bomb it - you have been warned!</li><li><i>Tank</i>; appears once (area 8). Don't bomb it - you have been warned!</li><li><i>Bridge</i>; appears once (area 15) and is purely cosmetic (completely benign). 'Allows' the <i>Domograms</i> to cross the river. </li></ul>And that's it really. To be fair, there was very little free ROM space available (they had to remove some copy protection routines) but I feel they could have done more than that. There are existing object handlers that aren't used - they could have (re)used them too?!?<p></p><p>As I mentioned, the code base now builds both variants.</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-39221866234796138632023-03-22T00:46:00.004+11:002023-03-22T14:14:27.101+11:00Super Xevious transcode complete! Now to squeeze both into the same binary...<p> I've finished the <i>Super Xevious</i> transcode, though I'm yet to test the new objects.</p><p>To give you an idea of how little code has changed, MAIN has 10 uses of an assembler directive to differentiate code, whilst SUB has only 2. These are mainly for title screen and high score table differences in MAIN, and the data structures in SUB that drive gameplay.</p><p>The code for the additional object handlers are included in build options for both, as they simply won't be called when playing <i>Xevious</i>. It's neater than adding more assembler directives, which only makes the code harder to read. And one of the tables in SUB has an extra 6 bytes on the end; one for each new object type. The negligible 'wasted' resources are hardly an issue on a typical 68K system.</p><p>My next challenge is to get both variants building in a single binary. The difficulty arises because <i>Xevious</i> is split into MAIN & SUB src (object) files, with a whole bunch of locations (labels) shared between them (so global). I don't really like the idea of reorganising into a single source file (using .include, for example).</p><p>What I think I need to do is separate the shared locations (RAM, more-or-less) into their own object file that need only be linked once, and then go from there. Both MAIN and SUB only have 2 entry points, so it's not difficult to duplicate for each variant. And hopefully that's about it.</p><p>I'll post my success, or lack there-of, here of course!</p><p><b><span style="color: #ffa400;">UPDATE:</span></b> SUCCESS!!!</p><p>I pulled all the RAM variables out into a separate source file to be assembled once (shared by the two variants). MAIN & SUB are assembled twice within the target, using <span style="font-family: courier; font-size: x-small;">--defsym OPT_SUPER=0/1</span> to differentiate the build. Now there are two (<b>s</b>)<b>xevious_reset</b> and two (<b>s</b>)<b>xevious_im1_irq</b> entry points exported. As it turns out, there's no difference between the two irq handlers, so it's possible to just call the original from either variant. As a result, the variant chosen is wholly dependent on which <b>reset</b> function is called!</p><p>It wasn't quite that easy; some duplicate routines that I was exporting from MAIN rather than re-implementing in SUB had to subsequently be copied into SUB. And there were a couple of data structures shared between MAIN & SUB that had to be either duplicated, or constructed in RAM.</p><p>The binary is larger now, so I had to arrange the objects to preserve my 16-bit branches.</p><p>The Neo Geo target now prompts to select the variant from the splash screen.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiAs2q1AeN-Mcfjry7E96Wd2xbZcWfTK9eKBHKE8FmwojA9o8O4rZa8gjf4n5jB5gHPn2dHLEJfaLSJeHL4zEX4K5Wj3XqPM9jKzsjRykQgGGHB1LoNfZL2Xb2KQY_C2nHVoGCxa6foHYGbo9Vqo0LnwHWlUgL5rv1Xqjgi29cZNDnB0NLLdiJRzyLJ1w/s640/0000.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="640" data-original-width="448" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiAs2q1AeN-Mcfjry7E96Wd2xbZcWfTK9eKBHKE8FmwojA9o8O4rZa8gjf4n5jB5gHPn2dHLEJfaLSJeHL4zEX4K5Wj3XqPM9jKzsjRykQgGGHB1LoNfZL2Xb2KQY_C2nHVoGCxa6foHYGbo9Vqo0LnwHWlUgL5rv1Xqjgi29cZNDnB0NLLdiJRzyLJ1w/s320/0000.png" width="224" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Selection of <i>Xevious</i> or <i>Super Xevious on the Neo Geo</i></td></tr></tbody></table><p>All that remains now is to support separate high score load/save for each variant.</p><p>Then test the new objects in <i>Super Xevious</i>, fix the sound, and the sparklies. And investigate some weird graphics 'sparklies' when shooting toroids... will it ever be finished?</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-21551609813078192012023-03-21T00:15:00.007+11:002023-03-21T00:21:44.331+11:00Amiga performance, Super Xevious ready for transcode, and Donkey Kong updates.<p>I've been playing around with the (transcoded) <i>Xevious</i> source in order to facilitate better performance on the Amiga. I think I was somewhat successful.</p><p>On the original machine, the MAIN CPU gets a VBLANK interrupt and updates the lower 32 (ground-based object) sprites. It then sets a pair of memory variables (aka semaphores) to signal to both MAIN and SUB ROMs to stop spinning and calculate the next frame. The MAIN doesn't touch any hardware, but the first thing SUB does is update the upper 32 (air-based object) sprites and then hits the h/w scroll register. This is why the ground-based objects "shake" a little even on real hardware!</p><p>In order to handle this on one processor, the transcode updates the lower 32 sprites and sets the memory variables in the VBLANK ISR as per the original. When MAIN is signalled, it first calls the SUB ROM routine, which updates its hardware (as described above), runs the rest of its code to completion, and then MAIN can complete the frame processing, before spinning again waiting for the next VBLANK.</p><p>So SUB ROM gets to update its hardware immediately after MAIN finishes its VBLANK ISR - just like on the original - which comprise the most time-critical tasks. But on the original, it wasn't clear which CPU was finishing its processing first. This could be important, since the last thing SUB does is update the sprite shadow registers with data from the current frame - including data updated by MAIN. HOWEVER, the transcode is calling MAIN *AFTER* SUB has run to completion. And this is still the case atm. It's something that requires more investigation on my part.</p><p>One thing the code couldn't handle though, is 'frame-skipping' which is especially important to get the game running at 60Hz on a PAL (50Hz) machine. So I added an 'ISR' for SUB, comprising the two h/w-related routines, and removed them from the SUB main loop. This 'ISR' gets called directly from the MAIN VBLANK ISR.</p><p>I then modified the code to treat the 'semaphore' variable (I removed the superfluous SUB semaphore) more like a real semaphore - a count instead of a flag. The result being, if you set the semaphore to 2 instead of 1, it'll call the main and sub routines twice, whilst updating the screen just once. Perfect for adding an extra frame every 5.</p><p><b><i>jotd</i></b> has reported better performance on the Amiga, though I can't immediately eplain why, unless excessive lag was causing the two semaphores to get out of sync and delay an extra frame? Regardless, it's getting a lot closer to a release and is certainly very playable on suitable Amiga harwdare now!</p><p>The other thing I've done is completed the RE for the new objects in <i>Super Xevious</i>. They aren't particularly exciting, or very complex at all, though to be fair there wasn't much spare memory to play with as the <i>Xevious</i> ROMs were pretty full; they even removed some of the copy protection to fit them in.</p><p>At the risk of spoilers, I will say that of the six new objects, 3 are better left alone and one is completely benign! I was wondering why they went to the trouble of adding an object that effectively does nothing, and only appears in one place - until I saw it in action; it's a bridge to allow <i>Domograms</i> to cross a river. Purely cosmetic of course, as there was nothing stopping them from crossing before, but a clever addition.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVHuayjf4sgfjCp97LLmmFeY9LiQBrwdx1uKLiKcfbFycjapT6VzWaLwO4UDNS54blaozU3m4i5QfvBIqsX1E5j_K7ltAgTuD7YI9xXjOy5sUDfKXxg8xCCf64YcHTl8orVYoa_OCY79tFzWFd5SAdOUbLsyRJwWoFN30FquUTg1zP2ufpDQWl1Aa5Dg/s640/0000.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="640" data-original-width="448" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVHuayjf4sgfjCp97LLmmFeY9LiQBrwdx1uKLiKcfbFycjapT6VzWaLwO4UDNS54blaozU3m4i5QfvBIqsX1E5j_K7ltAgTuD7YI9xXjOy5sUDfKXxg8xCCf64YcHTl8orVYoa_OCY79tFzWFd5SAdOUbLsyRJwWoFN30FquUTg1zP2ufpDQWl1Aa5Dg/s320/0000.png" width="224" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">The bridge 'allowing' <i>Domograms</i> to cross the river.</td></tr></tbody></table><p>The rest I'll let you discover yourselves.</p><p>It won't take me long now to add <i>Super Xevious</i> to the transcode, at least as a build option. I'll probably add it before the next beta release on the Neo Geo.</p><p>Oh and when I haven't had the opportunity to work on <i>Xevious</i>, I've been working on <i>Donkey Kong</i>. I've updated the makefile to bring it in line with the <i>Xevious</i> makefile, including eliminating any need for masquerading. I've also moved the Neo Geo-specific code from MAIN into the now-familiar OSD routines, and also removed some macros that I'm not sure why I implemented.</p><p>I still need to fix the mess I made of the graphics routines, where I attempted to support rotation by changing tile/sprite coordinates on-the-fly in the code, rather than writing the original values to shadow memory and converting then or during VBLANK rendering. Once that's done the MAIN code will be 'clean' and even suitable for <b><i>jotd</i></b> to work with on the Amiga.</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-61786322668952018502023-03-17T10:03:00.002+11:002023-03-18T00:03:30.687+11:00Super Xevious coming soon!<p>I've fixed one bug in the Amiga port (it was copied from my code) but I haven't been working on the next beta or the Amiga version as I should be... instead I've been distracted by the possibilty of adding <i>Super Xevious</i> to the transcode.</p><p>To this end, I've been going through the MAIN CPU and naming all the labels; IOW a complete RE except for the comments. And I finished this morning.</p><p>In a nutshell, the <i>Super Xevious</i> MAIN CPU code is a super-set of the <i>Xevious </i>code. The only real differences are the addition of six (6) object handlers at the end of the object handler table and the table of flying enemy types. And of course slight changes to the title screen and copyright messages. Some of the copy protection code has been sacrificed for the new object handlers.</p><p>Adding the additional object handlers wouldn't affect the <i>Xevious</i> gameplay in any way, so there wouldn't be any need to <b>#define</b> those out for a <i>Xevious</i> build. That just leaves the title, copyright and flying enemy table, which would be trivial.</p><p>And as mentioned previously, the SUB CPU code would just require those three (3) different lookup-tables to be selected for each respective build.</p><p>Almost too easy!</p><p><b><span style="color: #ffa400;">UPDATE:</span></b> I've updated my map parsing tool (it's more accurate now and handles the new objects) and have confirmed that none of the previously unused add-object functions in the SUB CPU, and none of the previously unused object handlers in the MAIN CPU are being used by <i>Super Xevious</i>. Thus additions are purely the six new objects. In fact, much of the map, and object counts throughout the map, are very similar to <i>Xevious</i> - it really doesn't play that differently, except perhaps the difficulty level in the new flying enemy table.</p><p>I also looked at the execution flow of the original vs the transcode (the context of the VBLANK interrupt and graphics hardware accesses) in light of the 'shaking ground objects' in the Amiga port. TBH I can't really explain it atm, without suggesting that the Amiga is eg. simply updating the scrolling outside the blanking period?!? I need to discuss further with <b><i>jotd</i></b>...</p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-1235714562632087542.post-57196804034472677842023-03-15T00:22:00.002+11:002023-03-15T00:37:47.069+11:00When is Super Xevious not Super?<p>Today I managed to find a bug that I had inadvertantly caused in the Amiga port of <i>Xevious</i>. So I think <b><i>jotd</i></b> will be happy about that!</p><p>I also found myself stuck en-route to dinner tonight with about an hour to kill, so I pulled out the laptop and worked through more of the RE of <i>Super Xevious</i>. I started with the SUB CPU and whilst I'm labelling all the routines and variables, I'm not adding any comments, unless the code differs from <i>Xevious</i>.</p><p>That's finished now and it turns out that there's only three (3) differences (of any significance) to the two SUB CPU ROMs, and they're all data structures:</p><p></p><ol style="text-align: left;"><li>The object data (where objects appear in aeach area)</li><li>The handler function lookup for various objects (to cater for new objects)</li><li>The flying enemy offset table (which determines which flying enemies and how many appear)</li></ol>The only other differences are a re-organisation of some of the routines (it goes about half-way towards implementing all the handler routines in the same order as they appear in the tables), and inversion of the FREEZE dipswitch setting (and a few extra instructions to handle it).<p></p><p>Since there are no additional handler functions (these functions are only responsible for adding new objects to the object table) - as several object types share the same handler here - my theory is that replacing the SUB CPU ROM in <i>Super Xevious</i> with the ROM from <i>Xevious</i>, will result in <i>Super Xevious</i> playing exactly like <i>Xevious</i>, but with a different title.</p><p>I'll try to put that to the test shortly...</p><p><span style="color: #ffa400;">UPDATE:</span> after patching 2 bytes in the <i>Xevious</i> SUB CPU ROM to ignore the FREEZE setting and replacing the <i>Super Xevious</i> SUB CPU ROM, <i>Super Xevious</i> does indeed run as <i>Xevious</i>. I only played through Area 1, but it shows that it is at least highly compatible.</p><p>What's most important here is the possibility of using a single source base for the SUB CPU ROM for both <i>Xevious</i> and <i>Super Xevious</i>, with assembler directives around the three data structures. Since the transcode doesn't implement the FREEZE dipswitch, that's not an issue either.</p>Unknownnoreply@blogger.com0