GeckOS: a Unix-like 6502 operating system | VCFMW 2019

GeckOS is a 6502 operating system by André Fachat with preemptive multi-tasking, signals, semaphores, redirection, a standard library, and its own relocatable file format. This talk from Glenn Holmer describes the Commodore 64 version.
---
Vintage Computer Festival Midwest is a free, volunteer-run show for the vintage computer hobbyist community. For more information about Vintage Computer Festival Midwest, visit www.vcfmw.org/

[@8bittimes]

Thanks so much Glenn for presenting my operating system whose roots go down 30 years now! Brings back so many memories! That was a really great presentation! I will try to answer some of the questions in separate comments

[@jumpstar9000]

I wrote a multi-tasking kernel for Commodore 64 in 1983 or 1984. That used stack swapping. It worked surprisingly well and ran a "user" task with an editor (with multiple virtual documents), another for a graphical display, with two background tasks, one running xmodem over RS-232 and another driving a 20 tonne CNC press over a parallel port. It wasnt designed to be as general as what is talked about here, but I was quite proud of it at the time. I think I wrote it using a cross assembler on a CP/M machine if I remember correctly. Very nice to hear about these projects. Super cool.

[@8bittimes]

So, if you like to delve deeper into GeckOS, there is a documentation page for V1 - the one just working with MMU - but that still gives you an overview on the microkernel base architecture of GeckOS that hasn't changed with V2: www.6502.org/users/andre/osa/oa1.html

[@8bittimes]

On IRQ handling: This is obviously system-specific, as for example the PET cannot map out its ROM, so you have to use the system IRQ vector and point it to GeckOS interrupt routine. But in general the OS only uses the IRQ. There is a specific area in the "ROM" image that contains the device handlers. On an interrupt each device handler is called in turn until the IRQ is resolved. The list of device handlers is thus determined at build time, although IIRC you can register new device handlers lateron as well. Devices have IIRC a separate kernel call to handle them. Note that the "fsdev" filesystem is independent from the actual device handlers. It only makes the devices accessible as files using the mentioned kernel call, so you can e.g. redirect input/output to them. One timer interrupt is handled by the scheduler (outside the device handler chain), to be able to preempt tasks. NMI can actually be used as well, but there can only be a single NMI handler registered to it. NMI is discouraged, as it breaks timings e.g. in the IEC bus, but maybe necessary for embedded systems with I/O protocols less susceptible to such timing problems.

[@8bittimes]

On scheduling...: I really didn't remember about the priorities :-) In fact a task (it sounds strange nowadays writing "task" instead of "process"...) can call YIELD to set itself asleep and let another task take over. For example the filesystem tasks like the IEC/IEEE488 "fsiec" task, when run, checks for incoming ATN (yes, on my self-built computer you could use the system as disk drive, e.g. "exporting" a PC disk supported by the "fsibm" task to the C64 or PET), or whether it needs to transfer some data to/from the buffers. If it has looped all open files, it just YIELDS to the next task. Regarding the Ctrl-C - that is an interesting idea. The terminal device does not know anything about who is listening to it, it only knows the data stream it sends to. It would need some kind of side-channel to send a SIG_STOP(?) signal to the task that actually listen to the stream. One could do a shortcut and send it to all tasks that have this stream as STDIN. The standard signal handler could then terminate the program if not overwritten by the program. But that shortcut to the process table feels nasty, and also deprives the possibility that you could forward the signal to a remote stream...

[@8bittimes]

In the internet capabilities...: there is a "slipd" "Serial Line Internet Protocol daemon" that runs in the background and accepts commands using the internal messaging feature. So when you look at the "telnet" program, it is in fact rather short, as it only calls "connect" on the lib6502, which in turn sends an "FS_CONNECT" message to the "NET" address (using the SENDBUF absolute address which is protected by a semaphore...). The slipd takes all the burden of the IP protocol, it is written completely in assembler. And probably buggy as hell. A friend of mine used to host (a loooong time ago) a C64 with a VC1541 connected to the internet, serving a single web page and a small gif. It was really slooooww as we did not use fast loaders. These days I would rather re-write slipd into a real TCP/IP daemon using Adam Dunkel's uIP stack.

[@cejaybee]

One person! \o/ Asterix came about after a discussion with a friend that one of the core features of Unix-like operating systems was... a reentrant shell, so I had a go at realizing it by making something that had a boot script. Unfortunately, University studies & exams got in the way of making Asterix a self-hosting assembler environment...

[@cejaybee]

...and regarding the source code-- I do still have it! I believe I used a de-lamer-ed version of turbo assembler/turboass/tass, and the original files are in its tokenized format, but I also have copies (of all?) converted to ASCII for emailing to someone back then.. Email me at [e-mail], and I'll organize an archive.

[@cejaybee]

PS: I believe Jim Brain's first post to comp.sys.cbm was thanking me for Asterix. :)

[@csbruce]

