Super Amiga Keyboard Time!

Special Needs

I've never been comfortable with QWERTY keyboards. Maybe it's just because I can't touch-type. The other keys are in awkward positions for me too. Also, I'm primarily a BASIC programmer who doesn't use the numpad a lot because I'm lefthanded and it's too far off. Special needs! It really takes up desk space too. Still, it's nice to have the math and programming characters available without relying on modifier keys. When modern laptop keyboards implement a compact layout they often use lots of modifier keys or scatter things about. Where's +? Oh, / is over there. * is on... 8. So, I want to design my own keyboard and the opportunity to elaborate presented itself with the escalation of this Amiga project. The keyboard has to be kind of international, supporting English, Swedish, German, Spanish, the latter via "dead-keys" which can put various accents/diacritics on characters. It shouldn't be a brick with cherry switches and "layers". I'm thinking Amiga 600 form factor.


For reference, here's my A500 keyboard. Notable features:
• Long space bar is long.
• Baffling amount of duplicate characters. ++(()) && '' *** :: == "" /// ,, ^^ --_ _
• I think there are a few diacritic/accent dead-keys but it's hard to spot them.
• Numbers on number row are too small and the keys are very busy looking. • Other messy keys makes it harder to see what dashes and dots are low and high.
• I believe the long dash is actually the underscore. There is no em dash.
• Should be YUIOP... I reassembled it incorrectly.

Keyboard layouts. It's hard to give new layouts a fair trial when one is so used to the arbitrarily established QWERTY and can't really shift just like that. I think I'd like the ABC (MNOP rather) one though. L and J are a bit unfortunate but otherwise the positions aren't too bad. Slightly updated version of it on the A770 concept later on...

I've seen letter frequency tables of C, JS etc, but not BlitzMax/BASIC. I wrote a thing and ran a few of my Famicube source files through it. BASIC is less pedantic than C so it doesn't need ; and () and {} cluttering up the code, so those are less common here. BlitzMax can use A$ and F# BASIC style variables but I don't use that declaration feature. X and Y might be a bit more common in code than general writing. Other than that, the counts are somewhat close to elsewhere with 0 1 E etc. being common.

With a keycap puller and keyboard layout program it might be fun to customize my A770 layouts (keymaps) using an editor of some sort. Since the keyboard might be out of commission I'm thinking a visual mouse interface might work... just drag characters onto the keys.

I cobbled together a microcontroller (32U4) driven USB keypad once. It just sent key strokes serially. There's a limit with USB of a few simultaineous keys + modifiers, but some keyboards pretend to be two keyboards to get around this. If I'm not mistaken, the A1200 used a 68HC05 microcontroller and serial communication. I suppose a microcontroller could store a custom keymap in EEPROM and default ones in progmem. But perhaps I'd just want to shift out a (momentary) 96-bit bitfield of all switches (12 bytes), which can be analysed by the BIOS/driver to produce a stack of keys (UTF-8?) since last scan.

First QWERTY Attempt (Dec.2019)

Jump to latest version on this page.

The Amiga uses a certain old (1986 or so) character set supporting several "latin" languages. However some characters are missing like the Euro sign, em dash, TM, and useful math/electronics glyphs. It does include • Bullet point, x dimension sign, © copyright, and ° degrees. I've always wanted those directly marked on a keyboard as I can never remember the key-codes or what Alt key they're on. Certain graphical characters are really difficult to show using lowrez fonts, like ¾ fractions and ® registered trademark.

I've included a number of accents/diacritics and after moving them around a bunch I decided to go for consistency and put them all as Alt-characters on the number keys. They could be printed using red to lessen confusion/noise. This left the keys near Return a bit barren... but I don't want to overload the keys either. Dots and such easily get lost in the noise.

The Amiga spacebar is really long. I looked at the wear on my PC spacebar and thought it'll be safe to shorten it quite a bit, like on Japanese keyboards. I think having some cursor keys down there would save wrist when navigating text. Right now I have to either move my right hand or pinky-out to the arrow keys. Programmers spend a lot of time formatting rather than typing. Parenthesis is more common than brackets, so that's another optimization. Copy pasting can put a strain on the wrist if Ctrl is in low pinky position, but on the Amiga it's to the side instead which works quite well.

