Logs, Turtles, Trucks, Tractors and Cars!

Aside from a couple of bugs in my transcode which prevented more than the first line of logs to be displayed, it was trivial to add the other 9 rows of scrolling objects.

No scrolling yet...

Now to get them scrolling!

Logging some progress!

Very quick update; I've done some RE on the code to display the scrolling content and transcoded the top row of logs.

I've transcoded just the top row of logs so far,
the rest will be a doddle.

In the process I came across what is possibly the worst piece of code I've seen in an arcade video game. I spent at least an hour to work out what it was doing; 20 lines of Z80 with a 6-iteration loop, only to replace it with quite literally two (2) 68K instructions (no looping). Pretty sure I could also re-implement it in Z80 in about 6 instructions, no looping. I might post more on this later...

Layout data structures revealed - in part

Some RE tonight and a bit of a breakthrough.

Firstly, I have worked out one of the variables, which I thought more-or-less duplicated another, has a different meaning altogether. Certain things then started to make a lot more sense, and it meant a bit of maintenance on the existing RE. All done now.

Secondly, and this followed on from the abovementioned variable, I've RE'd a bit more of the data structures that define the layout for each of the levels. Still a bit of work to do, but knowing now what it is doing will make finishing this part a lot easier.

I'm almost embarrassed to admit that I wasn't (currently) aware of the fact that each row on the screen only contains a single object type; 4-tile logs, turtle duos, 6-tile logs, 3-tile logs, turtle trios, trucks, cars (type 1), cars (type 2), tractors & cars (type 3) - in that order. I probably did notice at one stage, but it only hit home tonight.

And AFAICT now, the game cycles through only 5 different layouts. Other 'random' factors to mix things up a bit include speed, diving turtles, alligators and seals/otters (whatever they are).

I probably have a few more RE sessions to complete the logic for the scrolling objects, and then I can look at continuing the transcode - row by row by the looks of it.

More RE progress to come

Haven't done a lot of work on Frogger lately, due in part to TdF and visiting family.

I did hit a patch in the transcode where I really need to progress on the RE, or I'm blindly coding unnamed variables and routines, and there's enough of them in there already.

Tonight I have identified the jump table that handles all the scrolling objects, and by extension, the area of RAM that holds the data associated with them as the game progresses. I discovered something surprising about it, but I'll leave it until I've confirmed it, which shouldn't take too long.

This has just opened up a the opportunity to RE a new set of routines and memory variables, so I'm hoping to make progress on those in subsequent sessions. Only then will I switch back to transcoding.

As a result, no new eye candy in this post, sadly.

Pretty fly for a transcode

Still plugging away at Frogger as time allows.

I've been working through the high-level foreground/background (depending on your nomenclature preference) and NMI code, ensuring I've transcoded everything that is not in a subroutine. Along the way I've managed to name a few more variables, mostly simple flags, but also decided others have multiple purposes (the classic 'temp' variable). Ugh. Work that had to be done, but resulted in no tangible difference on the screen.

My next thought was to implement the code that handles when your frog gets 'home' - that's quite brain-dead and clearly identified in my RE. Alas, it's not actually possible to get home without scrolling logs to position you in the center of each home. So back to the drawing board.

Next idea was to handle the (seemingly) random appearance of the fly in the frog's homes. There wasn't a great deal of code, and the timers involved were all ticking over already, so it didn't take a great deal of effort to see it working.

A fly appears briefly!

Now it's crunch time; no choice but to tackle the scrolling cars and logs, turtles, alligators etc. This involves diving into code that I haven't fully RE'd. Some of it I have a high level understanding of what it is doing, but don't understand any of the detail. For example there are tables of bytes that are copied into RAM that comprise logic & data for the scrolling entities, and calculations that are done on some of that data which escape my understanding atm.

But at the same time, there are aspects of the code that do offer good hints, like it seems there's a routine to construct/update each of the scrolling rows explicitly. So for example, I believe that I can transcode the routines to update, say, just the bottom row of vehicles on the road.

For now though, I'm in the middle of wrapping my head around a routine that I guess calculates where to start drawing the log on one of the rows. It works backwards from the VRAM address and a few bytes that would indicate some sort of scroll position maybe? Not the sort of routine that translates well from Z80 to 68K either, so understanding what it's doing is definitely going to be more beneficial than a brute-force transcode.

By my crude calculation, the transcode is now 39% done.

Transcode now one-third done!

Turns out the 'freezing' of the game after GAME OVER was due to a simple bug in the transcode. It was trashing a whole bunch of variables from which it never recovered.

