Jeff's VIC 20 Book

[orion70]

Wonderful work Jeff, very nice looking graphically (I imagine it in small A5 pages on glossy, heavy paper held together with a metal binding - cute! ).

[Jeff-20]

Great idea with a book Jeff, perhaps you can add a floppy disk with the sample codes?

Thank you. What do you mean? For the programs in the back? None would exceed 9 lines.

This is awesome. Reminds me of Duckworth's "A Pocket Handbook for the VIC" (but much more nicely formatted).

I hadn't heard of this book and can't find a copied archived online. Is it available anywhere?
My goal is not to produce an original work. If there's anything I could use, I'd add it.

[Kweepa]

This is awesome. Reminds me of Duckworth's "A Pocket Handbook for the VIC" (but much more nicely formatted).

I hadn't heard of this book and can't find a copied archived online. Is it available anywhere?
My goal is not to produce an original work. If there's anything I could use, I'd add it.

Yeah, I've never found it on-line. It's a UK book from 1984 that I bought in Foyles in London around 1990.
A lot of it is cheekily taken from other sources (for example the Basic error messages section is apparently photocopied from the C64 PRG, and Tinymon and the zero page memory map credit Jim Butterfield).

Code: Select all

Contents

Preface 6
ASCII tables 7
Basic keywords 9
Basic error messages 12
Colour memory 14
Conversion tables 15
Disk commands 19
Disk error messages 21
Disk formats 26
Tinymon listing 35
Flow charting 38
Hex/dec convertor 40
Hyperbolic functions 41
Memory maps 42
Memory architecture 53
M/C instruction set 54
M/C mnemonics 74
Powers tables 76
Cartridge slot 77
Joystick slot 78
RS232 standards 79
Centronics standards 86
Other output 87
Screen memory 89
Sound chip registers 90
Musical notes values 91
Index 93

[EDIT]I was able to find "A Pocket Handbook for the Commodore 64" on-line which is identical in content and formatting with the exception of the bits that are VIC specific (eg colour memory, extramon instead of tinymon, the memory maps). The preface is even identical, aside from the name of the computer. https://www.retro-commodore.eu/misc-c64/2/

[AndyH]

Looks great Jeff. I'll buy a physical copy when it is ready.

[Jeff-20]

I had a chance to work on it today and am uploading a second draft. I compiled a bunch of things from this forum and tried to incorporate the suggestions I got in this thread. Again, this is mostly for myself, but I hope it will be useful to others here. So, if there's anything else you think could be useful, tell me.

If you are using a PDF viewer, go to VIEW>Page Display and change it to "Two-page view" so you can see what it would look like laid flat. Ignore the first two pages, one is the yet-to-be-made cover, and the other is just a spacer so you can see what a side by side layout would look like. If you open it in a browser, just know the even numbered pages are on the left and odd on the right.

I welcome input. My current concerns for the third draft:

1. Inside front cover. The "memory sequence" is not complete/correct.
2. page 10. The screen maps assumes hex will be mostly used with memory expansion. Is that ok?
3. page 46. The memory map is as detailed as I've been able to find. Did I miss some?
4. page 67. I left room for undocumented opcodes (included on 68) but need help on that.
5. page 68. My "super chart" puts undocumented or possibly wrong codes in gray.
6. page 80. I made a page for photocopying that could be cut if page count expands.
7. Is this draft more inclusive of assembly and ML programming?
8. Is this print large enough? The original goal was to make a durable large print book.

I explored some print-on-demand services and found I could get the book under 10 bucks shipped with heavy gloss-laminated pages and a wire spiral ring. Pretty happy with it so far (for my needs).

[srowe]

I'll have a proofread at some point but I noticed that the last hex value on page 50 is wrong, should be 03FC

Edit: a few more observations:

PETSCII character sets: char between '[' and ']' should be '£' not '\'

Page 14: Expansion RAM cannot be addressed by VIC

Pages 22/23: bit patterns between B0 and C1 are wrong

Page 35: Status: Tape routines do not flag end of tape in bit 7

Page 35: Command Numbers: Disk, SA 0 is used by LOAD, 1 is used by save

Page 59: Locations used by CPU, FFFA/B NMI, FFFC/D RESET, FFFE/F IRQ

Page 78: User Port: Pinouts are for C64 (mention CIA rather than VIA)

[Mike]

Inside cover:

Code: Select all

Logical values:

=0: FALSE     <>0: TRUE *)

*) relational operators <, =, > return -1 for TRUE

Code: Select all

Logical operators:

NOT 0 = -1
NOT -1 = 0

0 AND 0 = 0
0 AND -1 = 0
-1 AND 0 = 0
-1 AND -1 = -1

