Amibian

Let's have a look at the Amibian Amiga emulator on Raspberry Pi 3.

First I used Etcher to write the .img to the Micro SD card.

First time boot, exit the emulator config screen ("Quit"), use raspiconfig and find the option for extending the SD card filesystem. (It might not be on the first page of menu items). Then Finish and prepare to reboot.

It takes a few seconds to get to the config screen. F12 switches between the config and the emulation.

It's also possible to again Quit to the linux command line and examine the folders and change the various settings. There you can update the system, too. The command line parts have simple assistive menus so I'd think less advanced users might find what they want.

In the graphical config menu again, if the Amiga files are on a separate USB stick, navigate to /media/usb0 to get there.

You can select ROMs (e.g. kick13.rom) from anywhere, but at amibian/amiga_files/kickstarts they will be convenient. 

To get your system to boot as directly as possible to the Amiga Kickstart, quit the config, use "Emulators setup", "emulator config" and "uaeconf1" to select for example config 1 as the one that starts automatically. You can also use the uaeconf1 directly without resorting to the menus. From the graphic config untick "show GUI on startup" at Miscellaneous tab. 

To change or creatively remove the Amibian logo from boot, change the contents at amibian/boot_pictures/

As the linux shell background has been set as blue, it will flash in sight during the boot sequence. This was mildly annoying.

This can be changed by editing the file called .profile (e.g. nano .profile) at the home directory (the one you land at after Quitting the config). Change the "background blue" into "background black", so the boot process looks less aggressive. In theory you could set the font to black too but this isn't very practical as the shell is needed!

Composite video

I was curious about how well the Amibian would show composite video.

This is not an entirely minor point as many modern computer monitors won't do 50hz, but the 1084S does and it's also a period-authentic display.

Using the Raspberry Pi video splitter cable, the tiny audio/video connector can be divided into RCA Composite video and stereo audio.

Changing the config.txt on the Raspberry partition enables composite video output. 

sdtv=2 gives interlace and sdtv=18 enables progressive scan. 

There's an option that enforces HDMI even if no HDMI cable is connected, so this has to be commented out too.

I have to say Amibian appears not to be as sophisticated with video options as the recent BMC64. I will easily get pattern artefacts at least with 1084S. Adjusting the overscan settings in config.txt did not help. 

This may not be a big deal in many games, but it is obvious when making horizontal lines in Deluxe Paint.

How about screen refresh? Trying some games (Battle Squadron, Rodland, Giana Sisters) the screen sync was fine, but the demo Enigma by Phenomena started revealing hiccups in the screen update and there were some graphics glitches too.

This has nothing to do with the composite, as HDMI showed the same effects. But the glitches might also result from incorrect Amiga settings rather than the Amibian as such. 

It's also possible the Raspberry just can't emulate it all fast enough when it comes to more Amiga-specific bitmap and screen handling.

But, arguably the refresh rate was generally more stable than the 50 adapted to 60 on UAE on my Linux+computer monitor. The demo didn't have the glitches on Linux emulation so the adf is unlikely to be corrupt.

HDMI

Less of a purist can go with HDMI and it might be easier on the eyes.

You can't get audio from the composite/audio connector while the HDMI is connected, so you need to depend on your HDMI to deliver that, too. I had a HDMI->VGA/Audio splitter which separated the audio output to a mixer as my display doesn't have speakers (or HDMI for that matter).

A television does better than a computer display, as it is more likely to do 50hz and playback the audio through the HDMI.

My poor ears could not notice any particular audio problems. Of course with headphones the Amiga stereo separation can be unbearable, but as I had the sound go through a mixer anyway I could adjust the situation.

Other considerations

Trying Frontier: Elite II with an anomalous setting of an A500 with "Fastest" speed (I guess the maximum) the game plays quite smoothly. It can still choke on very high detail. The speed can be changed on the fly, and making an eyeball judgment here the "fastest" speed looks like at least twice as fast as the 25mhz setting and the launch from Ross 154 with high detail is quite smooth.

So from this I'd judge there is enough raw power in the Raspberry 3 to run an Amiga, it's just that there are some features it can't pull off that easily, and these can be more apparent in scenedemos. I didn't test a lot of software though.

