deskthority

I do not use any clipboard monitoring app now and I do not care about it personally. I had something in a far past on windows. It implemented something like clipboard with history and a preview.

Hey, I remember those!

iljitsch wrote: 21 Dec 2020, 22:32 What I would love is a good way for keyboards to send Unicode directly to the computers they connect to rather than just keycodes....

The X Window System (X11) sends key events to applications both a keycode (to identify which physical key was pressed) and a translation, i.e. if the context within the application works with characters, what character should be used. Keyboards could have been made to do the same, i.e. so the translation comes from the keyboard, not the OS.

Another missed opportunity - some keyboards send an ID - I believe the 122 Terminal keyboards do and some of the keyboards used on Unix workstations. PC keyboards never have. As an alternative to the keyboard sending characters (in Unicode now) keyboards could, from the start, have send a code at initialisation that tells the BIOS/OS what layout that keyboard has to save people having to set it up separately within the OS.

I'd love this!

dcopellino wrote: 22 Dec 2020, 16:36

matt3o wrote: 22 Dec 2020, 08:44 Here

shot_1608622786.jpg

The keyboard is just a USB HID, remove it and build your own enclosure with cherrymx or whatever and a screen if you want. Added bonus GPIO..

Yours is a brilliant suggestion. At the same time, It would be nice to insert the raspberry pi 400 into a mechanical keeb of our choice, maybe our most liked one, without being forced to build a new one starting from the scratch. The dimensions of the raspberry pi 400 PCB should be 286mm × 122mm × 23mm. (Ask Chryros for an imperial conversion, LOL) I have already tried to get the measurements of the void space inside an IBM m122 type II, but despite my most optimistic expectations, it seems not to fit. Should I turn my gaze toward chubbier beamsprings?

Some bizarre develops below according to author's post about real keyboards. Forgive them whom don't know what real keyboards are click here

Thanks, I hate it

Saw this on reddit a couple days ago, it maybe relevant https://www.kickstarter.com/projects/jl ... mputer-kit

Something related ... but in the reverse: Sneakbox GIGA40.
The cartridge has the controller, intention being that there will be a line of computers of different sizes all with the same slot for a controller cartridge. This small 40% keyboard, though, uses some of the unused matrix lines for a 9-pin port for Atari-compatible joysticks. The joystick directions and button are part of the matrix.

The 8-bit Guy on Youtube has a project designing his "dream 8-bit computer", the "Commander X16":Part 1. Part 2.
It has come a long way, and uses some 8-bit components that are still available such as a 6502 CPU, but they are using an FPGA for video. (See this recent video here by another contributor for a rundown).

I have always thought that a much more efficient (but cheating) way would be the other way around: use a FPGA chip with attached ARM microcontroller. Do the CPU and some hardware signals in FPGA, but emulate a lot of the I/O, video and sound chip capabilities in software on the microcontroller.
Then you could use software to map input from USB mouse, gamepads and keyboard into registers in your I/O chip on the FPGA. Alternatively, use emulation for everything.

Recently, the Raspberry Pi Pico microcontroller board was released. It costs ~€4 and with Raspberry Pi Foundation's own microcontroller: The RP2040 has two ARM Cortex M0+ cores at up to 133 MHz, two fast programmable I/O ("PIO") modules and a USB-OTG module (capable of being host or device).
The PIO modules together are capable of producing a video signal, and there is an upcoming board for it with VGA, but I think people have prototyped DVI.
For a virtual 8/16-bit computer, one core could emulate the CPU in step with shuffling video and modulating audio, all in a tight loop. The other core could run non-timing critical things: control, the USB host stack all virtual I/O ... and ... maybe scanning a keyboard matrix.

I think it would be possible to emulate an existing 8-bit computer on the RP2040, but a novel CPU and I/O design might be more fitting for software emulation, be more capable, and be less tricky to accomplish.
To emulate a C64 specifically one would have to emulate also non-intended op codes and cycle-per-cycle timing with the VIC-II chip ... which can be very involved, but for which there is source for.

Edit: Holy Cr*p ... Someone has already written a BBC Micro emulator for the chip.
I also found a 6502 CPU emulator in ARM Thumb2 assembler, made to run on STM32F4 (Cortex-M4, not Cortex-M0+) that might be what has been used here. The speed is around 1/10 per MHz, i.e. an emulated 6502 would run at ~13 MHz on a 133 MHz ARM Cortex.

