Mixing old and new Nikon lenses and cameras

▼ Seven years ago, I wrote Understanding old Nikon lenses: AI, AI-S, AF and AF-S. A few things have changed since then, so I thought it was time to do a follow-up that looks at how well different Nikon lens generations go with different Nikon camera generations.

The easy solution is of course to uses lenses and cameras of the same generation. All Nikon cameras introduced since about 2015 work with all Nikon lenses introduced since about 2000. But where's the fun in that?

First: what’s new since my previous article: AF-P lenses, E lenses and the new Z mount.

AF-P

For the past 20 years or so, Nikon’s autofocus lenses used ultrasonic "silent wave" motors in their AF-S lenses. AF-P lenses use pulse / stepper motors. Those can make small changes very quietly, so they're great for video. A big difference between AF-S and AF-P lenses is that the manual focus ring on AF-P lenses is not mechanically connected to the lens elements. Instead, the focus ring sends information back to the camera, which then uses the focus motor to change the focus.

This change means that the camera needs to know about AF-P lenses, or you won't be able to focus. Cameras introduced starting around 2013 support AF-P lenses. For some of these, a firmware update is required, and possibly there will be some reduced functionality.

E (electronic aperture) lenses

AF-P lenses also tend to be type E, indicating the lens has an electromagnetic aperture diaphragm actuator. (Not to be confused with "E series" manual focus lenses.) Support for E lenses goes back a few years further than AF-P lenses, to around 2008-2010, depending on the camera type.

Z mount

In 2018, Nikon introduced the Z line of mirrorless interchangeable lens cameras, and these cameras no longer have the F mount that Nikon's SLRs have used since 1959. Nikon has released a number of Z mount lenses, which are all AF-P as well as type E lenses. Of course these lenses don't work on older cameras, but F mount lenses will work on Z series cameras through the FTZ adapter. All the discussion below is about F mount lenses, for Z type cameras use of the FTZ is assumed.

The lens types

From left to right: pre-AI, AF-S type G, AI, AF type D, AI-s

So now we have an understanding of the following types of lenses:

• Pre-AI: manual focus
• AI or AI-s: manual focus
• AF: focus motor in the camera body
• AF-S, DX and FX, ultrasonic focus motor in the lens
• AF-P, DX and FX, stepper focus motor in the lens

All types of AF lenses also have a CPU in them which lets the lens tell the camera its properties. Let's see how they work on different cameras. I'll talk about the following specific cameras that I own, or more broad categories:

• Nikon FE, standing in for the AI type manual focus film cameras (around 1980)
• Nikon F65, as an example of a late lower end autofocus film cameras (around 2000)
• DX, the lower end crop sensor DSLRs (D3x00 + D5x00 and their predecessors)
• D7x00 and their predecessors mid-range DX camera with AI/AF lens support
• FX, the full frame high(er) end cameras
• Z DX: the Z50 and Z fc
• Z FX: the Z5, Z6 and Z7

So here we go.

Nikon FE and contemporaries

• Pre-AI: camera doesn't know aperture setting, so problematic metering
• AI or AI-s: perfect!
• AF: good!
• AF-S type G: no aperture ring, so fixed aperture and problematic metering
• AF-P: focussing impossible

Nikon F65 and similar

• Pre-AI: mounting will cause damage
• AI or AI-s: no CPU, so no or problematic metering (manual focus)
• "AF": perfect!
• AF-S, FX: perfect!
• AF-S, DX: typically black corners, some lenses may work to some degree
• AF-P: focussing impossible

DX DSLRs (lower/mid-range)

• Pre-AI, AI, AI-s: no CPU, no metering
• AF: manual focus
• AF-S: perfect!
• AF-P: depends on camera age

D7x00 and its predecessors

• Pre-AI: mounting will cause damage
• AI, AI-s: no CPU, enter lens data manually (manual focus) (no metering on D7500)
• AF-D: perfect!
• AF-S: perfect!
• AF-P: depends on camera age

FX DSLRs

• Pre-AI: mounting will cause damage
• AI, AI-s: no CPU, enter lens data manually (manual focus)
• AF-D: perfect!
• AF-S, FX: perfect!
• AF-S, DX: automatic cropping, but viewfinder shows black corners, some lenses may work in FX mode to some degree
• AF-P: depends on camera age

Z mount DX with FTZ

