Super Castlevania IV FastROM Patch - Improves performance

Brazilian hacker Vitor Vilela (@HackerVilela) (the same guy responsible for the Gradius III and Contra III SA-1 patches) has released a FastROM patch for Super Castlevania IV which dramatically improves the performance of the game:
https://github.com/VitorVilela7/fastrom/releases

https://sneslab.net/wiki/How_to_apply_ROM_patches

Quote:

---

Some games like Castlevania were made in SlowROM (2.68 MHz). Project FastROM makes them run in FastROM (3.58 MHz) instead. FastROM allows the SNES CPU to read data and opcodes from the ROM 33.58% faster compared to SlowROM.

---

Link to his SA-1 patches:
https://github.com/VitorVilela7/SA1-Root/releases

He's currently working on a Super R-Type SA-1 patch.

When these started coming out I was surprised that they didn't already exist, given the popularity of the SNES.

It's cool to be able to see the real performance that devs got out of the hardware for launch window games.

This is cool. Thanks for posting this Barone.~

Quote:

---

Originally Posted by Black_Tiger

When these started coming out I was surprised that they didn't already exist, given the popularity of the SNES.

It's cool to be able to see the real performance that devs got out of the hardware for launch window games.

---

It appears that you need a cart with an SA-1 chip on it, for this to work.

Quote:

---

Originally Posted by Black_Tiger

When these started coming out I was surprised that they didn't already exist, given the popularity of the SNES.
It's cool to be able to see the real performance that devs got out of the hardware for launch window games.

---

I was a bit blown away by Gradius III without slowdown. The parts where you have lots of bubbles on screen is quite impressive and the music has always been great.

Quote:

---

Originally Posted by BonusKun

This is cool. Thanks for posting this Barone.~

---

Thanks, you're welcome.

Quote:

---

Originally Posted by gamevet

It appears that you need a cart with an SA-1 chip on it, for this to work.

---

Not for Super Castlevania IV, any regular flashcart is enough for this one.

For the SA-1 hacks (Contra III, Gradius III), then you'll need something like a SD2SNES.

I do have an SD2SNES cart. I definitely want to check out Gradius III with the mods.

Thanks for the heads up.

Very interesting thread this. Is there anything similar for the MD? Or would it just melt CPU on account of the blast processing?

Serious question though.

Quote:

---

Originally Posted by cleeg

Very interesting thread this. Is there anything similar for the MD? Or would it just melt CPU on account of the blast processing?

Serious question though.

---

I don't remember the MD having a slower cpu speed available.

The PCE can run at the same slower speed as the SNES but I don't think any games use it and it may still require extra fast memory for games.

There is a thread somewhere on here about overclocking Mega Drive hardware. I believe that Barone contributed a lot of test results.

Quote:

---

Originally Posted by Black_Tiger

I don't remember the MD having a slower cpu speed available.

The PCE can run at the same slower speed as the SNES but I don't think any games use it and it may still require extra fast memory for games.

There is a thread somewhere on here about overclocking Mega Drive hardware. I believe that Barone contributed a lot of test results.

---

Sort of, the PCE can run at the same speed as the NES and some games have been converted from NES to PCE.

The PCE CPU is much faster than the SNES at 8-bit operations, but it would need more cycles for 16-bit stuff.

To get the MD equivalent of what Vitor is doing, it would be like adding a 30 MHz 68k into a Genesis cart. Except I don't think such a chip exists so the closest would be like a 33 MHz 68020.

Quote:

---

Originally Posted by gamevet

I do have an SD2SNES cart. I definitely want to check out Gradius III with the mods.
Thanks for the heads up.

---

You're welcome, gamevet.

Quote:

---

Originally Posted by cleeg

Very interesting thread this. Is there anything similar for the MD? Or would it just melt CPU on account of the blast processing?
Serious question though.

---

Quote:

---

Originally Posted by Black_Tiger

I don't remember the MD having a slower cpu speed available.
The PCE can run at the same slower speed as the SNES but I don't think any games use it and it may still require extra fast memory for games.
There is a thread somewhere on here about overclocking Mega Drive hardware. I believe that Barone contributed a lot of test results.

---

Thanks for the inputs.

Regarding the clock discussion:
- Like Black_Tiger was saying, early SNES games used slowROM and that implicated in the CPU running 33% slower; games like SCIV ended up running at below optimal framerate for that reason.
The fastROM hack basically makes the SNES run at its full speed.