On old computers like the MSX and Amiga, you could often control the joystick and mouse with the keyboard. On the Amiga you need to hold the Amiga keys which is kind of wonky and not obvious. I thought a tristate "lock" key might be a better solution (using two LED colours as indicator). I like the LED window key on the C65 remake by the way. The off/joy/mouse lock is perhaps best situated near the relevant arrow keys. Some nearby keys could be used as buttons.

What else... oh, right, the excellent looking Russian ZX clone called Didaktik has a pretty neat power light design... a sort of pretend-key which integrates it into the keyboard design really well. The A600 did it too, so I went that route with my indicator LEDs. I wanted to keep the arrow keys raised up one step like on the original Amiga and similarly ended up without any Pg.Up/Down/Home/End. I suppose those were alt functions of the arrow keys on the Amiga, depending on software.

I prefer half-height keys over both flat chiclet and full-height (be it cherry or old spring switches). I've positioned the text in a way which makes sense to me. Alt mode glyphs are right-center. Shift is left-top. System key text is centre-centre and so is single-use keys like =+-*. The down-arrow is slightly lowered. I believe older Amiga keyboards had a C= and A key but this was later turned into two A keys.

Full Throttle into Crazy Land

The A500 case design is a bit bland. Initially I wanted to do a smaller version of it, but my redesign below drifted away from the photo I used as a base... perhaps towards something more Atari-like? Mostly I wanted to see how my keyboard layout looked. Then I... began changing things.

I made the unshifted/primary chars larger than on the Amiga, except for A-Z which are traditionally caps. I swapped a few keys from the previous layout. Left Alt is now as high as Ctrl which I positions it nearer the number keys and it's not hidden by the hand. Also added «guillimets», and an approximate equal sign which might seems useful. I can't even easily type it on a modern keyboard. Actually it's Alt-x on my mac ≈≈≈, which doesn't really make sense so I won't remember that.

I decided to add some specs for fun. Hard to say where the Amiga should've gone. So much became rapidly obsolete mid '90s. Everything had to be quickly scalable, but the Amiga had a somewhat expensive custom design... which worked well in late '80s but later not so much. Other companies ran into trouble too so it's not like there was a silver bullet. I think.. at least with a 68030 (somewhat expensive then tho), memory would've been scalable. Additionally, a SVGAish GPU with dedicated memory would've helped when porting PC titles and worked better with 3D games than bitplane graphics. A friendly tile mode would've been nice too, just to promote simpler game development, especially early on.

I turned the number keys into a sort of one-hand numpad (the HighPad?). The number stuff is spatially discrete and accessed by moving both hands up just a little bit. 0 1 (more common) are accessible by index/long finger, and number entry can be done one-handed. Dot & comma might still be accessible on the thumbs when entering numbers. <> and () are available on the pinkies. There's a shift key under Escape for $%& and such. Alt can be used to select diacritic dead-keys. The diacritics are in red on the num keys to separate them from similar dotty looking characters.

MNOP layout huh? Well, I wanted an ABC layout because it synergizes with and reinforces an existing structure which could help with learning. But, straight-up ABC puts many keys in bad positions. However, with swapped rows it looks about as good as QWERTY. I noticed after trying out some touchtyping on a paper model that fingers will "jam" trying to type WITH... unfortunate since the bigrams IT and TH are very common. Some custom finger moves might be needed there. The letter L unfortunately would end up either on left high pinky or far right pinky, so I cheated a little bit and moved it to bottom row under JK where it feels a bit more accessible. I guess it could displace the top row one key (LMNOPQ), but I wanted Q at the center. I use " and : a lot so I put them on some free keys, but maybe those keys are better off as language specific keys. Spot the Alembic! It's a fairly obscure symbol depicting a destilling machine (retort), perhaps used by wizard achemists. I like how clean and cute it looks. Would be elephants in a Rogue-like.

! ? can be found near the original QWERTY "1" position. X & Y coordinates are often used in programming and those keys are now on right hand index finger. Had to put the German hard S on Alt S. It's there in English QWERT, but on H in German.

I moved in Left Shift so it's less of a pinky stretch. The Tab... I noticed it looks different on Amiga keyboards. It's more clearly showing a normal right-arrow tab in the low position and then a left-arrow tab in the high, shifted position. The latter is used to outdent text blocks rather than indent.

When programming I do use tab a lot so I added a second one near the spacebar, where one can also find extra arrow keys (Alt changes to vertical axis). I noticed that when I program I keep my right hand more over the Return key so I can reach the arrow keys with my pinky. It's straining on my PC keyboard where the arrow keys are low (spacebar level, but on the Amiga they're one step up (shift level) which is a little better.

