Wednesday, 31 December 2014

Top Western movies

I gathered my thoughts and wondered what might be the best Western movies in my opinion, at the present moment. I've seen more than 250 and viewed the better ones several times.

The list contains films I've "Facebook-ranked" with four or five stars. The order is not very thought-out, especially when going further than Top 10. But in any case I would perhaps build the list differently at different times.

Edit 4.8.2016: I added a couple of pictures and tightened the text a bit. The list stays the same though.

Once Upon a Time in the West

.1968 Once Upon a Time in the West (Sergio Leone)

I'd like to present something less typical as the "best western ever", but I can't avoid it. It is such a great summary of the genre, and works on so many levels.

.1968 The Great Silence (Sergio Corbucci)

I'm not going to let Leone entirely dominate the top 3. The Great Silence is bound with intriguing visuals and the fantastic Morricone score. Corbucci shows an almost supernatural wintry West, even harder than the normal west, where a normal western character does not survive long.



.1966 The Good, the Bad and the Ugly (Sergio Leone)

The Western "small story" opens up into a war movie, the three protagonists worming their way within the chaos around them. Ultimately, it does not have all the depth of Once Upon...

.1971 Duck, you Sucker! (Sergio Leone)

This is not often rated very highly, supposedly Leone even distanced himself from the product. What is now available is a sort of reconstruction. I consider the themes in it to be very moving, and I usually like James Coburn better than Clint Eastwood.

Duck, you sucker!
.1952 High Noon (Fred Zinnemann)

High Noon is able to combine psychological and social "political" themes without making them too underlined. Tends to get better in multiple viewings, almost as if the ultimate outcome - the one we keep waiting for - didn't matter all that much.

.1970 The White Sun of the Desert (Vladimir Motyl)

Perhaps not strictly a western, but clearly plays with Western themes within a war setting, albeit in smaller way than, say, the Good, Bad and the Ugly. The tempo, tones, compositions, editing and generally everything shown on-screen are so delicately put that it doesn't even much matter if the plot is fairly simple. I almost expect Corto Maltese to show up.
Some villains from The White Sun of the Desert.

.1969 The Wild Bunch (Sam Peckinpah) 

An all-around classic film.


.1982 Barbarosa (Fred Schepisi)

One of the first post-1960s movies that tried to positively re-affirm the Western hero myth, yet still remain revisionist.
Willie Nelson and Gary Busey in Barbarosa.
.1971 McCabe & Mrs. Miller (Robert Altman) 

This is probably the peak of "revisionism" in Western movies. The scenery and the Leonard Cohen soundtrack remain haunting.



.1962 The Man who shot Liberty Valance (John Ford)

I'm always astonished how this film manages to provide a very grand scenario and at the same time a small, but interesting, Western story. The only John Wayne film here.



.1966 Big Gundown (Sergio Sollima)

One of the "political" spaghettis made by Sollima. Face to Face may be better as a more serious work, but for once I feel the humour, music and extravagant characters are spot on and do not detract from the broader themes.



.1967 Face to Face (Sergio Sollima)

The more serious of the Sollima Westerns, the plot and the "moral" delivered are both interesting yet boiled in a good spaghetti styling.

.1959 Day of the Outlaw (Andre de Toth)

Another winter movie and a true original. A really gripping scenario that just gets tighter all the time. The winter environment is well integrated with the plot.

.1954 Johnny Guitar (Nicholas Ray)

Yeah it's a bit theatrical but somehow even that functions to serve the expressiveness and psycho-dynamics between the characters. It's a rare time women get the spotlight in a Western without everything becoming a silly affair.

Johnny Guitar
.1965 For a few Dollars More (Sergio Leone)

This one I would have previously ranked higher, but recent viewing revealed there are many spaghettis I prefer to this one. Some of the best Lee van Cleef material here, though.



.1976 Keoma (Enzo Castellari)

The last really significant spaghetti western, Keoma is pretty ingenious work, especially due to the music-image synergies and editing. On occasions I can't help feeling it's more of a "best of the guilty pleasure movies" than a truly, truly great movie.

.1971 Lawman (Michael Winner)

This film plays well with the elements of classic western yet turns them around. The revisionism is not for revisionism's sake, but helps deliver the moral problem for the viewer's consideration. Rarely, if ever, have the motivations of "small time henchmen" bad guys been fleshed out so well.

