Right now I'm using a battle-scarred Acer Chromebook R13 as my main driver. I bought it on a whim because my stuff tends to regularly blow up and my Debian laptop tried my patience one too many times. It proved to be both resilient and surprisingly versatile, especially since crostini and its Debian containers became available on it. It punches way above its weight for a fanless, quad-core ARM64, 13-inch laptop with 12 hours of battery.

My normal computer is a Ryzen 1800X with 32 GiB of RAM, 512 GB of SSD and a 1440p display, used as a beefy programming workstation. Like its owner, it's very effective at its job yet tends to crash every so often. I haven't booted it up in weeks because my Chromebook gets the job done and can sit on my lap.

I also have a bunch of other computers, but nothing really noteworthy nor recently used.

Not really my computers, but I do co-maintain a 5-rack datacenter at my job among other things. Our latest acquisition is a Dell PowerEdge R7425 with 64 cores, 192 GiB of RAM and 3x 2 TiB SSDs, soon to be used as a build machine. It's ludicrously powerful, especially since I've banned VMs on it and decreed only Docker containers shall be used. Being able to automatically invoke pristine Jenkins worker containers on-demand on it is just icing on the cake.

I'm aware of two native games on the NumWorks: my own Tic-Tac-Toe app (https://github.com/boricj/numworks-tic-tac-toe) that's actually an m,n,k-game with IA and zardam's NES emulator (https://zardam.github.io/post/nofrendo/).

There are only a couple of third-party apps on NumWorks. There are a couple of reasons for that:

• No flash filesystem, so currently one has to flash a whole new firmware to put things in flash.
• No syscalls/ABIs, so while there's good source code modularity at the end you end up with a monolithic firmware to flash.
• Since you ship firmwares, you're tied with epsilon's source code and it's a quickly moving target ; third-party apps tend to bitrot with each new version.
• Since you ship firmwares, end-users must flash them to use third-party apps, which limits their audience.

Basically it's a pain in the butt to maintain and making third-party apps available to non-technical end-users requires a lot of effort. zardam's NES emulator has a fairly nice dedicated flashing webapp (https://zardam.github.io/webnofrendo/), but it's nevertheless a kludge that doesn't scale.

That being said, the NumWorks platform itself is extremely programmer-friendly due to source code availability and unlocked hardware, but the original firmware is a bit too good at its math job. I'm actually thinking about writing my own firmware/shell with drastically different design choices to solve this issue, where adding native apps would be as easy as copying an ELF program with a file manager...

Quote from: gameblabla on March 14, 2019, 11:25:07 AM
When we will get native dev on it ? D:

Given that the datasheets and firmware source code are freely available, I'd say from day one. I mean, you can even program video games for the NumWorks in Ada for crying out loud! (https://tiplanet.org/forum/viewtopic.php?t=21794&p=234603)

I've unearthed one of my old pull requests and now we can (finally!) have proper Python games on the NumWorks calculator. The missing bits were keypad readout and some basic graphics primitives (zardam's time module was already merged some time ago). I've scrambled together a Pong game to showcase this:



Drawing performance is honestly quite terrible because the framebuffer isn't memory-mapped, but it's enough for a smooth Pong and probably other basic games in real time. Redrawing the full screen on each frame would require drawing the entire screen in one go pixel after pixel (like the third-party firmware GESTE did), not unlike racing the beam on the Atari 2600, but doing that from within MicroPython would be challenging.

Sources:

• https://tiplanet.org/forum/viewtopic.php?t=22284&p=239419#p239388 (News on TI-Planet)
• https://tiplanet.org/forum/viewtopic.php?t=22286&p=239396#p239396 (Initial post on TI-Planet)
• https://github.com/numworks/epsilon/pull/746 (pull request for NumWorks)
• https://workshop.numworks.com/python/jblbeurope/pong (Pong source code)

Quote from: xlibman on January 24, 2019, 08:35:50 PM
I am definitively curious about what a movie looks like when watched on this <.<

Probably not a whole lot better than 8088 Corruption:

You can model your game as a (set of) finite state machine(s), where each state (vertex) has a number of valid transitions (directed graph) to progress the story depending on both the game's state and the player's input. Most adventure games have at least one FSM modelling the current player's location, but you can have more than one to handle things like puzzles, timers, NPCs and so on, depending on how complex your game will be.

Understanding the player's input is historically one of the hardest things to get right. There's no miracle solution, but generally you'll have to identify at least the verb (= action) and optionally one or more objects to act on. Tokenize the input and try to make sense of it. I recommend handling a fair amount of synonyms too, unless you want to frustrate users.

