Disassembly of multi-bank ROMs

[+stephena]

OK, first a little context. For the next major release of Stella, I'm planning to add support for generating DASM-compatible assembly source code which can be output to a file. The ideal end result would be producing assembly code that, when re-compiled, is byte-exact to the original ROM. I have this pretty much working 100% for 4K and smaller ROMs. In the process, I also improved the the actual in-debugger disassembly, since it wasn't always absolutely correct (and it was impossible to tell that until a recompile of the actual output was attempted). The main impetus for this is that Distella isn't really maintained, is simply a static analysis, and doesn't work with multi-bank ROMs without manual intervention. The first two of these issues are addressed in Stella, since (a) it is maintained, and (b) it augments the static disassembly with runtime analysis. The third issue is what I'm addressing here.

 

So, I'm looking for advice on how to disassemble multi-bank ROMs. For now I'm considering the simple cases, so F8/F6/F4 schemes only (8K/16K/32K, respectively). Eventually, if I can get the previous ones working, I'll consider the Superchip variants, and then possibly the more esoteric schemes. But that will probably take several releases to get right.

 

My first question is how to accurately determine the ORG/RORG addresses to use? My first guess was to look at the reset vector in each bank, and use that directly. Many ROMs, such as Battle Zone and Moon Patrol, do set this up correctly, and use $D000 for bank 0, and $F000 for bank 1. To me, the disassembly there seems straightforward. Others, however, seem to use $F000 for all banks. So how would such a file be disassembled? How would you differentiate between banks??

 

I guess I'd like some feedback from people that have done manual Distella disassembly for F8/F6/F4 ROMs, and suggestions on how to automate the procedure. Also, some very simple test ROMs with source would be extremely useful, since I could use them as test cases to verify that my code is doing an accurate disassembly. Ideally, I'd need test ROMs for both the normal case (each bank has a clearly differentiated reset vector/ORG address), and the other case (all banks seem to use the same ORG address).

 

Thanks in advance for any help you can provide. This feature has been requested for years, and if it comes to fruition, will make disassembly of ROMs much easier.

[Omegamatrix]

My first question is how to accurately determine the ORG/RORG addresses to use? My first guess was to look at the reset vector in each bank, and use that directly. Many ROMs, such as Battle Zone and Moon Patrol, do set this up correctly, and use $D000 for bank 0, and $F000 for bank 1. To me, the disassembly there seems straightforward. Others, however, seem to use $F000 for all banks. So how would such a file be disassembled? How would you differentiate between banks??

 

I'm glad you noticed that. You actually hit the nail right on the head. Using the reset vector doesn't work a lot of the time.

 

 

What you have to do is look at the jump addresses inside each bank. They will hold the RORG used for that bank. There's a little more to it as well. For a human it is easy to tell that $9000 is being used in one bank and $D000 in the next. The jumps will tell you that. However, some bankswitched games have different jump addresses in the area where they are doing the bankswitching.

 

 

The ultimate solution is to do a majority vote of jump addresses in each bank, and use that for the RORG of that particular bank. Or, maybe just simply all the referenced absolute addresses. Jump addresses are probably good enough. If there are no jumps in the bank, then just default to the vector address.

 

 

Here is an example. I started doing a River Raid II disassembly after some recent discussion about it. Notice how each bank has jump addresses that use the same high address, i.e. 9,B,D,F. The bankswitching is done at the back of each rom. There you will see similar code (but not exact code) that appears in every bank. Hence why the other jump's are in there, just not used. Majority voting would overcome this.

 

RiverRaidII(re).zip

 

This disassembly is far from complete, but I'll post it now since you are asking. In general, most games seem to start with an lower address in the low bank and work up. This is not a rule, and any bank can be RORG to a rom address of choice, but in general most games follow that convention. A lot of the time you'll see 9,B,D, and F (in that order) for a 16k game.

[SeaGtGruff]

I think I've probably done only one multi-bank disassembly with distella, but I've done several with DIS6502, so I'll jump in.

 

As you know, the first task is to determine the type of bankswitching or ROM format used, so you'll know how to break up the ROM if necessary-- into multiple 4K banks, multiple 2K banks, multiple 1K banks, etc. Both distella and DIS6502 require that the ROM file be split up into its appropriate parts first. In distella you can work with only one bank at a time, but DIS6502 lets you load all of the banks simultaneously as long as they'll all fit into the 64K framework (or really 32K, I suppose, since the code would go at $1000, $3000, $5000, etc.). I don't know if Stella loads the entire ROM at once, or just the bank it's currently running in, but the automatic detection of ROM types is a great boon.

 