Still I wanted dedicated Beginning-of-Line and End-of-Line keys, so I raised the arrow keys up further to make room. Alt+BoL/EoL could step words (X axis). If stepping words is more useful I guess it could be primary behaviour. I only had space for a combined PgUp/Dn key. It could be shifted I guess, with Alt turning it into Home/End (Y axis behaviour in all cases). Linux seems to use Prior and Next keys as Page_Up and Page_Down... which are unused? Unfortunately there are no word step or top/bottom document keys (that I know of) so it's perhaps program specific behaviour, and inconsitent.

On my Mac, Alt+L/R steps words, Alt+U/D steps whole strings, i.e. paragraphs, but that's usually lines in code. It's confusing behaviour because U/D is Y axis. Shift+Arrows selects text.

I had some idea of adding a Move key, so after selecting a block one can hold the move key and arrow it around rather than Cut-Pasting. Let go to drop. Essentially it's Cut with Paste on release (or second tap). Not sure if it would work. Might save a lot of time though. The text cursor could change to a block whilst moving. The same key could have a Copy-Paste mode useful for e.g. duplicating lines of code or variable names. It does nothing without a text block selected but it might be up to applications to handle these kind of keys.

On the Amiga, I believe Shift+Arrows is hard mapped to SoL/EoL/PgUp/PgDn. The Ctrl key wasn't used much on the Amiga. I remember seeing the [A] keys in program menus (one of the As is inverted). I think one needs to be clear about separating OS command hotkeys (Super) and program hotkeys (Ctrl).

I initially made [ Backspace | Delete | Insert ] neighbours, but after testing I was immidiately reminded of how annoying it is to go into Insert mode accidentally so I stowed it away as a level on the Delete key. I added a word erase backspace key instead of Ins. There might be a terminal code like that.

I modified this Mac keyboard (A1048) to somewhat match my MNOP layout, then I wrote a little typing program to try it out. I type at just 35-40 WPM on QWERTY, and with MNOP that dropped to 7.5, rising to 20 after some hour of practice, only to drop back to 12 after changing to an unfamiliar sentence. I guess one mostly learns stroke sequences, similar to how speed-reading is about recognizing familiar word or phrase "pictures".

It seemed difficult to make an actual keyboard layout that would work in an OS, but after looking into linux's xkb system I thought it might be doable... and it sort of was. In the process I learned a bit about how keyboards work. They send keycodes (e.g. key 21) and then the OS has lookup tables for various models. On an old Mac keyboard, 21 might be the first alphanumeric key on the fourth row from bottom (called "AE01" on linux). Then another lookup table translates that to the "q", "Q", or Bullet depending on "level" dictated by Shift & Alt if held. This means that it's possible to use any keyboard model with any exotic mapping like say DVORAK, or my MNOP layout. There's also a geometry file which is just for visual presentation of the keyboard (pictured above).

Linux xkb chunk of text. Very much WIP and seemingly only works in basic text editors. Maybe there's some compatibility or hidden definition thing I've missed.

I think the Function keys should use levels. This way only 10 keys are needed. It would produce 30 function keys with three levels, and it would clean up menus: | Debug menu ______ F14 |. If more than 30 keys are needed (or accidental presses prevention), Ctrl or the OS key could be used. It shouldn't be Alt+F4, but OS+F4 because killing current application an OS function and Shift & Alt should only be used for levels. About Fn keys which extend small keyboards (like adding a numpad layer onto the alpha keys), I think maybe Ext or Layer might've been a better name... it's all levels/layers I guess, and it gets a bit confusing using different names for the dimensions, but they can't be too similar either. YShift, YShiftLock, XShift, XShiftLock, ZShift, ZShiftLock... eeh. I think Shift and Alt shouldn't combine, but there could be a LayerLock key which does, giving a part of, or the entire keyboard, new functionality. Maybe that's how kana modes on Japanese keyboards work? Such a key could be tristate or more... like my kb/joy/mouse lock key.

Right handed variant which puts numbers in read order. Note that Shift on pinky has to follow. Thinking about it now, it might be a good idea to put a Shift key under both Esc and F6 so people can swap layout. Also, Shift could be used along with BS/Del to erase words.

Apple Intermission (Oct.2020)