• Pre-AI, AI, AI-s: no CPU, so stop down metering, reduced focus aids
• AF: manual focus, reduced focus aids
• "AF-D": manual focus
• AF-S: good, somewhat hunting and noisy focus in video mode
• AF-P: perfect!

Z mount FX with FTZ

• Pre-AI, AI, AI-s: no CPU, so stop down metering, reduced focus aids
• AF: manual focus, reduced focus aids
• "AF-D": manual focus
• AF-S FX: good, somewhat hunting and noisy focus in video mode
• AF-S, DX: automatic cropping, also the viewfinder image, somewhat hunting and noisy focus in video mode
• AF-P FX: perfect!
• AF-P DX: automatic cropping, also the viewfinder image

As always, additional caveats may apply, be sure to check compatibility for your specific camera before you go out and get new lenses.

Conclusions

It looks like the D7100/D7200 as well as the not-too-old FX cameras are compatible with all F mount lenses. There is not a single lens type that works fully with the entire range of cameras, but the AF type D lenses come closest: they work on the old manual focus cameras, work with with autofocus on the mid/higher end DSLRs and still work fully as manual focus lenses on all other cameras.

An AF type D lens is still largely usable on cameras like the Z family, where you'll have to focus manually. But with the traditional "electronic rangefinder" focus aid available, where the autofocus system tells you if you've achieved focus, that's actually a bit easier than on an old manual focus camera such as the FE. However, manual focus lenses without a CPU for some reason don't get full focus aids on the Z cameras. You can still focus very precisely by zooming the viewfinder, but this is quite slow.

So there you have it. I'm sure the next few years the second hand F mount lens market is going to quite interesting, as more and more Nikon users migrate to a Z camera or a non-Nikon mirrorless camera.

Update:

In the original version of this article, I mistakenly said AF lenses that are not AF-D lenses don't have a CPU. That's incorrect. On DSLRs AF and AF-D lenses work the same, but for some reason on a Z camera (through the FTZ) the AF-D lenses have full focus aids but AF lenses have reduced focus aids. However, AF lenses are still more functional than non-CPU manual focus lenses because on AF lenses, the camera can control the aperture.

On non-CPU lenses, the camera doesn't know the aperture so it's difficult to use apertures smaller than about f/5.6 or f/8 because focussing gets more difficult at smaller apertures, so you may have to use stop down metering.

Permalink - posted 2021-10-09

Amiga short takes, juggling CF cards edition

▼ In this latest installment of Amiga short takes:

• Iconverter v1.0 released
• Just use FAT32 for your external CF cards
• Back up to HDF images
• CardBootDisk
• Joystick restrictor plates
• The Deathbed Vigil
• WHDLoad doesn't like network connectivity

Iconverter v1.0 released

Almost two months ago I released version 0.8 of Iconverter, a tool to convert old Amiga icons so they look right on Amigas running a newer OS version. Version 1.0 will now write ColorIcons by default, but can still write NewIcons. It can also read NewIcons and ColorIcons, and thus covert between the two. And write BMP files. (See the Changes section in the documentation for more details.) Available here and on Aminet.

Amiga 3000 boots a lot better with FastFileSystem added to a boot partition