0:05 A Unix-like OS on a 6502 system? But that's crazy!! 1:56 The Commodore-128 came with a Memory-Management Unit that had the ability to remap zero page and the stack page for quick context switches. The 65816 can do this also, for both the zero page and stack. If you have a RAM-Expansion Unit for your C64, then you could store those pages in the REU swap the content at about 500 kB/sec, or in 1/1800th of a second if you assume 254 bytes of zero page and 30 bytes of active stack, though most threads/processes would only need to copy a fraction of this amount. 3:51 How many people there raised their hand for ACE? The ACE-OS interface has a vague flavor of Unix, though it certainly doesn't multi-task. I once wrote a multi-tasking OS for the C128 using a machine-language monitor on the C128. (Never mind the luxury of an Assembler!) It was very cool in that it had multiple windows where different threads could show their output, but it was too buggy. This gave me the idea to develop a uni-tasking OS (ACE) and focus on the applications. 7:12 From context, I'll assume that a "task" is equivalent to a Unix "process". Each thread would need its own stack. Do all the threads of a process share the same zero page? It's not clear what makes more sense: to treat zero page like shared storage or as virtual processor registers. Maybe processes would want to allocate sections of zero page for each purpose. 13:42 I'll assume the kernel doesn't do a preemptive thread switch every 20 ms, but only every Nth interrupt, or else the system would spend most of its time context switching. The standard C64 Kernal also uses a CIA timer rather than a raster interrupt for its Jiffy timer. 13:55 Is it really necessary to partition the stack and give user threads such little stack space? Does the kernel actually need a separate stack area? It seems to me that you could handle the kernel pretty much how you handle interrupts: the kernel just uses the user-thread stacks in the normal way. If a process yields or gets blocked inside the kernel (the only place that this can happen), a context switch just brings in the new stack (and maybe zero-page) of the new Current thread/process and that thread just picks up from the point inside the kernel where it left off. All context switches would happen with threads executing kernel code (by call or interrupt). I wrote a couple of task-switching mechanisms for the C128 that were never fully completed, but I think they both worked like this. As pointed out, only the in-use portions of the stacks need to be copied. How is the context switching of zero page managed? If all the threads of a process share the same zero page, you don't need to swap that out when switching between the threads of a process. Are all of the zero-page locations allocated to processes or is only a small section available? On a limited CPU like the 6502, you want to allow applications to use as much of zero-page as possible, though most apps probably won't need that much, so they should probably explicitly ask for the zero-page storage they need, such as with a call to reserve the first N bytes of zero page, where the bytes beyond this limit are not guaranteed to maintain their content. This minimizes the amount of swapping needed for a process context switch. 16:41 So it's a microkernel, with I/O handled by driver processes. 27:43 It's more of a clone() than a fork() if the child process immediately starts running a new program with fresh variable values. An important quality of fork() on Unix is that it starts the child process with the exact context and variable content of the parent process, so it can be used for parallel processing without dealing with all of the inherent conflicts and Heisenbugs of using multi-threading for parallel processing. 29:18 It's good to see that the kernel calls are made with JSR instead of BRK. 35:00 Control-C is implemented as a SIGINT Signal on Unix. Since GeckOS already has a signal-management system, this seems like an obvious thing to add. 35:40 Even the first four or six characters of program names would be helpful. Lots of the command names are only two letters. 37:00 Do the shells run programs as separate child processes? 43:30 With an REU, you could do a little bit of swapping. You wouldn't want to *relocate* the code of the loaded programs, though. 44:22 Instead of relying on the assembler to allocate space in a special zero-page segment, it seems to me that you'd want to keep reusing zero-page locations as much as possible since they are so scarce. 46:38 Guess that answers my question from before; the priority mechanism reduces the context-switching costs in addition to inter-mixing the execution. 46:50 Can multiple processes execute the same instance of a loaded program? I.e., are the programs reentrant? If you allocate all storage to zero-page or to indirectly-referenced dynamically-allocated RAM, you could. How does the OS manage dynamically-allocated RAM?

[@8bittimes]

Wow, let me tackle some points: 7:12: yes, a "task" is like a unix "process" .And each thread indeed has its own stack space. Hierarchy goes thread -> task -> environment, where environment is a memory mapping. So in non-MMU systems iike the C64 there is only one environment, in my CS/A with MMU, each task has its own environment. 13:42: the kernel can do a switch every 20ms, but in fact it doesn't due to the "priorities" mentioned, which give a task more time slices. 13:55: Partitioning the stack is one option. Another is copying over the in-use part of the stack (there's a build option for that). The kernel has its own stack space because ... good question. It comes from the original MMU system that protects kernel stack in its own environment. There is no context switching of zero page. The zeropage is shared among tasks using some kind of memory management. When loaded, each program states what amount of zeropage space it needs, and the addresses i nthe binary get relocated. This also answers your question at 46:50. A binary can be executed multiple times, but it is loaded separately for each time, being relocated to a free memory space. It needs to be in o65 format for that. 16:41: yes. Well. interrupt I/O is done by device drivers (like keyboard, and screen, serial etc). More complex I/O is indeed done using driver processes like "fsiec" or "fsibm" for IEC bus and PC floppy devices respectively. 27:43: yes, it's called FORK, but not really. If you FORK, you start in a fresh environment (resp. task for non-MMU) 35:00 The problem is where to send the signals to. The only connection between devices (that generate the signal on Ctrl-C) and the tasks are streams - that are not (yet) capable of forwarding those. Got some ideas... 35:40 already fixed. 37:00 yes, as explained above, the extra shells are loaded separately. The unix type of FORK with shared binary image, and copied over variable data is not feasible with a non-MMU system (you'd have to either relocate the program on every task switch, or copy over not only zero/stack but also all the variable space) 43:30 yes. No REU here. yet. 44:22 yes, the zeropage space is memory-managed and prgrams are relocated to use what is available 46:50: as already mentioned, the OS relocates binaries. There only are three zeropage addresses that are switched over for thread / task / environment. For example the lib6502 uses this zeropage address as pointer to a per-task work area. In fact the kernel does not know about in-environment memory management at all, it only knows the size of the memory needed (from bottom up). In true separation of concerns, this is delegated to user space, particularly in the lib6502 library that loads programs into memory, allocates memory and zeropage areas for them, and relocates appropriately. Hope that helps

[@d942yd42]

@@8bittimes I love the relocation!

[@joolzg]

When i was a games programmer in the early 80s i wrote a little app that allowed you to run 2 C64 basic programs at once, a simple ping pong task switcher.....

[@jumpstar9000]

oh wow, that's a good one 👍

[@johnwinters4201]

It wouldn't be a proper UNIX if it didn't have (at least) two competing shells.

[@rhodaborrocks1654]

That's really incredible, I miss the simplicity of the 6502 and all the neat things you could do with it because of that simplicity. I still have my Apple ][ here so this has got me thinking, one of the questioners mentioned that the ][ doesn't have a timer, but one of the first things I did with mine was to buy the Apply prototyping board and put a 6522 on it which takes care of that issue, and also took care of printing etc and hooking up my radio station for RTTY, FAX etc. Happy days.

[@TheRetrospective]

Love it! The speaker is crazy... good kind of crazy! 🙂👏

[@shadowpresident4203]

The C64 is definitely a candidate for the machine that people managed to push beyond it's original makers' vision more than any other. Apparently Commodore's then-owner Jack Tramiel was so cheap that he didn't want to pay Microsoft for an updated version of BASIC included in the C64 ROM. He had an unlimited licensing deal with MS to use the increasingly outdated original version they licensed back in 1982. In a way, I think Jack himself would approve of anyone managing to get the absolute MOST performance, rather than spending money for updated hardware. Jack Tramiel was an interesting guy who had a very accomplished life, although he was ruthless and not necessarily somebody you'd want to grab a beer with. Check out the documentary on him by Kim Justice on KZbin.

