8-Bit Book Club: Mapping the Commodore 64
Вставка
- Опубліковано 15 лип 2024
- Continuing on with the "Book Club" series, it's another of my favourite C64 books. Let's take a tour of the Commodore 64 with this excellent memory map.
Mapping the C64 on archive.org: archive.org/details/Compute_s...
To support 8-Bit Show And Tell:
Become a patron: / 8bitshowandtell
One-time donation: paypal.me/8BitShowAndTell
Previous episode about the C64 Programmer's Reference Guide: • Book Club: Commodore 6...
C64 KERNAL variations: • All the Commodore 64 K...
Credits song is "64738" by Bedford Level Experiment: • 64738 - Lyric Video
Index
0:00 Intro
2:25 Comparing the two versions
4:08 Foreword
6:25 What Is a Memory Map?
9:05 Introduction
11:07 Chapter 1: Page 0
20:57 Chapter 2: Page 1
21:49 Chapter 3: Pages 2 & 3: BASIC and Kernal Working Storage
24:14 Chapter 4: 1K to 40K: Screen Memory, Sprite Pointers, and BASIC Program Text
25:52 Chapter 5: 8K BASIC ROM and 4K Free RAM
27:42 Chapter 6: VIC-II, SID, I/O Devices, Color RAM, and Character ROM
37:01 Chapter 7: 8K Operating System Kernal ROM
40:57 Chapter 8: GEOS
42:30 Appendices
44:17 Thanks to my patrons! - Наука та технологія
Commodore Book Club. It looks like the author is still alive. You could interview him or do an anything Commodore discussion.
Today I wish I had kept all my old C64 stuff instead of giving it away. I spend many hours with this book, didn't understand all of it back then, but it was amazing to have all this information in one book. People often forget we couldn't just google things back then.
I bought the Commodore 64 Personal Computer Programmer’s Reference Guide when I was young. It was a white non-binder book and it was awesome. It came with a fold out schematic of the C64. I read it a lot. Over the years, the pages began to fall out, and my wife finally through it out without telling because “it was falling apart”. I
wish I still had it.
This book was probably the most coffee stained book in my collection. It rarely found it's way to it's resting place on my book shelf, and I admit to my computer "nerdness" that this book was usually my bed time reading. That habit was actually the cause for some sleepless nights because I would read something that sparked an idea that I had to get out of bed and try out what ever it was. My other, well "dog eared" book of choice was Compute's Programming the Commodore 64, The Definitive Guide.
By the way, Robin, snow makes an excellent hand cleaner ... it's cold as all heck, but that's why it works.
P.S. Your editing skills have greatly improved - very sly and ALMOST unnoticeable.
I used to work for Sheldon Leemon! He was co-owner of a couple of Commodore-based computer stores here in the Detroit area called Slipped Disk. One was in Sterling Heights. I can't remember where the other location was. When I was a teenager, he paid me to do some stuff on the Amiga. The only thing I remember him having me do was copying a bunch of disks. He was a big ham-radio guy as well.
A list like that list of BASIC function entry points would have saved me a ton of time when I wrote my extension to BASIC 7. I had the reference guide for the c128 was not aware of the equivalent “mapping” book for the C128 at the time. I manually looked at the vector table for the various BASIC 7 tokens and manually disassembled the code it pointed at. I was able to borrow a lot of cool circle and line routine logic for creating hi-res 640x200 mode commands. It was terribly slow to go through the weird VDC chip ports to access that video RAM, but I eventually got it done :)
I love these book videos almost just as much as the assembly videos. I bought two Commodore books yesterday: "Programmering med Commodore Basic" (a norwegian book) and "Simons' Basic - 114 Additional Programming Commands". Finally I'll get some use out of my Simons' Basic cart.
My favourite trick was relocating where in RAM the PRINT command printed to, and then literally printing sounds and sprites into memory, rather than a slower reading and poking data one byte at a time. You just printed the characters that represented the numbers you wanted in that RAM location sequentially, understanding which RAM locations did what. I recall having a program where you could choose various sound effects just for fun, and there were no POKEs to set the sound, just one to redirect the PRINT to the start of SID memory, then a print command with a bunch of random characters that made the sound effect. It was a really and effective way to get a block of numbers into memory fast.
I owned the Programmer's Reference Guide and loved it.
😮
Here's the pokes to do this, I found some OLD notes on yellowed paper...
To Clear the SID (sound) chip:
POKE209,0:POKE210,212:POKE211,0:?"@@@@@@@@@@@@@@@@@@@@@@@@@";
That is 25 @'s, which is ZERO on the C64, each printed into a SID location. The pokes set registers which redirect the PRINT to the start of SID. Now change those @'s to character that represent values to POKE into the SID chip (the first @ being the start of SID memory of course) and then you just use this same line to PRINT a sound effect! Like magic. Or use it to PRINT a sprite into memory by changing the pokes. I don't recall which of those pokes is low byte and which is high... but it should be easy to figure out.
@@NeilRoyThat's much cleaner than those DATA-deserts usually found in such occasions. ✌️
And the POKE 210,212 is the highbyte as 212 x 256 = 54272, the start of SID.
While the SID gets so much attention I always found the VIC-II so fascinating, and later learning it was designed by one person (Charpentier) in a few months impressed me even more. Yannes saying the filter was a little unfinished (my words) didn't take anything away from their accomplishment in a very short design cycle. IEEE Spectrum, March 85. Commodore 64 Design Case History.
Good ol' Compute! Magazines and books. That brings back some memories.
I spent a lot of hours as a teen doing the type-in programs. Always fun when finished and typing RUN and then getting ?SYNTAX ERROR IN XXX.
On a memory oriented cpu like the 6510 (and all of the Motorola's 68xx family) this book is an essential reading; this also explains the heavy use of the BASIC POKE commands to not only fill the memory with user data but for controlling many I/O aspects and modes of the C64
I loved this book. I bought it new one summer as a teenager, in a bookstore we stopped at during vacation. We were visiting all these historic spots on the east coast, but I couldn't wait to be done with each so that I could get back in the car and continue poring over Mapping The Commodore 64. It really helped me make sense of a lot of the kernal calls I had seen in programs I was still hand disassembling (thanks to the Reference Guide) at that time.
I remember buying "mapping the commodore 64" when I did not understand english but needed it to improve my assembly language skills! Totally worth it...
I found that a good text book plus a knowledgeable teacher for lectures and tutorials/directed study is the best way for me to learn.
Those Mapping the... books are cool. I have downloaded a version of Mapping the VIC from archive, too. It was very useful, when I wrote my first VIC-20 machine language program in almost 40 years :-))) It has a feature, that the C64 book does not. It marks memory locations in the zero page, that might have some function, but also be available as user memory.
Oh yeah, Still have mine, a very valuable reference. Stayed up late at night a lot, learning some programming. Along with magazines like Transactor, Compute, Run, Ahoy, articles by Jim Butterfield, and learning from my friend Jeff Turney, very much fun and interest. Still even have my 64's and 128 ,my 1581's my 1541's etc. all in boxes (some in original ones) Maybe pull them out and try to remember what I've forgotten. It was a lot of fun back when, new stuff out all the time.
I decompiled the BASIC and KERNAL routines *by hand* back in school (1990). Could have used this book. I was planning to write my own double-precision floating point math routines, but I never got around to it. I lost the notebook soon after I was finished, so *that* was time well spent (sarcasm). I *did* learn a lot by doing it, so it wasn't a complete waste.
After rewatching this for the umpteenth time, I just now noticed that the foreword at 5:20 mentions Dan Heeb's Toolkit books that you mentioned in a later video slipped under your radar. Talk about hidden in plain sight. :)
Cool, I got the older book, didn’t know there was a new revision. Guess 34 years later is better then not at all ;)
19:54 Hello, C3PO! I guess it's a capital "o" rather than a zero, but I still think it's fun. :) Also love the Leonard Cohen -esque credits tune.
Yes, its a capital "o". Here in Germany it would be correct. Because they translated him with C3PO. For zero/oh we only have the word "null".
There's an R2D2 also. Pagetable.com has an article about it.
This is my favorite Commodore book. Probably wouldn't be a BackBit without it.
Around 14:45 - as far as i remember the ability to flup out the kernal for ram was due to the software-update-ability, an example is GEOS which puts itself in kernal space, because all necessary functions were builtin, that way 28k roundabout were free for the Layout-Engine, Font-Cache, Buffers and such.
iIt could also be used to roll sequentially through datapages quickly with an offset coupled to the nmi and basically create a fast blitter, in result allows for color-interlace (about 170 colors that are differentiable) , creating a hercules-graphics-cards resolution (the 4k of the 80s) or abuse the resulting video-signal as a highthroughput data pass because it was quicker to read and show memorypages visually converted than moving pages (including the kernal) via Centronics, RS-232 or the floppy and devices serial busses.
There's lot more it allows you to do - anyhow, thanks for sharing this - beautiful!
And yes the original reference is a holy grail - i can not think of any manual that was so rich and close to the whole system ever again on other platforms - the Acorn Archimedes 3000 had a nice reference, too but i dunno if that was from Acorn directly. Commodore was lightyears ahead in everything - fact.
An addition - there was a way to buffer the main kernal for routines and flags which were used by all in the C64 family (VIC-20, C64, SX64, C64C, C128) into the 1541 some around 8KB, to then load a complete custom kernal replacement via expansioncard - basically allowed you to do virtual EEPROM flashburns, which were quite pricey and took time and patience.
I heard the happiness in purposefully mispronouncing that French! My wife lived in France for many years and I routinely butcher the language on purpose just to make her squirm 😂
I always liked how the title and internal fonts gave these books the style of the early days of Compute's Gazette, fitting since they came from Compute! Books. I wonder who owns the Compute! trademarks now, if anyone? I suppose they've expired.
Another great video. Amazing that you can make referencing a book entertaining and informative.
My favorite C-64 book was The Anatomy of the Commodore 64 by Abacus Software - to the point that I totally destroyed the binding and eventually had to make copies of the pages to put in a loose leaf binder for use (still have the original pages, mostly unreadable, somewhere in a folder) - I later found and have a much better, almost mint, copy of the paperback as a backup. (looks like Anatomy and Mapping would work great as a pair as Mapping has locations of the routines and Anatomy has a full disassembly of those routines for further info)
Maybe that joystick port 1/2 nonsense comes from a trace routing issue? Another nonsense were the 8 sprite pointers at the end of the character screen. It prevented a VSP implementation for fast scrolling. But the biggest nonsense was the 1541 floppy. The early PET disk drives were network capable, so in the classroom you would connect many PETs to a single drive. But how many home computers are gonna share a single drive so that it needs to be a computer on its own? Anyways, Commodore made lots of extra bucks with their slow and expensive 1541s.
Thanks for this informative and enjoyable video. Learned a lot from it.
Brilliant video. I’m glad I still have my copy of this book.
What a great book, if only a mapping book was also shipped with every C64.
I had this awesome book (the original) and it goes into so much more depth than the Reference Guide, which was also awesome.
When Compute! published Mapping the Atari, it was quite a big deal because Atari Inc themselves was loathe to publish hardware docs to how the machine worked. De Re Atari helped but Compute! really blew it out of the water with their document. I think Bill Wilkinson worked on it.
I've always pronounced GEOS as G Ose, rhymes with "dose."
Great video. Thanks!
Great video. You should scan it in and offer it with the doodles and the penciled in notes, as a service to your patrons.
Yea I love this book. I recently changed my C64 project to use the address labels from this book, because I was referencing it so frequently online.
Not the opening we expected. But the opening we deserved.
It was fun adding something silly like that, to hopefully ward off any complaints about my dirty fingernails.
@@8_Bit Didn't notice any nails. Great, Now I will be looking for them... 😀
Mapping the Commodore C64 is so cheap to get hold of:/ One of the few books i like to get my paws on. The PDF available widely is not in a good condition and scanned.
The bit about the GEOS pseudoregisters sound like the original Apple II Sweet 16 pseudomachine.
I recently bought a complete C64 with accessories just because the programmers reference guide was included...
😮
I was almost thinking I clicked an AvE video.
Hahaha, I had the same thought!!
I remember seeing this one in a local book shop, and not picking it up because I already had the PRG. The in-depth descriptions would probably have been helpful. Thanks for the review!
In other videos you cover the Super Snapshot and its reset functionality. Presumably resetting will cause the kernal to reset some zero page RAM, but not all. It might be an esoteric topic, but I think a really neat video would be what you can and can't recover after a warm RESET (e.g., doing surgery on the BASIC pointers to recover your BASIC program that crashed the machine.)
yes the good old days when you got a book (brick) with your computer and BASIC at power up. ZX 81 / Spectrum and Blitz Basic for me.
Ahh my favorite book.
Great books. By coincidence I recently typed in an old Space Invaders clone that Sheldon Leemon wrote for the Atari Computer and published in SoftSide Magazine. Sheldon was really prolific back in the day.
quel beau témoignage à partager avec vous tous. J'ai été expulsé de ma maison à cause de la pauvreté. puis je suis tombé sur klaxonstools. Je les ai essayés et ils m'ont rapporté beaucoup d'argent. J'ai payé mon loyer et il me restait encore plus d'argent
0:30 Ouch, my ears a bleeding! Though I don't speak French, that still sounds horribly butchered! What's that about fish?
5:27 The C64 PRG would have had large chunks copied from the VIC-20 PRG that preceded it.
5:43 I had the book "Mapping the VIC", which was the same idea and also published by COMPUTE! Books in 1984, but by author Russ Davies. Davies acknowledges Sheldon Leemon individually, but not his "Mapping The 64" book, which is odd since the RAM and ROM descriptions between the VIC and 64 would be almost identical. The location descriptions seem to be written differently between the two books, which seems like a lot of redundant work within one company.
6:28 That's how I look up memory locations.
12:37 Trivia question: on a stock C64, how can you read the content of RAM location 0? (Note: the RAM content, not the processor-I/O-register content.)
15:52 On the VIC-20, locations 0-2 stored a JMP xxyy instruction called by the USR() function, whereas on the C64, locations 0-1 are the I/O port, so the USR() JMP had to be moved which gave location 2 no use. The BASIC ROMs are identical between the VIC and C64 except for address and a couple of tweaks like this one.
19:00 I guess they considered it worthwhile, but putting this in zero page only saves 3 clock cycles and the content of the .Y register (or .X, since LDA (zp,X) could be used here). OTOH, it wastes time doing character tests you don't always need (you could have several different variations of this routine in ROM that only do tests that are specifically needed; I suppose you still could) and consumes 24 bytes of zero page that could have been available to the user. While putting this in zero page enabled BASIC on the PET computers to be extended, the VIC-20 and later computers have a better method to do this (23:10).
20:24 The description says 25 entries, but 242-217+1 = 26 bytes. It seems terribly wasteful to put the link-link table in zero-page. This would be an endless expanse of zero-page locations for user programs!
21:27 I doubt that merely defining them would overflow the stack. The stack would be used while evaluating the DEF FN() functions. I wonder if BASIC handles nesting properly for things like FN A(USR(FN B(USR(FN C(3))))).
23:03 Several of the zero-page allocations could have been moved to the 679-767 (89 bytes) unused range with little impact on ROM size.
25:18 It's odd that they don't explicitly say that the byte sequence $C3, $C2, $CD, $38, $30 is the text string "CBM80".
28:21 The "Mapping The VIC" book gives the default values of the VIC-1 registers (and other memory locations).
32:29 They would have been streets ahead if they had made it so Writing to $D41B caused the Noise waveform to output the written value as a constant until changed, i.e., an 8-bit DAC.
32:48 Your kid presumably scribbled on your favorite page because the book was most often opened to that page.
35:22 You can "de-conflict" the joystick and keyboard by reading Port B with Port A=$FF before scanning and then after. If either of these reads returns anything other than $FF, then assume that no key is pressed because you have joystick input instead.
35:45 They had such a lack of I/O lines that they added an I/O register to the processor. If they added a 6520 PIA chip to the design instead, they would have had I/O lines for days!
39:04 You'd think they'd have put System Reset into the $FFxx jump table.
'Trés puissant' sounded like 'Très poisson'.
I believe having the CHRGET routine in zero page usually saves only 1 clock cycle, not 3 cycles. While the first INC ZP saves 1 cycle EVERY time a character is read, the High Byte only gets incremented once every 256 executions. And "LDA TXTPTR" is using absolute addressing, which takes 4 cycles to execute whether it's in zero page or not. What I find a bummer about the CHRGET routine is for the cost of only 2 bytes, the routine could have either been relocated OUTSIDE of zero page (without increasing execution time) or optimized 1 cycle FASTER inside zero page. Take a look:
INC TXTPTR+1 ;RARE
BNE CHRGOT
;EXTRA 2 BYTES NEEDED
INC TXTPTR ;CHRGET (ENTRY POINT)
BEQ RARE ;MAKE RARE EVENT BRANCH
LDA $0207
;CHRGOT
(ETC)
255/256 of the time, we save a cycle. That 1/256 rare event takes a branch (twice) for 6 extra cycles. And if TXTPTR+1 ever wraps 255 (BNE fails) we got problems...
148 / 96 is C3PO??? Was the engineers at Commodore Star Wars-fans? :) 19:55
34:28 I thought that was a bug in C64 Forever. Lol.
Hey Robin, are you aware that Bil Herd is active on UA-cam? He was a chief hardware designer for Commodore 128 and knows a lot on the C64 as well. Besides talking hardware, he recently posted a video of a visit at the old defunct MOS Technologies facilities. Check him out at ua-cam.com/users/BilHerd
SYS64738
Nice, I've got the Atari version of "Mapping.."
I found a copy of Mapping the Atari last year, nice book!
I probably should have asked this earlier, but: 40:40 is it just me, or does overwriting the RESET vector not actually do anything? I haven't tried it on real hardware yet, but in VICE at least a soft reset seems to always go back to KERNAL...
As the reset line also changes ports 0/1 to switch to the Kernal and Basic ROMs, you have to patch Vice's Kernal file on disk in order to have an effect. If you want to do it on real hardware you would have to replace the Kernal ROM with an EPROM.
the problem with that opening shot with the snow blower, is that because you're in Canada, that doesn't really help the viewer pin down what time of the year it is
True. It's definitely not mid-summer, so you're left with a narrow 49-week window.
@@8_Bit hee, hee :-)
love your videos - best place to come for C64 development lore
11:20 - A quarter of a kilobyte eh? I know you Canadians mix Imperial and Metric, but that's getting ridiculous! Also, I don't know if we got ripped off but when we bought our new 64C (with new 1541-II disk drive) in ~1988 in Australia, I'm pretty certain it did not come with GEOS. It came with some educational games (that I wish I could remember as they were fun). Perhaps there was a different release here?
Yeah, it may have only been a North American thing for GEOS to be bundled with the 64C. I've had some viewers from the EU say their 64C didn't include GEOS either. But the inclusion of GEOS with at least some 64C computers was clearly the motivation behind the 2nd edition of Mapping.
In germany the C64 C with board revision E was released together with Geos and the 1541-II. An advanced edition included the mouse and 1084s.
Must have been end 80s max beginning 90s when Amiga took over over here.
First time i hear of geos. Stil don't know what it is. I had 8 games.... snare and nightbreed
@@valentinoKun GEOS is a graphical operating system for the C64. I show a little bit of it in this video at about 6:30: ua-cam.com/video/88cJVoESSps/v-deo.html
I bought the c64c and the diskdrive and it didnt include geos.
It probably varied from country to country. USA, Canada, and Germany got the "free" GEOS included it seems, and I've now heard UK and Australia didn't. But its inclusion at least in the USA was the reason they expanded the "& 64C" edition of Mapping to include GEOS.
Can you keep up with the Commodore ?
Commodore distributed GEOS with the C64c in North America. I don't think it was bundled with any C64 or C64c in Europe
Correct. I had a c64c but it came with almost nothing by default I purchased a 1541ii a year of one or two later
Aha, makes sense especially in the UK. I could imagine them including GEOS in Germany?
A friend of mine got a 64C and I tried to copy his GEOS. Epic fail, thanks a lot early DRM. Didn't know until recently that GEOS on its first run saved some information about the machine it's first booted on to a weird uncopyable spot on the disk which basically locked it to ONE machine.
I eventually bought a legit copy (pretty pricey at the time like 65 or so dollars) and put out some really nice term papers that looked as good as or better than some of my classmates using Apple or IBM.
Yes. That's right. I live in Norway, and I got my C64c for christmas in 1986 and it only came with the default cables and user manual. But it DID have the PETSCII characters printed on the side of the keys, like the original breadbin. My other C64c that I bought last year has them printed on the top of the keys.
19:53 $94
C3PO "This location is used by the serial output routines to indicate that a character has been placed in the output buffer and is waiting to be sent."
Is that a reference to Star Wars? Because C3PO would not stop chattering, and always had some characters in his output buffer?
Not interested in old patreon content. Wouldn’t even click on it if you would mention it in the title.
Why?
Why?