3 ms·

Does the assembly listing look sensible to anyone? It's been a long time but to me it looks like the disassembly of random bytes. "Jam rts"? "Nop $60"? "Brk brk

by 0x0 5y ago

Does the assembly listing look sensible to anyone? It's been a long time but to me it looks like the disassembly of random bytes. "Jam rts"? "Nop $60"? "Brk brk sta Routine_0c86"? And a ton of raw un-assembled ".byte"?

onurcel 5y ago
that's really weird. It looks like the author wrote it with a more powerful system then partly disassembled it. In my opinion this hurts the narrative of this otherwise cool project/article.
- scarygliders 5y ago
  That's not the case. Back in the day you would use some sort of "monitor" program to assemble that code (or to disassemble code already in memory). For example, the C64 Action Replay cartridge had a built-in monitor. Software machine code monitors and assemblers were also available.
- ksherlock 5y ago
  You're 100% right. It looks like output from a tracing disassembler but it didn't account for the preamble so it quickly gets pear shaped. If you download the binary and hex dump it, it's a PRG file which contains a 2-byte header ($0801, the load address), followed by a short basic program (816 SYS 2061) followed by the actual code at 2061 ($080d). The actual code starts with LDA $01 but the address is off by 2 bytes (due to the PRG header) so the JSR subroutines are off as well. https://michaelcmartin.github.io/Ophis/book/x72.html https://michaelcmartin.github.io/Ophis/book/x72.html
scarygliders 5y ago
Nope, it's a perfectly normal listing of 6502 code in Assembler. The BRK instruction, if I recall correctly from my 6502 days, forces an interrupt for reasons I can't precisely remember. EDIT : https://www.c64-wiki.com/wiki/BRK https://www.c64-wiki.com/wiki/BRK
- Someone 5y ago
  Yes, but two BRKs in succession make little sense. The only reason to use that I can think of is as placeholders in self-modifying code. sta Routine_0c86 certainly is weird. It modifies the first byte of a subroutine. Again, that could be self-modifying code, but such a byte cannot be an immediate data byte or part of an address, making that less likely. Things like jsr $ffff also are weird. Why would there be a subroutine starting at the last addressable byte?
- 0x0 5y ago
  ... whose hex representation is 00 Also, "JAM". Really.

by 0x0 5y ago

onurcel 5y ago

that's really weird. It looks like the author wrote it with a more powerful system then partly disassembled it. In my opinion this hurts the narrative of this otherwise cool project/article.

scarygliders 5y ago
That's not the case. Back in the day you would use some sort of "monitor" program to assemble that code (or to disassemble code already in memory). For example, the C64 Action Replay cartridge had a built-in monitor. Software machine code monitors and assemblers were also available.
ksherlock 5y ago
You're 100% right. It looks like output from a tracing disassembler but it didn't account for the preamble so it quickly gets pear shaped. If you download the binary and hex dump it, it's a PRG file which contains a 2-byte header ($0801, the load address), followed by a short basic program (816 SYS 2061) followed by the actual code at 2061 ($080d). The actual code starts with LDA $01 but the address is off by 2 bytes (due to the PRG header) so the JSR subroutines are off as well. https://michaelcmartin.github.io/Ophis/book/x72.html https://michaelcmartin.github.io/Ophis/book/x72.html

scarygliders 5y ago

Nope, it's a perfectly normal listing of 6502 code in Assembler. The BRK instruction, if I recall correctly from my 6502 days, forces an interrupt for reasons I can't precisely remember. EDIT : https://www.c64-wiki.com/wiki/BRK https://www.c64-wiki.com/wiki/BRK

Someone 5y ago
Yes, but two BRKs in succession make little sense. The only reason to use that I can think of is as placeholders in self-modifying code. sta Routine_0c86 certainly is weird. It modifies the first byte of a subroutine. Again, that could be self-modifying code, but such a byte cannot be an immediate data byte or part of an address, making that less likely. Things like jsr $ffff also are weird. Why would there be a subroutine starting at the last addressable byte?
0x0 5y ago
... whose hex representation is 00 Also, "JAM". Really.