ikskuh

Creator here!

Yes, the OS is highly opinionated, as just making another linux is incredibly boring for me!

The 32-bit only constraint is mainly due to my focus on smaller architectures, especially microcontrollers.

x86_64 and aarch64 both have much more complex initialiastion schemes, and also use much more complex page table setups.

Thus, i wanted to keep that out of the system, considering i'm targeting systems with a tiny fraction of the 4 GiB memory limit.

The co-op multitasking is a part of the OS, and the OS doesn't give you preemptive multitasking. I never said i won't implement sanity safeguards! Just killing off a hanging process that doesnt yield for more than 1-5 secs is totally i scope and increases user friendlyness. but considering the system reboots in 1.2 s on target hw right now, the user will maybe just have hit reset by then :D

Module spec should be around 85x28x100 mm size, so we'd have a deep module with around 15mm of "front extrusion" to fit the modules.

It's definitly possible to re-layout the backplane into a different mechanical design, and reduce the number of slots

Final specs will be shared soon, i have to do another revision of the hardware design as i figured mechanical properties like that the "stickyness" of PCIe slots is good enough so you dont actually need mechanical screws to fasten the modules

Creator here!

You're absolutely right! I wasn't there either, and i wouldnt want a terminal-only machine.

My goal is providing means and knowledge to those that want it. The Ashet is more meant for technical schools, apprenticeship and "the interested", and definitly requires an initial spark that will make that project interesting to you.

It's here to fill a (percieved) gap and wants to sit more in the professional education part than the "get the kids to computing".

I'd love to have had such a hands-on device in school instead of the bare theory of circuit operation and basics of programming.

Lua is planned! It's an interpreted language with a lightweight compiler which is one of the next things on the "large scale" todo list!

Creator here!

Wanna hop onto my crazy train and make a second main board?

I wanna make the Ashet Home Computer an open and free platform, so if you implement the backend control interface, you can use all of the environment yourself.

I am way worse than OP and have no documentation at all.

I confess guilty at the currenr point. I do have planned a large phase in development where i will create entry-level docs for everything, as these are an essential part of the project.

The video is incredibly cool! Ashet started as a SoC in a ECP5, but the RP2350 basically hit all my spec requirements better than i could've done it myself, which made it a no-brainer to ditch the FPGA

Creator here!

I did consider Euro Rack, 19" racks, MiniATX and other case standards. But with any of these options, i wouldnt be able to keep the price low. The case including all parts and assembly cost is roughly at 20€ per device. It's an off-the-shelf part, with only lasercutted parts in two materials, and a single custom component which is yet to be determined what's the cheapest manufacturing option.

I wanted to keep the price low and any of the options above would increase the price by at least 40€, which is a subatantial part of the components

Creator here!

I'm also having ADHD but you can get help with the focus problem ;)

It's incredible to work for many years on the same thing and it's so pleasing to have steady progress.

So: Go, start building a vision for your cyberdeck! Having a clear goal helps you working towards building it, and you cam embrace the ADHD by jumping around between the many aspects of such a project.

sw design, hw design, visual design, mechanical design, handcrafting, soldering, programming, making websites, asking people, ...

Creator here!

You can subscribe to the E-Mail newsletter linked on the front page (or on Community)

Creator here!

I know, i know! This is what makes me a bit sad. I dont know of any modern compiler i can use on the platform, as most hobby compilers target aarch64 or 32/64 bit x86.

What i need tho is a compiler that targets Arm/Thumb-2.

My research tells me that this confines me to: - A non-complete patch series for TCC (maybe) - LLVM - GCC

As twonof them obviously won't run on 8 MB, my options are stripped down to:

- Evaluate CBE and write my own backend and add 32 bit support - Write my own compiler + backend

Both options don't sound viable before the release as they would increase the scope greatly.

Note taken!

Will add a new "cleaned up" photo that isn't also entangled with kids stuff, and other desk content :D

Sadly, it really looks atrocious and it's currently a 3D build which is hard to photograph.

Creator here.

Please take a look at the gallery, where there are photos of the actual electronics setups!

Also don't the mechanical mockups count as hardware? A pile of jumperwires, breadboards and devices don't make a good hero image, but physical hardware mockups do.

Also the electronics design in its current form is actually iteration 5 of the system, while the OS development started with iteration 2.

The OS does boot on the electrical prototype

Creator here!

That sounds exactly what i had in mind, and i really wanna do the same when my boy is old enough for computers.

It's a teaching tool and a fun toy to tinker with

If everything goes according to plan, Zig will be the only language that is capable of actually utilizing the AVR 24 bit address space properly, while also allowing you to make nice optimizations with the smaller 16 bit address spaces (Zig has first class address spaces on memory)

Also, RISC-V support is working quite fine, and i don't see much problems with that.

But I don't think we need more AVR going forward. It's rather proprietary, no?

AVR is Arduino. It would be a bad action to basically say: "well, zig is not going to support the most widespread maker hardware on the market"

Then you definitly should check out MicroZig!

I will push my bugfixes for current master branch tomorrow or later, so you can directly play around!

Zig is not perfect on targeting AVR, but it's capable enough to not be a PITA.

Since we've made microzig supporting AVR targets (currently atmega328p only, feel free to add more), i'm not using anything else.

Oh and: We can target an ATtiny1616 without problems. avr-libc doesn't officially support the Tiny2 family yet.

This is sadly very badly worded.

Zig provides a global allocator when running tests that will check for memory leaks and double frees. This allocator is only available in the test suite tho, if you want to compile an executable, one has to chose between several allocators and instantiate them explicitly.

