|
have you considered the unix file system (UFS/UFS2)?
it's an oldie but a goodie, robust, fast and easy to understand and debug (coding is straightforward without the need for a PhD in mathematics).
Supports partitions, block and raw access, comes with a bunch of tools for managing/checking.
There's source code out there in old fashioned C (i.e. not some modernised version of the C language) so even hand converting it to another language not hard. (Ust remember how pointers, pointers to pointers, array offsets from pointers work for the table lookups such as the inodes).
Probably could even find a C compiler to output assembly/machine code for the processor of your choice if that's the way you are going.)
Signature ready for installation. Please Reboot now.
|
|
|
|
|
Lopatir wrote: Probably could even find a C compiler to output assembly/machine code for the processor of your choice if that's the way you are going.)
I have a C compiler, so this might actually be worth a try.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Ext2 could work but I don't know how heavy it would be in terms of code complexity and it would limit the portability of the files.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Ah, Linux and also close to the already suggested Unix file systems. Good candidate.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
ext2 will be difficult and overkill and need a lot more code & complexity and wont leave much room for anything else
compared to UFS which could run (as just one part of the unix operating system) on PDP-11's with 64k memory (and still leave room for multi users running multiple programs) - sure the PDP was a 16 bit machine but it's instruction set was not too far off the Z80 - so code sizes would be comparable. (OK, no paging, no clock interrupt) but those can be fudged/arranged.
Signature ready for installation. Please Reboot now.
|
|
|
|
|
The PDP Macro-11 Assembler and Resulting Octal instructions were NOT Z80.
they were clearly similar to the Motorola. We had R0-R7 and most C (written for PDP 8 I believe),
instructions were a SINGLE Macro-11 Instruction, including Register Indirect moves!
You could increment and dereference any register. The Intel chip has a single accumulator, ugghh!
When I switched to Intel 8080 for the IBM PC... My first thought was "So this is what the 60s felt like!"
|
|
|
|
|
Kirk 10389821 wrote: The PDP Macro-11 Assembler and Resulting Octal instructions were NOT Z80.
Never said that, I actually wrote " was not too far off the Z80"
Way back then I and some other enthusiast nerds did "hand assembly" (instruction set reference manuals and pen + paper) for [mostly] Z80, PDP, 6502 machines, the instruction format and binary structure, names and even more the hex/binary pattern (i.e. which bits were the instruction and which were register bits) of PDP-11 and Z80 were quite similar and, and way easier to translate code PDP<->Z80 than to/from 6502. (such as translating the guts of MBASIC - excluding the I/O of course.)
Yeah I know PDP usually meant octal, but we annotated the PDP manuals with hex, that further made it easier to move between processors (and did further enhance the Z80/PDP similarities / instruction binary style).
On the surface Z80 seemed to have the best set of instructions, but PDP had the best power of instructions - as you mentioned PDP could do pretty much anything with any register, with Z80 a lot of time was spent switching data back and forth between regs (which in hand assembly is painful coz half a page down you have to keep remembering where you left what and if you need to change it around again again again or if it's already changed around).
Once was young and stupid, thankfully not doing (nor contemplating) that [stuff above] anymore.
Signature ready for installation. Please Reboot now.
|
|
|
|
|
Octal vs Hex... Then again, they used 2 Byte Words...
Later in college I wrote my own MicroCode and learned how instruction sets are created.
Again, the HUGE Disparity in General Register Usage meant the instruction sets were not THAT close.
For example, EVERYTHING you see in C is basically a single instruction on the PDP!
And after 35 years, I find it hard to remember the actual assembly lines, except I know 4747 in octal was the JUMP instruction.
Yeah, abstraction is the key to working faster. I wrote some Intel Assembly to do some fast calculations... When I was done, I saw that the optimized C version was like 99% as fast. It took me 40hrs in Assembly. The C implementation was closer to a day (including testing/comparing to Assembly).
At that point, I NEVER went back, except when I had to write a thunking layer and forcibly execute 32bit code on 16 bit Windows... Even that was 2 lifetimes ago.
|
|
|
|
|
Agreed. Having coded assembler language on 6502, 6800, 68000 and LSI-11 back in the day, there is a definite comfortable familiarity between all of them. Assembler languages for IBM 360, Z80, 8086, etc., are certainly different from that familiarity, and not particularly comfortable in any way.
|
|
|
|
|
Just use XML. 
|
|
|
|
|
8-bit programs won't be much of a size, and 8-bit operating systems can't be much of a size. So I would recommend taking the simplest one in existence.
If you need an OS my hobby is developing an 8-bit preemptive multitasking OS for ZX Spectrum and a Windows for it (called Buddy). Source code for both is here.
|
|
|
|
|
How do you time and schedule the time slices for your threads or processes? A timer interrupt?
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Yes. There is a 50Hz IM1 interrupt mode, that is triggered on screen refresh. At that time I do the context switch. The code is fairly simple, the task.* file has all the logic. Just storing the stack pointer and registers, finding next task control block, respecting synchronization events for threads, such as wait_for, restoring the stack of that task, and returning. Not a rocket science, but it works surprisingly well and is quite stable.
|
|
|
|
|
The Spectrum had a 2 Mhz Z80A? Then there is no need to go overboard with complexity.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
3.5Mhz. But quite simple architecture without any special chips. You need to write everything from the keyboard driver to the RS232 bit banging.
|
|
|
|
|
Same here. Bit banged RS232 used to be quite common.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
The trouble with big banging without timers or specialized UART i.e. just by counting machine instruction cycles is that it kills multitasking. But I envisioned a sneaky technique for bit banging. It would be interested to know if it works. I never tested it. Theoretically I wanted to transfer 32 bytes in each direction at start of each context switch at maximum speed and, hence, minimal loss of processor cycles spend waiting. Like a communication burst. Because ZX Spectrum runs on 3.5 MHz and requires approx. 30 cycles to transfer a full byte (with control bits i.e. 8-N-1), 3.500.000 total cycles / 30 cycles gives a total ideal speed of 116.666 bauds, which is fantastically close to standard speed of 115.200. You can transfer almost without loss i.e. wait states. Transferring 32 bytes in both direction (full duplex) give you background speed of approx. 3200 baud, and leaves you with most of processor time for your app in every context switch. That's good enough for 8 bit internet, and remote file system.  I think the only problems would be with GUI so I programmed Buddy in very serious way, with invalid rectangles, partial redraws, message queue optimizations, and pretty much everything that Mac or early Atari GEM had. It's all there in the source code. Windows almost work, I just run out of time for optimized clipping code for bitmaps which would provide me fonts and bitmaps. Everything else is there and it is real event driven GUI thingie in 6KB, not some fake linear code Windows system. 
I wish I knew in 1983 what I know today. 
|
|
|
|
|
Quote: If you need an OS my hobby is developing an 8-bit preemptive multitasking OS for ZX Spectrum and a Windows for it (called Buddy).
WOW. 
You run it on the real hardware?
What C compiler are you using?
|
|
|
|
|
I tested an early ROM version on real hardware, including the fast RS232 transfers. Ever since I've been developing it on the emulator (Fuse), using SDCC C compiler. Here's a description of my environment. I was able to get GDB to debug it remotely, but only on assembler level, no source code debugging.
|
|
|
|
|
Cool!
|
|
|
|
|
You didn't by chance get into networking and hardware before coding, did you? sounds like it.
|
|
|
|
|
Back then the only way to get my own computer was to build one.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
128 GB for a 8 bit computer? Are you serious?
|
|
|
|
|
The interface allows it, so the software must deal with it. Otherwise it will get ever harder to find devices to plug into that interface without bumping into something you 'forgot' to implement.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
So are you going to use 5 registers to address it?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