Another right handed variant based on the Apple //c - the Drive Dock. No Alt/Opt near the number/diacritic keys now, but I did mirror the upper shift keys. The keys surrounding the arrow keys are for one-handed code/text navigation/editing. fn is used for pageU/D, home, end and F6-F12. I also had to move , . to spacebar row so they're on a thumb when in number mode (would prefer to have them on V B though). Backspace and Delete always felt a bit inaccessible to me over Enter because they're on the high pinky, meaning big hand movement.

Enter the Matrix

The ghost problem. Diodes between each row on each column can solve it, but you'll need quite a few.

As I understand it, a keyboard matrix would not produce ghosting along a row, or if only one switch per column is on. It's the "L" shapes that spawn ghosts. So maybe WASD and arrows should be on the same row? Modifier keys are not in matrix. In theory I guess the whole 1234, QWER, ASDF, ZXCV (4x4) chunk could be one row. Then you'd plenty of keys for grenades, zoom, crouch, etc. It'd only work for one player (per keyboard) though. A PCB autorouter could probably figure out the traces for that (to adjacent similar blocks).

Ghost keys can be detected because they appear on the same poll frame along a column, and unless polling frequency is very slow, it's highly unlikely to be human presses. But, it's problematic what to do about it... the controller needs to remember and filter these presses. Then the human can of course mangle the keyboard further, meaning the filter has to be expanded. A bitfield?

A very cheap solution is to only allow one active row at a time. The active row is selected on a first-come basis, i.e. the other rows HAVE to be 0. If two rows get presses (e.g. D and V is held) then no one gets to play. There could be a software (or jumper) disable for this, along with diode pads on the PCB e.g. []-[] where - is cut and a SMD diode can be installed... through-hole might work but needs much more space. Scratch-built keyboards are a different thing as they often use the diode legs as traces.

Here's my attempt at staggering the keys so "WASD" (in qwerty) and arrow keys ends up on the same row. I can see why it's not done as routing becomes messy, especially with a 1.5-sided through-hole board. Large PCBs get expensive so a simpler matrix might be worth it. I reworked this a few times. Currently using a (flexible) membrane layout where it's not really possible to install diodes (well, apparently FPC can take SMD but a keyboard takes a lot of impacts).

If using the keyboard as a piano, chords in C-major might cause ghosting because the rows are so short. It's somewhat fixable if by alternating odd/even numbers, but there are of course other scales which use the upper black keys.

Shift and space are separate modifier keys outside the matrix. I did the same with Esc & CapsLock because they might have special features... like an interrupts/resets or something. I'm thinking the Shift keys are actually one key, same for Ctrl keys. CapsLock (tempted to call it Shift Lock) could be an actual locking switch joining the Shift trace. It's more tactile and how old keyboards used to work. You can see/feel if it's pressed. Because I ended up moving it down... I guess the special shape and LED will no longer be useful. If put on a locking switch it will need a special neck (interior) that can mate with the switch.

Compact Version (May.2021)

Compact version! It's been some time since I worked on the Alembic keyboard. It was one of my earliest attempts at a custom keyboard layout. It's now approaching mid 2021 and I've learned a little bit from each of my many other layout attempts along the way. I'm typing this in bed on an old ASUS eeePC keyboard, so my elbows are locked, which is not so good for carpal/ulnar tunnel. Anyways, I don't generally touchtype-ish with the hands in place, but now I kinda have to. It works well on the eee because the keys are actually smaller, especially along the Y axis, which means less finger movement, and less stretch.

So, this new keyboard variant takes that idea and pushes it further with layers (thumb shifts flanking the spacebar). It also relies on the Compose key rather than my earlier version with deadkeys and many AltGr layers. For example, to get the currency turtle, you'd compose o and x. Paragraph, o and s. I suppose the fastest way to decode is a big lookup table, but I think it might be better to run a search with the amount of characters in my set. So, after both key presses have been made, swap/sort the presses so certain non-letters go first (or just by code order). Now the table can be smaller, and variable length, probably a start and end offset in a string (for-loop search). So for - first, search:
+:- ().|D
which finally converts to:

The MCU might doing other peripheral work as I have imagined it, like joy shift reg, mouse quadratures, FDD, responding to bus activity/interrupts, but I don't think a pile of IFs will disrupt that with the KB being kinda low priority too probably.

