Writing 6502 Assembly on a Commodore 64 using the Macro Assembler Development System. Part 1.
Вставка
- Опубліковано 27 сер 2024
- Writing Assembly Language on a Commodore 64 using the Macro Assembler Development System.
* Basic Overview of the tools on the disk.
* Creating, Assembling, Loading and Saving a simple assembler language program that sets the border, screen and cursor color.
![Programming Like It's 1979: 6502 Assembly language on the Apple ][](http://i.ytimg.com/vi/PNOj6GTzfGY/mqdefault.jpg)
I started a 45 year programming career doing assembler on a Commodore Pet, a brilliant machine at the time because it has a CPM OS inside it. I am retiring in September this year (2023) at age 70. Still programming even now.
I started 30+ years ago with BASIC on a TI 99/4A (cassette tapes and RF modulator connected to a TV). I soon learned 6502 assembly on an Apple ][ clone, and Turbo Pascal on on CP/M. Got paid during the 90s writing RPG/II and RPG/III on S/36 and AS/400. I'm mostly using C/C++ now. My son is following my footsteps. He's always trying to make me use modern languages like Go and Rust, but I always countered with the story about old dogs and new tricks. What's your language of choice?
@@TheanHooYew I've been doing mainly react and microsoft MVC the last 5 years, with a lot of C#. I really look forward to retiring now though. Had enough of the constant change.
The Pet... 6502.... CP/M... 8080 ???????
Keep on tinkering, it keeps your mind young. ;)
Do you miss hitting the hardware directly (and having full control of everything) without having to go through all those layers in modern OSes?
I wrote my own assembler/editor back then. It was no pain - it was fun. With that tool I could write my software to DNA analysis. Yes DNA sequencing was manual work then and a few hundred bases per run. C64 and Apple IIe (also 65xx) later for reading the gels. Pionering times it was. Miss it a lot. And then maybe not.
👍👍👍👍👍👍
This brings back a lot of memories of doing assembly language in college.
How refreshing that your computer doesn't run crap in the background.
Man, tools for programming the C64 have greatly improved since then, such as CBM Studio and many others. I can't imagine trying to create a complex game using this set of tools back in the day! And systems like the Atari 2600 had it even worse. Luckily that system (and many other retro systems) also has numerous new and powerful programming tools to aide the programmer.
One of the best assembler/monitor nowadays for the C64 is Turbo Macro Pro (TMP). With an REU memory expansion unit it can stay resident while writing and testing code.
@@BillAnt TMP hasn't been updated in a while but it does seem to be the assembler of choice nowadays (Robin from "8 Bit Show & Tell" uses it extensively on his channel - which I highly recommend if you're into this sort of thing).
@@JustWasted3HoursHere - Indeed, I got sick and tired of having to reload an assembler every time I test my code. A resident assembler/monitor makes code testing so much quicker and fun. :)
@@BillAnt Without any sort of fast load feature I can imagine that this process would be nerve-wracking, especially if the bug is just a single line of code.
@@JustWasted3HoursHere - Yup!
I wrote my first assembly language program with the macro assembler. First Machine language program I wrote with a machine language monitor (Which I seem to recall having made a new version which was moved in memory so it could coincide with other memory locations). I remember spending one weekend in which I converted the ML monitor code (Which was a Basic extender) to the assembler code.
This video contains excellent content and is very well presented. Thank you very much!
seriously, it's fantastic ! the true retro experience !
It was 1984 for me 😅, and the drive didn't feel slow. I was coming from using the KIM-1 at school.
What almost everyone forgets to tell in these tutorials is how to save the program with the 10 SYS 49152 line included so one could start it with RUN.
I always wondered when I was younger why some programs were SYS 49152 and others just ran automaticaly.
I remember doing this in 1985 with a BW TV. It was hell.
I may be recalling incorrectly, I seem to recall the Vic20 having the 6502 and the 64 having the 6510 processor. Incidentally, I did a deal of assembly programming for the 64 using a basic program
I used to write assembly on the Atari 8 bits 6502. Was really cool to see how similar. Of course the memory maps are different, but assembly is assembly.
680x0 here. Way back in the early 90’s.
@@roygalaasen Amiga and ST. I remember them well, especially the Amiga.
@@ChrisM541 especially the Amiga 😄 I was expecting someone to mention the Atari.
Regarding the processor itself, I have seen it used in everything from elevators to massive Xerox colour laser printers.
I found the PAL assembler at a thrift store around 1995, and still use it today. The source files are BASIC files too, no special editor needed. I can assemble to memory, test, tweak, reassemble and so on, until I botch something that requires a reboot.
I remember buying Brad Templeton's PAL assembler back in the 80's for a good pile of money, but it was pretty sweet. I was part way through writing my own version of 'spacewar' when a friend showed me a full featured version he downloaded from a BBS. The wind went out of my sails, and I never finished it. LOL
@@pssthpok PAL was the best $15 I ever spent. Still clinging to that childhood yearning to "make a game", but with adult eyes. No matter what, someone out there can do it better. It is quite easy to get discouraged and sidetracked. My sympathies for your younger self.
In those days my friends at school wrote assembler with a pencil and assembled it with a mostek or Z80 reference card and another pencil.
A pencil? Luxury.
I would have killed for this software when I was 13!
Yeah I too didn’t know that assembler existed until 1990 i preprogrammed everything on a monitor cartridge for C64 and debug for XT 😂. When we learned C I saw that the intermediary step was assembly and it called tasm. As of that moment I solely used assemblers and I wrote one for the Z80 that were had to code in machine language in college. After one day do going through the mnemonics table to get the opcodes and operants I knew it was time to quickly hack a Z80 assembler in C 😂
I bought mine at Toys R Us for $15 in 1984. Not a lot...compared to $250 for the 1541.
This brings me back over 40 years. I followed it all! I don't remember the name of my PET and C64 assembler but it was amazing. Power?
I love this old school stuff! Would be great if you would share the rest your social media links
Damn he has more views on a single introductory video on C64 assembly than I have in total of my 10 lesson 😂
Wow super
That's a lot of work. Guess the Yves Han assembler was pretty good by the standards of the time.
6502-era keyboards were the best.
This is absolutely horrific. I'm happy to have fancy shmancy things like Notepad and .BAT scrips 😅
Thanks for sharing!
It truly was the dark ages of coding
Too much time has past for my memory to be complete, but I do recall a lot of anomolies with opening/closing 1541 disk channels related to SEQ or REL files never closing the command channels afterward seemingly because those file types allowed some kind of real-time append, but not overwrite. Some of the C-64 Database programs of the time would leave the channel open to allow DB updates to SEQ without additional delays in drive operation. I don't claim to know whether that has anything to do with this scenario, but when I was messing with BBS Databases, I OFTEN got not ready or flashing error when I was switching file types, or trying to commit incompatible changes to the different files involved.
The 1541 drive was a whole computer in itself with many undocumented commands. Nowadays it has been reversed and well documented, and even emulated with cycle accuracy on the Pi1541, including GCR read write using the ZoomFloppy adapter for the PC.
@@BillAnt If the new method doesn't go out of alignment, then it isn't 100%
@@MicrophonicFool - LOL
I LOVE C64 ❤❤❤❤❤❤❤❤❤
An assembler? You were lucky. My first 6502 experience was at school on a Commodore PET in the 1970s. My "assembler" was sheets of graph paper transforming machine code into hex bytes to be dumped into memory. And, Jesus weren't cassette tapes slow and unreliable for storing data.
I had to do it on the KIM-1 in school, so this program was the first I bought for the '64 once I had a disc drive.
Interesting for historical reasons but seriously, Turbo Macro Pro was (and still is) the best native way to develop assembly programs in C64. it's just way easier than this in all aspects.
Disk i/o would be interesting and not really too involved to show... Maybe build on that to allow for a disk paging system...
I've been using the LADS assembler since I was a kid. I thought the way it worked was strange, using the BASIC editor to write source. Now I realize it was actually just following its predecessor!
P.S. I wonder if PUT "@0:HELLO.ASM" would have removed the need to scratch first?
I tried that command, and it does work (which is awesome).
As a kid though (And this was a longggggg time ago and this maybe incorrect), I remember avoiding that command with the SAVE from BASIC because of rumors of a bug with it where it could potentially corrupt the file. Not sure if that was a real bug or just 'urban nerd myth'.
Cool
If anyone knows where you can change the screen defaults in the rom please post it here.
I did a ton of C64 6502 programming using almost exactly the same processes. I used the Merlin 64 assembler, though. I can't for the life of me recall if I had to do the "scratch the existing file before saving out the new version", but the notion of having to do that totally frightens me now (specifically, the situation I would be in if I'd scratched the source file and the C64 lost power before the new version was written to disk).
Is there a "rename file" disk command? Because it seems like it would be much safer to rename the current version of HELLO.ASM to something else (HELLO-OLD.ASM?), then write the new HELLO.ASM, than it would be to have that period of time where you've deleted the only copy of your source code and have yet to write out a new version from the computer's memory.
Thanks for taking the time to reply, much appreciated.
Yes, there is a rename command in the Dos Wedge. It's @R:newname=oldname. For safety, that would definitely be one really good way to go. I've been playing around with this assembler the last few days and I found myself saving files with names like 1.asm, 2.asm 3.asm.... and then removing the older versions every so often.
I can't imagine how tedious it must have been to write code for an actual serious program with this package back in the day. The write code/assemble/load/test loop just takes so long.
I may have to check out Merlin 64. I've not heard of that package before. I just took a brief look at the PDF manual via Google and it is very interesting to me. It seems to have been released in 1984 and needs just a C64 and a Disk Drive.
Hi, your keyboard, is it red switches ?
Thx for the video !
They are indeed Cherry MX Red Switches.
The one thing I would love to know is who is the engineer that picked the blue on blue color scheme for the boot up screen. Must have been a sadist. Why not something like high contrast black and white blue and white black and blue something better than blue on blue.
😄, yeah for me every reset was followed by CTL-2 (white text), should have been in the ROM.
Lets do something more substantial... Everyone does that border change and hello, world...maybe show how to convert 16 bit integer into pet sci for display...?
Many years ago I thought assembly was the wa y to gol It's not.l
Overriding by @:
I don't understand, why would somebody go trough all the pain, to write asm in a such way?
Cross-compilation "wheel" have been discovered long ago even before c64 was actually used in that painful way.
I wish I understood this question, but I'm pretty sure I can guess the answer from context; When you only have one computer, you do everything on that one computer.
@@bozimmerman While such scenario is highly possible in 80s, now everybody uses multiple computers - starting with a smartphone and finishing with some PC.
On the video is obvious that you don't even use an actual c64 rather an emulator, so don't play dumb pretending that real c64 is the only thing that you use.
Agreed. At the company I worked, we cross-assembled for C64 and C128 development on a PC using Avocet tools. It’s been so long ago now I can’t recall the process I used to get the binary onto the Commodore for testing. But it was far less painful than what I just watched 😮
He's showing you one method of how it was done...then, not now. Using an emulator doesn't detract from showing us the coding process used then. Yes, back in the day many studios programmed on one machine and sent the code to another. No one compiled for the 6502/10 (or Z80, 680xx etc) when programming in assembly programming back then - the binary generation process then, and now, is called assembling (using an assembler). Games(!!) programmers then would never use a compiled language to generate machine code (for these 8 and 16-bit systems), they hand-wrote every line in assembly because they were pretty much all experts in the processor's instruction set. That, and the fact max speed and smallest program size were crucial.
It's vastly different today where compilers have gotten pretty good. They're still not perfect, and again, it's not uncommon for studios to include hand-written assembly, particularly where maximum speed is important. Unfortunately, expertise in assembly is rapidly being lost, and programming, in general, is being abstracted away.
@@ChrisM541 I understand that. But the way it is done in the video is very slow and inefficient- thus thus the metaphor of pain!
It is much easier and faster to write and compile on PC using contemporary editors and assemblers for 6502. Not to mention that using emus like VICE allows you to even debug.
Even if you write on c64, there are much better tools. That Macro Assembler Development System seems quite primitive.