• pointer

• name

• type + name?

• only name, it is up to the system developer to ensure unique name for every component even when there are components of a same type
  Name can't be empty -- add warning to docs. The method should be precisely documented.

https://en.wikipedia.org/wiki/One-instruction_set_computer

Options:

• native file dialogs: https://github.com/samhocevar/portable-file-dialogs
  • why good: already included in bundle, neat native dialogs
  • why bad: no emscripten support yet, will need to fall back to imguifiledialog probs
• imgui dialogs: https://github.com/aiekick/ImGuiFileDialog
  • why good: nice imgui design, easy to use, support also emscripten

Bad options:

• https://github.com/pthom/ImFileDialog
  • why bad: need to create a texture, ugly (not native but also not unified with imgui design)

Every component could either:

• do the rendering itself (bad, it makes the component GUI library-dependent)
• export an Elements package (separates the GUI and serialization),
• export serialized data and pass them to the state-saving class (allowing to step back in time and to save the state to the file) and a GUI rendering class (this does not allow to specify formatting in the Component).
  • there could be formatting support added by exporting a GUI config
  • what about the speed of this solution?

• Memory
• 6502
• Bus

System will export required keyboard keys with default values and emulator will provide a settings menu to configure keybindings.

Add tests

1. run binary manually with requested system and test ROM
   a. unable to use google tests
2. append test files to the sources
3. copy test files to the working directory and load them in the sources

This function should output a loggable string containing the state of the relevant parts of the component.

Overall, the documentation will consist of:

• auto-generated docs - this tutorial
• tutorials for creating systems and components - issue #38
• bachelor thesis (only in Czech)

Normally, the cartridge can choose whether to use 2C02's built-in VRAM or provide its own. When using 2C02's VRAM, the cart can choose the mirroring type by connecting the CIRAM-A10 to A10 for vertical mirroring or A11 or horizontal mirroring.

Emulating the original implementation will require additional Cart<->2C02 communication (getting the mapper type or some connector) or lowering the level of abstraction for PPU bus addresing.

The better idea is to leave all the VRAM handling to cart - either the cart will always provide VRAM (better, even if it ignores real implementation, behavior stays the same) or the 2C02 can provide additional CIRAM interface (probably uneccessary overhead).

File name = system name. System will load keybindings on its load.

• During initialization memory should not be wiped (CPU initializes memory).
• On cart load CPU should be initialized (PC is loaded from reset vector).

The memory mapped peripheral is obviously already supported, however, the address spaces have to be separated, otherwise the Bus will write to all devices responding to the same address.

If the peripheral overlaps a memory, for a write access it does not matter. For the read access, there should be either:

• priorities, or other arbitration mechanism,
• possibility to ignore specific addresses in the component (bad),
• separated memories (bad if there is a lot of small peripherals).

The tests should use GTest error reporting instead.

Not needed

A usage of accumulator can be deduced from the m_currentInstruction.addrMode

Neat example would be a memory mapped LED.

• Add a new function readWithStatus() which will be used by Bus and similar classes, while the simple uint32_t read(...) can be used by other components.
• Leave it as it is and in every component add a handler, that can be also responsible for using correct types (busRead(uint16_address) etc.)

https://github.com/pthom/hello_imgui#main-signature-use-int-mainint-char

The Component should allow to dynamically add data/other IO connections - used in e.g. Bus.

https://www.nesdev.org/wiki/CPU_power_up_state

This is a behavior of NES, not 6502

How to generalize a data bus?

• use templates
• use a data type of a biggest possible size
• return a variant

Single type for all devices (uint32_t) will waste a few bytes for every transaction but it will be faster and more flexible than using templated Bus and then doing checks. The biggest problem will be when using Component interface's getBusInterface - this function could return various interfaces.

Use K. Dormann's tests.

Test config:

• zero_page = $0
• load_data_direct = 1

Assembler config:

• listing on
• as65 binary output

Latest version shall be built and deployed publicly.

Here is the tutorial.

Local files cannot be accessed with current file dialog. This will need further investigation (probably there could be an option to load zip file from an url).

https://stackoverflow.com/questions/47313403/passing-client-files-to-webassembly-from-the-front-end

If the bus does not inherit from the Component class, there will need to be a separate handling mechanism for the buses in the node editor.

If it does, we will need to implement a connect()/getConnection() for every Component - but that is what is essentially done in the first scenario.

This can contain tools e.g. for iNES header checking.

There should be possibility to discover "steppable" components. In static systems, doSteps and doFrames can be implemented manually, but in a case of dynamic systems there should be autodiscover features.

To be able to react only to specified bits.