1973 Pat Garrett and Billy the Kid (Sam Peckinpah)

This is a more uneven film than the Wild Bunch but I've found it emotionally satisfying. The focus is clearly on Pat Garrett here, which James Coburn delivers as the more interesting character.


Some good sound-visuals combinations with the Dylan soundtrack (that "knocking on heaven's door"...), but Dylan's presence in the film is perhaps less successful.

.1990 Dances with Wolves (Kevin Costner)

I thought it predictable at times, but then again things that sort of needed to happen, happened. I suppose for a certain generation it's almost impossible not to know something about the film even if you've not seen it.

.1960 The Magnificent Seven (John Sturges)

Initially I did not think much of this, it seemed to have all the hallmarks of what I consider a boring western, but it has grown on me.


.1987 A Man from the Boulevard des Capucines (Alla Surikova)

A Soviet "Western", but not bogged down with the kind of politics one might expect. It's not often that stunts, acrobatics and technical hijinks manage to support a Western film well, but here it happens.

.1952 Viva Zapata! (Elia Kazan)

Maybe not a Western either, and perhaps a bit suspect politically even, but the story arc works well for me and leads to a great ending. Hilariously Marlon Brando cuddles some puppy dogs.

.1951 Westward the Women (William Wellman)

Many Wellman Westerns would deserve to be mentioned (The Ox-Bow Incident, The Yellow Sky, Track of the Cat) but this has a more grand scenario, with appropriate humor and seriousness mixed in good proportion.



Edit: Recently I have watched the three and a half hour version of Heaven's Gate (1980, Michael Cimino) and the zapata-western Tepepa (1969, Giulio Petroni). Both might easily be included, but of course the list reflects the situation by the end of 2014...

Thursday, 25 December 2014

Merry Xmas PETSCII


It's been some time since I've tried to do PETSCII graphics. It took a surprisingly long time, a few re-starts and a night's sleep to do, even when the aim was to do a simple thing.

The entry listed at csdb, in case you want to download an PRG file for the C64/VICE.

http://csdb.dk/release/?id=135563

The PETSCII editor itself:

http://www.kameli.net/marq/?page_id=2717

Monday, 15 December 2014

Lego car drawing


In this picture, I tried to recreate an early 1980s Lego Technic steering mechanism, bit like in the 854 Go-Kart. It's drawn and painted from "memory". It's not too hard to remember, because while drawing the blocks pretty much begin to suggest each other.

Some mistakes/thoughts:

