Scott Stevens wrote: No, it's a laptop SLT/286, which makes adding RAM problematic. I can get upgrade modules, but they seem to run about $15-30/MB. Maybe reasonable, but not happenin'. :) But yeah, built very solid, and its only problems were a dead disk, a busted IDE cable, and the dead Dallas clock battery. Doc

Scott Stevens wrote: The last versions of Coherent were in two versions, one for 286 and one for 386. Expanded memory boards that add LIM EMS only will *not* work, it needs to be "native" memory. -- Jim Leonard (trixter at oldskool.org) World's largest electronic gaming project: http://www.MobyGames.com/ A delicious slice of the demoscene: http://www.MindCandyDVD.com/ Various oldskool PC rants and ramblings: http://www.oldskool.org/

Chuck Guzis wrote: Well, instead of pulling out your 286, you could send me disk images (3.5" DS2D would be perfect but 5.25" is fine) and I'll try 'em out. :) Doc

Minix runs a bit tight in 640K. For example you can't compile the kernel in 640K. I also don't think Minix will switch into protected mode in less than 1024K. You might want to do a Google search to see what state ELKS (the Embeddable Linux Kernel Subsystem) ended up in. It might give you a bit more room than Minix (which was really assuming it would be run in more that 640K). Again that was mostly cross compiled. ELKS, I believe, is small model userland code. Minix (again according to my often faulty memory) is large model. Can't recall which model Coherent used. Don't know too much about which memory model Xenix used. From the looks of it, it might have supported huge model code. Remember that if your system has an ISA bus, you can put more memory right on the bus. There must be a lot of ISA memory cards floating around. (I think I have four in various states of use/disuse). Depending upon the processor speed and the bus speed you might not even get a speed hit for ISA memory. Most 16 bit EMS cards would also show the memory as extended memory rather than expanded.

On 1/2/06, Jim Leonard <trixter at oldskool.org> wrote: I'd call that linear mode. By huge mode I mean "logically adjacent segments in 16 bit mode" so that pointer math can support objects larger than a segment. (i.e. segment=segment0+(offset/seg_size)*seg_incr; seg_offset=offset%seg_size; would be done automatically by the compiler. In DOS, seg_size could be 16 and seg_incr 1. In 286 protected mode, seg_size might be 64K and seg_incr would be 8 if I recall 286 protected mode stuff.) Virtual memory in 286 mode is one advantage OS/2 might have over any of the 286 unixes. I'm not sure if Xenix supported it.

From: "Liam Proven" <lproven at gmail.com> I am certain that Xenix/286 doesn't page. It does swap, much like early PDP-11 Unix kernels. But you will need enough RAM to load the kernel plus your largest process. I once ported GNU Emacs to the beast. In the largest configuration I had access to, there was enough memory to load it, and compose a document about 20 bytes long. Vince

On Wed, 2006-02-22 at 12:16 +0000, Liam Proven wrote: Swap is technically putting a segment (data or code) as one unit to the disk. paging is like swapping except using smaller-than-segment chunks (i.e. pages). In a paging system, each segment consists of a bunch of fixed-size pages and each one of those pages can be put on disk (or brought back) individually. When the OS tries to read from one of the missing pages, an exception is raised and the memory is loaded from disk. It wouldn't be so bad if people didn't use them interchangeably, but alas they do. Brian

On 2/22/2006 at 8:06 AM Brian Wheeler wrote: The wikipedia on memory management isn't too bad; contrast "segmentation" with "paging": http://en.wikipedia.org/wiki/Virtual_memory However, like a lot of computer-related stuff, these terms are evolutionary. The wiki would have you believe that special hardware is necessary for either paging or segmentation. Not true at all--JRT Pascal used segmentation and ran on a Z80 and I've worked on one BASIC implementation that paged from disk on an 8085. Similarly, my earlier comment was that a paging system could be implemented on a 286 if the page size was defined as the segment size limit--64K. Since the 286 doesn't offer offsets greater than 64K, one would still have to go through the nonsense of segment/offset calculation (why the 8086 never implemented a single instruction to compute a segment/offset from an existing segment-offset+displacement is beyond me), every distinct selector value represents a different page. To its credit, Windows 3.x did allocate large structures as a series of consecutively numbered selectors, so that a program could simply compute a new selector+offset value. Cheers, Chuck

