What should we work on next?

We would like to hear from you!
What do you think we and our community should be working on next?
What CPUs would you recommend? What parts and modules should we introduce or improve? Try use this simple poll, and most importantly please reply and let’s discuss in this thread blew, dream free and wild!

  • New CPU
  • More Memory
  • New Screen
  • Upgrade Mainboard
  • New Keyboard or Gamepad
  • New Extension Modules
  • Operating System
  • Application Software
  • Other Hardware
  • Other Software

0 voters

1 Like

I assume this is for DevTerm rather than GameShell?

Keyboard/Gamepad

I think a new keyboard/gamepad module would be great, for me it is actually a really comfortable device to hold to play games but the direction keys are almost unusable, having something much more traditionally shaped with a much shorter travel would be great.
As for the keyboard I do like it but with it being so flat it is hard to differentiate the buttons sometimes and sometimes make accidental presses of neighbouring keys, I think some shaping to the keys could really help.
On the same topic of the keyboard module, I know some people have done modifications to the trackball by replacing it with a different model (such as this one). Alternatively maybe consider a “nub” mouse/pointing stick like on Thinkpads.

Extension Modules

Extension modules would be really neat, I was actually a little surprised to find that the actual “printer” part of the thermal printer is (semi-)permanently attached to the DevTerm which I guess means that any other expansions that might come out would need the printer to be removed entirely to work? I expected there to just be some kind of edge connector in there.
It would be great if it was more generic and allowed you to plug all kinds of things in (shoutout to @fip and this thread about a cartridge module).
Some expansion modules off the top of my head would be things like adapters for 8 and 16 bit console controllers (think SNES, MegaDrive etc. - a bit like this) and a MIDI interface board,

New CPU

A low powered x86 core module is the next obvious addition I can think of (Dreaming: The DevTerm-X86) for an additional core module.
Also I’d love to see a more powerful RISC-V CPU at some point, I’ve recently backed the StarFive VisionFive2 with a processor which wants to compete more directly with the ARM SoCs in the Raspberry Pis.

Operating System

Officially supported non-Debian based Linux distributions would be nice.
Maybe something non-Linux like FreeBSD on the “easier” end of the scale and at the other end RISCOS would be amazing (but I suspect difficult and not very realistic but I want to give a shoutout to it anyway :stuck_out_tongue: (when I can finally get a CM3 or CM4 I want to give it a try but I strongly suspect it will have all kinds of issues with screen size, mouse support and no wifi making it fairly useless - the brief did say “dream free and wild”.)).

New screen

Adding touch sensitivity would be interesting

“Other”

One other small revision I would like to see is to make it a little easier to swap the core module. In particular I like to play around with the R01 but always go back to my A04 for more “normal” stuff. I was thinking that a door on the bottom of the case to access the mainboard would be great.

Sorry, I may have got a bit carried away…

3 Likes

Seconding this, a nub would be perfect.
Also, as a german speaker, it would be really nice to have options regarding the keyboard layout itself.
Maybe a just a handful of alternative keycaps could be a solution.

Meanwhile I’m dreaming of an FPGA board inside the DevTerm. But this is just a solution looking for a problem kind of deal. What to do once we get an FPGA inside it? Co-processing and the likes?

Another cool EXT board could be a connectivity module: dual ethernet where the expansion port is, broadband mobile internally and maybe RS232 on the side where the USB normally sits?

1 Like

Hope to adapt to kali linux first

Currently I only have A06 (bought R01 a while ago but status unknown edit: it shows up today. Magic!) so I speak from one perspective. If I must pick only one thing I’ll vote for Operating System. I don’t mean new OSes like BSDs, HaikuOS or something, but the Linux kernel and stuff around it. This will ensure the best experience for newly landed DevTermers.

Driver issues. This is the intrinsic challenge for arm64 and riscv alike, for they don’t have standard platform infrastructures like UEFI or ACPI.

Most of my own dev/research efforts went into this part:

  • (All variants) Partly resolved the screen 5px cutoff, but don’t know how to proceed without knowing the exact model/datasheet of the panel: A04 screen display vertical offset - #27 by yatli
  • (A06) I have documented along for trying to get suspend to work: Getting suspend to work properly on A06 - #21 by yatli
  • (R01) I’ve played with it for a few hours to get to know the landscape. Less “moving parts” than A06 since there’s no “trusted firmware for ARM” getting in the way. Suspend doesn’t work either, “wakeup cause unknown” but D1 standby should be supported by the driver already. G2D driver is also there. I’m looking forward to HiFi4 DSP driver.

… , but I don’t think it’s enough. Especially not enough information to work with. I’ve familiarized myself with rk3399 technical reference manual, felt almost ready to become a kernel dev on that, but still not enough. Something is missing. Maybe some support from Rockchip directly?