I experienced keyboard problems when typing, but this meant I had to remove the keyboard from the joystick emulation. After that the keyboard worked ok for AMOS Professional :)

The Logitech Gamepad F310 was recognized easily and worked fine. The config menus can be operated with the gamepad. Putting "Enter GUI" to the start button enabled me to reach the config from the joypad, however the function actually went to the left shoulder button. So a lot can be done without a keyboard if you have set things up cleverly enough.

I would have liked to connect a real Amiga keyboard to the GPIO or at least a joystick. The keyboard would probably require far more work than the Commodore 64 solution.

Edit: I could use the USB wanna-be Competition Pro joystick that came with THE C64 to give some more "authenticity". With Stunt Car Racer it felt better than a modern gamepad.

When connected to HDMI, it's hard to see an advantage or difference compared to having UAE on your main computer, for example running on a second screen. It's of course nice to see the Raspberry is so capable.

With composite video, the nostalgia factor is higher but the video options couldn't get rid of the horizontal line artefacts and it's possible a proper Amiga screen just can't be achieved in all situations.

The best use situation is with a HDMI 50hz television.

Amibian from here:

https://gunkrist79.wixsite.com/amibian

2020

The customary look-back into the year.

Retro stuff = C64 stuff

Apparently I'm concentrating on fewer and fewer platforms. The year was quite Commodore 64-centric, such as toying around with THE 64, 1541 Ultimate II and casemods. More recently, I've worked with the BMC64 Raspberry Pi C64 emulator again.

I did a bunch of 6502 code but only a little of it has seen the light of day. I did release a small videotester for C64, though. PETSCII graphics is small enough to do occasionally. Also I made a couple of tiny demos based on PETSCII, such as the Petmanbatman and Advanced Pet Dragons.

I also got a PETSCII piece out in a paper publication, Kuti #57.

I've done less pixel graphics. I prefer to draw fast and that's hard to reconcile with the pixel aesthetic. Compared to PETSCII it feels time consuming and the results are not that different.

Multipaint got the inevitable 2020 update with transition to Processing 3 and resizable windows. Possibly it finally works reliably on a Macintosh. I'm perhaps hoping to put less time into this project and the 2020 version could be one of the last big overhauls. Many tiny improvements are on the to-do list, though.

On less retro front, I've been playing with a server, more and different Linux installations, a "new" mac and with some help I'm getting to know my way around these systems. Even Raspberry Pi looks more attractive now that I understand more about Linux than 5 years ago, and maybe it's a platform to look at more closely in the future.

Games

Mostly thanks to Proton, I could enjoy new games in 2020. The biggest game I completed was Just Cause 3 which worked nicely on Linux. A very enjoyable and not too long open world destruction romp.

I couldn't finish Nier:Automata, but maybe will return to it eventually as it had some quite impressive parts. It also glitched more on Proton than Just Cause, but was playable. 

Some of the smaller games were Lonely Mountain Downhill and Saboteur Sio. 

Lonely Mountain was incredibly addictive at first, but when I got bored I got totally bored with it. Perhaps less routes and bikes might have been better so I would have had more genuine motivation to optimize the courses, like with Stunt Car Racer.

It amuses me now how I initially dismissed Surviv.io, a game I first tried at the end of 2019. Then I played it for most part of the year and still play it. The overhauls to the login system and various outages almost put me off it, though. I'm now better at it but even now the results seem more to do with whether the really good players happen to be on-line or not, rather than my inherent skill. Outright cheating/hacking may have diminished somewhat at least.

Chess is still on the playlist but I've been concentrating on it a bit less. I make this complaint every year, and I'll make it again: I feel I could improve if I put even 30 minutes into it every day, but that measly amount would feel too much to dedicate. I did manage to play about 1000 games this year, although mostly blitz on Lichess. Slower chess would be nice but the time use is even harder to justify.

TV, Films, Books, Scifi

For films, the year 2020 was more about re-watching rather than covering much new terrain. Tenet was a memorable film but perhaps not the bullseye everyone was hoping. Well, amidst the worst Covid-19 stupor, this film had begun to gain a messianic promise which it really could not fully deliver.