I always look at the 6502 vectors to see which address to load a given bank into (DIS6502 displays the contents of the file in a scroll box before you tell it where to load the file, so you can scroll down and see what the vectors are set to). Of course, this helps only if the ROM type uses banks that have their own vectors-- and some ROM types have banks smaller than 4K which go to areas of memory that don't have the vectors in them. But we'll focus on 4K-bank ROMs first.

 

If each bank uses a different page number in its vector addresses, you can just load each bank in the appropriate memory space. But if the banks use the same page number (whether it's $F0, $10, or anything else), the solution is to use different ORG addresses for each bank but followed by the same RORG address:

 

  ORG $1000
  RORG $F000
; bank 1

;etc.

 

Of course, this also works with ROMs that have unique addresses for each bank anyway, so you could use it as the defacto method. And you can actually pick any ORG addresses you want, such as

 

  ORG $0000
  RORG $1000
; bank 1

  ORG $1000
  RORG $3000
; bank 2

; etc.

 

In fact, the ORG addresses should define a contiguous block of memory anyway, so the ROM assembles into a contiguous block of code. In other words, you wouldn't want to use ORG $1000 for bank 1 and then ORG $3000 for bank 2, because then the re-assembled ROM would have a 4K bank ($1000-$1FFF), followed by a 4K *gap* ($2000-$2FFF), followed by another 4K bank ($3000-$3FFF), etc. It's really the RORG addresses that determine what the addresses inside each bank will be, and the ORG addresses can just start at $0000 for the first bank and go up from there depending on the size of each bank-- for example, if the ROM uses multiple 2K banks then the ORG addresses could be $0000, $0F00, $1000, $1F00, etc., but for multiple 4K banks the ORG addresses could be $0000, $1000, $2000, etc.

 

So it would probably be simplest to always use both ORG and RORG addresses, with ORG always starting at $0000 and incrementing as necessary to reflect each bank's physical position within the ROM file. In fact, you could just read the entire ROM file into memory with a single ORG of $0000 to start with, even before determining what type of ROM it is. Then you don't even need to keep track of the ORG addresses as such, since the ORG address for any given byte of code or data within the ROM would be directly indicated by its position in memory, if you follow me. Next, after determining the cartridge format or bankswitching scheme, you can start defining a set of RORG addresses for each bank, based on its vector addresses if it has any. If it's a bank that doesn't have vector addresses, you'll need to look at the code within the bank (assuming it isn't just a bank filled with nothing but data) to see what addresses it uses internally, if any-- or, in some cases, you'll need to look at the code in *other* banks to see what addresses they use when referring to the given bank.

 

I'm thinking you'll end up with three sets of numbers-- the ORG addresses, the RORG addresses, and the bank numbers. For any given bit of code or data, its ORG address would simply be its offset into the chunk of memory where you've loaded the entire ROM, and its RORG address would be dependent on how it's referred to by the entire program, but you'd actually need to combine the bank number with the RORG address to distinguish which bit of code or data you're dealing with, since it's possible that multiple banks may use the same RORG address as each other. Of course, in an assembly program that wouldn't be a problem, since the programmer would be using labels rather than addresses per se. But when you're disassembling a program you have no idea what the labels were (other than the labels for the TIA and RIOT addresses), so you end up with non-meaningful labels like LF123 for the label that corresponds to address $F123. All you need to do is add the bank number to that-- e.g., B1LF123 would be $F123 in bank 1, and B2LF123 would be $F123 in bank 2.

 

Now, I'm not familiar with how Stella handles ROMs-- whether it loads the entire ROM at once into a single chunk of memory, or whether it loads the banks into separate chunks of memory, etc. So the idea I've described above might not be suitable.

[+stephena]

OK, I will need to give this some thought. And if anyone can provide some sample F8 disassemblies, it would be great. Preferably some small test program you've written yourself, so I can examine how a multi-bank assembly file is structured.

 

I think my main issue right now is that last point. I wouldn't even know how to go about creating an F8-compatible assembly file and compiling it into an F8 ROM. As usual with the little beast that is the 2600, what initially looked somewhat easy turns out to be much more complex

[SeaGtGruff]