[@brucemcfarling6594]

When Bill Gates wanted a per-unit license to use the upgraded Basic for the C64, after Commodore already had an open ended license for Basc V2.0, Jack purportedly told Bill something like "I already married my wife, I don't want to get married to anybody else."

[@pweddy1]

The first machine that ran a version of Unix was the 18bit PDP 7. (Then known as Unics.) And it was originally written in ASM. The standard PDP 7 had 4K words of RAM but could be expanded to 64K words, or equivalent to 144KB. The C version was written on a PDP 11. The source for an early version of C was found and stated it was the pdp 11/20 model. The PDP 7 was probably similar to a C64 in power, and I haven't been able to find any information on what upgrades the system they used at Bell labs had so there is no guarantee the C64 didn't have more memory than it did.

[@peterlamont647]

As far as I know, other than LSX, unix needed a fair amount of RAM to run at all. The only version of unix that could run on the 11/23 would be LSX(internal Bell labs OS thought to be lost, but I have a copy). Unix as far as I know ran on a PDP11/73 and systems in that range. It may have been programmed on a smaller computer, sure. However, even LSX requires way more than 4K words. In 4k, you're working from straight ML with no OS. LSX runs on 32k words of ram. It does this by doing a sysgen where you pick what part of the OS to use.

[@pweddy1]

Peter Lamont The first version of Unix was written in ASM. On a pdp 7. Think it may have had the 32k-Word option, but that may have been the first pdp 11/20 version. The MAX memory the pdp 11 series supported was 4MB. When Unix was written they most systems didn't have anywhere near that and also didn't have Virtual memory or normal memory protection. The main point is a Commodore 64 would have been fine when they were originally writing Unix. As a matter of fact being able to use a built in Keyboard and plug it into a TV on a 64K machine with floppy disk instead of paper tape and regular tape would have seemed miraculous to them at the time.

[@pweddy1]

Source for the early versions of Unix: www.tuhs.org/cgi-bin/utree.pl

[@8bittimes]