Compose key aside, I did also include a local (Swedish) language deadkey under the compose key. Let's call it the IKEA key. Arrows are on the left and surrounded by modifier keys for word/line/pg stepping and selecting. BS is not that far off because of the overall reduced kb size. It's possible to do CSV number entry and calculator stuff one-handed whilst the right hand is off on the mouse. The keys are of the halfheight membrane (Logitech K120, eeePC size, Amiga colour) type. The key section is 26.6cm wide, which is the same width as Esc-F10 on an Amiga 500. (printable test ver).

Matrix, or not. Using diode networks, or just a chain of shift registers appears to be about the same cost, component-wise. Maybe there are drawbacks I'm unaware of, but a chain of shift registers is simpler (no row pulse). Both solutions would directly produce a 64-bit string of bits (and not a short list of key codes). The leftover (7) bits could go to a DE-9 port, for legacy joystick support. For Reset the MCU could check if only the Esc+A+A bits are set, or rather if the number is a specific number and remains so for say counter=3sec. If so, the MCU yanks on the reset line. On the A500, this is done using logic gates and a 555 timer.

Chip-wise, it would be nice to have new discrete Amiga replacement ICs, but if all consolidated, I'd call the mega chip "Magnus" (though it's not a girl name). Afaik, the 68K is sort of alive in a M68SEC000 incarnation. Honestly, the Amiga hardware was a tad complex to develop efficiently for as a kid... what the Amiga had going for it was the fairly mature development ecosystem with the OS, DP, Trackers, and utilities and various languages.

Prototype (2022)

On this version I moved ?! and narrowed Del. The keys are a bit smaller as I'm just doing the top of the keys, not the side which of course are normally sloped so you can not press there. Unfortunately it seems the fingers can catch on the cardboard edges a bit when switching sideways.

I'm trying to prototype using sheet foam for springs and a paper tinfoil membrane, then thin enamel wire as traces. The keys have little feet which push the row foil strips through the mask and onto the bottom pads. The matrix is read by a 32U4 MCU (e.g. Leonardo) which has native USB.

I only have 1N4007 diodes in any quantity (need upwards 64). It isn't ideal for keyboards but likely alright at the scan freq. we're dealing with. Since I soldered up the diode bundles as common cathode I... may have to do things backwards, as the switches now need to go on the anode side. I intentionally kept the leads long so I can reuse the diodes later. I'm tempted to make an actual PCB and just order it. I don't want to peel and solder 70 tiny enamel wires, which is what i'm looking at now. A naked MCU has more possibilities then the rather crummy Arduino boards too.

At first I had a 15x4 matrix bit realized that I could just do an 8x8 matrix by splitting the 4 common strips. The 32U4 has enough pins for an 8x8 so I can skip shift registers. It would be nice to use Ports B and D directly, but on the Leo board these are cluttered up by the LEDs (maybe this is not the case on the smaller breakout boards). It would be nice to basically handle the 8 pins with single instructions, such as DDRB, PORTB, and PINB. Ports are byte sized, which is really handy for an 8x8 matrix. Using the arduino instructions which deal with individual named pins requires a lot more more setup and awful C for-loop stuff. The 32U4 B port seems to have a port-wide interrupt but I'm not sure if I'll bother with sleep logic.

My common cathode diode setup perhaps requires a solution like this. I tested it on a 328P and it seems to work. I source and current limit though the input pull-ups. Block with outputs.

Perhaps I'd prefer something like this over the typical Arduino layout, with sorted ports, larger mounting holes, 0.1" alignments. The 32U4 has 8+8+6+2+2 = 26 I/O pins, many of which are ADC. But for actual use as a peripheral chip in my A770 it's not a good fit since I don't need USB. I would need more I/O for peripherals unless I use expanders.

K120 Teardown

I bought my Logitech K120 keyboard in a physical store where I could try out a whole bunch of different keyboards. I'm not really a fan of new mechanical (or old spring) keyboards. Chiclet keyboards feel a bit too flat, though I kinda like the one on my ASUS eeePC netbook. The K120 is a budget keyboard but I ended up liking the feel of the half-height keys. There's a rare white model (German layout) which I would prefer over the black. Anyways, eventually keyboards get gunky and have to be cleaned, so I took the opportunity to also peek inside...