Regarding banks that have "mixed" addresses, yeah, I've seen that. As long as you're building a set of pseudo-labels that combine the bank number with the "referenced" address, I don't think it would be a problem. Use the "majority vote" idea to get the RORG address, but you can still use the referenced address in the label. For example, bank 1 might end up with a RORG address of $1000 based on the addresses used by the majority of code that refers to bank 1, but an individual label in bank 1 might still be B1LF123 even though bank 1 doesn't have $F000 as its RORG address.

 

As far as ending up with a disassembly that will re-assemble into a byte-exact copy of the original ROM, this situation could be handled by two different labels-- one in the code itself, and the other defined at the top of the code, such as

 

B1LF123 = $F123

  ORG $0000
  RORG $1000

; bank 1

  ; ...

  JMP B1LF123 ; <-- reflecting that it's jumping address $F123 within bank 1

  ; ...

B1L1123 ; <-- label inserted at address $1123 within the code, synonymous with B1LF123 but not actually referenced as B1L1123

  [...]

[SeaGtGruff]

Preferably some small test program you've written yourself, so I can examine how a multi-bank assembly file is structured.

 

There should be a set of examples for the different bankswitching methods here in the 2600 programming forum-- I think they're zipped up into attached files with names like bankswitching.zip, bankswitching_2.zip, bankswitching_3.zip, etc.

[+stephena]

Like I said, definitely more complicated than I originally thought And I can see before I start this, that the current way of disassembling ROMs won't scale beyond the "4K per bank" assumption currently used in the code. So even when I get it working for F8/F6/F4, there will need to be a revamping for the more esoteric schemes. Not to mention the SC variants, where the address space occupied by RAM can't be disassembled in the output file; it needs to be all zeros, or $FF, or whatever is in the original file.

 

WRT determining the bankswitch scheme, this is done at a different level, before the disassembly has begun. In fact, by the time disassembly can happen, the ROM has already been running for some time and done runtime analysis, so the disassembly is more accurate than static Distella.

 

WRT how Stella loads the ROM, it reads the entire image into a buffer in one go. For bankswitching, there's essentially a virtual 'MMU' middle layer that maps reads (and writes, where possible) to the correct address.

[SeaGtGruff]

WRT how Stella loads the ROM, it reads the entire image into a buffer in one go. For bankswitching, there's essentially a virtual 'MMU' middle layer that maps reads (and writes, where possible) to the correct address.

That should make the disassembly process easier, I think. I'll try to work up a partial example using an actual ROM to illustrate how I'd probably go about it if I were doing it with a disassembly program of my own (as opposed to using distella or DIS6502).

[+stephena]

I should note that the current disassembly is built around the concept of 4K per bank, since that's the actual address space that the console can 'see'. So when you see the disassembly in the debugger, you're seeing 4K worth since, to the 2600, that's all there is. Now in the simple case of F8/F6/F4 ROMs, this is fine, since each of their banks occupies the entire 4K address space. But when you get to the more esoteric schemes which can have a 'bank' less than 4K, it gets more complicated. For example, when you view the disassembly for E0 scheme, you're actually viewing the output from the four 1K slices that are active at that point in time. From the POV of the debugger, this is absolutely the right thing to do; you want to see what's currently active. But from the POV of generating an assembly file, it's obviously not correct. You can't just dump the data as-is, since the banks may not even be in order.

 

I think what needs to happen is that the disassembler needs to look at the entire 4K address space when generating data for the debugger, and look at the actual ROM contents when generating data for the assembly file. Running the emulator for a while will generate the 'hints' as to what each section of ROM space actually is (CODE, GFX, DATA, etc); the disassembler will just use these in a different context depending on the desired output.

 

One scenario, though. Say we have scheme E0, where there are 8 1K slices, each of which can be put in the first three 1K slots (the last one always points to the last 1K of ROM). Say slice 0 is first in slot 0, and later in slot 2. Will the code represent the same thing when moved around like that? Or more to the point, will the disassembly match (labels, addresses, and all)?? Because if not, I don't see how to solve that issue at all.

 

EDIT: When I refer to hints here, I'm essentially talking about Distella config directives (CODE/PGFX/GFX/DATA/ROW). Because in the final analysis, these hints are all we really care about. Otherwise, we could just dump the ROM contents directly as bytes, which would still be a valid (but completely useless) disassembly. And these hints are stored for the entire size of the ROM

[Omegamatrix]

OK, I will need to give this some thought. And if anyone can provide some sample F8 disassemblies, it would be great. Preferably some small test program you've written yourself, so I can examine how a multi-bank assembly file is structured.

 