Questions about memory limitations...: GeckOS was first built (in V1) for a system with an MMU, so it used absolute addresses for comms buffers in each tasks, and every task had the full zeropage and stack area. In fact every task could have up to about 58k RAM (up until the I/O space at $e800), I even ran a version of MS BASIC in it. In V2 I started working on non-MMU machines, so RAM had to be shared: 1) stack: there is the option to swap out the current tasks stack on context switch, another option is to divide the 256 byte stack into a number of areas, one for each tasks, so only stack pointer needs to be changed (IIRC that was 32 byte per threads plus 64 byte for OS, giving a limited number of 6 threads, but that might just work for an embedded machine), and of course the MMU version still works. 2) zeropage: there is a memory management for zp addresses just as it is for main memory. The o65 relocatable format can relocate zp addresses just as well, and so zp is shared between all processes without each process knowing of the others. 3) main memory: there are IIRC still some fixed address areas (like the PCBUF message buffer, that is now transparently protected with a semaphore in lib6502 when needed, but the rest of the memory is malloc-able by any task (so the memory may be interleaved). There is no garbage collection (that would be a whole level more of complexity if at all possible). There also is no swapping in the non-MMU versions. In the MMU version there is a filesystem that maps in a ROM image of a program (that is already relocated to a fixed address) and runs it from there to save on precious RAM. This is how the boot image starts the first programs IIRC.

[@JustWasted3HoursHere]

How did you implement an MMU in your version? Is this an off the shelf chip or something you whipped up yourself?

[@8bittimes]

@@JustWasted3HoursHere I built a PET replica and used a 74ls610 chip as MMU. That chip maps 4 bits into 12, of which I used 8 for address bits and the others for write protect, no exec and valid bits. For details see www.6502.org/users/andre/csa/index.html and look for the CPU board

[@runvnc208]

This looks like an amazing way for someone to gain a fairly deep (although certainly not broad) understanding of some of the concepts behind the operation of internet servers in a relatively short time. More so than on a modern system, because you have a concentration and concise formulation of important features, in a way that makes everything from the lowest level to the highest level accessible an approachably-sized package. Not to say it isn't complex or something but boiling things down in this way is advantageous on my opinion.

[@farhanyousaf5616]

Good observation. These old processors are so simple, that it really makes learning them a do-able task. That's why I'm hear and totally love the 6502 (my first puter was an Atari 800XL).

[@PETTILmobile]

This is an amazing achievement

[@imachynn]

With a 1MB of RAM, and additional followed commercial release functionality, I can see this making sense in 1989.

[@ArneChristianRosenfeldt]

I have not yet watched, but considering that 6502 and unix are from the 70ties this would have made sense in the EARLY 80ties. The key is: Expansion slots. 1980 you got like 32 kB DRAM for 1000$. The next 64 kB. So RAM grows with you code.

[@imachynn]

@@ArneChristianRosenfeldt i see it making sense as a form of say raspberry pi of the day - universal, somewhat low power and cheap yet fully functional Unix like. That said it'd have to come out 1989, not be in the making of. If the guy moved it himself and not try to occupy himself with other things or getting some investors, he might make it a moderate success.

[@ArneChristianRosenfeldt]

In 1989 we upgraded to a 386 !! at home !! A third of the die is used for memory protection. But the memory itself was buggy and crashed Win16 (so: not Microsoft fault). Still would be cool to have Linux available then. 6502 was purely recreational at that time. Seems to be a play on the Word GeOs which already came to late.

[@8_Bit]

13:50 The standard C64 OS is also driven by a CIA timer interrupt at ~60 Hz on both PAL and NTSC machines. The Commodore 128 (in C128 mode) is vblank IRQ-driven though, which is probably what Glenn was thinking of. Great talk, just a minor detail.

[@csbruce]

Awww, I was going to make this comment! But are you sure about PAL C-128s? If I run TI$="000000":GETKEY A$:PRINT TI on a PAL C128 in VICE and manually stop it after ten seconds, I get around 600 jiffies. It would be disruptive for Commodore to change the meaning of "jiffy" on the PAL C128, so I'm guessing that they use a CIA timer like usual for the main keyboard-scan, TI-clock-increment IRQ and activate extra screen-management VIC IRQs as needed for screen effects.

[@saf271828]

The presenter is also a big proponent of the GEOS environment, which uses raster interrupts (no vblank IRQ on the C64) to source the kernel's event pump.

[@jonathanstein6056]

Glenn, thank you for doing this! Fantastic!

[@chrisf1600]

What an amazing achievement ! Great talk.

[@xlar54]

Nice work, Andre, and very good presentation, Glen!

[@douggale5962]

The commodore 128 has a very rudimentary MMU - you can page the first two pages to any 256 byte region - one mapping for zero page, and one mapping for the stack page ("1" page). 256 byte pages. When I was a kid (12 or 13) I wrote a multithreading kernel for my Commodore 128D that used it.

[@Stoney3K]

It also has twin processors because there's both a 6502 and a Z80 (aside from hardware 80 column mode). Might be interesting to develop for that, although I don't know if they can run simultaneously.

[@8bittimes]

@@Stoney3K They cannot run simultaneously. Either/or, but not both at the same time

[@8bittimes]

@Doug Gale great achievement!

[@WalterEGough]

@@Stoney3K It had a Z80 and a MOS 8502

[@joelavcoco]

This is very cool, and quite an achievement for the 6502. I really enjoyed this demonstration. The Commodore 64 gets lots of well deserved love for its graphics and the SID chip. I have a couple of them and some 128s, and I love having them. But my first love is the Tandy CoCo. Not to detract at all from GeckOS, but the difficulty in implementing a UNIX-like OS on the 6502, and the necessary limitations imposed by the 6502's design reinforces how astonishing the OS-9 operating system for the Motorola 6809 was for its time. It's a modular, preemptive multitasking, multi-user, UNIX-inspired OS that ran on machines like the SWTPC/6809, the GIMIX, and the TRS-80/Tandy Color Computer series. Level I OS-9 ran on machines without an MMU (really just a dynamic address translator) and had 64K total (minus I/O addresses) for the kernel, the file managers (file handlers), device drivers and device descriptors, and any user programs. But each program module was written in entirely position independent code, using e.g. relative branch instructions instead of absolute jumps, so it was relocatable without having to patch up addresses. And valid OS-9 modules were also supposed to be re-entrant, so that a single copy of a program in memory could be shared by multiple processes and multiple users. Level II OS-9 ran on machines with an MMU that could swap blocks of RAM in and out of the 6809's 64K address space, so each _process_ could have nearly 64K to work with. The CoCo 3, introduced in 1986 came with an MMU, came stock with 128K, could be upgraded to 512K, and could run Level II OS-9. It's really the differences between the 6502 and the 6809 that make OS-9 a more useful OS, if a somewhat less impressive feat than GeckOS. The 6809 has 2 8-bit accumulators, A and B, that can be concatenated into a 16-bit D register. It has 2 16-bit index registers, X and Y, and both U ser and S ystem 16-bit stack pointers. In addition, it has an 8-bit DP (direct page) register that can position the direct page (0 page) anywhere in memory, so each process can have its own 256 byte direct page. It has 8-bit hardware multiply. It also has lots more addressing modes than the 6502, facilitating this kind of OS and high level languages. OS-9 had a self-hosted K&R C compiler, a Pascal compiler, a structured BASIC that had an integrated editor and compiled to intermediate code, 3rd party Forth and Prolog, and so on. Its modern evolution is a community-maintained re-write called NitrOS-9 that has many optimizations, drivers for modern retro-hardware, and support for the Hitachi 6309's undocumented extra features, such as running many instructions in fewer clock cycles, more registers, hardware divide, and block transfer instructions. Far from being a proof of concept, Tandy wrote and distributed quite a bit of software under OS-9, especially Level II with the CoCo 3. SubLogic Flight Simulator, Sierra King's Quest 3 and Liesure Suit Larry (and recent unofficial backports of most of the early Sierra games), LucasArts' Koronis Rift and Rescue on Fractalus, Epyx Rogue and Sub Battle Simulator, and Activision's Laser Surgeon: Microscopic Mission were all OS-9 applications. If you want to see a good demo of the multi-user capabilities of stock 1980s OS-9 Level II on a CoCo 3, take a look at this video: kzbin.info/www/bejne/mpalgXiGha6Xrc0 Here's a video showing multitasking and windows under NitrOS-9 circa 2008: kzbin.info/www/bejne/fZm0eJ6kjrWfZ7s And here's what Level 1 OS-9 looked like on a CoCo 1 or 2 with 64K RAM: kzbin.info/www/bejne/rJ3Qk3aDoM2papI

[@csbruce]

The 6809's stack-relative addressing modes makes the system much more able to implement the C language's local variables in a clean and efficient way. The 6502 really struggles with this. 16-bit registers - luxury!

[@75slaine]

Awesome stuff. Adding this to my list of things to play with.

[@MadsonOnTheWeb]

Great presentation, this guy is really good.

[@scififan698]

wow, this is impressive stuff!

[@AaronHuslage]

I helped put on that Linux Expo Glenn! Still great memories.

[@jonathanpullen7439]

I was there ;) I loved Linus's bit about accidentally typing the device name of his modem instead of the hard drive.. "The next thing I did was file permissions". ;)

[@Cenbe]

Yes, definitely a high point in my life.

[@AgeofReason]

*Terry Davis smiles. F*

[@SquallSf]

One thing that I wanted to see in the video is memory usage. Like: - how much RAM this OS takes (after fresh boot) - how much extra RAM the OS uses per process (to keep stack, environment, signals,.. ) Also an interesting question is - how well the OS relocate things like self-modifying code ...

[@SealedKiller]

This guy is great and he reminds me of my grandpa

[@ErdrickHero]

"GeckOS" Subtitles: "Gecko ass"

[@petermuller608]

That's great!

[@charlesbaldo]

Nice video thanks. Will subscribe and like

[@thekornreeper]

Very cool 😎

[@TastyBusiness]

This is super cool. 48:19 I too would like to see it run on the Cactus. I wonder if an OSI port exists...

[@Cenbe]

To answer White_Flame's question about memory usage, the build prints out the segment usage for the c64rom image file: c64rom.o65: o65 version 0 executable file mode: 0000 =[executable][16bit][byte relocation][CPU 6502][align 1] text segment @ $77fe - $10000 [$8802 bytes] data segment @ $0300 - $0a8e [$078e bytes] bss segment @ $0a90 - $15d0 [$0b40 bytes] zero segment @ $0008 - $0073 [$006b bytes] Also, here's the "Cenbe's Commentary on GeckOS" page I mentioned: www.lyonlabs.org/commodore/onrequest/geckos-analysis.html

