Engin Cilasun

Well that's the easy part. The real question is, how do they get out?

Packed the whole thing into the small resin printer volume. Hope this time around (and with tough resin) tolerances are good.

How do 9 elephants get into a car?

I see something bent a bit, more supports needed next time.

A transparent mockup (since I ran out of tough resin)
Brittle, but should hold to test putting one machine together.

Things are coming along nicely. Also managed to fix my old 3D printer and printing a few mockups to see how they hold up.

Made the enclosure much smaller today.
It still requires a large format printer (to not cause cuts), but on the bright side it doesn't require screws to hold together except for the 4x 1mm screws at the bottom for the FPGA board.

Printing the enclosure on a small-ish resin printer is haunting me. I don't want to print it in pieces or deal with resin anymore.
I'll look into buying or building an FDM printer later.

Took a week off to work on sandpiper and relax my mind a bit.
This evening, I added a hardware scroller. Thanks to the extra 64 bytes I read at the end of a scanline, I can scroll the view by that much without CPU intervention.
Once I get permits, I'll opensource this thing as well.

Coding some samples on the sandpiper itself. Just got a 4:3 monitor to fit its display output.
Once I recover from this cold I’ll do more, now I have to get back to rest.

First song that crossed my mind when I heard

Audio and video modules are now both according to design.

Now, to add other interesting hardware bits and finish the enclosure of sandpiper :)

Sandpiper is up and running with everything I wanted from software side.
One problem is that audio ticks way too fast, I have to allocate some time to fix it.

The video/audio control register mappings can be obtained with two ioctl calls. The driver maps them to virtual memory at startup.

The linux kernel has no access rights to the shared memory area, and the mmap() can't leak into kernel regions, therefore user processes do not risk corrupting memory this way.
Thus, sandpiper becomes a linux machine with sort of retro computer behavior (when it comes to device access rights)

The sandpiper platform driver works.

It maps the physical address of control registers for the video and audio devices and allows mmap access to shared physical memory from user space, for non-root user.

This way, apps & games have direct access to hardware as one would with older home computers.

Working on the platform driver for the machine today. Seems like it does load and start it using the device tree and maps the device memory properly.

Interesting. I should give it a go I guess. After switching to Zynq I found very little I needed to do on the FPGA fabric and honestly didn’t want to deal with Vivado

What can I say, I miss the 80s computers :D

No more screws, a more realistic FPGA board representation, hope the holes will align.
Back to writing a driver for the system.

Still a bit more to do, added custom snap-fit on the left and right side, reducing screw count to 4 (on bottom part)

So blocky :D

I think this is closer to final. It doesn't fit onto my 3D printer and splitting it would not be great, so I have to figure out an economical way to build this.

I currently do not have bandwidth to make my own OS (like I did with the RISC-V one), also hesitant to do so because there is so much software which runs out of the box.
Maybe not a big deal; swapping the SD card can change the entire OS + hardware so maybe later.

And btw this is Linux kernel 6.12.* plus Ubuntu 20.04 (armhf running on the device)

The dual ARM cores are clocked at 666.6 MHz, and the memory is a 512Mbyte part with ~1600 MT/sec
It's quite something compared to my own attempts of making a poor CPU :D

It was quite easy to get fbcon going as well; just need to make sure it's mentioned in the device tree, and the kernel fbcon picks it up (via dev/fb0)

I haven't done much except custom video scan-out + audio output hardware, plus a custom USB keyboard yet, but I'll add more hardware devices going forward.
Here's Quake running on the device at 72FPS thanks to those fast ARM cpus.

Everything works now.

Custom keyboard over USB, video out as /dev/fb0, fbcon, audio (still not ALSA compatible but oh well), network and running Ubuntu 20.04

1% unsure about using Linux but I don't have to port over or rebuild tinysys OS for dual ARM cores in time.

We'll go with Linux for now.

Final keyboard build. I'm aiming to have this as a separate panel which can also plug into a PC.

Fixed keyboars on the way. Firmware downloader arrived. New enclosure design going well.
I think at this speed I'll have v1 in a state that is ready to go through the sharing / permit process.