- The Mega Drive doesn't have a slower mode like that but some early games also used slower ROM chips. They don't affect the regular performance but if you try to run them on an overclocked Mega Drive then you'll run into issues.
The rev00 of Super Hang-On is known for having unlocked frame rate and can be boosted from 20 fps to 30 fps once you overclock the Mega Drive to either 10 MHz or 12 MHz. BUT we've seen that the old original carts would glitch out at times, supposedly due to the ROM chip they use, while it runs fine from an Everdrive or in the later re-release of the rev00 contained in the Mega Games collection.
Not all games have uncapped framerate, but several ones do benefit. Most enjoyment I got from it was probably Super Hang-ON and Zero Tolerance (which is actually quite playable at 12 MHz).

- There's a thread I created years ago which compiles a lot of valuable info related to overclocking on the Mega Drive. The results depend on the hardware revision you own, with the Mega Drive 1 VA5 and VA6 being those which can run stable at 12 MHz most games. Other models are usually stable up until 10 MHz.
https://www.sega-16.com/forum/showth...atibility-List
Years ago there was a belief that you had to use more expensive oscillators, shielded and very short wiring in order to achieve better results. I was able to come up with a cheapo alternative at the time which would rely on the use of a Schmidt trigger to output a more stable clock signal and then I used the cheapest oscillators I could find at the time on eBay (from a Czech seller) with regular wires and it worked fine for me: https://docs.google.com/drawings/d/1...it?usp=sharing

- Other than overclocking, you can also replace the 68000 with a 68010 processor but then you'll run into many compatibility issues with several games, since it has a bit different handling of some specific instructions. The 68010 should give you a 5 to 10% boost due to it being more efficient with division and multiplication; difference would be more noticeable in polygonal games which use those instructions a lot. ComradeOj did a lot of tests with that, this an interesting one:
https://www.youtube.com/watch?v=0G4yuvCo-gc

But the incompatibility issues are annoying and include games such as Sonic 3. We failed to fix Sonic 3's compatibility at the time, for an example. You would need to come up with patches for each incompatible game and in some cases it might be quite difficult.

- SNES overclocking is a no-go as far as the console hardware goes, it doesn't support even the least amount of it. But people did came up with lots of overclocking mods for the SuperFX carts.
Thunderblaze16 has a good tutorial on it: https://www.sega-16.com/forum/showth...Super-FX-games
Modern premium flashcarts also support some overclock to the SuperFX implementation IIRC.
For general use on other games though, the solution came from these Vitor Vilela's recent hacks. And they are extremely laborious for what I've seen.
But you get the advantage of not needing to mod your console or worrying about shortening the life cycle of them.

- In terms of software patches for MD games, I tried years ago to hand-optimized Corporation (yeah, that damn old FPS game) for the MD but it didn't get where I wanted. I still have like revision 30 of the hack here with me and I need to release it to the public. I did managed to improve the controller responsiveness by accident, lol. I figured there was a UI loop used to control the pointer speed which also deteriorate the controls in game.
Such hacked hand-optimization is a thankless job because unless you stumble onto some really big fuck up, you won't gain much even if you rewrite hundreds of assembly lines as I did. You'd need to have proper profiling tools and more knowledge of the logic of the game and the VDP itself than I have (which is not much).

- Another thing that nobody tried so far but that I think that could bring some nice in-game results for some MD games would be to decompress old small-sized games into bigger ROMs that any Everdrive would run fine nowadays.
Some games, such as Gaiares, take a long time (full seconds) without in-game action to decompress the next wave of enemies to the VRAM. You could increase the pace of the game if you eliminated the need to do that on-the-fly and worked with uncompressed graphics like SFII SCE does.
This is something I'd like to try one day since there are some tools available for some of the old and most used compression schemes in MD games.

Quote:

---

Originally Posted by axel

To get the MD equivalent of what Vitor is doing, it would be like adding a 30 MHz 68k into a Genesis cart. Except I don't think such a chip exists so the closest would be like a 33 MHz 68020.

---