There are three allocators that are globally available in the standard library: - `std.heap.c_allocator`, a wrapper around malloc/free. only available when linking libc - `std.heap.page_allocator`, a wrapper around VirtualAlloc/mmap. Can only allocate in OS page size granularity and is quite slow. A good backing for other allocators tho. - `std.testing.failing_allocator`, an allocator that will always yield OutOfMemory.

For the use in an application, there's the std.heap.GeneralPurposeAllocator type that needs to be explicitly instantiated, and it provides a good portion of debugging features right now. High-speed implementations are planned for release modes

Zig is harder to learn than C with more difficult concepts.

I'm using Zig and C for a good amount of time now and i disagree. Zig has simpler concepts as C, but in C you can just ignore them.

Consider

   char buf[4];
   float * f = buf;
   *f = 32;

And Zig has a lot of these things that require implicit knowledge in C as explicit knowledge implemented in the language itself. Same goes for integer casting, shifting more than sizeof() bits, and so on.

It moves the footguns from the code to the user, and so the user has to learn about all of these concepts before writing Zig code. In C, the code will silently compile and misbehave at runtime. This might feel like additional complexity in a lot of places, but the complexity is there in both languages. One just makes it explicit.

But this is obviously not true for all things in Zig. comptime is a whole new feature that wasn't seen in a lot of languages before and afaik not as it is used in Zig, so it's something new to learn even if you already can do perfect C. The same goes for more precise data types (struct vs extern struct) and so on.

One hard footgun in Zig right now is implicit aliasing of parameter types, which sometimes get passed as a reference and sometimes as a value. This is a known footgun is already on the table to be adressed by better semantics and more safety guards

For me, writing Zig feels way less complex than C because a lot of brain load that went into writing correct C was offloaded to the compiler, which is good. But it also increases the friction when writing code as the compiler forces you to think about alignment and such.

One thing to note is that usvg doesn't preserve text at the moment (will be converted into paths automatically) and Quadratic curves.

I mean, that sounds perfect in my ears as TinyVG doesn't has text/font support anyways and you need to perform the conversion at one point or another.

Probably a day, as long as you know Rust. I can take a look into it if you're interested

That would be rad! I'll try to do that myself as well, but my last experience with Rust is over two years away, so i'd be happy to see a pro doing the work!

I wasn't talking about text in that case. Here's a screenshot of that image:

https://mq32.de/public/9f3cd5eb7f310139cf8acdd61edb73080d26a...

Oh, hi!

A small nitpick as the resvg author: the repo located here https://github.com/RazrFalcon/resvg

Oh, i didn't see this. Thanks for some more correct and real numbers, i will correct them in the article later!

I'm not sure why the author linked some random, outdated fork.

because it appears way higher up on the google search if you search for "svg rendering library". Sorry i didn't recognize that it's a fork!

Nice work then! I should check it out for SVG rendering and parsing.

How much work would it be to port over the C# SVG→TinyVG converter to Rust based on resvg? Considering that you already have a well done parser compared to mine...

Yes, but SVG can and will do forward references. Ergo, we have to store some kind of DOM in order to resolve them. Even if it's not in the form of the XML doc

If excalidraw supports conversion of text to paths, you can do it!

I think you got me wrong then. I WANT authoring files and redistributables to differ. Nobody should send SVG, xcf, psd files to the consumers. We use PNG or JPEG for pixel graphics, why not send of TinyVG instead of SVG, but use SVG as the source file.

This is what i've done for a lot of test files until i had the TinyVG text form ready.

Also, we should not edit graphic files in a code editor. We have better tools for that

Oh, good catch. But this is actually not a problem in the rendering, but a conversion problem from SVG to TinyVG. The converter doesn't do hierarchical attributes yet, so if something uses a <g> to disable filling, it will still fill those elements

So i did the dance with a single file (my starter file):

It's the "shield-account" from material design.

    353 shield.svg
    246 shield.svg.gz
    119 shield.tvg
    139 shield.tvg.gz

TinyVG was also designed to be used on constrained embedded systems with low RAM, and i have a proof of concept that it can render medium complexity files with less than 32k RAM without memory optimizations in the reference implementation. NanoVG doesn't seem to support streaming render events either, so it isn't suitable for low memory profiles as it creates a DOM that will be rendered

2. …

Oh that explains why all my rendering experiments looked different from SVG. I think the reference renderer already does gamma correct blending.

This is something we should add to the specification for sure.

1. …

Even re-encoding the SVG crap would only remove XML from the equation, but that's not my main concern with SVG.

Zig has the Zen "only one way to do things". Meanwhile SVG has tens of ways to solve the same problem.

One example: You can set the opacity via css, fill-opacity and opacity. What you cannot do: Set the opacity via color. But you can make 50% black by just specifying fill-opacity, as black is the default color. to render lines, you need to set fill to "none". ugh.

The question is if we talk about decoding or rendering performance. Right now, the software renderer is slow as heck and not optimized at all.

But the decoding speed should be blazingly fast, as there is not much memory heavy lifting to do, and only a handful of int to float conversions.

As soon as i have a competetive rendering (aka Vulkan), i will add those to the benchmark. My guess is that rendering TinyVG should also be much faster than SVG due to not having any matrix transformations or hierarchies included in the format

That's a good question! I fell for this problem with text rendering once as the font i've used in a SVG wasn't installed on the target machine.

If i create a image, i want that image to look exactly the same on all machines. This is sadly not the fact for SVG :(

The W3C SVG example files contain a lot of these files that make every SVG renderer explode. There's images that don't render anywhere except inkscape

The tag thingy is an interesting idea, could you create a github issue on the specification repo for that?

=> https://github.com/TinyVG/specification/

Can you elaborate that and provide some sources on what a mesh gradient is?