-The cog would not fit where it is now, the steering mechanism box is too low.
-The back part of the car frame is not held together (though I did leave it vague deliberately).
-There's too few Lego knobs on the right side angular bar :)
-The steering wheel frame is probably a bit too front to make that angle possible (though it's hard to judge)
-The steering mechanism overall is unnecessarily wide (Compared to Lego model 854)


Above, one of the earlier sketches, just before starting the top image. (A few unrelated sketches have become overlayed here.)

Below is the second take. I took a different angle that would show the part relations more clearly. The perspective came out a bit wonky, but as an illustration it's a bit clearer. In places the mistakes could even be fixed, but I don't want to do too much overpainting. As an image, I feel the red one turned out better.

This version, I think owes even more to the old 854 Go-Kart.



Addendum: I made the car from available parts, also changing some things as I went along. The proportions of the steering mechanism are a bit off in the above image, although it is not very obvious. The steering wheel frame was far too tall, and the car was too long to be well-proportioned. (But this is more a matter of taste)


Saturday, 13 December 2014

Western Games

Here's a six cylinder-ful of western games from the 8-bit era (Spectrum and C64 games). I tried to look past the usual action shooters and check out more complex gameplay. This bunch would make neat premises for new games with only modest changes and additions.

West Bank (ZX Spectrum)

Ok, I'll start with a bit of a shooter anyway, but it is an unusual one. As far as I know, this is a direct copy of the arcade game Bank Panic. There are 12 doors to your bank, and three of them are visible at a time. The doors open quickly, with customers approaching. Or a bank robber! The villains are shot simply by pressing the key that corresponds with the door, which I find more fun than if I had to aim at them. Shooting the bad guys before they shoot you gets you forward, whereas shooting an innocent person will set you back.

At the Weird West Bank.
There's honest looking folk, something that looks like a bar singer, thieves with covered faces and so on. The friendly folk bring their bags of money, whereas the nasty folk bring their guns. And it's not always easy to see which way they turn out to be. Often, a tiny "clown" type of character with about 7 hats, appears. Shades of some of the more surreal Spaghetti westerns here, I suppose... Shooting all of the hats reveals either a bomb or a bag of money. A nerve-wracking procedure!


Wild Bunch (ZX Spectrum)

Nothing to do with the Peckinpah film! Here the player takes the role of a western hero who has to fight the "wild bunch" gang. This simple multiple-choice adventure has a western simulation feel, with maps, several towns and various buildings to visit. Lots of stuff can be bought from the general store, and you can enter a saloon to play poker and so on and on.

A wild bunch of equipment, not that it makes that much difference.
One clever idea is that the members of the wild bunch gang are presented as Wanted posters with identifiable features. When you meet strange people, you are given a description and you need to decide whether they have to be challenged.

Left: One of the Wild Bunch. Right: Go west, young man...
It's quite apparent that the game is based on the numerous space trader type text games, and nothing wrong with that. It's not exactly "Elite in the West", though. It's far too intense for me to take notes about the townsfolk's appearance, but that's it what it takes if you want to win. Or you need to have a super-memory. Fighting, what I've seen of it, is too simplistic. The player pits his "energy" against the plethora of snakes and critters you meet each day you work your way through the never ending desert.


Gunfright (ZX Spectrum)

Ultimate's latter-day outing. They had run a bit out of steam at this stage and this game (alongside with Cyberun) received mixed reviews at the time. Portrayed in a scrolling isometric 3-D, pretty flat here to be honest, the game at first sight appears to be a full-blown western town simulation, with money, bullets, fares, telegram and whatnot.

-Where did you get that tin star, at the carnival fairground?
-As a matter of fact, I did.
-Oh.
Yet this is all mostly sheen, the designers have opted for a quite surreal interpretation of a western town, a haunting collection of bare-bone elements floating against a black background. Not that it's all a bad thing, but most of the game is about avoiding the townsfolk than fighting the rather sedately moving villain. Also, despite the facades, the buildings are just empty frames in a sparse maze. At least once you get the (hobby) horse you can zoom past and through everything and everybody. It all costs money, though.
It's a horror...
Scared townspeople point at the direction of the villain, which is a nice touch. After finding and "shooting" the villain in the main view, the perspective is switched to a first person target-game/quick-draw style showdown.


Six-Gun Shoot Out (Commodore 64)

A seemingly complex tactical level turn-based game that allows re-enactment of various historical and fictional gunfights from the old west. I say "seemingly", as most of the complexity arises from the clumsy and slow interface. The idea is pretty good, there's field-of-visibility checks and a variety of weapons and body postures that (probably) affect the gunplay outcome.

Left: There's a mouthwatering selection of scenarios in the game.
Right: Though your mouth dries up as you see the game's interpretation of the Magnificent Seven.
Yet on overall the gameplay seems woefully random. Also, the play fields are not that interesting. I'd like to see the idea re-done with a Laser Squad-style engine.


Law of the West (Commodore 64)

Clearly inspired by the film High Noon, the player takes the role of a sheriff who encounters various western town types while patrolling a town. Depending on the outcome of the discussions, the day might play out a bit differently, leading to duels with villains or preventing a bank robbery. If the player survives the day, it will be scored according to kills and hearts won etc.

The wonky-rubbery gun-draw needs to be seen to be believed...
I admit the visuals blew my mind when I saw them in the 1980s. Now I feel it could look a bit better even on the C64. Yeah, the backgrounds and the characters are quite good, but the sheriff on the left is a bit clumsy. Cute how the music changes according to the character you meet.

The game scheme is pretty compelling for the few first goes, but has little replay value after most of the avenues have been worked out.


Johnny Reb II (Commodore 64)

Whether a war game based on the Civil War is a western game, is one for the philosophers. Yet there's certainly overlap between western as a kind of action setting, a period piece, or a war scenario. I like to mention JR II because it plays pretty smoothly for such an old game. Also it works on a somewhat more detailed scale than most war games of the 1980s, so they player gets "inside" the action better. And that's perhaps what justifies the "western" monicker here.

Don't get bushwhacked by Jesse James!
So, okay, the gameplay is not very fluid for today, but I remember enjoying this game back in the day. Possibly because it was faster than the dreadfully slow SSI games.

Friday, 21 November 2014

The Bratz are OK with coding

"The Bratz, however, are OK with coding"
Something I drew. Can't be bothered to explain this, too bored.

Edit: Actually, it's simply a kind of response to the Barbie computer engineer debacle.

Thursday, 20 November 2014

BASIC Interpreter


I have been doodling a BASIC interpreter, written in Processing. A BASIC interpreter is something I've always wanted to do, with varying levels of ambition, resulting in various abandoned attempts.  "Abandoned" meaning they couldn't be said to work as BASIC. Now, the current project is beginning to resemble a working language.
The multiplication table in "hi-res". Note that the FOR...NEXT structure is still absent. Also, the parser currently requires some superfluous brackets.
Instead of trying to create a modern IDE + compiled BASIC (which there are plenty), I wanted to make a sort of virtual computer inspired by 1980s machines, with limited fixed-memory space and limited character "display modes".

I'm also trying to project how BASIC-based computers might have developed if history had followed another course. This shouldn't be taken too seriously, though. What's here is a mash-up of cherry-picked features benefitting from hindsight. For example, even if I've kept the graphical capacity of the "computer" pretty low, the storage space is near-infinite. This was not at all the situation in the end of the 1980s.

Although I admire various BASIC interpreters from the 1980s, the most significant source of inspiration comes from Sinclair QL SuperBASIC environment. I like the idea that a computer would be used not so much for running "apps", but giving enough building blocks for making interesting things. Arguably Linux/UNIX environments do this already, but woefully they inherit a bit too much from the text-terminal days. Instead, the BASIC interpreters were directly coupled to visuals and sound. Currently the emphasis is on a character display-style interaction with the visuals, but other "display modes" could be inserted just as well.
The obligatory "scroll some random garbage on screen" program.
The virtual machine contains 128K of "RAM", which is partially mapped as character display, character set graphics, free memory and system parameters, BASIC listing, variables and stack, just like the 8-bit computers.  I'd say this arrangement was even helpful at times, as it creates a straightforward division between "in-computer" variables and the Processing variables: the entire memory and all the virtual computer parameters are simply inside a byte array in Processing.

Although a Sinclair-style separation of graphics and command entry has merits, I went for full-screen cursor editing. (With some as yet half-baked windowing features.) The BASIC listing is line-numbered, something I chose for simplicity but also for certain immediacy. If it's not meant to be an IDE, let's not even go halfway there. Supporting some labels might still be viable, and I hope to have Sinclair QL-style procedures unless they prove to be too difficult.
A fragment from a BASIC program for editing the character set. It's a bit slow.
I kept the amount of memory low (128 kilobytes) because I wanted instant saving and restoring snapshots of the entire machine state, and for this reason the images should not take too much space on the disk. Saving the entire memory is much like saving a snapshot in an emulator, everything will be conveniently contained in it, colours, character display, character set, cursor position, BASIC listing, system variables, just everything.

One difference to emulators is that the snapshots can be loaded with commands during run-time. A major reason for this is to enable hypertext elements for traversing between snapshot images. So it's not necessary to "program" anything to make use of the screen editor. The old BASIC systems worked as on-screen scratchpads, and here, before the BASIC was functional, I could use the screen editor as a notepad for future features and to-do lists and general thinking-out-loud.

The system variable reference, as a memory snapshot. The [bracketed] text typed on-screen act as commands, which may invoke other memory snapshots.
However, I did not go so far as to emulate a processor, in which the BASIC would run. This would have been cool but far too difficult and time consuming for me at this moment. I have to raise a hat to anyone who made these things work in the 1980s and before. Here the Processing code is used to parse the BASIC commands, arranging all the memory reads and writes and handles the updating of the display.

What's the most difficult part here? The "pipeline" of functions that identify the keywords and elements in a BASIC statement and return values to various expressions and functions.

This kind of line could be entered in the full-screen character display:

CLS: PRINT "Hello world: ";PEEK(32128+PEEK(64));" times"

After the program scoops the ASCII string from the full-screen editor, it is sent to the pre-parser, which decides whether it ought to be added to the BASIC listing (not, because there is no line number) or run immediately.
A one-time scheme of the command pipeline, as a memory snapshot.
When run, the pre-parser splits the line into the two separate command lines, CLS and PRINT, divided by colons (:), yet ignoring the colon inside the quotation marks. So far quite simple. Then the command lines are sent one by one to the proper parser, which splits the statement into components. The components are separated by either space, comma, brackets and so on. (This is a bit more complex than I'm letting on).

With PRINT, the parser needs to handle an arbitrary amount of expressions, which can be strings or numeric variables or functions, usually separated with a comma. All of these are sent one by one to the Resolver, which identifies other parts as strings and others as something to be sent to the Calculator/Counter. The Counter is a recursive function which breaks the PEEK(32128+PEEK(64)) part, first the PEEK(64), re-working the initial string into PEEK(32128+1) (for example) and then into PEEK(32129), which is finally seen as a straightforward function, returning the contents of the address 32129, which might be 255. This is turned into a string and put on screen.

This is all a bit messy, and my hands-on style of improvisational programming means that a change in one part easily means an unexpected result in some other part. It's all been going on fairly well, though.
Possibly a support for cyrillic alphabet...
Is it available? No, at least not yet. Probably never, if past projects are any indication. There's too much work to be done ensuring the program works nicely and does not provide a potential backdoor for destroying somebody's files. If I do my own programs for myself there is a massive amount of work I do not need to care about. (better error-handling, some user-friendliness, manuals, support) There's a message here somewhere, I think.

Why? It's an interesting thing to do. Also it might help in devising scripting languages and word parsing for something unrelated.

Tuesday, 21 October 2014

Canon X-710 Plotter



I've always sort of wanted to own a plotter, but never went for full pro equipment. Guess I knew I'd just want to play with one. Plotters at home never caught on that much, as the other printing techniques were eventually able to produce similar results on the A4-size. Still, there's something elegant about that paper-traversing pen.

Well, here's one tiny toilet paper holder plotter for Canon X-07. It came together with yet one more Canon X-07 computer. One of the neat ideas was that grey binder that covers the machine. Now, here the very same design has been simply extended to cover both the computer and the plotter, and it looks simply ridiculous. For comparison, Canon X-07 and a Canon X-07+plotter side by side:

It will probably fetch $1000 from eBay at 2025.
Incidentally, don't think the X-07 is worth more than 40-50$, please.
The plotter is simply packed together with the computer, and it has to be connected to the X-07 with an external parallel cable. The connector is an 8-line wide bus, activated with a strobe signal. The plotter prints straightforwardly any text you throw at it, except in the drawing mode text commands are used to move the pen around.

PSU-modded. I suppose the mechanism is identical between CBM, Sharp etc. models.
First, I had to do the power supply mod to make the plotter work without the battery. Canon apparently aimed to create a fully portable system so the power supply included is really a "battery charger".

The pens that came with the plotter had dried a long time ago, and attempts at rejuvenating them with water have failed despite coughing up some ink. So, I ordered some plotter pens from eBay. These are old too, but supposedly never opened. (They cost more than the plotter. Some things never change). They are not perfect, but still, I'm surprised they work at all.

Cleverly, the pens are contained in the paper roll axle. (centimetre grid)
The graphic mode has to be activated with LPRINT CHR$(18). Subsequently, commands such as LPRINT "M0,0" will move the pen to coordinates 0,0 with the pen up. LPRINT "D100,100" will bring the pen to coordinates 100,100 with the pen down, drawing a line in the process. Pressing Reset on the plotter will reset the pen and takes the plotter back to the text mode. The new 0,0 coordinate will be at the new pen position.

At the moment, it seems my plotter has some difficulties changing the pen colour reliably. It may be because I somehow wrecked the delicate parts of the pen revolver when replacing the pens. Oh well.

Note that here the black pen had some trouble when moving right.
The bottom left corner is "bolder" from multiple passes.

From what little I have seen this tiny plotter is able to keep the coordinates very well. The printer uses a mechanism to perforate the paper slightly from the edges. These tiny holes are at the same time used for holding the paper in position (much like matrix printers use the ready-made holes to align the paper).

It appears that most of these small plotters of the era used the same ALPS mechanism with pens of same size, so Sharp, VIC, Casio and Canon plotters might have interchangeable parts.

But who was the intended user for the plotter, or for that matter, the strange Canon X-07+plotter combo? Imagine in 1983, a businessman pulling it out of the bag during a meeting, throwing together some lines of BASIC that plot out the latest sales curve projection...

It's a big world out there, son, and you've got to compete. No time chasing balls of string.
With the Canon pltoter, you can have that crucial edge...

Wednesday, 15 October 2014

Binary silliness

Ok, something a bit weird for a change.

Many old books on computers start by teaching the principles of binary notation, and conversions between hexadecimal and decimal. This is usually shown with something resembling the 128*b7+64*b6+32*b5+16*b4+8*b3+4*b2+2*b1+b0 formula.

From An Introduction to Microcomputers, Volume 0: The Beginner's Book. Third edition. (Osborne & Bunnell, 1982)

Yet if I ever worked with hex, I would never really grasp this mathematical underpinning of the system. If I wrote a snippet of C64 machine code, to me "$D020" would be the memorized "name" of where I put the border colour value, and I would not really give much thought to what it was in decimal. Similarly, I just knew that $C000 was 49152, without doing the conversion.

Also, when building user defined graphic characters on the Spectrum BASIC, I'd be lazy and use the BIN 00011000 style statements instead of converting them into the shorter decimal form. Even then, if the patterns were simple and repeated often, I'd use 255 for BIN 11111111 and 24 for BIN 00011000 because I "knew" these values by heart, not because I was good at calculating the decimal in my "head".

Yes, visually simple but a bit silly.
Yeah, I can nowadays get along between small binary, decimal and hex values, but I could still do better. Although the modern programmer does not need to know that much about binary or hex, with retro computers and digital electronics, they are quite relevant.

From my previous experiences, I have begun to think, why would learning binary be different from learning guitar chords or another alphabet? People can memorize numerous guitar chords without having a through-and-through understanding of the mathematics of the chord theory. Did the computer books go a bit wrong way about the whole binary thing, especially for beginners?

I think the guitar chords are a good example: Through perseverance, a number of chords can be memorized directly. Knowing three chords, something satisfying can already be played. Then you can add more chords to your repertoire as you learn more complex and more satisfying songs. But learning hits really when you see that somewhat similar chords can be grouped sensibly.

The Binary alphabet

With this in mind, I began pursuing a learning approach that would help me convert binary/hex/decimal. I can't vouch for any "system" here but perhaps this gives some ideas.

The "Binary Alphabet"

I imagined each hex number to have an alternative 4-bit binary "glyph" or notation that needs to be memorized. These are simply binary versions of the same numbers, yet visualized as blocks. I've abandoned the 0/1 notation, because we're not necessarily dealing with numbers, but HIGH/LOW,  ON/OFF and TRUE/FALSE states, or indeed, bitmaps.

Most of us carry practice equipment with us. Just don't go showing a "4" around in public places.

With eight-bit numbers (0-255 or 0x00-0xFF or $00-$FF) the amount of "letters" in the alphabet would be too big to memorize. However, only 16 "glyphs" are really needed when moving between hex and binary, because each hex number corresponds directly to four binary numbers.

Each 8-bit hecadecimal number is made out of two such components. Below is an example of a few of such combinations. Referring to the above alphabet, it can be easily seen how the hex values are built, without any "calculation" going on.


This would already form the basis for the notation of 8x8 characters, familiar from 1980s micro computers. Note that as the required pieces are repeated, there's a need for only a few distinct values. (Remember the three-chord analogy...)


A lot of 8x8 graphics can be worked out with just $0,$3,$6,$9 and $F.

Alphabet groupings

Normal letters are grouped to wovels and consonants, musical chords can be sharp, flat, diminished and so on. Grouping can advance learning and analysis. Both the alphabet and chords are often teached from the simpler towards the more complex. Below, I have attempted to group the binary glyphs according to simplicity and order.

Looking at the table below, it should be Obvious, that 0x0 is 0000 and 0xF is 1111. Also, the basic components, 1, 2, 4 and 8 ought to be Simple to learn by heart.

But it should be apparent, that by moving the block right or left, the number becomes divided or multiplied by two. This holds true for all binary graphics that can be moved so that the figure still stays intact. This is really the basis of the grouping here. So, 0101 is five (0x5) in decimal, but 1010 is ten (0xA). The point here is that knowing one can lead to knowing the other, knowing 5 you will know 10 and vice versa.




There's only three "letters" that are not grouped in this way in the above system, 0x9, 0xB and 0xD, as the can't be shifted. (Neither can 0 or 15, but they are exempt from this difficulty anyway.)

There's another way to group the binary family that might be helpful. The image below limits the family to eight "root" glyphs, which is half the number of 16.


Each of these base values are +1, if the last bit is set. Each 4-bit binary value that has the last bit 0, can be changed into a value+1 by setting the bit. This may seem a bit strange at this point, but consider the ungrouped values above. The 9 can be considered an "8" with +1 added, the "11" is "really" a "10" with 1 added, and "13" is a 12+1.

I only show this because it has some resemblance to the way guitar and piano chords can be varied by adjusting the last note. (Think the difference between the open guitar chord C and C7) This is more to demonstrate that there are a number of approaches by which to exercise your binary muscles without going too deep to the math side of things.

Another additional tool is to learn to rapidly invert the values and gain the result from a simple calculation. Meaning, each of the empty/white regions are considered black and vice versa. Looking at 1001, I can think of 0110 which is 6. at which point I have to think "15-6" which brings up 9, the decimal value of 1001. But this is already a bit cumbersome and introduces calculation in a way I hoped to avoid.

I think the sixteen shapes could simply be learned by heart. Most of the above might be dismissed as tricks that can be somewhat helpful in the process of learning. Yet they also have the added significance in that inverting and shifting are also common and useful operations in machine code and discrete logic. To "know" binary and hex is to "know" how they are to be manipulated, it is not simply a matter of converting them between each other.

Towards larger numbers?

The conversion between binary and hex should be fairly simple, even if the numbers are larger. So, 0xC020 is 1100 0000 0010 0000, and 0xB4CD becomes 1011 0100 1100 1101.

At this point it should be good to be able to instantly recognize the hexadecimal and the decimal value of any 4-bit binary number, and the decimal values 0-15.

Indeed, what about decimal conversion? Here I'm on a bit shakier ground. For 8-bit numbers (0-255), one could learn a second "alphabet", for the higher part of the byte:


These are the previous values * 16. This value will have to be added with the lower part, and I'm uncertain if this is more handy system than simply adding all the binaries individually together just as the books say.

Besides, the route for converting decimal values back to binary is not as obvious. You would have to see that a value such as decimal 119 is above 112 yet below 128, and so would have the 0111 high portion.

The shifting rule of course always works, so 224 (1110 0000) shifted right is 112 (0111 0000) and vice versa.

For 16-bit numbers, I'm afraid there would have to be one more of these alphabets. A 16-bit number is High byte * 256 + Low byte, but here are only the highest 4-bits of a 16-bit value:


This may seem unreasonable to memorize, and the shifting rule becomes less useful. But if I'm targeting an understanding of a typical 8-bit computer memory map, it becomes somewhat more meaningful. The memory can be visualized as 16 equal-sized (4k) chunks. Available memory spaces and memory mapped portions in 8-bit computers often start from such "even addresses", for example the VIC chip of the C64 starts at 0xD000, 0x1101 0000 0000 0000, 53248. The ZX Spectrum screen memory address (and RAM altogether) starts at 0x4000 = 0x0100 0000 0000 0000 = 16384. 0x8000 is the halfway point in 16-bit memory space, 32768.

So, a 0xC000, 49152, is 0x1100 0000 0000 0000, and 53280 (The C64 border address) is 1101 0000 0010 0000, 0xD020.

Yet, the above is less helpful for deciphering a random 16-bit value. I'd need yet another "alphabet" for the lower part of the high byte, which I just can't think is the road to go now.

Just an example. Not worth the trouble really.
So, the system would end up being exactly the kind of addition-game I was hoping to avoid in the first place. The best bet might be to use a combination of memorization and the "book system" of counting the 32768+16384+8192+4096+2048+1024+512+256 values together.

But, umm, yes, anyways. At least the hex-bin thingy is easy. And 8-bit numbers are not that bad. I think I'll go back doing whatever I was doing.