Join 3,512 readers in helping fund MetaFilter (Hide)

Tags:

All I see now is blonde, brunette, redhead... in 8 bit sprites.
March 10, 2010 7:35 PM   Subscribe

This isn't your grandpa's PEEK and POKE. Real-time graphical hacking of the Commodore 64 system.
posted by loquacious (45 comments total) 44 users marked this as a favorite

 
Do you believe it now, Trinity?
posted by clarknova at 8:05 PM on March 10, 2010 [1 favorite]


Meh, that's just how character mapped graphics work. Kids today with all their fancy 64 bit words and expansion busses.
posted by ecurtz at 8:19 PM on March 10, 2010


wicked cool. love it.
posted by leotrotsky at 8:20 PM on March 10, 2010


This is awesome. I grew up with these machines and remember how daunting gamedev on them was whan I was a kid.
I find this complete deconstruction of this machine to be fucking awesome.
posted by Lord_Pall at 8:27 PM on March 10, 2010


Yeah, awesome. I love how bits are bits and can be interpreted so many ways. The CPU interprets them as code. This demo video interprets them as pictures, and then as a particularly visual form of memory dump. Good stuff. A bit harder of a trick to pull off when your average Twitter client takes up 30 megs of RAM :-(
posted by Nelson at 8:28 PM on March 10, 2010


yeah, it's cool, this is what i thought "hacking" would be like when i first heard about it in 1992... 18 years later we figured it out.
posted by nathancaswell at 8:30 PM on March 10, 2010


You can hack a C64 from fucking Mathematica?
posted by shadow vector at 8:33 PM on March 10, 2010 [4 favorites]


Great visualization with the zoom-in feature. There's no way you could understand what's going on with modern 1GB boxen, but the 64K memory space seems positively cozy.

(disclaimer: once hacked Karateka to make the other guy die when you pressed Esc)
posted by RobotVoodooPower at 8:38 PM on March 10, 2010


yeah, it's cool, this is what i thought "hacking" would be like when i first heard about it in 1992... 18 years later we figured it out.

No, man. They were doing this stuff in their heads in the 1980s. We ordinary mortals are just now catching up.
posted by Malor at 8:56 PM on March 10, 2010 [6 favorites]


I'd like to see this done for the computer I had in my youth, an Amstrad CPC, but all it would probably reveal is how lame the Amstrad was in terms of sprite handling etc.
posted by Jimbob at 9:04 PM on March 10, 2010


That's fascinating.

Great visualization with the zoom-in feature. There's no way you could understand what's going on with modern 1GB boxen, but the 64K memory space seems positively cozy.

I don't think it's really that much more difficult. Check out, for example hacking the PS3, or this hour long video about hacking the Xbox360. You can filter out a lot of data really quick and focus on the parts that matter by analyzing program flow, where the instruction pointer is, etc.
posted by delmoi at 9:28 PM on March 10, 2010 [2 favorites]


This would be interesting to see on the Time Crystal demo (the only C64 game I can recall which managed to write beyond the usual screen area into the border areas).
posted by crapmatic at 9:29 PM on March 10, 2010


Watching the remapping and decompressions between the intro screens really brought back memories. It looks exactly like what was in my mind's eye back then when visualizing what happened in my code - I hand-coded several different compression/decompression schemes in assembly on the C=64, most based on math books my buddy and I checked out from the local college. We were pretty young at the time - probably early high school. Imagine coding Lempel-Ziv compression algorithms in a Machine Language monitor, and you know what my social life was like :/

At one point, we compiled a demo that consisted of about 15 different screens, each bootstrapped from the last, which stopped to load a second side of the floppy.

Our crowning achievement, though, was to write a "boot-sector" virus for the 1541/C=64. It never made it out of my room, but it worked. It was on a specially-crafted vector disk, with it attached to the front of a program file. When run, this program file would patch the 1541's code so that any disks that were inserted until the next reset would: Check the unused blocks of the directory for itself, write itself there if it wasn't there, and then re-write the directory to include itself first on all program files. The patched programs would load and run the virus first, and then remap the attached program and execute it. This was all done silently (except for the disk access).

Really just a proof-of-concept, since we didn't think anyone had done it before.
posted by tomierna at 9:40 PM on March 10, 2010 [6 favorites]


This visually explains why copy protection will almost never work.
posted by stbalbach at 9:57 PM on March 10, 2010 [2 favorites]


I ♥ C=
posted by signal at 10:00 PM on March 10, 2010


This video contains content from Sony Music Entertainment. It is no longer available in your country.

Could someone summarize what Sony Music doesn't want the rest of the world to know about the C64?
posted by wanderingstan at 10:09 PM on March 10, 2010


Could someone summarize what Sony Music doesn't want the rest of the world to know about the C64?

How much more awesome it is to hack a C64 with the soundtrack to The Matrix running in the background.
posted by delmoi at 10:11 PM on March 10, 2010 [1 favorite]


Needs more connecting pins with a paperclip.
posted by obiwanwasabi at 11:00 PM on March 10, 2010


This is incredibly awesome. I can't wait to see what he does with the SID chip.
posted by jeffj at 11:03 PM on March 10, 2010


There's more on the creator's blog, including this interview.
posted by jeffj at 11:16 PM on March 10, 2010


Here are some backup links in case it gets removed or you can't see it in your country.

1 - 2 - 3

To play back download VLC or drag and drop into your browser.
posted by loquacious at 11:20 PM on March 10, 2010 [1 favorite]


Man I spent years in therapy trying to forget about my grandpa's PEEK and POKE, and now you bring it all back up again.
posted by chaff at 11:43 PM on March 10, 2010 [4 favorites]


Well, you know what they say about teaching your grandpa to suck bits.
posted by loquacious at 11:51 PM on March 10, 2010


$100 says Hugh Jackman has nothing to do with this.
posted by Blazecock Pileon at 1:53 AM on March 11, 2010


More on ICU64; another thing they do with it is build custom GUIs for C64 games in emulation. (Want to see the entire Paradroid deck map on your PC monitor?)

Unfortunately, it seems to be Windows-specific.
posted by acb at 3:46 AM on March 11, 2010


POKE 53281,0 would turn the screen border black; POKE 53280,0 would turn the main screen black.

If that is correct, then I really did learn something in 10th-grade computer class.

If it is wrong, THANKS FOR NOTHING MR. WYSOWSKI.
posted by Shepherd at 5:50 AM on March 11, 2010 [2 favorites]


I really needed this 25 years ago.
Now... just don't have the time. I used to have Frodo, but all I can find now on my laptop is VICE.
This looks incredibly useful. (If you need that sort of thing)
I like watching the screen mapping going on in 2 places at once.
posted by MtDewd at 6:55 AM on March 11, 2010


This is fascinating, and makes me misty-eyed about the hundreds of hours I spent hacking around with BASIC on my C64 as a kid. Eventually I got an advanced programmer's guide... I believe it was published by Commodore, and was basically a top to bottom guide covering all of the system resources available to developers, including how to implement low-level assembly instructions.

Most of it was way, way above my head, but somehow managed to grok just enough about assembly to write a program that POKEd a bunch of bytes into just the right spots in memory, and then with the mysterious SYS command flipped a bit somewhere to use that data to draw all the characters on the screen, instead of using the ROM's baked-in display font. (I calculated the bitmasks for each 8x8 pixel character by hand, after drawing each glyph on graph paper.)

Yeah, that was what I did while my peers were out playing little league.

I'd love to load my old program into this and be able to actually see the memory space, which was so abstract at the time. If I had been about 5 years older in the early 80's, I probably would have become a "real programmer" a lot sooner than I did as an adult.
posted by usonian at 8:14 AM on March 11, 2010


usonian-
C64 User Manual
C64 Programmer's Reference Guide
Memory Map
-have at it!
posted by MtDewd at 8:37 AM on March 11, 2010 [2 favorites]


Programmer's Reference Guide! That's exactly what it was, many thanks MtDewd!
posted by usonian at 8:42 AM on March 11, 2010


Here are some backup links in case it gets removed or you can't see it in your country..

Hate to say it, but I was nearly shaking with rage when one of your Senduit links wanted me to wait for a whole minute staring at an ad (which didn't even load) before telling me it couldn't download due to "a technical difficulty." Graah.

As for the link, well, I guess it's a little-known fact that you can do this, in a way, on an actual, completely unmodified Commodore 64.

The C64's text screen is simply a kilobyte-sized section of system RAM the VIC-II video chip has been directed to display. That, combined with another K of memory used for color data, is the entirety of the display in character mode. But the operating system really doesn't care where the VIC-II is getting its display data; with a simple poke (I think it was to 648 but it's been decades since I learned it - this page confirms I'm right) you can set the spot the OS considers to be the screen region to begin on any page of memory.

The change happens immediately, and is independent of where the video chip actually gets its graphics data from. If you set the system screen to be different from the visible screen you end up typing blind, but in all other respects it works perfectly. You'd probably want to set it somewhere that doesn't overwrite important memory or is covered by ROM, and you'd also want to do a CLR SCRN right away to get rid of the random garbage that was already there and reset the "line links."

To change the location of the physical screen is just a little harder. There are two locations that need changing. One determines which of the "memory banks" the VIC-II has access to. The chip only sees one 16K block of memory at a time out of which must come all of the graphics data you're using. Since the computer has 64K of memory, that means there are four possibilities. The relevant register is 56576, or $DD00. (This register actually is in the second of the C64's two CIA memory management chips.) The other is 53272, $D018, which tells the VIC-II where in that bank to get its data from.

By writing to these two locations, you can determine which 16K section of memory the video chip gets its graphics data from, and which 1K section of memory within that it gets the screen from. In fact, the screen is determined by the high bits of 53272; by changing the low bits, you can also tell the chip where to get character data from, that is, the graphics information displayed for each character shape.

Aside: I must have been about 13 years old when I was playing around with my Commodore 64, trying things from out of the Programmer's Reference Guide, and managed to piece together what these facts meant. It meant that the computer didn't actually care what the characters looked like. It was just data to it. That data had to come from somewhere; it got it out of a "shadow" area of ROM only the VIC-II chip could see, but it was still there. If I changed the bits in 53272 so it got character data from elsewhere, then immediately the whole screen turned to garbage, since none of the characters on screen has sensible bitmap representations anymore. However, if I typed things, the general areas on the screen where I typed still changed. They just changed from garbage to different garbage. If I typed blind a POKE to change it back, then the screen turned normal again. Furthermore, if I POKEd my own character bitmaps to the part of memory the VIC was getting its data from, I could define my own character set. This is a powerful sort of revelation for a 13-year-old kid; it may have been the moment I began to realize that maybe my C64 wasn't a magic box after all, put together by what amounted to wizards, whose mental processes were foreign to me. I started to think, maybe there is a kind of logic here.

It's sometimes called the text screen, but really it doesn't have to be "text" at all. Each byte of the character memory represents one of the eight-byte character representations in the character data. That data can be letters, or line-drawing graphics, or playfield tiles, or little pieces of a larger bitmap image, whatever you put there. What matters is the mapping, the procedure the VIC-II uses to look up the character data working from the screen data.

Well, it turns out there is another mode the VIC-II can use to get its video data, bitmap mode. Instead of getting each eight bits of graphics data from referencing a kind of pointer, it can just get them linearly, starting from one spot in memory and going forward, no referencing done. It still does them one character at a time, that is to say, eight bytes going down then moving back up for the next tile, but it's still a one-for-one representation of memory. Since each of the 1,000 character cells has all its data provided in line, instead of referenced from a tilemap, it takes eight times as much data to display, so there is only room for two such "hi-res" screens in one 16K video bank.

Now to tie this all together. The OS also doesn't care if the VIC-II is in hi-res mode or not. If you set the memory bank to 0 (which it is by default actually), switch it to hi-res mode and set the bitmap area to the first 8K of the bank, you'll get the first eight kilobytes of memory displayed on-screen as raw pixels. The first K of data is among the most interesting in the entire system, containing all of the OS-important locations, including zero page, the first 256 bytes of memory which is a bit more flexible in its uses under the 6510 chip that powers the C64 and so is being used all the time. Many of these bytes change in interesting and weird ways constantly while the computer is on. In fact, the whole "normal" screen is in that 8K as well! Filled with spaces, this shows up as an area filled with one-pixel-wide lines. (The space character is 32 in the C64's numbering scheme.) The C64's blinking cursor, which is implemented by flipping the high bit of one of the characters about twice a second, shows up as a single pixel blinking at the same rate, and as you type things eight-pixel lines of garbage appear over and over. BASIC program storage begins at 2049. If you enter or load a program into memory, it'll start appearing as garbage one-fourth the way down the screen.

You can do anything with your computer in this state as you could normally, including run programs. So long as the software you run doesn't change the video registers itself (which is unfortunately the case with most games) you can watch the system variables directly in operation as the program, and the OS functions that run it or are called by it, does their thing. It doesn't have nearly the UI pizazz as ICU64, only displays 8K at a time, and the ordering isn't linear (because of that eight-byte cycle), but it essentially performs the same trick.

POKE 53281,0 would turn the screen border black; POKE 53280,0 would turn the main screen black. If that is correct, then I really did learn something in 10th-grade computer class.

Mr. Wysowski's lessons were learned well.
posted by JHarris at 9:18 AM on March 11, 2010 [7 favorites]


(Er, except that you got the numbers mixed up. 53280 is the border, and 53281 is the background.)
posted by JHarris at 9:18 AM on March 11, 2010


On further examination/remembering with WinVICE, it turns out that memory is all set up at power-up for the technique I described. All you have to do is turn on the bitmap display with POKE 53265,187 . POKE 53265,155 blind to turn it back.

You can also just set screen display memory to the first K of memory instead, to see that memory as characters instead of pixels. POKE 53272,5 to do that, POKE 53272,21 blind to go back.
posted by JHarris at 9:41 AM on March 11, 2010


I actually did stuff like this on my first PC, which I didn't get until I was in high school, a Pentium 75. I found an old copy of Borland's Turbo Assembler and and did all that stuff, writing to graphics memory, making the computer beep, and, that was pretty much it. All in pure x86 assembly. My biggest pure ASM program was a little drawing program that would put a dot on the screen wherever the mouse was. This was after I hard taught myself C++ programming using Borland's Turbo C++, and then I moved on to Java, Javascript, Win32, etc. But there was always something deeply satisfying about messing with the guts of the machine at the lowest level.
posted by delmoi at 10:21 AM on March 11, 2010 [1 favorite]


The TRS-80 was also configurable by POKE. One address would disable the BREAK key; another would change the cursor character. I imagined the rest of the addresses were just as magic, and if I only could get a complete memory map...
posted by kurumi at 10:33 AM on March 11, 2010


Dear nerds of MetaFilter,

Thanks for writing down all my childhood memories of my C64 so I didn't have to. You're the bestest.

Also: I learned how to use the disk hex editor on the FastLoad cart to change all my saved games and cheat like hell. You can't learn like that anymore.
posted by GuyZero at 10:54 AM on March 11, 2010


I once deveoped a cheat for some platform game by dumping the entire memory of an 8-bit Amstrad CPC464 and searching for all instances of a value of 5 (which was the number of inital lives the platform game had), and then sequentially test-poking that to 255 until I found the memory location for lives.

Sad but true.
posted by lalochezia at 10:57 AM on March 11, 2010 [1 favorite]


I have my own self-made cheat story. There is a budget game for Commodore 64 called Phantoms of the Asteroid. It is amazing, especially for the time, a vast game world with seemingly endless caverns to explore and lots of colored step pads to figure out what they do. Except it is really a hugely difficult game, you're constantly running low on air, energy and fuel, you can only replenish them at certain points in the huge scrolling world, each replenishment point has a limit and is gone when it runs out (I never did figure out if one of the pads reset them), nearly everything is deadly, there are annoying time puzzles and it's very easy to get into an unwinnable position. And to win you have to look everywhere for 36 cubes, it's easy to miss some and the game has absolutely no map feature.

Eventually what I did was find the spot in the game I had to go to win (it took a while to find all by itself but it was easy to figure out I had found it, the goal pad was just special somehow), then saved the game. I started a new game and saved right away, then found one cube, saved again, then compared the two files. Eventually I managed to deduce that 36 contiguous bytes in the save represented the 36 cubes. I filled them all in the at-end save, loaded that into the game, was heartened to discover my cube inventory was full, landed on the pad and won!

It was tricky enough to figure out that it didn't feel like cheating at all. The ending music is pretty awesome, too.
posted by JHarris at 11:13 AM on March 11, 2010


The meta-game of figuring out how to hack C64 games was far more instructional than the games themselves. FastLoad disk editing taught me how basic disk filesystems work. Directory was on track 18 in the middle of the floppy. Sectors were linked via their leading two bytes, etc etc.
posted by GuyZero at 11:31 AM on March 11, 2010


I didn't get much further than BASIC on the C64, but I turned out all right, and today I'm an embedded real-time systems software engineer. This video brought back some memories, though, and would have improved my understanding to no ends back when...
posted by Harald74 at 12:44 PM on March 11, 2010


wow. can someone tell me whats going on in the link?
posted by uni verse at 2:21 PM on March 11, 2010


uni_verse, all those squares represent different words in the memory of a Commodore 64 emulator. Hacker guy is zooming into the particular square he wants, clicking, and changing the value of that word. This allows him to give himself extra lives and score and such in the game he is playing. This is the way memory hacking works everywhere; GameSharks do the same thing. The interesting part is the visualization. Being able to really see the memory that way is neat.
posted by LogicalDash at 4:09 PM on March 11, 2010


I too had more fun hex editing to cheat* on my C64 than I did playing games. My hack of choice was my character in Ultima 4 (and the Ultima series led years later to the nick I carry to this day).

* Cheat my ass. Figuring that stuff out was a lot harder than the brain-dead grinding my friends had to do to to level up.
posted by djeo at 8:26 PM on March 11, 2010 [1 favorite]


This visually explains why copy protection will almost never work.

Funnily enough he's using a pirated version of the game. The first screen that comes up has scroll text shout outs in it.
posted by inpHilltr8r at 3:18 AM on March 12, 2010


I was kinda impressed at first. But then realized I've done this, on the actual machine, without fancy graphics to help. So. Yeah. You young punks and your rock and roll video films do not impress me.
posted by chairface at 11:21 PM on March 12, 2010


« Older The Secret Origin of Windows, recollections of the...  |  Vintage German illustrations, ... Newer »


This thread has been archived and is closed to new comments