Doctor Who continued, the episode ideas were good but the writing overall had some problems. No reason to stop watching, though, it's still solid TV sci-fi. In some ways I'd compare it to the first season of the new Who, an attempt to keep the episodes self-contained and finding ways to renew the mystery of the character.

Westworld season 3 started with a bang, what the season 2 ought to have been. But it begun to veer away from the Westworld concept and overall was a puzzling addition to the series. I guess it was meant to deliver the idea that we all live, or are about to live very soon, in a sort of "westworld". As a detail, a lot of people got shot from a close distance in a random and nonchalant way, something that got boring very quickly. 

The 100 came finally to an end, a not so high-profile series that over the years has had its ups and downs. I often felt it built upon watered-down themes from bigger series (Game of Thrones, Hunger Games) but it had its own voice too. The confused last season perhaps took some story-telling elements from Westworld.

The Mandalorian was probably the best Star Wars related thing in ages, but it also reminded me of how bloated the whole SW phenomenon has become. There's a lot of verbal/visual in-jokes and meta-gags, which the series can now afford as there are so many layers to the SW verse. 

The Queen's Gambit mini-series was a fascinating story about chess and a nostalgic look at 1960s US. As a TV series it was able to give more detail to the games and the chess player's practice than films usually do. Given how popular it has been perhaps there will be more chess-themed shows.

As for books, I also kept revisiting the old rather than reading much new things. Well, when I was somewhat ill I did go through Suzanne Collins' Hunger Games trilogy and Stig Larson's Millennium trilogy, pieces of past zeitgeist I had previously ignored. I made a point of reading the Asimov Foundation/Empire/Robot novels in a chronological order and a blog post about it is still in the works.

Onwards to 2021

I'm hoping to continue with business as usual. This blog will have its tenth anniversary in June!

Some more BMC64

Just a small update on putting the Raspberry Pi BMC64 Commodore emulator inside a Commodore 64C case, as described in the previous post.

The starting point:

I chose a suitably sized prototyping board with unconnected holes, sawed off the corners to make the Rpi screws fit. Then I soldered a 2-wide female pin header for the Raspberry GPIO and a 1-wide pin header for the C64 keyboard connector.

Then I soldered all the connections, trying to keep track of the mess. I lost the track once but fortunately it was not too difficult to re-solder a few wires. Soldering wires into pins isn't ideal, but tinning the wire ends prior to soldering helped a lot.

In hindsight I should have used a bit lighter, more bendy wire as now I had to push them down to make the C64C cover fit.

The end point (for now):

That horrible hole is the trapdoor for getting the SD card out. Sorry.

It's now quite compact.

I didn't do the joystick connections at the same time which was silly as they will be more difficult to solder now that the keyboard wires are in place.

Instead, I soldered a joystick connector in from the underside, aiming for the GPIO Bank 2 pins.

After a few mistaken solders, I found out I need to be careful which GPIO configuration I am aiming at, and also understand that I'm looking at the GPIOs from below the board. 

Now, it's getting crowded in here.

When using both the Keyboard and Joystick from GPIO, the pins are different than when using a joystick-only configuration.

So, in this case I used GPIO U=20, D=19, L=16, R=13, F=26 and Ground to get my joystick connected.

The joystick port is made from a PC COM-port as it had the correct sized header for the pins. Nothing has been properly fixed to the case but this shouldn't take too much work.

In use

If there's a Commodore 64 lying around, I sometimes write nonsensical little BASIC programs. Multiplication table tutors, tiny games, graphics effects, PETSCII scrollers, whatever.

This time my excuse was that I needed to test the keyboard more extensively.

And it works, I had really no trouble in getting to that BASIC programming mood with the BMC64 and the C64C keyboard.

A word of warning with the BMC64 emulator: Any changes to the attached D64 disk image will not be preserved if you don't detach the image first! So if you save your BASIC program to the attached D64, always remember to detach it before shutting down.

