Wow, I wish this video was available when I was a kid trying to learn Assembly on Commodore 64... back then it was too complicated, I just gave up and continued on regular BASIC programing...
I've got to agree with other comments on here, I wish I'd know about this back in the day. Your delivery on this subject was excellent, I've learn't so much as I followed along on my vice emulator. I'm now inspired to actually try writting some Assembly code, thank you. More guides please!!!
I had Machine Lightning, back in the day! I don't recall much about it, other than it was really easy to screw up the disk. Seems like it had commands that wrote directly to tracks/sectors. Thank goodness the first thing I did before I started playing with it was to back up the original.
I actually had this back in the day. I remember reading a review in a magazine that said it was the best assembler you could buy at the time. So i bought it. To be honest, alot of it was over my head at the time and i never used it to it's full potential. I ended up selling it along with one of my C64's and was never able to buy it again. Something i regretted later on. For most of my C64 coding i ended up using a ripped copy of Micro Assembler, which sat at $8000 in memory if i recall correctly and i would design my memory map around the assembler. Great memories. :)
I bought some C64 assembly book "back then" in the 80's. I tried to read it - I was under 15 years old - I had absolutely no idea what the hell it was supposed to mean
Are you a teacher IRL? Your setup works great for my teflon brain. Your different lessons on the C64 and the 6502 are actually makeing sense and in an engaging way. Thank you!
Thanks for the kind words, much appreciated. I'm not a teacher where I have a classroom of students every day. But as a part of my job, I do train my developers and support staff on various topics regularly via videos, in person meetings and webcam sessions.
6502! Haven't heard about that chip for a while 😅 Of course the BBC Micro that I "grew up" with used a 6502A. As BBC BASIC was so good (and advanced in those days) I never bothered to learn assembly language...
10:05 I have a real c64. Assy 250407. I have a kawari installed and it always comes back with F for the high nibble. I have also swapped in my original 6567R8 just in case but it also does the same. I think it it is pretty safe to say vic chips always return F for high nibble
I wonder how they implemented that trace command/single stepping in this and other old monitor programs. I'd have to guess they're parsing the next instruction and simulating the results on the registers/flags because executing them (and re-capturing control by temporarily inserting a BRK in the next instruction and capturing the interrupt) would let a jmp/jsr would take off and execute multiple instructions (unless they also temporarily put BRK's at the destination addresses???). Really neat feature and probably a pain in the ass to implement unless there's some simple way I'm overlooking.
The BRK technique you describe seems workable. I notice in the video that the trace does not step into the KERNAL routine. I would guess that it limits itself to tracing code that it has itself assembled, because it knows it can write to that memory (and can insert BRK statements into ROM). Monitors use BRK for everything, because it stashes register state and expects your interrupt handler to restore that state just before resuming, so it's easy for the utility to allow adjusting things like the program counter even while running on the machine. It's magic. :) I love the idea of using a machine code interpreter for debugging purposes, but if the BRK technique works I wonder if it's overkill. It too would have to be careful about system calls and KERNAL variables and such...
Very interesting video, but the software is SOOO primitive! For comparison Oric Atmos (another 6502 based) had: - Text editor - kinda E3 for DOS (to write the code) - Assembler ... like Apple II (probably Merlin) - no line numbers nonsense, 2 pass, max 38k per file, multi file, huge variables names (64 or 128) - Debugger - a real one, not like this toy in the video. It had a stunning UI for its time (imagine Borland Turbo vision interface), code displayed in scrollable boxes, break points, ... P.S. I dont remember all the features, but really it was revolutionary - kind-a of what you will see later in DOS era (90s). Keep in mind that 1986 that computer was no longer sold.
Pilfered from the internet due to my failing memory. Vector Technqiue: ========================= Make the load address of the file 02A7. Put some ML here that emulates a RUN command by calling rom routines, or poke in R U N into the keyboard buffer, or whatever. At address $0302 plug in the value A7, and at address $0303 plug in 02. When you save the file, start saving at address $02A7, end at the 3rd 00 00 00 in the normal basic address space ($0800). When the file is loaded ,8,1 it starts loading in data at 02A7 which is your autoboot code. When it reaches 0302 it overwrites that vector and re-directs control too your ML. When the file finishes loading, it executes your ML automatically
I want to learn more about the machines and software that was used so for assembler. Clearly, anyone writing serious software for the C64 now, like new games, etc. would use what you suggested but that doesn't mean that the information in this video is not valuable - without it I would never have even known about this assembler being used. I also think it is easier to learn and understand (at least for me) while actually working in the C64 environment itself.
@@phil2768i wasn't disparaging the work shown here, i loved the video. i just thought maybe someone should point out there are newer/easier ways of doing things. anyone new to c64 dev finding this video might not be aware of things like kickass.
@@furroy yes, I need to looked into using it myself to be fair. I'd heard about it a while ago, set it up with VS Code, but never got to really dabble with it properly.
It really depends what you are after. I started using the original hardware again for the nostalgic reason... and many do. 8 bit show and tell is also great content and on the actual machines. Another interesting thing is c64 os. Greg has been writing the whole os in tmp... on a c128. When I spoke with him about it he mentioned it all started with wanting to spend time on the machine... not somewhere else. For many it is about the trip down memory lane.
Wow, I wish this video was available when I was a kid trying to learn Assembly on Commodore 64... back then it was too complicated, I just gave up and continued on regular BASIC programing...
same here...
I've got to agree with other comments on here, I wish I'd know about this back in the day.
Your delivery on this subject was excellent, I've learn't so much as I followed along on my vice emulator.
I'm now inspired to actually try writting some Assembly code, thank you.
More guides please!!!
Thanks!! I'm glad you liked it. I've been quite busy this month, but I do have a couple of new interesting videos coming out soon.
I had Machine Lightning, back in the day! I don't recall much about it, other than it was really easy to screw up the disk. Seems like it had commands that wrote directly to tracks/sectors. Thank goodness the first thing I did before I started playing with it was to back up the original.
I wish I had known about Laser Genius back in the day. Seems very intuitive.
That is the best assembler I have ever seen. The trace part was the best
I actually had this back in the day.
I remember reading a review in a magazine that said it was the best assembler you could buy at the time.
So i bought it.
To be honest, alot of it was over my head at the time and i never used it to it's full potential.
I ended up selling it along with one of my C64's and was never able to buy it again.
Something i regretted later on.
For most of my C64 coding i ended up using a ripped copy of Micro Assembler, which sat at $8000 in memory if i recall correctly and i would design my memory map around the assembler.
Great memories. :)
I bought some C64 assembly book "back then" in the 80's. I tried to read it - I was under 15 years old - I had absolutely no idea what the hell it was supposed to mean
Are you a teacher IRL?
Your setup works great for my teflon brain.
Your different lessons on the C64 and the 6502 are actually makeing sense and in an engaging way.
Thank you!
Thanks for the kind words, much appreciated. I'm not a teacher where I have a classroom of students every day. But as a part of my job, I do train my developers and support staff on various topics regularly via videos, in person meetings and webcam sessions.
Thanks - another great video that demystifies asm and understanding C64 memory. keep up this great work!!
Thanks!
That line 1 filename hint is a great idea. Nice unobtrusive assembler there.
6502! Haven't heard about that chip for a while 😅 Of course the BBC Micro that I "grew up" with used a 6502A. As BBC BASIC was so good (and advanced in those days) I never bothered to learn assembly language...
Great tut mate many thanks..
I have my original copy of Laser Genius I bought in 1986 on cassette!
Like most C64 owners, I couldn't afford a floppy drive.
10:05 I have a real c64. Assy 250407. I have a kawari installed and it always comes back with F for the high nibble. I have also swapped in my original 6567R8 just in case but it also does the same. I think it it is pretty safe to say vic chips always return F for high nibble
Thanks for doing this! I also learned today that there exists a modern replacement chip for the VIC-II that offer HDMI output.
@@MyDeveloperThoughts you're welcome.
I wonder how they implemented that trace command/single stepping in this and other old monitor programs. I'd have to guess they're parsing the next instruction and simulating the results on the registers/flags because executing them (and re-capturing control by temporarily inserting a BRK in the next instruction and capturing the interrupt) would let a jmp/jsr would take off and execute multiple instructions (unless they also temporarily put BRK's at the destination addresses???). Really neat feature and probably a pain in the ass to implement unless there's some simple way I'm overlooking.
The BRK technique you describe seems workable. I notice in the video that the trace does not step into the KERNAL routine. I would guess that it limits itself to tracing code that it has itself assembled, because it knows it can write to that memory (and can insert BRK statements into ROM). Monitors use BRK for everything, because it stashes register state and expects your interrupt handler to restore that state just before resuming, so it's easy for the utility to allow adjusting things like the program counter even while running on the machine. It's magic. :)
I love the idea of using a machine code interpreter for debugging purposes, but if the BRK technique works I wonder if it's overkill. It too would have to be careful about system calls and KERNAL variables and such...
Very interesting video, but the software is SOOO primitive!
For comparison Oric Atmos (another 6502 based) had:
- Text editor - kinda E3 for DOS (to write the code)
- Assembler ... like Apple II (probably Merlin) - no line numbers nonsense, 2 pass, max 38k per file, multi file, huge variables names (64 or 128)
- Debugger - a real one, not like this toy in the video. It had a stunning UI for its time (imagine Borland Turbo vision interface), code displayed in scrollable boxes, break points, ...
P.S. I dont remember all the features, but really it was revolutionary - kind-a of what you will see later in DOS era (90s). Keep in mind that 1986 that computer was no longer sold.
Pilfered from the internet due to my failing memory.
Vector Technqiue:
=========================
Make the load address of the file 02A7. Put some ML here that emulates a
RUN command by calling rom routines, or poke in R U N into the keyboard
buffer, or whatever.
At address $0302 plug in the value A7, and at address $0303 plug in 02.
When you save the file, start saving at address $02A7, end at the 3rd 00
00 00 in the normal basic address space ($0800).
When the file is loaded ,8,1 it starts loading in data at 02A7 which is
your autoboot code. When it reaches 0302 it overwrites that vector and
re-directs control too your ML. When the file finishes loading, it
executes your ML automatically
👍👍👍👍👍👍
line numbers for assembly? I wouldn't have bought this package. Turbo Assembler or Merlin.
these old tools were great back in the day, but now you're really better off using modern tool chains like vscode and kickass and cross compiling
Point missed I think
I want to learn more about the machines and software that was used so for assembler. Clearly, anyone writing serious software for the C64 now, like new games, etc. would use what you suggested but that doesn't mean that the information in this video is not valuable - without it I would never have even known about this assembler being used. I also think it is easier to learn and understand (at least for me) while actually working in the C64 environment itself.
@@phil2768i wasn't disparaging the work shown here, i loved the video. i just thought maybe someone should point out there are newer/easier ways of doing things. anyone new to c64 dev finding this video might not be aware of things like kickass.
@@furroy yes, I need to looked into using it myself to be fair. I'd heard about it a while ago, set it up with VS Code, but never got to really dabble with it properly.
It really depends what you are after. I started using the original hardware again for the nostalgic reason... and many do.
8 bit show and tell is also great content and on the actual machines.
Another interesting thing is c64 os. Greg has been writing the whole os in tmp... on a c128. When I spoke with him about it he mentioned it all started with wanting to spend time on the machine... not somewhere else.
For many it is about the trip down memory lane.