Add NameTable and AttributeTable resolve funcs
that use the registers as input to obtain the
address.
Made v and t registers into a variable type
Fixed error regarding the highest bit of the registers,
which should've been null, not 1, my bad.
Change the PPU register engines to use the proper behaviour
as described by loopy and documented in the nesdev wiki
(https://www.nesdev.org/wiki/PPU_scrolling) <- here
Thus, ppu.address and ppu.scroll become obsolete and replace
with ppu.tReg and ppu.vReg that contain both, but in different
moments in time, we sometimes sync t -> v at certain triggers.
Basically we work with t and read from v, and sync some parts
between them when neccesary, loopy does a great job at documenting
this.
!!! PPU.ADDRESS and PPU.SCROLL ARE NOW OBSOLETE, WILL BE RM'D
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
!!!!! BUSTRANSACTION.VALUE IS NOW 8 BIT
apparently it was 16 bit before, thing which I forgot about and that
caused a lot of issues with bit shifting and masks, so I fixed that
- I also changed REL and all the branching (B*) opcodes to match it,
they now get the new PC from x.address, not x.value, which is more
logical and also means x.value doesnt have to be 16 bit anymore
(hurray!!)
-rewrote and fixed: ASL
ROL
SBC
- Also fixed typo on the opcode info registry at AND (0x21), it
was INDY instead of INDX
- Added __restrict__ to more opcodes
if the tmp variable in ADC went over 0xFF everything would break
also the overflow flag in the SR used to be set improperly
this fixes ADC (hopefully) entirely
:)
RenDev
Joaquin
KoNicks
KoNicks