module
35
You can sit at an Einstein with a disc that has a compiler on it, type a program in an editor, compile it and run it - which, S2 said, is the thing this course is really about. You can read the compiler's map and its errors. You know what an int is here and what it is not, where a string ends, why a pointer steps by two, what a structure costs and what it may not do, where the stack is and what happens when it runs out. You have read two libraries and found a bug in one. And you have a game, with a title screen, that fits in ten kilobytes.
You have also learnt a dialect. That is worth being clear about, because the next C you meet will not be this one.
HiSoft C is K&R C from 1985, small enough for a 64K machine, and it says so. The gaps you have met are the gaps you will fill elsewhere:
RESTRICTION: Floating Point not implemented (S9). Every larger C has float and double; a course that used them would have been about arithmetic, and this one was about the machine.int f(int a) is an error here (S13) and the rule everywhere after 1989. The habit that carries across is the one the course insisted on: count the arguments at every call, because here nothing else does.#ifdef and #define SQ(x) (S19) are in every other C. The function you wrote instead is not wrong; it is slower.x and the ball's x by the same name.unsigned char, local initialisers, declarations in blocks. Small things, all refused here (S9, S10), all everywhere else.A second edition of the manual came out in 1988, still for this machine among others, and what it changed is not known to this course. If you find a later HiSoft C for the Einstein, S2's stance applies: what it does is what it does when you run it.
Down. S23 and S25 showed the floor: inline, mcal, the MOS calls by number, the video chip on ports 8 and 9, the frame flag on port 9. All of it is Z80 machine code seen through C, and the assembly course on this site is the same machine from underneath, with the same reference behind it. A C programmer who reads it will recognise every number.
Sideways. There is another C for the Einstein in the site's collection: C/80, from The Software Toolworks, 1983 - a compiler that writes assembly source, an assembler, and a linker, in three steps where HiSoft's takes one, with its own library and its own gaps. It is a different dialect again, and everything this course said about importing knowledge applies to it in both directions.
Up. Every C after this one is a superset, more or less, of what you have used. A modern compiler will accept every program in this course once the two #include lines are changed and cast(name) is written (name) - and it will warn about the things this compiler did not check. Those warnings are the argument counts, the missing returns and the stray ; after a #define that you have been finding by hand. Take them.
BREAKOUT.C is about 300 lines. It has a bat that moves one column a tick, a ball that moves one square, four rows of bricks in four colours, three lives, a level counter and a beep. Exercise 33.2 gave it a high-score file. What it has not got is a second player, a bat that shrinks, bricks that fall, a ball that speeds up in the middle of a rally, or sound worth the name - and every one of those is an afternoon with what you know.
The rule that made it work is the one to keep: draw what changed, and keep the state in the program, not on the screen. It is the rule every game on this machine follows, in every language on this site.
You have written C on the Einstein the way it was done. This compiler is a small K&R C with rules of its own, and you know which they are. Down is the assembly course; sideways is another C; up is every C since. The game is yours to finish.
