Jeff's VIC 20 Book

[srowe]

Couple of typos on page 18

"Merge files" the command should start "C0:" (zero) and I'm not sure spaces are allowed after the commas.

"Read ERROR CHANNEL" shouldn't "AS" be "A$" in both cases?

[Jeff-20]

Great feedback, guys!

The charts on pages 26-27 and the one on page 30 are kind of redundant. I'd probably rather have these combined.

I included both in the draft for comparison. It seems both fail in specific ways.

One of them leaves out one-byte instructions, which seems like it would become an unwelcome feature.

The following page 31 had what ever didn't easily fit in that chart.

You can put the instruction size in the header with the addressing mode rather than in the opcode box, and it'll look less cluttered.

Good idea!

The information I mostly need to look up is cycles and register behavior. I hardly ever need to look up opcodes, and I never need to look up instruction size. Unfortunately, cycles and register behavior don't fit well on the same chart because you need to know addressing mode for cycles, but not for register behavior.

I made a mock page with a different approach. Imagine the opcodes could be swapped out for cycles. With single digit cycles, there should be room to even include the brief description or other information.

I could add bytes to a vertical axis...

ML2.png (11.31 KiB) Viewed 8687 times

The practical impact of this is that my favorite kind of 6502 chart is the big alphabetical chart-with-everything.

On page 143-161? I recall several.

Couple of typos on page 18

"Merge files" the command should start "C0:" (zero) and I'm not sure spaces are allowed after the commas.

"Read ERROR CHANNEL" shouldn't "AS" be "A$" in both cases?

Got 'em! Thanks! I get sloppy sometimes.

[Jeff-20]

Or maybe this? Color columns make it a bit less cluttered to me. I seem to be missing some columns the PRG has like relative, implied, absolute direct... should I drop the descriptions to add them?

[chysn]

Yeah, that one's great. Maybe don't drop the descriptions, but use formalized descriptions. So instead of

ADC "Add with Carry"

it would be

ADC "A + M + C -> A, C"