On 2/22/2006 at 2:33 PM Jim Leonard wrote: Ever tried to work with an array that was much larger than 64K in 16 bit mode? The huge-mode address computation to get from a byte offset to a segment+offset representation is miserable--and a loop that does something like a[i] = b[j]+c[k] where all three arrays are larger than 64K is ridiculous. Chuck

On 2/22/2006 at 4:11 PM Jim Leonard wrote: Yeah, but when I saw the hoops one had to jump through on 8086 code for large structures with the sales engineer sitting there with a straight face and telling me it was ONLY 7 instructions, I became an instant fan of the 68000--just about had management convinced that 68K was the way to go when Bill Davidow (who was on the board) got wind of it and unilaterally shot it down. We ended up debugging the early steppings of the 80186. We had a socket onboard for the 286 but it was nowhere near ready for primetime yet. Cheers, Chuck

I don't know if anyone remembers the speculation about the architecture of Intel's first 16 bit PC back in the late 70's. We had some teasers from Intel like "bigger addressing space" and "16 bit registers" and "backward compatible with 8080 code". My guess was that Intel would simply double the register sizes. Let's see a->ax, check, b->bx, check, c->cx, check, d->dx, check, e->ex, h->hx, l->lx (huh?). Well, okay, we did get SI and DI (but the Z80 has IX and IY as 16 bit regs, so no big deal). My other thought was that registers would get paired up to form 32 bit address pointers (like hl, de, and bc). Nope, we got the funny segment registers. I was pretty happy about the improved register orthogonality (e.g. add dx,bx), but the 8086 overall was a big letdown. When the 68K was announced, my reaction was "Now that's the way it should be done". I liked the NS 32016 even better. The Z8000 left me pretty unimpressed, but less so than the 8086. Cheers, Chuck

On 2/23/2006 at 3:09 PM Liam Proven wrote: We're suffering a bit from nomenclature problems. Generally speaking, paging consists of dividing addressing space up into equally-sized chunks of memory, and swapping these chunks of memory from a secondary store. Optimization (i.e. making sure that related pages are in primary memory at the same time) is left to the operating system (hence, you'll see terms like "demand paging" (basically dumb paging) or "working set paging" (an attempt to predict the behavior of a program based on its history)). Segmentation operates at a higher level. A segment may represent all or part of a DLL or data structure--in other words, contents of a segment are more likely to be related. Segments are not usually of equal size. Since a segment is swapped in as unit, contiguous physical memory must be available for it--hence Windows insistence on using handles for memory allocation (the implication is that things can move). Consider a segment to be a chapter in a book--it's a logical entity. In general, a well-designed program operating in segmented mode has the potential of swapping less than one that is paged. However, paging frees the programmer from worrying about organizing things in segmented fashion (and having to deal with selectors)--what is seen is simply a huge linear address space (Usually CS=DS=ES=FS=GS and nobody changes them). But when we talk about segmentation, don't confuse this with Intel's unfortunate labeling of CS DS ES FS and GS as "segment" registers in real mode. That was a bad name for them--better to have called them "paragraph registers". In fact, when you get into 286 segmented mode, Intel calls them "selectors", not segment registers. Yes, in 286 segmented mode, the size of a segment is limited to 64K, but that's because the segment length field is 16 bits. Segments can be smaller than 64K. Cheers, Chuck

On 2/26/2006 at 11:50 AM Eric J Korpela wrote: No argument there. At the very least, permissions should have been better managed. But having CS separate from DS/ES/FS/GS makes the most sense. Sometimes it seems that while we've evolved from a mule cart to a Maserati, all we've done is moved the mule to the front seat. Cheers, Chuck

On 2/26/2006 at 7:10 PM spc at conman.org wrote: Still, it's possible to protect (read only or execute only) code pages. I think that Windoze got into the mess by taking a lax attitude such as dynamically modifying code (e.g. DLL calling sequences) as a routine part of operation. Once you start down that road, it's hard to change. A lot of our current security problems arise from insecure thinking. I could hardly believe it when MS trotted out OLE as an internet facility (renaming it ActiveX in the process). One could, for example, treat executable files as sacrosanct and difficult to modify or access as data without permission. But they're still treated as if they contained nothing special. Cheers, Chuck