It depends on the game.
Some SNES games use the SA-1 chip mostly for graphics decompression since the SNES uses planar graphics and the compression favors other formats, so the decompression is usually more complex on the SNES than on the Mega Drive (see Mickey Mania for an example of much longer loading times).
In such cases, if you could just use a bigger ROM you could achieve similar results. IIRC, some of the slowdowns you see in MD's Crude Buster is due to the enemies graphics decompression running on the fly. Other old MD games have full pauses that could have been eliminated if you used decompressed graphics data instead.

AFAIK, Krikzz has been working on something that would allow patched MD games to use a FPGA-implemented coprocessor for division and multiplication and that would accelerate some MD games tremendously.
Not my cup of tea though. I prefer something like Vitor is doing which sticks to the enhancements available during the original life cycle of the platform.

The problem with that Super Hang-On overclock is the entire game runs in fast-forward mode. It's not just a higher frame rate but the entire game is running faster. That's not cool. Same with Super Castlevania IV. I noticed that some things are definitely moving faster than normal rather than the same speed with an increased framerate, which would be preferable.

Quote:

---

Originally Posted by Barone

AFAIK, Krikzz has been working on something that would allow patched MD games to use a FPGA-implemented coprocessor for division and multiplication and that would accelerate some MD games tremendously.
Not my cup of tea though. I prefer something like Vitor is doing which sticks to the enhancements available during the original life cycle of the platform.

---

I agree with you in principle, but it sounds like what Krikzz is doing is just using the FPGA to speed up the 68000 instructions, as if there had been a faster 68k in the cart. To me that seems plausible during the MD lifespan (just like the faster CPU in the Sega CD) versus using entirely new tech that didn't exist in the 1990s. I guess it depends how much faster it runs.

The thing about the 4th gen is that the SNES needed all these extra chips to compensate for the dog slow CPU, on the Genesis most games don't really need extra processing power. They would benefit more IMO by adding more color palettes, so if an emulator or FPGA clone wants to add support for 32 palettes and then people want to hack the games to support that I think the results could be interesting.

Quote:

---

Originally Posted by axel

The thing about the 4th gen is that the SNES needed all these extra chips to compensate for the dog slow CPU, on the Genesis most games don't really need extra processing power. They would benefit more IMO by adding more color palettes, so if an emulator or FPGA clone wants to add support for 32 palettes and then people want to hack the games to support that I think the results could be interesting.

---

Megadrive VDP had native support for a 128 colour mode, by using an external ram chip for the extra palettes. I'm not sure if any emulators support this mode.

There's also a 128k VRAM mode, which is useful because it allows for uploading nearly twice as much data to the VDP during vblank. This alone would make framebuffer based games significantly faster (this includes all FMV games, all Sega CD scaler games, Virtua Racing, and any other game that is handicapped by the amount of tiles it is uploading on-the-fly to the VDP such as games using software 3d graphics). The downside is that the memory is interleaved, so enabling this mode breaks all existing games. But an emulator could create a standard, such as a bit in the header indicating support, that an emulator could interpret and selectively turn the mode on for certain ROMs.

Kind of thinking about it, do any emulators allow for either of these? I think Exodus is the only one that possibly could, given how much research Nemesis put into this, but I don't know if the emulator actually can do it.

On a side note, the 128k VRAM mode was available in the Teradrive and possibly some development hardware (unconfirmed). The extra palette mode may have been used in the arcade C2 hardware (a mostly megadrive based board).

Quote:

---

Originally Posted by axel

I agree with you in principle, but it sounds like what Krikzz is doing is just using the FPGA to speed up the 68000 instructions, as if there had been a faster 68k in the cart. To me that seems plausible during the MD lifespan (just like the faster CPU in the Sega CD) versus using entirely new tech that didn't exist in the 1990s. I guess it depends how much faster it runs.

The thing about the 4th gen is that the SNES needed all these extra chips to compensate for the dog slow CPU, on the Genesis most games don't really need extra processing power. They would benefit more IMO by adding more color palettes, so if an emulator or FPGA clone wants to add support for 32 palettes and then people want to hack the games to support that I think the results could be interesting.

---

They do other things like decompressing files to keep cart sizes down. Street Fighter Alpha 2 actually has some load times, while the data is being decompressed using the S-DD1 chip inside of the cart. The downside is, that the music is horrendous, because all of the sprite data used up most of the cart's space.

Quote:

---

Originally Posted by zyrobs

Megadrive VDP had native support for a 128 colour mode, by using an external ram chip for the extra palettes. I'm not sure if any emulators support this mode.

