- Fixed mapper 000 by chaning the mod operation to not disinclude 0x3FFF from being turned into 0. This fixes all issues with mapper 000 as it matches other established emulators
- Fixed all warnings other than non-disableable ones.
- Added a way to assign a test rom name so that it can start at a custom location rather than the address vector at 0xFFFC
RenDev's latest commit cleaned the 4 bytes of buffer before the
PRGROM even tho the program already accounted for that when
calculating the return address by substracting 0x4. I'm leaving his
way of dealing with the buffer since it saves 4 bytes of memory used
for nothing in my implementation.
Also cleaned the code a little, expect another commit that cleans
the code more vigurously
+ Added debug-tickonclick Make rule for manual clock operation
ROM loading did not remove the 5 bytes of padding when loading the rom. This caused the last 5 bytes of the rom to never be read. These last 5 bytes contained the vector to set the PC to during boot.
Now that that was implemented, any rom can now load rather than a Hardcoded location for all roms.
BEQ was facing some issues as well. Seems that we did not take into account negivite numbers in relation to address resolution. This has now been accounted for by typecasting the 'unsigned char' into a 'char'
If not for the attribute flag, the proccesor
would automatically makes padding between the
elements of the struct since they jump over
the byte boundary for efficiency purposes,
making all elements easier to acces for the
cpu. This however destroys our entire union, since
its made with no paddin in mind, the attribute flag
removes the padding
+Makefile cleaning
+*Reg.bits renamed to more appropriate .field
Did a bunch of small fixes to the code architecture,
most notably wrote the NMI function for the CPU and
actually docked the ppu files to the rest of the project.
The PPU currently does nothing but process some registers
in a basic sense.
I (hopefully along with rendev) will start work on the
background rendering soon, I also need to fix the registers
from their current makeshift solutions to the correct loopy
ones, lots of work to be done *sigh*, but the future does
seem bright.
Nothing much, removed the useless and overly complicated
mapperResolve funcs in preparation for starting work on
the PPU, this kinda simplifies things a bit.
As some may know (I didn't), when doing JMP(6C) on an address
like 0xXXFF (X may be any, let Y = X+1), JMP composes the
final address by reading the lsb from 0xXXFF and the msb from
0xXX00 instead of 0xXY00, as would be logical. JMP doesn't use
carry and as such can't pass over to the next page, and when
incrementing the argumental address (0xXXFF) the msb stays put.
I did now know about any of this, and this is a pretty monumental
exception, I feel more documentation should be written about this,
I only randomly stumbled upon this on 6502.org
bus_read16 used to read the lsb as the msb and the msb as the lsb,
fixed this by changing the read offsets for the addresses.
This was only primarly used in the IND addressing mode only used by
opcode 6C (JMP IND), which messed up on call, this fixes the issue,
but we still have later JMP problems that look not related to the
code, expect a further commit fixing JMP or any opcode causing the
branch from the expected output.
On branch main
RenDev
Joaquin
KoNicks