It was thus said that the Great Liam Proven once stated: Segments have a starting address with a length associated with each segment, and paging is ... well ... a bit more complicated. I'll start with the 8086. In order to address more than 64K you can do one of a few things: you can increase the size of the addressing registers, you can bank switch memory, or you can do something that kind of mixes the two. The 8086 does this mixing. Each register on the 8086 is 16 bits in size, so the most that can be addressed is 64K. To get around this, the engineers at Intel added four segment registers that marked the start of a 64K block of memory. Since the address space of the 8086 was 20 bits, these segment registers were multipled by 16 (shifted left by 4) to get the physical address of the segment, then the 16 bit offset was added to this. So, the next instruction was pointed to by the CS:IP registers (CS is the Code Segment register, and IP is the instruction pointer), each being 16 bits. The math looked like: +---- ---- ---- ----+ | CS |0000 +---- ---- ---- ----+----+ + 0000| IP | +---- ---- ---- ----+ +------------------------+ | 20-bit physical addr | +------------------------+ The other three segment registers are DS (data segment), SS (stack segment) and ES (extra segment). There are implied segments to use depending upon the instruction (anything instruction related goes through CS, all data references use DS *except* references via BP use SS, stack references use SS and there are a few instructions that use ES by default. You can however, override the segment but it's an additional byte in the instruction stream). On the 80286, in protected mode, the segment registers no longer point to physical memory, but are instead indecies into a segment table that describes the segment. The segment register is still 16 bits however. The segment register (aka selector register) now has the format: +------------- ---+ | index | p | +------------- ---+ The first 13 bits (I'm going from memory here so details may be a bit sketchy) are the index into the selector table, and the last three bits are used for protection. Each entry in the selector table has the following fields: Physical address 24 bits Length of segment 16 bits Direction flag 1 bit Permissions a few bits Present flag 1 bit The direction flag instructs the CPU that the segment either starts at the physical address with addresses increasing, or *ends* at the physical address with addresses decreasing (for stacks typically). The present flag is set if the segment is in physical memory, otherwist it's not and the rest of the selector entry is not interpreted (this means that the OS can use the rest of the entry mark where on the swap device this segment is in this case). If you try to reference memory outside the segment, you get a fault. The reference (sorry for the lack of diagrams---using pseudo code here, with the CS:IP pair): if (!segtable[cs.index].present) segfault(cs:ip); if (ip > segtable[cs.index].length) segfault(cs:ip); physaddr = segtable[cs.index].physaddr + ip; The 80386 intruduced paging (and 32 bit registers but that's not important right now). Paging is slightly different. The program works with logical addresses: +--------------------------------+ | 32-bit address | +--------------------------------+ When a reference is made to memory, the CPU treats the address (on the 80386) as a collection of three offsets: +-------------------------------+ | offset 1 | offset 2 | offset 3| +-------------------------------+ (I don't recall the exact length of each one, but the last offset is 12 bits in size). Offset 1 is an entry in the top level page table, with each entry having a structure similar to the segment table for the 80286: Physical address 32 bits Size 32 bits Present flag 1 bit Permissions a few bits Offset 2 points to a second level table with the same structure, and offset 3 is a pointer into the actual bit of memory. So the address calculation looks like: if (!page1[ip.off1].present) pagefault(page1,ip); page2 = page1[ip.off1].physaddr; if (!page2[ip.off2].present) pagefault(page2,ip); physaddr = page2[ip.off2].physaddr + ip.off3; The reason for the two levels is so you can have a spare address space and waste less memory in keeping the page tables around (each process has its own page table). Now, the 80386 can do both segments *and* paging at the same time (if that's the case, I think it does the segment calculations first, then the paging calculations) but not many operating systems actually use both (well, they will set up a small segment table where each segment covers the full address space, but they don't bother to swap segments). -spc (Hope that clears some of the issues up)