[@benjaminscherrey1124]

Really cool. I was an Apple ][ hacker myself but this is impressive no matter what the 6502 architecture.

[@GaryCameron780]

One challenge to get GeckOS to run on an Apple II is the Disk ][ drive doesn't have its own processor. This means the main Apple II processor would have to be100% focused on the disk drive, and ignoring all other tasks, during disk access. Else the timing for the read and write routines wouldn't work.

[@benjaminscherrey1124]

@@GaryCameron780 yeah Apple ][ was full of great little hardware hacks to make it really simple and cheap to build at the cost of requiring more tricks on behalf of the developers to do anything useful with it.

[@LionwoodRetroStudio]

Question: do any of these alternative operating systems work on the 264-series Commodore?

[@kevincozens6837]

Glen mentioned networking being done over RS-232. Instead of using SLIP I wonder if it could be set up to use ppp over the serial port.

[@8bittimes]

I guess it could. But you (or someone else) needs to provide ppp code....

[@jonathanpullen7439]

PPP is a bit more complex to implement. Let's remember this poor C64 only has 64k of ram.. ;)

[@8bittimes]

@Lassi Kinnunen slip has it's own IP stack. In fact GeckOS has an IPv4 stack written in Assembler to provide slip, and there is another IP stack, uIP that can run on the Commodore as well.

[@dellagustin]

Loved that cat that file joke

[@agpxnet]

What is missing? A SERIOUS optimized C-Compiler for 6502!

[@herrbonk3635]

How do you implement an Algol like language (like C) on a machine with max 256 bytes of stack? It must be extremely limited in parameter passing and local variables, especially times call levels. Not to mention recursion.

[@rabidbigdog]

C on the 6502 is really difficult, hence why I believe the cc65 and (prior) Small C actually runs on a virtual machine/runtime. A bit more like .NET or Java.

[@herrbonk3635]

@@rabidbigdog Or like the 1960s o-code or 1970s p-code, to be a little less recentist🙂The p-code based UCSD Pascal worked on processors like PDP-11, Z80, 8086, 68K, and was also ported to the 6502 based Apple II. (I still got the manuals.) (Pascal is also in a way more demanding than C, as it implements nested functions with local scopes in "any" number of levels.)

[@BruceHoult]

@@herrbonk3635 That's simple -- you don't put any of those things on the CPU stack, you make your own using a pair of zero page locations as the stack pointer. At maximum you leave return adresses on the CPU stack. If you recurse 128 deep then you're probably already out of RAM for other reasons, and if its anything other than a silly linear recursion that should be TCOd then you're at the end of the universe too.

[@herrbonk3635]

@@BruceHoult Good answer! But still pretty slow (having to manually inc/dec that stack pointer in memory, with carry too).

[@jimreynolds2399]

This is great! Wondering if someone could produce some "ROMS" for MAME. I'm guessing that this should be possible since MAME provides an emulation of the hardware i.e. the CPU, the graphics and memory map so the GeckOS code should just boot up like it's running on a real 6502-based machine. A quick check reveals that there are already a number of C64 implementations on MAME.

[@harrytsang1501]

I retreat turning on captions on this video

[@r3jjs]

Look into SLIRP, which is a SLIP emulator -- much easier to set up. You telnet in and then run a command from the prompt.

[@eternalskywalker9440]

I'm interested in doing a Commander X16 port. Where to start...

[@natilevia6794]

Start by rewriting the source code to use all of its extra registers, Design a video interface for the OS. The rest is up to you

[@afloyd4976]

This would work easily on the Atari 8-bit systems. Especially RAM expanded Rapidus systems.

[@b43xoit]

Does it issue a 1202 program alarm?

[@8BitNaptime]

Would a REU help with the swapping in and out of stacks?

[@zachz96]

The internet is 50 years old as well!

[@magoostus]

ok ok, ya gotta tell me what camera you used to record this presentation. the video is amazing

[@VCFMW]

Thanks! We used a Panasonic G85 (micro-four-thirds camera) with a 14mm-140mm zoom lens for the presentations. Video was exposed with a priority on visibility of the screen slides, which is why the presenters are a little dark. Recordings, editing, and upload to youtube were all at 4k resolution at 24fps. We have ideas on improving the lighting and exposure for next year.

[@magoostus]

@@VCFMW panasonic wins again!

[@gertachimrenel595]

Why haven't you used a C128? It has an 80 column text screen with color graphics up to 640x400 and monochrome graphics up to 720x700 pixels. And it can work with 2 MHz. New C128neo mainboards are freely available in KiCAD format.

[@brucemcfarling6594]

Because, as stated in the video, the implementer implemented it for his own custom built board first, then for the C64 and a 32KB PET. So "using a C128" would be a port, not a report on an existing OS.

[@agoogleuser2667]

Does anyone know if you could put this onto Ben Eater's 6502?

[@CrazycruxGaming]

LOL The only reason I know the 6502 is because of him!

[@maxpolaris99]

@@CrazycruxGaming You're no Boomer Nerd!

[@voltcorp]

I'd guess not, at least not right away. the C64 has twice as much RAM as Ben Eater's kit.

[@memediatek]

You would need to upgrade the ram

[@olivierdulac]

​@@voltcorp Beneater's system has 32kb of ram?

[@TymexComputing]

I am watching during the first minute and ask myself - is this the Altium guy? and what's the guitar for? Is it eclectic electric guitar

[@kevinchastain727]

has anyone tried to make a multi processor system using this OS. I found a page that talks about using these chips to make a multi processor from 6502 chips.

[@youdonotknowmyname9663]

A multi processor system with 6502s? That sounds interesting ...

[@kevinchastain727]

@@youdonotknowmyname9663 the idea came from a paper that was published on 6502.org titled "Context-Switching and Thread-Synchronization with a 6502"

[@robertturner2000]

Since the source is available, how difficult would it be to make a small board with a CPLD and an SRAM. The 6507 could plug into this board and the board plug into the CPU socket. The CPLD could use any available 8-bit memory location as an i/o port - it would always be the same location. This would select one of 256 banks of the SRAM for stack. The CPLD would also make sure that anytime the stack were accessed it would redirect to this onboard SRAM (the stack in C64 memory would no longer be accessed but a "switch" in the cpld could re-enable it if needed). This would allow context switching similar to how the TMS9900 handled it. Then the only thing needed to be preserved and restored would be the stack pointer and the context bank number. Such a scheme might also be useful to replace zero page with a banked SRAM.

[@8bittimes]

My Commodore PET clone used an MMU to re-map any of the 16 4k memory blocks in the processor address space from a larger, 1MB bus address space. This was the original "MMU" implementation of GeckOS, before I ported it to the C64

[@TheMason76]

Amazing :-O

[@ughadunk]

Can someone please show this guy the way to the C64 Demo scene?

[@gaiuszeno1331]

I'm a UNIX guy not a C64 guy so forgive me if this is a dumb question but one of those shells said it was loading an autoexec.bat file. I thought those type of batch file formats were from CP/M descendent's while Commadores ran a basic interpreter as a shell. To bootstrap GeckOS did you have to run a CP/M emulation layer?

[@saf271828]

GeckOS unmaps the KERNAL and BASIC ROMs, so it is running in a pure 64KB RAM configuration. The kernel is a real kernel. There is no emulation layer; it runs raw 6502 machine language, as the presenter indicated. autoexec.bat is just a filename.

[@vanderaj]

As it's own implementation of a very cut down Unix, and there's no init (shells are started by the kernel according to the video), you can call your configuration file anything you like, including autoexec.bat. I don't know why they chose that name though because it's not very Unix-like. I would have gone for something like "rc" but that's just me.

[@ChristmasEve777]

This shouldn't be hard to write a program for (this isn't for GeckOS, it would be a C compiler for the C64, loaded at 49152, outputting to 16384): 10 rem int i=0; 11 rem char* ptr = 8192; 12 rem while(i

[@csbruce]

Hand-coded 6502 assembly would do something like LDA #0 : TAX : - STA $2000,X : STA $2100,X : … : STA $3D00,X : STA $3E00,X : INX : BNE - : LDX #$3F : - STA $3F00,X : DEX : BPL - . I doubt a general-purpose compiler would beat this.

[@BalancedSpirit79]

Are there plans to port this to the NES? I used to follow Contiki, but their NES port never really manifested.

[@8bittimes]

I don't have a NES - but I take volunteers!

[@2000freefuel]

@@8bittimes I am in the middle of reverse engineering the Nintendo Famicom keyboard for their BASIC carts.

[@2000freefuel]

@@8bittimes use this to dev code, is had a keyboard expansion port on the side, www.ebay.com/itm/Nintendo-AV-Famicom-New-Famicom-HVC-101-System-Console-US-Seller-Japanese-B-/132131890946

[@2000freefuel]

www43.tok2.com/home/cmpslv/Famic/Fambas.htm information about the Nintendo HVC-007 keyboard as supplied with Nintendo Family Basic.

[@tthtlc]

For the question in 49:05, the answer can be found here: 6502.org/tutorials/interrupts.html#2.1

[@theannoyedmrfloyd3998]

Easily portable to the Atari 8-bit with its awesome memory upgrades.

[@jrshaul]

Mmm. Jay Miner.

[@Stoney3K]

I'd like to see this run on a NES, just for kicks.

[@ylmzhamdi2]

just reset the device, it was freezed blue screen, and close these multiple apps, resolve it, good luck!

[@parrotraiser6541]

This is all very clever and admirable in overcoming technical difficulties, but the inevitable question is "Why?". Whose problems does it solve? The "want list" sounds as though a /proc directory might be an asset.

[@Rasv-]

Why hunt when you can buy meat cut and packaged for a lot less trouble?

[@fallingwater]

If you need to ask "why", you will never understand.

[@Rasv-]

@@fallingwater i was being hyperbolic

[@fallingwater]

@@Rasv- I was replying to Parrot Raiser, hadn't read your reply, sorry

[@Rasv-]

@@fallingwater the mistake was mine.

[@taoli5497]

👍

[@AshtonSnapp]

What are semaphores useful for anyways?

[@Reth_Hard]

I think the semaphores were used in the 9th century by the Byzantine Empire to transmit messages from the border with the Abbasid Caliphate across Asia Minor to the Byzantine capital, Constantinople. I'm not quite sure tho how it is used in this context, maybe there is some little primitive people inside the Commodore 64 and that's the only way they found to communicate? Who knows...

[@vanderaj]

Semaphores are used within Unix for thread or process interprocess communication (IPC) and synchronization. Imagine you are writing some code that is waiting for something from another thread, like reading from a slow disk, like a 1541, or a serial device, like a modem. You can sem_wait() for the semaphore to be unblocked by another thread, which is executing some other code to do the read or deserialization. The other thread needs to sem_post() when it's finished, which will wake up the original thread. Although semaphores came before POSIX (IIRC, back in the SysV days of Solaris 2.x / AIX / etc), but these days that interface has been superseded by POSIX semaphores. Pretty much most modern Unix like systems have the POSIX API, and not necessarily the SysV API.

[@youdonotknowmyname9663]

As far as I understand it, they are used if you have multiple pieces of code that want to do stuff to the same variable. Imagine it like this: While a process is "using" a variable (or a piece of memory), that variable is "locked" for other processes, so the value of that variable does not change during the execution of process 1. It is a system to avoid "conflicts" while reading/writing data in a multitasking system. If I understand it correctly ...

[@herrbonk3635]

@@vanderaj In other contexts, they are simply called flags, because that's what they are.

[@DAVIDGREGORYKERR]

Would that not have been a killer OS for the Z80A based PC.

[@saf271828]

Look up fuzix.org.

[@mmille10]

"I think we all understand that the Apple and Atari computers and programmers aren't capable of making a GeckOS port." Oh, you tempt me!... Re. the last question re. why there's no C code, I totally understand why the kernel is written in assembler. If it was written in C, the OS would run even slower than what you saw in the demo, and it would hardly seem worth using. Though, I still think it would be nice to see some C code run on top of the kernel. C compilers existed for 8-bit computers back in the day, though all of them ran p-code on an Intel 8088-emulated VM, since they were all based on Tiny C, which was originally written for the x86 CPU. This gave C programs a 16-bit stack (as existed on the 8088).

[@vanderaj]

There were true C to assembly language compilers for most 8-bit computers back then, particularly on CP/M and Z80 machines. They just weren't very good. I remember having one on my Amstrad CPC 6128, although the name fails me, and it definitely wasn't interpreted, like Tiny C. I had more lockups than I care to remember. That's what drove me into the arms of Z80 assembly language. The code generated was almost as slow as BASIC. If you wanted any speed at all, write it in assembly. p-code is used by UCSD Pascal, which implements a virtual and mythical p-machine architecture, not the x86 architecture. p-code dates from the early 1970's, and I don't think the 4004 (the only Intel CPU back when the first p-Code interpreters were written), was what they were targeting. The history of p-Code and Nikolas Wirth's version (heavily used in the Apple II days), is quite interesting.

[@mmille10]

@@vanderaj - Thanks for filling in information from other platforms. My experience was only with C compilers that ran on the Atari, C-64, and Apple II (6502 platforms). The only 8-bit C-to-assembler compiler I saw was CC65, which was originally written as a cross-compiler. I could understand why, since the 8-bit version of it (created by compiling itself) was large. I'm trying to remember whether it fit on one 8-bit floppy disk. I'm thinking it didn't. My memory is the term "p-code" was used with these Tiny C-based compilers, and my understanding of what the term stood for was just "portable code." It was descriptive of the fact that it didn't run on the native hardware, but on a VM, which could be ported from machine to machine. I don't think it signified that the code from these compilers would've run on the same runtime as was used for Pascal. From your description, it's likely it wouldn't have. I read later about the history of Tiny C, that it was originally written for the 8088, and that the runtime for the versions on the 6502 platforms was an 8088 emulator, since these compilers produced 8088 code. What was likely "portable" about this is that these compilers all shared the same derivation from Tiny C, thereby producing a subset of its object language, and that they ran similar emulation amongst themselves.

[@herrbonk3635]

@@vanderaj Some Pascal compilers were much faster. And not only Turbo Pascal for CP/M. A simple Pascal compiler for ZX computers outperformed (in speed) the Pascal compiler Microsoft sold for MS DOS. A compiled program ran faster on a 3.5 MHz Z80 than on a 4.77 MHz 8088.

[@presspageentertainment]

The description of GeckoOS and the developer is an IBMer (IBM Gernany) has the same features as OS/2 2.0+. GeckoOS could be a free version of OS/2?

[@160rpm]

I thought the C64 had a 6510?

[@charlesbaldo]

160rpm Correct, the 6510 had additional io capabilities, Original generation 1 c64 used them. Both MosTech 8 bit processors. Fun and easy to work with.

[@dfgfdsfsdfsdfds5349]

can this run on the nes?

[@paschikshehu7988]

doubt it C64 has 32kB of RAM while NES has only about 2kB (famicom disk system has 8kB)

[@memes_gbc674]

@@paschikshehu7988 i thought it was called the commodore 64 because it has 64kb of ram...

[@wolvenar]

Cool

[@xTerminatorAndy]

Somebody tell the 8-bit boy

[@VCFMW]

He was in the audience.

[@szabolcsmate5254]

@@VCFMW of course he was! :D

[@nathanielbarragan882]

GeckOS for the Commander X16????

[@AshtonSnapp]

Should be possible. Don’t know if it will happen though.

[@ChristmasEve777]

It's nice that it does a lot of the stuff that a real OS does but you are just so limited running this on a C64 vs. a totally custom computer with a lot of memory that also uses the 6502. On a C64, the programs you could write would be horrible, to be honest. To write anything significant on a C64, you really need full access to the whole machine. You can do HIRES mode and write some very amazing things in 64K when you're not bogged down with a kernel (memory-wise and speed-wise). I'm not putting down this OS at all though. I'd love to see it on the custom machine André originally built it for. EDIT: how about a custom computer that uses a 6502 clocked at 2 MHz and has 1 MB of memory. And have a C compiler! That would be AWESOME! This could never ever be done on a real C64 with no memory expansion. But once you start expanding the memory on the C64, you're on a slippery slope because where do you draw the line? Might as well build a custom machine that uses a 6502.

[@8bittimes]

In fact the OS was first implemented for my custom computer with 2 MHz, and an MMU that made it super easy to switch zeropage and stack. And it was Commodore PET compatible :-) But no C-compiler back in the days.