(see https://www.masswerk.at/6502/6502_instruction_set.html for these formal descriptions)

I do like the layout of those.

[Jeff-20]

How's this draft (link removed)? Corrected typos and reworked the ML pages 26-31. I now have two free pages.. what else could I add?

[chysn]

How's this draft? Corrected typos and reworked the ML pages 26-31. I now have two free pages.. what else could I add?

That 6502 instruction chart on pages 28 and 29 is something I'll want access to all the time.

The only nitpick I have is that, for the BIT instruction, the registers say "M M - - - ✓ -" and it would be more useful as "M7 M6 - - - ✓ -" I mean, the same information is in the formal description, and I realize that you might not have room for two characters there. Not having two characters available is likely why you left out the bit numbers in the first place.

But either way, it's a good chart. It should be laminated.

[AndyH]

Looks excellent Jeff. Also agree about that chart.

[srowe]

How's this draft? Corrected typos and reworked the ML pages 26-31. I now have two free pages.. what else could I add?

Pixel table on page 9 has the wrong pattern for 11

The commands CONT and NEW on pages 20 & 21 have the text "{direct more}", should that be "mode"?

[Mike]

Regarding the opcode table, I would still prefer the opcode values given in decimal, as that would cover the two use cases I'd mostly expect for this table: manual coding of machine language into DATA statements in the absence of any supporting tool like a monitor with direct assembler, and checking the validity of an address mode for a given instruction mnemonic.

I seem to be missing some columns the PRG has like relative, implied, absolute direct... should I drop the descriptions to add them?

You can unite the columns for implied and accumulator address mode, but having the branch instructions sorted in there is just plain wrong. Neither would the branches belong to the absolute address mode column. They use relative address mode with a signed 8 bit encoded offset (-128 .. +127, counted from the instruction following the branch!).

Both address mode variants of the JMP instruction and the JSR instruction are wrongly categorized and absolute indirect address mode also needs to go in an own column.

The instruction size can be inferred from the address mode column, once this is sorted out.

Unless you code cycle exact routines (like raster screen effects or transfer code on the serial bus), the table for cycle counts is mostly redundant. Neither are those cycle counts really needed to optimize for speed. Simply counting executed instructions works quite as well.

The undocumented "illegal" instructions can also be left out at no great loss. BASIC and KERNAL do not use them and unless the function of a program critically depends on the odd byte or odd cycle being saved by their use, their mode of operation can always be expressed by a combination of the regular, documented opcodes.

[Jeff-20]

I feel I've gotten too far away from my vision: a large font simple refence (not an instructional guide). I'll use THIS NEW WORKING DRAFT as reference to this post.

Yeah, that one's great. Maybe don't drop the descriptions, but use formalized descriptions.

I knew when I started it would be more than presumptuous to add assembly to the book at all. I'm starting to realize assembly programmers would need little or none of the information I tried to include. The value chart (PAGE 44-) and maybe flags would probably be enough. Agree?

The only nitpick I have is that, for the BIT instruction, the registers say "M M - - - ✓ -" and it would be more useful as "M7 M6 - - - ✓ -" I mean, the same information is in the formal description, and I realize that you might not have room for two characters there. Not having two characters available is likely why you left out the bit numbers in the first place.

.. demonstrating this is not an easy to read, large print text. I simplified and removed information that may be contentious (I didn't even have a chance to see Mike's comments before coming to this thought).

See page 24. Is there any reason it would not be formatted as the alternative page 25?

Looks excellent Jeff. Also agree about that chart.

Thanks for the support!

Pixel table on page 9 has the wrong pattern for 11
The commands CONT and NEW on pages 20 & 21 have the text "{direct more}", should that be "mode"?

Got 'em! Thanks!

Regarding the opcode table, I would still prefer the opcode values given in decimal, as that would cover the two use cases I'd mostly expect for this table: manual coding of machine language into DATA statements in the absence of any supporting tool like a monitor with direct assembler, and checking the validity of an address mode for a given instruction mnemonic.

Very good point! That is the only circumstance I could see myself using this information. I think the value chart in the back will suffice in that case.

I included the VICMON instructions (also information I would never use myself)... I am thinking that because there are so many tools for this sort of thing, I could probably cut that too. Otherwise, I might be tempted to add instructions for the Super Expander and Programmer's Aid cart, etc. I assume no one would really need that.

1. I was working on the memory listing (page 27-43). I added labels pulled from COMPUTE guides. Useful?
2. Lost lots of little things like the hex screen map.
3. I'm also now thinking of quick little useful lines of code. Like relocating BASIC and such (page 53). Does anything else similar come to mind?

[chysn]

I knew when I started it would be more than presumptuous to add assembly to the book at all. I'm starting to realize assembly programmers would need little or none of the information I tried to include. The value chart (PAGE 44-) and maybe flags would probably be enough. Agree?

Yeah. The value I'll get from this book isn't in the assembly stuff anyway, it's from the other charts, like that value chart.

And, I think that the page 25 chart is a fine alternative to the page 24 chart. I do think, for any kind of reference, that the formal functional descriptions are important, but you'd probably need to go to two pages for the big print version of this.

[Jeff-20]

How's (link removed)? Corrected typos and reworked the ML pages 26-31. I now have two free pages.. what else could I add?

That 6502 instruction chart on pages 28 and 29 is something I'll want access to all the time.

The only nitpick I have is that, for the BIT instruction, the registers say "M M - - - ✓ -" and it would be more useful as "M7 M6 - - - ✓ -" I mean, the same information is in the formal description, and I realize that you might not have room for two characters there. Not having two characters available is likely why you left out the bit numbers in the first place.

But either way, it's a good chart. It should be laminated.

[Jeff-20]

New draft for your approval: link (please view PDF in "two-page" mode).

Adjustments to note:

• Spiral bound books may be too expensive to print and ship. Shifted to one page formats (no longer lays flats).

• Shifting to greyscale lowers the price significantly and makes it easier for me (for my vision) to design.

Concerns:

• Greyscale may need to be darker for proper print contrast.

• ML pages need input/suggestions.

• Memory map may still have areas for expansion and elaboration.

I finally organized book based on my particular coding (rather than guessing at what others may want). Good idea or bad? I think I can get the price down to $5 if it's eventually shared.

[Mike]

Some remarks:

Pages 2-5: generally, all descriptive parts like "file number", "line number", etc., should be in angle brackets, "<" and ">", to discern those from literal parts of a syntax. Optional parts of a syntax go into square brackets, "[" and "]". Your use of curly brackets, "{" and "}", in the lower, grey rows is inconsistent and you should leave them out of the syntax descriptions. What you write in the upper, white row should suffice.

• ASC should have ASC(A$) in its syntax description,
• with DEF FN and FN, you should state the variable name with angle brackets, "<" and ">", to denote the specifier,
• EXP, LOG - no need to specify "X < 88.03" or "X > 0" in a syntax description!

Pages 7,8: "COLUMN" should be "ROW".

Page 8: "insert" should go into the section "manually in RVS mode, SHIFT-T". "delete" should go into the first section (DEL) - you need to be in insert mode, though. "Reverse @" cannot be entered within a BASIC statement!

Page 9: Addresses 8192 to 15872 do not work at all for video data! Adresses 1024 to 3584 require an internal 3K RAM expansion (on the VIC "side" of the address and data busses) and thus are likely out of question as well. Memory allocation needs to be explained more thoroughly - you never would point 56 to low addresses (rather, raise the start of BASIC in 44) and 52 is always set along 56 upon CLR!

Page 14:

• "Format a disk" should use - "N0:Diskname,ID" (ID: 2 chars) - to stress that IDs, when given, *must* be 2 chars!
• "Copy disk" only works with dual disk drives (i.e. the older CBM stations with two drives built in)!
• the routine for "Read Error channel", as stated, does not work in direct mode.

Page 18: "JMP 108" should be "JMP() 108".

Page 19: "SYS 64096" should be "SYS 6*4096".

Page 22: Your copy of my memory chart here should include all the information I put into the diagram and the caption below it.

Pages 31..41, $C000..$FF72: this list is likely to be redundant without an accompanying ROM listing. All these routines need the registers and certain memory locations correctly set up to be useful, which is missing information here. That place was better used for a verbose description of the KERNAL jump table ($FF84..$FFF3), with all entry and exit description as stated in the PRG. If you actually venture into ML programming, that is.

Page 53: The "BAD DATA" error message should be "FILE DATA" instead.

[chysn]

• Spiral bound books may be too expensive to print and ship. Shifted to one page formats (no longer lays flats).

My suggestion would be, go with the spiral binding. For a reference book, laying flat is worth the extra money. Nobody whose hobby is "retro-computing" is particularly price-sensitive, and if they are, there are always PDFs.