Review: A500 Mini, F710 game controller, PETSCII Robots

▼ The A500 Mini, the Logitech F710 and Attack of the PETSCII Robots: an excellent combination. So let me cover all three in a single review.

The A500 Mini

Shortly after its release, I wrote a first take on the A500 Mini, a shrunken down, modernized reincarnation of the Amiga 500 for playing games.

A big limitation of the original firmware was that it didn't support disk emulation with ADF disk images. The only (official) way to get other software than the included 25 games on the device was WHDLoad. WHDLoad is a great system for running older games, especially floppy-based ones, but as a regular user you depend on others to make WHDLoad "slaves" that make it possible to load various software.

But with the latest firmware, the A500 Mini will let you boot off of an ADF disk image, and switch between different preselected ADF images afterwards. So this way, it's possible to run any floppy-based Amiga software. Writing to the disk images works, so you can even save your work.

Logitech F710 wireless game controller

When I learned that the A500 Mini works with the Logitech F710 wireless game controller, I immediately got one to replace the wired controller that comes with the A500 Mini. Before this, I never played games using a controller like this, so I have nothing to compare it to apart from the one that comes with the A500 Mini. Compared to that one, the F710 is a lot heavier and feels good to hold. It has a few extra buttons in the middle and two analog sticks. It can also "rumble". Strangely, the A/B/X/Y buttons are in the same place, but have different colors.

Initially, the F710 didn't work with the THEC64 Mini or Maxi, or with my Mac. But it turns out that you can trick the F710 to start up in a more compatible mode. For this, the switch on the back must be in the "a" position and the USB receiver dongle must be unplugged. Then remove the batteries and put them back in and plug the USB receiver into the computer. Then, the F710 shows up on my Mac as a "Logitech Cordless RumblePad 2" and it's much more compatible. If you don't go through this steps and/or after reactivating the F710 after it goes into sleep mode, it shows up as a "Wireless Gamepad F710" in the list of USB devices.

It looks like the A500 Mini is not picky about mice, I was able to use my Logitech mouse using the unifying receiver without issue. (Of course it would have been too easy if the F710 and the mouse had been able to share the same receiver dongle...)

Attack of the PETSCII Robots

As a subscriber to David Murray's "The 8-Bit Guy" Youtube channel, I had already seen him talk about his game "Attack of the PETSCII Robots", probably the most ambitious game ever made for the Commodore PET computer from 1977. He then proceeded to make versions for other Commodore 8-bit computers and people started offering to port the game to other platforms. Right now the list of computers the game runs on is:

• Sega Genesis
• Commodore Amiga
• Sony PlayStation Portable
• Commodore 128
• Commodore Plus/4
• Commodore 64
• Apple II
• Atari 800
• Commodore PET
• Commodore VIC-20
• Sinclair ZX-Spectrum
• Commander X16

So I bought the download-only Amiga version for $10. (The shipping on other purchase options was too steep for me.) For that, you get an ADF image that you can write to a floppy and the game will boot from that floppy. You also get a WHDLoad installable version and the floppy includes the green monochrome PETSCII version of the game.

Attack of the PETSCII Robots was originally created to work with a keyboard, as it's hard to make the "move in some direction" and "shoot in some other direction" actions both work well with just a joystick. However, the Amiga version also supports the CD32 controller... which is not unlike the A500 Mini controller or the F710!

So when you start the game, just select "CD32" as the controller, and you can do everything you need without needing a (virtual) keyboard. And go into the game settings on the A500 Mini and tell it the second joystick port has a CD32 controller connected to it.

This makes playing the game better on the A500 Mini than on a real Amiga. Well, you get the same benefit on a real Amiga if you have a CD32 controller, and a compatible one comes with some purchase options of the Amiga version of the PETSCII Robots game.

I was stuck on the first map (level) for a while, trying to figure out the gameplay. David's Petscii Robots Gameplay Tutorial came when I had already figured out some stuff on my own, but it was still helpful.

After getting past the first map, the rest was a lot of fun trying to figure out creative ways to lead the robots to their demise. Just one or two maps gave me problems, as I needed to go through lots of steps before I got to the part where I couldn't figure out what to do. So in those cases, I used the "save game" feature of the A500 Mini so I could restart without having to go through the same five minute run to collect weapons and keycards each time.

I think the game could benefit if it would be a bit easier to get through that first map. Maybe give the player hints after some time has passed?

Recently, some "shareware" versions (i.e., free demos limited to two maps/levels) were released for a number of platforms, so you can try out the game without shelling out your hard earned money immediately.

Conclusions