I also tried my go-to game for testing joystick lagginess, Buck Rogers (catridge image). Playing with a TAC-2 joystick I can feel a tiny amount of lag if I really concentrate on it. The BMC site says the joystick is only read alongside the screen sync, considering that it's not bad at all. Most games would probably poll joystick once a frame anyway, then depending on how it's done I guess the lag could vary.

BMC64 the sequel

Time flies. About a year and a half ago, I had an all too brief look at the BMC64 Commodore 64 emulator for the Raspberry Pi (and the corresponding ZX emulator).

Although the emulator was already impressive by then, I had some minor gripes with it. Now it's a time for another look.

On my Raspberry Pi 3B+, the system boots in a few seconds, comparable to a sluggish real C64. Nothing to complain here! Hit F12 to enter the menu.

The video options are now extensive, and I could get a good picture out of the 1084S monitor. It's worth mentioning the Y offset may need to be changed to 1, otherwise the scanlines are "between" the actual monitor lines and will look blurry and incorrect.

The picture is obviously a bit too perfect :) as it doesn't have the black bleeding and other C64-style artefacts. But it certainly doesn't have any moiré effects. (Any such in the images are result of the photo processing.)

Trying Buck Rogers again made me feel as if the lag had been further minimized. I could not really detect any significant amount of delay here.

Based on vice, the emulator now supports the other Commodore computers too, such as VIC-20, PET and Plus/4. I didn't try these yet, but it is possible these are not as perfected as the vice C64 emulation (Plus/4 people keep saying this) but it's a good bonus.

Although I don't remember this either, the sound may have been improved and there are likely more sound options than when I last looked, as seen from the above menu.

Still, SID emulation is tricky to perfect and this is an area where differences are easier to spot.

Real C64 keyboard

The overall impression was so good I was motivated to test a real Commodore keyboard. It can be wired to the Raspberry Pi GPIO connector with no additional electronics. Last time I only tried the 9-pin joystick.

A PCB design exists for just dropping in the keyboard connector and the joysticks (also a power switch), but now I could test it with breadboard wires.

Without such a PCB, it's not that obvious how to place the Raspberry in the case, but it's a start.

A tip for mounting a Raspberry on some surface. First drill through one hole, then screw the Rpi in place. Then drill another hole through the Rpi circuit board hole. Put that screw in place too and then drill the two remaining holes, again through the circuit board. 

This way the holes will be more accurate than trying to mark positions for drill holes using the Rpi holes or with a ruler.

I got a bit sidetracked at first as although I had a loose C64C case and keyboard, I didn't find my keyboard mounting brackets. 

So I had to improvise something. Luckily as the C64 board doesn't have to be there the shapes aren't that specific, as long as they hold the keyboard in the correct place.

I took the basic dimensions and some inspiration from crashmeplease's Ultimate64 Keyboard Mounting Brackets (https://www.thingiverse.com/thing:3051450) STL models, but of course my mounts are not 3D printed.

So what if the case is full of wires, what else I'd put there? 

I took the wire order from here:

https://makerhacks.com/raspberrypi-bmc64-c64/

...and of course the GPIO numbering is not the same as pin order:

https://www.raspberrypi.org/documentation/usage/gpio/

Later I might solder a proper connector between the Rpi and the keyboard connector, and also adjust the positioning a bit. The SD card isn't particularly accessible at the moment, I carved a crude trapdoor for changing it, though. No, I don't think every C64 case needs to be preserved in pristine condition. Damn those micro-SDs.

Starting the Pi, the C64 keyboard didn't work! But no worries, it needs to be activated first from the keyboard sub-menu, using the USB keyboard. 

After this the C= and F7 key together activates the menu and it can be operated with the C64 cursor keys. Obviously it's a good idea to save the settings at this point.

I left the joysticks unconnected and this might need some additional figuring out.

I noticed that as the C64 keyboard is active, I seem to lose the possibility of using arrow keys as a joystick. In fact, if try to use the option Left Control/Arrow keys as joystick, I can no longer access the menu using C= and F7 and have to restart the Pi.

I had to test the one major advantage a real keyboard has over emulators, the PETSCII characters! I didn't have the patience to do anything larger, though... Shift Lock doesn't seem to work.

