Programming the VIC

Programming the VIC - The definitive guide to the Commodore VIC-20 Computer
	Sprache	englisch
	Autor(en)	Raeto Collin West
	Verlag	COMPUTE! Books
	Jahr	1984
	ISBN	ISBN 0-942386-52-3
	Neupreis	$24,95
	Datenträger
	Seitenzahl	602
	letzte Auflage
	Genre	Profi, Programmieren, Hardware
	Information

Dieses (englische) Buch beschreibt die Internen Details des VC-20 (in den USA unter dem Namen VIC 20 bekannt) in relativ detaillierten Einzelheiten. Es war früher eines der "Standardwerke" für VC-20 Programmierer (so sagt man zumindest).

Vorwort

Programming the VIC picks up where other programming guides leave off. It covers virtually every aspect of the VIC-20, from simple BASIC commands to complex machine language techniques, and every explanation is written with clarity and style. The result? A comprehensive book, easy to read and understand, that thoroughly reveals the VIC and demonstrates its capabilities. [...]

Inhaltsverzeichnis

• Foreword
• Chapter 1 - Introduction
• Chapter 2 - Getting to Know Your VIC-20
• Chapter 3 - BASIC Reference Guide
• Chapter 4 - Effective Programming in BASIC
• Chapter 5 - VIC-20 Architecture
• Chapter 6 - Beyond BASIC
• Chapter 7 - 6502 Machine Language
• Chapter 8 - ML Methods Specific to the VIC-20
• Chapter 9 - Mixing BASIC with Machine Language
• Chapter 10 - Vocabulary of the 6502 Chip
• Chapter 11 - VIC-20 ROM Guide
• Chapter 12 - Graphics
• Chapter 13 - Sound
• Chapter 14 - Tape
• Chapter 15 - Using the Commodore Disk Drive
• Chapter 16 - The Games Port
• Chapter 17 - Major Peripherals
• Appendices
• Appendix A - A Beginner's Guide to Typing In Programs
• Appendix B - How to Type In Programs
• Appendix C - The Automatic Proofreader - by Charles Brannon
• Appendix D - Screen Location Table
• Appendix E - Screen Color Memory Table
• Appendix F - Screen Color Codes
• Appendix G - Usable Graphics and Screen Combinations
• Appendix H - Screen and Border Colors
• Appendix I - ASCII Codes
• Appendix J - Screen Codes
• Appendix K - VIC Chip Registers
• Appendix L - Device Numbers
• Appendix M - Decimal-Hexdecimal Interconversion Table
• Appendix N - Opcodes in Detail
• Appendix O - Table of 6502 Opcodes
• Appendix P - 6502 Quasi-Opcodes
• Appendix Q - Interconverting VIC-20, Commodore 64 and CBM Programs
• Index

Leseprobe

Seite 165: Beyond VIC BASIC

How String Storage Can Corrupt User-Defined Graphics and ML in RAM

Provided the end-of-BASIC pointer is correctly set, strings will not disturb redefined characters or machine language stored at the top of memory. Programs 6-4 and 6-5 are small-scale, controlled examples (for the unexpanded VIC) of what happens when BASIC strings encroach into the wrong area.

Program 6-4. Unwanted Screen Characters

10 POKE 55,22: POKE 56,30: REM END OF BASIC INSIDE SCREEN
20 POKE 36879,8: REM BLACK, MAKES POKED CHARACTERS VISIBLE
30 INPUT N$: N$=N$+"": REM STRING GOES IN SCREEN RAM
40 GOTO 30

Program 6-5. Corruption of User-Defined Characters and Graphics

10 POKE 36869,255: REM $1C00 IS START OF USER CHARACTERS
20 POKE 55,8: POKE 56,28: REM BUT BASIC ENDS AT $1C08
30 FOR J=7168 TO 7680: POKE J, PEEK(32768+Q): Q=Q+1: NEXT: REM MOVE VIC CHARACTER SET
40 PRINT "{HOME}{WHT}@ABC": REM PRINT A FEW CHARACTERS
50 INPUT N$: N$=N$+"": GOTO 50: REM @ SYMBOL IS CORRUPTED

Garbage Collection

Programs using many strings are subject to so-called Garbage Collection delays. It is fairly easy to see why. Figure 6-6 shows a simplified situation where RAM contains several strings, some of which are now redundant.

Figure 6-6. Garbage Collection

Let's suppose BASIC tries to set up a new string but finds there's insufficient room. It calls a routine, the same as FRE(0), to find out which of the strings after BASIC are still being used. Strings stored within BASIC itself are outside the scope of this algorithm, and are ignored.

The routine has to check every string variable to determine which is nearest the top end of memory. This string is moved up as far as possible. The process is repeated with the remaining strings until the whole collection is cleaned up. The number of strings is important, not their lengths; generally, with N strings this takes time proportional to N plus N-1 plus N-2, etc. Mathematically inclined people will realize this adds up to an expression including N multiplied by itself (N squared). What this means is that, like the well-known bubble sort, a process that is acceptably fast with a small number of items can become painfully slow with a larger number. In fact, the whole process is analogous to the bubble sort: Intermediate results are thrown away, which saves space but wastes time.

The VIC takes roughly .00075 times the number of strings squared to free memory. The actual relationship is a surprisingly precise quadratic; this is only an approximation. For instance, 100 strings take .8 seconds, 200 take 3 seconds, 300 take 6.6 seconds, and so on.