> FWIW, I believe Minix 2 meets at least some of your requirements. If > you're interested in tiny Unixalikes, it's well worth checking out: > > http://www.minix3.org/previous-versions/Intel-2.0.4/ > > (Although if you really want to run it on an XT, you'll need 2.0.3. > 640kB isn't quite enough for 2.0.4.) Available memory was one issue (256KB is all you can easily count on, 512KB isn't stock, and more than that was generally a custom card). But another problem is part of video memory needs to be located somewhere in the first 256KB. Maybe it's possible to make work but it just doesn't feel right. FreeDOS was pretty trivially easy to make run - all it needed was a base/load address modification and it was good to go. Well, that and writing a BIOS (or ripping Sanyo's from the DOS 2.11 that came with it, but that's not my style, except for the horrible, horrible little floppy data transfer engine that arises from the lack of DMA). > As it stands this will only work on the text segment, of course. We > don't know the layout of the data segment, so are unable to relocate > pointers in it. (Because we don't know what addresses contain pointers.) > This is where the half-baked 8086 'MMU' actually comes in handy; all > memory accesses are relative to SS, DS or CS, so moving stuff around in > memory is trivial. I keep forgetting this stuff is coming from C that assumes it can do sane pointer arithmetic. Some parts of my scheme were pretty much assuming hand coded assembly with procedures written around the windowing scheme. (I was envisioning a sort of java-like programming language where segments are selected when crossing "class" boundaries, so it would be unlikely for a 64KB segment to be filled, except for by really bad coding techniques). But I feel my chances of implementing something like that are slim. But if I change it to the idea of implementing a target for a "plain" compiler... Anything that targets "normal" x86-16 with bigger than 64KB data chunks needs to understand arithmetic on far addresses, and I wonder how hard it would be to do some sort of virtual linearization here, basically instead of a far pointer being effectively 20 bits of address inside 32 bits of storage, just make them flat 32 bits. Then, calculating the segment address is either shifting around for the "normal" case of 1MB space where the address really just is 20 bits, or could be converted to an ABI call (some interrupt numbers range?) for the OS to prepare memory and provide a segment address. The pointer arithmetic would reduce to plain 32 bit operations, but dereferencing an address would be significantly more complex. It would be easy to make a compiler generate code, but would probably be challenging to make a compiler generate fast code. > My opinion is that the 8086 is so limited and so intrinsically slow and, > well, crap, that trying to handle anything bigger than 64kB code + 64kB > data isn't worth the hassle. Definitely a fair point. My best counterpoint is that lots of these earlier machines were built like tanks and I suspect they will still be operable many decades from now. But the less they're capable of, the less chance they will be operating. > It would be relatively trivial to add the ability to allocate extra > chunks of data which are then accessed via read/write-like functions. > > extern int mmapalloc(int size); // returns handle to new block > extern int mmapfree(int size); // returns handle to new block > extern void mmapread(int handle, void* buffer, int offset, int length); > extern void mmapwrite(int handle, void* buffer, int offset, int length); > > mmapalloc() and mmapfree() would allocate a new segment. mmapread() and > mmapwrite() would be tiny little pieces of code that would just load the > segment descriptor into ES and do a bulk copy with REP STO or something. > There's lots of options for special applications to get access to extra memory, but lots of programs of interest wouldn't be compatible with this. Porting things would be (even more of) a nightmare. > I do actually have Watcom *almost* generating ELKS executables. No libc, > of course, I'm simply fighting the linker (which is deeply bizarre), but > it is getting there. This sounds like it'd be a good way to help ferret out bcc compiler bugs or bypass them entirely, plus from what I've read, Watcom is one of the better compilers to target 16 bit x86 in general. There may be some hints in FreeDOS, as openwatcom is one of the supported compilers for the kernel there. -- To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
