104 TO DO List

Andy McFadden edited this page 2023-12-22 13:02:38 -08:00

Unescape Escape

Table of Contents

• TO DO List
• Known Issues
• Main Window UI/UX
• Code List
• References Window
• Symbols Window
• Info Window
• Actions and Editors
• Visualizations
• Hex Dump
• Other
• Analysis
• General
• Code Analysis
• Data Analysis
• Source Code Generation
• Cross-Assembler Source Code
• Text/HTML Export
• Project Management
• External Files (Extension Scripts and Symbol Files)
• Miscellaneous

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

TO DO List

Contents:

• Known Issues
• Main Window UI/UX
• Analysis
• Source Code Generation
• Project Management
• External Files (Extension Scripts and Symbol Files)
• Miscellaneous

Known Issues

• Working with very large selections (> 5K lines) can be very slow. This is due in part to the WPF ListView control. SourceGen has work-arounds for common operations like select-all, but saving and restoring very large selections can take several seconds. For this reason, selections over 5,000 lines are not restored.
• Sometimes double-clicking on an opcode seems to move you to the wrong place. What's actually happening is the List View control is registering a phantom third click, so it scrolls to the correct place and then selects the line under the mouse cursor. The intended destination will usually be at the top or bottom of the window.
• Sometimes banging on undo/redo quickly will leave you scrolled to the bottom of the code list. Possibly due to a command-handling race in WPF.
• Sometimes the program stalls for a bit after updating the application settings. This happens because it's querying the installed assemblers, and it appears that Win10's built-in anti-malware system needs a second or so to verify that the assemblers haven't gone bad. (It didn't used to do this... got much slower in 2019.) This is especially pronounced for cc65, which has multiple binaries. The stall only seems to happen the first time the programs are run on a given day.

Main Window UI/UX

