Along these lines, I have fond memories of the Amstrad NC200 I used in school. Say what you like about Amstrad, but their dedicated-purpose word-processor-class computers were exceptionally well-designed.
The display was a 480x256 letterbox of a monochrome passive-matrix LCD, but it was not only instant-on and instant-load, but would instantly switch between any of the built-in applications using a two-key shortcut. And the batteries would literally last weeks as long as you kept the backlight off and didn't use the floppy drive. Just try finding a modern laptop that can match that.
I also have distinct memories of the family RiscPC feeling distinctly "hard" in its response to command-prompt input. In that mode, the OS looked a great deal like a 30MHz, 32-bit, RISC version of a BBC Micro - and not just on the surface, either. The fact that the graphics hardware supported hardware scrolling (just set the addresses of scanout start, wraparound trigger and wraparound target in the appropriate registers) undoubtedly helped. You can run RiscOS on a Raspberry Pi too, but that uses software scrolling, so you don't quite get the same effect despite the further increased theoretical performance.
I'm pretty sure the VC4 can be made to do hardware scrolling, BTW. Even if it doesn't support wraparound in the same way as old RAMDACs did, you can give it two overlays to display either side of the wrap point. But I don't think the current version of RiscOS bothers to do that.
As for keyboard hardware latency - it's actually quite straightforward to achieve *microsecond* matrix scan delays for single keypresses, and you could probably do that with straightforward modifications to most of the PC keyboard hardware out there today. The process is:
- 1: Set the row and column drivers to impedance pull-down with input sensing. Wait for all the row and column inputs to register as low.
- 2: Set the row drivers to hard pull-up. Wait for at least one column input to register as high, signifying key has been pressed. (Note: no active scanning required while quiescent - potentially very low power consumption here.)
- 3: Set the row and column drivers to impedance pull-up with input sensing. Wait for the row inputs (only) to register all high.
- 4: For each column that was registered high, set its driver (alone) to hard pull-down, and wait one microsecond for at least one row input to go low, indicating unambiguously a pressed key. Register these keys in the debounce table. When the microsecond timer expires, go back to step 3 *if* there are more active columns to scan.
- 5: Set the row and column drivers to impedance pull-down. Process the debounce table and notify the host of any relevant key-down events.
- 6: If any keys were apparently released, set an interrupt timer to the debounce delay. If that timer fires and the key is still released, notify the host of key-up event at that time. (Key-up is less perceptually relevant for latency than key-down.)
- 7: Go back to Step 1.
Login
Register
FAQ
Search
