I remember having that same exact issue of COMPUTE's GAZETTE when I was a kid and typing in all the code for the Face-Off game on the front cover. It was really fun!
I had it as a kid, and now I have it again! And I once typed in The Fast Assembler! I learned assembler using a basic assembler in one of compute's books. Later I learned how to do split border and split background colors. That was some cool times!
To me and my friends, “assembly language” meant the same as black magic. It was that advanced stuff that we mortals needn’t even try to comprehend. Wish I had tried tho. Future me learned assembly by making Flappy Bird for C64.
Wow! this takes me way back to an early point in my childhood. This was the article that unlocked allot of concepts for me and set me on a course to where i am today. I had forgotten about article until i saw your video in my recommended list. thank you!
This assembler is not even close to the Turbo Assembler by Omikron, now Turbo Macro Pro. Cyberpunx Retro Replay cartridge has Turbo Macro Pro built it, started with the BASIC "TASM" command.
When I used to MLX I never looked at the screen. It was faster to just listen and if (when) hearing a 'BUZZ' I knew it was positioned at the start of line and I would just retype the line again. Saved trying to eyeball the mistake.
Thanks so much for this excellent video. I've been dabbling in C64 development for a little while now and this is one of the clearest and most well-presented YT videos I've watched.
See wiki.haskell.org/wikiupload/1/14/TMR-Issue6.pdf for a much, much, much more modern implementation of the same idea: an assembler embedded in Haskell.
Yes this is what is missing from the video discussion. Since you can make use of basic to have calculated data it opens some possibilities that I don't think can be done with Turbo Macro Pro either.
Never had a C64 but i did have the Oric 48k , and i taught myself pure machine code using Hexadecimal code direct, it took about 2 year to make my first space invaders program , i had to so many delays in it to slow it down or you lost before had a chance to see anything move, about 2 seconds for the invaders to move back and forth and then move down the screen . dam that 6502 was so fast, thanks for the memory recall.
Great video, makes me want to play with 6510 assembly again! One minor minor correction: The VIC-II and SID are not "constantly scanning memory" as stated @18:55. The VIC-II and SID chips are *mapped* into memory address space. When you change $d020, you're talking directly to the I/O registers in the VIC-II. You have to bankswitch the chip out (using memory location $0001) of the I/O space to work with the RAM that is also mapped to that location. There's also character ROM mapped to the same space, but you generally wouldn't see that unless you switch it in... it's a pretty busy area!
Technicalities! And how you see it (from your viewing angle, you little bank switcher[1]!). I could say you are wrong, but lets speak "The MOS 6567/6569 video controller (VIC-II) and its application in the Commodore 64" by Christian Bauer. 2.4.3 Memory access of the 6510 and VIC --------------------------------------- 6510 and VIC are both based on a relatively simple hard-wired design. Both chips make a memory access in EVERY clock cycle, even if that is not necessary at all. E.g if the processor is busy executing an internal operation like indexed addressing in one clock cycle, that really doesn't require an access to memory, it nevertheless performs a read and discards the read byte. The VIC only performs read accesses, while the 6510 performs both reads and writes. There are no wait states, no internal caches and no sophisticated access protocols for the bus as seen with more modern processors. Every access is done in a single cycle. The VIC generates the clock frequencies for the system bus and the RAS and CAS signals for accessing the dynamic RAM (for both the processor and the VIC). So it has primary control over the bus and may "stun" the processor sometime or another when it needs additional cycles for memory accesses. Besides this, the VIC takes care of the DRAM refresh by reading from 5 refresh addresses in each raster line. The division of accesses between 6510 and VIC is basically static: Each clock cycle (one period of the ø2 signal) consists of two phases. The VIC accesses in the first phase (ø2 low), the processor in the second phase (ø2 high). The AEC signal closely follows ø2. That way the 6510 and VIC can both use the memory alternatively without disturbing each other. However, the VIC sometimes needs more cycles than made available to it by this scheme. This is the case when the VIC accesses the character pointers and the sprite data. In the first case it needs 40 additional cycles, in the second case it needs 2 cycles per sprite. BA will then go low 3 cycles before the VIC takes over the bus completely (3 cycles is the maximum number of successive write accesses of the 6510). After 3 cycles, AEC stays low during the second clock phase so that the VIC can output its addresses. [1] No offense! I am just joking. For a hammer, everything looks like a nail. For you ... obviously everything looks like a bank:) You completely ignore the hardware design and the very smart ø2 clock line technique used to access shared RAM and VIC RAM, which she is CONSTANTLY SCANNING when generating a video output. Nice try, nice thought, but weighted as false, hehehe:)
And the workings of the VIC-II ( "Besides this, the VIC takes care of the DRAM refresh by reading from 5 refresh addresses in each raster line.") in-system alone justifies to describe this functionality as "CONSTANTLY SCANNING MEMORY". Because that is WHAT IS HAPPENING in REALITY!
I share your thought about the SID. The "scanning"-claim there is just nonsense, as he has no active role on the BUS and is just an addressable sink/source of memory locations accessed over the 6510 address-bus.
@@dieSpinnt Incorrect. You can have a different value in RAM (the memory addressable at that location) and the IO register. The address lines are not "memory". You can't possibly believe that the VIC and SID are able to access the memory *mapped to the same address bus location as themselves*, reading it, then somehow magically restoring the value that was in the RAM before. They simply listen on the address lines and change internal registers. If you don't believe me, go ask Bill Herd or one of the C= engineers. The memory access referred to in Bauer's text above is just talking about the interleaving of memory access because chips like the VIC will need it to access sprites, custom char sets, etc., not their own registers.
Oh man... I used to love me some COMPUTE!'s Gazette type-in utilities. I seem to recall getting a pretty decent word processor, sprite, and character editor from their pages back in the day.
I'm 31 yo never experienced these era but always wanted to learn assembly because my brother used to have oold magazines with old IT books that teaches them old stuff... i didn't even had computer access at that time so the interpreter would be my brain loll... still love them but for nostalgia purpose only haha...
Excellent! Like you I missed it when the magazine was delivered to my house. I didn't realize the uniqueness of Fast Assembler. Thanks for putting this together it was a great watch and I am sure it is one of the few on TH-cam as I think this went under the radar for many as there were some great assembler packages out there then, as you have shown. Thanks again!
Careful on using @ to overwrite the previous version of the program. The original 1541 ROM has a mistake that would screw up the BAM, causing file corruption when using @ replace. Use the 15441-II ROM, or keep several versions of the file :)
I have this, I even made a simple template for it just to speed things along. It's a nice assembler to have, especially back in the day when you couldn't afford any of the commercial packages.
The Laser Genius assembler from Ocean is really good too. Nice options to list lines using labels, as well as renumber lines, move and delete lines etc. Plus a built in monitor, and number convertor, plus assemble straight to memory or from files on disk. It's nice :)
Thank you so much for this video. I also was too young for Fast Assembler in 1986 (I would have just turned 8) but I messed around with it a bit. I remember the companion disk for the issue included the source for FA in FA, so I was able to change the text banner and re-assemble it, but that's as far as I got. I haven't gone back to it, so I didn't know how it used BASIC itself as a macro language. Really great clear explanations, too! Thanks again!
As a former demo coder. I want you all to know. That everyone I ever knew in the demo scene. Used turbo assembler. There is even a REU version of it. So you can use all memory without ruining the source code.
I have that same issue of COMPUTE!'s GAZETTE and messed around with both the Fast Assembler as well as Commodore's Assembler Development System back in the day.
It was quite common in those to write assembler code with BASIC. But I did not see anything like this. Usually a SYS command, from there assembly code until an end mark and everything between was pure assembler no possibility to use BASIC. The tools used to type those programs were quite similar here in Germany, later we did not have to use hex numbers but most of the letters and had to type in less. The VIC and the CPU share the memory and the memory access. The VIC even regularly stops the CPU to get its needed bandwidth (fetching the 40 chars stored in screen memory, fetching sprite data). But the VIC only reads graphic and color data actually used. But it never reads e. g. the border color. $D020 is a memory mapped register of the VIC (6502 only knows memory mapped IO). Some memory areas within the 64 KiB of address space access different things controlled by a chip called PLA which is partly controlled by the 6510's 6 bit GPIO port (Zero Page $00 and $01). $D000 to $DFFF e. g. is - I/O area, to control all the internal and up to two optional external chips, and 0.5 KiB of SRAM (color RAM for the VIC) - CPU access to the character ROM (VIC sees this ROM in other areas instead of RAM) - RAM Switching to anything else than IO in BASIC will crash the C64. So assembler was often needed.
Love these assembler series, a great way to brush up on those faded 80's memories. heh While assembling on a real C64 is great even with some limitations, perhaps review some of the newer assemblers and resource editors, such as the Kick Assembler, X-Ass, X-Mem, and Windows based ones like the C64-PRG-Studio, CBM-PRG-Studio, C64-Studio and TRSE.
"#" is the convention on the Commodore 64. Pioneered by Turbo Assembler (which is now Turbo Macro Pro), I believe. But it's the de facto standard. When you write lda #>label, everybody knows what you mean.
Wonder how efficient this was, compared to editing text files & running a Makefile. Adding keywords to the BASIC interpreter must have been real efficient.
I was playing along happily at home on a real c64, and found that after exiting monitor8000, the sys4408 did not rerun the fast assembler just crashed :( I then tried it on the Vice emulator and that made a better attempt at running fast assembler, but after typing sys4408 it displayed the basic code with the assembly embedded - but shifter to almost half across the screen and Vice showed a status of "Main CPU JAM at $11BA". Just thought I'm mention that in case anyone else was having trouble. Of course you can just reset and reload from scratch, not as quick though. Maybe I have slightly different version of fast assembler or the monitor8000?
I keyed in Fast Assembler from PDFs of Computes Gazzette for the video, so it is very possible that it is different than a version found online. As you mentioned, it could also be the monitor. If I recall correctly I was using the monitor from the MADS (Macro Assembler Development System) which I found online. Thanks for the feedback! much appreciated
So, the strange thing is I've tried this again, and now it's ok - I can go back and forth from fast assembler to monitor8000. The only thing I can think is that I was either not exiting the monitor with "x" or I was typing sys$4408 to get back to assembler.
@1:58 - I absolutely had to type that code in. I did it a lot. A small, flexible pocket ruler I stole from my dad served as a line guide which I taped in place when I needed a break. I wanted to see this EXACT thing when I typed it in the search bar on TH-cam. Well done, lad! Can you point me to this C64 emulator you're using?
Thanks!!! The emulator I'm using is Vice 3.7 (64bit GTK3) vice-emu.sourceforge.io/ vice-emu.sourceforge.io/ I'm running it on Windows 11. My favorite feature by far is the 1541 drive sound emulation. It's ridiculous I know, but I when I hear it, I swear I'm 11 years old again in front of my old beloved C64.
@@MyDeveloperThoughts Excellent!! I was nearing on HS graduation when I was playing with this and I was blessed to have stacked 1541s to mess with. I also am probably the only person you know that had a school term paper rejected because I used line-feed paper in our Star NX10 to print in - in 1986. The teacher didn't want the perforation marks.
I had to explain to my 10th or 11th grade English teacher, that my mps-801 printer did not print true descenders, when I turned in my book report on "The Hobbit" that I typed with Easy Script. Although I did get points off for misspelling beards as breads. Yeah, missed that on my proofreading, not having someone else proofread it, and not having Easy Spell. 🥴
It took me 24 hours to type line 160 of MLX 2 :-). That thing "[< 8 @ >]" was completely untypeable to me. Finally I switched VICE's keyboard from symbolic to positional and only then the checksum was 121
You do know that you can write the Cyperpunx Retro Replay into "EasyFlash 3", and then you have Turbo Macro Pro IDE launch from cartridge when you type in "TASM", right?
I love his Channel, he has such great content. My personal favorite Assembler on the C64 at the moment is Laser Genius by Ocean. While it doesn't have REU support (or even a full screen editor) - it has the ability to easily move itself around in RAM, and the tools to manipulate memory and load binary data from disk are awesome / as well as the integrated monitor. The Trace Feature is what really sets it apart from TMP. With that said, the full screen editor in TMP is awesome and the REU support is fantastic. The U/I is also way better in TMP. So for me I'm like 52% Laster Genius, 48% TMP. Depends on what I'm working on.
I don't think so. But tthe LADS assembler runs on a VIC and was really fun to play with. You will need at least 8K expansion RAM though: th-cam.com/video/tFWIPFnlkEk/w-d-xo.html
Not a problem! After buying the Vic I placed an order for a Penultimate+2 cart along with a SD2IEC drive! I will look into LADS starting with your video. Thanks!@@MyDeveloperThoughts
Feedback: You are good at typing code and the logic involved. However, you are not very good at explaining what your code is doing. Case in point: t39.07++. You say we should get 192 and 1. However, you don't explain where those numbers are coming from and why they are 192 and 1. This is just one of many such points where I had to pause the video and try and figure it out for myself. A simple explanation, would help your viewers learning ASM, understand what you are doing and why.
the $e for clearing the screen didn't work for me so i found that i can use just before ploop: a jsr $e544 which is just a sub routine for clearing the screen thats in the kernal
I remember having that same exact issue of COMPUTE's GAZETTE when I was a kid and typing in all the code for the Face-Off game on the front cover. It was really fun!
I had it as a kid, and now I have it again! And I once typed in The Fast Assembler! I learned assembler using a basic assembler in one of compute's books. Later I learned how to do split border and split background colors. That was some cool times!
To me and my friends, “assembly language” meant the same as black magic. It was that advanced stuff that we mortals needn’t even try to comprehend. Wish I had tried tho.
Future me learned assembly by making Flappy Bird for C64.
Kick assembler in 1986. This is astounding! Essentially the same concept as kickass inside basic interpreter. Just crazy.
Wow! this takes me way back to an early point in my childhood. This was the article that unlocked allot of concepts for me and set me on a course to where i am today. I had forgotten about article until i saw your video in my recommended list. thank you!
This assembler is incredibly powerful, wish I'd knew about it back in the days
Same!
This assembler is not even close to the Turbo Assembler by Omikron, now Turbo Macro Pro. Cyberpunx Retro Replay cartridge has Turbo Macro Pro built it, started with the BASIC "TASM" command.
@@AnnatarTheMaiafor c64?
I LOVE C64 ❤️💕💖💖❤❤❤❤
A mis 7naños, aprendí a programar ASM en mi C64, y lo adoraba... Aún lo adoro y lo amaré Siempre 😘😘😘😘
This is like BBC Micro's BBC BASIC with its built-in assembler.
When I used to MLX I never looked at the screen. It was faster to just listen and if (when) hearing a 'BUZZ' I knew it was positioned at the start of line and I would just retype the line again. Saved trying to eyeball the mistake.
I used this assembler back when I wrote C64 software! It was the only option available to me at the time.
Thanks so much for this excellent video. I've been dabbling in C64 development for a little while now and this is one of the clearest and most well-presented YT videos I've watched.
It was such a game-changer for me to type this program in 35+ years ago...
Very clear narration, you've done well. By the way, I had one of those monitor cartridges back in the day, convenient actually.
Assembler-as-a-DSL is a surprisingly modern approach for 1985!
See wiki.haskell.org/wikiupload/1/14/TMR-Issue6.pdf for a much, much, much more modern implementation of the same idea: an assembler embedded in Haskell.
Yes this is what is missing from the video discussion. Since you can make use of basic to have calculated data it opens some possibilities that I don't think can be done with Turbo Macro Pro either.
Never had a C64 but i did have the Oric 48k , and i taught myself pure machine code using Hexadecimal code direct, it took about 2 year to make my first space invaders program , i had to so many delays in it to slow it down or you lost before had a chance to see anything move, about 2 seconds for the invaders to move back and forth and then move down the screen . dam that 6502 was so fast, thanks for the memory recall.
Great video, makes me want to play with 6510 assembly again!
One minor minor correction: The VIC-II and SID are not "constantly scanning memory" as stated @18:55. The VIC-II and SID chips are *mapped* into memory address space. When you change $d020, you're talking directly to the I/O registers in the VIC-II. You have to bankswitch the chip out (using memory location $0001) of the I/O space to work with the RAM that is also mapped to that location. There's also character ROM mapped to the same space, but you generally wouldn't see that unless you switch it in... it's a pretty busy area!
Commodore 64 is the best teacher, complicated yet still simple
Technicalities! And how you see it (from your viewing angle, you little bank switcher[1]!). I could say you are wrong, but lets speak "The MOS 6567/6569 video controller (VIC-II) and its application in the Commodore 64" by Christian Bauer.
2.4.3 Memory access of the 6510 and VIC
---------------------------------------
6510 and VIC are both based on a relatively simple hard-wired design. Both
chips make a memory access in EVERY clock cycle, even if that is not
necessary at all. E.g if the processor is busy executing an internal
operation like indexed addressing in one clock cycle, that really doesn't
require an access to memory, it nevertheless performs a read and discards
the read byte. The VIC only performs read accesses, while the 6510 performs
both reads and writes.
There are no wait states, no internal caches and no sophisticated access
protocols for the bus as seen with more modern processors. Every access is
done in a single cycle.
The VIC generates the clock frequencies for the system bus and the RAS and
CAS signals for accessing the dynamic RAM (for both the processor and the
VIC). So it has primary control over the bus and may "stun" the processor
sometime or another when it needs additional cycles for memory accesses.
Besides this, the VIC takes care of the DRAM refresh by reading from 5
refresh addresses in each raster line.
The division of accesses between 6510 and VIC is basically static: Each
clock cycle (one period of the ø2 signal) consists of two phases. The VIC
accesses in the first phase (ø2 low), the processor in the second phase (ø2
high). The AEC signal closely follows ø2. That way the 6510 and VIC can
both use the memory alternatively without disturbing each other.
However, the VIC sometimes needs more cycles than made available to it by
this scheme. This is the case when the VIC accesses the character pointers
and the sprite data. In the first case it needs 40 additional cycles, in
the second case it needs 2 cycles per sprite. BA will then go low 3 cycles
before the VIC takes over the bus completely (3 cycles is the maximum
number of successive write accesses of the 6510). After 3 cycles, AEC stays
low during the second clock phase so that the VIC can output its addresses.
[1] No offense! I am just joking. For a hammer, everything looks like a nail. For you ... obviously everything looks like a bank:) You completely ignore the hardware design and the very smart ø2 clock line technique used to access shared RAM and VIC RAM, which she is CONSTANTLY SCANNING when generating a video output. Nice try, nice thought, but weighted as false, hehehe:)
And the workings of the VIC-II ( "Besides this, the VIC takes care of the DRAM refresh by reading from 5
refresh addresses in each raster line.") in-system alone justifies to describe this functionality as "CONSTANTLY SCANNING MEMORY".
Because that is WHAT IS HAPPENING in REALITY!
I share your thought about the SID. The "scanning"-claim there is just nonsense, as he has no active role on the BUS and is just an addressable sink/source of memory locations accessed over the 6510 address-bus.
@@dieSpinnt Incorrect. You can have a different value in RAM (the memory addressable at that location) and the IO register. The address lines are not "memory". You can't possibly believe that the VIC and SID are able to access the memory *mapped to the same address bus location as themselves*, reading it, then somehow magically restoring the value that was in the RAM before. They simply listen on the address lines and change internal registers. If you don't believe me, go ask Bill Herd or one of the C= engineers. The memory access referred to in Bauer's text above is just talking about the interleaving of memory access because chips like the VIC will need it to access sprites, custom char sets, etc., not their own registers.
Oh man... I used to love me some COMPUTE!'s Gazette type-in utilities. I seem to recall getting a pretty decent word processor, sprite, and character editor from their pages back in the day.
the 80 column driver, this, spreadsheet....
I'm 31 yo never experienced these era but always wanted to learn assembly because my brother used to have oold magazines with old IT books that teaches them old stuff... i didn't even had computer access at that time so the interpreter would be my brain loll... still love them but for nostalgia purpose only haha...
Nice video, well done! Happy to see that it is still being used.
Excellent! Like you I missed it when the magazine was delivered to my house. I didn't realize the uniqueness of Fast Assembler. Thanks for putting this together it was a great watch and I am sure it is one of the few on TH-cam as I think this went under the radar for many as there were some great assembler packages out there then, as you have shown. Thanks again!
Careful on using @ to overwrite the previous version of the program.
The original 1541 ROM has a mistake that would screw up the BAM, causing file corruption when using @ replace.
Use the 15441-II ROM, or keep several versions of the file :)
I have this, I even made a simple template for it just to speed things along. It's a nice assembler to have, especially back in the day when you couldn't afford any of the commercial packages.
The Laser Genius assembler from Ocean is really good too. Nice options to list lines using labels, as well as renumber lines, move and delete lines etc. Plus a built in monitor, and number convertor, plus assemble straight to memory or from files on disk. It's nice :)
Thank you so much for this video. I also was too young for Fast Assembler in 1986 (I would have just turned 8) but I messed around with it a bit. I remember the companion disk for the issue included the source for FA in FA, so I was able to change the text banner and re-assemble it, but that's as far as I got. I haven't gone back to it, so I didn't know how it used BASIC itself as a macro language. Really great clear explanations, too! Thanks again!
As a former demo coder. I want you all to know. That everyone I ever knew in the demo scene. Used turbo assembler. There is even a REU version of it. So you can use all memory without ruining the source code.
I remember using that and typing in programs. To program in 6502 I used the Machine Language Monitor cartridge.
Having to manually run the 3 assembly passes is a bit odd, but this looks so much nicer than the built-in BASIC on the C64.
Thankx for another nice video
I have that same issue of COMPUTE!'s GAZETTE and messed around with both the Fast Assembler as well as Commodore's Assembler Development System back in the day.
Nice video shot, keep it up, thanks for sharing it with us :)
It was quite common in those to write assembler code with BASIC. But I did not see anything like this. Usually a SYS command, from there assembly code until an end mark and everything between was pure assembler no possibility to use BASIC. The tools used to type those programs were quite similar here in Germany, later we did not have to use hex numbers but most of the letters and had to type in less.
The VIC and the CPU share the memory and the memory access. The VIC even regularly stops the CPU to get its needed bandwidth (fetching the 40 chars stored in screen memory, fetching sprite data). But the VIC only reads graphic and color data actually used. But it never reads e. g. the border color. $D020 is a memory mapped register of the VIC (6502 only knows memory mapped IO). Some memory areas within the 64 KiB of address space access different things controlled by a chip called PLA which is partly controlled by the 6510's 6 bit GPIO port (Zero Page $00 and $01). $D000 to $DFFF e. g. is
- I/O area, to control all the internal and up to two optional external chips, and 0.5 KiB of SRAM (color RAM for the VIC)
- CPU access to the character ROM (VIC sees this ROM in other areas instead of RAM)
- RAM
Switching to anything else than IO in BASIC will crash the C64. So assembler was often needed.
Love these assembler series, a great way to brush up on those faded 80's memories. heh
While assembling on a real C64 is great even with some limitations, perhaps review some of the newer assemblers and resource editors, such as the Kick Assembler, X-Ass, X-Mem, and Windows based ones like the C64-PRG-Studio, CBM-PRG-Studio, C64-Studio and TRSE.
I have a lot of C64 and other platforms too. Perhaps you are interested. And I use KickAssembler I didn’t wanna go back to macro pro after 33 years 😂
Any news on Yves Han? That's some genius work.
"#" is the convention on the Commodore 64. Pioneered by Turbo Assembler (which is now Turbo Macro Pro), I believe. But it's the de facto standard. When you write lda #>label, everybody knows what you mean.
Wonder how efficient this was, compared to editing text files & running a Makefile. Adding keywords to the BASIC interpreter must have been real efficient.
Spectacular!
I was playing along happily at home on a real c64, and found that after exiting monitor8000, the sys4408 did not rerun the fast assembler just crashed :( I then tried it on the Vice emulator and that made a better attempt at running fast assembler, but after typing sys4408 it displayed the basic code with the assembly embedded - but shifter to almost half across the screen and Vice showed a status of "Main CPU JAM at $11BA". Just thought I'm mention that in case anyone else was having trouble. Of course you can just reset and reload from scratch, not as quick though. Maybe I have slightly different version of fast assembler or the monitor8000?
I keyed in Fast Assembler from PDFs of Computes Gazzette for the video, so it is very possible that it is different than a version found online. As you mentioned, it could also be the monitor. If I recall correctly I was using the monitor from the MADS (Macro Assembler Development System) which I found online.
Thanks for the feedback! much appreciated
@MyDeveloperThoughts yes great videos you have here. I will at some point, type in from the pdf of the original magazine, for the full experience😀
So, the strange thing is I've tried this again, and now it's ok - I can go back and forth from fast assembler to monitor8000. The only thing I can think is that I was either not exiting the monitor with "x" or I was typing sys$4408 to get back to assembler.
fascinating
great video!
This was awesome - thank you :D
@1:58 - I absolutely had to type that code in. I did it a lot. A small, flexible pocket ruler I stole from my dad served as a line guide which I taped in place when I needed a break. I wanted to see this EXACT thing when I typed it in the search bar on TH-cam. Well done, lad! Can you point me to this C64 emulator you're using?
Thanks!!!
The emulator I'm using is Vice 3.7 (64bit GTK3) vice-emu.sourceforge.io/
vice-emu.sourceforge.io/
I'm running it on Windows 11.
My favorite feature by far is the 1541 drive sound emulation.
It's ridiculous I know, but I when I hear it, I swear I'm 11 years old again in front of my old beloved C64.
@@MyDeveloperThoughts Excellent!! I was nearing on HS graduation when I was playing with this and I was blessed to have stacked 1541s to mess with. I also am probably the only person you know that had a school term paper rejected because I used line-feed paper in our Star NX10 to print in - in 1986. The teacher didn't want the perforation marks.
I had to explain to my 10th or 11th grade English teacher, that my mps-801 printer did not print true descenders, when I turned in my book report on "The Hobbit" that I typed with Easy Script. Although I did get points off for misspelling beards as breads. Yeah, missed that on my proofreading, not having someone else proofread it, and not having Easy Spell. 🥴
Wow.. what a weird and complex assembler. I see you also have a video on merlin64.. my experience is with Merlin 8/16 on the Apple II.
It took me 24 hours to type line 160 of MLX 2 :-). That thing "[< 8 @ >]" was completely untypeable to me. Finally I switched VICE's keyboard from symbolic to positional and only then the checksum was 121
You do know that you can write the Cyperpunx Retro Replay into "EasyFlash 3", and then you have Turbo Macro Pro IDE launch from cartridge when you type in "TASM", right?
Robin at 8-bit show and tell on YT swears by turbo macro pro. It's a cart-based assembler with REU support. (ram expander cart) Looks pretty swank
I love his Channel, he has such great content.
My personal favorite Assembler on the C64 at the moment is Laser Genius by Ocean. While it doesn't have REU support (or even a full screen editor) - it has the ability to easily move itself around in RAM, and the tools to manipulate memory and load binary data from disk are awesome / as well as the integrated monitor. The Trace Feature is what really sets it apart from TMP.
With that said, the full screen editor in TMP is awesome and the REU support is fantastic. The U/I is also way better in TMP.
So for me I'm like 52% Laster Genius, 48% TMP. Depends on what I'm working on.
35:14 big fan of $FFD2 😁
Use Merlin.. I used it when I was developing C64 Games and Apple ][ Games... It's a real assembly compiler..
will this assembler work on the Vic-20? I just bought one to play with!
I don't think so. But tthe LADS assembler runs on a VIC and was really fun to play with. You will need at least 8K expansion RAM though: th-cam.com/video/tFWIPFnlkEk/w-d-xo.html
Not a problem! After buying the Vic I placed an order for a Penultimate+2 cart along with a SD2IEC drive! I will look into LADS starting with your video. Thanks!@@MyDeveloperThoughts
Not using OCR instead of typing?
No OCR here. I did it old school and keyed it in.
oh fast assembler so how slow was slowest LOL todo fastest program write hello world without doing 10 print "hello world" and then interpret it
Btw. Your not "clicking" yes. Your age is showing 😂😂
Feedback: You are good at typing code and the logic involved. However, you are not very good at explaining what your code is doing. Case in point: t39.07++. You say we should get 192 and 1. However, you don't explain where those numbers are coming from and why they are 192 and 1. This is just one of many such points where I had to pause the video and try and figure it out for myself. A simple explanation, would help your viewers learning ASM, understand what you are doing and why.
the $e for clearing the screen didn't work for me so i found that i can use just before ploop: a jsr $e544
which is just a sub routine for clearing the screen thats in the kernal