Seperation of PPU interfaces

[semiversus]

With commit 4372a45 I started to rework the interface between emulator and ppu. At the moment the ppu is defined by a big structure containing all the internals states, references to the emulator and references to the actual video output.
When playing around with different ideas for ppu optimizations things started to get complicated so here is a proposal to solve this issue:

• The only interface the emulator is getting to the ppu is via function pointers for read and write ppu registers and reset the ppu.
• An additional void * reference is here to point to the internal ppu data structure. The emulator don't need to have any knowledge about it.
• The ppu will be initialized outside of the emulator and is a module of it's own. No matter what the output looks like or which internal optimizations are used (fpga implementation, opengl buffering, ...) it's all up to the implementation.
• This separation helps to clean up nes.c which is holding a lot of ppu centric functionality.
• Different ppu implementations can share same functionality

The separation is work in progress. Missing is clean up of nes.c and adapting ppu_pixel_based.c (renamed to ppu_caching.c). The same separation makes sense for APU and controller input as well.

What do you think? @GorgonMeducer

[semiversus]

Working on the interfaces I came to the following conclusion: nes_t should be the struct holding the callbacks for PPU, APU, controllers and cartridge (may be even the cpu). The initialisation would look like this:

nes_t nes;
ppu_framebuffer_init(&nes, frame_buffer_array);
apu_stream_init(&nes, &audio_stream);
controller_callback_init(&nes, ui_controller_callback);
cartridge_init(&nes, rom_data);

The idea is to have various implementations (if needed). So beside ppu_framebuffer_init is a ppu_caching_init or maybe a ppu_opengl_init.
The mappers would be relatively easy to implement, because the nes_t would access the cartridge via four functions: read_prg, write_prg, read_chr, write_chr. Each mapper would have its set of access functions doing the expected work.

[GorgonMeducer]

A agree with you about those structural changes. Please moving forward, I will start a branch and try to optimize the new structure.
By the way, I don’t like the name: callbacks. It gives no useful information and it’s purely the legacy of procedure-oriented programming.

Since we are practicing interface-oriented programming and OOPC, please can we call those “callbacks” the “event handler”.
Although it looks the same, but the concept is different, they are not hooks, they are part of event-driven system.

[semiversus]

Agree, I take your point

[semiversus]

Reworking the cartridge interface I struggle with the special 16Bit access. I would like to avoid conditional compiling where possible. So when optimization makes sense and is working in all cases use that optimization. As the code and the interface is more complex with this 16 bit access path I'm not sure it's a good idea. What's your idea on that? We could benchmark the optimization and decide on that - which performance gain would justify a increase in complexity?

[semiversus]

Another possibility would be that we just have a 16bit read access. When the processor is reading from an address he gets a 16bit value from that and the next address. If it's meant to be a 8 bit access, it just drops the higher 8 bits.

[GorgonMeducer]

I like your second idea as it works like a prefetch mechanism or cache in theory.

I believe the you can have performance gain with an increased bandwidth in micro-architecture

[semiversus]

Ok, will go for a 16bit interface

[semiversus]

I pushed some commits, but it's work in progress. I learned some stuff about DMA: DMA is not part of the PPU, it's part of the CPU. Also the source for DMA transfers is limited to the 2kB RAM -> this makes it a lot easier. I removed the conditional compilation flag JEG_USE_DMA_MEMORY_COPY_ACCELERATION and made it the default.

[GorgonMeducer]

I am glad that the micro architecture is simplified.