I've found an error in the C64 Programmer's Reference Guide. This copy of the C64 Programmer's Reference Guide apparently doesn't have the same error. I hope this thread can be used to collect other errors so they won't be a stumbling block for anyone else.

On page 277 ( page 296 of the PDF I have ) the description of the kernel routine CHRIN states that all characters on the line are stored in the BASIC input buffer.
This is wrong! BASIC stores the line in the BASIC input buffer, CHRIN does not. CHRIN reads each character directly from the screen ( screen memory.) If CHRIN is use from an assembly language program, the line of text on the screen will not be stored in the BASIC input buffer. Other than that, the description should be correct.

[Edit: Noted discrepancy with copy I have locally and a copy of the C64 Programmer's Reference Guide I found online]

Let's not forget the greatest error in the C64 guides of all time....the infamous "kernal" error.

_________________
Cat; the other white meat.

That edition has multiple errors.

For example, the entry for SETLFS on page 297. At the bottom in "How to Use", the first 2 steps are incorrect.
They SHOULD read:
1) Load the accumulator with the logical file number.
2) Load the .X register with the device number.

On page 299 the description is missing entries:

It SHOULD read (in part):
Purpose: Set file name
Call Address: $FFBD
Communication registers: .A, .X, .Y
Preparatory routines: None

The code example for LOAD on page 287 is incorrect.
The first two commands are wrong (the arguments are correct, though).

It SHOULD read:
LDX #DEVICE1
LDA #FILENO

At least that one won't cause you any problems.

The two versions I have, the one I already had and the one I downloaded Monday, do not have these two errors


They both have that one though.

Mine's printed in the UK, 1st Edition, 4th printing. I have a number of other PRG editions (and printings) in my collection and the changes and errors certainly vary. Fortunately the PRG is pretty good in terms of relevant information for ML programming, and assisted my exploration of the ROM code. Some of the Kernal code may seem messy but IMO it's surprisingly well-designed to work around the numerous constraints, and some parts are excellent examples of how to squeeze multifunctional 6502 code into a small amount of space.

Yes, I'm glad I also have Compute's Mapping the Commodore 64 as an alternate source of information for the C64.

Except nerd fights in the playground. LOL

_________________
Cat; the other white meat.