[@ChristmasEve777]

@@8bittimes Ohh cool! Are we on the same page or what?? (no pun intended) :) I was really into my C64 back in the day (before C compilers) and I thought about writing a BASIC to machine language converter back then. I actually started it then but, being a kid, it was a little overwhelming for me so I aborted. I started to get confused by complex lines of code and how to handle them. Plus, I would have abandoned floating point numbers altogether. I'm sure I could do something much better these days but I don't think I have the time. :)

[@Lion_McLionhead]

Interesting to see just how badly the 6510 has to be degraded to do preemptive multitasking. Too bad he didn't demonstrate a segmentation fault.

[@KuraIthys]

Just hearing 'unix-like' and '6502' in the same sentence makes me feel awkward. the 6502 has so many problems with trying to force such a system onto a CPU like that. Plus, high-level languages don't run well on it either. (the poor stack operations make using stack frames impractical, which is the most common solution for most high level languages, so you end up with some really unusual decisions...)

[@8bittimes]

@@KuraIthys The OS was first built for a custom (Commodore PET-compatible) computer with MMU, that made it super easy to switch zeropage and stack, and even protect memory against other processes.

[@csbruce]

You can't get a segfault on a processor that has no memory protection.

[@csbruce]

@@8bittimes: The C-128 also has an MMU that can easily remap zero page and the stack page. It offers no memory protection, though. There is a trick that can be used with the C64 if you have an REU: store those pages of processes/threads in the REU, and you can swap the content at about 500 kB/sec, or in 1/1800th of a second if you assume 254 bytes of zero page and 30 bytes of active stack.

