- VCF East - April 12 - 14, Infoage Museum, Wall NJ
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Sothern CA
-
Please review our updated Terms and Rules here
Source Code of Commodore 64-128 Games
- Thread starter NicolasF
- Start date
Terry Yager
Veteran Member
You'll prob'ly need a disassembler to get to the source code, and even then, it'll be a real challenge to understand undocumented AL code.
--T
Terry Yager
Veteran Member
Ummn, Assembly Language, sometimes confused with Machine Language (ML).
--T
--T
carlsson
Veteran Member
I'd say it is machine code/language (represented as mnemonics) you get when you disassemble a binary program. The assembly code for me is a bit more high level, using logical labels, comments, include files and so.
That said, you can disassemble a machine code program and get a somewhat readable listing using a program like e.g. recomment. However, it won't be the original source code, if it ever existed other than on paper or in the programmer's mind.
Unless you're an aspiring machine code programmer who want to figure out a particular routine, it is rather pointless trying to disassemble a game. Even then, it will be tough to locate exactly which code does what.
That said, you can disassemble a machine code program and get a somewhat readable listing using a program like e.g. recomment. However, it won't be the original source code, if it ever existed other than on paper or in the programmer's mind.
Unless you're an aspiring machine code programmer who want to figure out a particular routine, it is rather pointless trying to disassemble a game. Even then, it will be tough to locate exactly which code does what.
PhotoJim
Member
Technically, you can only see a disassembly of the code unless you have the original development files that the software author had. (That's why it's called source code - it's the source of the assembled code that actually runs the computer.)
It's entirely possible to learn assembly language enough to do cool stuff with it - but disassembling commercial games probably isn't the place to start.
Jim butterfield published an excellent book on learning assembly language on the Commodore computers; you can still find copies around. It's an excellent resource.
Jim
It's entirely possible to learn assembly language enough to do cool stuff with it - but disassembling commercial games probably isn't the place to start.
Jim butterfield published an excellent book on learning assembly language on the Commodore computers; you can still find copies around. It's an excellent resource.Jim
billdeg
Technician
When you list the source code and you get an output to the screen of something like
"SYS 3452"
[1] if you're using a c128, use 64 mode and try loading/running again.
[2] Don't put the ",1" at the end of your load statement
try loading your program like this:
load "programname",8 [enter]
*wait for ready*
run [enter]
...sometimes a program for various reasons will not load properly if you have ",1" at the end of your load statement.
[3] You have a bad copy. What program is it? I will see if I have a copy.
"SYS 3452"
[1] if you're using a c128, use 64 mode and try loading/running again.
[2] Don't put the ",1" at the end of your load statement
try loading your program like this:
load "programname",8 [enter]
*wait for ready*
run [enter]
...sometimes a program for various reasons will not load properly if you have ",1" at the end of your load statement.
[3] You have a bad copy. What program is it? I will see if I have a copy.
carlsson
Veteran Member
A clarification: LOAD"PROGRAM",8,1 means that the program will be loaded from device 8 (typically a disk drive) and to the memory location it was saved from. When it comes to machine code modules, it usually is important that the code is loaded back to the same position it was saved from, as the code contains absolute memory references. The same is of course true if you load character sets or other graphics.
When it comes to Basic programs, these can be relocated most of the time. Usually on a Commodore 64, Basic starts at the position all the time, so you wouldn't have to bother. On e.g. a VIC-20, the start of Basic differs depending on how much memory expansion you have inserted. If you saved a Basic program on an unexpanded machine and load it back ,8,1 the following happens:
1. On an unexpanded machine: nothing. It loads back to its intended position.
2. With +3K expansion: it loads to $1001, while Basic starts already at $0401, so you won't see any visual signs the program loaded at all.
3. With +8K expansion: it loads to $1001, which happens to be the position of the video matrix in this configuration. The screen will be full of garbage.
If you loaded the same program ,8 (or ,8,0) it will relocate to the current beginning of Basic memory. Programs written in Basic will automatically relink upon loading, so most of them will work, except for programs with a lot of PEEK and POKE statements that rely on a particular memory layout. Programs written in machine code, graphics etc will mostly turn into garbage, since they will be relocated to a different address than intended.
Some crunchers/packers/emulators or whatever it is, saves Basic programs to address $0800 (C64), $1000 (VIC-20) etc, while it usually should be $8081, $1001 and so on. It means that if you load the program with ,8 and let the computer relocate it, everything will be offset by one byte and tends to screw up the computer. In those cases, you must load ,8,1 to get it to work.
If you load a long program, and when you list it, you only see a SYS statement, it is because the rest is machine code. I'm quite sure it doesn't have anything to do with relocation or load errors. As stated before, the machine code can be disassembled to some degree, but the question is what one wants to obtain from listing it.
When it comes to Basic programs, these can be relocated most of the time. Usually on a Commodore 64, Basic starts at the position all the time, so you wouldn't have to bother. On e.g. a VIC-20, the start of Basic differs depending on how much memory expansion you have inserted. If you saved a Basic program on an unexpanded machine and load it back ,8,1 the following happens:
1. On an unexpanded machine: nothing. It loads back to its intended position.
2. With +3K expansion: it loads to $1001, while Basic starts already at $0401, so you won't see any visual signs the program loaded at all.
3. With +8K expansion: it loads to $1001, which happens to be the position of the video matrix in this configuration. The screen will be full of garbage.
If you loaded the same program ,8 (or ,8,0) it will relocate to the current beginning of Basic memory. Programs written in Basic will automatically relink upon loading, so most of them will work, except for programs with a lot of PEEK and POKE statements that rely on a particular memory layout. Programs written in machine code, graphics etc will mostly turn into garbage, since they will be relocated to a different address than intended.
Some crunchers/packers/emulators or whatever it is, saves Basic programs to address $0800 (C64), $1000 (VIC-20) etc, while it usually should be $8081, $1001 and so on. It means that if you load the program with ,8 and let the computer relocate it, everything will be offset by one byte and tends to screw up the computer. In those cases, you must load ,8,1 to get it to work.
If you load a long program, and when you list it, you only see a SYS statement, it is because the rest is machine code. I'm quite sure it doesn't have anything to do with relocation or load errors. As stated before, the machine code can be disassembled to some degree, but the question is what one wants to obtain from listing it.