Continuing my exploration of reimplementing LÖVE upon a risc32cfimv with memory-mapped I/O... How'd I reimplement its love.keyboard module?
I'd register some Assembly code to for the keyboard to interrupt with PS/2 scancodes (or F0 to indicate that the next scancode was released) read into an I/O shift register & validated over a SPI protocol. Which would precede to copy that into a ringbuffer which our LÖVE runtime can convert into events, possibly whilst filtering out key repeats.
1/3?
Even if it takes more skill to get the most out of it!
Later on in that decade we added splashes of colour using hardware that avoid requiring anything more from the CPU.
Yes, the differences are quite stark!
1024x768x1bpp = 96kib VRAM / bandwidth per full screen refresh
For the same amount of VRAM with coor:
@ 2bpp (4 color/grey) = 724x523
@ 3bpp (8 color/grey) = 591x443
@ 4bpp (16 color/grey) = 512x384
@ 8bpp (256 color/grey) = 362x272
@ 16bpp (64k color) = 256x192
@ 24bpp (16.7M color) = 209x157
It's pretty merciless. ;)
I miss monochrome, particularly the clean, hi-rez stuff like OpenLook.
In doing that conversion I'd convert the scancodes into LÖVE-compatible strings via a lookuptable, with another to convert it on into "keys". I'd store this 2nd table in a 3rd "text" cartridge position near the PS/2 port to allow configuring it.
A couple functions would be exposed (don't know why they don't take into account the shift key) to convert between highlevel "scancodes" & "keys".
There'd be accessors for whether we're filtering out the repeats from the keyboard's input.
2/3?
In doing that conversion I'd also update a bitmask of all pressed scancodes, so apps/games can check whether a key or scancode is pressed. Maybe I'd also switch between key-mappings (for the sake of shift & capslock)? Whilst writing the new state to an I/O register to be displayed by LEDs in the keyboard.
If configured (by another couple accessors) I'd meanwhile hand these scancodes to sandboxed-Lua code in the text cartridge to turn into "textinput" & "textedited" events.
3/4!
The whole point of that "text-cartridge" btw is to allow for extensive localisation & accessibility options without eating up this hypothetical machine's entire 4GiB of memory!
I'd also include a hook for the text-cartridge to render an onscreen keyboard above your app/game to produce these "keypressed", "keyreleased", "text input", & "textedited" events. If this hook's present love.keyboard.hasScreenKeyboard() would return true.
4/4 Fin for today!
A space for Bonfire maintainers and contributors to communicate