[@drmosfet]

Not really into retro computers, I've been there done that already, but the most impressive think to me is the small tight code, needed to make this work. I get sick and tired of over bloated code, with so many places to hide vulnerabilities and malware. I'd love to see some cross pollination between this and modern OS's. It the only way I know that stands a chance of making computer securable.

[@massmike11]

They did it on the 6809 its called os/9

[@RealDevastatia]

The 6809 was designed for multitasking though.

[@colbertbd]

FujiNet!

[@jeffreybrace5322]

Yes, it is a PDP 11/70

[@upyourtube123]

Jeffrey Brace no it’s not , you’re not playing with a full DEC

[@DanafoxyVixen]

@@upyourtube123 and that jokes so bad because you keep playing with your DEC, stop before you go blind

[@upyourtube123]

@@DanafoxyVixen that wasn't a joke, that was a line used by LGC to describe the non-36bit machines A full DEC would have 36bits.. That maybe an 11/20 its certainly not 11/70 and it should not appear as blue which is doubly misleading as no 11 cab like those would be blue ( the original photo was black and white) Seems when I looked around the internet the photo has been wrongly tagged several times, one had called it a PDP-7 and its certainly not that. I'd thought it was a PDP-10 for a bit mainly because of the blue cabs but I'll concede that its and -11 but not a 70

