Jeff's VIC 20 Book
- orion70
- VICtalian
- Posts: 4341
- Joined: Thu Feb 02, 2006 4:45 am
- Location: Piacenza, Italy
- Occupation: Biologist
Re: Jeff's VIC 20 Book
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! ).
Re: Jeff's VIC 20 Book
Thank you. What do you mean? For the programs in the back? None would exceed 9 lines.joshuadenmark wrote: ↑Fri Nov 20, 2020 10:22 am Great idea with a book Jeff, perhaps you can add a floppy disk with the sample codes?
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
- Vic 20 Scientist
- Posts: 1315
- Joined: Fri Jan 04, 2008 5:11 pm
- Location: Austin, Texas
- Occupation: Game maker
Re: Jeff's VIC 20 Book
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
- AndyH
- Vic 20 Afficionado
- Posts: 368
- Joined: Thu Jun 17, 2004 5:51 am
- Website: https://www.hewco.uk
- Location: UK
- Occupation: Developer
Re: Jeff's VIC 20 Book
Looks great Jeff. I'll buy a physical copy when it is ready.
Re: Jeff's VIC 20 Book
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).
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).
Re: Jeff's VIC 20 Book
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)
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
- Herr VC
- Posts: 4845
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Jeff's VIC 20 Book
Inside cover:
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:
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
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
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.
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
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
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
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)
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
- Vic 20 Afficionado
- Posts: 368
- Joined: Thu Jun 17, 2004 5:51 am
- Website: https://www.hewco.uk
- Location: UK
- Occupation: Developer
Re: Jeff's VIC 20 Book
Hi Mike
In the list of notes, the first entry is 255 - is that correct?
In the list of notes, the first entry is 255 - is that correct?
Code: Select all
C 255 191 223
- Mike
- Herr VC
- Posts: 4845
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Jeff's VIC 20 Book
Yes.AndyH wrote:In the list of notes, the first entry is 255 - is that correct?
Code: Select all
C 255 191 223
Re: Jeff's VIC 20 Book
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?
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?
Re: Jeff's VIC 20 Book
I've used the Pet Me 2X font from here:
https://www.kreativekorp.com/software/fonts/c64.shtml
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).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?
Re: Jeff's VIC 20 Book
That's where I must have copied it! It's missing the pound character too. I guess I'll have to make my own(?)srowe wrote: ↑Tue Jan 05, 2021 12:49 pmI've used the Pet Me 2X font from here:
https://www.kreativekorp.com/software/fonts/c64.shtml
- Mike
- Herr VC
- Posts: 4845
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Jeff's VIC 20 Book
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.Jeff-20 wrote:I sometimes use binary charts just to know if a certain bit is on or not.
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.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.
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.
- Mike
- Herr VC
- Posts: 4845
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Jeff's VIC 20 Book
A few more corrections:
Page 79: Game Port
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.
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
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.