I think my main issue right now is that last point. I wouldn't even know how to go about creating an F8-compatible assembly file and compiling it into an F8 ROM. As usual with the little beast that is the 2600, what initially looked somewhat easy turns out to be much more complex

 

Here are some of the multi-bank disassemblies I've done.

 

Disassemblies(multibank).zip

 

WRT the complexity, all you need from Stella is what addresses were resolved as what (PFGX, CODE, DATA, etc...)

 

For 8K/16K/32K I would:

 

1) split everything into 4k files

 

Then for each 4k file:

2) do a new type of pass, where you check all the jumps to determine the RORG. This is the majority voting.

3) set aside the unfound jumps, such as a jump $B456 when the bank is $9000 or $D000

 

After you've done that for each 4k file you should have your RORG's:

4) If any of the RORG's are the same, i.e. all the banks RORG to $F000, then you need to use unique labels for each bank. You don't want any conflicting labels. Even if it assembled it would be horrible as you couldn't tell what bank you're in by looking at it, and searching for a label would also take you to all the other duplicate label in other banks. That is not good. Imagine later trying to replace "LF3AE" with ".loopDrawScore" when "LF3AE" appears in two other banks because the RORG's happened to be the same. You can quickly see that would not be user friendly.

 

So instead of "L", use a different prefix letter for each of the banks labels. I would start above "F" because it won't be confusing with the hexadecimal address. For a 4 bank rom I might go J,K,L, and M in that order. J,K,L, and M are really distinguishable letters in any font. Using these different letters still keeps the label nice and short. If you look at the Star Trek disassembly I posted, you'll see where I encountered this type of situation. I simply made the labels in the first bank begin with "K", and the labels in the second bank begin with "L". They are in alphabetical order so I get a sense of what bank I'm in (low to high). I can also search for labels in that rom and get the correct one without going to a different bank. That part is important.

 

Okay at this point you still have unresolved absolute addresses. Now that you know the true RORG for each bank, you can compare the unresolved labels against the RORGS. If they belong in that bank go back into that 4K rom and resolve it with these labels. If you can't match them with the RORG's then just leave them as absolute addresses.

[Thomas Jentzsch]

Here are some more disassemblies. Most are just 4k, but some are larger.

[Thomas Jentzsch]

And here is some helpful discussion

[+stephena]

I probably should have asked this first: Just how much interest is there in having Stella be able to disassemble the more esoteric ROMs? I can easily do 4K or less, and with some difficulty do F8/F6/F4 (wth Superchip), and possibly some of the other 4K per bank schemes (UA, EF, etc). But what about E0/E7/DPC/DPC+, etc? These latter ones would really increase the complexity of the code, and I'm not sure the effort for me to do it is justified. Maybe I should create a poll or something??

[RevEng]

A poll would be good. For me, 4K/F8/F6/F4 would cover my needs. I don't see a legit need for DPC+.

[SeaGtGruff]

I'd love to see Stella be able to output a disassembly of any cartridge type it can run.

 

HOWEVER, there's no reason you'd need to implement something like that all at once. It would make good sense to start with just the non-bankswitched cartridge types first-- 2K and 4K. Once you've got the disassembly for those working to your satisfaction, the next logical step would be adding the bankswitched cartridge types that swap out the entire 4K cartridge space. And after that's working well, you could begin thinking about slowly adding the more exotic cartridge types, with the more common ones taking precedence over the less common ones.

 

Besides, the ones that swap out the entire 4K cartridge space are probably far and away the more commonly-used ones. Why fret now about how to handle a seldom-used exotic bankswitching scheme if there's only one or two ROMs that use it? And once you've got a better idea of how to handle the common 4K-bank schemes, the more exotic schemes might start to look less intimidating.

[Thomas Jentzsch]

I probably should have asked this first: Just how much interest is there in having Stella be able to disassemble the more esoteric ROMs? I can easily do 4K or less, and with some difficulty do F8/F6/F4 (wth Superchip), and possibly some of the other 4K per bank schemes (UA, EF, etc). But what about E0/E7/DPC/DPC+, etc? These latter ones would really increase the complexity of the code, and I'm not sure the effort for me to do it is justified. Maybe I should create a poll or something??

Actually I thought the debugger logic would support all those schemes and therefore I hoped(!) it would be easier to create a disassembly for the more complex schemes..

 