There's also a 128k VRAM mode, which is useful because it allows for uploading nearly twice as much data to the VDP during vblank. This alone would make framebuffer based games significantly faster (this includes all FMV games, all Sega CD scaler games, Virtua Racing, and any other game that is handicapped by the amount of tiles it is uploading on-the-fly to the VDP such as games using software 3d graphics). The downside is that the memory is interleaved, so enabling this mode breaks all existing games. But an emulator could create a standard, such as a bit in the header indicating support, that an emulator could interpret and selectively turn the mode on for certain ROMs.

Kind of thinking about it, do any emulators allow for either of these? I think Exodus is the only one that possibly could, given how much research Nemesis put into this, but I don't know if the emulator actually can do it.

On a side note, the 128k VRAM mode was available in the Teradrive and possibly some development hardware (unconfirmed). The extra palette mode may have been used in the arcade C2 hardware (a mostly megadrive based board).

---

Wow, I had no idea the Teradrive had that. Mentioning the arcade hardware gives me an idea, has anyone ever tried converting MD games over to the System 16A? That would open up a ton of possibilities for ROM hacks with a faster CPU, more colors, more sprites, scaling, translucency etc and it's still authentic to hardware that actually existed back in the day.

Quote:

---

Originally Posted by axel

has anyone ever tried converting MD games over to the System 16A? That would open up a ton of possibilities for ROM hacks with a faster CPU, more colors, more sprites, scaling, translucency etc and it's still authentic to hardware that actually existed back in the day.

---

I don't think anyone has tried that yet, probably due to three factors: 1) Lack of debugging tools for platforms such as System 16, 2) Lack of interest since part of the appeal is to be able to run stuff on real hardware and who owns actual arcade PCBs these days?, 3) No everdrive for such boards.

2) and 3) can be mitigated if stuff such as MiSTer gets really popular.

Quote:

---

Originally Posted by Barone

I don't think anyone has tried that yet, probably due to three factors: 1) Lack of debugging tools for platforms such as System 16, 2) Lack of interest since part of the appeal is to be able to run stuff on real hardware and who owns actual arcade PCBs these days?, 3) No everdrive for such boards.

2) and 3) can be mitigated if stuff such as MiSTer gets really popular.

---

I mean...there's the MAME debugger right? :p

Ideally something like the Mega Sg could be updated to run games from Sega arcade boards. That was always Sega's goal, wasn't it? Bring the arcade home? They could have made one of their boards into a home console like SNK with the AES, they just chose to make a few downgrades to reduce cost. I agree though there's no interest in that kind of thing. But if people want an enhanced Genesis it's been there since 1985.

Quote:

---

Originally Posted by axel

I mean...there's the MAME debugger right? :p

Ideally something like the Mega Sg could be updated to run games from Sega arcade boards. That was always Sega's goal, wasn't it? Bring the arcade home? They could have made one of their boards into a home console like SNK with the AES, they just chose to make a few downgrades to reduce cost. I agree though there's no interest in that kind of thing. But if people want an enhanced Genesis it's been there since 1985.

---

If arcade home means playing on flat panels without the proper bloom, contrast, definition and gamma ramp the game was designed for, then, yes.
Seriously though, MiSTer seems to be a far better option and there is more work and knowledge accumulated on that front.

Contrary to popular belief, MD and System16 are quite different things, especially concerning graphical abilities.

A simpler idea would be to hack some emulator (or ideally FPGA code) to implement simple enhancements of the MD hardware :

1) backgrounds palette and sprites palettes dissociated (4+4)
2) 12 bits colors for master palette
3) 128 KB VRAM (like the Teradrive)

Hacking games for this ideal platform would be really easy (simple palette hacks would beneficiate from 12bits colors, and hardly trickier would take part of the dissociated sprites/bg palettes).

I'm dreaming of such a think for several years now :)

This is a great thread. Loving all the comments.

Just a head ups, If anyone decides they want to do some off topic thread shitting, I'm letting Barone decide who gets a foot in their ass.~

Quote:

---

Originally Posted by tryphon

Contrary to popular belief, MD and System16 are quite different things, especially concerning graphical abilities.

A simpler idea would be to hack some emulator (or ideally FPGA code) to implement simple enhancements of the MD hardware :

