• Please review our updated Terms and Rules here

MT86: a real-mode multitasking OS

just thought i'd post this, btw.. this shows how the processes fork. i executed the plasma demo from the shells on terminals 1, 2, and 4 and ran ps on term 3. when an application wants to fork a new process, it can specify in the call whether it's own process should be blocked until the child's process stops running or if it should stay active. being a shell, of course i made blocking calls and you can see the parents are paused. and of course, if i kill any processes from another shell or wherever (or a divide by zero/illegal opcode exception is tripped) it would also automatically kill it's child (and the child's children, recursively)

i think i've got all the process forking stuff down pretty solidly at this point. also, child processes always will inherit their environment (terminal and current filesystem path) from the parent.

mt86-childprocs.png
 
Mike Chambers said:
you gave me an idea though, in addition to one of those tandys with 768 KB of RAM, i could also use the RAM on machines with VGA cards right up to 0xB7FFF -- which would make 736 KB available to the kernel and all applications. :twisted:

since i will never be using any graphics modes, that wouldn't be a problem. i could do a quick test when the kernel first loads to find all writable memory from the end of the kernel at 0x20000 through 0xB7FFF.
Click to expand...
Yeah, that is a thought. One thing to keep in mind, though, is that any such access on discrete video cards is going to be limited to the speed of the ISA bus (4.77MHz,) which wouldn't be a problem on, say, an XT, but would result in a noticeable slowdown on 8+ MHz systems. (I'm not sure whether this applies to chipset video or not, probably depends on the board.) On the other hand, an extra 64+ KB of RAM on a 640KB base is a significant increase.
 
commodorejohn said:
Yeah, that is a thought. One thing to keep in mind, though, is that any such access on discrete video cards is going to be limited to the speed of the ISA bus (4.77MHz,) which wouldn't be a problem on, say, an XT, but would result in a noticeable slowdown on 8+ MHz systems. (I'm not sure whether this applies to chipset video or not, probably depends on the board.) On the other hand, an extra 64+ KB of RAM on a 640KB base is a significant increase.
Click to expand...

good point, i forgot about that. a couple options would be that i could leave it up to the user if they want to use it, and/or just use that area for non-performance-critical things like storing the terminal screen buffers there. that would give me more room to have extra terminals. each one takes about 4 KB to store its struct. it can add up fast. i.e., 8 terminals would take 32 KB. i have it set to 5 for now because of that.
 
Yep, there is that. You could set some of it aside for a RAM disk or disk caching, too - less responsive than normal RAM but still faster than disk access, at least on older hard disks.
 
commodorejohn said:
Interesting. I'm trying to recall if Tandy 1000/PCjr computers' relocatable video-memory window can be changed with a granularity fine enough to simply switch directly between terminals' buffers rather than performing a copy...instant switching'd be nice, though Tandy-specific stuff is admittedly fairly limited-application.

(Alternatively, I know of at least two Tandy 1000 models that can have 768KB RAM, the extra 128KB of which is nominally video memory, but it would be nifty to allow its use as main system memory, as I believe it's mapped into the main address space.)
Click to expand...

On any of the machines with multiple text pages (everything except CGA) you have this capability - the "SCREEN" command in BASIC demonstrates it well.
 

This is all that happened on my 486. On my PS/2 however, it booted up just fine and I was able to switch to the various shells and the plasma demo.
 
it seems the OS now has TCP/IP support. it uses packet drivers for the hardware layer access. i have just enough MS-DOS compatibility code to handle running them. now to actually write a test app, like a simplified telnet or something...

mt86-tcpip.png


it boots off a single floppy disk now too, no hard drive required.
 
well, the TCP/IP should theoretically work. as in, my TCP stack works when used as a C library for DOS apps. :)

i don't have any disk images smaller than 1.44 MB yet, i will need to modify the bootloader to do so but here is a 1.44 image with no TCP-related stuff.

http://rubbermallet.org/mt86-0.11.9.16.img

that should run fine in QEMU or fake86. there's still not really much to do on it. basically just look at the shells and execute the plasma demo with:

exec plasma.bin

;)

but, it serves a a good demonstration of the OS as it stand anyway. shows that it can fork and run processes.
 
You must log in or register to reply here.
Back
Top