0 OR 0 = 0
0 OR -1 = -1
-1 OR 0 = -1
-1 OR -1 = -1

Code: Select all

Typical Program Memory Sequence
[...]
Bottom of string space:  51|52
Highest Address available to BASIC: 55|56

53/54 is an internally used workspace pointer into the string space and of no use whatsoever for the BASIC programmer. Please omit it!


Pages 20..23: For the sake of brevity, I'd omit this hex/binary/decimal translation table entirely. If this was intended to easily(?) match bit patterns for UDG design, I'd rather provide a simple one-line character editor like this one:

Code: Select all

1 OPEN1,3:PRINT"{HOME}";:FORY=1TO8:S=0:FORX=1TO8:GET#1,A$:S=2*S-(A$<>"{SPACE}"):NEXT:PRINTS"{LEFT,2 SPACE}":NEXT:CLOSE1

You'd need to enter this program line with abbreviations, otherwise it will overflow the 4 line (88 character) limit.

Just clear the screen and place a pattern with any other character than space in the top left 8x8 corner of the screen, then enter a RUN command in the bottom half of the screen. The converted values will appear to the right hand side of the bit patterns. Changes in the pattern are reflected in the converted values upon re-executing the RUN command.


Pages 32/33: Please provide this table instead:

http://www.sleepingelephant.com/ipw-web ... 43&start=7

Code: Select all

C     255    191    223
C#    134    195    225
D     141    198    226
D#    147    201    228
E     153    204    230
F     159    207    231
F#    164    210    232
G     170    212    234
G#    174    215    235
A     179    217    236
A#    183    219    237
H     187    221    238
C     191    223    239

This table is much more accurate than the table in the VIC-20 handbook. The original table is completely de-tuned.


Page 34: Disk Drive

Code: Select all

[...]

Format a disk  OPEN 1,8,15,”N0:Diskname,ID”: CLOSE 1      (Jeff, please note: "ID" instead of "00")

[...]

Copy disk      OPEN 1,8,15,”D0=1”: CLOSE 1               ("D", not "C". No second "D". Only for dual disk drives!)

[...]

Rename a file  OPEN 1,8,15,”R0:NewName=OldName”: CLOSE 1  (Jeff, this one was missing)

Please remove the entry with "Replace a file SAVE”@0:filename”,8"! As noted at several places here in Denial and elsewhere, this command can lead to data loss on the disk. A file should only be replaced by first deleting it with the Scratch command and then saving again with the same name.


Pages 38..41: The described syntax of the addressing modes is non-standard - where in heaven did you quote this from?

The absolute (16-bit) addressing mode usually is denoted with either "ABS" or "$xxxx", for example ADC ABS or ADC $xxxx


Absolute-X and Absolute-Y go as: ADC ABS,X or ADC $xxxx,X and ADC ABS,Y or ADC $xxxx,Y

Zeropage address mode is denoted with either "ZP" or "$xx", for example ADC ZP or ADC $xx

Zeropage-X and Zeropage-Y go as: ADC ZP,X or ADC $xx,X (similar with ZP,Y which only exists for a few instructions though)

Immediate address mode is denoted with either "#IMM" or "#$xx", for example ADC #IMM or ADC #$xx

Indirect Zeropage address mode is denoted with either (ZP),Y or ($xx),Y (Y-post-indexed) and (ZP,X) or ($xx,X) (X-pre-indexed)

Indirect (absolute) address mode is denoted as JMP (ABS) or JMP ($xxxx) (only the JMP instruction provides this address mode on the NMOS 6502)

Branches use the same syntax as the absolute address mode, but encode the address as signed 8-bit offset from the address following the branch instruction.

Implied instructions have no literal operands (some assemblers require "A" as operand for shift instructions on the accumulator).


Pages 60..67:

Mixing zeropage, I/O addresses, ROM routines, OS workspace addresses and then sorting them alphabetically completely destroys any inner structure that might be inherent due to the original address order. I could not imagine to use that list for reference myself, sorry.

[AndyH]

Hi Mike

In the list of notes, the first entry is 255 - is that correct?

Code: Select all

C     255    191    223

[Mike]

In the list of notes, the first entry is 255 - is that correct?

Code: Select all

C     255    191    223

Yes.

[Jeff-20]

Great feedback, everyone! It's, admittedly, a very rough 2nd draft in need of a LOT more work than I thought!

First, I found these little PNG images of VIC characters online somewhere and have not been able to find them again. Anyone know the original source?

I need the pound symbol (and reverse images to save me the time of manually inverting each PNG).

