Ooh, this takes me back! I spent most of the 1970s working on my own OS and toolchain starting in 1972 with the datapoint 2200, then moving to the 8080 and ending with the z80 on a home-brew computer. The Z80 "killer" feature for me was mode 2 interrupts as well as the support for DRAM refresh. I have fond memories of that time. Anyway, best wishes for your project! Mike (Someone born in the first half of the last century).
Thank you very much for your comment! I am sure you understand my joy coding for the Z80 then! The mode 2 interrupt makes working with other Zilog products very comfortable indeed. I really like the amount of registers the Z80 gives, including the alternate set. I would have loved to see more Position-Independent instruction though. I admit that today I don't think the DRAM refresh signal is very useful as we can find SRAM for fairly cheap (in small sizes of course), but I can imagine that this made a big difference compared to other CPUs back in the days.
I got a chuckle watching the beginning of this video. It described the EXACT state of personal computing in the mid 1970s when I entered the computer world. Even in the mid to late 70s when the Z80 was quite popular, every manufacturer put their hardware at different locations in the I/O or memory map, depending on the processor architecture you were using. You had to enter those addresses into your BIOS (basic input output system) to be able to locate the hardware. The CP/M operating system abstracted that a bit, providing a software BIOS (table) as part of the OS, so you only had to update that. No reprogramming ROMs, etc. CP/M (Control Program for Microcomputers) was an early OS that allowed using programs written for the Z80 to be used on different manufacturers computer systems. Even then, each manufacturer used a different proprietary floppy disk format (no hard drives yet that were cheap enough to be easily accessible to hobbyists). I had one whole floppy disc with nothing but a series of utilities to alter my computer to read floppy formats for other computer systems. Once read, a Z80 program would run on another Z80 based machine. Then I just had to reverse the process and save that program from memory to a disc that used MY system's format, so i could use it again in the future. Ah, the good old days. The best thing IBM did was to create the IBM PC, arguably "a dependable Chevy" rather than "a screaming Porsche", as we had expected from the world's largest computer company. However, their two most important contributions did NOT include their hardware but were 1) standardizing the architecture for desktop (i.e. personal) computers and 2) providing the validity to industry (i.e. larger companies) for using desktop computers. Prior to that mini (one or more washing machine size) computers and mainframe (one or more room size) computers were the norm. A laptop computer... what was that? My first "portable PC" was a Kaypro "luggable", based on a Ferguson BigBoard Z80 based "all in one" board with memory, floppy drive interface, and other I/O on a single board. It had a 7" (or was it a 10") diagonal text-only screen, two 5-1/4" floppy drives, and a whopping 64K (yes, kilobytes) of memory. My main machine prior to this was also a Ferguson Big Board based homebrew system that took 1/3 of my desk, had dual 8" floppy drives and an LA-36 pedestal keyboard and wide carrage (132 characters?) printer combination, which evolved to a 12" monochrome (orange on black text) text-only monitor and full keyboard. These were my first "real" computers with more than a few kilobytes of RAM and a real operating system (CP/M). I already had some assembly language experience on the 6502 (Motorola architecture), and learned Pascal. BASIC, Forth, and C on the Z80 systems, as well as early text editor (Wordstar) and spreadsheet (Lotus 123) programs, and of course computer architecture. All this served me well in my electronics career, so I can't complain. Times have certainly changed for the better, though. My wife and I burn through a laptop every 18 months or so now, so there are a dozen or more laying around or stored in boxes, and those are just the recent ones. I am a retired EE, and she is a degreed (MS) criminologist (focus on cybercrime) and computer security admin (CCNA)... turned realtor. My desk now has 2 laptops with additional screens, an adjacent work area with various small single board computers on it, a soldering/rework area, and a small ham radio area. Everything in sight has one or more processors (most with multiple cores) running them. Yep, I have seen quite an arc in computer development, since I first took an AAAS degree in a new area of electronics some people believed would be the new direction of electronics. It was called "digital" electronics. My initial training was as an RF tech, operating and repairing microwave transmitters, receivers, and frequency division multiplexers that used discrete transistors in all-analog circuitry. The idea of digital control of RF equipment was not even taught in my military electronics courses in the USAF. Yep, a lot has changed.
NASA used Z80 processors in their Voyager spacecraft, now in interstellar space, still operational (most instruments shut down to low power available) at 45 YEARS+.
@@paulmoffat9306 erm, no. The Voyager craft we launched in 1977, not long after the Z80 was created and far too soon to be used in spacecraft. It uses 18 bit CPUs built from TTL logic as was common pre the single chip microprocessor.
Haha, thanks, I guess so! 😂 More seriously, programming in assembly is not that hard, you only have to think in assembly and not in C or any higher programming language. It's a habit that you get. In fact it's the same for all the languages, for example, trying to write imperative code in functional programming won't get you far, you have to think functional.
@@Zeal8bit yeah I know, I studied Assembly in school for like 6 months. But I'm saying that in a Kernel you must handle an infinite number of things to make it work good. I created a simple one but in C, I did only the bootloader in Assembly
This blew me away, I remember tinkering with the Z80 in the early eighties, it was fun back then, but never did we think of making an entire OS! You have made a modern style OS, color me impressed!
@ipadista: Forgot CP/M? Or UTF-DOS, etc. There were also multiuser systems based on the Z80, even a minimalist Unix clone iirc. Not to mention all the real time operating systems for it, some of them with preemtive multitasking.
@@herrbonk3635 All the Z80 computers i played with were "BASIC computers", zx80/spectrum/ABC80/ABC806 etc booting straight into a Basic env, sure in principle you could call it an OS. There were some very basic tools to interact with cassette tapes mostly "load" and "save" programs. But no actual file system. At that time I never heard about CP/M. I became aware of it a couple of decades later as a historical curiosity. We did play with asm to some extent, but typically for very specific tasks like trying to optimize sort algorithms.
In the 80's one of my first projects was to build a small computer based on Z80. It included: Z80, UVROM memory, RAM memory, PPIO, 8279 chip to manage a small keyboard and 7 segment displays, reset Push button, and so on. All the chip terminals wire wrapped, with 30 gauge wire. The software, a state machine to manage the hardware, was developed on HP emulator system and written in assembly language ...
Right! It's also hard to find the limit and stop abstracting too much, else we lose the purpose of 8-bit computers. But for example, when you write a text based program, you surely don't want to manage screen printing and scrolling manually. Similarly for disk management, so having an OS is great for that 😄
Guess it is a balance of letting the low level code handle the hardware and the high level code do the program stuff like a data base or game, but that is easier said than done.@@Zeal8bit
That would depend on the degree of abstraction and whether your API is a high or low level one. BASIC's 'PLOT X,Y' command is an API of sorts and provides some degree of abstraction. You can give a "screen" location in X,Y coordinates and it will draw a dot/pixel for you, maybe even in color if your BASIC implementation supports that. You don't need to know anything about the display generation, video memory location, how pixel data is represented memory, etc.
@@jnharton You're right, but in practice, even this API is not 100% portable. On Zeal 8-bit Computer, you cannot plot a single pixel natively, the graphics are tile based.
I like how allmost everything is basicly a file in ZealOS or could be accessed as such. Working on a Rabbit 2000 based SBC, z180 done well on steroids but very different from a hardware/interface perspective due to it's glueless design mantra, looking forward to eventually trying out that hardware abstraction layer some time later this year. ;)
Thank you! Having opened files as the most basic entity is something I love on Linux, so I wanted to have the same thing on Zeal 8-bit OS. Correct me if I am wrong but the Rabbit 2000 may not implement all Z80 instructions, if that's the case, the OS may need to be patched or corrected. In any case, feel free to try porting the OS, I can help if you have any question.
@@Zeal8bit Yeah a few, notably in/out. To access I/O space you prefix an ld instruction to specify internal or external I/O space for example. The biggest question imho will be if/how-well z88dk supports it I think, or how readable that codebase is for me to add support if it doesn't Thanks for the offer, when I get the cpuboard done and I can start porting it over I'll send you message. At the very least so you can look at the crazy thing I designed. :)
This is so cool! I haven't done much Z80 stuff this year, but I'm hoping to get back to it ^~^ I have a few programming languages I could try to port, I have a floating point library, too, which might be useful for a calculator (I come from the world of Z80 calculator programming).
Thank for you comment! Which programming languages are you interested in? I would love to see softwares on Zeal 8-bit Computer (and Zeal 8-bit OS)! Did you use to program on the TI-83/4 calculators?
@@Zeal8bit I used to code for the 83+/84+ (still do occasionally) and I got into the habit of making my own interpreters to make code more compact (at the time, we didn't have an easy/safe way to modify 0x0000-0x4000). I have one super convoluted interpreted language that occupies 32KB of ROM (2 16KB banks used, only one needs to be loaded at a time). It is the one I "completed" but the code is very ugly, unfortunately :| (both the parser and the input) I have other "bytecode" interpreters that I've used in RPGs for scripting and I vaguely modeled them after assembly, but never wrote a compiler for them, so you had to hand-calculate the bytes. I did have assembler macros to help, though. I have a parser that was heavily inspired by postscript that is actually decent in my opinion (in terms of organization, readability, and ease of use), but still very underdeveloped. I was able to make games though! I have an ambitious language that kind of works, but is buggy and, again, underdeveloped. That one has a bunch of variable types planned and is loosely inspired by python and other languages. It was meant as a TI-BASIC alternative that was faster and better for games and better at math, while still being easy to use for math, science, and engineering folks who are not dedicated programmers. Most of the math is there, but only for a handfuls of float and int formats (I think 80-bit and 32-bit floats, 8- and 16-bit ints) I don't think I can post links here, but I'm /Zeda on GitHub and have some of my projects there. Grammer2 is the "completed" one Parsnip is the "ambitious" one And apparently I never put toastscript anywhere :( that one has basic floats and ints, but is also the only one that properly supports user-defined functions :( it's also the most compact one, even with the floating point routines and all of the "graphics driver" and keyboard driver code compiled with it, I think that's all around 4KB
@@ZedaZ80 Nice, I am going to check this now! I guess that in the case of your bytecode VM you could imagine developing and compiling on a host computer before transferring the resulted binary to the target (calculator). That would be easier than hand-calculating the instructions😄 Regarding your two other projects and their parsers, do you usually make a "hard-coded" parser that is language-dependent or do you take a more generic approach with a lexer, tokens and an AST, like what yacc and bison do in C? I am also interested in writing parsers, interpreters and compilers. I usually do this for my x86_64 host computer, I haven't written any in Z80 yet. I started writing a Z80 parser and assembler in Z80 but didn't have time to finish it since I had to move forward on the motherboard hardware. I would like to finish it though and embed it in the OS' user romdisk. Ideally in a further future, if time allows, I would love to write an interpreter for a modern scripting language like Lua
@@Zeal8bit I'm not fully sure what you mean, sorry! (I don't have any kind of formal education in CS, so I often do things without knowing the words.) The parsers are designed for the language, though for the handful of times I've written an actual compiler, I do all the the tokenizing, generating an AST, optimizing the AST, and then emitting code, if that makes sense. But those have always been done on separate machines, I had started working on it for the Z80, but abandoned that :P
If it's like assembly, then the tool would be more of an assembler than a compiler, afaik. That's because it would mostly be a direct translation from mnemonics to opcodes and turning any parameters into whatever number format the bytecode interpreter expects. Unlike a language such as C, you aren't really converting the languge into something else entirely.
I'm so curious. I entered the tech industry before general-purpose operating systems existed. BASIC wasn't even invented yet, and the "internet" was just a loose network of computers linking a few universities. I can't describe how nice it is to work within modern systems, like being able to create an entire virtual machine within seconds, launch it, and begin developing within it, using any number of a variety of programming languages, command line, or RAD - your choice, with editors that will assist you with syntax highlighting and code-completion. This is hugely more convenient, to say the least, than key-punching FORTRAN code into a bunch of card stacks (1 line per card, 2000 cards, ~15 lbs. per box), delivering said stack or stacks to the computer operator, (guaranteed to be in a physical location far away from the keypunch and collators), waiting a week hoping for the best, receiving the output on like 50 lbs. (or more) of fan-folded line-printer paper, debugging, then repeating the cycle until the output matches expectations. I notice an undeniable resurgence in interest with our old hardware and software, where young people are "discovering" value in the crap we chewed our arms off to improve and leave behind. I suppose if you were raised enslaved to the console as the pioneers in this industry were, escaping meant no looking back for us. Why would we ever want to? Because to us, those inconvenient technologies were merely a means to an end, and we still have a lot of work to do. I look to the future, building it on the experiences of the past, so having actually lived it, perhaps it's a bit of a mystery for those to whom these are merely "historical events". The curious ones appear to be looking at the old 8-bit stuff with a lot more than passing interest, maybe wondering how we got along with such primitive systems? I look at that old stuff (glancing at my retired, yet functional classic IBM PC-XT and CGA monitor, with its DIP switches, huge ONE MEG of RAM, and text-scrolling that I could nearly type as fast as) and think "thank God that's over with". I think I'll go spin-up a Proxmox server and connect it to my proxy in the UK. Now where did I put my Atari 800? (Yeah, right!)
That would certainly be an interesting thing to see in an FPGA or ASIC, especially if you could make it relatively efficient. Forget those dang Intel chips, let's make an 8-core Z80!
I think you should produce a version which, given a system running CP/M, loads your new OS from a disk file, which when executed leaves the user with your new OS rather than CP/M.
That's a good idea actually! It theory we would "only" need to read the binary executable thanks to CP/M and copy it inside address 0 before jumping to it. That's something to test.
Looks like I am late to the party. The only thing I can contribute, is that the original couple of versions of MS DOS is open source. While it will be for different processors and the like, it might hold some bits that could be useful to you. Excellent work, and kudos for making it in assembly.
Thanks for your long-time support! It's never too late to join the party. There are still a lot of things left to do, mainly on making or porting software, your experience is valuable. You can join the Discord if you want to talk about the project 😄
@@Zeal8bit I have no experience in that field. I just happen to know that old DOS source code is now open source. I just did a quick check, and it is version 1.25 and 2.0. It was placed on GitHub in 2018, under an MIT license. So it means - as I understand it - that you can take the code, and modify it for your project. For me to be of any use to your project in this manner, I would have to have an 8-bit Computer and be doing some sort if programming myself, to get to grips with it all. And I don't have that, I'm afraid. But I certainly want this project to succeed, as I think it is going to have some significance down the road. This could end up being a useful educational tool for students, which alone would be wonderful.
The coolest TDM OS I used was PCMOS386 by Symlink Inc. If you typed in an unrecognised command or did a typo, it would respond with: "What?" Too cool for Skool...
Memories resurfaced... i was poor and had only own ZX-81 in about 1992-1993, with knowledege from other computers i naively dreamed of mutlitasking OS for it, i have some "in head projects" but i failed in attempts to take over interrupts without modification of hardware. I'm really envy you.
Even if a lot of people like to criticize the ZX80 and ZX81 because the standards they have today, I am convinced these two computers meant a lot to many people, they made computer science available for anyone. It's never too late to start new projects 😉 Maybe you can have a try implementing a cooperative multitasking OS
@@Zeal8bit Sadly like so many other's ... I have my own "project" and time is limited. The good thing is, you can always learn from each other and that's why I like to watch Zee80 project's.
What I would like to see is a video on the MMU, mostly because there aren't many (any?), but also to show why you chose the particular layout you did over more traditional CP/M style layout, like the one chosen for CP/M 3, or the 32k upper/lower layout which you first had and is common in some CP/M (Z80) retro devices but is usually limited to 16 pages, and how that is different (or the same) as say the NES Mapper (8KB pages?). Also why you chose "MMU" over "Mapper" (which I believe are the same in the context of this project). How you use the (current) MMU in code, an why the needed to add ability to read the MMU device in the latest PCB layout. NOTE: the new (current) MMU layout equates to a certain "Mapper" type used in MSX (16KB pages, any slot, 4MB max), sorry I cant remember what it is exactly (ASCII16?).
Basically yes, it's a Mapper, I call it MMU because that's the generic way to call it on modern MCUs and SoCs. As you guessed, the current implementation is similar to the MSX Mapper: 4 virtual pages of 16KB which can be mapped to any 16KB window of the physical 4MB of address space. So in the beginning, the memory mapping was fixed, the first half was ROM, the second half was RAM, with one 16KB bank is each half. That was easy to implement in hardware but was way too restrictive. In fact, it was not possible to port CP/M because of this because CP/M requires RAM in the first part of memory. In fact, I don't like the way CP/M maps the memory, having RAM in the first memory addresses makes it hard for boot. Indeed, as the Z80 starts executing code at address 0, it means that upon boot, we need ROM here, which will setup CP/M and switch the first part of the memory for RAM instead of ROM. This is why I decided to split the memory in 4 pages which can be swapped around at our will. Thanks to this, we can port pretty much any Z80 OS on Zeal 8-bit computer. Moreover, Zeal 8-bit OS takes advantage of this as everytime a user program is loaded, the kernel's RAM page is swapped out, kind-of "protecting" it from spurious writes. To swap in and out the pages, as single OUT instruction is required, for example, to make the first 16KB page point to the physical address 0, I only need to execute: ld a, 0 OUT (PAGE_0_ADDR), a , if I want to point to physical address 0x4000, I only need to change ld a, 0 to ld a, 1 etc... Why reading the MMU/Mapper configuration is important? Let's take the example of Zeal 8-bit OS video driver. When we are executing a user program, the first 16KB page is the Kernel code, the second, third and fourth pages are User Program RAM. As soon as the program performs a write to the video driver (print for example), the kernel will switch the last page to kernel/driver RAM. So, as soon as we enter the video driver, the first page and the last page cannot be swapped out because they are in use by the driver. But we still need to map the VRAM somewhere to write to it, how to do? The solution is to temporarily map VRAM to a page pointing to user memory (second and third page), but after we finish writing to VRAM, we need to switch back the memory page to the value it was originally mapped to! Thus, having a way to read back the configuration is necessary. In fact, it would be possible to get rid of the hardware buffer and have a "mirror" in RAM that stores what page is mapped to which address, in software. But it means that any program that would want to swap pages would strictly need to go through the kernel or the routine that would update that mirror. Else, we would have unsynced data between hardware and software, I wanted to avoid that.
@@kilianhekhuis I explained it a bit in the video presenting the latest prototype I think. In short, I am using two 4x4 bits register files, so it makes a 4 bytes SRAM. At each memory read performed by the Z80, I take the highest 2 bits of address which becomes the index of the value to read form this small RAM. The outputted 8-bit value represents the highest 8-bit of the physical address, so we get a total of 16-2+8=22 bits of address. In order to be able to read back the value of any of the 4 bytes, I had to add an octal buffer (74HC541)
@@Zeal8bit cool, thx. I have considered something like that for my initial design, but I want sure this was feasible. My current design (I'm making an FPGA CPU) just uses 20-bit addresses.
Great idea! But something is missing - this is extended addressing, de facto only 64Kb is available, but if you correctly monitor some undocumented commands on the data bus using a microcontroller, you can expand the address range without using page addressing.
Thanks for your comment. Can you give more details about what you mean for the undocumented information? I did have a thought about using an external instruction decoder to extend all the Z80 registers, but that was almost equivalent to redesigning a Z80...
Wow ... I really miss the old days, where 6809EP's, 6502's, and these Z80's were - in a way - much easier to program, than the colossal and bloated modern bits ... not like the old monitor programs and Borland C days ... Good going with your efforts. Thanks ... Subscribed ... Cheers ...
These old 8-bit computers are a pleasure to work on! The specification and manual is so simple, no cache, no pipeline, it's deterministic! 😄 Thank you for your support!
Hmm.... I would recommend putting your syscalls side-by-side with traditional Unix/Linux syscalls. You might find some more efficiencies that you can gain. For example, gettime/settime are "read/write" to the clock device, readdir is open and read from a directory file, and so on...
Linux does have a syscall for clock_gettime, clock_settime, opendir, readdir, etc... I did consider having only open/read/write/close for almost all features, but this would bring less "typing" to the code and almost less performance in some critical cases. For example, the gettime syscall can be redirected very quickly to the timer driver instead of going through the VFS and driver layers. However, gettime should not be too slow, else the returned value may be already outdated when the user program receives it. I would like to note that it's still possible to open the clock and timer drivers (if they don't register themselves as hidden) with open, and perform ioctl without using the gettime/settime syscalls. Of course, you would still need to know the name of the driver to open it, which is not the case with gettime/settime/getdate/setdate. Finally, having an all-in-one syscall for directories would be possible but somehow confusing. Imagine you want to open the file name `build`, and it turns out it is a directory. Reading from it would work, but it would return some "weird" from the user point of view who is expecting a text file. The solution to that would be to check the opened descriptor after every `open`, which makes this a bit heavy for the user program.
Plan 9 From Bell Labs was designed like that. The last change made to it was to add a `nsec` system call for tight timing, much to the annoyance of purists. :)
In the case of the Z80, even a μs granularity would be too low 😅 The syscalls context switch themselves already take hundreds of μs on Zeal 8-bit OS (on a Z80 running at 10MHz)
Is it the driver letter that reminds you of CP/M?😄 I thought about embedding the command line inside the OS, but that would have been too restrictive in my opinion, we would even be limited by the size. The kernel should not exceed 16KB (one MMU page). By making the command line a user program, this limit doesn't exist anymore. Moreover, this will also let anyone have its own startup program, maybe a GUI?
I think a general purpose BIOS that provides low level IO and load OSes from disk would also be a nice addition. Maybe I should do that as a pet project once I'm done with the C64.
@@atirutwattanamongkol8806 It's a good thing that you mention this! I have also written a small bootloader that handles loading programs/OSes from UART or ROM. It can also flash the ROM (as I am using a NOR Flash) from a file sent over UART, which can be handy and doesn't require an external flasher such as the TL866. I haven't published it yet but it's planned, just like the OS, it will be open-source, so that anyone can extend it or improve it. (Its main goal for me is to pre-flash it inside the few kits that I would like to sell soon)
hm probably this could be ported to c128 easy and burned 32KB(inside function) rom with it. It would be very nice if it would be cpm compatible so we can run some programs :)
The current version of the OS (v0.1.0), requires a virtual memory space organised as 4x 16KB pages. This is used to swap in and out kernel/programs RAM. It would be possible to add support for non-MMU computers (in exchange of adding limitation on the OS though) Making an OS natively compatible with CP/M has the disavantage of being too tied it in the syscalls, mapping, and drivers. In other words, it would be a CP/M clone. Thus another way to get its softwares to run on Zeal 8-bit OS would be to add an emulation layer around the softwares that would redirect/convert the syscalls to Zeal syscalls. Or, to port the software completely, but this requires the source code or a good amount of time to disassembly/reverse-engineer each 😅
Thanks for your comment! In theory yes, the goal of the OS is to be able to be ported to other machines. Currently, there is a requirement that the memory mapping is organized as 4 pages of 16KB. I couldn't find online if that's the case for the Z80-MBC2. Do you know if that's the case? In the future, I would like to add a No-MMU option that would let the OS be ported to more computers, without the need of the 4x16KB pages. Of course this will add some restrictions.
Would it be possible to load programs from an alien os, in such an instance, i would ask about cpc and their basic when it starts up, ie could it be converted to a base os underneath amstrads basic to run their software or could it load games directly ? Hard to word what i mean but i think i got the jist right
I would say there are three types of programs: - Binary programs: these are too tight to the hardware, porting them would be tricky as we would first need to reverse-engineer them enough to replace placed where hardware is touched. So out of the box, no they can't be run - Binary programs with source code: some old programs are now available with source code, I think about BBC Basic for example. These can be ported to Zeal 8-bit OS and thus executed. They need a bit of work. - Interpreted programs: like BASIC programs. There is currently no BASIC interpreter ported to the OS, but if someone does port one, it will be possible to execute a bunch of old programs.
Interesting choice for rom/kernel routines, useful at various levels. Most Z80 OS/BIOS/Kernel opt for CP/M, MS-DOS v1, MSX-DOS 1 route (all CP/M 2.2 compatible). Besides the VGA, Sound and SD-card in the (new larger) FPGA, is it possible to add some Maths/GPU routines into it, or is that not practical because its only accessible by memory map?. - Oh and what was the reason for dropping the second bus port, the one you previously used to hack in a RTC demo/proto?
Thanks for your comment! Indeed, I wanted to go a bit further than CP/M which is great honestly, but I wanted something a bit less restrictive in terms of file systems and modularity. This is why I went for the linux-like driver path. For the maths routines, if it's purely software, I see two possibilities: - You can make a driver for it, so that these routines are part of the kernel itself. Then the user programs would need to open/read/write/ioctl as if it was a device or a file. - You can make a library/binary that you embed inside the ROMDISK, which is a very simple read-only filesystem that resides in ROM/Flash. This is where the init programs and the commands resides at the moment. With this approach, it will not be part of the kernel, but still be part of the ROM and so, accessible by any program. There is currently no dynamic loader that lets user programs depend on dynamic libraries yet, but the user programs can still read your binary/library containing the math routines and load/copy it inside its address space. If it's a hardware FPU/GPU, you can connect it to the extension port and: - You can make a driver for it and let the user program communicate with it thanks to open/read/write/close. - Directly communicate with the hardware within the user program, so with out/io/ld instructions. That's not portable, but in any case that would require anyone wishing to use that program to have the same FPU/GPU hardware anyway, so it's not a big problem. That port was a debug port, it had all the signals from the CPU which was not the case of the extension port at that time. Since on the newest prototype the Extension Port has all the CPU signals, the debug port wasn't really useful anymore, it made the PCB routing much more complex too.
Oooooh also seeing a nano and vi/vim clone, port, whatever the term is, would be super cool. Eventually with Ethernet, WiFi, Bluetooth support being able to download nice, optimized apps with a tiny package manager from a server, use them, remove them, etc would be super duper cool. Ok more imagination tonight mb for all the words.
I know this may not be possible but, If you can, you should make a video going deeper into the os internals, stuff like how the graphics work and stuff like that
@@Zeal8bit yeah, that's true, also, I've been trying to do something similar but for an esp32, and I'm having trouble with making the terminal, how did you do it?
@@manuelhurtado9970 Do you mean you are trying to implement an 8-bit machine (emulator) in an ESP32? How are you implementing the terminal? On an external screen? UART?
Thanks for you comment! From what I see online, Zeta SBC uses the same memory mapping mechanism, it should work without a problem! I haven't found any emulator for that board though. If anyone is willing to have a try porting it, it would be great, I can help too 😄
alot of respect and admiration for your dedication and experience that you put into learning and sharing with us what you have learned. high five bro high five. well done
Technically it's possible! We would need to implement a video or serial driver for the output, a keyboard driver for input and a disk driver (ROM is possible too) If anyone has an MSX Machine and is interested by this project, I can help porting it!
Thank you for the video, realized so soon after the last one!!! Also thank you for explaining the conceptual essence! TBH I'm speechless after the video. It seems to me you are going the road PC had walked (and still do) - complicated systems that should be easy to use but end up complicated and only geeks understand, many abstraction layers, OS that works on every platform. So here is the problem - PC has the power to do so without penalty, because of the constant demand of faster hardware. Your project and in general all 8 bits systems are pretty static - no new monster CPU to hide the laziness of developers, no new GPU/SPU to take part of the CPU load, ... The more broader OS you create, the more layered it will became and thus more slower. Why people like 8bit? Nostalgia? Sure there is some part of that. But why it is attractive to young people? Simplicity - easy to understand easy to use, full control and direct access to the hardware. No abstractions, no layers, just Poke/Peek in the prompt and it works, you can see the result! No need to write a program at all, a program that syscall, then kernel, then driver, ... By saying this I don't want to discourage you. I believe that if a person has a vision of what to do, he should pursuit it to make it reality.
Thanks for your comment! That's a very interesting point of view and honestly I agree with most of your points. In my case, the main goal of an 8-bit computer is indeed to have a simple system that can be mastered by a single person, easy to use, full control over the hardware😁 At first, I wanted to design a system similar to what was on the ZX Spectrum or the Commodore 64: a prompt, a monitor, BASIC and that's it. And I did start with it, this is what I call today the "former system". Then the "problems" began: as soon as I wanted to read or write a file, it became very complex. How is a program, such as an assembler or BASIC, supposed to read a file? On Zeal 8-bit Computer, I have an 32KB I2C EEPROM, a 256KB ROM/FLASH and a uSD card slot which can theoritically accept any size of card. Each of them has its own file system. the uSD mus tbe able to read and write from a regular computer, so FAT12 or FAT16 is a must. The ROM doesn't need such a complex FS, it's read-only. The I2C EEPROM can't handle FAT16, it's too small. Then how to deal with these in the softwares? The assembler or interpreter I was talking about doesn't care at all about where the files will be stored to or read from, it only need a sequence of bytes and that's it. Thus, an abstraction was required. Of course, it would have been possible to have 3 different static libraries for that, but then, could a file from one storage be considered as the same as one in another (in terms of data structure) ? Not sure. Thus, this was my first motivation to make such OS: abstract the file systems, the files and the directories (I didn't talk about them, but it's the same pain) On the driver part, I also agree with you. They add an abstraction that alters the "pleasure" or direct access to the hardware. Or do they? The memory is not protected on Zeal 8-bit Computer, the programs can still directly poke the registers, the FPGA, the MMU, the PIO. Nothing prevents them from doing so. The drivers will, once again, give the programs/users a simple interface for fast prototyping. But, it is completely okay to bypass them. Yes, the programs would be target-dependent, but in case of veyr demanding games or demos, that's acceptable. Finally, for Zeal 8-bit Computer, I don't plan to "force" the usage of this OS. Any OS can be chosen, even no-OS/bare-metal! 😄
@@Zeal8bit I fully agree with what you said, and the way of thinking! (except IO files trough BASIC, asm, but that is not important). Especially "The drivers will, once again, give the programs/users a simple interface for fast prototyping." My concern is that you will spend so much time to develop excellent things and they will be used mainly as static libraries :D
Sorry I don't want to drag this, but lately on a Discord server for 8 bit so many new people jumped and in their intro they said something similar to that quote: "Always found older 8 bit systems interesting with how close you get to actually control the hardware but was born a bit late and poor (currently 29) and I didn't have any exposure to computers until the early 2000s so I haven't had any really a draw to a particular system to really try." And this is from 13 yo: "excited for XXXX not only because it provides a modern platform to tinker with that you don't get with a lot of modern hardware anymore"
@@SquallSf Thanks for the feedbacks! I agree with them, that's why I started Zeal 8-bit Computer project too: to work with the hardware directly. Regarding the (static) libraries in general, you can always drop them and poke the hardware directly. The way I see it is that all the pre-programmed libs/softwares are helpers that you can use, but not forced to use
Implementing a protected mode with such NMI mechanism brings a lot of overhead that makes it not really usable on a real project. Zeal 8-bit OS brings a software protection in the form of banked pages. The kernel RAM is mapped out when the user program is executing, so in theory, the user program doesn't have access to it (expect if the memory mapper is manually tweaked) A hardware protected mode would be much better with a CPLD where only parts of memory could be protected, defined at runtime
This is awesome work! Is there anything that would prevent this from running on one of the commercial Z80 implementations? E.g. the Sinclair ZX-81 or the SoftCard series for the Apple ][?
Thank you very much! At the moment, the OS requires a 4x16KB memory mapping. I know that the MSX2 computers have such mappings, so it would be possible to port it to them. For other computers like the ZX81 or ZX Spectrum, I would need to add support for no-MMU/no-mapper computers, which is possible in theory (it would bring limitations of course). I don't have a lot of time to have a try at the moment but if anyone is willing to have a try to port it, I can help 😄
Thank you! It can be ported thanks to the Hardware Abstraction Layer. I added a no-MMU feature which makes it usable to even more computers now, there is a small TRS-80 port as a Proof-Of-Concept. There is a developer from the community on Discord that started porting it to the Agon Light, you can join to follow the project
I'm totally impressed! Not just with software but having working hardware too. You made it look too easy :) I think it could have various benefits over existing systems. What do you think? Will it have practical use or basically stay an experiment? I think it could be used for network security or signal integrity checks, as it has very limited attack vector - beeing built that minimalistic.
Hello Alexander! Thanks for your heart-warming comment. It will have a practical use as it will be the official OS for Zeal 8-bit Computer. I plan on writing/porting the most basic softwares to it such as a text editor and an assembler. I hope it will not just be a proof of concept of course, but this will depend on its software library.
@@Zeal8bit I'm speechless! I think you're onto something very very huge. Having an easy to understand, completely open hardware, open software and open compiler is crazy. Never thought modern and understandable computing could be mentioned in one phrase.. One challenge will be to write the compiler in high-level language and get the same result as your machine code. This would very easily prove that your compiler actually works as intended (chicken-egg issue with compiler needing compiler to compile). I hope you see the huge potential. Just one idea: debugging an application including the compiler (make it possible to see the high-level language instructions but also the assembly code - or maybe even the high-level compiler code). This would make software development far more transparent. I hope more people can find you. I think there is a huge interest if you mention why this is so special. Why shouldn't IT education start with this? What about scientists, why should they use tools that are overcomplicated and impossible for them to understand? You could become what linux became to windows or what arduino became. It was a honor talking to you, sorry for the long text. I wish you all the best!
@@Zeal8bit I really don't know much about the Z80 but I am still impressed. I have just enough knowledge about these old 8bit systems to suspect that your OS probably wasn't coded using Java™ or .NET C# lol It's super cool how you guys are keeping these old systems alive and we can still learn from them.
On a similar note, it would be nice to see a port of Doom on it😂 Yes, the real joy is to be able to manipulate the hardware at our will, which is not something we can do that easily today anymore.
Just a recommendation. Consider dropping the build time supporting code. It's of no use other than permitting irreproducible builds from the same code .
With the discontinuing of the Zilog z80, do you have plans to use a Zilog ez80 Acclaim Plus? It can operate at up to 50 Megahertz and is triple pipe lined so you can have a logical clock speed of 150 megahertz if you write your Zeal 8 Bit OS to take advantage of it, although it is designed with a Z80 backwards compatible mode in mind.
Just posted a video short of the Zilog I-box prototype. I may have the only one! Cool story. Figured you may wanna look at it. Feel free to use the video or comment at me for more information. Ty
Impressive! It looks so smooth, too. Who would have thought that a humble Z80 chip could do so much? What made you go for a Z80 rather than, say an STM32 or RP2040; the greater technical challenge?
Thaks for your comment, it does run smoothly! Several reasons led me to start this project with a Z80: I could go for an STM32, ESP32, or RP2040, however, these are MCUs rather than CPUs. so they embed ROM, EEPROM or even RAM. They don't provide any access to the internal bus, where devices (UART, I2C, SPI, ...) are connected. They only provide pins for GPIOs and other peripherals. This means that we cannot extend their capabilities. Thus if an MCU has, let's say, 128KB of RAM, we cannot extend it on the address bus. Yes,we can add some SPI RAM, but this won't be mapped on the main bus in most cases. Another reason is that having only a CPU like a Z80 makes the computer a white box. As I also want this board to be an educational one for people willing to learn about hardware, seeing the actual chips that have a single purpose is much better than having one black box that does everything. Moreover, for repairing it's also better: for example, if the PIO, repsonsible for input/outpus, fails we can replace it without replacing all the computer. This is not the case with an MCU. If one of the MCU features fail, we have to get rid of the MCU and replacing it, even if 99% of other components are still working. Finally, the last reason is more personal, but I would like to proove that having GHz of frequency in a CPU doesn't mean that computer will be stable or better. The problem we have today is despite the fact that CPU are more and more powerful, softwares are also much more greedy in terms of memory and CPU power. We have traded coding time for higher CPU requirements. We take less time coding difficult things but it makes the CPU perform much more operations and need for RAM. As a small anecdote, when I run the Zeal Emulator I wrote in JS (available in the description), I cannot emulate the machine at full-speed. So my 4-core 2GHz CPU cannot emulate a 10MHz Z80 at full speed in a web browser. (Of course, I realize that a native application written in C/C++/Rust/... would be much faster, but when I see that most desktop applications today are written with Electron, with is just a hidden web browser, it makes sense to make this comparison)
@@Zeal8bit Thanks for your thoughtful reply. I'm always impressed when people are able to do great things with such humble resources. Keep up the good work! Best wishes to you.
Do you mean export it to a custom hardware or port it to a new hardware? To port it to a new hardware, you will need to create a new target in the project ("target" dir), write the drivers associated to it. You can check the details in the GitHub project. The current main requirement for all targets is to have a 4x16KB address space
Natively no, the OS has been written in Z80 assembly, so it will only run on Z80-compatible CPUs. But on 64-bit processors, you can have an emulator to execute it
What's my Fathers Next Project. Fix the Mac VM boot sequence. Computers Boot in order to detect Hardware changes. We don't Need that. Instead of booting, Suspend and Resume the VM like Hibernate. This Should Speed Bootup. This will require a Large Memory Copy. Also, include the Option of Restarting the VM, to refresh the Memory Copy. Long running Machines, Slow down and Need a Reboot.
Thanks for your comment! Indeed, it was a lot of work but also a lot of fun! How far did you go at that time? I mus thave been very difficult bak then, very few resources compared to today.
Thanks! I wasn't aware of the existence of (64-bit) ZealOS until 2 days before I publish my OS. At first I also wanted to name it ZealOS because my 8-bit computer is named Zeal 8-bit Computer, so it was an obvious choice. In order to reduce the confusion, I decided to add the "8-bit" emphasis in the name
@1:40 Im getting the idea this computer architecture is why There can be trouble emulating games Ps1 is 100% compatibility, ps2 has gaps in the library
hey you have gotten me inspired and i want to make something like this myself but i am wondering if there is any way to prototype (like emulate and build a schem or smth like that in a program) so i dont have to invest money straight away
I am glad you got inspired! When you say "something like this" do you mean an OS or a program? In any case, it's completely possible to prototype without the hardware. In my case, I made an emulator, as shown in the video, which has the most important features of my 8-bit computer. It's not 100% accurate but it's more than enough for prototyping. This is what I use everyday. Once I get my program working on the emulator, I test it on real hardware. In your case, if you want to prototype something for Zeal, you can re-use the emulator, it's open-source (check the description), if you mean you want to prototype on another 8-bit computer, check if you can find an emulator for it or you can make one yourself.
@@Zeal8bit when I say inspired I more mean I want to make an 8-bit computer myelf but don't know what a good program is for prototyping a schematic, although as you said I could write an emulator for it and go from there, anyway another question is do you have a discord server for the board
@@funkyegg3516 Oh for schematics and PCB I use Kicad. If you need to make some logic/circuit simulation, Logisim is pretty good. It's not an electronic simulator, but for logic gates/demux/mux functional simulations, it works pretty good. I created a discord, here is the link: discord.gg/UzEjwRvBBb
Did you mean "cat" ? "cat" can concatenate multiple files, this is not the case of my command which only takes a single parameter. It's not as advanced as the real less either, I should have named it "more"
I couldn't find any technical details about the memory mapping of the TI-84. Do you know where I can find it ? If it has the proper memory mapping, it should be okay
@@Zeal8bit There is flash rom and RAM, the TI-84 and TI-83 share a convoluted page system, but the TI-83 is more documented when it comes to memory mapping. I found a few websites with a TI-83 memory map.
I just found it, TI-83+SE and onward have "Memory Map Mode 0" which separates the memory into 4 pages of 16KB. The first one is fixed to flash (totally fine as it can contain the OS) and the three other can be mapped to RAM. From what I see, that's compatible!
I don't have any MSX machine, to try to port it. But if anyone is willing to have a try, I would be happy to help! From what I know MSX also has an MMU (Mapper), that divides the memory into 4 blocks of 16KB, so it should be compatible!
Hello, you will have to look for some specialized forum for your phone. Maybe someone lready tried to reverse engineer how th screen works? Maybe it is re-usable in a homebrew project?
Just-In-Time compilation? In which case TempleOS and ZenithOS use this? This is usually done on interpreted languages or bytecode binaries, like Java. Do you mean that assembler programs should be able to be assembled to binaries directly from Zeal 8-bit OS?
@@Zeal8bit I'm not an advanced programer, so I'm sorry if I'm just saying bullshit. But i believe TempleOS programs and kernel could be modified on the go without the need of compiling binaries, it's a kernel0 operational system, and all the code inside it is self described and you can change the kernel functions at any time without the need of recompiling the program or the operational system, it was made for x86 but it's based on commodore system
As ZealOS is a low level operational system, i believe you could may port something similar of what TempleOS creator used to make your CPU more advanced and intuitive to use, you probably need to change all the CPU calls to fit your needs but i believe it's a awesome idea because the versatility it has is absurd
Or at least, for me, your subscriber, i implore you you, when you are finished with your homebrew computer project, please, port your FPGA based GPU yo run on TempleOS, i believe it could run such amazing games, but the fact that it's mostly CPU-core dependent, it can't do much parallel computing... And it's creator it's dead so it's up to the community
Good morning Zeal .. I have a question. I have some old Grundy newBrains which, in my opinion, was a very nice machine at the time. Unfortunely the machines that were used in Angola were lost in time and now I am not able to make one for my museum .. I just saw your video and, eventually, you could be interested in pursuing that initiative and 1- modernize it 2- make the disk drives interface to it 3- eventually put it back in the market ... The machine used to have unique features and worked from the Bios as well as CP/M... Tell me something ... I would be interested in participating in the costs of some thing like this.
Hello! That looks like a very interesting project. I personally still have quite a lot of things to do on Zeal project. But I would be happy to hear more about it, you can join the Discord, some members can also help
I haven't tried but in theory, it should be possible if we configure the Z180's Common Area 0 to end at 0x4000 and configure the Common Area 1 to start at 0xC000. This will give 16KB for the kernel in Common Area 0, 16KB for the kernel RAM in Common Area 1 and give 32KB of bank area for the programs.
Develop a embbeded System based on the Chipset used by the iconic and legendary Matell Intelivision the First 16-bit Video Game Console and far before Nvidia a GPU in the Chipset/Platform. The Mattel Intelivision Chipset incl. 16-bit-CPU, a GPU and a Sound-Processor. Then add your own 16-Bit OS to this Platform....😎 Back in. the time The Video Game Console "Coleco Vision" Like the Arcade-Game Consoles used the Z80. Many facts of today came from the Matell Intelivision. First Voice-Output at Video Games. The technology of today is still based on Mattel's Approach. App Store where you can Download new Games, Edutainment, etc...
Porting Zeal 8-bit OS to another CPU would mean re-writing the whole OS as I wrote in Z80 assembly 😂 The Coleco Vision has good game library! Do you know if any of these games went open-source or resverse-engineered so that it could be ported to other Z80-based machines?
@@Zeal8bit Regardimg Open-Source or reverse-engineered Video Games you May have a better Chance at the Z80-based Sinclair Computers Like Sinclair ZX80, ZX81 and ZX Spectrum. Competitors to the Commodore C64 (Not Z80-based). All These platforms at the end Just ported Arcade Games onto their Consoles / Computers while Mattel Intelivision stays to be the Pioneer in many Cases incl. Adventure Games. All showed Arcade Games-like graphics on their diverse Game-Levels while the Mattel Intelivision Had endless Game-Levels thanks to it's 16-bit Platform, while graphics at the and makes a good Game a Genius gaming Idea Not better.
Thanks for the advice! It's just that the ZX Spectrum may not be the best good looking because of the attribute clash. But I will definitely check some.
@@Zeal8bit Hope the Platform you use does Not have the artefact of the ZX Spectrum... Attribute clash (also known as colour clash or bleeding) ...an artifact caused by limits in the graphics circuitry ... Another Z80-platform of the Golden 80s Amstrad-/Schneider-CPC. Also there a better Chance compared to the Coleco Vision. Finally the only survivor of the Golden 80s is the Pionier. Intelivision today as Intelivision Amico.
Salut, superbe projet Je suis impatient que tu le proposes a la vente. Qu'en est-il d'une case? Tu comptes en proposer? Peut-être une version amstrad cpc +++ ? Reprenant le cpc+ ?
Bonjour, merci beaucoup pour ton message! J'espère que je pourrai en mettre quelques exemplaires de Zeal 8-bit Computer à vendre sous peu. Une case c'est-à-dire un boitier? J'ai réalisé quelques prototypes (sans clavier, simplement un boîtier pour la carte mère) grâce à une imprimante 3D, mais cela reste des prototypes. Je pense qu'il serait possible d'en proposer mais pas dans l'immédiat.
![A new file system for Z80! [Zeal 8-bit Computer]](http://i.ytimg.com/vi/eCBCXIuRWl8/mqdefault.jpg)
![Twenty One Pilots - “The Line” (from Arcane Season 2) [Official Music Video]](http://i.ytimg.com/vi/E2Rj2gQAyPA/mqdefault.jpg)
Ooh, this takes me back! I spent most of the 1970s working on my own OS and toolchain starting in 1972 with the datapoint 2200, then moving to the 8080 and ending with the z80 on a home-brew computer. The Z80 "killer" feature for me was mode 2 interrupts as well as the support for DRAM refresh. I have fond memories of that time.
Anyway, best wishes for your project!
Mike (Someone born in the first half of the last century).
Thank you very much for your comment!
I am sure you understand my joy coding for the Z80 then! The mode 2 interrupt makes working with other Zilog products very comfortable indeed. I really like the amount of registers the Z80 gives, including the alternate set. I would have loved to see more Position-Independent instruction though.
I admit that today I don't think the DRAM refresh signal is very useful as we can find SRAM for fairly cheap (in small sizes of course), but I can imagine that this made a big difference compared to other CPUs back in the days.
I got a chuckle watching the beginning of this video. It described the EXACT state of personal computing in the mid 1970s when I entered the computer world. Even in the mid to late 70s when the Z80 was quite popular, every manufacturer put their hardware at different locations in the I/O or memory map, depending on the processor architecture you were using. You had to enter those addresses into your BIOS (basic input output system) to be able to locate the hardware. The CP/M operating system abstracted that a bit, providing a software BIOS (table) as part of the OS, so you only had to update that. No reprogramming ROMs, etc. CP/M (Control Program for Microcomputers) was an early OS that allowed using programs written for the Z80 to be used on different manufacturers computer systems. Even then, each manufacturer used a different proprietary floppy disk format (no hard drives yet that were cheap enough to be easily accessible to hobbyists). I had one whole floppy disc with nothing but a series of utilities to alter my computer to read floppy formats for other computer systems. Once read, a Z80 program would run on another Z80 based machine. Then I just had to reverse the process and save that program from memory to a disc that used MY system's format, so i could use it again in the future. Ah, the good old days.
The best thing IBM did was to create the IBM PC, arguably "a dependable Chevy" rather than "a screaming Porsche", as we had expected from the world's largest computer company. However, their two most important contributions did NOT include their hardware but were 1) standardizing the architecture for desktop (i.e. personal) computers and 2) providing the validity to industry (i.e. larger companies) for using desktop computers. Prior to that mini (one or more washing machine size) computers and mainframe (one or more room size) computers were the norm. A laptop computer... what was that? My first "portable PC" was a Kaypro "luggable", based on a Ferguson BigBoard Z80 based "all in one" board with memory, floppy drive interface, and other I/O on a single board. It had a 7" (or was it a 10") diagonal text-only screen, two 5-1/4" floppy drives, and a whopping 64K (yes, kilobytes) of memory. My main machine prior to this was also a Ferguson Big Board based homebrew system that took 1/3 of my desk, had dual 8" floppy drives and an LA-36 pedestal keyboard and wide carrage (132 characters?) printer combination, which evolved to a 12" monochrome (orange on black text) text-only monitor and full keyboard. These were my first "real" computers with more than a few kilobytes of RAM and a real operating system (CP/M). I already had some assembly language experience on the 6502 (Motorola architecture), and learned Pascal. BASIC, Forth, and C on the Z80 systems, as well as early text editor (Wordstar) and spreadsheet (Lotus 123) programs, and of course computer architecture. All this served me well in my electronics career, so I can't complain.
Times have certainly changed for the better, though. My wife and I burn through a laptop every 18 months or so now, so there are a dozen or more laying around or stored in boxes, and those are just the recent ones. I am a retired EE, and she is a degreed (MS) criminologist (focus on cybercrime) and computer security admin (CCNA)... turned realtor.
My desk now has 2 laptops with additional screens, an adjacent work area with various small single board computers on it, a soldering/rework area, and a small ham radio area. Everything in sight has one or more processors (most with multiple cores) running them. Yep, I have seen quite an arc in computer development, since I first took an AAAS degree in a new area of electronics some people believed would be the new direction of electronics. It was called "digital" electronics. My initial training was as an RF tech, operating and repairing microwave transmitters, receivers, and frequency division multiplexers that used discrete transistors in all-analog circuitry. The idea of digital control of RF equipment was not even taught in my military electronics courses in the USAF. Yep, a lot has changed.
Phew! Saved me a lot of typing to say the same (generally speaking!)
Thanks!
You're living history my friend!! ❤
I coded in 8080 and Z-80 Assembly in my youth. This is very good work! All good wishes.
Thank you for your support, Z80 never gets old!
NASA used Z80 processors in their Voyager spacecraft, now in interstellar space, still operational (most instruments shut down to low power available) at 45 YEARS+.
@@Zeal8bit Old pre-Internet computers, where Internet security didn't ruin the fun.
Z80 assembly on a TI-84 gave me migraines more than anything I've ever done but I still managed to make a few things in my youth. Good times!
@@paulmoffat9306 erm, no. The Voyager craft we launched in 1977, not long after the Z80 was created and far too soon to be used in spacecraft. It uses 18 bit CPUs built from TTL logic as was common pre the single chip microprocessor.
you're crazy man. Writing a complete kernel in just assembly is just......
Haha, thanks, I guess so! 😂
More seriously, programming in assembly is not that hard, you only have to think in assembly and not in C or any higher programming language. It's a habit that you get.
In fact it's the same for all the languages, for example, trying to write imperative code in functional programming won't get you far, you have to think functional.
@@Zeal8bit yeah I know, I studied Assembly in school for like 6 months. But I'm saying that in a Kernel you must handle an infinite number of things to make it work good. I created a simple one but in C, I did only the bootloader in Assembly
@@bridiro You're right, this is why I tried reducing the number of features to only include the most important ones at the moment
@@Zeal8bit but still you're crazy (in a good way). I truly admire you
the word is, "Admiral"
thats the name of the OS!
This blew me away, I remember tinkering with the Z80 in the early eighties, it was fun back then, but never did we think of making an entire OS!
You have made a modern style OS, color me impressed!
Thank you very much!
Z80 assembly is still very fun in my opinion, I still have a lot of ideas I would like to implement
@ipadista: Forgot CP/M? Or UTF-DOS, etc. There were also multiuser systems based on the Z80, even a minimalist Unix clone iirc. Not to mention all the real time operating systems for it, some of them with preemtive multitasking.
@@herrbonk3635 All the Z80 computers i played with were "BASIC computers", zx80/spectrum/ABC80/ABC806 etc booting straight into a Basic env, sure in principle you could call it an OS. There were some very basic tools to interact with cassette tapes mostly "load" and "save" programs. But no actual file system. At that time I never heard about CP/M. I became aware of it a couple of decades later as a historical curiosity. We did play with asm to some extent, but typically for very specific tasks like trying to optimize sort algorithms.
took a while, finally got here
by traveling back in time...
no more industry secrets! just outdated information 😅
It is an operating system, just a very simple one by comparison to today's behemoths.
In the 80's one of my first projects was to build a small computer based on Z80. It included: Z80, UVROM memory, RAM memory, PPIO, 8279 chip to manage a small keyboard and 7 segment displays, reset Push button, and so on. All the chip terminals wire wrapped, with 30 gauge wire. The software, a state machine to manage the hardware, was developed on HP emulator system and written in assembly language ...
Nice! Was it for professional purposes? How far did you go with the project?
Impressive. A mix of what was learned of the years, i.e. abstracting from the hardware to let your program focus on doing its thing.
Right! It's also hard to find the limit and stop abstracting too much, else we lose the purpose of 8-bit computers.
But for example, when you write a text based program, you surely don't want to manage screen printing and scrolling manually. Similarly for disk management, so having an OS is great for that 😄
Guess it is a balance of letting the low level code handle the hardware and the high level code do the program stuff like a data base or game, but that is easier said than done.@@Zeal8bit
Yes exactly! Mainly for graphics, it'll be hard to abstract it an have a common API
That would depend on the degree of abstraction and whether your API is a high or low level one.
BASIC's 'PLOT X,Y' command is an API of sorts and provides some degree of abstraction. You can give a "screen" location in X,Y coordinates and it will draw a dot/pixel for you, maybe even in color if your BASIC implementation supports that.
You don't need to know anything about the display generation, video memory location, how pixel data is represented memory, etc.
@@jnharton You're right, but in practice, even this API is not 100% portable. On Zeal 8-bit Computer, you cannot plot a single pixel natively, the graphics are tile based.
I like how allmost everything is basicly a file in ZealOS or could be accessed as such. Working on a Rabbit 2000 based SBC, z180 done well on steroids but very different from a hardware/interface perspective due to it's glueless design mantra, looking forward to eventually trying out that hardware abstraction layer some time later this year. ;)
Thank you! Having opened files as the most basic entity is something I love on Linux, so I wanted to have the same thing on Zeal 8-bit OS.
Correct me if I am wrong but the Rabbit 2000 may not implement all Z80 instructions, if that's the case, the OS may need to be patched or corrected. In any case, feel free to try porting the OS, I can help if you have any question.
@@Zeal8bit Yeah a few, notably in/out. To access I/O space you prefix an ld instruction to specify internal or external I/O space for example.
The biggest question imho will be if/how-well z88dk supports it I think, or how readable that codebase is for me to add support if it doesn't
Thanks for the offer, when I get the cpuboard done and I can start porting it over I'll send you message. At the very least so you can look at the crazy thing I designed. :)
I am currently designing a multiprocessor computer on the Z280, I want to try to install this OS. Is it possible?
bruh, amazing work, so proud for you
Thank you very much for your support!
This is so cool! I haven't done much Z80 stuff this year, but I'm hoping to get back to it ^~^
I have a few programming languages I could try to port, I have a floating point library, too, which might be useful for a calculator (I come from the world of Z80 calculator programming).
Thank for you comment!
Which programming languages are you interested in? I would love to see softwares on Zeal 8-bit Computer (and Zeal 8-bit OS)!
Did you use to program on the TI-83/4 calculators?
@@Zeal8bit I used to code for the 83+/84+ (still do occasionally) and I got into the habit of making my own interpreters to make code more compact (at the time, we didn't have an easy/safe way to modify 0x0000-0x4000). I have one super convoluted interpreted language that occupies 32KB of ROM (2 16KB banks used, only one needs to be loaded at a time). It is the one I "completed" but the code is very ugly, unfortunately :| (both the parser and the input)
I have other "bytecode" interpreters that I've used in RPGs for scripting and I vaguely modeled them after assembly, but never wrote a compiler for them, so you had to hand-calculate the bytes. I did have assembler macros to help, though.
I have a parser that was heavily inspired by postscript that is actually decent in my opinion (in terms of organization, readability, and ease of use), but still very underdeveloped. I was able to make games though!
I have an ambitious language that kind of works, but is buggy and, again, underdeveloped. That one has a bunch of variable types planned and is loosely inspired by python and other languages. It was meant as a TI-BASIC alternative that was faster and better for games and better at math, while still being easy to use for math, science, and engineering folks who are not dedicated programmers. Most of the math is there, but only for a handfuls of float and int formats (I think 80-bit and 32-bit floats, 8- and 16-bit ints)
I don't think I can post links here, but I'm /Zeda on GitHub and have some of my projects there.
Grammer2 is the "completed" one
Parsnip is the "ambitious" one
And apparently I never put toastscript anywhere :( that one has basic floats and ints, but is also the only one that properly supports user-defined functions :( it's also the most compact one, even with the floating point routines and all of the "graphics driver" and keyboard driver code compiled with it, I think that's all around 4KB
@@ZedaZ80 Nice, I am going to check this now!
I guess that in the case of your bytecode VM you could imagine developing and compiling on a host computer before transferring the resulted binary to the target (calculator). That would be easier than hand-calculating the instructions😄
Regarding your two other projects and their parsers, do you usually make a "hard-coded" parser that is language-dependent or do you take a more generic approach with a lexer, tokens and an AST, like what yacc and bison do in C?
I am also interested in writing parsers, interpreters and compilers. I usually do this for my x86_64 host computer, I haven't written any in Z80 yet. I started writing a Z80 parser and assembler in Z80 but didn't have time to finish it since I had to move forward on the motherboard hardware. I would like to finish it though and embed it in the OS' user romdisk.
Ideally in a further future, if time allows, I would love to write an interpreter for a modern scripting language like Lua
@@Zeal8bit I'm not fully sure what you mean, sorry! (I don't have any kind of formal education in CS, so I often do things without knowing the words.)
The parsers are designed for the language, though for the handful of times I've written an actual compiler, I do all the the tokenizing, generating an AST, optimizing the AST, and then emitting code, if that makes sense. But those have always been done on separate machines, I had started working on it for the Z80, but abandoned that :P
If it's like assembly, then the tool would be more of an assembler than a compiler, afaik.
That's because it would mostly be a direct translation from mnemonics to opcodes and turning any parameters into whatever number format the bytecode interpreter expects.
Unlike a language such as C, you aren't really converting the languge into something else entirely.
I'm so curious.
I entered the tech industry before general-purpose operating systems existed. BASIC wasn't even invented yet, and the "internet" was just a loose network of computers linking a few universities.
I can't describe how nice it is to work within modern systems, like being able to create an entire virtual machine within seconds, launch it, and begin developing within it, using any number of a variety of programming languages, command line, or RAD - your choice, with editors that will assist you with syntax highlighting and code-completion.
This is hugely more convenient, to say the least, than key-punching FORTRAN code into a bunch of card stacks (1 line per card, 2000 cards, ~15 lbs. per box), delivering said stack or stacks to the computer operator, (guaranteed to be in a physical location far away from the keypunch and collators), waiting a week hoping for the best, receiving the output on like 50 lbs. (or more) of fan-folded line-printer paper, debugging, then repeating the cycle until the output matches expectations.
I notice an undeniable resurgence in interest with our old hardware and software, where young people are "discovering" value in the crap we chewed our arms off to improve and leave behind.
I suppose if you were raised enslaved to the console as the pioneers in this industry were, escaping meant no looking back for us. Why would we ever want to? Because to us, those inconvenient technologies were merely a means to an end, and we still have a lot of work to do.
I look to the future, building it on the experiences of the past, so having actually lived it, perhaps it's a bit of a mystery for those to whom these are merely "historical events".
The curious ones appear to be looking at the old 8-bit stuff with a lot more than passing interest, maybe wondering how we got along with such primitive systems?
I look at that old stuff (glancing at my retired, yet functional classic IBM PC-XT and CGA monitor, with its DIP switches, huge ONE MEG of RAM, and text-scrolling that I could nearly type as fast as) and think "thank God that's over with".
I think I'll go spin-up a Proxmox server and connect it to my proxy in the UK. Now where did I put my Atari 800? (Yeah, right!)
Thank you, algorithm
Haha thanks!
Yeaahh ☺️ GoodJob Bro for your Z8 OS opensource 👍
Thank you very much!
Hope for Z80 based machines on the desktop)
Haha, one day maybe, with 2 or 4 Z80 running at the same time
That would certainly be an interesting thing to see in an FPGA or ASIC, especially if you could make it relatively efficient.
Forget those dang Intel chips, let's make an 8-core Z80!
Top of the line, best of breed, 8-bit computer design! Zeal-8-Bit OS is going to be big for the community across multiple platforms!
Thank you very for your (long) support! 😀
Amazing. Thank you. Will test this asap
I think you should produce a version which, given a system running CP/M, loads your new OS from a disk file, which when executed leaves the user with your new OS rather than CP/M.
That's a good idea actually! It theory we would "only" need to read the binary executable thanks to CP/M and copy it inside address 0 before jumping to it. That's something to test.
awesome work, much more professional than what could usually be expected by a hobbyist! well done
Thank you very much for your comment!
I guess my professional experience influenced me on that project 😄
I've aways had a soft spot for Z80 assembly!!!
You have good taste then! 😄
Looks like I am late to the party.
The only thing I can contribute, is that the original couple of versions of MS DOS is open source. While it will be for different processors and the like, it might hold some bits that could be useful to you.
Excellent work, and kudos for making it in assembly.
Thanks for your long-time support!
It's never too late to join the party. There are still a lot of things left to do, mainly on making or porting software, your experience is valuable.
You can join the Discord if you want to talk about the project 😄
@@Zeal8bit I have no experience in that field. I just happen to know that old DOS source code is now open source.
I just did a quick check, and it is version 1.25 and 2.0. It was placed on GitHub in 2018, under an MIT license. So it means - as I understand it - that you can take the code, and modify it for your project.
For me to be of any use to your project in this manner, I would have to have an 8-bit Computer and be doing some sort if programming myself, to get to grips with it all. And I don't have that, I'm afraid.
But I certainly want this project to succeed, as I think it is going to have some significance down the road. This could end up being a useful educational tool for students, which alone would be wonderful.
You made I great job, maling alive one of the most popular processors. It is one of my essentials for my doomsday library!
Thank you very much for your support!
Next step: make it better with even more softwares 😄
The coolest TDM OS I used was PCMOS386 by Symlink Inc.
If you typed in an unrecognised command or did a typo, it would respond with: "What?"
Too cool for Skool...
I also saw that is TinyBASIC I think 😄 That's not very hard to add this feature
And now, let geniuses port "Doom" on Zeal. :)
Oh waw, that would be awesome! A lot of things would need to be modified though 😄
Memories resurfaced... i was poor and had only own ZX-81 in about 1992-1993, with knowledege from other computers i naively dreamed of mutlitasking OS for it,
i have some "in head projects" but i failed in attempts to take over interrupts without modification of hardware. I'm really envy you.
Even if a lot of people like to criticize the ZX80 and ZX81 because the standards they have today, I am convinced these two computers meant a lot to many people, they made computer science available for anyone.
It's never too late to start new projects 😉
Maybe you can have a try implementing a cooperative multitasking OS
very well made, hope you get some support to enhance
Thank you! Anyone is welcome to contribute😄
@@Zeal8bit Sadly like so many other's ... I have my own "project" and time is limited. The good thing is, you can always learn from each other and that's why I like to watch Zee80 project's.
Fascinating! Can’t wait to dig in.
Thanks for your comment, don't hesitate to take a look at the source 😄
Impressive work!
Congratulations! :>
Thank you very much!
What I would like to see is a video on the MMU, mostly because there aren't many (any?), but also to show why you chose the particular layout you did over more traditional CP/M style layout, like the one chosen for CP/M 3, or the 32k upper/lower layout which you first had and is common in some CP/M (Z80) retro devices but is usually limited to 16 pages, and how that is different (or the same) as say the NES Mapper (8KB pages?). Also why you chose "MMU" over "Mapper" (which I believe are the same in the context of this project).
How you use the (current) MMU in code, an why the needed to add ability to read the MMU device in the latest PCB layout.
NOTE: the new (current) MMU layout equates to a certain "Mapper" type used in MSX (16KB pages, any slot, 4MB max), sorry I cant remember what it is exactly (ASCII16?).
Basically yes, it's a Mapper, I call it MMU because that's the generic way to call it on modern MCUs and SoCs.
As you guessed, the current implementation is similar to the MSX Mapper: 4 virtual pages of 16KB which can be mapped to any 16KB window of the physical 4MB of address space.
So in the beginning, the memory mapping was fixed, the first half was ROM, the second half was RAM, with one 16KB bank is each half. That was easy to implement in hardware but was way too restrictive. In fact, it was not possible to port CP/M because of this because CP/M requires RAM in the first part of memory.
In fact, I don't like the way CP/M maps the memory, having RAM in the first memory addresses makes it hard for boot. Indeed, as the Z80 starts executing code at address 0, it means that upon boot, we need ROM here, which will setup CP/M and switch the first part of the memory for RAM instead of ROM.
This is why I decided to split the memory in 4 pages which can be swapped around at our will. Thanks to this, we can port pretty much any Z80 OS on Zeal 8-bit computer. Moreover, Zeal 8-bit OS takes advantage of this as everytime a user program is loaded, the kernel's RAM page is swapped out, kind-of "protecting" it from spurious writes.
To swap in and out the pages, as single OUT instruction is required, for example, to make the first 16KB page point to the physical address 0, I only need to execute:
ld a, 0
OUT (PAGE_0_ADDR), a
, if I want to point to physical address 0x4000, I only need to change ld a, 0 to ld a, 1
etc...
Why reading the MMU/Mapper configuration is important? Let's take the example of Zeal 8-bit OS video driver.
When we are executing a user program, the first 16KB page is the Kernel code, the second, third and fourth pages are User Program RAM. As soon as the program performs a write to the video driver (print for example), the kernel will switch the last page to kernel/driver RAM. So, as soon as we enter the video driver, the first page and the last page cannot be swapped out because they are in use by the driver. But we still need to map the VRAM somewhere to write to it, how to do? The solution is to temporarily map VRAM to a page pointing to user memory (second and third page), but after we finish writing to VRAM, we need to switch back the memory page to the value it was originally mapped to!
Thus, having a way to read back the configuration is necessary.
In fact, it would be possible to get rid of the hardware buffer and have a "mirror" in RAM that stores what page is mapped to which address, in software. But it means that any program that would want to swap pages would strictly need to go through the kernel or the routine that would update that mirror. Else, we would have unsynced data between hardware and software, I wanted to avoid that.
@@Zeal8bit So how did you implement the mapper hardware-wise? I couldn't readily find the answer in one of your videos.
@@kilianhekhuis I explained it a bit in the video presenting the latest prototype I think.
In short, I am using two 4x4 bits register files, so it makes a 4 bytes SRAM. At each memory read performed by the Z80, I take the highest 2 bits of address which becomes the index of the value to read form this small RAM. The outputted 8-bit value represents the highest 8-bit of the physical address, so we get a total of 16-2+8=22 bits of address.
In order to be able to read back the value of any of the 4 bytes, I had to add an octal buffer (74HC541)
@@Zeal8bit cool, thx. I have considered something like that for my initial design, but I want sure this was feasible. My current design (I'm making an FPGA CPU) just uses 20-bit addresses.
@@kilianhekhuis Which CPU architecture are you making in your FPGA?
Great idea! But something is missing - this is extended addressing, de facto only 64Kb is available, but if you correctly monitor some undocumented commands on the data bus using a microcontroller, you can expand the address range without using page addressing.
Thanks for your comment. Can you give more details about what you mean for the undocumented information?
I did have a thought about using an external instruction decoder to extend all the Z80 registers, but that was almost equivalent to redesigning a Z80...
Z80 is beyond iconic. Great work, sir! 🎉
Thanks a lot !
Long live the Z80!😄
Wow ... I really miss the old days, where 6809EP's, 6502's, and these Z80's were - in a way - much easier to program, than the colossal and bloated modern bits ... not like the old monitor programs and Borland C days ... Good going with your efforts. Thanks ... Subscribed ... Cheers ...
These old 8-bit computers are a pleasure to work on! The specification and manual is so simple, no cache, no pipeline, it's deterministic! 😄
Thank you for your support!
Hmm.... I would recommend putting your syscalls side-by-side with traditional Unix/Linux syscalls. You might find some more efficiencies that you can gain. For example, gettime/settime are "read/write" to the clock device, readdir is open and read from a directory file, and so on...
Linux does have a syscall for clock_gettime, clock_settime, opendir, readdir, etc...
I did consider having only open/read/write/close for almost all features, but this would bring less "typing" to the code and almost less performance in some critical cases. For example, the gettime syscall can be redirected very quickly to the timer driver instead of going through the VFS and driver layers.
However, gettime should not be too slow, else the returned value may be already outdated when the user program receives it.
I would like to note that it's still possible to open the clock and timer drivers (if they don't register themselves as hidden) with open, and perform ioctl without using the gettime/settime syscalls. Of course, you would still need to know the name of the driver to open it, which is not the case with gettime/settime/getdate/setdate.
Finally, having an all-in-one syscall for directories would be possible but somehow confusing. Imagine you want to open the file name `build`, and it turns out it is a directory. Reading from it would work, but it would return some "weird" from the user point of view who is expecting a text file.
The solution to that would be to check the opened descriptor after every `open`, which makes this a bit heavy for the user program.
Plan 9 From Bell Labs was designed like that. The last change made to it was to add a `nsec` system call for tight timing, much to the annoyance of purists. :)
In the case of the Z80, even a μs granularity would be too low 😅
The syscalls context switch themselves already take hundreds of μs on Zeal 8-bit OS (on a Z80 running at 10MHz)
9:20 I didn't expect to see CP/M combined with UNIX. AFAIK even MS-DOS uses a built-in command line interpreter and not a user defined program.
Is it the driver letter that reminds you of CP/M?😄
I thought about embedding the command line inside the OS, but that would have been too restrictive in my opinion, we would even be limited by the size. The kernel should not exceed 16KB (one MMU page).
By making the command line a user program, this limit doesn't exist anymore. Moreover, this will also let anyone have its own startup program, maybe a GUI?
> Is it the driver letter that reminds you of CP/M?😄
Yup.
I also initially forgot that this is running from ROM unlike CP/M or MSDOS.
@@atirutwattanamongkol8806 Yes, executing from ROM was my first requirement. I really didn't want to drop it
I think a general purpose BIOS that provides low level IO and load OSes from disk would also be a nice addition. Maybe I should do that as a pet project once I'm done with the C64.
@@atirutwattanamongkol8806 It's a good thing that you mention this! I have also written a small bootloader that handles loading programs/OSes from UART or ROM. It can also flash the ROM (as I am using a NOR Flash) from a file sent over UART, which can be handy and doesn't require an external flasher such as the TL866. I haven't published it yet but it's planned, just like the OS, it will be open-source, so that anyone can extend it or improve it.
(Its main goal for me is to pre-flash it inside the few kits that I would like to sell soon)
hm probably this could be ported to c128 easy and burned 32KB(inside function) rom with it.
It would be very nice if it would be cpm compatible so we can run some programs :)
The current version of the OS (v0.1.0), requires a virtual memory space organised as 4x 16KB pages. This is used to swap in and out kernel/programs RAM.
It would be possible to add support for non-MMU computers (in exchange of adding limitation on the OS though)
Making an OS natively compatible with CP/M has the disavantage of being too tied it in the syscalls, mapping, and drivers. In other words, it would be a CP/M clone.
Thus another way to get its softwares to run on Zeal 8-bit OS would be to add an emulation layer around the softwares that would redirect/convert the syscalls to Zeal syscalls. Or, to port the software completely, but this requires the source code or a good amount of time to disassembly/reverse-engineer each 😅
Oh, great work 🤩
Thank you very much!
I hope you are able to release this computer in both kit and finished form.
Thank you for your message! Actually that's my plan, I hope I will be able to release soon 😁
@@Zeal8bit This will be a most positive development. I hope it becomes a success for you.
@@horseradishpower9947 Thank you for your long-time support!
This is amazing. Well done. Thank you for a great video!
Thank you very much for your comment!
I only vaugely understood some of this, but find it fascinating nonetheless
Thank you! If you have any question, don't hesitate to ask
That's just awsome!
Thank you ! 😄
Really cool project. New sub here. :) Is this os will be possibly ported to another 8-bit systems? example: z80-mbc2?
Thanks for your comment!
In theory yes, the goal of the OS is to be able to be ported to other machines. Currently, there is a requirement that the memory mapping is organized as 4 pages of 16KB. I couldn't find online if that's the case for the Z80-MBC2. Do you know if that's the case?
In the future, I would like to add a No-MMU option that would let the OS be ported to more computers, without the need of the 4x16KB pages. Of course this will add some restrictions.
@@Zeal8bit Iam not sure, doc says: 128KB banked RAM
Fantastic work! I look forward to your future work!
Thank you very much, there are still more to come!
Very nice job. Congratulations!
Thanks a lot!
Thia is just well...COOL!
Thank you !😄
Would it be possible to load programs from an alien os, in such an instance, i would ask about cpc and their basic when it starts up,
ie could it be converted to a base os underneath amstrads basic to run their software or could it load games directly ?
Hard to word what i mean but i think i got the jist right
I would say there are three types of programs:
- Binary programs: these are too tight to the hardware, porting them would be tricky as we would first need to reverse-engineer them enough to replace placed where hardware is touched. So out of the box, no they can't be run
- Binary programs with source code: some old programs are now available with source code, I think about BBC Basic for example. These can be ported to Zeal 8-bit OS and thus executed. They need a bit of work.
- Interpreted programs: like BASIC programs. There is currently no BASIC interpreter ported to the OS, but if someone does port one, it will be possible to execute a bunch of old programs.
Interesting choice for rom/kernel routines, useful at various levels. Most Z80 OS/BIOS/Kernel opt for CP/M, MS-DOS v1, MSX-DOS 1 route (all CP/M 2.2 compatible). Besides the VGA, Sound and SD-card in the (new larger) FPGA, is it possible to add some Maths/GPU routines into it, or is that not practical because its only accessible by memory map?. - Oh and what was the reason for dropping the second bus port, the one you previously used to hack in a RTC demo/proto?
Thanks for your comment!
Indeed, I wanted to go a bit further than CP/M which is great honestly, but I wanted something a bit less restrictive in terms of file systems and modularity. This is why I went for the linux-like driver path.
For the maths routines, if it's purely software, I see two possibilities:
- You can make a driver for it, so that these routines are part of the kernel itself. Then the user programs would need to open/read/write/ioctl as if it was a device or a file.
- You can make a library/binary that you embed inside the ROMDISK, which is a very simple read-only filesystem that resides in ROM/Flash. This is where the init programs and the commands resides at the moment. With this approach, it will not be part of the kernel, but still be part of the ROM and so, accessible by any program. There is currently no dynamic loader that lets user programs depend on dynamic libraries yet, but the user programs can still read your binary/library containing the math routines and load/copy it inside its address space.
If it's a hardware FPU/GPU, you can connect it to the extension port and:
- You can make a driver for it and let the user program communicate with it thanks to open/read/write/close.
- Directly communicate with the hardware within the user program, so with out/io/ld instructions. That's not portable, but in any case that would require anyone wishing to use that program to have the same FPU/GPU hardware anyway, so it's not a big problem.
That port was a debug port, it had all the signals from the CPU which was not the case of the extension port at that time. Since on the newest prototype the Extension Port has all the CPU signals, the debug port wasn't really useful anymore, it made the PCB routing much more complex too.
Incredible stuff. This is incredibly interesting.
Thank you very much!
Very impressive! Nice work 👍🏻
Thank you very much!
Can we port this to TRS-80 Model 4?
trs80gp is a good emulator for testing on
I ahven't tried, I am not very familiar with it but if anyone wants to have a try, I can help and give more details about the OS implementation 😄
Was your less working like cat or more, or a genuine less program?
At the moment it looks more like a single-parametered "cat" indeed, I should rename it to "cat" or "more"😄
Oooooh also seeing a nano and vi/vim clone, port, whatever the term is, would be super cool. Eventually with Ethernet, WiFi, Bluetooth support being able to download nice, optimized apps with a tiny package manager from a server, use them, remove them, etc would be super duper cool.
Ok more imagination tonight mb for all the words.
You mean something like this: github.com/Zeal8bit/Zepto ? 😉
@@Zeal8bit geez! Yes! Beautiful! Ok next challenge! A gui and a clone of Abiword and of Kate 🤣 😜
nice work ..
Thank you!
I know this may not be possible but, If you can, you should make a video going deeper into the os internals, stuff like how the graphics work and stuff like that
That's possible, not sure if a lot of people would be interested but that's possible! 😄
@@Zeal8bit yeah, that's true, also, I've been trying to do something similar but for an esp32, and I'm having trouble with making the terminal, how did you do it?
@@manuelhurtado9970 Do you mean you are trying to implement an 8-bit machine (emulator) in an ESP32? How are you implementing the terminal? On an external screen? UART?
@@Zeal8bit no, I mean I am making a computer with basic, and a Dos based on a esp32, it has a vga connector, ps/2 port and SD card slot
This looks really cool, could this work on the Zeta SBC?
Thanks for you comment!
From what I see online, Zeta SBC uses the same memory mapping mechanism, it should work without a problem! I haven't found any emulator for that board though.
If anyone is willing to have a try porting it, it would be great, I can help too 😄
오진다. ㅋㅋㅋ
GOOD
감사합니다!
That is awesome. 😀😀😀
Thank you !😄
Great work!
Thank you very much!
alot of respect and admiration for your dedication and experience that you put into learning and sharing with us what you have learned. high five bro high five. well done
Thank you very much, it means a lot!
It ll run ina real Z80 MSX machine ??
Os need to rewrite drivers ??
Technically it's possible! We would need to implement a video or serial driver for the output, a keyboard driver for input and a disk driver (ROM is possible too)
If anyone has an MSX Machine and is interested by this project, I can help porting it!
Thank you for the video, realized so soon after the last one!!! Also thank you for explaining the conceptual essence!
TBH I'm speechless after the video. It seems to me you are going the road PC had walked (and still do) - complicated systems that should be easy to use but end up complicated and only geeks understand, many abstraction layers, OS that works on every platform.
So here is the problem - PC has the power to do so without penalty, because of the constant demand of faster hardware. Your project and in general all 8 bits systems are pretty static - no new monster CPU to hide the laziness of developers, no new GPU/SPU to take part of the CPU load, ... The more broader OS you create, the more layered it will became and thus more slower.
Why people like 8bit? Nostalgia? Sure there is some part of that. But why it is attractive to young people? Simplicity - easy to understand easy to use, full control and direct access to the hardware. No abstractions, no layers, just Poke/Peek in the prompt and it works, you can see the result! No need to write a program at all, a program that syscall, then kernel, then driver, ...
By saying this I don't want to discourage you. I believe that if a person has a vision of what to do, he should pursuit it to make it reality.
Thanks for your comment!
That's a very interesting point of view and honestly I agree with most of your points. In my case, the main goal of an 8-bit computer is indeed to have a simple system that can be mastered by a single person, easy to use, full control over the hardware😁
At first, I wanted to design a system similar to what was on the ZX Spectrum or the Commodore 64: a prompt, a monitor, BASIC and that's it. And I did start with it, this is what I call today the "former system". Then the "problems" began: as soon as I wanted to read or write a file, it became very complex. How is a program, such as an assembler or BASIC, supposed to read a file?
On Zeal 8-bit Computer, I have an 32KB I2C EEPROM, a 256KB ROM/FLASH and a uSD card slot which can theoritically accept any size of card. Each of them has its own file system. the uSD mus tbe able to read and write from a regular computer, so FAT12 or FAT16 is a must. The ROM doesn't need such a complex FS, it's read-only. The I2C EEPROM can't handle FAT16, it's too small. Then how to deal with these in the softwares? The assembler or interpreter I was talking about doesn't care at all about where the files will be stored to or read from, it only need a sequence of bytes and that's it. Thus, an abstraction was required. Of course, it would have been possible to have 3 different static libraries for that, but then, could a file from one storage be considered as the same as one in another (in terms of data structure) ? Not sure.
Thus, this was my first motivation to make such OS: abstract the file systems, the files and the directories (I didn't talk about them, but it's the same pain)
On the driver part, I also agree with you. They add an abstraction that alters the "pleasure" or direct access to the hardware. Or do they? The memory is not protected on Zeal 8-bit Computer, the programs can still directly poke the registers, the FPGA, the MMU, the PIO. Nothing prevents them from doing so. The drivers will, once again, give the programs/users a simple interface for fast prototyping. But, it is completely okay to bypass them. Yes, the programs would be target-dependent, but in case of veyr demanding games or demos, that's acceptable.
Finally, for Zeal 8-bit Computer, I don't plan to "force" the usage of this OS. Any OS can be chosen, even no-OS/bare-metal! 😄
@@Zeal8bit I fully agree with what you said, and the way of thinking! (except IO files trough BASIC, asm, but that is not important). Especially "The drivers will, once again, give the programs/users a simple interface for fast prototyping."
My concern is that you will spend so much time to develop excellent things and they will be used mainly as static libraries :D
Sorry I don't want to drag this, but lately on a Discord server for 8 bit so many new people jumped and in their intro they said something similar to that quote:
"Always found older 8 bit systems interesting with how close you get to actually control the hardware but was born a bit late and poor (currently 29) and I didn't have any exposure to computers until the early 2000s so I haven't had any really a draw to a particular system to really try."
And this is from 13 yo:
"excited for XXXX not only because it provides a modern platform to tinker with that you don't get with a lot of modern hardware anymore"
@@SquallSf Thanks for the feedbacks! I agree with them, that's why I started Zeal 8-bit Computer project too: to work with the hardware directly.
Regarding the (static) libraries in general, you can always drop them and poke the hardware directly. The way I see it is that all the pre-programmed libs/softwares are helpers that you can use, but not forced to use
It would be awesome if you implemented Z80 protected mode like Andy Hu...Z80 still needs a protected mode OS!
Implementing a protected mode with such NMI mechanism brings a lot of overhead that makes it not really usable on a real project. Zeal 8-bit OS brings a software protection in the form of banked pages. The kernel RAM is mapped out when the user program is executing, so in theory, the user program doesn't have access to it (expect if the memory mapper is manually tweaked)
A hardware protected mode would be much better with a CPLD where only parts of memory could be protected, defined at runtime
This is awesome work! Is there anything that would prevent this from running on one of the commercial Z80 implementations? E.g. the Sinclair ZX-81 or the SoftCard series for the Apple ][?
Thank you very much!
At the moment, the OS requires a 4x16KB memory mapping. I know that the MSX2 computers have such mappings, so it would be possible to port it to them. For other computers like the ZX81 or ZX Spectrum, I would need to add support for no-MMU/no-mapper computers, which is possible in theory (it would bring limitations of course).
I don't have a lot of time to have a try at the moment but if anyone is willing to have a try to port it, I can help 😄
Cool project. It will run just in zeal 8bit or you think to made versions for other z80 computers like agonlight 2 ?
Thank you!
It can be ported thanks to the Hardware Abstraction Layer. I added a no-MMU feature which makes it usable to even more computers now, there is a small TRS-80 port as a Proof-Of-Concept.
There is a developer from the community on Discord that started porting it to the Agon Light, you can join to follow the project
I'm totally impressed! Not just with software but having working hardware too. You made it look too easy :)
I think it could have various benefits over existing systems. What do you think? Will it have practical use or basically stay an experiment?
I think it could be used for network security or signal integrity checks, as it has very limited attack vector - beeing built that minimalistic.
Hello Alexander!
Thanks for your heart-warming comment. It will have a practical use as it will be the official OS for Zeal 8-bit Computer. I plan on writing/porting the most basic softwares to it such as a text editor and an assembler.
I hope it will not just be a proof of concept of course, but this will depend on its software library.
@@Zeal8bit I'm speechless! I think you're onto something very very huge. Having an easy to understand, completely open hardware, open software and open compiler is crazy. Never thought modern and understandable computing could be mentioned in one phrase..
One challenge will be to write the compiler in high-level language and get the same result as your machine code. This would very easily prove that your compiler actually works as intended (chicken-egg issue with compiler needing compiler to compile).
I hope you see the huge potential. Just one idea: debugging an application including the compiler (make it possible to see the high-level language instructions but also the assembly code - or maybe even the high-level compiler code). This would make software development far more transparent.
I hope more people can find you. I think there is a huge interest if you mention why this is so special. Why shouldn't IT education start with this? What about scientists, why should they use tools that are overcomplicated and impossible for them to understand? You could become what linux became to windows or what arduino became.
It was a honor talking to you, sorry for the long text. I wish you all the best!
@@alexruedi1995 agreed. This channel is quite underestiamted for its very very interesting content
@@Zeal8bit I really don't know much about the Z80 but I am still impressed.
I have just enough knowledge about these old 8bit systems to suspect that your OS probably wasn't coded using Java™ or .NET C# lol
It's super cool how you guys are keeping these old systems alive and we can still learn from them.
@@Reth_Hard Haha indeed, pure assembly is the root of every software, I can't stop loving it
does it run crysis? just kidding... anyway the real joy come from working on real hw without crosscompiler.
On a similar note, it would be nice to see a port of Doom on it😂
Yes, the real joy is to be able to manipulate the hardware at our will, which is not something we can do that easily today anymore.
Cool!
Thanks!
Nice!
Thank you!
The great JOB !!!
Thank you very much!
Just a recommendation. Consider dropping the build time supporting code. It's of no use other than permitting irreproducible builds from the same code .
Oh thanks, that's a very good point! It's a good reason to drop it (or make it configurable)
Awesome !!
Thank you!
With the discontinuing of the Zilog z80, do you have plans to use a Zilog ez80 Acclaim Plus? It can operate at up to 50 Megahertz and is triple pipe lined so you can have a logical clock speed of 150 megahertz if you write your Zeal 8 Bit OS to take advantage of it, although it is designed with a Z80 backwards compatible mode in mind.
very cool!!
Thank you!
That's awesome.
Thank you very much!
Very Nice.
Many thanks!
Just posted a video short of the Zilog I-box prototype. I may have the only one! Cool story. Figured you may wanna look at it. Feel free to use the video or comment at me for more information. Ty
Impressive! It looks so smooth, too. Who would have thought that a humble Z80 chip could do so much? What made you go for a Z80 rather than, say an STM32 or RP2040; the greater technical challenge?
Thaks for your comment, it does run smoothly!
Several reasons led me to start this project with a Z80: I could go for an STM32, ESP32, or RP2040, however, these are MCUs rather than CPUs. so they embed ROM, EEPROM or even RAM. They don't provide any access to the internal bus, where devices (UART, I2C, SPI, ...) are connected. They only provide pins for GPIOs and other peripherals. This means that we cannot extend their capabilities. Thus if an MCU has, let's say, 128KB of RAM, we cannot extend it on the address bus. Yes,we can add some SPI RAM, but this won't be mapped on the main bus in most cases.
Another reason is that having only a CPU like a Z80 makes the computer a white box. As I also want this board to be an educational one for people willing to learn about hardware, seeing the actual chips that have a single purpose is much better than having one black box that does everything. Moreover, for repairing it's also better: for example, if the PIO, repsonsible for input/outpus, fails we can replace it without replacing all the computer. This is not the case with an MCU. If one of the MCU features fail, we have to get rid of the MCU and replacing it, even if 99% of other components are still working.
Finally, the last reason is more personal, but I would like to proove that having GHz of frequency in a CPU doesn't mean that computer will be stable or better. The problem we have today is despite the fact that CPU are more and more powerful, softwares are also much more greedy in terms of memory and CPU power. We have traded coding time for higher CPU requirements. We take less time coding difficult things but it makes the CPU perform much more operations and need for RAM. As a small anecdote, when I run the Zeal Emulator I wrote in JS (available in the description), I cannot emulate the machine at full-speed. So my 4-core 2GHz CPU cannot emulate a 10MHz Z80 at full speed in a web browser. (Of course, I realize that a native application written in C/C++/Rust/... would be much faster, but when I see that most desktop applications today are written with Electron, with is just a hidden web browser, it makes sense to make this comparison)
@@Zeal8bit Thanks for your thoughtful reply. I'm always impressed when people are able to do great things with such humble resources. Keep up the good work!
Best wishes to you.
Thank you very much!
How do you install it on custom hardware
Do you mean export it to a custom hardware or port it to a new hardware?
To port it to a new hardware, you will need to create a new target in the project ("target" dir), write the drivers associated to it.
You can check the details in the GitHub project.
The current main requirement for all targets is to have a 4x16KB address space
A Unix-like kernel in only 6KB; nice!
Thank you very much!
I am convinced it can still be optimized in some parts
@@Zeal8bit May I list it on the OSDev wiki projects page?
No problem, please do 😄
i've not studied hardware architecture (cpus cores etc)
I presume this could not run on a 64 bit processor
right?
Natively no, the OS has been written in Z80 assembly, so it will only run on Z80-compatible CPUs.
But on 64-bit processors, you can have an emulator to execute it
What's my Fathers Next Project. Fix the Mac VM boot sequence.
Computers Boot in order to detect Hardware changes. We don't Need that.
Instead of booting, Suspend and Resume the VM like Hibernate.
This Should Speed Bootup. This will require a Large Memory Copy.
Also, include the Option of Restarting the VM, to refresh the Memory Copy.
Long running Machines, Slow down and Need a Reboot.
hmm that's a lot of work you have done to get to the same place my computer was at in 1979 lol. I admire the effort though!
Thanks for your comment! Indeed, it was a lot of work but also a lot of fun!
How far did you go at that time? I mus thave been very difficult bak then, very few resources compared to today.
Cool, but that's gonna create confusiong with the 64bit ZealOS
what is 64bit ZealOS?
Thanks!
I wasn't aware of the existence of (64-bit) ZealOS until 2 days before I publish my OS. At first I also wanted to name it ZealOS because my 8-bit computer is named Zeal 8-bit Computer, so it was an obvious choice. In order to reduce the confusion, I decided to add the "8-bit" emphasis in the name
@1:40
Im getting the idea this computer architecture is why
There can be trouble emulating games
Ps1 is 100% compatibility, ps2 has gaps in the library
hey you have gotten me inspired and i want to make something like this myself but i am wondering if there is any way to prototype (like emulate and build a schem or smth like that in a program) so i dont have to invest money straight away
I am glad you got inspired!
When you say "something like this" do you mean an OS or a program? In any case, it's completely possible to prototype without the hardware. In my case, I made an emulator, as shown in the video, which has the most important features of my 8-bit computer. It's not 100% accurate but it's more than enough for prototyping. This is what I use everyday. Once I get my program working on the emulator, I test it on real hardware.
In your case, if you want to prototype something for Zeal, you can re-use the emulator, it's open-source (check the description), if you mean you want to prototype on another 8-bit computer, check if you can find an emulator for it or you can make one yourself.
@@Zeal8bit when I say inspired I more mean I want to make an 8-bit computer myelf but don't know what a good program is for prototyping a schematic, although as you said I could write an emulator for it and go from there, anyway another question is do you have a discord server for the board
@@funkyegg3516 Oh for schematics and PCB I use Kicad. If you need to make some logic/circuit simulation, Logisim is pretty good. It's not an electronic simulator, but for logic gates/demux/mux functional simulations, it works pretty good.
I created a discord, here is the link: discord.gg/UzEjwRvBBb
Not "less", but "cut"
Did you mean "cat" ?
"cat" can concatenate multiple files, this is not the case of my command which only takes a single parameter. It's not as advanced as the real less either, I should have named it "more"
but can it run on a ti-84?
I couldn't find any technical details about the memory mapping of the TI-84. Do you know where I can find it ?
If it has the proper memory mapping, it should be okay
@@Zeal8bit There is flash rom and RAM, the TI-84 and TI-83 share a convoluted page system, but the TI-83 is more documented when it comes to memory mapping. I found a few websites with a TI-83 memory map.
I just found it, TI-83+SE and onward have "Memory Map Mode 0" which separates the memory into 4 pages of 16KB. The first one is fixed to flash (totally fine as it can contain the OS) and the three other can be mapped to RAM. From what I see, that's compatible!
ALL HAIL
THE Z80
is it avaible for MSX or MSX2?
I don't have any MSX machine, to try to port it. But if anyone is willing to have a try, I would be happy to help!
From what I know MSX also has an MMU (Mapper), that divides the memory into 4 blocks of 16KB, so it should be compatible!
@@Zeal8bit there are many emolation for free.
@@maximilianprivrat I can have a try in the future if time allows. Meanwhile if anyone wants to have a try porting it, please feel free!😄
Hi,i have a question what can i do wiht a old nokia screen and a old phone procesor?
Hello, you will have to look for some specialized forum for your phone. Maybe someone lready tried to reverse engineer how th screen works? Maybe it is re-usable in a homebrew project?
@@Zeal8bit It is reuseble. And there’s a big BUT...... i have to wire like 20 or 40 weres to sodwer it to a motherboard ore something?
You should have made something like TempleOS or ZenithOS, that use a compilr-on-the-go processing
Just-In-Time compilation? In which case TempleOS and ZenithOS use this? This is usually done on interpreted languages or bytecode binaries, like Java.
Do you mean that assembler programs should be able to be assembled to binaries directly from Zeal 8-bit OS?
@@Zeal8bit ruclips.net/video/d3eFHyryopQ/видео.html
@@Zeal8bit I'm not an advanced programer, so I'm sorry if I'm just saying bullshit. But i believe TempleOS programs and kernel could be modified on the go without the need of compiling binaries, it's a kernel0 operational system, and all the code inside it is self described and you can change the kernel functions at any time without the need of recompiling the program or the operational system, it was made for x86 but it's based on commodore system
As ZealOS is a low level operational system, i believe you could may port something similar of what TempleOS creator used to make your CPU more advanced and intuitive to use, you probably need to change all the CPU calls to fit your needs but i believe it's a awesome idea because the versatility it has is absurd
Or at least, for me, your subscriber, i implore you you, when you are finished with your homebrew computer project, please, port your FPGA based GPU yo run on TempleOS, i believe it could run such amazing games, but the fact that it's mostly CPU-core dependent, it can't do much parallel computing... And it's creator it's dead so it's up to the community
Good morning Zeal .. I have a question. I have some old Grundy newBrains which, in my opinion, was a very nice machine at the time. Unfortunely the machines that were used in Angola were lost in time and now I am not able to make one for my museum .. I just saw your video and, eventually, you could be interested in pursuing that initiative and 1- modernize it 2- make the disk drives interface to it 3- eventually put it back in the market ... The machine used to have unique features and worked from the Bios as well as CP/M... Tell me something ... I would be interested in participating in the costs of some thing like this.
Hello! That looks like a very interesting project. I personally still have quite a lot of things to do on Zeal project. But I would be happy to hear more about it, you can join the Discord, some members can also help
@@Zeal8bit Tks for answering. Can you pls tell me how to join the Discord ? Do not know what is and how to join
Would this be compatible with the z180 and it's built in MMU/mapper
I haven't tried but in theory, it should be possible if we configure the Z180's Common Area 0 to end at 0x4000 and configure the Common Area 1 to start at 0xC000. This will give 16KB for the kernel in Common Area 0, 16KB for the kernel RAM in Common Area 1 and give 32KB of bank area for the programs.
Develop a embbeded System based on the Chipset used by the iconic and legendary Matell Intelivision the First 16-bit Video Game Console and far before Nvidia a GPU in the Chipset/Platform.
The Mattel Intelivision Chipset incl. 16-bit-CPU, a GPU and a Sound-Processor.
Then add your own 16-Bit OS to this Platform....😎
Back in. the time The Video Game Console "Coleco Vision" Like the Arcade-Game Consoles used the Z80.
Many facts of today came from the Matell Intelivision. First Voice-Output at Video Games. The technology of today is still based on Mattel's Approach. App Store where you can Download new Games, Edutainment, etc...
Porting Zeal 8-bit OS to another CPU would mean re-writing the whole OS as I wrote in Z80 assembly 😂
The Coleco Vision has good game library! Do you know if any of these games went open-source or resverse-engineered so that it could be ported to other Z80-based machines?
@@Zeal8bit Regardimg Open-Source or reverse-engineered Video Games you May have a better Chance at the Z80-based Sinclair Computers Like Sinclair ZX80, ZX81 and ZX Spectrum. Competitors to the Commodore C64 (Not Z80-based).
All These platforms at the end Just ported Arcade Games onto their Consoles / Computers while Mattel Intelivision stays to be the Pioneer in many Cases incl. Adventure Games. All showed Arcade Games-like graphics on their diverse Game-Levels while the Mattel Intelivision Had endless Game-Levels thanks to it's 16-bit Platform, while graphics at the and makes a good Game a Genius gaming Idea Not better.
Thanks for the advice!
It's just that the ZX Spectrum may not be the best good looking because of the attribute clash. But I will definitely check some.
@@Zeal8bit Hope the Platform you use does Not have the artefact of the ZX Spectrum...
Attribute clash (also known as colour clash or bleeding) ...an artifact caused by limits in the graphics circuitry ...
Another Z80-platform of the Golden 80s
Amstrad-/Schneider-CPC.
Also there a better Chance compared to the Coleco Vision.
Finally the only survivor of the Golden 80s is the Pionier.
Intelivision today as
Intelivision Amico.
So the system is made primarily for loading external programs and disk management. Technically, it's DOS, right?
I was more inspired by Linux but yes, technically it's also a DOS 😄
@@Zeal8bit it lacks the fun part of unix-like system - multitasking, for me it looks more like DOS, and it's not bad!
@@LiveGameDriveChannel Good point! We can see it as a DOS then yes 😄
Good Job, the schematic Is open source? can you share?
Salut, superbe projet
Je suis impatient que tu le proposes a la vente.
Qu'en est-il d'une case? Tu comptes en proposer? Peut-être une version amstrad cpc +++ ? Reprenant le cpc+ ?
Bonjour, merci beaucoup pour ton message!
J'espère que je pourrai en mettre quelques exemplaires de Zeal 8-bit Computer à vendre sous peu.
Une case c'est-à-dire un boitier? J'ai réalisé quelques prototypes (sans clavier, simplement un boîtier pour la carte mère) grâce à une imprimante 3D, mais cela reste des prototypes. Je pense qu'il serait possible d'en proposer mais pas dans l'immédiat.
Is the British version of this OS called Zeddle?
Wow.
Want to test your emulator but provided link doesn't contain one.
I can access the Github repo of the emulator from my side, try again: github.com/Zeal8bit/Zeal-WebEmulator
@@Zeal8bit you definitely have different link in video description
@@alt0v14 Thank you for noticing😀
It should be fixed now
Nice, can you share circuit?
При ерно 30 лет назад я сделал это.