[@lucidmoses]

Forth (the programming language) would likely be pretty easy to implement.

[@thanatosor]

Since when, making stuff for old mpu is a hobby ?

[@your-mom-irl]

anything can be a hobby

[@nickcopeland5497]

There's a new 8 bit computer in production for a couple years now, the Commander X-16. A 6502 unix is interesting to me for that system.

[@thanatosor]

@@nickcopeland5497 I saw ppl still making 6502 / Mos kit for such hobby

[@RealDevastatia]

@@nickcopeland5497 And the Foenix256. People have been making SD card readers and custom cartridges for old 6502 for many years.

[@cecilhenry9908]

0:49: Excuse me, did you say Commodore 64???? The 8KB computer??

[@sietuuba]

If you mean the 8-bit computer, yes - and some would argue that it's not even "a real computer", certainly some (Gates) thought about it that way back then, because the 6502 has such a small stack. It didn't matter for the C64 though since it was given such a large ROM with its version of Microsoft BASIC interpreter and everything else necessary right in there so it became a useful machine. I have no idea how _this_ magic here can work, though!

[@r_j_p_]

64KB - comparable to the PDP-11 that Unix is best known for running on.

[@PeterRichardsandYoureNot]

Woah. So, back in the mid 80s we installed AIX on an rs6000 and it was over 100 megabytes of pure install. Good luck fitting The 800lb gorilla into a box made for a pair of shoes. This is like going out and saying you are going to create a preemptive multitasking OS for the Timex Sinclair. A pipe dream for sure....but actually doable.... nope.

[@sl9sl9]

The Timex Sinclair had a Z80 CPU, and this CPU was far more capable of running multi tasking operating systems than the 6502. The Z80 also did not have an MMU, but it had no stack limitations and did have a set of "shadow registers" which are extremely useful for task switching. Google "SymbOS" and your mind will be well and truly blown ;)

[@kenmeade9924]

Was AIX really 100 floppy disks worth of install or was it more like about 8 or so......

[@stephenlord8005]

be good in dos. and free dos and. ms dos dos box all of dos pc

[@jlinkels]

Programmers don't learn this elementary stuff anymore these days.

[@PaulSpades]

@@NRGY no, no. i've been trough that exact cycle the last decade. it's sadly just how things work.

[@AndreiNeacsu]

I'm sorry for this guy, but it's only thanks to emulators that anyone gives a damn about Zilogs, MOS CPUs, PowerPC and so on. If it weren't for emulators, this video would only get one view; his own. Also, emulators are phenomenal tools for understanding any architecture; be that software emulators or hardware FPGA emulators. Even for the simple fact that in an emulator you can single-step all the buses of a system originally with DRAM, the emulators deserve praise.

[@0SteveBristow]

Yes. That's exactly why the price of used computers as sky-rocketed. [/sarcasm] Plenty of computer oldies (like me) are now able to relive their youth with the benefit of being able to afford the fully-specced machines they always wanted, and with the in-depth knowledge they didn't have at the time. There is much to learn by applying modern thinking to old hardware : we have a generation of computer users learning to code who are completely abstracted from hardware - and this is how we end up with idiotic oversights like speculative execution flaws.

[@MatthewWalster]

One word counterpoint: Demoscene.

[@peterlamont647]

Owned!

[@KuraIthys]

Oh yeah. sure. That's why I have a room full of this old hardware and routinely run stuff on the hardware itself, and only use an emulator in rare circumstances... Because of course... Did you know you can still buy brand new z80 and 6502 family cpu's? Ever asked why? Granted that doesn't hold for other old designs (68000 for instance) but... These designs have uses outside of just being historical curiosities...

[@ZakKohler]

Lol

[@joebonsaipoland]

But why????????

[@ian_b]

"Because it's not there"?

[@theshouro]

Because this amazing people can :)

[@gnustep]

because it's there.

[@victordeoliveiramelo]

50th birthday of Unix!

[@mandarbamane4268]

Why not?

[@KuraIthys]

Honestly have no idea why people are so obsessed with 'unix' of all things, even in contexts when it's self-evidently not a suitable tool for the job at hand... This kind of thing above all else makes it seem more like a cult than anything else...

[@MichaelPohoreski]

KuraIthys Because of it's beautiful, minimal, **scalable** design. If you are not a programmer you probably won't understand. Yes, a custom DOS would be faster & simpler but those are relatively trivial to write because they typically only need to do 1 thing -- load programs from disk. People write *nix on 6502 for FUN and learning regardless of people saying you shouldn't waste your time with it. With such a resource constrained computer pushing things to their logical limits helps understand topics in a new light as you come up with various workarounds and solutions to problems created by the system / platform. It's the same reason Doom, NetBSD, Linux, etc. gets ported to a toaster, touchbar, super computer, and everything between. Everybody has a hobby. Writing OS's on archaic machines is this guy's passion.

[@francisgeorge7639]

I call it having fun.

[@vidaroni]

Time you enjoyed wasting wasn't wasted.

[@charlesbaldo]

Michael Pohoreski correct. The fastest best networking OS. Currently working on AIX running on AS400, it’s fast and powerful, run both business apps and telephony on it. Use Windows 10 desktop development clients though.

[@charlesbaldo]

KuraIthys checked out you channel, half the software on it is running on top of Unix, would bet my house on it. KZbin itself is running on a Google variant of Unix

[@justusstern9125]

Who needs this useless crap ?!?

[@timrichter1980]

Right, it's a hobby thing. Pushing limits etc.

[@Edward-bm7vw]

It's just for fun

[@DanafoxyVixen]

"Who needs this useless crap ?!?" Your indeed correct.. your comment is indeed useless crap

[@markb7084]

World - as far as we know - is built of things that You can eat and things that You cannot eat ... Those are non consumable kinda :_)

[@szabolcsmate5254]

Who needs attention? ;)