Now it runs back through the attract mode screens as it should.

I also transcoded the routine that updates the high score table after a game. It hasn't been tested yet as I am unable to score more than 300 pts, but at least it no longer highlights any of the scores after the game (it highlights the scores on the high score list - if any - from the last game).

I have the estimated transcode at 34% done, so now "officially" one-third done!

No eye candy today.

Scoring!

Not much time to work on Frogger now that it's school holidays AND Tour de France time... but I did get the score updated whenever the frog hops forward.

Getting a frog to the top of the screen
will earn you 100 pts.

Not that I went looking to do this, but a side-effect of trying to stop the game freezing after GAME OVER rather than cycle through the attract mode screens again.

GAME OVER

I've now got it displaying "GAME OVER" when the last frog dies...

It animates the frogs dying
before showing the GAME OVER screen

However after subsequently clearing the screen, it hangs the Neo Geo.

I have done a little more RE and identified some more of the code, specifically the code that animates the dying frog. Not a huge leap forward, and the number of unlabeled flags, counters & timers just keeps growing, but I am trying to transcode the main NMI and background execution flows even if these variables remain 'unknown' in order to get the game cycling through attract mode and gameplay.

The transcode is nearing the one-third mark!

Why did the frog cross the road?

Managed to fix the never-ending frogs left display; from memory (I've forgotten already) it was a flag/timer that was never updated in what I had transcoded, so it was forever decrementing a frog.

I also managed to get the player inputs working, after implementing another cascading execution flow of arbitrary flags and counters. Ironed out a few bugs in the input routines in the process and can now hop around the screen within the confines of the coded limits.

Hopping across the road in game mode

On that note, I had never realised you could jump down below the starting row, and over the timer bar. But I did subsequently confirm this on the emulated Frogger in MAME. You also can't jump left/right from the uppermost ('home') row, but that's a moot point because hitting that row you're either home or dead.

So with nothing to kill the frog, the time runs down until "TIME OVER" is displayed and then it just sits there. I'll now look at finishing off the logic that will properly end the game and re-enter attract mode. Besides a few bits that I've purposefully skipped - like high score table update - that'll be everything outside the gameplay mechanics of moving the objects and killing the frog.

I figure (roughly) that the transcode is now 30% done.

My frog still won't budge

I've been working towards getting the gameplay to a point where I can control the frog. Given that it hops around in attract mode, I figured the mechanics at least were there. But it has been a bit of a slog to get to the point where it will actually move, and I'm still not there yet.

The transcode is approximately 30% complete now, and during that time I've made very little progress on the RE side of things. I've named a few timers here and there but that's about it.

[rant]

I can't hold back any longer; this really is crappy code. For the amount of time I've spent on RE and transcode with this project, I can't believe I still don't have a clear picture in my head about the overall program structure. It's a tangled mess of spaghetti code with execution paths that just meander through the memory space, duplicated functionality in the code, functions that call seemingly unrelated subroutines, duplicated variables (as far as I can tell) and a plethora of flags and timers that defy a precise description of function. I can't even partition the code in my head between NMI (which is triggered by VBLANK and must run FAR longer) and main execution, they both seem to be doing a little bit of everything. This had to be written by an intern at Konami.

[/rant]

Anyway, the lack of structure makes it very difficult to work out which parts of the code I need to implement to get the player controlling the frog. You just need one timer to not be ticking, or one flag to not be set, and the whole execution flow breaks down. In my handful of transcodes thus far, I've never had this problem. It's going to be painful.

So the plan forward is to continue on with the transcode, and do what little RE I can in the process. I'm aiming to get the frog moving without any of the traffic or logs, turtles etc. in the picture but, given what I've seen so far, I wouldn't be surprised if the timer used (and updated in) the diving turtles routine also handles player inputs! OK, maybe not that bad, but it's a challenge.

I'll leave you with a screenshot of what I see after coining up and starting a game. Currently the code is continually incrementing and printing the number of frogs, and I'm not sure why yet. Maybe I need to look at the bonus frog logic...

It keeps incrementing the number of frogs...

UPDATE: It's actually calling decrement frogs continually...

Frogger

It's been a long time since I posted anything on this blog, and that's because I haven't done anything retro-porting related in all that time. I had started on a now-stalled project creating a new core for the MiSTer hardware, but even that was probably a year ago now.

In recent weeks I decided it was time to work on another port. To be honest, I struggled to find a candidate that I was both interested in personally, and could run on the Neo Geo - my favourite retro platform for porting. I was really looking for a horizontal title, but finally settled on Frogger thinking it would be relatively simple. After all, I had done Galaxian and it is essentially the same hardware.

I'm now a few weeks into the RE - I'd estimate about 65% done - and have actually started on the 68K implementation before finishing the RE. Initially the decision to start on the implementation was more due to impatience than anything else, but I've actually found it helps with the RE.

Not surprisingly, I was able to create the Neo Geo assets for Frogger using the same tools I built for Galaxian, almost without any changes. Ditto for the Neo Geo code itself. I'll have to keep this in mind for any future projects on the same hardware, and there were quite a lot of games on Galaxian hardware, even if some were bootlegs.

So, right now the attract screens - title, points table, high score, insert coin - have all been implemented. The static elements of the gameplay screen are drawn in attract mode, and the frog happily leaps across an otherwise empty screen as the time bar counts down. You can also coin up and start a game, though visually it appears to just hang on the start screen. A crude comparison of the Z80 and 68K assembler listings would suggest the transcode is about 21% done.

A few screenshots of  Neo Geo Frogger in action.

The frog hops around in the attract mode gameplay

The next step is adding gameplay elements. This will be a process of RE and transcoding in parallel.

And that's probably it for Vulgus!

I've decided to put Vulgus to bed.

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.

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.

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.

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.

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.

That's it for Vulgus... for now at least.

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.

Let's see what takes my fancy next...

You'll want to collect 'E' as well!

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.

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!

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!!! 😶

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.

Nothing to do with 'E', just eye candy for attention

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.

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...

Parallax Scrolling!?!

Another quickie; cracked a few more variables in the last session which revealed an interesting if subtle detail to the game.

I had previously deduced the meaning of one variable to be the amount by which the background had scrolled left/right (dy), 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.

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 other variable is actually dy for the background and ground-based objects and the first variable is dy for airborne objects, such as bullets and aliens.

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.

[I should note that I use dy for left/right movement rather than dx 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!]

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...

Here are the areas I have visited but have yet to complete:

• Background map generation/rendering; the data appears to be packed into blocks of meta-data
• Alien movement; alien movement is all table-driven
• 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

I think that's about it.

'S' is for... nothing!

Just a quick one... still progressing on Vulgus, chipping away at the unknown variables.

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.

Somewhat puzzling given that the other two letters do affect game play.

Random Vulgus picture for attention

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.

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.

It's official, collecting the letter 'D' is good!

I haven't posted in a while but I have been making quite a lot of progress on the RE.

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.

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.

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.

On the subject of collecting 'D' from an earlier post, I can say with absolute authority that it is beneficial to the player. Here's what the Vulgus manual on Capcom Arcade Stadium on the Nintendo Switch has to say about it:

"Increases enemy firepower when it appears. Collect it to stop the effect."

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).

