Once upon a time, you might have developed for the Commodore 64 using the very machine itself. You’d use the chunky old keyboard, a tape drive, or the 1541 disk drive if you wanted to work faster. These days, though, we have more modern tools that provide a much more comfortable working environment. [My Developer Thoughts] has shared a guide on how to develop for the Commodore 64 using Visual Studio Code on Windows 11.
The video starts right at the beginning from a fresh Windows install, assuming you’ve got no dev tools to start with. It steps through installing git, Java, Kick Assembler, and Visual Studio Code. Beyond that, it even explains how to use these tools in partnership with VICE – the Versatile Commodore Emulator. That’s a key part of the whole shebang—using an emulator on the same machine is a far quicker way to develop than using real Commodore hardware. You can always truck your builds over to an actual C64 when you’ve worked the bugs out!
It’s a great primer for anyone who is new to C64 development and doesn’t know where to start. Plus, we love the idea of bringing modern version control and programming techniques to this ancient platform. Video after the break.
[Thanks to Stephen Walters for the tip!]
“or the 1541 disk drive” and had $400 to spend for one back then. $1200 when adjusted for inflation, that was an expensive drive.
But what else? A fixed disk was even more expensive.
And the datasette drive was a joke.
Good enough to run a few less sophisticated, commercial games.
Programming with it took months what otherwise had required days or weeks.
For home users or users living in poverty the datasette drive was nice enough, though.
Better than typing in listings from a magazine each time.
Seriously, though. The users who didn’t afford a 1541 could have bought a compatible clone drives.
There was a market for no-name diskette drives in the C64 heyday.
In fact, real 1541 drives were so buggy that any clone couldn’t have messed up things even more.
Or let it out me this way, the datasette didn’t require random access.
It wasn’t possible to overwrite/update a specific file in same way as with a diskette.
Updating/overwriting a “file” (data block) on a datasette was cumbersome, due to variable lenght.
If multiple “files” were being stored on a datasette already, it caused trouble.
You couldn’t safely update/overwrite a specific “file”, the following “file” was being overwritten, too.
Doing software development this way wasn’t fun.
The spooling back/forth alone was annoying.
For distribution of ready-made software, though, the datasette was an option. Albeit not a good one.
Especially in poor locations like western Europe, were people apparently didn’t have money to spend for the basic computing equipment:
Like a real computer monitor, a disk drive or an analog mouse (GEOS).
Here, the kids and elderly people not seldomly had used old b/w TV sets as cheap C64 monitors (via antenna jack). Like in a third-world country.
We started with the Datasette. After it ate a program my dad was working on, he instantly went out and bought a 1541.
I haven’t dug into the video yet, but I’m hoping it can be adapted for macOS. If not, I guess a parallels VM will have to do.
That’s how they get you. Draw you in with a cheap price and barely functional secondary storage. And you start buying disk drives and RGB monitors.
My Dad got pulled into buying up TI-99/4A accessories along the same route. I would have rather had an Apple II+, but holy smokes those things were expensive back in the day.
Some of the clone drivess didn’t emulate 1541 and some games were coded with speed code to increase data rate from the disk drive or used anti-piracy trick that only worked on 1541. Those games often wouldn’t load or crashed when loading on a clone drive.
So if one wanted to play retail games on C64, they were sort of forced to buy only 1541 or have a 1541 as drive 8 and any clone drive as 9 or higher as most games only used one disk drive.
I had Excelerator for C64 it worked but the power supply was a disaster, supposedly they were prone to catching on fire.
That may well be true, compatibility on C64 platform is (was) based on hacks atop hacks, essentially.
Up to a level that nothing but the original Commodore hardware has worked.
So it’s not essentially the fault of the clone drives here.
They can’t be blamed for bad programming, I think.
The speed loaders could be disabled, if memory serves.
Either by peek/poke or by using a different load command.
Using something like the Final Cartridge III also provided an alternate fast loader program, which might have been more compatible with certain drives, not sure.
And for software development, these clone drives were still better than cassette drives, I think.
The random access alone is avery important feature, I think.
It makes live so much easier in comparison to sequential access.
Speaking of copy protection schemes, there were memory upgrades for the 1541 drives, which allowed drives to read whole sectors. Without these upgrades, copying certain disks didn’t work. It could be that higher-end clone drives didn’t have same limitations, maybe because they used more modern technology or more RAM. Speaking under correction, though.
Then there’s the light barrier/head-bumping story.
Normal 1541 did bump the drive head 40 times against the chassis, to make sure the head is on track 0.
The 1541C did have a light barrier for track 0 detection, but it used a newer firmware and had repurposed a pin on the parallel bus (some C64 users had used a parallel cable). In order to regain maximum compatibility, the light barrier was being removed again.
More information on this fine site, it knows more about it than me:
https://theindustriousrabbit.com/blog/2021-04-21-the-commodore-64-and-1541-the-micromanaging-bosses/
So yeah, the C64 platform was charming, but also full of little bugs. And clone drives may or may not have copied those flaws, not sure.
Having something like an VC1570/VC1571 or an C128D with internal 5,25″ drive was quite a relief, I guess, even if compatibility wasn’t perfect.
I actually use vim
Then you can try durexForth: “The durexForth editor is a vi clone” ;)
I used it to write Z80 assembly code…
Been using Visual Srudio Code with Vice and Acme for Commodore assembly since 2019. Included some instructions on git and blog posts.
Video instructions are the key to unlocking this potential for more people!
There are really good video tutorials from c64braindotcom YouTube channel showing a lot of basic programming and what’s really cool he shows a book called “Mapping The C64” it really helped me understand the address codes that control everything. I find it so easier to just write a basic program and then use basic blitz to convert it into assembly code, but still you would need to understand everything about writing basic code.
These instructions were to do this in Windows 11, however I found doing this in Linux is also quite easy, and half the tools you need to install (git, java, etc.) are likely already there. Just follow his instructions, substituting Linux equivalents and/or checking if a tool already exists before installing it.
Similarly, you can write and debug 6502 assembly code for Atari 8-bit computers with VS Code, atasm and the Altirra emulator.
Where is 6502 assembly going?
ARM A and M, RISC-V gcc c to machine code hardware platforms going somewhere?
I used to write assembly code using a special version of Turbo Assembler one C64 and the compiled code ran on a second C64 connected via user port interface, so I could use the entire memory on the second C64.
Visual Studio does sound like a better solution.
I saw the the screenshot in the article with the ‘SYS 49152’ and instantly curled up in my bed shaking….
In any event, I can’t but feel that these days you’d be better off using Eclipse etc. which has a decent track record when if comes to hosting 8- and 16-bit cross-development tools.