(hide navigation)
  • Swedish content
Fund my projects
Log in
Latest comments
RSS feed

Forum comments in chronological order

Disclaimer: I am not responsible for what people (other than myself) write in the forums. Please report any abuse, such as insults, slander, spam and illegal material, and I will take appropriate actions. Don't feed the trolls.

Jag tar inget ansvar för det som skrivs i forumet, förutom mina egna inlägg. Vänligen rapportera alla inlägg som bryter mot reglerna, så ska jag se vad jag kan göra. Som regelbrott räknas till exempel förolämpningar, förtal, spam och olagligt material. Mata inte trålarna.

May 2013


Sat 4-May-2013 21:16
Fratres,is it based in Passacaglia form?

Kernighan's lever

Sun 5-May-2013 19:46
Interesting essay with some valid points, but the context lacks depth: it is one thing to do this because it is a hobby, quite another if one must walk the very delicate line of writing code easy to debug in consideration of others, because one is an entrepreneur, racing against the clock. "When are we going to ship?"

You are probably privy to the Zen of "software is done when it is done!", which means that writing quality code must necessarily avoid cleverness in favor of maintainability: if one is an entrepreneur, one must eventually ship, or the startup will bust.

Rule of clarity: clarity is better than cleverness

"Because maintenance is so important and so expensive, write programs as if the most important communication they do is not to the computer that executes them but to the human beings who will read and maintain the source code in the future (including yourself)."


Rule of representation: fold knowledge into data, so program logic can be stupid and robust

"Even the simplest procedural logic is hard for humans to verify, but quite complex data structures are fairly easy to model and reason about. To see this, compare the expressiveness and explanatory power of a diagram of (say) a fifty-node pointer tree with a flowchart of a fifty-line program. Or, compare an array initializer expressing a conversion table with an equivalent switch statement. The difference in transparency and clarity is dramatic."

Sun 5-May-2013 19:53
I would also like to leave you to think about the following:

anyone can write clever code; anyone can write complex code; anyone can over-complicate...

...but if you are really, really smart, make a complex thing simple! Can you go the other way, can you effectively simplify complex things? That is true smarts, because it is incredibly hard to do, and requires one to be extremely smart, knowledgeable, and experienced. Not very many people can do it, even among the smart.


Martin Schulte
Tue 7-May-2013 13:54
Great! Do you consider releasing the soundtrack?


Wed 8-May-2013 18:40
Rather than parsing the replay routine and doing all this analysis, would it not have been cheaper to just extract the data, and write one's own replay routine?

I mean, most of the $1000-$1003 tunes were made in a limited set of music programs, were they not? And $1800 tunes, there is only one culprit, Future Composer, whose format should be well understood, well enough to construct one's own relocatable replay routine (if using Future Composer's own relocation capabilities is not desired). That should cover 90% of tunes out there, should it not?
Wed 8-May-2013 18:44
What C=64 code really needs is support for executable and linking format ("ELF"). Writing ELF headers from Turbo Assembler is no problem, but something should be able to read and parse the global offset table ("GOT"), which is exactly what is needed here for all these SID tunes (not the data itself, of course, but for a truly relocatable replay routine).

So maybe a little "shim" routine which would act as the runtime linker for dynamic objects, ld.so.1?

Hmmm, that might be a cool next project for me to implement, hmmmmm...

A Chipful of Love For You

Thu 9-May-2013 01:11
Wow, that sounds great!

The hardware chiptune project

Sun 12-May-2013 11:33
Greetings from Aus.

The Hardware Chiptune Project is a work of Genuis!

I love your work and your website; I do hope you make other tunes with a similar orchestration in terms of the waveforms used. I hope to build something like this myself when I get the time. You're an inspiration!


Mon 13-May-2013 01:52
The soundtrack is released, in that it's part of the (released) source code (see sfx.c).
A pre-rendered MP3 would indeed be nice, I you meant that. --jn
Mon 13-May-2013 12:25
The soundtrack is released, in that it's part of the (released) source code (see sfx.c).
A pre-rendered MP3 would indeed be nice, I you meant that. --jn