Because I was getting read errors on the CF card that my Amiga 1200 uses as its harddrive, I decided to play musical chairs with all the SD cards. Which resulted in my 3000 not willing to boot even though it had three perfectly good boot partitions on different drives available. (The superkickstart that needs to be loaded from the harddrive makes the 3000's boot process rather complex.)

These issues went away after I used HDToolBox to "add" the 3.0 version of the FastFileSystem to these boot partitions.

Just use FAT32 for your external CF cards

Replacing the CF card is the easy part. The hard part is getting all the data from the old one to the new one. Now I could slightly cheat because I have an IDE-to-CF adapter than can take two CF cards. With that, it's just a question of setting up the right partitions and copying all the data with copy DX0:#? to DY0: all clone.

In the past, I've managed to mount Amiga-formatted CF cards using a PCMCIA adapter. But that's quite a bit of work and often unsuccessful. However, mounting FAT32 formatted cards in the PCMCIA slot is super easy. So after inserting a third, FAT32-formatted card to temporarily hold the data in the PCMCIA slot, now it's time to...

Back up to HDF images

Obviously it's possible to copy all the files to the FAT32-formatted card. And even though the Amiga isn't too picky about special file properties, there's always a chance that something gets lost in translation. Also, copying individual files is relatively slow. It's much faster to just write an HDF image of the partitions on the old card to the temporary card. The TSgui tool will do that.

This worked very well on my Amiga 3000, but not so much on the 1200: systems running Workbench 3.0 said the image "was not a DOS disk". After I got 3.1.4 back up and running again on the 1200, it mounted the images just fine. However, I couldn't make an HDF image of my largest partition at all. It looks like TSgui is limited by the original Amiga 4 GB drive size limit.

Still, it's not a bad idea to create empty HDF images (or download these) and mount those with ImageMount and copy files to the image rather than directly to the FAT-formatted card. Just make sure to check whether they're readable before switching those internal CF cards...

CardBootDisk

So now you have an empty CF card inside the Amiga and a FAT-formatted card with all your data (and, for good measure, ADF files of the Workbench disks and a copy of HDToolBox). Then you turn on the computer and it doesn't see any of that. So I made a CardBootDisk, which is a floppy that has all the drivers to mount FAT-formatted cards in the PCMCIA slot and ImageMounter to mount ADF, ISO and HDF images. So after booting from that floppy you can partition your new internal CF card and start copying data to it. If you forgot anything, just plug the CF card into another machine (in my case my Mac) and copy the missing data on the card and put it back in the 1200.

Download the ADF image of the CardBootDisk. Tip: if you're installing a fresh copy of AmigaOS, first copy all the files from the CardBootDisk to the harddrive and then install the OS over it. You should then still see the CF card after booting from the harddrive.

Joystick restrictor plates

I got an arcade style joystick recently. I'm not entirely happy with it, but I also don't want to write a bad review. So I'm just not going to name any names. Anyway, the actual joystick mechanism is great, much better than my old joysticks from the C64 days or the ones that come with THEC64. (Too bad the THEC64 won't recognize this joystick when used with a perfectly good DB9-to-USB adapter.)

The thing I wanted to mention is the restrictor plate. This one came with a square one with rounded corners. When playing my favorite game, BoulderDäsh, that doesn't work very well. When for instance you move right, but not exactly at a 90 degree angle, but let's say 95 degrees, the restrictor plate makes it really easy to slip down to 120 degrees or so and now you're trying to walk diagonally. Which makes Rockford walk down.

The fix is to rotate the restrictor plate 45 degrees. Now the round parts catch the underside of the joystick as you move left/right/up/down. But in this configuration, it's almost impossible to move diagonally. So for games that need that, this is unworkable. Solution: get a new restrictor plate. Gaming supply shops sell those. I got an octagonal one, which works fine, but perhaps a round one would have been even better.

Restrictor plates. Who knew. Of course with arcade games a joystick would only be used with a single game, so it makes sense that there are different ones that allow for different degrees of freedom. Something to check for when buying joysticks.

The Deathbed Vigil

Recently I rewatched "The Deathbed Vigil and other tales of digital angst", the movie Dave Haynie made of the last days of Commodore. If, unlike me, you didn't get your VHS copy 25 years ago and still have a VCR to play it, you can now also watch the movie on Youtube. Don't miss the "Chicken Lips Blues" at the 55:30 mark.

WHDLoad doesn't like network connectivity

A good way to easily run demos and games, especially floppy-based ones, is with WHDLoad. On the official website they focus on providing "slave" definitions that allow you to import your existing copy of games, but of course helpful individuals around the internet have already imported lots of games... You then just click an icon and you can start the game.

However, when I tried installing WHDLoad last year, I could only get a handful of games to work, most would just show garbage on the screen. But then when I was messing about with CF cards, all of a sudden all the games worked. Turns out that WHDLoad makes some kind of network connection (as it tells me there is a newer version) and then doesn't work properly. Shutting down the network before starting any games fixes that.

Update:

I blocked cgi.whdload.net so WHDLoad can't perform its update check, but that didn't help. After some further checking, it looks like it's a hardware issue with the way PCMCIA network cards work. I normally use the I-Card, which is a wired 10 Mbps Ethernet card. With that one, if I shut down Roadshow, my networking software, WHDLoad games work. Or, keep the network stack running but unplug the Ethernet cable. But as soon as I plugged the cable back in and the Amiga started to receive (broadcast) packets, the game stopped working. So I'm guessing the issue is with interrupts generated when packets arrive.

