4 ms·
The clock might have been 4MHz, but the actual MIPS was only 0.5, IIRC. The beauty of that cpu/architecture is that you could write in machine code easily, no
by yalok 8y ago
The clock might have been 4MHz, but the actual MIPS was only 0.5, IIRC.
The beauty of that cpu/architecture is that you could write in machine code easily, no assembly required. For example, MOV a constant to a pointer in memory was code 012737 with 01 denoting move command, 27 specifying the first operand as a constant residing in the memory immediately following that instruction, and 37 is specifying the second operand as a pointer, also in memory.
010102 was MOV register 1 to register 2.
I self-taught myself this while in the high school, because Basic was too slow there.
- raverbashing 8y agoI was about to correct you but then "mind blown" I can imagine how inefficient it is to have every command take 3 bytes, kind of explain its slowness (but other 8-bit machines weren't much better in MIPS terms)
- pjc50 8y agoTwo bytes: it's octal, and the system is a 16-bit machine. The leading octal digit is always 0 or 1, if I've understood https://en.wikipedia.org/wiki/PDP-11_architecture https://en.wikipedia.org/wiki/PDP-11_architecture correctly. Surprisingly similar orthogonality to ARM.
- Annatar 8y agoIt's extremely efficient, actually. After a while spent in the monitor on the C=64 (courtesy of the Final Cartridge III), we started just punching in hex opcodes instead of mnemonics; more efficient that way. I still remember that $4c is the hexadecimal opcode for the jmp instruction: 4c 00 c0 jmp $c000
- rbanffy 8y agoFor a second I was confused why would someone want to jump into the slot 0 ROM of the Apple II... All that's there is memory-mapped IO...
- Annatar 8y ago$c000 is free memory for user code on the Commodore64.
- jacquesm 8y agoI once poked a bunch of 6502 opcode into memory to speed up someone elses basic code and they looked at me like I was some kind of wizzard. They didn't know I could not afford an assembler...
- Annatar 8y agoYou could have used a cracked copy of TurboAssembler like everyone else. The cracked versions had bugs fixed, performance enhanced and many features added, even long after the author abandoned the software and all support for it: https://csdb.dk/search/?seinsel=releases&search=turbo+assembler https://csdb.dk/search/?seinsel=releases&search=turbo+assemb... http://turbo.style64.org/ http://turbo.style64.org/ Growing up on the Commodore computers in a country with no access to originals, I've never seen original software for Commodore64 in my life.
- jacquesm 8y agoI never owned a Commodore64, though I did fix a large number of them because a computer store in Amsterdam had so many DOAs that there was good money to be made turning five broken C64s in to four working ones and a couple of spare bits. The machine I did most of my 6502 stuff on was a BBC Micro, which had a basic assembler built in, so that really helped but the KIM-1 which I used before that was so sparse that even though an assembler existed I would have first had to expand the memory (big $back then). So memorize opcodes and use the handy 'opcode card' that you could get for those CPUs back in the day. No big deal, though I was really happy once I moved on to automating that part of the process. Especially branch calculation is tricky because if a branch is on a boundary you could fix it easily in something with macros but by hand it is hell because if the branch can't reach the target you need to invert the branch and then use a JMP, which requires more space, which may cause other branches to no longer reach their targets and so on.