So many screws... maybe to prevent creaking. Without any screws there is actually no creaking, but as soon as I put a few back in after reassembling... it started so I guess they're all needed. Some screws go into the central key area so that's something to consider when routing. The case has various supporting shapes helping rigidity. It might be possible to grease the plastic keys to improve the feel.

Inside we get a simple but elegant, and "spillproof" construction. The key plungers go through stalks, but even if the liquid somehow gets up through, it'll end up on the rubber sheet. If it gets through that, it can't easily reach the conductive traces because those are on the inside of the films (capillary action is tricky though). The layers look like this:

   /_   _\     KEY
===||   ||===  TOP CASE
_____/ \_____  RUBBER DOME SHEET

_____________  UPPER PCB FILM

_____   _____  THIN SPACER FILM (note hole on photo)

_____________  LOWER PCB FILM

=============  BOTTOM CASE

I forgot to let it fully dry before reassembling but let's trust the marketing on sprillproofiness. There's a clip-on LED light pipe/guide plastic piece. The PCB is single layer and minimal... This was built to a price. Probably just a blob underneath. The metal bracket likely presses the matrix film onto the PCB. Some extravaganza with the connector and ferrite choke on cable.

It's possible to solder components to a cheap membrane/film "PCB", but key diodes need to go near where there might be some mechanical stress from the keypresses. The floppy PCB film needs a hard backing, which is the plastic case itself in cheap keyboards. A keyboard computer is wedge shaped and won't be able to use the bottom case part as backing so a rigid metal sheet might be needed.

Also, it's possible to manufacture layered PCBs with a flex film as an attached or even embedded layer which can fold over.

And a tip: when washing matt black plastic it often develops an uneven surface finish. I don't know if I'm doing anything wrong, but I disovered that it's fixable with a subtle polish of hand creme ("Atrix soft protection cream"). In fact, I think it sometimes improves the finish over the factory plastic sheen.

Membrane key caps need a way to snap in place over the rubber domes. It's done by plastic locking hooks/tabs, but these increase mould complexity. It might be possible to adapt the widely available cherry keys. The extra part increases assembly labour, but tooling is simpler. Putting the hooks on the keyboard plate would not complicate the mould since there's no overhang. It doesn't even need to be springy hooks since the adapter part is be held inside the collar and the key can be pulled off the adapter.

Deltaco TB-57 teardown

I also have this Deltaco keyboard of similar price and construction, but not of similar quality. I guess the devil is in the details. When I first opened the keyboard, about a hundred rubber domes fell out. It was probably cheaper to not have to make a large mould for a rubber dome sheet, but I bet assembly cost was higher (pick'n place machine, I hope... it was dreadful labour to put them all back in). The general construction had not been able to keep dust out. Several plastic posts inside had broken, either at factory or when I opened it. Tooling seemed a bit sloppy. The way the film attaches to the PCB and top of case crinkles it and some component legs poke at the film dangerously. The PCB looks horrible. When I reassembled several screws would no longer take. The rubber feet are nice but aren't angled with the slope of the keyboard for mysterious reasons so only the edges are touching the table. The keys somehow feel... off with their less tactile flat & square (chiclet-like) top. And they're a bit rattley, perhaps because the key necks lack vertical guides. Guides, like on the K120 can however cause some stuck'ey friction when hitting the very edge of a key.

Misc Bits

Thinking about logic symbols and witchcraft.

The Amiga 500 Kickstart screen is actually a vector image, similar to old Sierra games. I ported over some code I found to BlitzMax and added time-step editing features. Here I'm in the process of enlarging the hatch and label but ran into problems near the thumb. The drawing routine could probably have been made more compact with thick line support.

Fooling around with ideas for a new Kickstart screen. I turned the tick mark into a sort of heart-shaped impossible W.

I guess it might be possible to use PCB films in a joypad. The films could be folded 90 degrees also handling the shoulder buttons (which usually require two separate PCBs and short cables).

Lemmings and Blood Money doodles. Lemmings 3 featured... almost minecraft type slabs instead of pixels. I think some would disappear if walked over. I think machines, moving platforms, enemies could make a Lemmings type game more interesting, but Amiga pixels work better than "HD". I prefer the white face lemming design used ingame.

Random PS5 case, Codename Baleen.

Some other hardware pages

Amiga HDD - Amiga cleanup - Amiga pixels - SBC - Assorted - MSX - Acorn project - Amstrad project, etc. - ZX project - Assorted - Electronics Endeavour

Art by Arne Niklas Jansson