Yes, that's what I meant. :)


Wed 15-May-2013 23:44
That's awesome work there!
Just wondering, are you going to open up some of the guts of your build?
I would really like to tinker around with it, but am clearly lacking the skills to pull this off :(

A case against syntax highlighting

Stephen Holtom
Fri 17-May-2013 11:40
In addition to the points mentioned above, I'd like to point out that some skimming is *good*.

For example, say a string literal is being passed in a function call. In essence, there are two bits of information for a programmer to be aware of:

1. A string literal is being passed
2. The contents of the string

Now, it is *right* that those things can be considered separately. It's right that I can saccade past the contents of the string if right now I'm not interested in that argument, and need to examine another argument to the function more closely.

It is wrong to be forced every time to track my eyes across carefully, and find the closing quote, before I can look at the next argument to the function. These little inefficiencies add up.

The analogy with a novel is false. A novel must be read in a linear fashion. For most modern code paradigms it's not even clear what linear would mean (a source file, a stack trace, an inheritance hierarchy?). Furthermore the English language does not have the same kind of formal syntactic structures as code: function calls, literals, operators, macros etc are not merely different kinds of words.

The TTY demystified

Sat 18-May-2013 11:57
So much for the 'age of information'.

Well, it is the age of information. Noone said it was the age of wisdom.
Sat 18-May-2013 12:08
"yes" program , produced in 2009 !

Thank you David McKenzie for your contribution to open source community !

I am just wondering what in your background that enabled the FSF to accept such worthless contribution ?

Member of what masonic lodge or what church or son of a war hero or billonarties you have to be so they accept that piece of crap ?

For reference:

yes command - otputs a line on tty until killed !

coded and added to Linux in 2009.

Actually, "yes", which is part of GNU coreutils, has been around since, like forever, being an implementation of the same-named Unix command.

David MacKenzie is the author of many of coreutils' commands, including chgrp, chmod, chown, date, dirname, expand, fold, ginstall, groups, head, mkdir, mkfifo, mknod, nice, printenv, printf, rmdir, stty, su, tty, uname, unexpand, and obviously yes; and is co-author of many others. But he is probably best known for autotools, which is one of the most central pieces of free software, as any distribution maintainer could tell you.

Now, what have YOU done for GNU or Linux or free software?

Spindle v1

Sat 18-May-2013 23:01
Very well done!
Klemen Verdnik
Wed 22-May-2013 10:52
you're one crazy sonofabitch! :) that's one hell of a job you did there. I can't wait to see the fluidity of other demos using this tool.

And the example demo you provided is also cute (music, plasma and the morphing logo).

I really like coming to your site, you really amaze me :) Any chance you'll be playing around with Propeller II, when it comes out (or with the FPGA version)?

Getting string input (TI-83 assembly programming)

Sun 26-May-2013 17:21
How to do in x86 assembly ?

A case against syntax highlighting

Stephen Holtom
Mon 27-May-2013 05:11
It also occurs to me that you've had a bit of a free pass with the "seeing the woods for the trees" comment. It's the kind of statement that seems intuitively right, and most programmers at first glance would consider it to be important.
But on reflection, I don't believe it is important, or even correct.

For any sufficiently complex program, abstraction is incredibly important.

When I'm writing a class I should be concerned with just what that particular class does. And in terms of calling other classes, it should be safe to forget how they internally work. If I can't do this then this implies poor design and a creaky system. And needless to say, there should not be global variables, or shared states. I should be able to focus on a single method at a time because everything is so neatly encapsulated.
So being able to work at the "trees" level is actually an ideal.

Now I'm sure you'll say that what you mean is the big picture: an awareness of what the whole shebang is doing, and is for.
But again, for sufficiently complex programs that level is far above the level of actually looking at source code. Understanding the big picture, and your preferences for displaying code, are very far removed.

Making the Chipophone

Wed 29-May-2013 23:57
i just stumbled upon this through youtube. i am amazed you did this all on your own!! you guys in sweden are bad ass :D have the best day!!