If that's not the case, then the debugger should come first. E0 is pretty common (Parker) and E7 offers some capabilities other original bank switches schemes do not have. E.g. I used E7 for my Elite demos. So having a good debugger here would make sense. Disassembling should be 2nd thought and maybe easier afterwards.

[+stephena]

I'd love to see Stella be able to output a disassembly of any cartridge type it can run.

 

True, that would be the ideal solution.

 

Why fret now about how to handle a seldom-used exotic bankswitching scheme if there's only one or two ROMs that use it? And once you've got a better idea of how to handle the common 4K-bank schemes, the more exotic schemes might start to look less intimidating.

 

Because I'm trying to figure out a framework where all these things can be accommodated. I guess I'm stuck at the C++ design class hierarchy step, trying to find commonality between all the differing schemes. For example, if I extend Distella to know about Superchip RAM, it will have to apply only to those ROMs that actually use that scheme, and not otherwise. But what about the other schemes, where they can have different RAM areas (of differing sizes) at different places?

 

I can easily see there being a disassembly method and specific Distella code for each bankswitch method, so a lot code duplication and maintenance. Maybe I'm making things too difficult, and there just isn't a common ground between many of these schemes??

 

EDIT: Consider that there are bankswitch-specific classes; one for 4K, F8, F6, etc. All the specific functionality is thus separated out into specific classes. This seems to be what's needed for generating assembly files too. Problem is, I don't want to have to create a Distella class specific to every scheme! And I'm not sure Distella can be extended to be general enough for all schemes. It too, after all, is written based on the assumption of 4K per bank.

[+stephena]

Actually I thought the debugger logic would support all those schemes and therefore I hoped(!) it would be easier to create a disassembly for the more complex schemes..

 

If that's not the case, then the debugger should come first. E0 is pretty common (Parker) and E7 offers some capabilities other original bank switches schemes do not have. E.g. I used E7 for my Elite demos. So having a good debugger here would make sense. Disassembling should be 2nd thought and maybe easier afterwards.

 

There's still some issues in the debugger, though, that I never really did work out, and they're coming back to bite me. Take the E7 scheme. Technically, it really has only one 4K bank, with 2K slices swapping in and out. From the POV of the debugger, all 4K is seen at once, since it's showing the virtual 4K address space. However, I've assigned a bankcount of 8 to that scheme, and you're able to change banks in the debugger. In reality, this doesn't make sense. When you switch from one bank to the next, what is really changing? In this case, it's swapping in each consecutive 2K bank for the first 7, and then the 2K RAM for the 8th.

 

I guess I'm back to the same issue. The concept of 4K per bank is everywhere in the code, even the debugger UI. I still need to work out how to get around this for ROMs that don't follow this scheme.

[Thomas Jentzsch]

I guess I'm back to the same issue. The concept of 4K per bank is everywhere in the code, even the debugger UI. I still need to work out how to get around this for ROMs that don't follow this scheme.

Yes, even though I don't know the implementation details, the 4K limitations show at various places. And with more and more sophisticated schemes being developed and supported by hardware, IMO it is really time to address the problem.

 

I hope that's in the area you like to code.

[+stephena]

Yes, even though I don't know the implementation details, the 4K limitations show at various places. And with more and more sophisticated schemes being developed and supported by hardware, IMO it is really time to address the problem.

 

I hope that's in the area you like to code.

 

Well, if this is the part to work on next, then the disassembly will have to wait About the only possible solution I can see is have another window that can pop up, which is scheme-specific and shows disassembly from the POV of the cart itself, and not from the POV of the 4K virtual space. The current view would stay there of course, but you wouldn't be able to switch between banks in that view (which TBH, never really worked right in many cases anyway). This new view would show the disassembly in essentially the same format as would be needed to save to an assembly file.

 

Do you guys think that such a view would be helpful? Essentially, the current view would be for what the console sees at that point in time, and the other view would be for an overall view of the system, regardless of what is currently being executed. Another benefit of this approach is that the creation of the UI and of the assembly file go hand in hand; once one is complete, the other follows from it. And until a UI is available, generation of assembly won't be available (allowing the work to proceed in steps).

 

This is a lot of work, but could eventually lead to a much more useful debugger. So my question is, would that suffice for all use cases? I think it would, but I don't actually program for the 2600, so I can't say for sure ...

[Thomas Jentzsch]

So the new view would contain the complete e.g. 16k while the old view would show the current 4K, correct? Sounds good. I would probably use the 4K view 95%.

 