• Add configurable hot-keys. Provide the ability to define a key sequence for any of the Edit or Actions menu items, and perhaps for additional things not defined there (like "instantly format the selection as a string using whatever format mode seems best"). Especially useful for non-US keyboards, where the existing keyboard shortcuts may not be convenient. (See https://github.com/fadden/6502bench/issues/55, #54, https://github.com/fadden/6502bench/issues/135, etc.)

Code List

• Allow cut / copy / paste of long comments, notes, and pieces of local variable tables. Maybe have a way to "paste" an operand format to make it easier to format multiple items. This would make user interaction more fluid.
• Add a vertical bar with a graphical representation of the contents. Use different colors for code/data, notes, global labels, long comments. At the very least, an address region representation would be helpful.
• Code list clutter reduction.
  • Add show/hide region mechanic that allows you to collapse regions of the file to a single line, similar to Visual Studio regions.
  • Or, have a mode where all unlabeled data lines are collapsed. Can be toggled with a keyboard shortcut.
  • Or, have a mode where only the first line of long string and dense-hex items are shown. Can be toggled with a keyboard shortcut.
• Add optional syntax highlighting. See https://github.com/fadden/6502bench/issues/134 .
• Labeling improvements.
  • Auto-detection of loop labels. Rename auto labels from "L1234" to "]LOOP" if the only references to it are short backward conditional branches. Should be fast enough to do in the on-screen list.
  • Support for "anonymous" labels, like "3b" or "--". Assemblers vary widely in what they support, so this may be hard to define.
  • Define a way to set an "area" label that could overlap with other labels, similar to the way that project/platform symbols with length values work. This would allow a general label ("saved_game_state") and specific labels ("current_level", "current_hp"). It would also allow large data items to be formatted as something other than a monolithic block. https://github.com/fadden/6502bench/issues/138
• Improve readability for longer labels by placing them on a separate line on-screen. (Otherwise it's necessary to make the label column very wide.)
• Provide a way to identify labels in comments, so that when a label is renamed the comment is updated automatically. (Otherwise it's fragile to refer to variables by name in comments.) Markers are only visible when editing the comment. Something like "paramref" in XML docs.
• For large 65816 programs, add tabs to the code list, and use one tab per 64K bank. This keeps the number of lines in the code list view to a manageable level, and reduces the amount of work required after every edit because we don't have to update stuff in tabs that aren't visible (assuming we have incremental code analysis).
• Code and data that runs off the end of a bank should have their address shown in red, especially on non-65816. (It currently flows into the next bank.)
• Show alternate values next to some labels in on-screen display. Toggle to enable in settings.
  • Show branch offsets the way the IIgs monitor does, e.g. BRA 200F {+0C}.
  • Show value of address labels, e.g. LDA ZP {$80} and STA DATA {$4000}. (cf. https://github.com/fadden/6502bench/issues/136)
  • Show characters next to single-byte default-format operands if they're in the primary character encoding range (e.g. LDA #$41 'A').
• Add signed decimal as a format, so we can LDY #-1 instead of LDY #$ff.
• Allow greater flexibility in long comments. See https://github.com/fadden/6502bench/issues/111 for ideas on making it look like you can have multiple comments per offset, insert blank lines between statements, etc.
  • Make the box character for long comments configurable. Provide a way to generate a row of asterisks (or whatever) in a non-boxed comment.
• In-place editing of data items in the GUI, so you can edit a label without having a dialog pop up. This would be hard to make work for anything but labels and comments.
• Provide split-screen viewing, where different parts of the same file can be viewed in adjacent windows.
• Add a command that changes all default-format AND/OR/EOR operands to binary.
• Need a way to display control chars in operand that shows the letter, e.g. "#Ctrl+R" or "#^R" vs. "#$92"
• Figure out why renaming a label is blowing out DisplayList virtualization (WPF-specific).
• Replace WPF ListView with custom control. Some advantages:
  • Can retrieve and restore selection quickly (LV SelectedItems is wrong).
  • Avoid some INotifyCollectionChanged / INotifyPropertyChanged traffic.
  • Avoid CodeListItemStyle shenanigans.
  • No weird item generator event focus stuff.
  • "Find top line" doesn't need flaky ScrollIntoView().
• Provide a way to identify modified vs. unmodified operands at a glance, e.g. by showing them in different colors.
• Add RTS-style numbered bookmarks (e.g. Shift+5 to set position, Ctrl+5 to jump to position) to move around the project quickly. (See https://github.com/fadden/6502bench/issues/73)
• Make cycle counts a separate column (to left of comment).

References Window

• The References window entries should list the nearest prior label to provide context.
• For global direct-page address symbols, add a line referring to each local variable table that references (or overlaps?) the same address. (The goal is to be able to find everything that references a DP address; this may be insufficient since it only works if there's a global def with at least one reference.)
• We should generate references to address region pre-labels.

Symbols Window

• Symbols window could have additional options, e.g. display the value in hex/dec, filter on exported symbols, etc. Maybe a "is actually used" filter to screen out un-referenced platform symbols.
• Grey out symbols that aren't referenced.

Info Window

• (nothing?)

Actions and Editors

• Improve the data operand editor:
  • Need an easier way to set single-operand stuff.
  • Need an easier way to set target labels (similar to the way the instruction operand editor works), perhaps as an "add label" button that appears when a symbol is typed on a 16/24-bit value.
  • Consider switching to single-byte automatically when a symbol is typed. (This is the opposite of the previous item; order of operations may matter.)
  • Split "Address" into "Data Address and "Code Address". The latter applies a code entry point hint to the target address so you don't have to go through and add them by hand. (cf. #126)
  • Allow arguments other than hex for the data argument in "fill" operations, e.g. ".fill 80,'*'" for a line of asterisks. Would also be good to allow hex for the count argument. See https://github.com/fadden/6502bench/issues/116
  • Be a bit smarter about selecting appropriate defaults when formatting strings. Add a shortcut to make selection and formatting of strings easier. (See https://github.com/fadden/6502bench/issues/70)
  • Generalize the max-byte-per-line feature, so it can apply to things other than densely-packed-bytes (e.g. strings). See https://github.com/fadden/6502bench/issues/140
• Streamline instruction operand editor: don't open a separate dialog to edit a line label. Maybe just show the operand target line and invite them to update the label in place?
• Improve Format Address Table (cf. https://github.com/fadden/6502bench/issues/130):
  • Look for matches with platform/project symbols for external addresses. Show these in the preview, and generate symbolic references to them when the table is formatted.
  • Add another checkbox (yikes!) that causes new project symbols ("ETxxxx") to be generated for external addresses that don't have an associated symbol.
  • Show a warning (probably in the label preview window) when the labels we're about to generate would end up hidden inside an existing multi-byte data area. Maybe don't generate those labels?
    • Need to explore how this interacts with the "tag as code start point" feature.
  • To make this work well, we probably also need: Do a refactoring rename on project symbol name changes. Requires breaking the change into small pieces. One tricky item is making it work correctly when there's a user label with the same name.
  • Add ability to specify a fixed offset, for the benefit of address tables that are stored as offset tables. (https://github.com/fadden/6502bench/issues/143)
  • NOTE: this probably ought to be a stored record rather than a one-shot formatting tool. If we re-applied it during analysis, we could tag code points dynamically, and display single-byte low/high parts correctly instead of treating each part in isolation. We wouldn't need 'T' labels. Further, we could offer nicer output modes, such as putting multiple items on a single line.
• Improve status flag editor (https://github.com/fadden/6502bench/issues/132):
  • Add buttons to quickly change conditional branches to branch-always, branch-never, or branch-sometimes.
• Add a feature to quickly format "LDA #<lo / LDA #<hi" situations. See https://github.com/fadden/6502bench/issues/120 (related: #21)
• Improve the "find" feature. Case-sensitivity, regex, incremental searching, "you have wrapped" dialog disable. Normalize string delimiters so searching for "'A'" finds 'A', "A", ‘A’, etc. Should be a floating window.
  • Add a Visual Studio-style "find all" that displays the results in a double-clickable table.
• Enable "define project symbol" for constants.
• Intellisense-style auto-complete of symbol names.
• Proper handling of MVN/MVP double-operand editing. (We can tuck a format descriptor for the second operand inside, attaching it to the offset of the first operand byte.)
• Add keyboard shortcut to rotate through operand states. Would be a quick way to set an operand to decimal or ASCII.
• Make the Apply button in Project Properties immediate, rather than waiting until the dialog closes. This would create a new undo item every time Apply was hit, which might be useful.
• Have a "no really, it's a string" mode that overrides the current string-detection heuristics and forces something to be encoded as a string, even if it's mostly control characters.
• Allow operands to be formatted as partial numeric addresses. So if you see "LDA #$00" "LDX #$20", you can format both as parts of $2000, and let the numeric operand resolver convert it to whatever symbol happens to be at $2000. There are various scenarios where this is more convenient than entering a label.
• When a local variable table item is double-clicked on, open the editor with that item selected and focused.
• Support expressions.
  • Start with simple expressions, such as ORing of multiple constants or defining an offset as the difference between two symbols.
  • Add "define offset table" that takes a base address and creates 8-bit or 16-bit offsets to symbols.
  • Allow arbitrary expressions in places that currently accept symbols (instruction and data operands). This is straightforward to manage within SourceGen, but can be difficult to generate for all cross-assemblers if the complexity gets too high.
  • (See https://github.com/fadden/6502bench/issues/123 .)
• Support multi-line editing for instructions. Like what we do for data, but for code. Not sure how often that will be useful, or how it will work for an arbitrary selection. (A keyboard shortcut that rotates through the various numeric forms might be sufficient.)
• We can do better on non-unique local symbol matching in EditOperand dialogs.
  • LDA #<value : no OperandValue, but we can pick the symbol that minimizes the adjustment.
  • .DDB value : for single-range stuff, extract the value as an address and find the best match.
  • Could pop up a list of possible matches and let the user choose. Set default to best option.
• Add internal "see also" links in comments and notes.
• Create tooltips for data operand editor items, especially when they're disabled ("you don't have an even number of items selected").
• "Navigate to last change" jumps to offset 0 for things like project property changes that don't have an offset. Should probably jump to the previous change instead.
• Support a "struct" notion, possibly defined in external files, for things like file headers, bitmaps, and parameter blocks. (See https://github.com/fadden/6502bench/issues/121 .)
• Add a notion of "fixed length" vs. "fixed endpoint" to the various bulk data operands. The idea is that the data needs to end at a specific point, like an "align" directive but more arbitrary. The distinction becomes important if the generated code is modified and re-assembled. (See https://github.com/fadden/6502bench/issues/122 .)

Visualizations

• Animated bitmap preview should scale things correctly, based on the largest item in the set (the way it's done for animated GIF).
• Improve debugging of wireframe visualizers. Provide a way to show specific edges in a wireframe image in color. Add a feature that displays vertex numbers next to the vertices.
• Add a ComboBox enum variable type. Useful for things like C64 colors.
• Consider adding a live-verify function that tests all parameters and returns useful diagnostics.

Hex Dump

• Use the same font as the main code list.
• Support PETSCII glyphs. Requires a custom font (https://style64.org/petscii/) and conversion routines. See https://github.com/fadden/6502bench/issues/136 .
• Add Mac OS Roman glyphs.

Other

• Improve info/error dialogs; some are hard to read.
• Do a color check, e.g. the bottom window in the long comment editor is difficult to read in the Win7 high-contrast theme.
• Add window with undo/redo history. Click on an item to jump to the offset of the first part of the change.
• Better integration of Help, e.g. help buttons on editor dialogs. (I started out doing this, but stopped because things get weird when you try to shell-open a web page with an anchor string under Windows.)
• IntelliSense-style completion for symbols and constants. Might be best with more detailed annotation of constants. (See https://github.com/fadden/6502bench/issues/28)
• Generate call graphs on request.
• Add memory map graphic that shows which sections of memory are occupied, using different colors for code/data/junk.

Analysis

General

• Reduce the scope of symbols for larger programs. In a small program it's okay if everything is essentially global, but in a larger program that gets awkward, and even having non-unique locals doesn't help when you've got stuff cris-crossing banks. We could break it down by bank, treating inter-bank symbols as global and intra-bank symbols as local. Requires generating multiple source files, one per bank, but we'd probably want to do that anyway.
• Identify common patterns, like "LDA #<label / STA ZP / LDA #>label / STA ZP+1", and apply appropriate formats automatically. (But see also https://github.com/fadden/6502bench/issues/21)
• Define a notion of "external header data" for files with headers that are consumed by the operating system. Examples include C64 .PRG load address and Apple /// headers.

Code Analysis

• Improve multi-bank code handling, where code is present at the same address in multiple banks. We need a way to tell the code analyzer to not follow a JMP/JSR, so that we don't add branch targets in the middle of the wrong code. https://github.com/fadden/6502bench/issues/147
• Add an "isolated region" checkbox to the address region editor. Factor it into the address-to-offset calculation to allow for code that gets uploaded to a place with a separate address space. https://github.com/fadden/6502bench/issues/139
• Finish W65C02 support (currently ignores the ZP arg for BBR/BBS).
• Add support for the HuC6280 CPU, used in the TurboGrafx-16. (See https://github.com/fadden/6502bench/issues/106 )
• Try to improve "smart PLP".
• Incremental code analysis. Changes that potentially affect the code flow require the code analysis pass to be repeated. For a large 65816 project (think multi-megabyte SNES ROM) this could take hundreds of milliseconds.
  • We can try to break the code into chunks (probably into fixed-size blocks of N bytes, since we can't do basic blocks until after we've done the analysis). Create a dependency graph describing which chunks affect which other chunks, and how (branch in, self-modifying code, etc). If the outputs of a chunk change (added / changed / removed), we update the dependencies on the target chunks and flag them for re-examination. This is similar to how the processor status flag tracking works, but at a coarse granularity, and we would retain the analysis data between calls.
  • Some code may be so tangled up that every change causes a substantial re-analysis, and some operations (like adding/removing code entry point hints) will be large. Hopefully the very large projects will have a lot of structure to them, and seismic code hint changes will be infrequent.
  • This would likely make a full analysis pass slower because of the additional work required. Ideally that would usually be spent only when the project is first loaded.
• Trace code across indirect jumps, e.g. "JMP (addr)", if we can determine that the operand address is within the file and the location referenced is also within the file. Handle the incorrect behavior at page boundaries on the 6502.
• Add a jump-table recognizer that essentially code-hints every JMP instruction in the selection. Run it automatically on the start of the file when the project is first loaded. (See https://github.com/fadden/6502bench/issues/22)
• During code analysis, keep track of in-project addresses that are written to. If the location turns out to be an immediate instruction operand, assume that it's part of self-modifying code, and disable the related clever heuristics (e.g. ORA #$80 sets the N flag and clears the Z flag).
• Allow different pseudo-ops for constants and addresses. Some assemblers support this, e.g. cc65 has "=" for constants and ":=" for labels. If nothing else it makes the equate list easier to comprehend.
• Improve handling of dummy branches, e.g. start of Apple II serial card firmware. The branch is never taken; it just conceals an embedded instruction. This causes an auto-label to be generated. In generated source code the auto-label is output but never referenced.
• Speculative code hinting. A human can look at a9 40 85 02 20 ed fd and recognize 6502 code. The computer should be able to manage it with a reasonable degree of success. The result would need to be displayed in a way that is useful rather than distracting.
• Propagate status flags back from RTS during code analysis. Rarely useful, and can be hard to identify call sites in certain situations.
• Recognize and disassemble SWEET-16 code.
• Support disassembly of relocatable object files (Merlin REL, CC65 .o).
• Auto-detection of compiled code. For certain popular compilers we could identify prolog/epilog, variables, etc.
• Add a peephole optimizer to suggest improvements. (This is not really the way a disassembler should be used, but we do have enough data to identify some common situations.)

Data Analysis

• Expand DataAnalysis.AnalyzeUncategorized.

  • Automatically scan for other string types, such as strings prefixed by length or null-terminated. May require pre-scanning the data file to get decent performance.

• Map absolute references to direct page locations onto local variables (e.g. LDA $0077,Y could map to lvar $77).

• Provide a way to define generated data. This is mostly useful when the target assembler supports the concept, e.g. Merlin's LUP directive. This might be too assembler-specific, although it's okay if the code list shows an expression and the assembled output has a dense-hex dump.

• Fix the TODO(perf) in the data target code.

Source Code Generation

• Add ability to write sections of the file to an external binary file, which is then referenced with a binary-import pseudo-op. Useful for large binary chunks like music data that can also be viewed with an appropriate tool. (See https://github.com/fadden/6502bench/issues/144)
• Provide a way to send extra arguments to the assembler. Might need to be per-project rather than general asm config. (Can be done with .BAT; see https://github.com/fadden/6502bench/issues/81)

Cross-Assembler Source Code

• Aggregation of adjacent elements. ".dd1 $00 / .dd1 $01" can be output as ".dd1 $00,$01". This is really just for assembler output; on screen you want them to be independently addressable.

• Improve output of equates at the top of the file.

  • Group .EQ items by tag, so similar constants get grouped together. Maybe insert a full-line comment above a group? Can also group items by which platform file they came out of.
  • Provide a way to freely order equates and intersperse long comments. (Examples where this could be handy: Nintendo SMB, Apple II SSC.)

• Macro generation from plugins. Useful for Apple /// SOS MLI calls, ProDOS 8 MLI calls, GS/OS calls, IIgs toolbox calls, etc. The goal is to match the way code was typically written by humans. This is a little weird because, instead of reformatting an operand, we're actually replacing LDX/JSL with an arbitrary string. Definitely something that would happen as part of asm generation, not in the on-screen code list.

• Multi-source output. Large projects should be generated into multiple source files. Breaking them apart at top-level address region boundaries should yield good results. See https://github.com/fadden/6502bench/issues/115

• Expand per-assembler output options.

  • Make operand wrap length configurable.
  • Consider making options like upper/lower case and label localization assembler-specific.

• Support additional assemblers.

  • Identify other popular cross-assemblers (maybe http://www.floodgap.com/retrotech/xa/ or https://github.com/docbacardi/dreamass ? https://github.com/dasm-assembler/dasm seems popular on Atari but doesn't support 65816.)
  • Consider targeting a retro assembler.

• Fold long end-of-line comments across multiple lines. Either bump to the next line with "; ", or insert blank lines if the following line already has an EOL comment.

• Add a "no auto labels" mode. Instead of generating a label like "L1234", just reference an offset from the previous user-specified label. (Seems like a step in the wrong direction, but might be useful.)

• Output different pseudo-ops for constants and addresses (2-byte/3-byte). (This is maintained internally, but all two-byte values currently just turn into .dd2.) This is desired by some assemblers, e.g. 64tass has ".word" vs. ".addr".

• Add ASCII-art generation of bitmap data.

• Optionally output zero-page globals as a DUM/DEND sort of segment. Assembler-dependent.

Text/HTML Export

• Add symbol dumps.

  • Output unused project symbols. (Alternatively, provide an editor feature that strips them.)
  • Generate symbol lists in formats expected for emulator debuggers. (See https://github.com/fadden/6502bench/issues/77)
  • Generate .SYM65 with all global labels (or exports only).

• Exported text could include the full dump of the "bytes" field, not just the first few. Useful for multi-byte data items like strings and dense hex. Less important for .fill.

• Add an alternate HTML anchor that sits on the first line associated with an offset, rather than on the label itself. That way URLs can jump to the comment above the code rather than the code.

• Show modified status flags in color in HTML. (Low priority since we don't normally show the status flag column in HTML.)

• Add URL linkification for comments.

• Change AnimatedGifEncoder to use a global color table when possible. This is a little harder for wireframes because of anti-aliased line rendering. Generally just need to scan the colors out of every bitmap, and if there are 256 or fewer, create a global color table and rewrite the colors in every image. Should make the output a fair bit smaller.

• Generate other kinds of reports.

  • Generate a list of external addresses that are referenced by the program but don't have associated symbols.

Project Management

• Periodic autosave to a temp file, in case something crashes.

• Add git integration. Provide a way to create commits with project file updates. Consider refreshing any generated assembly files present and including those in the commit.

• Add "file format recognizers". Simplest form looks at filename and bits of files, and sets default values for things like address and entry-point status flags. Could pull in optional symbol files and extension scripts.

  • Could implement as one or several extension scripts. Possibly platform-specific.
  • Concrete example: https://github.com/fadden/6502bench/issues/119

• Use a non-JSON format for project files. A custom format would be more compact, easier to hand-edit, and yield better diffs.

• Improve "recent files"

  • Make the count configurable. Have some options for what appears in the main window when no project is opened.
  • Add a "clear" button.
  • Allow projects to be "pinned" in place.
  • Add hotkeys to allow a quick switch between projects. Maybe Ctrl+1, Ctrl+2, etc.

• Check whether projects exist before displaying them on the initial two "recent project" buttons.

• Allow "code patching": replacement of small sections of code. These could be toggled on or off at generation time. This would allow minor fixes to be made at fixed addresses. (Could allow patches to extend the size of the original.)

• Code descrambler

  • Allow an extension script to define how a region of code should be descrambled. These kick in at load time. They should work both directions, so we can apply the reverse direction to the generated output before comparing it to the original. (Alternatively, just compare the output to the descrambled original.) Might be better to just do this with pre-/post-SourceGen code.

• Support extracting data from archives and disk images. This could be useful for extracting files directly from native disk formats, but also for things like arcade cabinet ROM image archives, where code intended to be a single binary in memory is split into multiple files (one per ROM chip). Would need to allow selection of files within an archive/image and perhaps a "load map" for multi-file items.

• Improve support for sharing symbols between projects that span multiple binaries.

  • Current approach requires a manual import, but can pull the symbols directly out of another .dis65 project file.
  • Could do an auto-export when a project is saved, generating a .sym65 symbol file with exported symbols.
  • Could link projects together, so they automatically import symbols from each other when the project is loaded. Ideally this would happen "live", with project changes being detected automatically.
  • We currently only export symbols that are marked for export. This is desirable for a static mechanism like we currently have, but may not be needed if a "live" import side is only pulling in the symbols it needs.
  • (see also https://github.com/fadden/6502bench/issues/148)

• If DEBUG features are enabled, add a "load it anyway" button when reporting that the file length or CRC is incorrect.

External Files (Extension Scripts and Symbol Files)

• Enhance symbol files.

  • We currently have "address" and "constant". Might be useful to identify vectors (which are expected to point to code, making it easier to spot lda #<thing / sta vector / lda #>thing / sta vector+1).
  • Allow definition of non-ASCII character constants, e.g. CR=13 / LF=10, that will be used when an operand is formatted as ASCII but the value is outside the ASCII range. Could be global, could be custom.
  • Define a way to specify symbols for indexed vs. non-indexed access to memory-mapped I/O locations. Useful for things like Apple Disk ][ symbols. (https://github.com/fadden/6502bench/issues/80)

• Enhance extension scripts.

  • Define file access primitives so scripts have limited access to files outside the sandbox. Only useful if something needs data beyond what it can extract from a .sym65, or more data than we want to load into the symbol table.
  • Define some sort of "struct" mechanism, e.g. for operating system parameter blocks.
  • Allow scripts to generate a wider variety of things, like comments and long comments.
  • Define a way for scripts to indicate that they want a certain .sym65 file, so we can notify the user if it isn't part of the project.

• Define a way for plugins to call each other. (Can we do this now, with reflection?)

  • Define a way to have shared code libraries for plugins.
  • Improve debugging. The Visual Studio debugger is a little hit-and-miss depending on how things are configured. With a Debug build and the sandbox disabled it works quite well, but we may be able to do better in a regular Release environment.

• Add a revision number to platform symbol files, which are copied into the project file. That way the user can know if they're using the correct version of RuntimeData symbol files. (Not convinced a single version number is the answer here.)

• Performance: projects with large numbers of platform/project symbols take a long time to refresh.

• Optimize case where multiple projects use the same project-local plugin. Consider naming the DLL after the SHA1 of the source file. This would avoid unnecessary recompilation and duplicate binaries, but would require a more active PluginDllCache cleanup.

• Define project query interface, e.g. to ask what the default character encoding mode is.

Miscellaneous

• Make a better SourceGen program icon.
• Add user interface regression tests. The current regression tests only exercise the analyzer.
• Use Visual Studio style docking windows, allowing the UI to be configured freely. (I have no idea how to do this.)
• Add some attributes to the project, like author info and data created. Sort of a "header note" that doesn't get displayed. Could also add a URL where the data file can be downloaded. Could even do the download automatically.
• Add quick-find modes to the 65xx Instruction Chart tool, so you can quickly jump to an instruction by hex opcode or mnemonic. (See https://github.com/fadden/6502bench/issues/61)
• Add "set-label" and "set-operand-symbol" to SGEC.
• Add a timer that counts the amount of time a project has been open. The idea is to get a general sense for how much work has been put into a disassembly, so the timer would need to pause when no input events have been received for a certain period of time.