You can study some classic adventure games like battlestar (https://github.com/NetBSD/src/tree/trunk/games/battlestar), though code quality has come a long way since the early 80s. I'd also recommend studying adventure (https://github.com/NetBSD/src/blob/trunk/games/adventure) as an example on how NOT to write an adventure game.

Android applications do not require Linux to work.* They do however require an Android runtime.

* unless they do, but that's another story.

BlackBerry 10 devices (which are based on the QNX microkernel) can run Android applications and I do not think they are running a full-blown Android operating system with its Linux kernel inside a VM on their phones to do that. Another, less pertinent example here would be the original ARC for Chromebooks, even if it turned out to be a technological dead-end. Alternative Android implementations do appear to exist too (Dalvik Turbo) but I do not know anything about them and especially if they require Linux.

I'm not suggesting this is something easy to do (far from it), but it's been done before and Google has the resources to make it happen once Fuchsia is ready for it.

Quote from: gameblabla on December 06, 2018, 06:11:56 PMAh, interesting. I've heard a lot of talk about the GS processor on the PS2 but not a hell lot about the CPU. I guess most people assumed it was just a boring old MIPS cpu. I mean in theory it should be possible to tell GCC to target some of the CPU's features right ? (or even create a new target but i think you guys went with the safe route C:)

The toolchain situation for the Emotion Engine is a tad complicated. Back in the day, Sony released the sources of a patched GCC version alongside their Linux port, but it did not end up being merged upstream for reasons I do not know. You can treat it as a MIPS-III from the userland's point of view and get away with it (which NetBSD users did for a while), but that won't work for the kernel. Someone did add basic support for the EE to GCC without the proprietary insane bits shortly before I started to work on the resurrection, which was enough for me to reach the point where the kernel panicked because it did not found a root disk to mount, with almost no hexadecimal-coded instructions in the assembly source files.

Anyway, all of this is moot now as any interest in this port resurrection promptly died when Imagination Technologies announced the CI20. Which really was for the best, because the PlayStation 2's architecture is a bad fit for general-purpose computing and the MIPS world really needed an official Raspberry Pi-like equivalent.

Quote from: gameblabla on December 06, 2018, 06:11:56 PM

QuoteHopefully the G2 will not be such a pain in the ass to work with

Isn't  the G2 going to be more locked down though ? It's a shame that neither the Linux or NetBSD ports went anywhere.But touchscreen isn't that important on a calculator one could argue.

It gained the ability to enforce a lockdown with a signed bootcode at the SoC level and the official HP firmware appears to enforce an effective chain of trust. However, from what scant tips I've gathered, the bootcode should be unlocked and we should be able to run homebrew firmwares (patching the original firmware will be far harder and we should definitively not risk invoking the wrath of HP). I intend to explore the G2 once mine gets delivered during this Christmas.

The touchscreen itself is not needed for a Linux port, but there's only one USB port available. Having the ability to have a mouse/touchscreen without requiring an USB mouse (and possibly an USB hub to plug in more things) has its upsides.

That reminds me, some time ago I've managed to come up with a theoretical way to effectively lock-down the NumWorks calculator with a simple software update, at the cost of fusing off the debugging interface. The "nice" thing about it is that I also found a theoretical way to allow unofficial firmwares to still run unhindered yet still prevent them from compromising the root of trust and from operating the LEDs. So if it ever comes to that, there will be a glimmer of hope besides desoldering the SoC and soldering an unlocked one.

Quote from: gameblabla on December 06, 2018, 06:11:56 PMI saw some articles about Fushia but it's as early stages as Haiku OS it seems. At least they got rid of Java it seems.I don't really care for the microkernel design but as long as it is POSIX compliant and performs decently, it's all good.But then again, it might end up like Tizen and stay on smartwatches and all. (which kind of died because the license was not truly open source among other things)

Fuchsia is not POSIX compliant (but does offer a limited level of POSIX compatibility) and frankly I think the POSIX API has accumulated a lot of rust over the decades when directly used as the native kernel ABI of an operating system. However, crostini's approach to bring Linux containers to Chrome OS (which I am impatiently waiting for it to leave the dev channel for my Acer R13) decouples the host kernel from the Linux kernel running containers inside a VM, so Chrome OS switching from Linux to Fuchsia in the future would be completely transparent to the end-user (as long as they migrate Android support to crostini too).

On the other hand, I am not sure what will be the consequences of switching Android from Linux to Fuchsia will be in practice, beyond that upgrades at the lowest layers of the OS stack should be much easier to perform. I am however tepidly sure that Fuchsia won't disappear overnight (if anything, it should make for a wicked embedded OS).

That reminds me of all the smut various stuff that single men draw when bored I've drawn over the years while in class and at pubs. If Tumblr was a religion, I'm pretty sure I would've been framed as a heretic by now.

Now that I think about it, I'm pretty sure everyone I've met so far thinks I'm a heretic anyway. The trick is to get away with it

PlayStation 2

My take on this is somewhat atypical because I once tried to port back NetBSD to it, so I did not care about all the insane Sony proprietary bits. Turns out the CPU is one of the most insane things about it : from what I can recall, it's a MIPS-III with most MIPS-IV instructions, a couple of MIPS-V instructions, 128 bits registers, 64 bits virtual addresses like MIPS64, 32 bits physical addresses like MIPS32, FPU units almost but not quite IEEE 754-compliant and a 64 byte cache line.

WHY?!

It's technically a MIPS CPU, but that's the weirdest MIPS ever made by far. It's like they've decided to make a hybrid of five different MIPS ISA because they could and piled on more insanity on top of it...

I haven't even talked about things a general-purpose UNIX-like OS does not care about, but the heterogeneous computing with the PS1 CPU bolted-on (or the PowerPC core on later models) on the bus would've yielded even more insanity to exploit.

HP Prime G1

It's not hard because of the hardware (it's fairly standard), but the firmware' OS is quite odd from what I've heard (early versions actually relied on the RAM mirroring to boot, which screams sloppy programming to me), the flashing protocol is proprietary and the utilities are Windows-only, the calculator will be bricked if the beginning of the NAND gets corrupted or overwritten and the touch chip is proprietary. That makes for a very, very frustrating platform to work on for homebrews.

