28-08-2025, 11:01 AM
Unfortunately there has not been much time available of late to work on the new models,
however, some work has been done where I can squeeze it in.
The work of late has been to do with the keyboard.
Although I've had the keyboards for both models working for a while now, there were some things that needed
attending to.
Firstly, the keyboard driver needs to test which keyboard layout is in use on the machine - the 64 key original (premium)
layout, or the new 98 key layout. ( I've done this so that the firmware & system software can be the same for both models. )
Then it needs to adjust the key mapping to suit. While I had the keyboard layout detection working already, I hadn't
implemented the 64 key layout mapping as yet, so the keyboard was working o.k. for the standard QWERTY keys, but the
symbol keys ()@^& etc. and the arrow keys were not working, or in the wrong place. That is now done, so the 64 key layout
works fully. There are still a few keys on the 98 key layout that need handling properly while NumLock is on (arrow keys have
different scan codes while in different NumLock states for example).
The more important thing with the keyboard though was the interrupt priority needed changing for the keyboard (and mouse)
as previously the floppy disk emulation (and systems calls from Z80 -> M68K) had a higher priority. This meant that
during emulation task processing it was possible to miss / not recognize key presses. This meant changes in the FPGA logic and the
M68K firmware.
Now the keyboard (and mouse interface when that is implemented) have the highest priority interrupt. I've implemented
a full 64 byte scancode buffer and also had to implement an interrupt driven 6545 keyboard matrix driver so that it is fully
backwards compatible with how the original microbee keyboard interface was implemented.
The aim with the keyboard hardware / firmware when complete is to be fully backwards compatible with the original microbee
keyboard and the 256TC's keyboard so that no matter what boot disk (or disk image) you use (64k/128k/256TC), the keyboard
will still work.
Still to finish off on the keyboard driver:
* debug the CapsLock / Numlock handling
* add in handling for the arrow keys alternate scan codes (while NumLock=ON)
* provide 256TC keyboard interface compatibility
While this development work is still going on I am busy sourcing parts and building up stock ready for release.
Sadly though, and I am normally very careful when dealing with overseas suppliers for the first time, I was caught out.
While the loss is not overly significant, is was still around $530 USD that I handed over and have never seen the components
shipped. Looking online at TrustPilot, I see I'm one of many that have placed orders with component-store.com and never seen
components shipped. Communication was perfect until I'd sent the money & then crickets & tumbleweeds. Lesson learned.
I mention it here so that others don't fall into the trap.
Anyway, Onwards & Upwards.
however, some work has been done where I can squeeze it in.
The work of late has been to do with the keyboard.
Although I've had the keyboards for both models working for a while now, there were some things that needed
attending to.
Firstly, the keyboard driver needs to test which keyboard layout is in use on the machine - the 64 key original (premium)
layout, or the new 98 key layout. ( I've done this so that the firmware & system software can be the same for both models. )
Then it needs to adjust the key mapping to suit. While I had the keyboard layout detection working already, I hadn't
implemented the 64 key layout mapping as yet, so the keyboard was working o.k. for the standard QWERTY keys, but the
symbol keys ()@^& etc. and the arrow keys were not working, or in the wrong place. That is now done, so the 64 key layout
works fully. There are still a few keys on the 98 key layout that need handling properly while NumLock is on (arrow keys have
different scan codes while in different NumLock states for example).
The more important thing with the keyboard though was the interrupt priority needed changing for the keyboard (and mouse)
as previously the floppy disk emulation (and systems calls from Z80 -> M68K) had a higher priority. This meant that
during emulation task processing it was possible to miss / not recognize key presses. This meant changes in the FPGA logic and the
M68K firmware.
Now the keyboard (and mouse interface when that is implemented) have the highest priority interrupt. I've implemented
a full 64 byte scancode buffer and also had to implement an interrupt driven 6545 keyboard matrix driver so that it is fully
backwards compatible with how the original microbee keyboard interface was implemented.
The aim with the keyboard hardware / firmware when complete is to be fully backwards compatible with the original microbee
keyboard and the 256TC's keyboard so that no matter what boot disk (or disk image) you use (64k/128k/256TC), the keyboard
will still work.
Still to finish off on the keyboard driver:
* debug the CapsLock / Numlock handling
* add in handling for the arrow keys alternate scan codes (while NumLock=ON)
* provide 256TC keyboard interface compatibility
While this development work is still going on I am busy sourcing parts and building up stock ready for release.
Sadly though, and I am normally very careful when dealing with overseas suppliers for the first time, I was caught out.
While the loss is not overly significant, is was still around $530 USD that I handed over and have never seen the components
shipped. Looking online at TrustPilot, I see I'm one of many that have placed orders with component-store.com and never seen
components shipped. Communication was perfect until I'd sent the money & then crickets & tumbleweeds. Lesson learned.
I mention it here so that others don't fall into the trap.
Anyway, Onwards & Upwards.