With the 11 Mbps Wi-Fi card there's obviously no cable to disconnect, and just shutting down the network stack isn't enough: the Prism driver comes with a WirelessManager program that handles connecting to the right network, so you need to shut that down, too. Use the status command to see the process number (for instance, 6) and then type break 6. Interestingly, taking the wireless network down by turning off the wireless access point also works, even though the activity light on the Wi-Fi card still blinks once in a while.

And... then it turns out this is a known bug. RTFM, Read Those Fine Manuals. Weird though that WHDLoad happily uses the network as you start a game and doesn't issue a warning.

Permalink - posted 2021-08-15

(Re)creating new Amigas for the 2020s and beyond

▼ Two forum posts made me think of what it would take to build an Amiga using modern parts, and what should remain the same and what should change about a new Amiga to remain useful in the next decades.

The first is on AmigaLove, a forum that I found recently and that I enjoy participating on: FPGA Custom Chips. The original post is about creating FPGA implementations of the Amiga's custom chips. That way, it's possible to replace the original chips when they fail, or build a new Amiga from scratch.

The other one is on the MiSTer FPGA Forum: Faster CPU for Minimig core?. (Minimig core = Amiga on the MiSTer.)

(An FPGA is a field programmable gate array, or basically a lot of small parts that perform functions used in all kinds of computer chips, and these parts can be connected in different ways so the FPGA can "become" lots of different chips.)

But what should be our goal?

Obviously, some of us, especially those who still have Amigas that we use from time to time, would love to retain access to something as close to an original Amiga as possible. However, then what about the peripherals?

Today, if you bring an Amiga into a home, there's a 99% change that you can't hook it up to a TV or monitor there, and a 99.9% chance you can't exchange any files between the new Amiga and anything else.

So I say: a new Amiga needs to be more like a THEC64 than an actual Commodore 64 (well, actual Amiga). That means: HDMI for video output and the ability to use USB peripherals.

And that's not impossible. I'm typing this on my Amiga 1200 right now, but I'm using an HDMI monitor thanks to the Indivision AGA MK3 adapter and a USB mouse thanks to the MouSTer adapter. And a USB keyboard thanks to the Rapid Road USB adapter, but I readily admit that that's just showing off. (Although the CTRL keyboard types a lot nicer than a 28-year-old Amiga 1200 keyboard.)

What this could look like is just like with the original Amiga generations, two versions: one integrated with the keyboard, and a "big box" model. I think for the integrated one, a case that holds the middle ground between the A600 and A1200 would make sense. Remove the numeric keypad but keep the cursor keys. This is something new, it doesn't have to look exactly like its predecessors. For the big box version I think something that looks like an A3000 but smaller would be great, or maybe even a smaller version of the Amiga 1000 case.

Chipset and floppies

Obviously to run old games, the chipset needs to recreate the A500/A1000/A2000 chips exactly, as seen by Amiga software. So USB peripherals such as mice, joysticks and keyboards must be remapped to recreated versions of the Amiga hardware. I think that also needs to apply to the floppy drive, as so many games and demos had their own floppy drive code. Perhaps the machines should optionally have an actual floppy drive. That way, access to the floppy-based Amiga legacy is guaranteed. But most of the time, an integrated Gotek-like floppy emulator would do the trick.

(And the middle ground: something that physically looks like a floppy drive and accepts floppies and floppy-shaped objects, but then only reads a barcode from the back to mount the right disk image. That would provide the authentic experience without all the issues with actual magnetic storage.)

Ports

On the one hand, it would be great to have all the original ports, but on the other hand, that is more difficult/expensive, for probably relatively little benefit. Let's have a look:

Mouse and joystick ports: it's easy to map USB mice/joysticks to the Amiga hardware. I'm doing that right now. Then again, the hardware is super simple, so perhaps the ability to use the real thing isn't too onerous.

Video: I'd say: just embrace HDMI and leave the past behind. Of course add good scaling and filters and especially handle PAL vs NTSC well. One of the cool things only the Amiga could do is switch video modes on the fly when cycling through screens.

Then again, the MiSTer FPGA platform does support analog video out currently. Could this be an option? But a complete Amiga video connector, genlock-capable and all? Too much to ask, in my opionion. If you really want that, use an original Amiga in good condition.

