The configuration file and runtime (crt0.s) provided for the default NES
ROM layout (2x16k PRG, 8k CHR) incorrectly added interrupts (IRQ1, IRQ2,
TIMERIRQ) which are not supported by the NES hardware. For example, see
the NESdev wiki, which makes no reference to these interrupts.
https://wiki.nesdev.com/w/index.php/CPU_memory_map
The VECTORS region was also incorrectly set to 0xFFF6, which would have
left the 0xFFF4 normally unspecified. This did not result in any error,
however, since cc65 simply placed ROMV directly after ROM0 regardless of
start address.
(This layout may be due to a copy-and-paste from the PC-Engine
configuration, whose interrupt registers start at 0xFFF6, begins with
the three interrupts listed above, followed by NMI and START, and does
not end with a final IRQ interrupt.)
Despite the absence of any actual error, since START is still placed at
0xFFFC, this patch removes the nonexistent interrupts and also correctly
aligns the ROM0 and ROMV regions. It also has the (admittedly very
minor) benefit of freeing up 6 additional bytes for ROM0.
* scanner: Correct handling of \0101
The C language has this oddity that octal constants are 3 bytes so the sequence
"\0101" is two bytes and well defined by the langage. cc65 currently misparses
this as a 1 byte octal code. Add a count to fix this.
Signed-off-by: Alan Cox <etchedpixels@gmail.com>
* cc65: remove un-needed logic from octal parsing
We no longer need the extra error handling logic for octal parsing so simplify
it as requested by Greg King.
Signed-off-by: Alan Cox <etchedpixels@gmail.com>
We no longer need the extra error handling logic for octal parsing so simplify
it as requested by Greg King.
Signed-off-by: Alan Cox <etchedpixels@gmail.com>
The C language has this oddity that octal constants are 3 bytes so the sequence
"\0101" is two bytes and well defined by the langage. cc65 currently misparses
this as a 1 byte octal code. Add a count to fix this.
Signed-off-by: Alan Cox <etchedpixels@gmail.com>
Stefan Dorndorf, author of XDOS, pointed out that retrieving the
default device by looking at an undocumented memory location won't
work in future XDOS versions.
He also showed a way to get the default device in a compatible
manner.
This change implements his method and adds a version check (XDOS
versions below 2.4 don't support this -- for them the behaviour
will be the same as, for example, AtariDOS: no notion of a default
drive).