It should however be possible to switch banks (like you can switch the PC too). But probably it would be better not to have a single bank counter in the GUI, but something that better represents the current bank switching scheme. E.g. an extra tab for showing and selecting the banks. This should show the physical address and the virtual address of the bank, plus the bank size and type (RAM/ROM).

 

Here is how I visualize E7 in my Elite code:

;+-----------------------------------+-----------+-----------------------+
;|ROM:.ffe0-ffe6,.RAM:.ffe7..........|ffe8-ffeb..|.......................|
;+-----------------------------------+-----+-----+-----------------------+
;|7.ROM.banks........................|write|read.|fixed.ROM..............|
;|f000...........................f7ff|RAM..|RAM..|fa00...............ffff|
;+-----------------+-----------------+.....|.....+-----------------------+
;|write.RAM........|read.RAM.........|.....|.....|.......................|
;|f000.........f3ff|f400.........f7ff|f8xx.|f9xx.|.......................|
;+-----------------+-----------------+-----+-----+-----------------------+

Also it would help if the 4K view would (at least for the current instruction and memory reference) show the physical address and/or bank information.

 

I think taking something complex like e.g. E7 as an example (it has multiple banks, a fixed bank, RAM and ROM banks and different sizes for the RAM banks) and finding a good solution for that might be a good idea. Better than to start with something simple and then realizing that the UI is not sufficient.

Edited March 18, 2013 by Thomas Jentzsch

[+stephena]

Well in that case, I may as well not have a separate ROM view at all, and simply add scheme-specific bankswitch functionality to a tab. So the first tab will be the current view, without the ability to change banks (because changing banks is scheme-specific). And the second tab will contain a description of the scheme layout, with ability to set each 'bank' of ROM or RAM at each location, according to how the scheme actually works. And if you want to see the changes you just made, simply switch back to the other tab. And if you still want to see the entire layout of the ROM, yet another tab could be added for that.

 

UI-wise, this is definitely easier than what I suggested. In fact it's very similar to how there are UI items for the specific controller in the IO tab. And it completely solves what it means to switch a bank, even when the banks aren't 4K.

 

So, if I commit to this, the disassembly will have to wait. In fact, now that I think about it, it sort of has to be done in this order ...

[Thomas Jentzsch]

Sounds like a good plan to me...

[SeaGtGruff]

I think it's a good idea to delay any implementation of a disassembly output until (1) any other issues are dealt with and (2) you've worked out a good plan for how you want to implement it. In order of relative priorities, I think getting the TIA emulation fixed and (if possible) adding options to emulate the differences between the different versions of the TIA and its clones should be the first priority. This also includes any possibility of adding options to compute the color palettes internally and let the user tweak them by adjusting brightness, contrast, and tint. The debugger has second priority. And any plans to implement a disassembly output should have the lowest priority. Stella is an emulator, first and foremost, so emulation should always be its top priority. The debugging features are extremely useful for developers, but they make up only a fraction of Stella's users. And disassembly would be really nice, but I don't see how it would be of any use except to someone who wants to hack a game, or a developer who wants to study someone else's game to see how some nifty trick was done. And since there are already existing programs and tools for hacking and disassembling games, there's no urgent need for adding this functionality to Stella.

[+stephena]

I agree the TIA is top priority for the project from the POV of being an emulator. But there are several other issues you might not be aware of. First, I'm kind of burnt out on that area of the code, and will (hopefully) get help from others in completing it. This is documented in another thread, and ATM the people involved are busy with other things. So I'm leaving that area alone for now. And second, I don't see Stella as just an emulator, but a developers emulator. This has been true for some time, since my personal interests lie in debuggers, operating systems, etc.

 

As for the TIA tweaks for colour, tint, contrast, etc, that is also coming, and will be part of the TV effects. But again, I've taken a break from that part of the code for now, until the TIA reworking is more complete.

 

So as a diversion, I decided to work on disassembly stuff. But seeing that the debugger has some outstanding issues, I need to fix that first.

 

So long story short I guess: While the TIA is top priority for the emulator, it's not top priority for me right now. Better to take a break from that area of the code than to walk away from it all completely.

 

EDIT: Also, even though disassembly of all types of ROMs is meaningful only to a small fraction of emulator users, you have to admit that it would be an extremely cool feature, and one that no other emulator has done before, AFAIK. And I think working on something new like this, that hasn't been done before, will re-energize me, allowing me to tackle the TIA stuff when the time comes.