Audio: one of my complaints about the modern THEC64 is that it only outputs audio over HDMI. That's pretty limiting. Please give us line out for those sweet, sweet MOD files.

External floppy: not sure how difficult this is. But is it useful? For an internal floppy option, a PC floppy drive can be used (the differences are extremely minor and can be accommodated in a recreated chipset), but external Amiga floppy drives are more complex. And one physical floppy drive along with additional emulated ones seems more than adequate.

Serial: there are a few uses for the serial port that are still relevant, I'd say. So having the Amiga think it has a working serial port would be useful, but not sure if having the additional hardware is very necessary. The Amiga's serial port could be mapped to a USB serial port but also be mapped to a network service.

Parallel: well, parallel printers are dead. Not sure if there's any printers left with reasonable Amiga drivers. Intercepting the Amiga's print output and saving it to a file for later display, conversion and then printing to a modern printer makes more sense. But the parallel port was also used for all kinds of interesting stuff, such as the Digiview video digitizer. Not a priority, but on the other hand: just a bunch of GPIO (general purpose IO) pins seems workable.

A1200 hardware

So that's all the ports you'll find on an A500 / A1000 / A2000. But there is more. Next to the A500, the A1200 is the big gaming platform that you'll want to support to let people play AGA games. So:

Harddrive: lots of Amiga software needs a harddrive. And again, I think the right approach is to recreate something that looks like the original Amiga hardware from the software side, but then remaps to modern hardware. I'm thinking an SD card as the harddrive.

PCMCIA slot: used for all kinds of stuff, but mostly to exchange data with other systems on CF cards and for network cards. I would replace this with an (additional) SD card slot. As using CF cards in this slot required extra software anyway, it would be fine to have an extra AmigaOS driver to talk to this SD card slot.

68020: the A1200 uses the 68(EC)020 CPU. So in order to run software made for the A1200, it's necessary to support the 68020.

More advanced hardware

Retargetable graphics (RTG): most non-game software on later AmigaOS versions will happily run on screens powered by RTG graphics cards. These don't have the limitations of the Amiga's chipset. So RTG support that integrates well with the Amiga's native graphics capability would be extremely useful.

68030: the Amiga 3000 uses the Motorola 68030 CPU. The 68030 isn't very different from the 68020, except that is has an MMU. Not a feature that is used a lot by Amiga software, but still useful in some cases. So not a top priority, but nice to have. 68040 and 68060 were a lot faster, but also less compatible. It's probably more useful to make the 68020/68030 implementation faster than to recreate the 68040 or 68060.

FPU: the Amiga 3000 has a 68882 floating point unit, and Amiga 4000s with a 68040 CPU had a built-in FPU. I think in general Amiga software doesn't require an FPU, but there could be situations where not having an FPU creates issues, such as having to use a less capable version of some software.

And an FPU speeds up some software quite a lot. (I think some people doing MiSTer Minimig benchmarks aren't comparing their results to FPU-enabled results.)

Perhaps giving up some accuracy for speed makes sense here, for instance by emulating the FPU (or CPU+FPU) in software rather than use a cycle exact FPGA implementation to run this kind of software.

Last but not least: networking. No original Amiga came with a network card. So recreating old networking hardware doesn't make much sense. However, some way to implement networking functionality does. Not sure if a bsdsocket.library that simply punts network calls to the ARM CPU that runs a Linux variant makes sense, or perhaps something that looks to the Amiga like Ethernet hardware and is then bridged with Wi-Fi. That way, the Amiga can use "real" networking but doesn't have to keep up with changing Wi-Fi (security) standards.

Well, that's my vision of future Amigas. Now the only thing to figure out is what model number they should get. 1600? 5000?

Permalink - posted 2021-08-08

Review: MouSTer: making my favorite wireless mouse work with my Amiga

▼ Original Amiga mice were never that great, and a few decades of use and storage didn't help. So if there's one part of the Amiga I have no problem replacing with something new, it's the mouse. (Don't feel bad, I swore of Apple mice, too.) So a while ago I got a USB-to-DB9 mouse adapter. That one worked fine with wired mice, which was a big improvement.

An Amiga 3000 "tank mouse", an Amiga 1200 mouse and a 2000-era Logitech Mini Wheel Mouse

