Jim Butterfield's Machine Language for the Commodore 64, 128.. Revised
Вставка
- Опубліковано 28 тра 2024
- Continuing on with the "Book Club" series, it's Jim Butterfield's classic tutorial on machine language for Commodore computers.
To support 8-Bit Show And Tell:
Become a patron: / 8bitshowandtell
One-time donation: paypal.me/8BitShowAndTell
The original Machine Language for the Commodore 64
archive.org/details/Machine_L...
Revised Edition:
archive.org/details/Machine_L...
End credits music by bedfordlevelexperiment.bandca...
Index
0:00 About the books, Contents
4:45 Note to Readers, Preface, Introduction
8:42 Chapter 1: First Concepts
12:20 Chapter 2: Controlling Output
17:20 Chapter 3: Flags, Logic, and Input
20:54 Chapter 4: Numbers, Arithmetic, and Subroutines
21:39 Chapter 5: Address Modes
23:17 Chapter 6: Linking BASIC and Machine Language
25:26 Chapter 7: Stack, USR, Interrupt, and Wedge
27:04 Chapter 8: Timing, Input/Output, and Conclusion
31:05 Appendices
36:45 Conclusion
38:01 Thanks to my patrons! - Наука та технологія
I'm 40 years late to this party, but here I am: running the C64 core on my new MEGA65, started up SuperMon+64, and with my printed and spiral bound ML for CBM by Jim Butterfield working my way through learning some ML. Something that I did not understood back in the days.
Since I grew up with MSX/Microsoft, the whole concept of the CBM machines (and the lovely unique keyboard) is new to me. Having a brand new "CBM" machine in the form of the MEGA65, and putting a lot of notes in my printed ML book, I think I'm close to the feeling most of you had 30-40 years back. I love it, and these excellent videos help me a lot in understanding all that new (to me) stuff! 😊
Thank you, I had the Machine Language book myself. I had the honor of knowing Jim Butterfield, he helped us start our Pet User Group. 6502 was my start of a 40 year career as a software engineer. RIP Jim Butterfield.
After I got my Commodore 128 in 1987, I spent about a year writing in BASIC, but really wanted to learn ML after reading some of Jim's columns in Compute!'s Gazette. Came across this book at a B. Dalton bookstore, along with the C128 Programmer's Reference Guide, on clearance for a few bucks each, and snatched them up. This book was a fantastic, gentle introduction to ML programming, that was perfect for a 12 year old beginner like me who had no prior experience with any low-level programming. Something really special to me about Jim is that when I ran into him on Quantum Link one evening and asked him advice about some ML I was writing, he patiently and thoroughly worked through my routine with me, and followed up with me some days later to ask how my project turned out.
My copy was signed by Jim at one of the Chicago Expo's. Bil Herd and Dave Haynie signed my C128D. Jim was a total rock star!
I had that book! The original, and I think it went with my C64 when I sold it. That book is GOLD.
And yes, I do regret selling the C64 now.
When I was in 7th or 8th grade, my family had a Commodore PET. I loved programming on it, and at one point was trying to get something to work from an article in Compute! It was for part of a school project and I don't remember if his number was published or we were able to get it from information, but I called him up and explained the situation and he chatted with me for around 30 minutes and thoroughly explained everything. I don't remember the conversation, nor what the article was about or what I was stuck on, but was left with the impression that Jim was a genuinely nice, genial, generous guy who went out of his way one evening to explain things to a curious kid. And I, being enamored with all things computer at the time, felt like I'd met royalty. Somewhere I may still have a picture from some magazine of Jim with one of his cats, which I had taped to the side of the PET for some years. I still have the PET.
ooh, cool! my dad used to know Jim back in the day when he was a software librarian in TPUG. it’s always really cool to see Jim mentioned and then remember all my dad’s stories about TPUG and about Jim!
To me, this is THE book to start with if you have no machine or assembly experience. I’m fortunate to have found a paper copy some months ago.
I might find a little pdf of this and have a look.
I just wanna learn programming in a way that came before everything got really convoluted and complicated having to support constantly updating platforms and services as you're going and the like. Just want the real basics that will hopefully help me to understand what the hell this is all about, and in a way I can likely take forward into learning programming on modern systems.
I presume I could run some kind of C64 emulator and go through the machine language stuff (that's just another way of saying code, right?) on my PC emulating the C64 and typing the code directly into it via my PC keyboard, assuming that's how this stuff works (I don't own an actual C64, so that's not an option)?
@@inceptional That's a good free option to start for sure
I hung out with JB a few times back in the day. I was in high school (85) and had a computer teacher who was originally from Toronto was was good friends with JB. JB was one of the smartest people I have ever met.
Yes, very smart and even more importantly, an excellent teacher who knew how to communicate. I got to meet him in his later years in the 2000s at TPUG meetings in Toronto and also in Chicago when he travelled to be at our computer shows there.
It's weird seeing a review on book I read when I was fourteen (in 1984). Reminds me how old I am and how much I've forgotten about my first love - the C-64 :)
Love watching your videos but over 30 years ago at college I had to learn machine language on a BBC Micro whilst doing my electrical and electronic engineering qualification and I really struggled to understand it. Just watching you go through that book makes me realise I would never have been able to get to grips with 6502 machine language EVER. I take my hat off to you - a very clever guy! Thanks for the videos.
Watching this I,* painfully*, realize that having the physical book is so, *so* much more convenient than reading the scans of a tablet or PC. Browsing to and fro to appendices etc. is a digital punishment. You're a lucky man to own the original books, Robin! :)
The simplest example that illustrates the concept: The Secret Life of Machines. Great way to teach.
This book is how I learned programming fifteen years ago, as an adult, after countless failed attempts at learning C/C++/Java from other sources. I'm an engineer thanks to it!
That’s so cool! To me C and C++ made sense and was a relief. But probably only because I’d hacked 6502/Z80 and 8086 assembler and pascal before we did C.
It’s an argument I made at a local college to start teaching assembler in first and perhaps even a second semester. Because we got interns that were not able to write efficient code. And most couldn’t do binary arithmatic. That school board said: “computers are fast now and who used binary these days?”
I said that I studied electrical engineering and that we had more IT (Z80, 8086 and C) in two years than these kids learn in 4 years.
I believe a school needs to teach concepts and you can build upon those concepts. And assembler is the most basic concept for software. One can go further and even say the digital logic; BSc computer science here in NL doesn’t even teach that anymore. Instead kids learn Java Spring for micro services and Python Flask. That’s too specific! Teach them the concepts of micro services and give them a task to complete. And allow them to select the technology to be used.
I couldn’t care less in what language and framework something is written when it matches my SMART criteria.
I suddenly remembered an argument we had with that school leading up to us meeting the board.
We had an intern (my now best friend) and I noticed that this kid, was really clever, his abstract thinking skills and math skills really outdo mine and he wanted to become a programmer. But college was not really his environment because he obviously is super gifted and bored shitless. So we suggested he would do a traded school IT which entails 1 day at school and 4 days at work.
And one of his school tasks was to design and assemble a system (yeah simplistic IKR!) So I gave him a task to specify, order and assemble a system for a customer running Navision. I gave him the customer requirements and gave him the best practices from Navision and basically let him figure it out. And write a quote that we can give to the customer to be signed and then procure and assemble it.
He gave me a quote and it said: 16GB, 2 CPU's, 4 spindles (whatever it was). And it was all correct according the guidelines but I asked him (what all my teachers asked in college: WHY?).
So I asked: "why 2 CPUs, Rene?"
-"It's twice as fast."
"Is it really?"
-"Yeah makes logic sense."
"Okay buddy, the specs are correct order the system and when it comes in you install and configure it and since you wanna become a programmer. Here's your first programming challenge. You will install a C compiler on there (visual studio is in the cupboard) write a C program that only loops forever without any other instructions in that loop."
-"Why? Thats useless"
-"I'm trying to make a point Rene."
So he did and it took him a few days of learning how to install, compile and link (all good stuff to learn and they don't teach that at schools!). And he was like
"huh? what the fuck?"
-"What is it Rene?"
"I created that program like you asked, I only get a black dos screen, that's fine. But the cpu load is only 90-95% on one CPU"
-"Exactly, now run a second instance of that same application."
"Hey now it's also running 90-95% on the second CPU! But why isn't it 100% loaded? And how does the operating system know where to assign these? As they do seem to jump around."
I was so proud on him (4 weeks into his internship) and I told him to figure that out. Put that in his report for school.
So he figured a lot out, not all correct and I showed him some stuff on Unix machines with SMP and pthreads.
And his report was good enough to hand in (based on what I had to write 20 years earlier).
His teacher found it too technical, too in-depth and too complex. And we were asked to come to school because we may not have the right idea of the technical dept. He graduated petty much after that (4 weeks in) just had to do his final project because they deemed it impossible to teach him something. And we stopped taking in interns after that. Because when you can't educated them to the same standard as we deemed is required for the job, then its useless. And these kids can do this! But education has just been dumbed down.
I might find a little pdf of this and have a look.
I just wanna learn programming in a way that came before everything got really convoluted and complicated having to support constantly updating platforms and services as you're going and the like. Just want the real basics that will hopefully help me to understand what the hell this is all about, and in a way I can likely take forward into learning programming on modern systems.
I presume I could run some kind of C64 emulator and go through this stuff on my PC emulating the C64?I presume I could run some kind of C64 emulator and go through the machine language stuff (that's just another way of saying code, right?) on my PC emulating the C64 and typing the code directly into it via my PC keyboard, assuming that's how this stuff works (I don't own an actual C64, so that's not an option)?
@@inceptional I did just that. Before going down that route, I had tried numerous C, C++ and Java tutorials. But with the VICE emulator, a monitor (which is a really rudimentary program to read and modify the memory of the C64) and this very pdf I learned the basic foundations of how a computer operates, which made further investigations into C a lot more comprehensible. The intimate understanding you get from starting with machine language is still useful to me, even when I work in high level languages.
And the hardest part of this all is installing VICE.
@@inceptional with that said, if what you want is to learn modern programming in general, there are probably more relevant routes to go today. But 15 years ago, this was the best route I could find.
Python and Javascript are two languages that are really easy to get started with. Check out p5js for instance!
I really like your videos, I have written a 6502 emulator in C because your videos rekindled my love for the C64 (which I owned from 83) and the 6502. Please keep them going, I really enjoy.
0:12 The "1" character on the cover of the first book sure looks like a "2"!
2:59 Jim was such a celebrity that I'm guessing the various publishers just let him do what he wanted.
7:10 The examples are probably pretty short and maybe not everyone had a full assembler system. Heck, I wrote a 17-kB program with an ML monitor before getting an assembler.
10:11 The PETs also had a VIA chip. The PIAs don't have a timer. The C64 also had two I/O registers bodged into its CPU.
12:42 My strategy to writing clear documentation is to write something so simple that even I could follow it.
16:03 You young whippersnappers! Why when I was you age, we had to program everything in ones and zeroes, and zeroes hadn't even been invented yet!
17:47 Well, the flags have multiple uses and Jim's only taking about comparisons. If you load a byte into a register, the ZERO flag will tell you if the byte was Zero. If you add two numbers, the CARRY flag tells you the arithmetic Carry digit. Granted, the flag names don't quite align with the Branching-instruction names.
19:06 I mostly use the 'V' flag with the BIT instruction to test the '64' bit. It's pretty rare to use signed integers in this environment. You can also use CLV:BVC as an unconditional branch that rarely interferes with your program.
21:07 There are a lot of broken programs out there that are stuck using 32-bit integers in a 64-bit world because the programmers and compilers got too specific about their word sizes.
32:19 I always use Jim's memory maps from The Transactor as my first reference.
The names of the flags and corresponding branching instructions are less of a problem when keeping in mind that a comparison is actually a subtraction of the addressed operand from the register:
Z - Branch on EQual to zero: If the result of the subtraction is zero, both register value and operand are equal.
C - BCS: If the subtraction results in the carry flag set, the register value must be greater than or equal to the operand, otherwise the carry flag would be cleared.
N - BMI: Makes sense when keeping in mind that negative numbers are represented as two's complements, which always have the most significant bit set. (But it does indeed depend on the context if a value should be seen as a two's complement.)
I just did a quick search for these 2 books on ebay and amazon.
$150 for the first and $300(!) for the latter.
I personally prefer this kind of litterature in physical, tactile, paperback form rather than a digital pdf or whatever...
But with ridiculous prices like that for second hand copies - not gonna happen.
Wish they'd just do another print run of it.
I don't even own a C64 anymore but I'd still buy it just for the knowledge and memories of coding back in the 80's.
Thanks for the nice overview!
But you can get the PDF and head to a copy shop. You can get it spiral bound too. Sure, it's not like the real book, but it's better than reading the pdf on a screen.
I had the second revised edition of the book, even though I never had a C128D. I got it from my friend who had just purchased a new IBM 286 PC and sold his 128. But he gave me all his books and C64 games. Looking back, I wish I would have bought the 128D from him as he only sold it for 175 dollars Canadian.
I STILL have that book (the C128 version). It sits on my bookshelf today. I have a row dedicated to nostalgic books from my youth that I just could never part ways with even though I have no practical use for them. Just looking at that row of books brings back my original excitement with computing and puts a smile on my face and in my mind.
The honest comment about C# web programming was enough for me giving you my "like". 😂😂😂
I love the book reviews! I recently got this book because of your video. I love the humour: "Indeed, most programmers lead full, rich lives without ever writing code that uses indexed, indirect addressing."
many hours playing Warlock of fire top mountain and BattleCars with friends back in the mid 80s
When i was a kid I wrote Jim Butterfield a letter asking how to free up more memory in the C64. He wrote me back(!) and detailed how to copy upper rom data into ram and then how to swith the rom to ram and that added 4k (if I remember correctly) - I used the information for a project where I created new c64 BASIC commands to perform 'turtle graphics' - I added BASIC commands to turn hi-res mode on and off, and to move the turtle and draw as it went. My opus project around the age of 13! I wish I still had the letter from Jim, sadly it got lost during life... 😐
About the status register flags, the B and unused flag is in fact a bit special in that a PHP or BRK will always push these as set onto the stack, but when pulling them off the stack and setting the status register using PLP or RTI these both bits will not be used (so the processor status flags for both of these remain the same as before). When an IRQ or NMI happens both B and unused will be always zero on the stack. So its possible to check whether an IRQ or a BRK happened by reading the B flag of the processor register that was stored on the stack. Since both IRQ/BRK uses the same vector at $fffe, this is the only way to know which one triggered and is indeed what the Kernal code does too in the default code that is called on those events (at $ff48). So it jumpt through the vector at $0316 if a BRK happened and at $0314 if an IRQ happened. Ofc a BRK then ends up triggering the routine at $fe66 which is the same that is done when RUN/STOP+RESTORE is pressed.
I love this book. I have it and have added tabs to the pages and wrote in almost all the pages. This is why I know ML. I only wish he had covered assemblers. Its great tho. Anyone who wants to know ML get it!
Yes, I wish he had written a sequel to this book that got into assemblers.
I’m currently in a Python class. I am also working with my oldest on learning basic on my Vic 20 and Atari 800XL.
Nice to see someone else who is curious not only about his writings, but Jim himself. Thanks for this video.
Even if I am not an english native speaker, this book is so good and easy to understand! It's even better than any other books about C64 assembler in my language! Thanks for the info about it!
Oh now I need to read this after seeing the title of Appendix G... I learned so much from Transactor magazine and Mr. Butterfield back in the day.
This video was very helpful to me in introducing me to this book, thank you!
I ran over to the Archive and got it right away. This looks like much of it might be applicable to other CPU instruction sets as well!
Wonderful. When learning about coding for the C64 gets us inspired to do so many things and learn to appreciate C/C++(and other higher level languages) more. A C64 programming phase should not be overlooked for inspirational purposes.
Jim Butterfield toured and spoke at shows and conventions as well. I met him in 88 and 89 at the Commodore Association South East (CASE) show in Nashville. Class act and also was willing to chat with folks via email on QuantumLink. I'd be surprised if he didn't make a fair bit of money touring and speaking.
I used to have the first edition. I wish I still had my copy. Used it to write my own assembling monitor for my vic20.
Learning how things are layed out in memory... having gone from poking things into ram using basic, to a simple monitor (supermon, jay), to a better monitor (fc3) to a real assembler to a cross assembler... I still mentally keep track of how many bytes I am using, and in many cases have at least some idea of the cycle count of what I wrote. But.. on a system with limited ram and cycles its much more needed to know those things.
Oh, he wrote Unicopy? A very useful program ro use with strange floppy drives on unusual commodore computers! Helped me greatly with the 1581.
**Uncrashing** - _It's best to write a program that doesn't fail (or "crash"). Not all of us succeed in doing this_ ❤ that hint could have saved me so much time 🤣 also, understatement of the century 😄👍
Superb video! And yes, I have always found the more machine like languages to be easier on the mind.
I'm currently working through this to learn machine language/a bit of assembly
I actually met Jim on a bus going to a local computer show back in the day. I believe Jim lived in Toronto (at least at the time)
We had a nice chat which was cool as I was quite young at the time
I was spoiled by Borland's Turbo Debugger for DOS(8086). I just love that progam.
Wow this book seems incredible. I love good programming books, I every tried writing my own once. I am a student at the University of Cincinnati and we have a very decent collection of computing books (unsure how our collection compares to other universities), if you are looking for a book you can't find I could check to see if I have access.
I just started going through this book a few weeks ago, and the code all runs and much better written than most of modern programming books.
Great content, as always.
"Boooo" for the comment at 16:37. (I'm a COBOL programmer in my day job.) But otherwise another excellent video. 😀 I'm going to get this book and read it as soon as I can. It looks interesting. Thanks.
Yeah, I did COBOL at college and Polytechnic, and liked it. I later got a job writing it for a large car company. If the COBOL stops running, so do the cars, as it would stop production. Many things still rely on it.
No disrespect meant; I did take COBOL in university and I'm still a little sore from it. Uh, 28 years later? Eventually I'll recover.
@@8_Bit I get the dislike for COBOL, but the pandemic has proved that it is a vital skill that is still in demand.
"Except maybe COBOL", LOL
I had to learn the basics of COBOL for my first programming course when I was 17 in '98 or '99. It's a weird language, but what do you expect from a language first developed in 1959? But hey. If you get good at it you can still find jobs (usually at banks and other financial institutions) with starting salaries in the ballpark of $200k a year. It only goes up from there and once you're a few years in you become "irreplaceable" to the company because finding and training a replacement will cost more than it would to keep you on until retirement. Demanding a raise is pretty simple, too. My instructor back then talked about how it was common practice for COBOL programmers to write spaghetti code that was indecipherable to anyone but the person who wrote it meaning if they didn't get the raise they wanted they could call the company's bluff and quit on the spot only to get a call a couple weeks later begging them to come back when nobody could make heads or tales of the code.
That is if you can stomach working with COBOL. It's pretty soul destroying.
@@Darxide23 Respectfully, I disagree. First, COBOL has been upgraded approximately every 10 years up to this current day, the last update was 2013 working committee. It includes OOP and other modern features. While it is wordy, COBOL has abilities not implemented in most C based languages. It is extremely streamlined given it's power.
Don't get me wrong, it's not for everybody and it's not for every job. It's much more accurate for decimal computation for things like money (not necessarily floating-point: that's not quite the same). This is especially true on the 360-390 series of mainframes because COBOL compiles directly to the machine language equivalent. Also, if the 3270 or 5250 terminals are being used (either actual hardware or software emulation) access to the terminal is actually done by using assembly language to describe the screen and COBOL to handle the program processing through various subsystems like CICS, which can manage THOUSANDS of simultaneous users.
When you needed math processing on mainframes people used FORTRAN - but after C came along, it was a good replacement.
On microcomputers or client/server applications, it's usually better to use a more controlled language like C based languages or Pascal/Modula. Some other languages are better for other more specific tasks. BASIC was designed to be a learning language. It wasn't perfect, but people flocked to it by the thousands.
For me, a CS instructor at university, what's soul-destroying is the fact that students can't be troubled to follow best practices of structured programming when I teach recursion... :-)
What makes these books sound even more antiquated than they are is the term machine "language" vs code or assembler. Early 80s af.
Machine language is still a helpful term to help distinguish between different things:
Machine code is just numbers like hex or binary: a9 06
Machine language uses mnemonic opcodes such as: lda #6
Assembly language allows symbolic labels: lda #blue
Butterfield explains in the book that he's deliberately teaching machine language, and the resulting machine code, to give the student a good grounding in memory use before moving on to assembly language. In a machine language monitor for the C64, you can use the M command to get a hex dump of memory, or the D command to disassemble to machine language, but they of course won't display true assembly language which would be the source file originally used to write the program (complete with labels, comments, and other pseudo-ops).
Judging by the covers of those two books, 0 was two timing 1 & 2
+1 for old man rant at 15:30
Here in UA-cam there is a training tape by him, that maybe also based on his 2 day training: ua-cam.com/video/J9WnHuGjZ38/v-deo.html
That 2 hour training tape is really cool, but he barely gets into machine language at all in it; it's more about general use of the C64 and has very little programming in it.
That was great, thanks! On a tangential topic, I was wondering if you had any thoughts and experience with the merlin64 assembler. It has a nice set of integrated features in a single package.
Merlin was actually my first assembler, the first one I remember seeing for sale in a store too, and that wasn't until around 1989! Before then I had just used SuperMon for everything. Merlin was pretty great; I used it until around 1995 when I discovered Turbo Assembler and then I switched to that, as it was even faster and more convenient.
Cool. I'm starting to get into C64 stuff again. 😎
*6:40* _I really felt that!_ 😢
Is that about having a C64 but no assembler or machine code monitor, while trying to understand the ML chapter in the Programmer's Reference Guide? Very painful!
@@8_Bit _Essentially, except I had a VIC. The 64 was still on the drawing board. The literature touted Assembler, but I had nothing to go on._
@@8_Bit I am currently learning ML without assembler or monitor (yet): I have alternating REM and DATA lines, where in the REM lines I write the assembler code and in the DATA lines I assemble them by hand. For little programs it works. ;-) I don't find the ML chapter in the P'sRG very helpful though - it lacks lots of information you need as a beginner.
The great course
That is pretty interesting, what he says about the different kinds of subroutine call commands:
Gosub: BASIC --|> BASIC
Sys: BASIC --|> ML
JSR: ML --|> ML
So that puts the SYS(tem) command as the liaison between BASIC and ML. Kind of cool to think about it in this way. But what about if there were a way to do this:
BSR: ML --|> BASIC (an ML program calling a BASIC subroutine via the ML address that contains the interpreter's lead to the BASIC line number wanted as the start of the basic subroutine)?
"Learn it all! (Except maybe COBOL.)" Haha!
Hi - Pretty good, first computer was a C64 and the usual type of basic.
I personally never went past Basic ( GW then Quick basic ) / Cobol / Pascal on the IBM, Pascal i eventually went to turbo Pascal 5.5 and 6 and had a collection of assembler routines that i used like external calls / overlays
I actually found Amiga500 basic a bit confusing
When you mentioned old man rant, i am reminded of the old joke
Yong bull and old bull see some cows, young bull advises he wants to run over and do a cow or 2
the old bull says , No take you time and we both will walk over and we will do them all
Regards
George
Commodore memory maps of machines possessing more than 64K including the B-Series, The C128, and any instance when memory expansion carts can get very complicated. It wasn't a walk in the park for the VIC 20 either.
If I can ever get my hands on a "The C64" this might be fun to pickup and run thru
Whoa, so the way we got the first ML monitor/assembler for the Commodore 64 was that Jim made the whole thing in BASIC, and then saved that to a disk, from which he then had installed into chips at a fab house, or at least burned onto a PROM?
So you're saying that plugging in the cartridge can automatically run a BASIC program? How did that part work?
And from there, how would they either burn it onto a PROM or etch/layer it at a fab house?
And the whole time this monitor is running in BASIC, it's showing memory values using a bunch of peek commands and using BASIC's hex/dec converters? And how would it have been fast enough?
And when Commodore didn't want to include a monitor in the 64, then why didn't they just include one on a tape with the 64 or on one of the disks that came with the 1541, or at least in printed form in the programmers' guide?
Would you consider doing a video on other programming languages on the C64/128? Assuming there are other languages, of course.
I've done videos looking at LOGO and COBOL for the C64. I'll probably do some more in the future too.
It's funny but I just came across my old "Vic20 Interfacing Blue Book" which contains both basic and asymbler programs plus hardware schematics etc. 😀
Hi Robin! Thanks for an interesting video as always!
35:25 nice, I'm at the point where I've got a C128, a 1084S, a dataset, a 1451 and some suitable blank discs and nothing else! I want to do some assembler.
I'm aware I could use the monitor or even basic to write an assembler. I've written a two pass assembler for another computer before, it wasn't very difficult but I did write it in perl.
Do you happen to know if the assemblers in the 8 bit home micro days were two pass? I wouldn't know where to start writing a one pass, but a two pass might be prohibitively slow...
I played around with mon for a little bit with and the way it shows branch offsets was confusing me no end. I think it calculates the effective address that will result after adding to the program counter and shows you that instead of the offset? I threw me at the time because it didn't match the books I was attempting to work from. But probably now I've had a think about what it was trying to tell me I would be fine...
Or maybe I'll type in supermon :v
Maybe
This I've tried. I don't know what's going on, but it seems to have issues (if you are referring to the Supermon type-in program included in Compute magazine, Issue #32 from 1983). That's why I'm here. Trying to grasp how to successfully run the checksum program (program 3). Looks like I have to reserve/relocate basic programming space as was performed for the Tiny Peeker/Poker (program 1), so it doesn't stomp all over the ML entered. Trying to understand the POKE 8192,0 / POKE 43,?? and POKE 44,?? parts.
@@CollinBaillie the old turd goes through my boxes like a crab at low tide, gobbling up what he likes (eg. Making fishing floats from my yoga gear and knitting needles) and just chucks the rest.
The _only_ reason it wasn't set up and I wasn't using it all the time was because the old dero colonised the desk I had for it. He tried to toss the keyboard tray which fitted the Commodore 128 perfectly not once but four times.
Hi Robin! I would be very interested in learning more about GEOS programming - I've learnt via the X16 project that GEOS provides an API and that development of new software is possible. If this is something you're interested in or would rather talk about how GEOS works in general? I'm all ears!
I’m using this book to learn machine language programming right now. Is there a more modern reference guide that divulge all the nooks and crannies of the C64 that have been discovered since then? I know Michael Steil et al maintain a website with comprehensive information but is there a book?
Unfortunately nobody has put together a new book to rival the old ones. As you note, there's fantastic information available online about all the new discoveries and techniques, but I'd love to see it brought together in a new book.
@@8_Bit By the way I love your channel! So informative and interesting.
I might find a little pdf of this and have a look.
I just wanna learn programming in a way that came before everything got really convoluted and complicated having to support constantly updating platforms and services as you're going and the like. Just want the real basics that will hopefully help me to understand what the hell this is all about, and in a way I can likely take forward into learning programming on modern systems.
I presume I could run some kind of C64 emulator and go through this stuff on my PC emulating the C64?I presume I could run some kind of C64 emulator and go through the machine language stuff (that's just another way of saying code, right?) on my PC emulating the C64 and typing the code directly into it via my PC keyboard, assuming that's how this stuff works (I don't own an actual C64, so that's not an option)?
"Except maybe COBOL". At least COBOL is an instructive example of how not to design a language. I have never felt like praising C's simplicity as much as I have after your COBOL episode.
What was so bad about C# if I can ask? I was considering learning it
C# as a language is fine; I generally enjoy using it with Unity for game development. But I did not enjoy using C# for web development where you've got C# running one place and Javascript running another and SQL elsewhere and it's all happening asynchronously. C# isn't the problem, it's all the different technologies that need to work together and all the repetitious pieces of code that need to connect everything. I find it tedious and generally not fun.
@@8_Bit Thanks for clarifying - I was wondering what you meant by that. I understand what you mean about web development. C# is one of the best languages out there in my opinion, though with later versions it is less declarative than it used to be which I dislike. And I thoroughly dislike the LINQ query syntax and recent async extensions. I favour the fluent interface approach which I find more intuitive. I would like to know more about your Unity development Robin, unless that is too many bits for this channel.
Does anybody know where to get the optional disk (or virtual disk image) of the book?
What sort of computer was used to program the Atari 2600 before they stored the code onto a chip either using a fab house or a PROM?
I'm sorry if you already answered this for me and I had forgotten.
is there a similar book to recommend for the Z80?
Rodnay Zaks has a Z80 book that's fairly good, but I don't know of any that matches Butterfield's tutorial style in this book.
What is the song playing in the credits?
It's called "An Obsequious Tear" by my band Bedford Level Experiment, but unfortunately I still haven't got around to releasing it! Here's a related song of ours though (a different mix of this song is meant to be on the same EP as "Obsequious"): ua-cam.com/video/U1VKwqUWYa8/v-deo.html
I might find a little pdf of this and have a look.
I just wanna learn programming in a way that came before everything got really convoluted and complicated having to support constantly updating platforms and services as you're going and the like. Just want the real basics that will hopefully help me to understand what the hell this is all about, and in a way I can likely take forward into learning programming on modern systems.
I presume I could run some kind of C64 emulator and go through the machine language stuff (that's just another way of saying code, right?) on my PC emulating the C64 and typing the code directly into it via my PC keyboard, assuming that's how this stuff works (I don't own an actual C64, so that's not an option)?
Hi, there's links in the video description to both editions of the book on archive.org and you can download pdfs from there. It's a great resource.
And yes, look for the VICE emulator which includes emulators for the C64 and other Commodore machines. Machine language is code, yes, specifically the low level code that the 6510 processor in the C64 directly runs. You can also program the C64 in the BASIC language which is much slower, but is easier to use and perhaps more friendly for beginners. Either way, it's a great thing to learn.
@@8_Bit OK, I've just started reading the book and this came up almost immediately "This book assumes you know a little about programming fundamentals: loops, branching, subroutines and decision making".
I really don't know any of these things, so where would I actually go back to as a starting point in order to know the most basic stuff I need to know to then understand the stuff the guy is going to be covering in this book?
Think of me as someone who literally knows nothing about programming or the fundamentals of a computer (other than the fact I use a PC for typing into Word and drawing in Photoshop, and at most trying to make some simple games in Game Maker Studio, along with maybe the most basic idea of some elements of a circuit I learned in high school over 30 years ago): What is step one that they might have taught to some kid at school back in the day, or that the kid learned on their own somehow, who had never done any of this stuff but saw a computer like the C64 and wanted to learn how to make games on it?
I want to understand things in a way the likes of John Carmack and Steve Wozniak and Manfred Trenz and Matthew Smith and so on did/do, presumably because they learnt from ground zero so they basically understand it all at a truly fundamental level and everything else is just another layer on top of or extension/evolution of that.
If only the COMMODORE C64 outputted data to the tape port as a SPDIF signal it could be saved to tapes using the PHILIPS DCC900 cassette deck via the associated SPDIF ports and also loaded from said cassette deck back into the tape port and converted back into data or machine code, The COMMODORE C128 includes a ZILOG Z80A processor so the assembler/disassembler for the COMMODORE C128 has to be able to handle 6510/Z80A machine code assembly language.
Assembly is more clear for simple tasks, as it is pure imperative style - no OOP/functional junk, no types, structs, or pointers.
I see butterfield i click
@@UC3gRBswFkuteshdwMZAQafQ : Where have you been? Also, I have a thought/idea which would be good to explore. I have heard repeatedly about the existence of "undocumented op codes." I have also heard that some projects have made use of them. I think it would be VERY interesting to explore these undocumented op codes, what they do and how they might be used. And more interesting would be a test to see how faithfully the emulators (theC64 or Vice) implement them.
For what it’s worth I believe Jim’s favourite colour was Beige.
I think so! He fully embraced the 1970s.
5:20
I thought for over 40 years that preface was pronounced pre(EI) face as a prefix in grammar
Thankyou for making me realise I'm a douche! Ha!
PS could you one day go over Amiga programming? Languages used? Especially the changes once the AGA chipset was introduced... I think it would be really interesting as it is the commercial progress of Commodore programmers
My Amiga experience really only extends to AmigaBASIC (which was fairly terrible!) and AMOS (which was pretty good!). I'd like to make videos about those someday, but I unfortunately don't have much to say about the AGA machines as I've never really used one.
Indeed assembly because you know you have to do everything yourself. And therefore it’s easy to start, it’s the grunt work that gets you. But take Java or C# or Python there’s a millions of libraries and ways of doing things; which also change with time and which management buzzword is not now. So you spend more time googling how to do certain things efficiently than to just building.
I find myself googling a hell of a lot more in modern languages and their plethora of frameworks then I do when writing assembler or C/C++ (without extra libraries).
That's what I like about platforms like C64 or DOS which are not developed anymore: What you learn now or have learnt 15 years ago will still apply 15 years in the future. And I am sure C64 and DOS emulators will be around in 15 years, but not so sure that emulators of current platforms will be around.
I wonder how many "lamers" this book created? a ton of us, I'm guessing...eh Robin?
SOB .. Start of basic.. 😁🤣
C# web dev eh?
Well... I tried :) I hope you're doing well!
@@8_Bit You did great! I'd be better if I would have clicked the stupid bell. I have some catching up to do now. I hope things are good on your end. :)
"Learn it all! ... Except maybe COBOL." Genuinely laughed hard at this one. I learned COBOL in University and confirm it is a waste of time unless you want job security in the financial IBM world.
I learned COBOL in 1999 and since then I've been working with mainframes. I'd say it is safe because banks have millions of lines of code and they need constant maintenance (last week I was making changes on a 1974 cobol program). But I dont recommend learning COBOL. Working on legacy systems is very stressfull and I wish I had taken the Java route.
@@marciomaiajr Exactly, I've heard the same thing from many COBOL programmers. At least thee job security is there, but yea, can't imagine doing it fulltime.
What??? There’s no section on NOP sleds?!? No book on assembler is complete without at least a mention of NOP sleds! 🤗 I’ll have to give that book a thumbs-sideways. Meh. 😆😝😂
Is there any use case other than intruding systems?
I too find Butterfield an exciting figure. Wish there was more info about his career.
I’m a proud owner of one of the original books. I imagine his voice when I read it.