srowe, good eye! I get sloppy sometimes. I would have never noticed those slips.

I got the "end of tape" info from the Programmer's Reference Guide page 50. Could you say more?

Mike, I sometimes use binary charts just to know if a certain bit is on or not. Just like the screen maps, it speeds up the simple math for me (so, maybe that kind of thing is only useful to me).

Great catch on the notes! I totally forgot about your note value corrections! Cool.

As most of you know well, I'm only interested in BASIC type-in aesthetics. I'm not sure where I got that syntax... I believe I got my assembly info mostly from the Programmer's Reference Guide and maybe a Compute Book. Should I just remove it (page 38-41)? I suspect this sort of project wouldn't be of interest to machine-language programmers. Removing 60-67 is a good idea and will save me a lot of pages.

I will still need to make corrections to the "super chart" 6502 info beginning on 68.

Now that I write this, I am thinking a lot of this info could be cut. Ports, Disk drive status numbers. A comprehensive guide would need to be much longer than what I'm shooting for. Any opinions on removing all of that if this is just a quick reference guide?

[srowe]

First, I found these little PNG images of VIC characters online somewhere and have not been able to find them again. Anyone know the original source?

I need the pound symbol (and reverse images to save me the time of manually inverting each PNG).

I've used the Pet Me 2X font from here:
https://www.kreativekorp.com/software/fonts/c64.shtml

srowe, good eye! I get sloppy sometimes. I would have never noticed those slips.

I got the "end of tape" info from the Programmer's Reference Guide page 50. Could you say more?

Yes, this is found in many books. Having disassembled the tape routines I assert that isn't what the code actually does. EOT actually results in a "DEVICE NOT PRESENT" error (by accident, $05 is the EOT tape header type and it 'leaks' out as an error code).

[Jeff-20]

First, I found these little PNG images of VIC characters online somewhere and have not been able to find them again. Anyone know the original source?

I need the pound symbol (and reverse images to save me the time of manually inverting each PNG).

I've used the Pet Me 2X font from here:
https://www.kreativekorp.com/software/fonts/c64.shtml

That's where I must have copied it! It's missing the pound character too. I guess I'll have to make my own(?)

[Mike]

I sometimes use binary charts just to know if a certain bit is on or not.

A simple "PRINT value AND x" with x=128,64,32,16,8,4,2,1 in the screen editor does the trick for me.

As most of you know well, I'm only interested in BASIC type-in aesthetics. I'm not sure where I got that syntax... I believe I got my assembly info mostly from the Programmer's Reference Guide and maybe a Compute Book. Should I just remove it (page 38-41)? I suspect this sort of project wouldn't be of interest to machine-language programmers. Removing 60-67 is a good idea and will save me a lot of pages.

You could experiment with putting the instruction mnemonics on the left of a page (sorting them alphabetically is o.k. here, 56 instructions), all addressing modes at the top (12 if you subsume accumulator addressing and implied), then filling in the table with all documented opcode values in decimal (151 in total), for whatever amount of hand-assembly into DATA lines you intend to support.

Even for the experienced ML coder this still allows for a quick look-up whether a given instruction actually allows for a certain addressing mode.

Otherwise, the use of a monitor cartridge on the VIC-20 pretty much takes care of all that. That doesn't even require anymore a list of the mnemonic opcode values in hex.

[srowe]

That's where I must have copied it! It's missing the pound character too. I guess I'll have to make my own(?)

No, it is there, code point E22C.

[Mike]

A few more corrections:

Page 79: Game Port

Code: Select all

JOYSTICK

Joystick UP       (PEEK(37151)AND4)=0    bit 2 off
Joystick DOWN     (PEEK(37151)AND8)=0    bit 3 off
Joystick LEFT     (PEEK(37151)AND16)=0   bit 4 off
Joystick RIGHT *  (PEEK(37152)AND128)=0  bit 7 off
Joystick BUTTON   (PEEK(37151)AND32)=0   bit 5 off

PADDLE

Paddle A button   (PEEK(37151)AND16)=0   bit 4 off
Paddle B button * (PEEK(37152)AND128)=0  bit 7 off

*) enclose between POKE37154,127 and POKE37154,255

Note the correction regarding the right direction, and bit numbers cf. their value. Also note how 37154 is supposed to be handled so PEEKing 37152 works as intended.


ERROR messages

"BAD DATA - received string data when numeric expected" - even though this error message even appears in the User Guide, it's actually printed as "?FILE DATA" error. It's the equivalent of "?TYPE MISMATCH" applied to file I/O.

one missing error message:

"ILLEGAL DEVICE NUMBER" - attempted file operation on unsuitable device. For example, SAVE to screen.