Ecosystem. The supporting libraries in the operating system, that makes a difference between “it works” and “it’s fantastic”

  • (A06) As of now, ffmpeg still runs in SW mode for our distros. In the 4.x era Rockchip had their own interfaces only supported by experimental/personal ffmpeg branches. Things are changing. Someone before us absorbed all the frustration, endured through it and documented the process: The state of mainline hardware decoding
  • (A06) hardware accelerated codec is also a prerequisite for power efficient camera interfacing. MIPI/USB alike, I guess.
  • (A06) I kept following mesamatrix: https://mesamatrix.net/ It seems that full OpenGL ES 3.1 is coming to panfrost.
  • (R01) Team Clockwork, any interest in porting the fbturbo driver? This will give us some 2D acceleration with G2D mixer. I looked into the source a little bit and it seems the ingredient is already there. I tried to remove the neon assembly code for ARM, LibUMP for MaliGPU, and the BackingStoreTuner, and it compiles on R01. I managed to successfully load the fbturbo driver in X11 – non rotated works, rotated black screen, but it does look like a low-hanging fruit that will give us proper performance in rotated screen.
    • (FYI R01 users, currently X11 performance is much better in non-rotated config even without further blit/compose/backing store optimizations!)
4 Likes

A lot of the options in the poll have essential items listed on it but I suppose something like a better firmware and OS is currently underway, if the other thread’s of any indication.

So I vote for a next CPU design. I agree with the reply above in this thread, an x86 is highly achievable and no-brainer; looking at current trend of gaming handhelds in IT space, perhaps something like a low power AMD APU (ie: Athlon Silver 3050U) should be within ClockworkPi’s reach, right? Windows is not required at all in this case though I suspect some devterm users may want it, but having an x86 option would broaden the use case of devterm rather than being limited to ARM Linux only.

1 Like

People who are really serious about software should make their own hardware - Alan Kay

About the RISC-V, the only CPU option that could free us from proprietary drivers and softwares. What do you think the spec and market should be like if we could potentially crowd-fund a RISC-V board that at least matches RaspberryPi 4 performance and cost?

Do you mean a complete RISC-V integrated board like a Raspberry Pi or a Clockwork core module?

If you have a look at the VisionFive 2 campaign on kickstarter that might give you a good idea for what kind of appetite there is for such a board - VisionFive 2 - open source quad-core RISC-V dev board by StarFive Tech — Kickstarter. With two weeks left to go it has got 1,500 backers and almost 4x their original goal.

I think that because it is so much closer in performance to ARM SoCs (possibly around Pi 3) than previous affordable RISC-V boards the market has been much more receptive. There are also far less “experimental” OSs for it now, they plan to support Ubuntu, Debian, Fedora and OpenSUSE.

I really wish we could have faster storage options. The SD card is very often a bottleneck holding back the A06. SSD/NVME module?

Also, I use my devterm with a flashlight every night, since I find the non-backlit keyboard impossible to use in the dark. So there’s one vote for a backlit keyboard, possibly with a nub.

My third vote went to “Operating System” for deep sleep / hibernation support. Because coldbooting and opening up emacs/firefox takes a good while.

2 Likes

Yes. I mean both a compete RISC-V integrated board like a Raspberry Pi 4 and a Clockwork core module. It would be much faster than VisionFive 2, and a lot cheaper if we could satisfy the MOQ.

2 Likes

You certainly would have my vote for it at that price point. The MSRP of the VF2 is around $64USD for the 4GB model and $85USD for the 8GB model which aren’t much more than the equivalent RPi and both are quite a bit cheaper than the A-06 core module (without the rest of the CPi) so I imagine you might well have quite a few people who might want to get on board.

I own Planet’s Cosmo Communicator (and had Gemini before that…), and I have a fresh DevTerm A06 (assembled the day before yesterday), and I am used to the Cosmo, so I might be biased, but so far I long for a Cosmo/Gemini like (alternate, swappable) keyboard for the DevTerm.

Cosmo (and Gemini) is for productivity. I learned to (kind of) touch type on that keyboard quickly, whereas I cannot imagine typing anything above a few lines on the DevTerm (while I wrote quite a lot on my Cosmo). The keys are just too small, although some sort of half-touch-typing (above henpicking speed) might be possible. The keyboard was otherwise a pleasant surprise (contrary to what I had read about DevTerm), it is sturdy and does no wobble.

The size of Cosmo keyboard is almost compatible (at least he lower four rows), but given the non-rectangular shape of the DevTerm keyboard, some creativity with the layout would be required (or a different front cover).

On the other hand, “more standard” layout means programming (or at least editing small shell scripts) would be easier on existing DevTerm (Cosmo has way too many important characters hidden under the Fn key).

Otherwise, a tiltable display (by a few degrees, e.g. like Olivetti M-10) would be nice as well, but I understand adding moving parts is bad for reliability.

Wait a bit longer, there will be some fully or nearly fully open source soon-ish on the driver level. I expect something around early 2023.

Personally I think you should finish the R01 before you go on to something “new”. Seems to be the way of things these days. Create something new. Get it so it sort of works. Call it done and move on to the next “new”. That’s a hideous practice.