Without joystick, I was not that eager to test so many games, but Thrust (keyboard-based arcade game) worked rather well.

Trying the composite video with 1084S monitor and using this real keyboard, the feel is pretty good. 

Unlike with THE 64 Maxi, there is no feel of delay from my keypresses to the on-screen characters in BASIC.

So, yeah

So, a definite multi-thumbs up from me and I'd say this looks like it is preferable over C64 Maxi, at least if you are prepared to do a bit of tinkering.

Keyboard project continued here

BMC64 website

Multipaint 2020

I've tried to have a major Multipaint version out each year, at least as long as it makes some kind of sense. Now Multipaint 2020 is out, somewhat later than I hoped. 

The fix-list of every tiny thing is too numerous to put anywhere, the website details the more important ones (http://multipaint.kameli.net). I'll just open up a few points too large to fit there.

The largest step was to move over to Processing 3. This itself doesn't really change the program appearance in almost any way. Hopefully as a newer version it would be more stable and the prefs.txt problems becomes a thing in the past. 

Sadly the transition to P3 means the application is likely slower, something that shows itself on less powerful computers. I compared the Processing 2-based version on Raspberry Pi 3, and found that version to be useable, whereas the new executable made with Processing 3 is quite slow.

This could be due to the way the screen renderer works, but I didn't dare to meddle too much with a thing that worked well in the past.

Application window resizing

(Edit: The feature doesn't work in all Linux desktops. Hang on.)

Edit 2: It does work, too! (24.11.2020)

A major visible change is that I made the application window resizable. Although the program had been already written with a flexible interface in mind, and it could be set from the prefs, the app could not be resized while running. 

However, despite the old code there was still bring a bunch of boring upheavals to the interface drawing and scaling routines.

Dark theme, resized window, SET GRID and a 100% C64->ULAplus conversion caught at the same time.

There are various reasons for making this. One is that there may be low-resolution screens which didn't just about fit the display, so you have a chance to adjust the situation a bit. It's also easier to make larger if it's too tiny for your display, without fiddling with the ZOOM parameter in prefs. Also, if your screen size allows it, it may be nicer to have some more of that good old border visible.

Just to be clear the target platform resolutions are not alterable. I did some behind-the-scenes work to enable non-standard screen sizes, important for Amiga, but this will be a future feature.

I long wondered why Processing 3 does not allow the direct use of size() no longer, or the use of variables as parameters to it. Well, in P3 it's now simply surface.setSize() and works just as well or even better so no worries really.

If the chosen viewport doesn't fit the current scale, Multipaint will re-scale the interface. Also, if you make the application window substantially larger, the scale will follow. Scaling was a feature that was previously only accessible from the prefs.txt ZOOM variable.

The least I now want is to make Multipaint more complex. So, it should still work as before and you might not even notice the resizable window feature if you don't need it.

Resizable window is also a base for future developments, as more flexible target platform resolutions could be made to fit better in the application window.

A very large window will unfortunately slow down a computer, or make your computer choke and start the fans, even if you do nothing with Multipaint. This is something that relates to the way Processing updates the window and apparently can't be helped much.

So, it's somewhat ironic that if you have a huge 4K/8K resolution display specifically for graphic work, then Multipaint might not work ideally on it. Resolutions like 1920 x 1080/1200 should not be too huge. I'd recommend not working on lower display resolutions than 1024 x 768, but it shouldn't be impossible.

Still, the window resizing is less than complete. You can't yet change the actual viewport position, for example.

Dark theme and Set Grid

I added an option to switch between light and dark theme. This did not require much work, as the interface fonts and icons are based on custom routines anyway and not on real fonts or image files.

Set Grid dialogue is something I wanted to add. The already existing grid commands and presets should work as before. This is again a "funny" thing in that the facility for making arbitrary grids has been there for a while, but there was no dialogue to make it happen.

I can only note that when working with 8x8 attribute modes, if the grid does not align with the attribute grid it can be really confusing.

What with the new drawing routines and all, the grid color is again a bit silly. It's like a recurring nightmare. I added a brightness setting as a hasty fix, but as some have commented the grid might have been too dark in their monitors anyway so it is good to have it adjustable. But this is a topic I'll have to look at in the future, again.

Border analysis

When loading png/jpg images, Multipaint will make an attempt to deduce if the image has a border and takes the "real" image from the middle, if it has the correct resolution (or a duplicate/triplicate of the resolution).

For ZX Spectrum and C64 modes this might be helpful when using Multipaint with plain jpg/png files.  It also makes it a bit easier to load existing images from the internet.

I'd still recommend using the BIN file format for project work.

Multipaint loading a 3x PNG file saved from Fuse. (In this case, use SCR, really)

However, if Multipaint can't explicitly determine a border, it will simply load and scale the image, borders and all. For example you might have a small logo in the centre of the screen and a black background and border. In the future there might be a "crop anyway" dialogue.

One problem was whether to include this feature in modes that don't really have a border. But I felt that there might still be quite a lot of images with a "border" in them, such as Atari ST screenshots. So I enabled this for every mode.

Amstrad CPC Overscan 384 x 270 x 16

The original Multipaint interface was very fixed to the idea of having a 320 x 200 resolution at tops. This was also reflected in many, but fortunately not all, internal structural choices of the program.

But now it might be the time to expand these horizons a bit.

To cut a long explanation shorter, instead of resizing buffers I'm using the same room more efficiently to manage the 384 x 272 x 16 resolution.

Just as with all the Amstrad modes, the export template is taken from Marq's Pixel Polizei (thanks!), so you should be able to get the exported images up and running on a real Amstrad. I also followed the export code quite strictly.

The CPC overscan, I'm told, is not really a very standard graphics mode, so I'm now sort of opened the gate for software-enhanced modes(!)

Amstrad CPC mode 1 320 x 200 x 4

This was already in the later 2019 version I think. The mode was a fairly simple addition, but I don't expect many to use it. It is somewhat nostalgic to me as I used to see screenshots of Amstrad games in magazines and they often looked like Spectrum games except with one or two more colors and I wondered how this could be. 

There is an overscan variant but I have not implemented it yet.

C64 unlimited 320 x 200 mode, and other C64 goodies

I added the C64 hires unlimited mode that was previously experimental. It behaves like a C64 320 x 200 mode, with the fixed palette of 16 colors. Howver you can draw the colors freely without any color clash.

So you could basically draw a C64 hires image without Multipaint imposing anything on you, and then move over to the C64 hires mode, and have Multipaint "validate" your image.

The reason for this mode in the first place was I wanted to work on composite sprites, i.e. overlaying different-colored sprites to make hires sprites with many colors. (Or superimpose hires on multicolor sprites). However, it is your responsibility to convert the output png into valid sprite data.

Adding this mode is a bigger change in the Multipaint "philosophy" than might seem and I've felt a bit troubled about it every now and then. However, perhaps better simply make it available and face the outcome.

Why don't all the modes have this option? I haven't still quite decided if this should be a unique mode or rather a switch inside the modes proper.

The transition between different C64 modes is now smoother in that your chosen palette will be preserved and so is the border color. The image is still transferred via "bitmap conversion", but I have not seen any problems coming out of this.

Multipaint at kameli.net

6€ Fleamarket bonanza

I found these three items, each cost 2€.

Virtual reality!

You'd think VR costs tens of thousands, but it actually costs 2€. If you already have the phone, that is. In the past I've been semi-impressed by how these plastic gimmicks could deliver a VR-type experience in a mobile phone.

I tried the Shinecon VR on an iPhone and it brings the usual split-eye head-achey effect and viewing angle for Youtube VR videos.

The eye horizontal and depth adjustment can be changed but overall this might be designed for a bit smaller head. My nose couldn't find a good location inside.

From the few videos I tried I could not really judge if the lens settings were correct or not. The head angle tracking in iPhone has been so far more impressive than the depth effect. Some videos were also kind of fake and not really stereoscopic.

I didn't try it on any games as they might need a separate controller so this side of things remains to be seen.

Karaoke microphones!

This was actually a quite nice find for 2€. These are Playstation 2 Singstar Karaoke mics. 

I stuck the USB adapter directly into my Linux system and picked the "serial" microphone input in Audacity. The other mic goes to Left channel and the other to Right. Seemed to work well enough on Performous, the free Singstar-like, and why not.

Obviously I could use the mics without the USB adapter, and the adapter without the mics. Maybe I'll follow up one day with my experiments.

The mic heads could be screwed out and the insides were a bit dusty and a christmas tree needle was stuck there.

I suspect it is a USB 1 interface but that should be enough.

Edit: The audio connectors are standard but have been made so that very few plugs fit them physically.

Mini Clothes Iron!

This Black&Decker Stowaway clothes iron doesn't have much to do with computers or electronics, and I added this to the pile mostly for the cute design.

Well, who knows I might want to heat something when building stuff and this would suit better than a full-size iron or a soldering iron.

The shape is very compact but the cable is still rather huge. Whether the handle lock doubles as a safety, I didn't yet check. There's a 110V/220V switch too.

Edit: After overwhelming popular demand, I will also show the iron in the compact mode. The cable can then wrap around the whole thing if needed.

I can also confirn that the handle lock does not double as a safety for the thermostat. So the iron can heat in this position too.

Bonus round:

A week later, I got this cable tester.

It works with a battery and blinks lights one at a time to show if the RJ45 or RJ11 cable connections work.

Rambo-thon

Finally, I got to watch all Rambo films.

First Blood 1982

We meet John Rambo, a Vietnam veteran whose best buddies died in the war and now he finds out the last one of them has died too.

While still dressed in that reunion garb, trying to get into a town he gets harassed by a local sheriff. He gets PTSD in the cell, kicks everyone's ass, leaves the station, steals a motorbike and drives to the hills and to the realms of legend.

I liked the detail when the sheriff's car turns over, Rambo actually seems concerned if something bad happened. As he sees the sheriff crawl out of the wreck, he leaves.

Rambo tries very hard not to kill anyone and even the sheriff has some sympathy towards him, it just turns out everyone else is a trigger-happy gun-nut. Things escalate and soon the sheriff has a small war in his hands. 

The general consensus is that this is a film with actual merit, and I've tended to agree. Well, I've always thought the Trautman character to be a bit silly.

Rambo lays traps in inhuman speed. All the sheriff's henchmen are clowns eager to join the fight despite having already seen what Rambo can do. Yes, some have worries about this but dutifully they go on.

Rambo II 1985

Rambo has been in the prison labour camp for five years. Trautman makes a deal that if Rambo does this mission he can have his freedom.

As Rambo later explains to a POW, it is 1985. Taken very literally, the events in First Blood would take place at 1980.

Some have ridiculed the lightning fast relationship of Co Bao and Rambo. But what isn't obvious is that the mission takes several days (as it gets botched) so perhaps these warrior souls could relate to each others quickly. 

Of course after they reveal their feelings it doesn't take a minute until something bad happens. I recall MAD Magazine making a joke about that lucky charm pendant perhaps being not so lucky after all.

This film established "Rambo" as a shorthand for American jingoism, but this isn't fully deserved. The film does have critical tones towards the establishment and derives some tensions from the post-Watergate conspiracy and paranoia themes.

The computers at the base seem old-fashioned for a high-end operation in 1985. The strange anti-technology vibe in the film is inexplicable. But it must be remembered, a "computer" picked up Rambo as the person most likely to survive this mission, so Rambo has some resentment towards the bureaucratic "machine" overall and the technology that made him do it. 

Likely the computers were networked so all the data was safe, though!

The film is actually quite coherent and enjoyable, maybe inexplicably a better film than it should be, and a canonic part of 80s nostalgia.

Rambo III 1988

This is a really big money film. Rambo is in Thailand, participating in an (illegal?) martial arts scheme and helping some monks. Later we see him in Afghanistan in an attempt to rescue Trautman.

A lot of effort has been put into presenting and respecting local cultures but this tends to be exoticist and orientalist. Also, the russians are characterized as brutal and inhuman.

One gets the idea this was to take Rambo more in the direction of Bond or Indiana Jones films, suggesting a series of films in the rambo format. And it kind of works, except the latter half of the film simply repeats the kind of action scenes already seen in Rambo II, only made bigger and even less credible.

Trautman's character is taken to strange extremes, suddenly he is quite a "rambo" himself, despite having been tortured by the russians for a while.

The Spetsnatz seems a weirdly mismatched, rag-tag bunch.

Surely the 1990s should have had a Rambo film or two, but the times had changed drastically. Perhaps the Gulf war again made war a reality so a rambo-flick might have been somewhat tasteless. Films like Hot Shots! Part Deux were already making fun of the genre.

Rambo IV 2008

At the time of the release of John Rambo, it felt surprising a Rambo made in 2000s could be as good. It didn't add that much to the Rambo mythos, though. Now that I've viewed it so quickly after the 1980s trilogy, it feels even less necessary.

I like the rawness of the images, and the return to somewhat more "primitive" film-making. The roughness of the environment and the brutal violence is a contrast compared to the more comic-book antics in Rambo III. 

It's a nice idea to start asking what Rambo is and how he could get his redemption, or come "full circle". It's just that this idea does not progress much here.

The bad-ass mercenaries are a nice touch, Rambo can concentrate on being quiet and the gang brings some added color to the film. Their internal dynamics is sometimes cleverly made apparent by visual storytelling, but they don't really have much of a story to tell.

Unfortunately, the poor treatment of women as some kind of story/shock element is annoying and tends to bring this film down. Perhaps this is ultimately what makes this film less appealing to me than Rambo III.

Rambo V 2019

Rambo lives near Mexican border at the farm we saw at the end of the last film. Ten years have passed and Rambo has apparently both helped solve some problems there and found some peace for himself. Ok, so he does dig these weird vietcong-style tunnels under the farm, keeps an unnerving amount of Vietnam memorabilia, and takes meds.

Rambo's sort-of grand-daughter goes to Mexico to see his biological father, despite stern warnings from John. Turns out the dad doesn't truly give a shit. By way of deception the girl is captured by criminals specialising in human trafficking and prostitution.

As Rambo goes there somewhat unprepared, the gangsters are able to, well, gang up on him and beat him to pulp. As he recovers with the aid of a journalist, crucial time has been lost.

Rambo is somewhat too old to be an action-hero, but when the violence really starts some thought has gone into figuring how he could still do it. This is done adequately, although I was hoping more of outdoor environments and perhaps even horseback fighting.

Trump's wall notwithstanding, criminals, drugs and guns move to-and-fro between the Mexican border. Again the henchmen are quite loyal. The fiery explosion that blows up a car should have given the gang a pause. Also, why are they so certain Rambo is alone on the farm in the first place?

I felt the film was tonally off at places. From Rambo II onwards John Rambo specialized in rescue missions and so it is here too. But, "Rambo goes to Mexico to rescue an innocent girl" is perhaps not the best premise. Why, after all of the shit Rambo had to bear, something nasty had to happen once more. Crucially, this time it is completely unrelated to his military life and perhaps this is what makes it feel random to me.

When discussing Rambo IV, I suggested the nasty treatment of women worked as a poor shortcut to showing how "evil" bad guys are. As human trafficking is a very real thing I suppose it is more appropriate here and it is not dwelled on too much or in a wrong way.

Whether Rambo dies here is open to some interpretation. But either way I hoped he could achieve something more than disposing an arm of a Mexican gang.

Altogether

I'd thought there would be more to learn and say about Rambo after watching all the films in relatively short time. But after Rambo III we don't get to know much more about Rambo's past or his persona. Last Blood kind of shows what came of him, but other than that not much is added to his story.

John Rambo ascended towards the film three, each time facing a bigger war. Then the scale of action becomes again smaller in IV and the latest film looks at a skirmish comparable to the first film.

There are Rambo books too, in fact the character made his first appearance in David Morrell's book from 1972. I've only read that one years ago and I am unable to compare it to the film here.

There's also more Rambo material. Such as the animation series. And I've yet to see Syndicate Sadists with Tomas Milian from 1975, technically the first Rambo film. Perhaps some other time!