Not a 'D', but here's an 'E' just for attention

'E' & 'S' are related to other variables which I haven't examined in detail just yet.

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.

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!?!

Slowly taking shape

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.

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.

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!

More to come on that subject...

UPDATE: I'll just tack onto the previous post...

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.

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.

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.

I can say that collecting 'D' is at least beneficial to the player in one aspect... more I can't say yet.

Answers and Questions

More progress tonight and more questions than answers.

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...

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.

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!

And it gets even stranger - it doesn't seem to call these routines in attract mode!?!

More to come...

UPDATE: I was curious about the bullet sprite vs tile issue, so I looked a little further into it...

During attract mode, the bullets are rendered as sprites, using hardware sprites 4-7.

During gameplay, the bullets are rendered as foreground layer tiles.

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!

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!!!

Why?

I haven't looked further into it, but I have my theory.

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.

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!?!

I've never seen anything like this before! 😲

Vulgus RE progressing a little better than I initially expected!

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.

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!!!

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.

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.

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.

Part of the instructional sequence - quite a lot of code required

My overall impression is that the code isn't exactly the best I've come across; Xevious 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.

And finally for this post; there's the debate over whether collection of the letters 'E', 'S' & 'D' 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 MISSED, rather than how many you've collected!!!

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!

Holiday project - Vulgus RE

Long time no post!

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...

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 Vulgus. Vulgus 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.

MAME screenshot

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.

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 Galaxian and Scramble - 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.

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'.

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.

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.

Next task is to return to the code and work out a way to render the entire map, as I did for Xevious (although I was far from the first to do that). I'm pretty sure I'll be the first to do it for Vulgus though.

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.

UPDATE: 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 think you can travserse the entire map 3 times before it resets?!?