lwv@n8emr.UUCP (Larry W. Virden) (06/05/88)
I am looking for info on the Intel 8748 chip. Back in 1984 a company called Quantum Leap was advertising a board for an Apple II series computer which used the 8748 to provide virtual memory management. The company has disappeared or at least isnt advertising now yet I think now more than ever this product would have a great impact on the Apple II line. Anyone have any info about such a chip - what are its features, problems, is it still in distribution>? Also, does anyone know anything about Quantum Leap Technologies of Arlington VA? They and a company called Data Link were selling this product, called the MegaTask PLUS. I am looking for ANY type of info - who were the managing personel there, did anyone out there buy this product, who designed the board, etc. Thanks! -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (INTERNET) We haven't inherited the world from our parents, but borrowed it from our children.
jac@andante.UUCP (Jonathan Chandross) (06/06/88)
I saw the note about Apple ][ virtual memory. I was originally just going to send this to Larry Virden but I think that the rest of you might be interested in it. Hardware experience on this group varies, so so I'll trying to keep this from going overboard technically. Let me know if you need more detailed information or a better explanation. And please, no flames for my simplifying assumptions. First, the 8748 is a microprocessor intended for use in instrumentation. It is an 8 bit 8080 like architecture, but it has a 2K EPROM on board and 2 parallel ports. These chips are commonly used in keyboard encoders and in appliances. It is a microprocessor, just like a 6502 so a program to control it is necessary. I suspect that all it did was monitor the addresses and do the paging for the apple. It probably just acted like a big ram board, much like the Saturn RAM boards. The solid state disks work very well and are fairly low overhead. Anyway, back to our virtual memory board. Suppose you devote a location on the VM board to specify the base address. This location would be the high order 8 bits of a 24 bit address - we simply use the ordinary 16 bits from the 6502 for the lower 16. Most Significant Bit Least Significant Bit _______________________________________________ | Base Address | Normal Apple Address | | 8 bits | 16 bits | ----------------------------------------------- The base address could be made to be 16 bits, 32 bits, anything you want. I chose 8 bits because 24 bits of addressing is 16 Megabytes, probably more than enough. The base address can quickly be reloaded since it only takes a write to a single location to change it. You can think of the base address as selecting 1 of the 256 possible memory pages. The lower 16 bits address an offset inside that page. The base address selects a "segment". To run a program you select a segment for it and put the program there. Addresses work as they normally do once inside this segment. I've arbitrarily selected 64K segments since this maps well to the 6502 address space. Those of you who've programmed on an 8086 or 8088 will see how familiar this is. To access a location outside of the current segment (as determined by the base address) you have to (1) save the current base address (2) load the base address with the proper base address for the segment you want (3) perform the memory access (4) restore the previous base address This is know as a "far" operation in the IBM world. It is "far" since it is not in your current segment. You can see that you pay a penalty for accesses outside of your current working segment. This is why most programs typically stay withing the "near" segment, that is, the current segment. To switch segments you perform a system call. This provides more freedom about which segments go where. Otherwise you would have to compile code to specifically work in one segment and know which programs lived in the other segments. After all, your program is manually switching segments by explicitly loading and saving the base address. A better scheme would relive user programs from knowing about other programs running in the system. To get around this we add a call in the operating system (OS) which says something like: I would like a free segment for a program The OS returns the number of a segment. Then whenever you want to access that segment you present the OS with the number. You *never* manipulate the base register yourself. Instead you ask the OS to manipulate the base register for you. While it would seem to be sill to have the OS perform segment manipulation, it is very useful for a number of reasons. If you want to run more programs than you have space for you can keep some of them out on a disk. Let's say you want to run 10 programs but only have space for 4. You keep 4 of them in memory and when you want to switch to another one of the 4 is placed on disk (you need to save working data and registers too!) and one of the other 6 is read in. Look at Tannenbaum's _Structured Computer Organization_ for a better description of "Virtual Memory." VM is the illusion of having more memory than you actually do. Anyway, by asking the system for a segment you can have the OS manage the memory instead of doing it yourself. You don't know *where* any program is at any given time, since the OS takes care of it for you. Whenever a program asks for a given segment the OS will swap out one of the segments and swap in the one you want (if it isn't in memory already). However, this won't work (as you're probably saying to yourself) for the simple reason that we can't get at the onboard memory. We need to disable the onboard memory since it wants to drive the data bus at the same time our VM board does. Remember, while VM board is monitoring and processing addresses using the base register the onboard memory is looking at the 16 bit address form the 6502. The two devices cannot respond simultaneously since (1) the VM board is furnishing correct data while the onboard memory is not and (2) electrical problems will destroy devices on both boards. So we have 2 choices. The first is to bank switch like the solid state disk drives do. These boards bank out the onboard ROMS (with Basic) and replace them with memory. There is a line on the motherboard which disables the onboard ROMS. This means you can only get at small pieces of memory at a time. It is very slow to keep changing which piece is banked in. And programs must be compiled with explicit knowledge of banks since they must call the OS every time they want to change the current bank. The second is a little more practical for our purposes. A "swapping system" takes the current contents of memory and saves them on disk. It then takes a new program and reads it into memory. A typical implementation might be: (1) save all the registers and other state of the machine (2) tell the hardware to swap out 48K of memory for us (I'm assuming that the OS is living in a Langauge Card. We can't swap it out since it manages memory for us) (3) tell the hardware to swap in the new program. Hardware can do this transfer at memory speed. 48K of 300nsec RAM wil take: .000000300 sec/byte x 65536bytes = .0196608 seconds to swap Call it 1/2 a second to swap out the old job and swap in the new. This type of transfer is easy to do with a very little logic. Changing processes is not blindingly fast, but it is certainly better than rebooting the machine. And each program "thinks" it has 64k of data to run in. And it thinks it owns the machine. We can run programs bigger than 64k easily by applying the banking techniques seen above. Note that you only need a special compiler if you are using the banks. Otherwise the program thinks it has control of the entire machine. Of course you have to be careful with the I/O devices. The OS would keep track of who was using what so things don't get clobbered. This shouldn't be too big a problem. If anyone knows how the VM board with the 8748 worked it is very likely that its function could be easily duplicated with some PALs rather cheaply. I suspect that a uP is overkill. Hope this was helpful and not too confusing..... Jonathan A. Chandross rutgers!allegra!jac