hi all,
thanks for the replies, however, the ready model 100, commander x16, emulating c64s, raspberry pi pico, and the sneakbox are all really very unrelated to the topic of this thread other than the connections which are "vaguely modular computer" or "retro related computer" which are not the subject of this thread. thanks!

Actually I quite enjoyed the post

I do not think Commander X16 makes sense though. MCUs are cheaper and better for a new stuff. Emulators are cheaper and better for the old Commodore stuff.

But the Commander X16 project is cute and funny. Not really useful though.

Yeah, I mentioned the Commander X16 mostly for context. I don't think it makes sense to put an actual 8-bit computer into a keyboard, but we could emulate one.
Emulating an 8-bit CPU and hardware would be fun and have a certain coolness factor, but maybe the most feasible option would be a BASIC interpreter running native on the MCU — providing a user experience similar to having BASIC on a 8-bit computer.

The Raspberry Pi Pico is as cheap as a Pro Micro clone -— which is very popular for DIY keyboards, but has more I/O pins and other capabilities, and is likely going to be generally available pretty much everywhere.
Therefore, you can bet that it will be used for DIY keyboards by a whole bunch of people in the community. There is USB HID stuff in the official repos and I'm sure that someone is working on porting QMK to the board/chip right now.
The enabling tech in it that makes it relevant to this thread is the second CPU core: it could be dedicated exclusively to the "8-bit computer". I'm sorry if I was unclear about that.

Findecanor wrote: 28 Jan 2021, 13:53 maybe the most feasible option would be a BASIC interpreter running native on the MCU — providing a user experience similar to having BASIC on a 8-bit computer.

yeah, that's pretty much what i'm aiming for right now.

The Raspberry Pi Pico is as cheap as a Pro Micro clone -— which is very popular for DIY keyboards, but has more I/O pins and other capabilities, and is likely going to be generally available pretty much everywhere.
Therefore, you can bet that it will be used for DIY keyboards by a whole bunch of people in the community. There is USB HID stuff in the official repos and I'm sure that someone is working on porting QMK to the board/chip right now.
The enabling tech in it that makes it relevant to this thread is the second CPU core: it could be dedicated exclusively to the "8-bit computer". I'm sorry if I was unclear about that.

i'm not even bothered with the hardware side so far. trying to figure out the feature set and general structure of the system seems to be more of a thing.

it seems to me like you want this sort of system broken up into a few parts:

1. very low power chip like an msp430, and all that does is scanning the matrix and outputting that via usb. and possibly a low latency wireless peripheral that it wakes up out of sleep.

2. a higher level chip that will run all the macros or interpreters, the UI, and do various protocol translations, as well as a possible vga or hdmi output. this can be located in some sort of "base station" somewhere if you want to have a wireless keyboard that lasts long on battery, or if you want a wired keyboard that doesn't have a million cables running out of it. a copy of this base station could be included in the keyboard as well, for portability.

3. a more beefy computer that can run compilation for whatever you're doing in basic / whatever other language



i'm also thinking about the language stack you might want to have on this thing. i'd like to have a stack of forth, basic, something J or APL-like, and something that's like Hypercard. it would be nice to have bidirectional compiling between them (i.e. basic -> forth -> basic without losing information). and it would be nice to be able to break out of one into the other, so eg if you're in APL/J, you can go to basic mode, or forth mode, do some stuff, and then go back to APL where you left off.

i'd also like to integrate some sort of simple sound ability. maybe a yamaha fm chip followed by a simple filter. this just carries on the "integrated piezo beeper" idea many keyboards do. and i'd like to add music related functions to the programming languages, so eg you can easily define a voice assignment logic system, or a small sequencer. if you've worked with stuff like keyboard macros, the two things are actually very similar in scope, just that for music you need to be able to define timings and understand note lengths or types and know the tempo. which reminds me the charset should likely include some form of useful musical notation, but probably not common sheet notation, since that's confusing as fuck and a bad idea for anyone but people who have been forced to learn it as a child.


anyways as a test of how basic performs as a macro keyboard i've decided to get a C64 and try and make an expansion cartridge which 1. takes usb keyboard input 2. lets the C64 run hooked programs based on what keys you're pressing 3. outputs usb via the cartridge again to the subsequent computer. might do this using something like a raspberry pi 4. but i have to read up on programming the c64, since i've never done anything like this.

Someone made something related, the "VT-69 Nice Edition": http://violence.works/