1) backgrounds palette and sprites palettes dissociated (4+4)
2) 12 bits colors for master palette
3) 128 KB VRAM (like the Teradrive)

Hacking games for this ideal platform would be really easy (simple palette hacks would beneficiate from 12bits colors, and hardly trickier would take part of the dissociated sprites/bg palettes).

I'm dreaming of such a think for several years now :)

---

That would be cool. The bigger master palette would have opened up Game Gear compatibility. If I'm doing a wishlist of features, I'd like to see widescreen hacks, which have already been done in Higan for Super Mario World and Link to the Past. I am unaware of any Genesis emulator with such a feature. The Genesis was the first console to have widescreen support (via 32X Virtua Fighter) so it's only fitting.

One thing that I would like to see implemented in these FPGA-based MDs is a CLUT feature.

It could benefit several games without the need to hack them.

You could have different color profiles linked to games.
Default one should always be the original MD colors but some specific profiles could be applied to dozens of games by the user without many cons.

A lot of games suffer with the lack of proper brown tones (especially the dark ones), since the MD's palette tend to be too red-ish in that side of the spectrum.

One of the many examples:
https://www.letsplaysega.com/wp-cont..._Adventure.png

What it was supposed to be (ignore the extra shading):
https://www.mobygames.com/images/sho...-the-first.png

Even when you try to hack the colors it still looks bad and to redo the whole artwork to workaround that simply isn't feasible, even if you had all the knowledge and tools necessary to edit all the tiles and sprites.

Quote:

---

Originally Posted by axel

Wow, I had no idea the Teradrive had that. Mentioning the arcade hardware gives me an idea, has anyone ever tried converting MD games over to the System 16A? That would open up a ton of possibilities for ROM hacks with a faster CPU, more colors, more sprites, scaling, translucency etc and it's still authentic to hardware that actually existed back in the day.

---

System-16 has crappy color rules for background tiles. Judging from existing games it looks like each tile can only use 4 visible colors and few palettes. The Mega Drive can and has already done much better overall backgrounds. The trade off wouldn't be worth it.

But I'm also not interested in fake Mega Drive games. The limitations are what the hardware and software's identity and charm are built from.

Quote:

---

Originally Posted by Black_Tiger

System-16 has crappy color rules for background tiles. Judging from existing games it looks like each tile can only use 4 visible colors and few palettes. The Mega Drive can and has already done much better overall backgrounds. The trade off wouldn't be worth it.

But I'm also not interested in fake Mega Drive games. The limitations are what the hardware and software's identity and charm are built from.

---

Wow I never knew it was that bad at backgrounds. I know Cotton has some areas that look almost monochromatic but in that type of game it's a good thing to see all the stuff flying at you. Golden Axe, Wonderboy III and Dynamite Dux only have 4 colors per BG tile? I would never have noticed that.

Quote:

---

Originally Posted by BonusKun

This is a great thread. Loving all the comments.

Just a head ups, If anyone decides they want to do some off topic thread shitting, I'm letting Barone decide who gets a foot in their ass.~

---

Woah!


https://www.sega-16.com/forum/attach...8&d=1609475530

lol Thanks eric. I needed the laugh.

Quote:

---

Originally Posted by axel

Wow I never knew it was that bad at backgrounds. I know Cotton has some areas that look almost monochromatic but in that type of game it's a good thing to see all the stuff flying at you. Golden Axe, Wonderboy III and Dynamite Dux only have 4 colors per BG tile? I would never have noticed that.

---

Golden Axe is particularly bad. It does full detail across the screen and bleeds colors between assets. The end result is mostly monochromatic elements, but something bluescale will have a brown running through it.

Altered Beast went for a clean look and when you examine it you can see how they designed the backgrounds to have assets share colors and assets that don't stand out as low color. It also looks like they might have used a tile layer for the larger bosses and had the background turn to greyscale to free up the palettes.

Quote:

---

Originally Posted by Black_Tiger

Golden Axe is particularly bad. It does full detail across the screen and bleeds colors between assets. The end result is mostly monochromatic elements, but something bluescale will have a brown running through it.

Altered Beast went for a clean look and when you examine it you can see how they designed the backgrounds to have assets share colors and assets that don't stand out as low color. It also looks like they might have used a tile layer for the larger bosses and had the background turn to greyscale to free up the palettes.

---

Wow, you're right. Now it makes sense why Altered Beast fades the backgrounds during boss fights.

