In the context of the Amiga you didn’t need to change the signal frequency, the underlying video signal stayed the same.

For wider pixels, the hardware just drew each pixel for longer, and for taller pixels each pixel spanned more lines.

Pixels weren’t real in the CRT days :)

> Pixels weren’t real in the CRT days :)

True, but it gets more purely true if we add the word analog in front of CRT. While no CRT had pixels native to the display in the way LCD & LED monitors do, it's worth clarifying whether we're talking about the video signal's native traits or the display's.

Most techies today were raised in a digital video world, so they learned to think of display output as being natively digital. Many struggle to fully wrap their heads around how a natively 'non-pixel' analog video signal is even a coherent concept. Often, they'll start by conceding "Sure, I get that in the 'old days', video output was converted into analog somewhere downstream before it 'hit glass', but raster image data in a digital computer was still 'born' as discrete pixels in a frame buffer. Even if it's converted to analog for display output, somewhere there's a natively 'pixel' form of that raster, right?"

While that was true on virtually all early 8-bit computers like the Apple II, Atari 400/800, C64, etc, it wasn't always the case before that. Some early digital computers displayed raster imagery on analog televisions which never existed anywhere as discrete pixels. Instead, they synthesized each horizontal scanline as an analog waveform. While these scanlines did technically have a resolution, that resolution was expressed as frequency and bandwidth of the waveform, not pixels. The raster image never at any point existed as discrete pixels, in much the same way that early audio recordings on vinyl discs or cylinders were never discrete "audio samples."

Thus, analog video imagery from some early digital computers wasn't just a display conversion of a 'ground truth' pixel raster, no pixels ever existed. For many digital natives it can be challenging to conceptualize media that isn't fundamentally quantized into discrete digital values.

In a sense pixels arent even real today right? It's an abstraction

Kinda, but a CRT literally doesn’t have precise pixel targeting in the way an LCD does. Instead, you’re telling the electron gun to draw red for a little while, and it paints what it paints.

LCD and OLED panels consist of a fixed, unchangeable matrix of native pixels. (Same for the discontinued Plasma TVs.) CRTs don’t have that.

This is open-source hardware, caveat emptor is implied.

At this stage in a project like this, I’d expect the people who were getting boards fabbed to also have the skills to sanity check the schematics and layout before they sent the gerbers off to China.

For me, one of the saddest side-effects of modern generative AI is this apparent rise in an attitude of “I don’t know how to do this, therefore anyone who does this must have just one-shotted it with AI”.

Even if we assume this _could_ be one-shotted, projects like this from respected members of the retro hardware community would be what made that one-shot even possible.

As far as I can tell the person you are replying to has never posted anything of value or substance, maybe they should start using AI more

If this is the case, they should start using AI less.

It isn’t, actually.

Thank you! A project like this is all about compounding small wins for sure, just building one thing on top of the previous thing until (hopefully) one day it’s a complete thing :D

I’m glad you found some inspiration and really appreciate your kind comment :)

Haha that quote felt pretty much obligatory :D Non-POSIX is definitely keeping things fun, letting me explore different ideas without having to fit into an existing interface design :)

While not basing the OS on POSIX is good, if you ever want to use it for more than a hobby, i.e. if you ever want to use it for your main personal computer, you will also need a translation layer for the LINUX syscalls, which would enable you to compile and run any of the existing open-source programs, or even run existing binaries.

Porting the programs that you are more interested in from Linux or *BSD to your own OS is the best, but this is necessarily slow and also the work of porting rarely used applications may not be worthwhile.

An alternative to a syscall translation layer is for your OS to act as a hypervisor for Linux or other OSes VMs. However, this would have a lower performance than using natively your IPC-based OS.

I agree that for it to be generally useful, it’ll need to be easy to port existing software to. But I don’t think I’ll need a translation layer at the syscall level (unless I want to expose a Linux-compatible ABI as you suggest, which is totally a non-goal).

You can get surprisingly far in this area with a decent libc implementation - once you have that porting a lot of things becomes possible. There will always be harder problems (e.g. anything that hard-depends on fork) but with enough work pretty much anything in user-space should be possible to port eventually.

I’m using newlib for libc, with a custom Anos-specific libgloss that mostly talks to SYSTEM via IPC to get stuff done, and uses syscalls where needed (and a process has the appropriate capabilities). I’m filling out that low-level interface as I go, and will be using porting of exiting BSD or Linux software to drive that implementation :)

I agree that instead of implementing the Linux syscalls implementing just those libc functions that are OS dependent is sufficient for a large fraction of the existing programs.

However, this means implementing a POSIX layer, similarly to Windows NT. So it is a solution more distant from a "non-POSIX operating system".

While a large part of the Linux syscalls have been motivated by the necessities of implementing POSIX, there are also significant differences and the Linux applications that require the best performance must deviate significantly from POSIX, so they are no longer based on libc for I/O.

There would likely be value in a POSIX layer as you describe, at least from the point of view of porting existing programs. And perhaps it will happen, if I get far enough along, but it will never be a kernel feature - it would be an entirely userspace concept intended only to speed up porting and building out said user space.

Perhaps in the fullness of time essential software can be rewritten to Anos’ “native API”, or perhaps that’s a pipe dream and not worth the work, but the option will be there.

Thanks! I haven't thought much about long term to be honest, right now my immediate goal is to get enough USB HID to be able to make it interactive, with the medium term goal of porting enough software for it being self-hosting.

> We live in an age of AI overinvestment. I would reserve judgement until they prove they actually have something.

Haha yes, that's a very fair comment!

There's ideas in here from various other kernels - some of the capability stuff is inspired by (but simpler than) seL4, and the message passing IPC and how I'll avoid priority inversion is based on ideas from QNX. Generally as a learning process I've tried to keep as open a mind as possible, without trying to reinvent all the wheels at once...

SYSTEM has a tiny arch-specific assembly trampoline which just sets up the initial stack pointer for new processes that it creates and makes the jump, but other than that it's source-compatible across architectures.

The platform detail extraction isn't yet complete, such that devices management on non-ACPI platforms isn't finished, but the idea is the abstraction will be enough that drivers for (at least) MMIO devices will be trivially portable.

That's a good way to look at it, and on reflection I feel the same way.

It's certainly useful _to me_ and has helped me really nail down concepts I thought I already understood, but it turns out I didn't.

I just hope that, in an age where it feels like code, and maybe even deep technical knowledge have diminishing value, projects like this don't become completely anachronistic.