However, a few years ago I discovered the Logitech Anywhere MX 2 wireless mouse. I liked it so much I got one for at home and one for at work. The MX 2 is a bluetooth mouse that can pair with three computers. You can simply switch to another computer with a small button at the bottom. Now obviously the Amiga doesn't do bluetooth, but the MX 2 comes with a Logitech unifying receiver, which you can plug in any USB port and then the computer thinks it's talking to a wired USB mouse.

Problem solved, right? Not really. The MX 2 didn't work with that adapter, nor with another one. Eventually I went as far as to get a RapidRoad USB adapter for my Amiga 1200. This does work very well most of the time, but the complex USB software is not compatible with most games and is not 100% reliable.

The MouSTer connected to a DB9 extension cable, with the Logitech unifying receiver and the MX Anywhere 2

So when I read about the MouSTer, I thought four times might be a charm. After waiting for the little device to make its way from Poland to Holland over the course of very many days, it arrived today. So I plugged it in and... not much. The mouse pointer did move a pixel or two, but nothing close to working correctly. Then I noticed:

So I plugged a USB thumb drive into the MouSTer, which produced furiously blinking LEDs. Afterwards, there was a new directory on the flash drive, with in it a file named MOUSTER.INI. This is a text file with settings and clear explanations what they do. Out of the box, the MouSTer was set up for the Atari ST (hm, maybe the capitalized ST in the name should have been a clue?). I quickly changed that to "amiga". For good measure, I downloaded the latest firmware and put that next to the MOUSTER.INI file and put the thumb drive back into the MouSTer. After that, different mice worked as expected, with just some tweaks to the DPI divider and LED heartbeat settings needed.

A modern optical mouse like the MX Anywhere 2 sends way more "hey, the mouse has moved" pulses than the Amiga expects. As a result, when you move the mouse quickly, the mouse pointer jumps around because the computer can't keep up. Using a DPI divider ("microstep") value of 2 - 5 on the MouSTer didn't completely solve that for me, but using the Mac Logitech Options program to tell the mouse to use the minimum pointer speed, along with a microstep value of 2 made everything work satisfactorily.

Amiga mice normally have two buttons. The DB9 port has just one unused wire, so the Amiga can recognize a third button, but that's it. No scroll wheels—without using different hardware. However, the MouSTer will helpfully map any additional mouse buttons to the three the Amiga can recognize, with or without autofire. A program like FreeWheel will let you do something useful with the extra mouse button.

