Attachment | Size |
---|---|
![]() | 6.63 KB |
I still can't compile this code, can someone help with this?
Please support the defense of Ukraine.
Direct or via Unclutter App
No Ads.
No Trackers.
No Social Media.
All Content Locally Hosted.
Built on Free Software.
We have complied with zero government requests for information.
~ Est. 1999 ~
A pillar of corporate stability since the second millenium.
© 1999-2999 Tom Owad
You don't need to assemble or compile it, the hex bytes are already there, you just need to convert them to a binary file. I don't know what generated that listing, but it would be pretty easy to convert on a modern system with something like a simple Perl script.
It's not a listing, it's text capture from an interactive Monitor console on an unidentified 6502-based computer. The syntax is similar to Commodore's Terminal Interface Monitor (TIM) but with additional commands. So the target computer might be any platform where TIM was a popular Monitor console, such as KIM-1, PET, CBM, Super PET, VIC-20, Commodore 64, C-16, Commodore 128, or Plus-4. Or maybe it's from a modern emulator that offers an extended TIM-style command console, such as VICE.
That machine code won't work at all on Apple nor clones. The BASIC STUB is formatted like Microsoft BASIC, but it uses tokens that don't form legal statements in Applesoft. (eg: passing a numeric argument "2062" after an INVERSE token "9E") Likewise, the machine code calls into ROM addresses that don't contain callable subroutines. (eg: JSR $F34A would call into the middle of a machine-code instruction, not a valid ROM entry point)
Fair enough, everything you say is correct. I'm just saying, that it has already been assembled, and the bytes are there in the text.
I'm thinking your guess about it coming from a modern CBM-ish emulator may be on the right track.
More specifically, the JSR targets are Commodore 64 subroutines. A quick search for target addresses like $FE00 and $F34A turned up this list of C64 functions:
Commodore 64 standard KERNAL functions
Whoever the user was, they took a shortcut by calling the "real address" of each subroutine instead of calling the KERNAL entry points. That's an understandable shortcut, since the KERNAL entry points just contain "JMP" instructions to each subroutine. Taking the shortcut saves 4 processor cycles, at the risk of incompatibility with other Commodore models with different ROMs. Compatibility probably wasn't importanty to the user who wrote the code.
Just for general interest, here are some functions called from that code sample according to the KERNAL function addresses listed at the page linked above:
[EDIT]
Knowing that the target platform was probably a Commodore 64, running Commodore BASIC (a Microsoft derivative), we can guess that the byte string "$00,$0b,$08,$c8,$07,$9e,$32,$30,$36,$31,$00,$00,$00" really is a stub of a one-line BASIC program:
1992 SYS 2061
That's a call into the machine language subroutine at 2061, which is address $080D in hexadecimal. It would appear that this listing is a transcript of a user who was using TIM to construct a machine code program that could be saved to tape or diskette under the disguise as a BASIC program. That's not malicious or suspicious in itself -- it was a common method of distributing machine code programs on Commodore platforms so that the average user could load them from tape or disk via the LOAD command.
Very interesting. It is possible to do the same thing by putting an Applesoft progran into data like that with the token for Applesoft's CALL instead of the one for Commodore BASIC's SYS.
I actually used a similar technique back in the day to disguise a machine code program as Applesoft. It wasn't for nefarious purposes per-se, it was more showing off.
The assignment was to write an Applesoft program that cleared the screen and then counted from 1 to 50000, displaying the count centered on the screen. Whoever's code ran fastest won the challenge.
So I coded pretty much an optimal version in Applesoft, but I wasn't satisfied with that. I wrote one in assembler taking pretty much every shortcut possible, like not actually using counter variables, but just incrementing the bytes in the screen memory. To hide it the first like was "0 HOME:CALL xxxx:REM" with backspaces to cover over the call then another HOME. If you LISTed it you saw what appeared to be just an Applesoft program unless you used SPEED= or something like that.
The teacher couldn't figure out how it worked. He even tried re-typing the BASIC code, which of course ran about as quickly as anyone else's or better, but nowhere near what the machine code did. I had to give him the SPEED= hint to figure it out. He couldn't figure out how I had added the machine code onto the end of the program until I explained about changing the start and end pointers.
Yeah, it was cheating. But that class was stupidly boring so I had time to kill.