The A500 Mini is a really nice little device for playing Amiga games, especially if you want to do so on your living room TV. With ADF support, you can now boot into the Workbench or floppy-based applications for some nostalgia (did anyone say "DPaint"?), but it won't replace a real Amiga for non-game use.

I have no idea if other game controllers are better, and having to do the unplug USB / remove batteries dance when I want the F710 to work on my Mac or the THEC64 is pretty annoying, but the Logitech F710 is a lot nicer than the A500 Mini's game controller, and the A500 Mini supports the F710 without any issues.

Attack of the PETSCII Robots is a very nice game, even for those of us who are not really into gaming, as it's about trying to figure out how to deal with situations rather than having quick reflexes. Can we have some more maps/levels, please?

Permalink - posted 2022-06-05

OSPF: time to get rid of the totally not so stubby legacy

▼ Recently, I was looking through some networking certification material. A very large part of it was about OSPF. That's fair, OSPF is probably the most widely used routing protocol in IP networks. But the poor students were submitted to a relentless sequence of increasingly baroquely named features: stub areas, not-so-stubby-areas, totally stubby areas, culminating in totally not-so-stubby areas.

Can we please get rid of some of that legacy? And if not from the standard documents or the router implementations, then at least from the certification requirements and training materials?

Shortest path first, but not so fast

The Open Shortest Path First routing protocol (OSPF, Internet Standard 54) was first defined in RFC 1131 in 1989. So in internet time, OSPF is truly ancient. The base OSPFv2 specification is over 200 pages, with additional extensions in separate documents spanning the early 1990s to the late 2010s.

OSPF is powered by Edsgar Dijkstra's shortest path first algorithm. SPF is a relatively efficient algorithm for finding the shortest path between two places, in the real world or in a network. Still, in a large network there's a lot of paths to check until you can be sure you've found the shortest one. The problem here is that for a network that's 10 times larger, SPF needs 60 times as long to run. So if a router in a network with, say, 100 routers, needs a second to do its SPF calculations after an update, in a network with 1000 routers that takes a minute, and in a network with 10,000 routers an hour.

So in order to make OSPF useful in large networks, you can split your network into different areas. The SPF calculations are then contained to the routers within each area. So rather than calculate SPF over a 10,000-router network, you could have 100 areas with 100 routers each. Then routers that connect two areas would have to calculate SPF over 100 routers for two areas, so 2 seconds rather than an hour worth of SPF calculations.

But if each of those 10,000 routers still injects two, three or four address blocks into OSPF, that means the OSPF database will have something like 30,000 entries. So now updating and remembering all those address blocks becomes a bottleneck. Solution: summarize link advertisements. So if routers in area 35 advertise address blocks 10.35.1.x, 10.35.2.x, … 10.35.95.x, rather than push out all that information to all 10,000 routers throughout the network, the area border routers for area 35 simply say “10.35.x.x” to the rest of the network.

Even better: if an area only connects to the “backbone” area (area 0) and doesn't learn any routing information from other areas or from outside OSPF, it's a stub area that really doesn't even need to know anything that's happening in the rest of the network, so let's give it a default route to reach the rest of the world.

Variations on a stubby theme

Stub areas still have some OSPF routing information from other areas. We can get rid of that too, and then we have a totally stubby area.

On the other hand, maybe we want to import external routing information into OSPF even in our stub area, and then propagate that external information to other areas. This makes for a not-so-stubby area.

And who said you can't have your cake and eat it: let's make our totally stubby area not-so-stubby, and we'll have a totally not-so-stubby area, guaranteeing certification income for years to come. (See Wikipedia's page on OSPF for more details.)

Spring cleaning

As protocol designers, we're really good at adding more capabilities, more options. As network architects and engineers, we're really good at adding complexity to make our networks do something they won't do out of the box. But we can't just keep adding options and complexity without ever taking any of it away. At least not if we want to have a fighting chance at teaching our craft to the next generation so we can retire at some point.

Our routers/computers are now 1000 times as fast and have 1000 times the memory as the 68030-based routers/computers back in 1990. OSPF implementations support incremental SPF.

10,000 routers in one area will melt the network operations center long before the SPF calculations melt the router CPUs. I've personally worked on a network with 600 routers in area 0 back in 1999. SPF performance was the least of our concerns.

So I'm calling it: OSPF areas and summarization are now legacy. New and current OSPF networks should just use a flat area 0 rather than try to micromanage the information flow between areas. Students should no longer have to learn how areas work, and only be informed about the various flavors of stubbiness as an example of humorous naming that doesn't age well.

Permalink - posted 2022-05-12