|
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?
|
|
|
|
|
Sounds like MSDOS will do the trick
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
DOS would fall right into the gap between the older components and the newer ones. A strange mixture.
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.
|
|
|
|
|
|
There are quite a few mentioned on the OSDev wiki. The LEAN fs might be worth looking at? Alternatively, there's a Simple File System, which should be... well, simple!
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
|
I would suggest examining some of the operating systems that were formerly implemented on 8-bit microprocessors. For example, there is TSC-FLEX, which was implemented first on the 6800, then the 6809, and which the still-existing usergroup has successfully interfaced to PATA hard drives.
There's also the Smoke Signal Broadcasting's BFD-DOS on the same hardware, but it is harder to find info about it.
There's also OS9 from Microware of Des Moines (not to be confused with similar designations i.e. Apple products) which was on 6809 and 68000 systems.
Or you could try and implement cpm as used on the 8080/Z80.
Or you could try TRS80DOS. There were a variety of operating systems, some produced by 3rd parties, for that platform.
|
|
|
|
|
I would recommend CPM for the operating system
|
|
|
|
|
...Rah-rah-ah-ah-ah-ah! Roma-roma-mamaa! I want your bad advice!
I'm sure this is going to sound completely Gaga, but I need your imaginative suggestions.
As usual, I needed an application for a given purpose, but couldn't find one I liked that could do what I wanted in the way I wanted it done. So I started rolling my own.
It's basically a tool application that does acts of unspeakble horror to PDF files (such as split, merge, add/edit/delete pages etc - Yeah I know, plenty of those around, but as I mentioned, I want to do it myself).
HOWEVA! I need a fun and catchy name for the application, something that partly describes what it does, but is also on the fun side.
Observe: I posted this in the Lounge, not the soapbox to rule out certain suggestions - So "PeDoFile Manager" for instance is out. Darn! Now I said it myself - but at least you get what I mean now, right?
So to cut to the chase: What would you call it?
Anything that is unrelated to elephants is irrelephant Anonymous
- The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944
- Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
|
|
|
|
|
Many (very many) years ago i was working on a new mainframe system and came across the source code for a very useful print utility, called "Fang". There was a long comment section at the beginning which explained the code and how it worked etc. Then right at the end it said "I couldn't think what to call this program so I named it after my cat".
|
|
|
|