You can tell the MouSTer is starting up after turning on the computer because its yellow-orange light flashes furiously. (It'll tell you any error messages in morse code.) This is fast enough that if you press both mouse buttons as you turn on the computer, you're greeted by the boot menu as intended.

Conclusions: after only a few hours of use, I'm already a fan of the MouSTer. The hardware is nice and small, so it doesn't stick out far enough to get in the way. The electronics are visible, but covered with plastic so no chance of accidental shorts. The configuration method is unorthodox, but works well. I tested it with both a wired and a wireless mouse, as well as a couple of joysticks. Everything worked. (It also supports gamepads.) Using the Amiga mouse port is a mixed blessing. On the one hand, it's a limitation: only the one extra middle button and no scroll wheel support. On the other hand, it works with everything. In my case, I simply use two Logitech receivers: one on the MouSTer and one on the RapidRoad. So I just flip the mouse and push a button to switch between features and compatibility. 😎

Permalink - posted 2021-07-24

Iconverter makes your old Amiga icons look right

▼ The way the Amiga handles icons changed a number of times over the history of the platform, with the result that many older icons don't look right on Amigas running later versions of the OS. I made a tool to convert these old icons so they look like they should on later Amigas: Iconverter.

Iconverter is a tool for converting old icons so they look as intended on Amigas running a more recent operating system.

In particular Iconverter will convert OS 1.x and MagicWB icons to NewIcons format using the palette those icons were created for. (Also OS 2.0 - 3.1 icons, but those usually look correct without conversion.)

Note that you need to run the NewIcons extension or the new IconLib_46 on an AmigaOS 3.0 or 3.1 system in order to see the converted version of icons created by Iconverter. AmigaOS 3.1.4 and 3.2 will show them "out of the box".

Iconverter is a shell / command line tool written in standard C. As such, it should compile and run on any system that has a C compiler.

Permalink - posted 2021-07-14

The Commander X16 (and some more BASICODE)

▼ The Commander X16 is an upcoming new Commodore 64 like 8-bit computer built from currently available parts, as explained in Youtube playlist. After watching some of the more recent videos, I decided to download the emulator... and tried out some BASICODE on it.

Why a new 8-bit computer?

Part of this is of course middle aged nerds wanting to relive their childhoods. Not discounting that aspect, I do think there was something special about the 8-bit home computers from the 1980s. Because those systems were so limited, they dispensed with all overhead and just gave you the minimum needed to write and run programs. So it was easy to write programs like games yourself.

And for some reason, for me at least, none of that translated to more modern systems like the Amiga. Not too long after I got an Amiga, I learned C in college, and ended up writing relatively low level code such as my own traceroute implementation. But I never wrote anything that uses the graphical capabilities of the Amiga, PC or Mac. (Unless you count some more recent web stuff.)

Now obviously those old computers can still be found, but it's getting harder and harder to use them, as compatible displays and I/O options are becoming more scarce. Some kind of emulation such as the THEC64 works well to run the old software more easily, but has nothing to do with the old hardware. Part of the charm of those 8-bit computers is that a single person can understand the whole thing, software and hardware.

Commander X16

So that's where the Commander X16 comes in. The basic idea is to start with a VIC-20, which is an extremely simple design with many parts still available, and then update some parts as necessary.

The biggest issue was finding a good graphics chip with abilities similar to the C64's VIC-II chip. They couldn't find any, so they use an FPGA-based video controller instead, with 128 MB of its own video RAM and also an SD card interface for storage. Audio options were also less than ideal, so it looks like they're also going to use the VERA FPGA video controller for audio.

The VERA will output 640x480 analog VGA, with various text and graphics modes.

The CPU will be an 8 MHz 6502. It's really too bad that they didn't choose the 65816, a backwards compatible 16-bit successor of the 6502. The X16 will have 40 kB of regular RAM (minus a bit for hardware registers) followed by 8 kB of "bankable" RAM. That's 512 kB or 2 MB of additional RAM, but the 6502 can't address that much memory, so at any one time, 8 kB of the extension RAM can be mapped into the 6502's address space. The ROM works in a similar way, with one 16 kB bank out of a total 512 kB available at any time.

The X16 will support a PS/2 keyboard and mouse as well as various extension options. Unfortunately, there is no RS232 port or any other way to communicate with the rest of the world included. So that means either an extension card or swapping out that SD card on a regular basis.

They eventually licensed the C64 BASIC and “KERNAL”, so BASIC programs or even machine code / assembly programs that only uses the system interfaces and don't try to directly use the C64 hardware will run on the X16. On the one hand, that's nice because it's familiar to people who've programmed on the C64 and it will be possible to port over C64 programs relatively easily, but on the other hand, even within the limitations of an 8-bit computer there are a lot of things we could do better these days. For instance, the C64 uses a weird variation of ASCII that makes exchanging text pretty annoying.

BASICODE on the X16

So I wanted to see what it would take to run BASICODE on the X16 using the emulator. I didn't know yet they'd licensed the C64 ROMs so I was surprised to see how compatible the X16 really is with C64 BASIC and C64 system calls. For the most part, the only thing I had to do is change my cursor position code a bit to use the official API call rather than jump directly to the KERNAL code.

But... Cursor positioning once again turned out to be my nemesis. Although the C64 has a 40-column screen, when you move beyond column 39, you continue on to 40, 41 and so on, until 79. That way, you can type lines of BASIC longer than 40 characters. So that creates trouble with BASICODE programs try to figure out the size of the screen. For the C64, I just made sure you couldn't go beyond column 39 and line 24.

The X16's default text mode is 80x60 and it can also run in 40x30. So I had to figure out which mode we're in to tell the difference between the actual column 40 on a 80x60 screen, or the face column 40 on a 40x30 screen. BASICODE programs may also try to figure out the size of the screen by specifying line 100 or so and see on which line they actually end up. But specifying a line outside the actual screen hangs the computer (or emulator). So I had to work around that, too. Eventually I managed to do all of that, and that same code now runs correctly on the C64 and the X16 both in 80x60 and 40x30 mode.

I've updated the my C64 BASICODE subroutines here. Here are some BASICODE programs in English. I like Sea Wars, which is a pretty good version of Battleship, which can run in Dutch, English, French and German. This is the PRG file that will run on the C64 or Commander X16: seawars.prg.

Permalink - posted 2021-05-30