Pretty cool, games like Biometal, EDF, Area 88, Phalanx, Return of Double Dragon + Kunio and other early stuff would benefit a lot from this. Also Konami games like Parodius, Axelay and Turtles in Time seem to run on SlowROM which is kinda impressive, those games have nice performance as is, same with Super Aleste.
edit: also in awe that all Natsume games use SlowROM :shock:

Quote:

---

Originally Posted by axel

Sort of, the PCE can run at the same speed as the NES and some games have been converted from NES to PCE.

The PCE CPU is much faster than the SNES at 8-bit operations, but it would need more cycles for 16-bit stuff.

---

Not true, actually. Even in 3.57mhz mode, the SNES cpu has extra cycle penalties for 16bit mode operations, not to mention that work ram is always 2.68mhz - and the 65x pretty much being a Read-modify-write type processor hits ram for already every instruction and for multiple bus cycles. It pretty much brings it down to 3.05mhz range. I clocked full 16bit and 16bit -> 16bit operations (not half cheating with early exit branches) on the PCE to be faster than the SNES. The only thing faster really is the multiply unit, but that's not the processor itself, and shift instructions.

Honestly though, I wish someone would run a cpu analysis on these games when they're running, just to see how much the cpu overblows the vsync flag 'window'. For some of these games, it literally just could be like 2-3% cpu resource over the limit, because it's an all or nothing thing for the frame rate for the game logic.

Quote:

---

Originally Posted by axel

Sort of, the PCE can run at the same speed as the NES and some games have been converted from NES to PCE.

---

If you're talking about the nes2pce games I did, they run at PCE's full speed because they emulate/simulate the NES video and audio hardware in realtime. Even with that overheard, the slowdown is removed from the games running on PCE haha. Vsync keeps the games running in sync, but special timed code for sprite detect 0 has to be manually fixed in the rom to compensate.

Quote:

---

Originally Posted by Black_Tiger

System-16 has crappy color rules for background tiles. Judging from existing games it looks like each tile can only use 4 visible colors and few palettes. The Mega Drive can and has already done much better overall backgrounds. The trade off wouldn't be worth it.

---

System16 tiles are 3bit (7colors + 1), but it literally has hundreds of palettes for the background. Sprites are 4bit, but only 14 showable colors instead of 15 because of how they are encoded.


@Barone; here's hoping he does some original homebrew stuff with the SA-1, with all that experience. I believe he has a youtube video of a hack for SMW, where he uses the SA-1 for dynamic cell removal for overlapping sprites (ala what Paprium was supposed to do at one point IIRC) showing a bunch of big boo sprites. Cool stuff!

Quote:

---

Originally Posted by turboxray

Not true, actually. Even in 3.57mhz mode, the SNES cpu has extra cycle penalties for 16bit mode operations, not to mention that work ram is always 2.68mhz - and the 65x pretty much being a Read-modify-write type processor hits ram for already every instruction and for multiple bus cycles. It pretty much brings it down to 3.05mhz range. I clocked full 16bit and 16bit -> 16bit operations (not half cheating with early exit branches) on the PCE to be faster than the SNES. The only thing faster really is the multiply unit, but that's not the processor itself, and shift instructions.

Honestly though, I wish someone would run a cpu analysis on these games when they're running, just to see how much the cpu overblows the vsync flag 'window'. For some of these games, it literally just could be like 2-3% cpu resource over the limit, because it's an all or nothing thing for the frame rate for the game logic.



If you're talking about the nes2pce games I did, they run at PCE's full speed because they emulate/simulate the NES video and audio hardware in realtime. Even with that overheard, the slowdown is removed from the games running on PCE haha. Vsync keeps the games running in sync, but special timed code for sprite detect 0 has to be manually fixed in the rom to compensate.

---

Oh hey, I didn't realize that was your work! Very impressive. And wow I am surprised the SNES CPU is *that* bad.

Quote:

---

Originally Posted by axel

Oh hey, I didn't realize that was your work! Very impressive. And wow I am surprised the SNES CPU is *that* bad.

---

I mean, there are areas where it's faster.. or just easier, like doing things like $0000,y which is basically [Y]. That's kinda nice. Long addressing (direct and indirect) is also nice, even if a little more expensive. A 7mhz version of the processor would have been incredible haha, even with the 8bit data bus.