I’m new to DevTerm and the R01 in particular but there are a few glaring problems that need to be fixed in the existing software for it:

  1. no cursor in the console?!?! In short the fb driver needs to be fixed.

  2. Although the D1 doesn’t offer 3D hardware acceleration it does offer video decoding and 2d accelerations. At the bare minimum the 2d acceleration should be implemented so that the video responds decently. Lets eliminate the inch worming!

  3. Better printer support. Changing fonts (bitmap style, specifically sizes) should be easy and published for using the bare printer driver (/tmp/DEVTERM_PRINTER_IN), without the need for CUPS. Using the printer driver without CUPS produces microscopic print. With CUPS produces huge print only allowing a word or two per line. Huh?!?! In this role CUPS is more of a detriment than an aid and its HUGE. So many uses are soooo much simpler by just pumping data at DEVTERM_PRINTER_IN. That was a great feature! I’ll get into your source one of these days and enlarge the font to a reasonable size. Anyhow there are at least two things that need fixing there.

  4. It was mentioned:

    I personally prefer the track ball of all the mobile pointing devices I’ve used. The problem with the trackball on the DevTerm is its spastic. Sometimes you have to spin it 500 times to move a mm. Other times the barest twitch and you’re across the screen. Yes I’ve tried it with and without X acceleration. I prefer it without. But it seems like this should be fixable and it should work smoothly and consistently. Maybe just a firmware fix?

  5. GPM needs to be fixed to work with the DevTerm R01. I haven’t had the time to get to the bottom of this. But I shouldn’t have to. That’s part of the hardware support. It works in X. This is a “Dev” “Term”. It should work in the “term”-inal. All other systems I’ve used it on… it just works.

  6. Full, complete, all patched kernel sources should be readily available. Since your aimed at makers this should be as important as providing an OS image. I’ve not had the time to get to this either…

Sorry, I started out with two things on my mind but then all of the issues started coming to me. You need someone doing some QA to say when something is “done”.

On the *NEW* front:

You know? Back in the mid '80s IBM acknowledged that people were tired of typing their date and time in at EVERY boot. So when they released the AT they added a battery-backed RTC (aka Dallas chip). It also stored MoBo settings and eliminated the need for dip-switches. Well… I keep saying technology is going backwards and here’s a perfect example: I’m back to having to manually inform a computer of the time again!!!

Yes, I know it can get the time from the Internet… So what if the Internet isn’t handy? This is a portable device WiFI will not always be available. Nor should I need it to be. Plus there is the issue of all the date/time stamps being wrong on files manipulated between the time you turn the machine on and it finally gets given the Internet. I really don’t want to add the old “date”, “time” prompt back to my system boot. Besides SystemD would make this a hemorrhoid. That hideous thing needs to die!

So I’d vote for an RTC on the MoBo. This should be standard equipment on ALL computers and SBCs. It can be powered from the rechargeable batteries.

The SUPER-OBVIOUS missing piece is some way to gain access to the pair of GPIO facilities in the DevTerm. I’ve looked! I can’t buy a role of FFC slice off a piece, strip out the needed number of conductors and connect it to my RTC or temperature sensor, or, or … Outside of manufacturing these are unobtanium. So a compact break out board/mechanism would be good. Probably get a bunch of repeat sales, since makers can easily and inexpensively gain access to the things that created the RaspberryPi crowd in the first place.

Of course while your at it you might also come out with a proto-board that plugs in the ext board port. So makers can cobble together their own specific accessories.

I’m all for a quality RISC-V build! Its obvious that Allwinner put the barest effort into the D1. An 8bit RAM bus for a 64bit processor?!?! The ARM64 gets at least 16! Still the PC industry went to a 64bit bus while the CPUs were still limited to 32! More RAM throughput is huge! When you have the replacement module for my DevTerm let me know. I’ll hang the R01 in the museum.

On the OS front: Devuan! Its Debian / Ubuntu without the hang ups and bleeding.

I like what you have so far … but it needs to be finished.

4 Likes

If I could have anyone thing as an add-on to my A06 a module with EMMC storage and a utility to move the OS to it would be that.

I am running the CM3, but the only reason I like it is the lower power consumption. It would also be nice to get the sleep modes to function properly so you didn’t need to shut down and power up.

Supporting an M.2 device would also be great, I would much rather have that than the printer. But then I don’t print much off my main machines anyway.

Was thinking about putting an ortho keyboard in as you could have slightly bigger keys. Still thinking about that.

It is a terrific platform.

I would kill for a DevTerm that was actually in the larger TRS-80 Model 100 form factor, so we could get a full sized keyboard for it. That would be the ultimate hacker terminal!

1 Like

Here! Here! I second that motion. Just never got around to typing it here. :smiley: I was actually kind of disappointed when I read the specs on the site and saw its about half size of the 100! :scream:

Totally! Even if they unfortunately don’t make a DevTerm XL, maybe someone can 3D print a compatible case so we can mod one up ourselves.

And I would add that some extra “air” in the case would provide space for hackers, like me, to build more goodies inside the case. This is good because then they too are protected from damage or loss by being enclosed inside the unit.