Hacker News Reader

Comment by dusted | Hacker News Reader

Screen does not start at 0 so your poke won't place anyhing on screen (actually, address 0 is the PORT register on the 6510 iirc).

POKE X CHR$(209) is not valid syntax, POKE takes a memory address (in decimal) a COMMA and the value (0-FF) in decimal.

Also.. CHR$ converts an ascii value to a character.. you don't want that here..

Also.. the character color has not been set under the ball, so it won't show up on most of the screen-area..

Screen memory starts at 1024, color memory at 55296 so to show your ball, you'll do

POKE 1024,209 POKE 55296,1

Also, you should use 81 and not 209, since the machine is in uppercase mode, and 209 is the inverted circle in that mode.

Why spend the time to write an article with examples that do not actually work?

View on HN

You skipped the foot notes?

> The emulator implemented here only supports POKE for accessing screen memory. To keep things simpler, it starts at offset 0 rather than at offset 1024 as in the real Commodore 64. When you access an invalid address, e.g. by waiting until the ball runs off the screen, the operation fails and the program execution will stop.

He doesn't need a full emulator to show the principle.

I actually did skip those, I never made it that far.

I was using the page in C64 reader mode (due to the colors making it impossible for me to see anything) and so I never realized that the image to the right was actually an emulator, I thought it was just a screenshot.

My fault ^_^

Still though, in my opinion it'd then be better to skin the thing as something other than a C64 so as not to avoid the confuzion for no reason.

> I'm not trying to create an accurate Commodore 64 simulator though. The point is to show a few things that we can learn from for future programming systems.

Apparently you haven't bothered to read the manual.

I agree with the author, one thing great about these systems was having BASIC as a kind of systems programming language, with high level niceties, and a REPL.

Something that younger generations taught in the ways of C have no idea how it went.

It is no small feat that what is essentially pre-debugged C64 Basic psuedo-code, is yet dynamically illustrated quite nicely by bespoke javascript rather than a pulled-in browser c64 emulation module. Besides the unusual errors in the displayed code, the lesson seems to flow nicely and I think may be great when "actualised" to actual c64 Basic. I only missed not being able to scroll the screen with arrow or space keys, mobile and mouse wielding readers may not notice that issue.

This is a really weird little simulation of a faux-64.

The virtual machine is not in uppercase mode, typing stuff into it goes in as lowercase and doesn't get properly parsed. (This might be a Safari bug).

As far as I recall there was no DELETE keyword, which this thing uses instead of NEW.

Different revisions of the C64 ROM did different things with regards to clearing the color memory when clearing the screen, my early c64 would set it all to white, while later revisions would (I think) set it to whatever the current character color was.

I guess this is trying to simplify things somewhat to make its points about the power of booting up straight to a BASIC prompt, but it sure does annoy anyone who spent time hacking on a real c64!

Why so harsh with the poor guy ? He just followed best practices from the industry and let the customer test it.

Reply on news.ycombinator.com