-
Notifications
You must be signed in to change notification settings - Fork 280
Frequently Questioned Answers
No. Most of these platforms can't keep time while doing disk I/O let alone run real time. However, this is an embedded OS.
Ideally yes. The kernel will treat the seconds from the RTC as a free running second timer and use this to lock its internal clock. As most platforms have to do long interrupt disables during floppy disk I/O it is useful to have. A few platforms (eg Amstrad PCW8256) have some clever hardware 'missed timer tick' counters we need to use instead. The RTC is only used to lock the kernel clock so problems like non Y2K safe RTC chips in older systems don't matter.
For the kernel itself generally about 8-10K plus any platform overhead like framebuffers. More is better as it translates into more disk buffers.
For user processes you need whatever the architecture and application size you want will be. At least 32K in most cases, a bit less for 6809 a lot more for 6502.
This assumes the kernel itself is ROMmed. If not add the kernel code (24-30K 6809, about 40K Z80, about 48K 6502)
Yes this was sorted for the 68000 - although it makes little sense to run Fuzix on a machine much bigger than that because it's not designed to scale to huge memory systems.
For multi-processing yes. For single process arguably you only need a keyboard interrupt and an RTC
The kernel can poll the serial lines but that may involve using a fast (eg 1KHz+) timer interrupt. To get the best behaviour when idle most platforms lacking serial IRQ spin polling the serial ports when idle. That means in most cases you get good serial behaviour.
I'm terribly sorry for you 8) If you have pure bitbanging you can probably use them for output only. If you have a fast timer and interrupt for bit edges you may be fine, but you probably need a separate high priority interrupt for it. 6809 with FIR is probably going to cope ok.
You could run an emulator on the PIC or similar. Really however the basic architecture of these machines generally splits 'program' flash and 'data'. Unix doesn't think like that. You could conceivably put all your programs into flash memory and make your executable format contain the initial data to load, and the XIP address/mappings for the "program" in the flash. You'd still have to decide how to partition RAM between apps though. Might be simpler to run an emulator on the PIC.
One possible exception to this is the ESP8266 as it has an SD interface and while it has separate I-RAM and D-RAM it does have RAM for both, and a reasonable amount, plus executable flash to hold the kernel.
I really wouldn't do that, certainly not yet, and quite possibly not ever.
Fuzix: because small is beautiful