Chris Kennedy wrote: Wow. So was it one 68000 per user, or did it actually do proper multitasking? I'm sort of asking the original question because I'm ripping LisaEm apart into its components so that they may be usable in other emulation projects. One of is a CPU library based on Generator, so I was wondering if it's worthwhile to make the library capable of supporting multiple virtual 68000's. (The trade off is a loss in execution speed.)

which pick company was that? Ultimate owned the Qbus and such, but never did a 68000 coprocessor for the qbus or any dec machine. Jim Chris Kennedy wrote: -- ********************************** * * note my email address is changing to jws at jwsss.com * **********************************

On Sat, Apr 19, 2008 at 03:38:51AM -0800, davis wrote: I have a Perkin-Elmer workstation (7350?) that has a dual-68K bus-fault recovery design. It's running System III UNIX. We bought it, way back, as the cheapest way of getting a multi-user cross-development platform for our products after COMBOARDs. It has a console screen and keyboard, and four serial ports for dumb terminals. ISTR the disk is SASI (but there's probably a SASI<->ST506 converter buried in there somewhere). I _think_ it shipped with a 15MB disk, but mine had its disk replaced when it was still a full time development platform, so might have 20-30MB at present. The screen is mostly text (there might be some limited graphics capabilities), but has the curious feature of "soft buttons" built into the monitor's frame, so you apparently _have to_ use their monitor (it's not a generic sort of plug, either - perhaps a DB25 or DA15). It booted up the last time I turned it on. I tried to sell it at a hamfest a while back, but couldn't get an interest in it. Ah well... fun little box. -ethan -- Ethan Dicks, A-333-S Current South Pole Weather at 19-Apr-2008 at 10:50 Z South Pole Station PSC 468 Box 400 Temp -84.1 F (-64.5 C) Windchill -122.7 F (-85.9 C) APO AP 96598 Wind 10.1 kts Grid 10 Barometer 676.2 mb (10772 ft) Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html

On Sat, Apr 19, 2008 at 04:33:28AM -0800, davis wrote: Perhaps, but I'm not an HP expert. I _do_ recall an HP CRT with LEDs and phototransistors around the rim for a low-res touchscreen (32x32?) I have one of the screen bezels, but not the HP machine it goes with. Someday, I think about dusting it off and trying to get it to work, but I haven't managed to find the time yet. Shh.... ;-) -ethan -- Ethan Dicks, A-333-S Current South Pole Weather at 19-Apr-2008 at 12:10 Z South Pole Station PSC 468 Box 400 Temp -82.7 F (-63.7 C) Windchill -118.0 F (-83.4 C) APO AP 96598 Wind 8.5 kts Grid 92 Barometer 676.1 mb (10776 ft) Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html

Ok, so from the sounds of this thread, perhaps there is a need for multi--cpu support. I think I'll build the library as two libraries, perhaps controlled by a #define.

Were they 68000s, though? All the ones double-fault-fix machines I know of were, I think, using 68010s. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Jim wrote: The MC68000 didn't have a double bus fault problem. It had a *single* bus fault problem! On either a bus error or an address error exception, the information the processor puts in the exception stack frame is not sufficient to either resume or undo the faulted instruction. [*] These errors were considered fatal, and the typical "recovery" was to kill the process that faulted. Obviously this is not conducive to implementation of virtual memory. What some companies did, perhaps including Metheus, was to use two MC68000 processors. When a page fault occurs, rather than signalling a bus error to the running processor, the hardware "suspends" that processor (disconnects it from the bus, but leaves it waiting for the memory cycle to complete). The hardware enables the other processor, which runs the page fault hander. When the fault handler completes, the hardware switches back to the first processor, which can then complete the cycle. The MC68010 was introduced largely to fix this problem, though it had a few other enhancements as well. In the MC68010 (and MC68012, MC68020, MC68030, and CPU32), on a bus error or address error the processor pushes enough of its internal state onto the stack that an page fault handler can determine exactly what memory access had an error, fix the problem (e.g., by bringing in a page from disk and updating the page tables), and resume the faulted instruction from where it left off. The bus error stack frame was affectionately known as the "stack puke". On the MC68010, this occupied 29 16-bit words, although only 26 of them were written, and 3 were reserved. About 16 words of it were undocumented internal state that the software was not supposed to touch. On the M68K family processors, if a bus error occurred while the processor was already handling a bus error, that was a double bus fault and would cause a processor halt. This would normally only happen due to a software bug, such as a failure to allocate enough pages for the supervisor stack, and there was no means of recovery other than a hardware reset. In principle a multiple processor hack as described above could be used to allow recovery from this condition, but there wasn't really any reason to do so. Eric [*] If you write software such that only specific, known instructions can generate bus faults, you can recover from them. This technique is called probing, and is used in the Apple Lisa operating system.

In article <480C36A9.7080505 at ubanproductions.com>, Tom Uban <uban at ubanproductions.com> writes: Ah yes, I remember this machine! Anyone got one in their collection? ISTR it was quite popular for people doing parallel processing research. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

Tom Uban wrote: Is there theoretically enough documentation left to build such a card? That would at least bring such a restoration into the realms of 'possible' (albeit a lot of work!) m88k-based hardware really appeals, for some odd reason... cheers Jules

I've always found the 88K fascinating, if for no better reason than it's so unusual. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- 1-GHz Pentium-III + Java + XSLT == 1-MHz 6502. -- Craig Bruce --------------

So speaking of which, I poked around and realize that I don't have any manuals for this CPU, and sadly it seems I couldn't find them online either. Before the whole Freescale thing, Motorola used to have PDF's for lots of their manuals including PPC and 68k. Anyone know where the 88K manuals can be found today? (Not that I'm planning to do anything specifically with them, so much as I realize that I don't have any docs for them around, just incase some use for such docs might pop up.)