Hopefully the G2 will not be such a pain in the ass to work with.

Good examples

The NumWorks calculator: extremely standard and boring hardware/flashing protocol/debugging interfaces, thoroughly documented, the source code of the firmware is available. The only real downsides are the limited amount of RAM/Flash on an unmodified model, the frame-buffer not being memory-mapped and the inability to act as a USB host, but man it is easy to work with.

Quote from: Juju on November 22, 2018, 05:00:51 AM
I heard Google is working on a new OS to replace Android because its design is just getting plain outdated and is a pain to support the new features that came out since, say, Android 2. Looking forward to it, just to see how better it'll be or if it's gonna replace Android at all.

That's Google Fuchsia. They'll probably use it in an embedded product like Google Home or Google WiFi first, but one of the main development platform is the Google Pixelbook and they do have a nice looking, hardware-accelerated UI on it based on Flutter. I'm getting familiar with the microkernel Zircon (previously Magenta), which is the best designed micro-kernel I've seen in a long time (I've done my share of hacking and pull requests on MINIX3). So much that I'm itching to do things with it, if only I could scrape together enough free time for such an endeavor...

By the way, some guys at the NSA are interested by it at the cyber-security level. They've done an informal audit of the system to evaluate how things are going even though it's still deep into development and even made a presentation on their findings (https://youtu.be/Jov4dTnjm2o?list=PLbzoR-pLrL6rOT6m50HdJFYUHyvA9lurI&t=1430).

I'm baaack ('cause social network login was broken here for a while).

I'm working on an integrated turtle Python module for the NumWorks calculator (https://github.com/numworks/epsilon/pull/748). It's coming along rather nicely:

from turtle import *
for i in range(255):
  gray=255-i
  color(gray,int(gray*0.75),int(gray*0.25))
  forward(i*0.1)
  left(10)



I've also done a RPN app for those who are addicted to HP calculators (https://github.com/boricj/numworks-rpn). The basics are here (16-level stack with nearly all operators on the kerboard implemented), but there's a lot of room for improvements. Turns out there are enough people interested that I get pull requests on this project from time to time. The discussion thread for this project, for lack of a better place, is at https://github.com/numworks/epsilon/issues/35#issuecomment-417885356.

Just because I have an unlimited supply of insanity doesn't mean I have an unlimited supply of free time

Besides, only the non-color TI-Nspire models could possibly fit inside an emulator running on the HP Prime. Who would want to turn their HP Prime into a severely underpowered, monochrome calculator with a ridiculously awkward and impractical keyboard mapping anyways?...

... I mean, except for insane people with too much free time on their hands obviously

Pictures from TI-Planet here: https://tiplanet.org/forum/gallery/image_page.php?image_id=9606. And yes, it does look neat in person.

This board won't let me port the firmware image because it's exactly 1024 KiB in size, so here's where to get it on TI-Planet if people want to try it out: https://tiplanet.org/forum/viewtopic.php?f=102&t=21520&start=20#p232267

I created the ultimate Frankenstein monster... BWAHAHAHAHA!

https://tiplanet.org/forum/viewtopic.php?t=21540&p=232286
https://github.com/numworks/epsilon/pull/534

Nice!

Looking at the code, my only remark for now would be to use a device tree instead of ATAGS. I don't think it's possible to upstream new non-device tree ARM platforms for Linux anymore.