- remove si_schedule function. Move it inside write_si_reg body.
- add word-alignment restriction on dram address, and do word-copy
- rename si_type to dma_dir, also SI_DMA_NONE is now SI_NO_DMA
- pif_addr validity test is more relaxed (test only 25 bits).
- add more comments
PI controller now accepts 4 different dma handler, one for each DMA'able
region (DD ROM, CART SAVE, CART ROM, 1FD00000). Each handler is
responsible for effective data transfer and some extra operation as
needed (cached_code invalidation for instance).
savestate loading code was trying to poweron rumble pak on a
non-initialized rumble pak.
Now we check that the game is rumble pak compatible (therefore it has
been initialized) before calling the poweron function.
A similar issue was also present for transferpak.
Also during this process, I felt necessary to slightly alter functions
prototypes (better name, easier usage/implementation).
I also specified the NULL terminated strings ownership, and thus
reworked some aspects of objects ownership.
NULL or empty strings usage also have been documented. For ROM, empty or
NULL strings allow to have an empty transferpak. For RAM, empty or NULL
strings will let the core generate a suitable save filename and
initialize it with empty content. This can be helpful when a GB save
file is not available and the game doesn't really care about the initial
saved content (for instance Perfect Dark).
The init_gb_cart function as also been slightly modified to better
handle loading failures (and not leak stuff in this case).
The GB pak switch function is now only activable when the game is
compatible with the Transferpak. Still you can change what is inside the
transferpak even when the transferpak is not plugged in.
Also
* Move backends implementations under backends directory.
* Rework file_storage to be a real implementation of storage_backend.
* Fixup PIF_PDT_EEPROM types
* Extract joybus stuff from pif module.
* Extract cart stuff from pif module.
* Extract controllers and paks from si module.
As this is fairly similar to a standard controller (at the pif
protocol level), I just implemented it using a game controller "flavor"
and not a separate entity.
Still WIP and not accessible (unless you hack your way inside main.c).
Also, in the future it should be possible to implement other kind of
"simple" game controllers such as the train controller.
I broke it when introducing opaque data to read/write memory handlers.
The issue was that there is a single opaque pointer for both read and
write function, whereas read and write breakpoints can be activated
independently. This was leading to a situation where wrong opaque
pointers was passed to read/write handlers.
The allocated memory is big enough (512M) to hold all the directly
accessible physical memory an N64 system have.
By having a single allocated block of memory we don't have to if/switch
for accessing ram, sp_mem, pif_ram and cart_rom in fast_mem_access.
This is also a first step toward implementation of "fast memory".
