From nyef@softhome.net Wed Mar 3 10:09:00 2004 From: nyef@softhome.net (Nyef) Date: Wed Mar 3 10:09:00 2004 Subject: [LMH] Ooh, look! List traffic! Message-ID: <20040303190611.GA31409@miyu.paradiesanalytics.com> Hello all. At http://www.dridus.com/~nyef/lispm/nevermore/frameimg.bmp is something that might be a little interesting (especially the lower left part of the image). I'm sure you all will be able to figure out what it is. --Alastair Bridgewater From Dan Moniz Wed Mar 3 16:23:00 2004 From: Dan Moniz (Dan Moniz) Date: Wed Mar 3 16:23:00 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <20040303190611.GA31409@miyu.paradiesanalytics.com> References: <20040303190611.GA31409@miyu.paradiesanalytics.com> Message-ID: <91988442.1078334542@localhost> --==========ED1A4104E747F7FDE94B========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday, March 03, 2004 2:06 PM -0500 Nyef wrote: > Hello all. > > At http://www.dridus.com/~nyef/lispm/nevermore/frameimg.bmp is > something that might be a little interesting (especially the > lower left part of the image). > > I'm sure you all will be able to figure out what it is. Cool! Also of interest are the other bitmaps in that directory. ;] --=20 Dan Moniz [http://www.pobox.com/~dnm/] --==========ED1A4104E747F7FDE94B========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: Mulberry PGP Plugin v3.0 Comment: processed by Mulberry PGP Plugin iQA/AwUBQEaE4FmE1hyKYjtREQIX8ACcCShk/ZH9C8N5rbwp4ddQMgr/jRsAoMaY j5D5NlJAbD6vJYnPVGDyZ/yB =f3Pw -----END PGP SIGNATURE----- --==========ED1A4104E747F7FDE94B==========-- From nyef@softhome.net Wed Mar 3 18:41:01 2004 From: nyef@softhome.net (Nyef) Date: Wed Mar 3 18:41:01 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <91988442.1078334542@localhost> References: <20040303190611.GA31409@miyu.paradiesanalytics.com> <91988442.1078334542@localhost> Message-ID: <20040304033822.GA31988@miyu.paradiesanalytics.com> On Wed, Mar 03, 2004 at 05:22:22PM -0800, Dan Moniz wrote: > On Wednesday, March 03, 2004 2:06 PM -0500 Nyef wrote: > > >Hello all. > > > >At http://www.dridus.com/~nyef/lispm/nevermore/frameimg.bmp is > >something that might be a little interesting (especially the > >lower left part of the image). > > > >I'm sure you all will be able to figure out what it is. > > Cool! > > Also of interest are the other bitmaps in that directory. ;] Indeed, but those weren't there when I sent my message to the list. As a data point, all of these images took about 20 minutes each of runtime in the emulator to create. The last thing I did with the code was to put in address decoding for the memory board control space, which was enough to get it to do a thorough test of the low 256k of the memory space, but still fail the board test. That took about three and a half hours to run and generated about 1,054,200 lines of output. And no, that's not a per-instruction trace. It's mainly the CMUCL GC going off and all of the NuBus access requests (and a bit from the mapping hardware, but that doesn't get used much yet). --Alastair Bridgewater From rjs@fdy2.demon.co.uk Thu Mar 4 01:21:01 2004 From: rjs@fdy2.demon.co.uk (Robert Swindells) Date: Thu Mar 4 01:21:01 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <20040304033822.GA31988@miyu.paradiesanalytics.com> (message from Nyef on Wed, 3 Mar 2004 22:38:22 -0500) Message-ID: <200403041017.i24AHKKE082163@ren.fdy2.net> Alastair Bridgewater wrote: >On Wed, Mar 03, 2004 at 05:22:22PM -0800, Dan Moniz wrote: >> On Wednesday, March 03, 2004 2:06 PM -0500 Nyef wrote: >> >> >Hello all. >> > >> >At http://www.dridus.com/~nyef/lispm/nevermore/frameimg.bmp is >> >something that might be a little interesting (especially the >> >lower left part of the image). >> > >> >I'm sure you all will be able to figure out what it is. >> >> Cool! >> >> Also of interest are the other bitmaps in that directory. ;] >Indeed, but those weren't there when I sent my message to the list. >As a data point, all of these images took about 20 minutes each of >runtime in the emulator to create. >The last thing I did with the code was to put in address decoding >for the memory board control space, which was enough to get it to >do a thorough test of the low 256k of the memory space, but still >fail the board test. That took about three and a half hours to run >and generated about 1,054,200 lines of output. And no, that's not >a per-instruction trace. It's mainly the CMUCL GC going off and all >of the NuBus access requests (and a bit from the mapping hardware, >but that doesn't get used much yet). How about a VHDL version ? :-) Robert Swindells From mikemac@mikemac.com Thu Mar 4 04:41:02 2004 From: mikemac@mikemac.com (Mike McDonald) Date: Thu Mar 4 04:41:02 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: Your message of "Wed, 03 Mar 2004 22:38:22 EST." <20040304033822.GA31988@miyu.paradiesanalytics.com> Message-ID: <200403041337.i24DbX905722@saturn.mikemac.com> >To: Dan Moniz >Date: Wed, 3 Mar 2004 22:38:22 -0500 >From: Nyef >The last thing I did with the code was to put in address decoding >for the memory board control space, which was enough to get it to >do a thorough test of the low 256k of the memory space, but still >fail the board test. That took about three and a half hours to run >and generated about 1,054,200 lines of output. And no, that's not >a per-instruction trace. It's mainly the CMUCL GC going off and all >of the NuBus access requests (and a bit from the mapping hardware, >but that doesn't get used much yet). OK, I'm confused now. Are you writing an emulator in Lisp? Can you provide some more info? Thanks. Mike McDonald mikemac@mikemac.com From nyef@softhome.net Thu Mar 4 06:22:01 2004 From: nyef@softhome.net (Nyef) Date: Thu Mar 4 06:22:01 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <200403041337.i24DbX905722@saturn.mikemac.com> References: <20040304033822.GA31988@miyu.paradiesanalytics.com> <200403041337.i24DbX905722@saturn.mikemac.com> Message-ID: <20040304151820.GA32669@miyu.paradiesanalytics.com> On Thu, Mar 04, 2004 at 08:37:33AM -0500, Mike McDonald wrote: > > >To: Dan Moniz > >Date: Wed, 3 Mar 2004 22:38:22 -0500 > >From: Nyef > > >The last thing I did with the code was to put in address decoding > >for the memory board control space, which was enough to get it to > >do a thorough test of the low 256k of the memory space, but still > >fail the board test. That took about three and a half hours to run Did I say three and a half? I meant six and a half. > >and generated about 1,054,200 lines of output. And no, that's not > >a per-instruction trace. It's mainly the CMUCL GC going off and all > >of the NuBus access requests (and a bit from the mapping hardware, > >but that doesn't get used much yet). > > OK, I'm confused now. Are you writing an emulator in Lisp? Can you > provide some more info? Yes, it's in Lisp. The old (late last year) source tarball is up in the same directory as all the screenshots ( http://www.dridus.com/~nyef/lispm/nevermore/ ), and I'm doing some cleanup on the current sources in preparation for releasing them at some point in the next day or so. As fair warning, the old version reqiures a combined microcode image that none of you have. The new version will require rom images for the SIB config rom, the memory board config rom, and all seven boot microcode roms. These files are (in order): 2236662_SIB 2243924-2_27S291.8MB 2236480-03 2236481-03 2236482-03 2236483-03 2236484-03 2236485-03 2236486-03 (here's where being a packrat and downloading every rom file and disk image mentioned on the list over the past couple years helps.) --Alastair Bridgewater From nyef@softhome.net Thu Mar 4 09:06:01 2004 From: nyef@softhome.net (Nyef) Date: Thu Mar 4 09:06:01 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <20040304151820.GA32669@miyu.paradiesanalytics.com> References: <20040304033822.GA31988@miyu.paradiesanalytics.com> <200403041337.i24DbX905722@saturn.mikemac.com> <20040304151820.GA32669@miyu.paradiesanalytics.com> Message-ID: <20040304180316.GA456@miyu.paradiesanalytics.com> On Thu, Mar 04, 2004 at 10:18:20AM -0500, Nyef wrote: > > Yes, it's in Lisp. The old (late last year) source tarball is up in > the same directory as all the screenshots ( > http://www.dridus.com/~nyef/lispm/nevermore/ ), and I'm doing some > cleanup on the current sources in preparation for releasing them at > some point in the next day or so. Fitting action to words, the new version is up as http://www.dridus.com/~nyef/lispm/nevermore/nevermore-9e0304.tgz I am uncertain as to if I will be continuing with this codebase. The speed has reached the point of untenability. --Alastair Bridgewater From rjs@fdy2.demon.co.uk Thu Mar 4 10:05:01 2004 From: rjs@fdy2.demon.co.uk (Robert Swindells) Date: Thu Mar 4 10:05:01 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <20040304180316.GA456@miyu.paradiesanalytics.com> (message from Nyef on Thu, 4 Mar 2004 13:03:16 -0500) Message-ID: <200403041901.i24J1NSg082987@ren.fdy2.net> Nyef wrote: >On Thu, Mar 04, 2004 at 10:18:20AM -0500, Nyef wrote: >> >> Yes, it's in Lisp. The old (late last year) source tarball is up in >> the same directory as all the screenshots ( >> http://www.dridus.com/~nyef/lispm/nevermore/ ), and I'm doing some >> cleanup on the current sources in preparation for releasing them at >> some point in the next day or so. >Fitting action to words, the new version is up as >http://www.dridus.com/~nyef/lispm/nevermore/nevermore-9e0304.tgz >I am uncertain as to if I will be continuing with this codebase. >The speed has reached the point of untenability. I was only half joking about translating it to VHDL. Just having done the analysis of what the microarchitecture needs to do might be useful in the long run. The whole CPU would fit into a $15 FPGA using current technology, add a couple of 16bit SDRAMs and some boot flash and you have a 10x faster microExplorer. Robert Swindells From Dan Moniz Thu Mar 4 17:58:00 2004 From: Dan Moniz (Dan Moniz) Date: Thu Mar 4 17:58:00 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <200403041901.i24J1NSg082987@ren.fdy2.net> References: <200403041901.i24J1NSg082987@ren.fdy2.net> Message-ID: <3344789.1078426623@localhost> --==========12568330DF163FFC5379========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday, March 04, 2004 7:01 PM +0000 Robert Swindells=20 wrote: > Nyef wrote: > > On Thu, Mar 04, 2004 at 10:18:20AM -0500, Nyef wrote: > >> > >> Yes, it's in Lisp. The old (late last year) source tarball is up in > >> the same directory as all the screenshots ( > >> http://www.dridus.com/~nyef/lispm/nevermore/ ), and I'm doing some > >> cleanup on the current sources in preparation for releasing them at > >> some point in the next day or so. > > > Fitting action to words, the new version is up as > > http://www.dridus.com/~nyef/lispm/nevermore/nevermore-9e0304.tgz > > > I am uncertain as to if I will be continuing with this codebase. > > The speed has reached the point of untenability. > > I was only half joking about translating it to VHDL. > > Just having done the analysis of what the microarchitecture needs to > do might be useful in the long run. > > The whole CPU would fit into a $15 FPGA using current technology, add > a couple of 16bit SDRAMs and some boot flash and you have a 10x faster > microExplorer. Which is an interesting point. I wonder how hard it would be to write the=20 emulator (or CPU) in Verilog (being somewhat higher-level and easier to=20 cope with than VHDL, at least for this task). I assume "hard", and that=20 would be an understatement. But possibly worthwhile. Of course, there's the longer term problem of getting a monitor and input=20 devices to talk to it, which would be painful, and disks, file systems, a=20 running install, oh my! Probably, now that I think about it, an FPGA-based Explorer processor on a=20 PCI card, with some interface glue would be the way to go. If someone is willing to buy me a simple Xilinx setup (usable FPGA for this = purpose, test-board, Verilog compiler, etc.), I'll take a crack at it. I=20 won't hold my breath, but this equipment has come down in price. I think=20 the FPGA we'd want/need is more expensive than the one included in their=20 $70 - $100 starter kit. Alastair, I should have asked you this years ago, but I've been somewhat=20 confused for a while as to where exploiter fit into the picture. E3 was=20 supposed to be an emulator, and exploiter was, what, your independently=20 developed emulator? And nevermore is the same sort of thing in CL (Mike=20 already asked this, but I had gathered as much from the code). For a while=20 now I've been confused as to what the relation was between E3 and=20 exploiter, but I never thought to ask. I always thought it was explained in = one of the previous list emails, but in infrequent and rather shallow=20 searching of my personal archive of lispm-hackers over the years, I never=20 found a mail with an explanation. I'm just curious, BTW, because this bit=20 of information has been missing from my picture of the development effort. --=20 Dan Moniz [http://www.pobox.com/~dnm/] --==========12568330DF163FFC5379========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: Mulberry PGP Plugin v3.0 Comment: processed by Mulberry PGP Plugin iQA/AwUBQEfsiFmE1hyKYjtREQKj1wCgnmkaF13v4gDKrPNKQRkDYzfdL6UAoIcF pAg84qLBJLZUflLpICXRS9qT =czNP -----END PGP SIGNATURE----- --==========12568330DF163FFC5379==========-- From nyef@softhome.net Thu Mar 4 19:35:02 2004 From: nyef@softhome.net (Nyef) Date: Thu Mar 4 19:35:02 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <3344789.1078426623@localhost> References: <200403041901.i24J1NSg082987@ren.fdy2.net> <3344789.1078426623@localhost> Message-ID: <20040305043155.GA1126@miyu.paradiesanalytics.com> On Thu, Mar 04, 2004 at 06:57:03PM -0800, Dan Moniz wrote: > > Which is an interesting point. I wonder how hard it would be to write the > emulator (or CPU) in Verilog (being somewhat higher-level and easier to > cope with than VHDL, at least for this task). I assume "hard", and that > would be an understatement. But possibly worthwhile. > > Of course, there's the longer term problem of getting a monitor and input > devices to talk to it, which would be painful, and disks, file systems, a > running install, oh my! Indeed. At this point we're approaching where I'd prefer we had the rights to the source and disk images sorted out. > Probably, now that I think about it, an FPGA-based Explorer processor on a > PCI card, with some interface glue would be the way to go. I'd prefer a PCMCIA card, mainly because I mostly use laptops these days. > Alastair, I should have asked you this years ago, but I've been somewhat > confused for a while as to where exploiter fit into the picture. E3 was > supposed to be an emulator, and exploiter was, what, your independently > developed emulator? And nevermore is the same sort of thing in CL (Mike > already asked this, but I had gathered as much from the code). For a while > now I've been confused as to what the relation was between E3 and > exploiter, but I never thought to ask. I always thought it was explained in > one of the previous list emails, but in infrequent and rather shallow > searching of my personal archive of lispm-hackers over the years, I never > found a mail with an explanation. I'm just curious, BTW, because this bit > of information has been missing from my picture of the development effort. Okay, so here's how it happened... Once upon a time, there was E3. And it was a wonderful idea. It could read a load band and disassemble the first function in it, but that was about all it could do. This is how it was when I stumbled across it. Some months later, after some effort was invested in the standalone-E3 code, and SSDN2 started being converted to text files, E3 could read a load bad and disassemble the first function in it, but that was about all it could do. For the past several months, the discussion had been about how to implement function calling, since the first (well, second) instruction to execute was a function call instruction. Unfortunately, I couldn't work on E3 because it would throw my computer for a loop every time I tried to run it (nasty kernel messages and everything). But I didn't like seeing the complete lack of progress with people talking about how hard the next step was and not doing anything about it. During this time I had done some studying of various things like the load band and the existing E3 source and such, and had some code for looking at a load band a little more meaningfully than as a hexdump. So I wrote a quick hack to read a load band, find the initial function, and then "execute" the first couple instructions, just to see how hard it really was. And it was -easy-. So I posted that first message to the list, trying to say "come on, guys, it's not that hard, just write the damned code." Nothing happened on the E3 side, but my curiousity wouldn't let me leave my own quick hack alone for too long. So a little while later I had quite a bit more working, made a tarball with my sources, and posted the first version of exploiter. And soon another. Now we get into some of the previously-undisclosed history: At this point, John Morrison, by private email, asked about reconciling my work on exploiter with E3 because there now appeared to be two projects where once there was one. I explained my position (more accurately, ranted for a bit), and gave a list of what I felt was wrong with E3. This was Tuesday, May 21, 2002. Other things that happened on this day included me figuring out how to run E3 without breaking my computer, and Robert Swindells sending me the first unsolicited patch against exploiter. On the following Thursday I exchanged emails with John again, with me explaining why I was going to continue with exploiter and not try and fix E3. This wasn't supposed to happen. There was a two and a half week window in which -any- progress on E3 would probably have caused me to drop exploiter, and which I would have welcomed as being a sign of exploiter succeeding at what it was supposed to do. There was a two-day window in which John could have done the same by fixing any two things on my list of complaints (admittedly, neither of us knew that at the time, and he was busy with his day job, and fixing the easiest two problems would have taken a few hours at least). After this point, very few if any changes were made to E3, and exploiter gained a lot of momentum and carried it fairly well for a while. So, from what I see, exploiter was the quick hack originally meant to light the way for E3 that accidentally ended up killing E3 and taking its place. The history of nevermore is actually recorded in the readme file in the source distribution. It was originally a microcode disassembler that ended up becoming an emulator. Unlike E3 and exploiter, nevermore is a microcode emulator, which means that it will likely be slower than E3 or exploiter would have been / will be, but also means that it should be able to run VM1 code if we ever find a disk image that old. There are other implications as well, but I'm not really up to figuring them out right now. This was probably more information than you really asked for, and I don't know if it answered your questions or not, but... Whatever. I'm tired. I'm going to bed. --Alastair Bridgewater From weel@caltech.edu Thu Mar 4 23:22:01 2004 From: weel@caltech.edu (Jaap Weel) Date: Thu Mar 4 23:22:01 2004 Subject: [LMH] Ooh, look! List traffic! Message-ID: <707239AA-6E7D-11D8-9283-000A959B403C@caltech.edu> On 4 Mar 2004, at 18:57, Dan Moniz wrote: > On Thursday, March 04, 2004 7:01 PM +0000 Robert Swindells > wrote: >> I was only half joking about translating it to VHDL. >> [...] >> The whole CPU would fit into a $15 FPGA using current technology, add >> a couple of 16bit SDRAMs and some boot flash and you have a 10x faster >> microExplorer. > > [...] > Of course, there's the longer term problem of getting a monitor and > input devices to talk to it, which would be painful, and disks, file > systems, a running install, oh my! > Probably, now that I think about it, an FPGA-based Explorer processor > on a PCI card, with some interface glue would be the way to go. I don't know if this is applicable, but hey, you never know. When they made OpenGenera (you know, the virtual Symbolics-on-Alpha), they didn't give it any intrinsic knowledge about DEC's hardware. All it knew how to do was to talk on the network. It would then find its filesystem through NSF, display its interface through X11, and in various other ways leverage the fact that there was always a copy of OSF/1 to take care of bit-diddling IO. It's not very purist, but you could do a lot with a network interface, while a $200 Walmart FORTRAN Machine can take care of I/O. > If someone is willing to buy me a simple Xilinx setup (usable FPGA for > this purpose, test-board, Verilog compiler, etc.), I'll take a crack > at it. I won't hold my breath, but this equipment has come down in > price. I think the FPGA we'd want/need is more expensive than the one > included in their $70 - $100 starter kit. In all the following, please keep in mind that I just happen to have become interested in FPGA's like, what, three weeks ago, so don't take any of this to literally: Xilinx development boards are overpriced and geared towards industries, not hackers or students; third-party suppliers are cheaper. Some of their boards come as PCI cards, which would be a Good Thing. There's www.geda.seul.org for various GPL'ed design tools, including a Verilog simulator. Xilinx put out a student edition of their software that you can order on Amazon for $65. It contains VHDL and Verilog tools as well as lower-level tools. It has a limitation on the size of FPGA it can deal with, but I don't think that need be prohibitive. It says for an older version: "any XC9500 CPLD, any Spartan FPGA, any XC4000 FPGA up to an XC4010, or the XCV50 Virtex FPGA." Spartan goes up to 28*42 CLB's with 56kbits on-chip "block ram". The d*(&%^*& Xilinx website is down so I can't check what the limitations on the current version are or how many CLB's are on a Virtex. At the risk of seriously offending the intellect of readers who know computer architecture much better than I do from just reading Hennesy&Patterson: Even though on LISP machines the microcode has the added advantage that it can be reprogrammed easily, the original reason for Microcode as opposed to Hardwired Control is that you could conserve precious silicon area by having a really simple control unit (in the CADR, practically none, since the microcode instruction set is notoriously simple; I don't know much about the Exploder, but I imagine it's similar). This is why I'm not too worried about needing humongous amounts of silicon. Many FPGA's have built-in fast RAM that could contain microcode. Question: What is the Exploder microcode instruction set like? Is it *much* different, conceptually, from CADR microcode? This would determine the amount of FPGA area needed to implement the controller. If it's anything like the CADR, my hunch is: not much. Question: What is the word length on a uExploder again? (I'm sorry, I can't ever keep the word lengths of all different LISP machines detangled in my head.) The size of the datapath part of a design should scale about linearly in the word length. Of course, it also depends on how many different operations you need to do, how many registers you need &c. Question: How much microcode is there? I.e. how much microcode RAM do you need? It is my impression, but then again, I am by no means well-versed in this stuff (yet), that "naive" Verilog coding and then letting a synthesis program figure out which wires go where decreases performance by a factor of something manageable but annoying, and that people prefer to tweak their code, potentially later on in the process, to get better cycle times. For example, the LEON-1 SPARC implementation from ESA (http://www.estec.esa.nl/wsmwww/leon/) is written in portable VHDL, independent of the flavor of silicon. It runs at 45 MHz on a biggish Xilinx, but only "after layout", which I *assume* means after somebody who knew his Xilinx stuff gave extra hints to the Xilinx software as to what to put where and maybe tweaked some of the code. To do that, you would probably need simulation tools that come with your FPGA, which implies buying them from Xilinx. To just get working Verilog code, you could probably use the free Ikaros simulator. I'm trying to get into the whole FPGA thing because I'm supposed to implement a CPU in one for my summer job. There have been various reports from people doing interesting projects in surprisingly little time given the right tools; look up fpgacpu.org for some pointers and lots of FPGA shop talk. Especially his circuit cellar article gives a good idea of the practicalities involved, I think. Once again, he's doing RISC-like hardwired control, not microcoded control. I don't know if anyone has tried microcoded control yet. /jaap ======================================================================== Jaap Weel Campus address: | dorm (626) 795-9748 Caltech, Blacker '05 Caltech MSC #874, Pasadena, CA 91126, U.S.A. www.its.caltech.edu/~weel Permanent address: | home +31-46-4337033 E-mail: weel@caltech.edu Kelderstraat 2-4, 6171 GB Stein, Netherlands ======================================================================== From asholz@topinform.de Thu Mar 4 23:53:01 2004 From: asholz@topinform.de (Andreas Holz) Date: Thu Mar 4 23:53:01 2004 Subject: [LMH]Re: LispM-Hackers digest, Vol 1 #247 - 7 msgs In-Reply-To: <20040304210101.2184.qmail@kappa.unlambda.com> References: <20040304210101.2184.qmail@kappa.unlambda.com> Message-ID: <40483FE5.3040305@topinform.com> Robert, >I was only half joking about translating it to VHDL. > >Just having done the analysis of what the microarchitecture needs to >do might be useful in the long run. > >The whole CPU would fit into a $15 FPGA using current technology, add >a couple of 16bit SDRAMs and some boot flash and you have a 10x faster >microExplorer. > >Robert Swindells > > who can do that? Andreas From rjs@fdy2.demon.co.uk Fri Mar 5 01:05:02 2004 From: rjs@fdy2.demon.co.uk (Robert Swindells) Date: Fri Mar 5 01:05:02 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <3344789.1078426623@localhost> (message from Dan Moniz on Thu, 04 Mar 2004 18:57:03 -0800) Message-ID: <200403051001.i25A1QhX085020@ren.fdy2.net> Dan Moniz wrote: >On Thursday, March 04, 2004 7:01 PM +0000 Robert Swindells > wrote: >> Nyef wrote: >> > On Thu, Mar 04, 2004 at 10:18:20AM -0500, Nyef wrote: >> >> >> >> Yes, it's in Lisp. The old (late last year) source tarball is up in >> >> the same directory as all the screenshots ( >> >> http://www.dridus.com/~nyef/lispm/nevermore/ ), and I'm doing some >> >> cleanup on the current sources in preparation for releasing them at >> >> some point in the next day or so. >> >> > Fitting action to words, the new version is up as >> > http://www.dridus.com/~nyef/lispm/nevermore/nevermore-9e0304.tgz >> >> > I am uncertain as to if I will be continuing with this codebase. >> > The speed has reached the point of untenability. >> >> I was only half joking about translating it to VHDL. >> >> Just having done the analysis of what the microarchitecture needs to >> do might be useful in the long run. >> >> The whole CPU would fit into a $15 FPGA using current technology, add >> a couple of 16bit SDRAMs and some boot flash and you have a 10x faster >> microExplorer. >Which is an interesting point. I wonder how hard it would be to write >the emulator (or CPU) in Verilog (being somewhat higher-level and >easier to cope with than VHDL, at least for this task). I assume >"hard", and that would be an understatement. But possibly worthwhile. It seems to be a pretty standard student project right now to design a CPU. Check out as well. I don't think VHDL is too hard or too low level to be useful. >Of course, there's the longer term problem of getting a monitor and >input devices to talk to it, which would be painful, and disks, file >systems, a running install, oh my! >Probably, now that I think about it, an FPGA-based Explorer processor >on a PCI card, with some interface glue would be the way to go. I wrote "microExplorer" on purpose. >If someone is willing to buy me a simple Xilinx setup (usable FPGA for >this purpose, test-board, Verilog compiler, etc.), I'll take a crack >at it. I won't hold my breath, but this equipment has come down in >price. I think the FPGA we'd want/need is more expensive than the one >included in their $70 - $100 starter kit. The free version of Xilinx ISE will target a big enough Spartan 3. The older PCI card that I'm using at work sells for $200. Robert Swindells From weel@caltech.edu Fri Mar 5 04:30:01 2004 From: weel@caltech.edu (Jaap Weel) Date: Fri Mar 5 04:30:01 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <4048615D.4050702@utopia.com.br> References: <707239AA-6E7D-11D8-9283-000A959B403C@caltech.edu> <4048615D.4050702@utopia.com.br> Message-ID: <826ED1E4-6EA8-11D8-9283-000A959B403C@caltech.edu> Dear Mr. Banffy Somewhat old-fashionedly, the mailing list is set up so that if you hit=20= the reply button in your email client, it replies to the sender, not to=20= the mailing list. This behavior is a near-religious issue with some=20 mailing list administrators that you probably don't want to touch, but=20= for the time being, you should probably use reply-all. I sometimes=20 forget, too. While I'm at it, let me comment on your message. /jaap On 5 Mar 2004, at 03:15, Ricardo L. A. B=E1nffy wrote: > Gentlemen, > > It can't be that hard to emulate a decades-old architecture (late=20 > 80's? 90's? - I remember reading about them at my college library) on=20= > a couple gigahertz current processor. I know the architecture was far=20= > more complex than an ordinary desktop computer of that time (and=20 > probably is now), but I doubt it is beyond the reach of a modern=20 > processor. Being somewhat of a bookworm, I'm always interested in written matters;=20= what was it you found about Lisp machines in your college library? > I remember my Pentium something (in Portuguese we call them Lentiums,=20= > which is not funny in English) could emulate a 68K Macintosh about=20 > twice as fast as a 68K Macintosh could emulate itself. There weren't=20= > more than 5 years between the two computers. Hmm... the joke *is* funny in French. At any rate, you are completely=20 right in this observation. > IIRC, OpenGenera did just that - emulation atop an Alpha. If an Alpha=20= > can do it, a Pentium 4 HT or a PowerPC 970 can. Yes, although OpenGenera *was* extremely well-bummed for speed. It was=20= written in straight alpha assembly, with a Lisp-based macro layer on=20 top, and the programmers took great care to lay out the segments of=20 code in such a way as to minimize cache misses. The crucial trick is=20 that the alpha's L1 cache was fast enough that it could practically=20 function as a microcode store, so that if you kept the simulator in=20 cache at all times, you would loose relatively little performance. That=20= said, time heals all wounds, and Moore's law certainly does, so I=20 wouldn't be surprised if you could do the same thing in a high-level=20 language just fine given a 970 (a.k.a. G5). > Implementing an emulator in software ("C" seems an obvious choice=20 > because of performance and portability, if not elegance) would also be=20= > a nice starting point to any hardware implementations. At least, if=20 > well written (as in "human-readable"), it could serve as a reference=20= > to what, exactly, the hardware should be doing. Sure; programming, as Sussman likes to say, is a way of expressing=20 ideas as much as a way to tell a computer what to do. (I hope I'm=20 quoting this right at 5 in the morning.) > If we are really serious about doing it, the rights to the software=20 > must also be sorted out. How generous are their owners? As I remember, but others know this much better than I do, TI (or=20 whoever bought them) doesn't want to admit that they own the=20 intellectual property to anything Exploder-related without consulting=20 their lawyers, for which you'd have to pay them money. The consensus at=20= the time was to not deal with legal issues until anyone is approaching=20= a working emulator. > We would also need functioning hardware to validate the emulator=20 > against. Can it be provided? I think some people on the list have running TI hardware. > As Alastair pointed out, it is a big, hard and scary thing to do,=20 > until actually doing it proves us wrong. Yes, and the main problem seems to be finding out the details of how=20 the system worked. If the project were to write an emulator for a=20 machine that was completely specified, the project would probably be=20 much further by now; unfortunately the brave hackers that have worked=20 on it so far seem to have to spend a lot of time reverse-engineering. > Jaap Weel wrote: > >> I'm trying to get into the whole FPGA thing because I'm supposed to=20= >> implement a CPU in one for my summer job. There have been various=20 >> reports from people doing interesting projects in surprisingly little=20= >> time given the right tools; look up fpgacpu.org for some pointers and=20= >> lots of FPGA shop talk. Especially his circuit cellar article gives a=20= >> good idea of the practicalities involved, I think. Once again, he's=20= >> doing RISC-like hardwired control, not microcoded control. I don't=20 >> know if anyone has tried microcoded control yet. > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jaap Weel Campus address: | dorm (626) 795-9748 Caltech, Blacker '05 Caltech MSC #874, Pasadena, CA 91126, U.S.A. www.its.caltech.edu/~weel Permanent address: | home +31-46-4337033 E-mail: weel@caltech.edu Kelderstraat 2-4, 6171 GB Stein, Netherlands =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From mark@buttery.org Fri Mar 5 05:47:00 2004 From: mark@buttery.org (Mark J. Dulcey) Date: Fri Mar 5 05:47:00 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <707239AA-6E7D-11D8-9283-000A959B403C@caltech.edu> References: <707239AA-6E7D-11D8-9283-000A959B403C@caltech.edu> Message-ID: <404892AA.2060207@buttery.org> Jaap Weel wrote: > Even though on LISP machines the microcode has the added advantage that > it can be reprogrammed easily, the original reason for Microcode as > opposed to Hardwired Control is that you could conserve precious silicon > area by having a really simple control unit (in the CADR, practically > none, since the microcode instruction set is notoriously simple; I don't > know much about the Exploder, but I imagine it's similar). This is why > I'm not too worried about needing humongous amounts of silicon. Many > FPGA's have built-in fast RAM that could contain microcode. > > Question: What is the Exploder microcode instruction set like? Is it > *much* different, conceptually, from CADR microcode? This would > determine the amount of FPGA area needed to implement the controller. If > it's anything like the CADR, my hunch is: not much. I don't have any direct knowledge of the TI Explorer architecture, but I believe it's similar. > Question: What is the word length on a uExploder again? (I'm sorry, I > can't ever keep the word lengths of all different LISP machines > detangled in my head.) The size of the datapath part of a design should > scale about linearly in the word length. Of course, it also depends on > how many different operations you need to do, how many registers you > need &c. Like all machines in the LMI branch of LispM heritage, the Explorer and uExplorer had 32 bit words. > Question: How much microcode is there? I.e. how much microcode RAM do > you need? True, the CADR, and its direct descendent the LMI Lambda, had fairly simple microcontrollers. They made up for this by using a LOT of microcode. The CADR originally had 8K of 48-bit microwords; the machines were later expanded to 12K, and then to 16K, to accomodate the increasing complexity of the microcode over time. (Later software versions put more functions into microcode.) The Lambda had 16K 64-bit microwords, and used most of it to implement the rather baroque macroinstruction set of the LispM. In addition, the Lambda had a 128K byte RAM - 64K 16 bit words - that was used for brute-force dispatching of the macroinstructions; by then, there were enough different formats that it took quite a few tests just to figure out what type of instruction something was, so the Lambda eliminated the problem with a complete jump table. All of these processors have more microcode than you would find in a modern RISC processor, though perhaps not more than an x86 implementation would have. I don't know how much microcode the TI LispMs had. From nyef@softhome.net Fri Mar 5 06:02:01 2004 From: nyef@softhome.net (Nyef) Date: Fri Mar 5 06:02:01 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <404892AA.2060207@buttery.org> References: <707239AA-6E7D-11D8-9283-000A959B403C@caltech.edu> <404892AA.2060207@buttery.org> Message-ID: <20040305145858.GA1810@miyu.paradiesanalytics.com> On Fri, Mar 05, 2004 at 09:46:02AM -0500, Mark J. Dulcey wrote: > Jaap Weel wrote: > > >Question: What is the Exploder microcode instruction set like? Is it > >*much* different, conceptually, from CADR microcode? This would > >determine the amount of FPGA area needed to implement the controller. If > >it's anything like the CADR, my hunch is: not much. > > I don't have any direct knowledge of the TI Explorer architecture, but I > believe it's similar. It is similar. In some ways more complex, in some ways simpler. > Like all machines in the LMI branch of LispM heritage, the Explorer and > uExplorer had 32 bit words. All Explorers had 32-bit data words. The Explorer I used a 56-bit microinstruction word, and the later systems used a 64-bit microinstruction word. > >Question: How much microcode is there? I.e. how much microcode RAM do > >you need? For the Explorer I, it is #x800 words for the startup microcode and #x4000 words for the writable microcode store. The Explorer I also needs #x40 words of M-memory, #x400 words of A-memory, 16 words of T-memory, #x1000 words of D-memory, 64 words of microstack, #x1000 words of level-1 map memory, #x1000 words of level-2 map control memory, #x1000 words of level-2 map address memory, and #x400 words of PDL-buffer memory. The microcode stores use a 56-bit word, the microstack uses something a bit less than 32 bits (I forget what, was it 17 bits?), and everything else uses 32-bit words. --Alastair Bridgewater From eb@comsec.com Fri Mar 5 10:21:01 2004 From: eb@comsec.com (Eric Blossom) Date: Fri Mar 5 10:21:01 2004 Subject: [LMH]FPGA / microcode In-Reply-To: <707239AA-6E7D-11D8-9283-000A959B403C@caltech.edu> References: <707239AA-6E7D-11D8-9283-000A959B403C@caltech.edu> Message-ID: <20040305191626.GA22608@comsec.com> On Fri, Mar 05, 2004 at 12:04:12AM -0800, Jaap Weel wrote: > On 4 Mar 2004, at 18:57, Dan Moniz wrote: > >On Thursday, March 04, 2004 7:01 PM +0000 Robert Swindells > > wrote: > >>I was only half joking about translating it to VHDL. > >>[...] > >>The whole CPU would fit into a $15 FPGA using current technology, add > >>a couple of 16bit SDRAMs and some boot flash and you have a 10x faster > >>microExplorer. > > > >[...] > >Of course, there's the longer term problem of getting a monitor and > >input devices to talk to it, which would be painful, and disks, file > >systems, a running install, oh my! > >Probably, now that I think about it, an FPGA-based Explorer processor > >on a PCI card, with some interface glue would be the way to go. I've considered the FPGA idea myself a few times. It would be fun ;-) One thing to remember, is that by today's standards, the Explorer's have dinky address spaces. 24MW if I recall correctly. I think that a blind re-implementation of the architecture would be a waste of time. Why spend all the time and end up with something with a dinky address space? Another thing to consider is the basic "back of the envelope calculation". For the sake of argument, assume that you're using a Spartan 2E or Spartan 3 (The spartan 3 has bunches of embedded multipliers. You could really speed up your bignum multiplies with them ;-)). Using the lower speed grades (much cheaper!) you can probably run them at about 125 MHz (hands waving wildly...). This gives you a 125 MHz microinstruction cycle. Of course, you're free to build your memory subsystem as wide as you like, so make it 40-bits or 48-bits or 64-bits... Now, on the other hand, you're competing against 3 GHz Pentiums or AMD64s or Opterons running at 2.6GHz or so. All of these have an incredible amount of internal parallelism. You can easily get 4 or 5 operations going per cycle (this includes address generator updates, ALU ops, floating point adds, mults, loads, etc). Without working hard, this gives you an easy 6M ops/second. It's going to be really hard to get your 125 MHz FPGA implementation to even begin to keep up with these monsters. Perhaps the way to go would be do define yet-another-lisp-virtual-machine, or figure out what symbolics used (or just use Common Lisp with lots of declarations!) and target the AMD64 architecture. It's got twice as many registers as the x86, lots of address space, they keep getting faster and cheaper all the time, and you can order one today, and have it delivered tomorrow. If people really like the idea of running near the metal, consider using something like the L4 microkernel or EROS as the bottom layer. http://os.inf.tu-dresden.de/L4/ http://www.eros-os.org/ EROS implements a persistent single-level store, which would be ideal for lisp. This means everything is addressed the same. All of memory is persistent. There is no "file system", just a directory of objects. EROS is also capability based, which is also very cool, but not directly relevant to this discussion. > I don't know if this is applicable, but hey, you never know. When they > made OpenGenera (you know, the virtual Symbolics-on-Alpha), they didn't > give it any intrinsic knowledge about DEC's hardware. All it knew how > to do was to talk on the network. It would then find its filesystem > through NSF, display its interface through X11, and in various other > ways leverage the fact that there was always a copy of OSF/1 to take > care of bit-diddling IO. It's not very purist, but you could do a lot > with a network interface, while a $200 Walmart FORTRAN Machine can take > care of I/O. This seems like a reasonable approach to me. Otherwise you're always going to be "behind the power curve" when it comes to supporting new peripheral hardware. Let's just use it! Note that this is how the microExplorers work too. NFS and RPC to access the file system and display/mouse/keyboard respectively. The other approach would be to take a decent compiled CL implementation (e.g., SBCL) and start moving it closer to the metal. Let's not forget that compilers are a lot smarter now than they were 15 years ago. I personally think that experimenting with a machine with persistent memory would be fun. FYI, there's a port of SBCL to the AMD64 underway. Eric From rjs@fdy2.demon.co.uk Fri Mar 5 11:00:01 2004 From: rjs@fdy2.demon.co.uk (Robert Swindells) Date: Fri Mar 5 11:00:01 2004 Subject: [LMH]FPGA / microcode In-Reply-To: <20040305191626.GA22608@comsec.com> (message from Eric Blossom on Fri, 5 Mar 2004 11:16:26 -0800) Message-ID: <200403051956.i25JuXKO085976@ren.fdy2.net> Eric Blossom wrote: >> On 4 Mar 2004, at 18:57, Dan Moniz wrote: >> >On Thursday, March 04, 2004 7:01 PM +0000 Robert Swindells >> > wrote: >> >>I was only half joking about translating it to VHDL. >> >>[...] >> >>The whole CPU would fit into a $15 FPGA using current technology, add >> >>a couple of 16bit SDRAMs and some boot flash and you have a 10x faster >> >>microExplorer. >> > >> >[...] >> >Of course, there's the longer term problem of getting a monitor and >> >input devices to talk to it, which would be painful, and disks, file >> >systems, a running install, oh my! >> >Probably, now that I think about it, an FPGA-based Explorer processor >> >on a PCI card, with some interface glue would be the way to go. >I've considered the FPGA idea myself a few times. It would be fun ;-) >One thing to remember, is that by today's standards, the Explorer's >have dinky address spaces. 24MW if I recall correctly. I think that >a blind re-implementation of the architecture would be a waste of >time. Why spend all the time and end up with something with a dinky >address space? The attraction of a LispM over a Lisp system on stock hardware is the integrated environment. It is a lot easier to migrate to a larger address space when you have a running system. >Another thing to consider is the basic "back of the envelope >calculation". For the sake of argument, assume that you're using a >Spartan 2E or Spartan 3 (The spartan 3 has bunches of embedded >multipliers. You could really speed up your bignum multiplies with >them ;-)). Using the lower speed grades (much cheaper!) you can >probably run them at about 125 MHz (hands waving wildly...). This >gives you a 125 MHz microinstruction cycle. Of course, you're free to >build your memory subsystem as wide as you like, so make it 40-bits or >48-bits or 64-bits... The Spartan 3s are cheap in any speed grade. They are in rather short supply at the moment though. >Now, on the other hand, you're competing against 3 GHz Pentiums or >AMD64s or Opterons running at 2.6GHz or so. All of these have an >incredible amount of internal parallelism. You can easily get 4 or 5 >operations going per cycle (this includes address generator >updates, ALU ops, floating point adds, mults, loads, etc). Without >working hard, this gives you an easy 6M ops/second. It's going >to be really hard to get your 125 MHz FPGA implementation to even >begin to keep up with these monsters. I'm not suggesting that a FPGA LispM will compete with a native lisp running on the fastest desktop or server CPUs. The fast CPUs require a lot of cooling and won't run for long on batteries. Think instead of competing with PDA class CPUs, these are 400-500 MHz in-order RISC processors that use ~500mW. I think you are going to see a lot of products released over the next year that use soft CPU cores in FPGAs for embedded applications. Most of these will run something based on Linux, but they could run something else. >Perhaps the way to go would be do define >yet-another-lisp-virtual-machine, or figure out what symbolics used (or >just use Common Lisp with lots of declarations!) and target the AMD64 >architecture. It's got twice as many registers as the x86, lots of >address space, they keep getting faster and cheaper all the time, and >you can order one today, and have it delivered tomorrow. Rather than define another one, why not follow KMP's suggestion and make a business proposal to new Symbolics. Someone, or a small group, could offer to port the VLM to AMD64 in exchange for X number of licences to use the finished product. Robert Swindells From eb@comsec.com Fri Mar 5 11:40:01 2004 From: eb@comsec.com (Eric Blossom) Date: Fri Mar 5 11:40:01 2004 Subject: [LMH]FPGA / microcode In-Reply-To: <200403051956.i25JuXKO085976@ren.fdy2.net> References: <20040305191626.GA22608@comsec.com> <200403051956.i25JuXKO085976@ren.fdy2.net> Message-ID: <20040305203534.GA22931@comsec.com> On Fri, Mar 05, 2004 at 07:56:33PM +0000, Robert Swindells wrote: > Eric Blossom wrote: >> > > The attraction of a LispM over a Lisp system on stock hardware is > the integrated environment. Perhaps I'm missing something? What's stopping us from having an integrated environment on stock hardware? I see that we could have lisp code that directly addresses the frame buffer, or for that matter, lisp code that directly manipulates the page table entries on stock hardware. For that matter, why not just compile the LispM lisp source to AMD64 native instructions? > It is a lot easier to migrate to a larger address space when you > have a running system. Sure. > >Perhaps the way to go would be do define > >yet-another-lisp-virtual-machine, or figure out what symbolics used (or > >just use Common Lisp with lots of declarations!) and target the AMD64 > >architecture. It's got twice as many registers as the x86, lots of > >address space, they keep getting faster and cheaper all the time, and > >you can order one today, and have it delivered tomorrow. > > Rather than define another one, why not follow KMP's suggestion and > make a business proposal to new Symbolics. > > Someone, or a small group, could offer to port the VLM to AMD64 in > exchange for X number of licences to use the finished product. Not a bad idea, but it leaves us in the same mess we're in now: No free software / open source lisp machine. I suggest that we learn from the examples of the past, but start new, with free software all the way to the bottom. We've got good free compilers already. There's McCLIM for the display. There are a couple of emacs-ish editors in CL. We may not actually be that far away. Eric From mikemac@mikemac.com Fri Mar 5 11:47:01 2004 From: mikemac@mikemac.com (Mike McDonald) Date: Fri Mar 5 11:47:01 2004 Subject: [LMH]FPGA / microcode In-Reply-To: Your message of "Fri, 05 Mar 2004 12:35:34 PST." <20040305203534.GA22931@comsec.com> Message-ID: <200403052046.i25KkjR03042@saturn.mikemac.com> >To: Robert Swindells >Date: Fri, 5 Mar 2004 12:35:34 -0800 >From: Eric Blossom > >Not a bad idea, but it leaves us in the same mess we're in now: >No free software / open source lisp machine. > >I suggest that we learn from the examples of the past, but start new, >with free software all the way to the bottom. We've got good free >compilers already. There's McCLIM for the display. There are a >couple of emacs-ish editors in CL. We may not actually be that far >away. Oh no! Not the dreaded "lets write a LispOS from scratch" thread again! :-) The LispM environment is the result of a lot of very smart people putting in a lot of years work on it. It's not something that is easily duplicated. Mike McDonald mikemac@mikemac.com From rbanffy@utopia.com.br Fri Mar 5 12:07:01 2004 From: rbanffy@utopia.com.br (=?ISO-8859-1?Q?Ricardo_B=E1nffy?=) Date: Fri Mar 5 12:07:01 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <826ED1E4-6EA8-11D8-9283-000A959B403C@caltech.edu> Message-ID: <59B960FC-6EE9-11D8-AEC4-000502C1962C@utopia.com.br> On Friday, March 5, 2004, at 10:25 AM, Jaap Weel wrote: > Somewhat old-fashionedly, the mailing list is set up so that if you > hit the reply button in your email client, it replies to the sender, > not to the mailing list. This behavior is a near-religious issue with > some mailing list administrators that you probably don't want to > touch, but for the time being, you should probably use reply-all. I > sometimes forget, too. While I'm at it, let me comment on your > message. If it is a religious issue, I can live with it ;-) > Being somewhat of a bookworm, I'm always interested in written > matters; what was it you found about Lisp machines in your college > library? Discussions about AI-related stuff and ads featuring machines that looked amazingly cool ;-) > The consensus at the time was to not deal with legal issues until > anyone is approaching a working emulator. We could do something in the political sphere. I bet they don't expect to extract much cash from this, but they could win sympathy. Having said that, the Hercules mainframe emulator keeps coming to my mind. IBM could license more software for hobbyist or education purposes. >> As Alastair pointed out, it is a big, hard and scary thing to do, >> until actually doing it proves us wrong. > Yes, and the main problem seems to be finding out the details of how > the system worked. If the project were to write an emulator for a > machine that was completely specified, the project would probably be > much further by now; unfortunately the brave hackers that have worked > on it so far seem to have to spend a lot of time reverse-engineering. You mean there is no documentation on low level programming?! Oh boy... This may just be a big hard and scary thing to do and actually doing it may prove us right ;-) Have the results of this reverse-engineering been published? I can't find much about it. From eb@comsec.com Fri Mar 5 12:21:01 2004 From: eb@comsec.com (Eric Blossom) Date: Fri Mar 5 12:21:01 2004 Subject: [LMH]FPGA / microcode In-Reply-To: <200403052046.i25KkjR03042@saturn.mikemac.com> References: <20040305203534.GA22931@comsec.com> <200403052046.i25KkjR03042@saturn.mikemac.com> Message-ID: <20040305211652.GA22982@comsec.com> On Fri, Mar 05, 2004 at 03:46:45PM -0500, Mike McDonald wrote: > > >To: Robert Swindells > >Date: Fri, 5 Mar 2004 12:35:34 -0800 > >From: Eric Blossom > > > >Not a bad idea, but it leaves us in the same mess we're in now: > >No free software / open source lisp machine. > > > >I suggest that we learn from the examples of the past, but start new, > >with free software all the way to the bottom. We've got good free > >compilers already. There's McCLIM for the display. There are a > >couple of emacs-ish editors in CL. We may not actually be that far > >away. > > Oh no! Not the dreaded "lets write a LispOS from scratch" thread > again! :-) > > The LispM environment is the result of a lot of very smart people > putting in a lot of years work on it. Agreed. > It's not something that is easily duplicated. Particulary if we never start ;-) However, let's get real. The existing LispM environments are effectively dead. The sources for them are encumbered by various companies, some of which are pretty close to zombies, but which still have stockholders to answer to. Unless the copyright holders release the source we're stuck. Yes, I know the source is around, but we'll never really get this thing off the ground if there isn't good, clear title to the code. The other thing to remember is that those smart people wrote a lot of papers. It's a lot easier to write code when you already know where you're trying to get to. I'm not proposing "let's write a LispOS from scratch", I'm asking "What was it about the lisp machines that made them great?" extrapolate fifteen or twenty years, now how can we get there, only this time with free software? Maybe this is the dreaded "lets write a LispOS from scratch" thread... Eric From weel@caltech.edu Fri Mar 5 12:30:01 2004 From: weel@caltech.edu (Jaap Weel) Date: Fri Mar 5 12:30:01 2004 Subject: [LMH]FPGA / microcode In-Reply-To: <200403052046.i25KkjR03042@saturn.mikemac.com> References: <200403052046.i25KkjR03042@saturn.mikemac.com> Message-ID: <9AC077A2-6EEB-11D8-9283-000A959B403C@caltech.edu> "I was an old fart when I was in my twenties" -- Alan Kay Don't be too offended; just realize that there was a LispOS mailing list that discussed for 2 entire years about CL vs. Scheme, VM vs. native, from scratch vs. Linux-based. The list archive greatly exceeds in size the code that was ever written. Hence, there is a strong feeling among people who have witnessed these endless discussions before that talking about "LispOS" on mailing lists is intrinsically wasteful of time. All that said, please do check out Movitz. /jaap On 5 Mar 2004, at 12:46, Mike McDonald wrote: >> To: Robert Swindells >> >> I suggest that we learn from the examples of the past, but start new, >> with free software all the way to the bottom. We've got good free >> compilers already. There's McCLIM for the display. There are a >> couple of emacs-ish editors in CL. We may not actually be that far >> away. > > Oh no! Not the dreaded "lets write a LispOS from scratch" thread > again! :-) > > The LispM environment is the result of a lot of very smart people > putting in a lot of years work on it. It's not something that is > easily duplicated. > > Mike McDonald From bmastenb@cs.indiana.edu Fri Mar 5 12:38:01 2004 From: bmastenb@cs.indiana.edu (Brian Mastenbrook) Date: Fri Mar 5 12:38:01 2004 Subject: [LMH]FPGA / microcode In-Reply-To: <20040305203534.GA22931@comsec.com> References: <20040305191626.GA22608@comsec.com> <200403051956.i25JuXKO085976@ren.fdy2.net> <20040305203534.GA22931@comsec.com> Message-ID: <43541C80-6EED-11D8-BAE3-000A9599AF88@cs.indiana.edu> > Not a bad idea, but it leaves us in the same mess we're in now: > No free software / open source lisp machine. > > I suggest that we learn from the examples of the past, but start new, > with free software all the way to the bottom. We've got good free > compilers already. There's McCLIM for the display. There are a > couple of emacs-ish editors in CL. We may not actually be that far > away. If you haven't been paying attention, you ought to look at what the rest of the lisp world is doing with cirCLe: http://ww.telent.net/diary/ -- Brian Mastenbrook bmastenb@cs.indiana.edu http://cs.indiana.edu/~bmastenb/ From eb@comsec.com Fri Mar 5 17:14:01 2004 From: eb@comsec.com (Eric Blossom) Date: Fri Mar 5 17:14:01 2004 Subject: [LMH]FPGA / microcode In-Reply-To: <9AC077A2-6EEB-11D8-9283-000A959B403C@caltech.edu> References: <200403052046.i25KkjR03042@saturn.mikemac.com> <9AC077A2-6EEB-11D8-9283-000A959B403C@caltech.edu> Message-ID: <20040306020937.GA23329@comsec.com> On Fri, Mar 05, 2004 at 01:25:20PM -0800, Jaap Weel wrote: > "I was an old fart when I was in my twenties" > -- Alan Kay > > Don't be too offended; just realize that there was a LispOS mailing > list that discussed for 2 entire years about CL vs. Scheme, VM vs. > native, from scratch vs. Linux-based. The list archive greatly exceeds > in size the code that was ever written. Hence, there is a strong > feeling among people who have witnessed these endless discussions > before that talking about "LispOS" on mailing lists is intrinsically > wasteful of time. > > All that said, please do check out Movitz. > > /jaap > Thanks for references to the LispOS list and Movitz. There's a ton clueful discussion in the LispOS list archives. Too bad no lisp LispOS came out of it :-) Eric From hans@huebner.org Sat Mar 6 04:34:00 2004 From: hans@huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sat Mar 6 04:34:00 2004 Subject: [LMH]FPGA / microcode In-Reply-To: <20040305191626.GA22608@comsec.com> References: <707239AA-6E7D-11D8-9283-000A959B403C@caltech.edu> <20040305191626.GA22608@comsec.com> Message-ID: <20040306134112.F78197@exklave.huebner.org> On Fri, 5 Mar 2004, Eric Blossom wrote: > Another thing to consider is the basic "back of the envelope > calculation". For the sake of argument, assume that you're using a > Spartan 2E or Spartan 3 (The spartan 3 has bunches of embedded > multipliers. [...] Speed is not the (major) point which drives the wish for an Explorer emulator. The original Explorer was indeed fast enough for a number of serious tasks, so having an implementation of it which is, say, ten times faster than the original hardware gives a lot of speedup for new applications. Price is much more influencial. If I read the latest comments correctly, a FPGA explorer could cost around $100 in chips, which is really in the (grown-up) toy price range. The reason to want Lisp hardware is the fact that such a CPU would eliminate a lot of complexity levels which are present when using LISP on a general purpose machine. Lisp hardware puts the whole computer, and not only a virtual image of a non-existing system, directly under control of the LISP code you work with in your development environment. If you need to work at high levels of abstraction, you can formulate suitable algorithms readably. If you need to handle interrupts within a certain amount of time, you can again formulate solutions in the same language and environment which is your high-level problem solving tool. Using the Explorer as starting hardware has the beauty that a lot of work has already been done by smart people. For example, TI's Emacs implementation Zmacs seems to be very good - at least from what I read from the excellent documentation. Having a working development environment within the new plattform is a really big plus, since otherwise you almost certainly end up cross compiling from Windows or Unix and having to spend time fixing the broken development environment instead of the target platform. It is true that the limited word length of the Explorer restricts the usefulness of any new implementation to problems of a certain maximum size. Still, I think it would be a excellent platform for applications like mail and personal information management as well as text processing. To me, these applications are not solved satisfactory by current software environments and I'd rather store and process all my email, contact information and appointments within a portable solid-state Lisp system than in Outlook or Unix files. There have been a lot of ambitious open source developments for advanced operating systems and development environments. None of the projects I am aware of have had any significant visibility, unless they have been directly funded and influenced by the industry. Using the existing Explorer code base would have such a funding in form of the intellectual property of TI (or whoever), which truly pushes the whole effort into some uncertainity. I am very curious to see this progress and I hope that enough free energy can be accumulated to get a new Explorer implementation running. Best regards, Hans From james@unlambda.com Sun Mar 7 19:16:01 2004 From: james@unlambda.com (James A. Crippen) Date: Sun Mar 7 19:16:01 2004 Subject: Infrastructure update (was Re: [LMH] Ooh, look! List traffic!) In-Reply-To: <59B960FC-6EE9-11D8-AEC4-000502C1962C@utopia.com.br> (Ricardo =?iso-8859-1?q?B=E1nffy's?= message of "Fri, 5 Mar 2004 18:09:11 -0300") References: <59B960FC-6EE9-11D8-AEC4-000502C1962C@utopia.com.br> Message-ID: Ricardo B=E1nffy writes: > If it is a religious issue, I can live with it ;-) I have it set up that way because it seemed to me when I first set up the list that the world expected mailing lists to be so configured that way. However, one of these days when I'm out from under my enormous pile of papers (taking two history courses and a philosophy course in one semester was in retrospect a stupid thing to do), I'll get back to building a kappa replacement. I have a couple of adequate systems and disks rescued from a dumpster, and I've gotten most of the way towards getting them usable, but I still need to get DNS, qmail, and Mailman running, and copy over the home directories. All that requires that I actually clean a path through the computer room to the computers in question, and that will take at least as much time to do. After kappa is rebuilt and restored I intend to put the temporary computer to use as a file server, which will free up space from kappa's sagging disks and add 10GB to the available storage. I'm also considering converting the repo to Subversion, but that's for later discussion. It seems to be much more efficient and has less problems with firewalls than does CVS. >> Being somewhat of a bookworm, I'm always interested in written matters; >> what was it you found about Lisp machines in your college library? > > Discussions about AI-related stuff and ads featuring machines that looked > amazingly cool ;-) Mine has, for some reason completely unbenknownst to any of the CS faculty, a copy of the INTERLISP manual from the PDP-10 days. I don't recall the exact date, but it didn't mention INTERLISP-D at all. Nobody here actually even knew what INTERLISP was except me. I don't think any of them knew what a PDP-10 was either. Which is one reason why I'm changing schools soon. That one apart from the Winston-Horn book is the only Lisp stuff I could find in our library. Strange. Although I did find a binder labeled "VAX NIL" and another labeled "TI PC Scheme" in the trash one day. No idea where those came from, and they didn't include contents. Kept them for hysterical value. >> The consensus at the time was to not deal with legal issues until anyone >> is approaching a working emulator. > > We could do something in the political sphere. I bet they don't expect to > extract much cash from this, but they could win sympathy. Having said tha= t, > the Hercules mainframe emulator keeps coming to my mind. IBM could license > more software for hobbyist or education purposes. I really think given the current `debates' going on in the wider world about software that we should stick to the original plan of having something working before we start pestering TI for rights. I'd really rather not have some lawyer after me with the DMCA in his hand right now, and I think my name, Alastair's, and John's are the three most well known out there. I suppose if there's still nothing really working (enough to give a working Lisp interpreter) in a couple more years people could start doing whatever they want. But I suspect that both JM and Nyef would like to avoid lawyers as much as I would right now. My father got a call from a lawyer in San Francisco last summer who was asking him about something to do with Lisp. He said he figured the guy got his name from the phone book (we have the same first and last names) and called him. My father gave the guy my number but he never followed up. And that was close enough for me. I want to at least have my degree done before I have to fuss with law. > You mean there is no documentation on low level programming?! Oh boy... T= his > may just be a big hard and scary thing to do and actually doing it may pr= ove > us right ;-) Have the results of this reverse-engineering been published?= I > can't find much about it. Alastair has done an incredible amount of reverse engineering already. I have complete confidence in his skills, even if he doesn't. ;-) I never have the time to help, which is horribly unfortunate, because I'd absolutely love to do so. But if anyone else is really genuinely interested I recommend them reading through all of the threads in which he's posted details, and then reading what he's got done so far very carefully. Then ask him for recommendations on where to start. The real trick is not to see the huge amorphous mass of undefined hardware and microcode, but to look at the system one instruction at a time. Nyef's had really great success with this approach. 'james --=20 James A. Crippen Lambda Unlimited 61.2204N, -149.8964W Recursion 'R' Us Anchorage, Alaska, USA, Earth Y =3D \f.(\x.f(xx))(\x.f(xx)) From james@unlambda.com Sun Mar 7 19:23:01 2004 From: james@unlambda.com (James A. Crippen) Date: Sun Mar 7 19:23:01 2004 Subject: [LMH]FPGA / microcode In-Reply-To: <200403052046.i25KkjR03042@saturn.mikemac.com> (Mike McDonald's message of "Fri, 05 Mar 2004 15:46:45 -0500") References: <200403052046.i25KkjR03042@saturn.mikemac.com> Message-ID: Mike McDonald writes: > Oh no! Not the dreaded "lets write a LispOS from scratch" thread > again! :-) Yes, let's keep it off here, please. People who want a PC Lisp OS should look at Movitz. Hardware hackers can of course do whatever they'd like, but this is probably not the best place to discuss it unless it's a hardware emulator of one of the existing LispMs, in which case it's totally on topic. Not that I mind the list traffic or anything, but I just don't think we should resurrect the LispOS thread. It lowers the S/N ratio far too much. And poor kappa is drowning under spam already... > The LispM environment is the result of a lot of very smart people > putting in a lot of years work on it. It's not something that is > easily duplicated. This is even more true than people often think. Consider that both Symbolics and LMI never abandoned the MIT sources to start over. And TI kept with the MIT sources as well. Even Genera 8.3 still includes an enormous amount of MIT code, because it's far too much work to throw away. People love to talk about creating OSes and OEs from scratch, but very few people seem to enjoy actually doing the work. (I should be one to talk. I never get any of my hacking projects finished. *sigh*) 'james -- James A. Crippen Lambda Unlimited 61.2204N, -149.8964W Recursion 'R' Us Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx)) From nyef@softhome.net Mon Mar 8 05:45:01 2004 From: nyef@softhome.net (Nyef) Date: Mon Mar 8 05:45:01 2004 Subject: Infrastructure update (was Re: [LMH] Ooh, look! List traffic!) In-Reply-To: References: <59B960FC-6EE9-11D8-AEC4-000502C1962C@utopia.com.br> Message-ID: <20040308144117.GA6484@miyu.paradiesanalytics.com> On Sun, Mar 07, 2004 at 07:15:39PM -0900, James A. Crippen wrote: > > I really think given the current `debates' going on in the wider world > about software that we should stick to the original plan of having > something working before we start pestering TI for rights. I'd really > rather not have some lawyer after me with the DMCA in his hand right > now, and I think my name, Alastair's, and John's are the three most > well known out there. I suppose if there's still nothing really > working (enough to give a working Lisp interpreter) in a couple more > years people could start doing whatever they want. But I suspect that > both JM and Nyef would like to avoid lawyers as much as I would right > now. Right now our biggest safeguards is not having working emulators and not having the ROM files easily accessible. Even if they know we're working on it, it's not such a big deal when only a select few people (most of whom would be in the market for the real thing -anyway-) can actually do anything with it. As it stands, I suspect that when we get everything close to working we should have the emulators and ROMs hosted on different sites by different people. And the ROM sites should be hard to get to. Which, admittedly, is just about how things are now. You basically have to ask someone who already has the ROMs and disk images to share. At that point we might consider writing a few academic-looking papers on the design of the emulators and the process of their creation, and try and keep everything as innocent-looking as possible. Or not. > > You mean there is no documentation on low level programming?! Oh boy... This > > may just be a big hard and scary thing to do and actually doing it may prove > > us right ;-) Have the results of this reverse-engineering been published? I > > can't find much about it. > > Alastair has done an incredible amount of reverse engineering > already. I have complete confidence in his skills, even if he > doesn't. ;-) My skills I have confidence in. My patience and continued interest, I don't. James, you aren't the only one who has trouble finishing projects. ^_- And, actually, -some- of the low-level programming information has been turning up. Usually shortly after I figure it out for myself. Amazing synchrony there. Most of what we don't have documentation for now is the internals of the CPU, particularly the ALU setup, and the memory boards. Scans for the SIB, NuPI, CPU, and ethernet boards are available, as are scans of parts of the maintenance manuals. > I never have the time to help, which is horribly > unfortunate, because I'd absolutely love to do so. But if anyone else > is really genuinely interested I recommend them reading through all of > the threads in which he's posted details, and then reading what he's > got done so far very carefully. Then ask him for recommendations on > where to start. For exploiter: Read all of SSDN2, ucode/def-elroy.lisp, ucode/defop.lisp ucode/lroy-qcom.lisp, ucode/lroy-qdev.lisp, ucode/lroy-templates.lisp, the list archives (particularly the Bug in SSDN2 posts), and then run exploiter and start reading through the output trying to line it up to the source tarball (remembering that the load band you use may be out of date with respect to the sources we have). For nevermore: Do the exploiter list (except maybe the bit about running exploiter) and read E1-proc-gen.pdf (except for the stuff about macroinstructions), ucode/ravfmt.lisp, ucode/ravsym.lisp, and anything in the list archives by Steve Krueger. Also hit up the bitsavers.org document archive and grab all the TI Explorer docs. Read anything that sounds like it is about hardware rather than software. Run nevermore for a while by single-stepping through instructions. Figure out how to make the nevermore disassembler work against prom-memory instead of reading from the prom_combined file (that none of you have). Disassemble the boot prom, figure out what it does (having an emulator here helps a -lot-, that's why I wrote nevermore in the first place). Actually, fixing up the disassembler would be a good first project for someone to get involved in nevermore. Making it work on a .mcr file would just be a bonus (now that we know the file format). Wait until I release a new version before starting, though, since I sortof changed some of the data formats... The game plan, if anyone wants to fix the disassembler, is to wait until the new version of nevermore, fix the disassembler as it is now, then I will release my current disassembly and symbol table files, then whoever is working on the disassembler can see about adding .mcr file support for Explorer I microloads (since they will then know what the file format is). > The real trick is not to see the huge amorphous mass of undefined > hardware and microcode, but to look at the system one instruction at a > time. Nyef's had really great success with this approach. That's because this approach is the one that works for me. As an example, instead of looking at the second instruction in the first function in the lisp load band and saying "Oh no, CALL-1-DEST-INDS is a function call instruction, that means we have to implement function calling next", what I do is look at it and say "Hrm... CALL-1-DEST-INDS is a function call instruction, what is it calling in this case? Oh, a DTP-FUNCTION? And what state do I have to set up to start in on the next function? Oh, I need to set up an args pointer, a locals pointer, reserve space for the locals, and set up the new function pointer. Oh, and make sure that the emulator dies with an error message if we try to call anything other than a DTP-FUNCTION. And don't bother saving the information for the return instructions, I'll deal with that when I get to them. I wonder what neat things I'll learn trying to step through this next function?" I stuck all of this in under a check specifically for the CALL-1-DEST-INDS instruction used in that first function. Any other call instruction would stop the emulator with an undefined opcode message. I hack through things this way, just handling the bare minimum of any situation that I don't understand, until I have enough information to go back and do it right. It's not exactly an approach to writing software, it's more an approach to learning about something that creates software as part of the learning process. The upside is that it leaves a record of the understanding gained. The downside is that that record is relatively difficult to interpret. About how long after we get this working do you think it'll be before someone tries to cross-build SBCL from it? ^_^ --Alastair From lars@nocrew.org Mon Mar 8 05:57:00 2004 From: lars@nocrew.org (Lars Brinkhoff) Date: Mon Mar 8 05:57:00 2004 Subject: Infrastructure update (was Re: [LMH] Ooh, look! List traffic!) In-Reply-To: <20040308144117.GA6484@miyu.paradiesanalytics.com> References: <59B960FC-6EE9-11D8-AEC4-000502C1962C@utopia.com.br> <20040308144117.GA6484@miyu.paradiesanalytics.com> Message-ID: <857jxvmlpw.fsf@junk.nocrew.org> Nyef writes: > we might consider writing a few academic-looking papers on the > design of the emulators and the process of their creation, and try > and keep everything as innocent-looking as possible. Sounds much like what Bob Supnik has done with the SIMH project. One strategy could be to release a LispM emulator under the SIMH brand, to make it more legitimate as a historical preservation project. -- Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP Brinkhoff Consulting http://www.brinkhoff.se/ From rbanffy@utopia.com.br Mon Mar 8 19:34:00 2004 From: rbanffy@utopia.com.br (=?ISO-8859-1?Q?=22Ricardo_L=2E_A=2E_B=E1nffy=22?=) Date: Mon Mar 8 19:34:00 2004 Subject: Infrastructure update (was Re: [LMH] Ooh, look! List traffic!) In-Reply-To: <857jxvmlpw.fsf@junk.nocrew.org> References: <59B960FC-6EE9-11D8-AEC4-000502C1962C@utopia.com.br> <20040308144117.GA6484@miyu.paradiesanalytics.com> <857jxvmlpw.fsf@junk.nocrew.org> Message-ID: <404D48F4.7070307@utopia.com.br> Lars Brinkhoff wrote: > Nyef writes: > >> we might consider writing a few academic-looking papers on the >> design of the emulators and the process of their creation, and try >> and keep everything as innocent-looking as possible. > > > > Sounds much like what Bob Supnik has done with the SIMH project. One > strategy could be to release a LispM emulator under the SIMH brand, to > make it more legitimate as a historical preservation project. > But this IS a historical preservation project. Is anyone here expecting to accomplish any real work on emulators? Anyway, I am sure that anything done after Nyef wrote that will never look innocent enough. From james@unlambda.com Tue Mar 9 10:28:01 2004 From: james@unlambda.com (James A. Crippen) Date: Tue Mar 9 10:28:01 2004 Subject: [LMH]Re: Infrastructure update In-Reply-To: <20040308144117.GA6484@miyu.paradiesanalytics.com> (nyef@softhome.net's message of "Mon, 8 Mar 2004 09:41:17 -0500") References: <59B960FC-6EE9-11D8-AEC4-000502C1962C@utopia.com.br> <20040308144117.GA6484@miyu.paradiesanalytics.com> Message-ID: Nyef writes: > About how long after we get this working do you think it'll be before > someone tries to cross-build SBCL from it? ^_^ The same week that the C compiler works. After SBCL is mostly ported some damned fool will try porting GCC. And then of course they will team up with some other evil mongrels and port Linux to it, which will be its (the Exploder's) undoing. But probably a good thing for Linux. 'james -- James A. Crippen Lambda Unlimited 61.2204N, -149.8964W Recursion 'R' Us Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx)) From nyef@softhome.net Wed Mar 10 15:39:00 2004 From: nyef@softhome.net (Nyef) Date: Wed Mar 10 15:39:00 2004 Subject: [LMH]Memory board docs? Message-ID: <20040311003451.GA10084@miyu.paradiesanalytics.com> Hello all. Does anyone have a copy of the memory board manual? The name and part number is: Explorer Memory General Description (8-megabytes) 2533592-0001 It doesn't appear to be on bitsavers.org with the rest of the docs, and I'm somewhat at a loss as to what's going on with the parity tests on the configuration rom. --Alastair From ford@objs.com Wed Mar 10 16:42:00 2004 From: ford@objs.com (ford@objs.com) Date: Wed Mar 10 16:42:00 2004 Subject: [LMH]Memory board docs? In-Reply-To: <20040311003451.GA10084@miyu.paradiesanalytics.com> References: <20040311003451.GA10084@miyu.paradiesanalytics.com> Message-ID: <404FC37B.1030003@objs.com> This is a multi-part message in MIME format. --------------000105050801000208000208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have that manual somewhere (I attached the list of the manuals I have). I'll dig it up and scan the TOC. Steve Nyef wrote: >Hello all. > >Does anyone have a copy of the memory board manual? The name and part >number is: > >Explorer Memory General Description (8-megabytes) 2533592-0001 > >It doesn't appear to be on bitsavers.org with the rest of the docs, >and I'm somewhat at a loss as to what's going on with the parity tests >on the configuration rom. > >--Alastair > >http://lists.unlambda.com/mailman/listinfo/lispm-hackers > > > --------------000105050801000208000208 Content-Type: text/html; charset=ISO-8859-1; name="manuals.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="manuals.html" THE EXPLORER TM SYSTEM SOFTWARE MANUALS I scanned in the manual list for the two major Explorer eras, the original 1985 release of the Explorer (through 1986), and the release of the Explorer II and Release 3.0 in the summer of 1987.  I have copies of the manuals for which there is a Rev date on the right.  I'm willing to scan in TOCs and relatively small numbers of pages upon request, or take one out to be copied.  My scanner's not up to more than that.

Steve

THE EXPLORERTM SYSTEM SOFTWARE MANUALS (May 1986)

Mastering the Explorer Environment

Explorer Technical Summary                               2243189-0001  Rev B May 86
                                                                       Rev C May 87
Explorer Operations Guide                                2243190-0001  Rev A May 86
Explorer Zmacs Editor Tutorial                           2243191-0001
Explorer Glossary                                        2243134-0001  Orig  Jun 85
                                                                       Rev A Jun 87
Explorer Communications User's Guide                     2243206-0001  Rev A Mar 86
Explorer Diagnostics                                     2533554-0001
Explorer Master Index to Software Manuals                2243198-0001  Orig  Jun 85
                                                                       Rev B Jan 88
Explorer System Software Installation                    2243205-0001  Rev B May 86
Explorer System Software Release Information Rel 2.0                   Rev C Mar 86

Programming With the Explorer

Explorer Programming Primer                              2243199-0001  Orig  Jun 85
Common LISP, The Language, by Guy L. Steele, Jr.         2537175-0001
Explorer Lisp Reference                                  2243201-0001
Explorer Zmacs Editor Reference                          2243192-0001
Explorer Programming Concepts and Tools                  2243130-0001  Orig  Jun 85
Explorer Window System Reference                         2243200-0001  Orig  Jun 85
Explorer Command Interface Toolkit User's Guide          2243197-0001  Orig  Jun 85

Explorer Toolkits

Explorer Natural Language Menu System User's Guide       2243202-0001
Explorer Natural Language Menu System Technical Report                 Orig  Jun 85
Explorer Relational Table Management System User's Guide 2243203-0001  Chg 1 Mar 86
Explorer Graphics Toolkit User's Guide                   2243195-0001
Explorer Grasper User's Guide                            2243135-0001
Explorer Prolog Toolkit User's Guide                     2243204-0001
Programming in Prolog, by Clocksin and Mellish           2249985-0001
Explorer Color Graphics User's Guide, Support for the
  Raster Technologies Model One                          2537157-0001
Explorer TCP/IP User's Guide                             2537150-0001

System Software Internals

Explorer System Software Design Notes                    2243208-0001

Explorer is a trademark of Texas Instruments Incorporated.

THE EXPLORERTM SYSTEM HARDWARE MANUALS (May 1986)

System Level Hardware Publications

Explorer Unpacking and Inventory                         2243216-0001  Orig  Apr 85
Explorer 7-Slot System Installation                      2243140-0001  Orig  Apr 85
Explorer System Field Maintenance                        2243141-0001

System Enclosure Hardware Publications

Explorer 7-Slot System Enclosure General Description     2243143-0001  Rev A Jul 85
Explorer 2-Megabyte Memory General Description           2243147-0001
Explorer Memory General Description                      2533592-0001  Orig  Aug 85
Explorer Processor General Description                   2243144-0001  Rev A Oct 85
Explorer Display Unit General Description                2243151-0001  Orig  May 85
Explorer System Interface General Description            2243145-0001  Rev A Oct 85

Mass Storage Hardware Publications

Explorer Mass Storage Enclosure General Description      2243148-0001  Rev A Oct 85
Explorer Winchester Disk Formatter (ADAPTEC) Supplement
  to Explorer Mass Storage Enclosure General Description 2243149-0001  Rev   Sep 85
Explorer Winchester Disk Drive (Maxtor) Supplement to
  Explorer Mass Storage Enclosure General Description    2243150-0001  Rev A Oct 85
Explorer Cartridge Tape Drive (Cipher) Supplement to
  Explorer Mass Storage Enclosure General Description    2243166-0001  Rev A Oct 85
Explorer Cable Interconnect Board (2236120-0001) Supplement
  to Explorer Mass Storage Enclosure General Description 2243177-0001  Rev A Oct 85
Explorer NuBus" Peripheral Interface
  General Description (NUPI board)                       2243146-0001  Rev A Oct 85

Mass Storage Hardware Vendor Publications

Series 540 Cartridge Tape Drive Product Description,
  Cipher Data Products, Inc.,
  Bulletin Number 01-311-0284-IK (1/4-inch tape drive)   2249997-0001
MTO I Tape Controller Technical Manual,
  Emulex Corporation, part number MT0151001
  (formatter for the 1/4-inch tape drive)                2243182-0001
XT-1000 Service Manual, 51/4-inch Fixed Disk Drive,
  Maxtor Corporation, part number 20005
  (5 1/4-inch Winchester disk drive, 112 megabytes)      2249999-0001
ACB-5500 Winchester Disk Controller User's Manual,
  Adaptec, Inc.,
 (formatter for the 51/4-inch Winchester disk drive)     2249933-0001

Optional Equipment Hardware Publications

Explorer NuBus Ethernet R Controller General Description 2243161-0001  Orig  Jun 85
Model 855 Printer Operator's Manual                      2225911-0001
Model 855 Printer Technical Reference Manual             2232822-0001
Model 855/856 Printer Maintenance Manual                 2225914-0001

Explorer and NuBus are trademarks of Texas Instruments Incorporated.
Ethernet is a registered trademark of Xerox Corporation.

THE EXPLORERTM SYSTEM SOFTWARE MANUALS (September 1989)
 

Mastering the Explorer Environment

Introduction to the Explorer System                      2243190-0001  Chg 2 Dec 87
Explorer Zmacs Editor Tutorial                           2243191-0001  Rev A Jun 87
Explorer Networking Reference                            2243206-0001  Rev B Jun 87
Explorer Diagnostics                                     2533554-0001  Rev E Jun 87
Explorer System Software Installation Guide              2243205-0001  Rev E Dec 87
Explorer System Software Release Information Rel 3.0                   Orig  Jun 87
                                             Rel 3.1                   Rev A Oct 87
                                             Rel 3.2                   Rev B Dec 87
microExplorer TM User's Guide                            2552701-0001

Programming With the Explorer

Explorer Programming Concepts                            2549830-0001  Chg 1 Dec 87
Explorer Lisp Reference                                  2243201-0001  Rev C Sep 89
Explorer Input/Output Reference                          2549281-0001  Rev A Jun 87
Explorer Zmacs Editor Reference                          2243192-0001  Rev A Jun 87
Explorer Tools and Utilities                             2549831-0001  Chg 2 Dec 87
Explorer Window System Reference                         2243200-0001
microExplorer Development Software User's Guide          2552702-0001
Explorer System Software Release Information Rel 3.0     2549844-0001  Orig  Jun 87
                                             Rel 3.1                   Rev A Oct 87
                                             Rel 3.2                   Rev B Dec 87
Explorer Software Release Information and Installation
  Guide for microexplorer Delivery Software              2555022-0001
SLE X Window System TM Programmer's Reference            2553272-0001  Orig  Sep 89
SLE Common Lisp Object System                            2559593-0001  Orig  Sep 89

Explorer Options

Explorer Natural Language Menu System User's Guide       2243202-0001
Explorer Relational Table Management System User's Guide 2243203-0001
Explorer Grasper User's Guide                            2243135-0001
Explorer TI Prolog User's Guide                          2537248-0001  Orig  Nov 86
Programming in Prolog, by Clocksin and Mellish           2249985-0001
Explorer Color Graphics User's Guide                     2537157-0001
Explorer TCP/IP User's Guide                             2537150-0001  Rev A Jun 87
Explorer LX TM User's Guide                              2537225-0001
Explorer LX System Installation                          2537227-0001
Explorer NFS TM User's Guide                             2546890-0001  Rev A Jul 87
Explorer DECnet TM User's Guide                          2537223-0001  Orig  Jul 87
Explorer Software Release Information and
  Installation Guide for microExplorer Source Option     2555023-0001
Explorer Software Release Information and Installation
  Guide for microExplorer Development Software           2555024-0001
Explorer SNA II                                          2537281-0001
Personal Consultant TM Plus Explorer                     2537259-0001

System Software Internals

Explorer System Software Design Notes                    2243208-0001  Rev A Jun 87

Explorer, Explorer LX, microExplorer, and Personal Consultant are trademarks of Texas Instruments Incorporated.
X Window System is a trademark of the Massachusetts Institute of Technology.
NFS is a trademark of Sun Microsystems, Inc.
DECnet is a trademark of Digital Equipment Corporation.

THE EXPLORER SYSTEM HARDWARE MANUALS(September 1989)

System Level Publications

Explorer 7-Slot System Installation                      2243140-0001
Explorer System Field Maintenance                        2243141-0001
Explorer System Field Maintenance Documentation Kit      2243222-0001
Explorer System Field Maintenance Supplement             2537183-0001
Explorer System Field Maintenance Supplement
  Documentation Kit                                      2549278-0001
NuBus TM Systems Explorer/Explorer LX Field
  Maintenance Handbook                                   2553315-0001
Explorer NuBus System Architecture
  General Description                                    2537171-0001

System Enclosure Equipment Publications

Explorer 7-Slot System Enclosure General Description     2243143-0001
Explorer Memory General Description (8-megabytes)        2533592-0001
Explorer 32-Megabyte Memory General Description          2537185-0001
Explorer Processor General Description                   2243144-0001
68020-Based Processor General Description                2537240-0001
Explorer II TM Processor and Auxiliary Processor
  Options General Description                            2537187-0001  Orig  Jun 87
Explorer II Plus TM Processor General Description        2553312-0001
Explorer System Interface General Description            2243145-0001
Explorer Color System Interface Board
  General Description                                    2537189-0001  Orig  Dec 87
Explorer NuBus Peripheral Interface
  General Description (NUPI board)                       2243146-0001
Computer Enclosure Installation and Operation            2557942-0001

Display Terminal Publications

Explorer Display Unit General Description                2243151-0001
CRT Data Display Service Manual, Panasonic
  code number FTD85055057C                               2537139-0001
Explorer Color Console General Description               2537195-0001  Orig  Dec 87
TRINITRON R Graphic Display Monitor GDM-1603
  Service Manual, Sony R part number 0-558-986-01        2551107-0001
Model 924 Video Display Terminal User's Guide            2544365-0001

143-Megabyte Disk/Tape Enclosure Publications

Explorer Mass Storage Enclosure General Description      2243148-0001  Rev A Oct 87
Explorer Winchester Disk Formatter (Adaptec)
  Supplement to Explorer Mass Storage Enclosure
  General Description                                    2243149-0001
Explorer Winchester Disk Drive (Maxtor)
  Supplement to Explorer Mass Storage Enclosure
  General Description                                    2243150-0001
Explorer Cartridge Tape Drive (Cipher)
  Supplement to Explorer Mass Storage Enclosure
  General Description                                    2243166-0001
Explorer Cable Interconnect Board (2236120-0001)
  Supplement to Explorer Mass Storage Enclosure
  General Description                                    2243177-0001

Explorer II, Explorer II Plus, and NuBus are trademarks of Texas Instruments Incorporated.
TRINITRON and Sony are registered trademarks of Sony Corporation.

143-Megabyte Disk Drive Vendor Publications

XT-1000 Service Manual, 5 1/4-inch Fixed Disk
  Drive, Maxtor Corporation, part number 20005
  (5 1/4-inch Winchester disk drive, 112 megabytes)      2249999-0001
ACB-5500 Winchester Disk Controller User's
  Manual, Adaptec, Inc., (formatter for the
  5 1/4-inch Winchester disk drive)                      2249933-0001
 

1/4-Inch Tape Drive Vendor Publications

Series 540 Cartridge Tape Drive Product Description,
  Cipher Data Products, Inc., Bulletin Number
  01-311-0284-IK (1/4-inch tape drive)                   2249997-0001
MT01 Tape Controller Technical Manual,
  Emulex Corporation, part number MT0151001
  (formatter for the 1/4-inch tape drive)                2243182-0001
Viper TM Half-High Intelligent 4 1/4-Inch Streaming
  Cartridge Tape Drive SCSI Models 2060S and 2125S,
  Archive Corporation, part number 21136-001             2551106-0001

182-Megabyte Disk/Tape Enclosure MSU II Publications

Mass Storage Unit (MSU II) General Description           2537197-0001

182-Megabyte Disk Drive Vendor Publications

Control Data& WREN TM III Disk Drive OEM Manual,
  part number 77738216, Magnetic Peripherals, Inc.,
  a Control Data Company                                 2546867-0001

515-Megabyte Mass Storage Subsystem Publications

SMD/515-Megabyte Mass Storage Subsystem General
  Description (includes SMD/SCSI con,-roller
  and 515-megabyte disk drive enclosure)                 2537244-0001

515-Megabyte Disk Drive Vendor Publications

515-Megabyte Disk Drive Documentation Master Kit
  (Volumes 1, 2, and 3), Control Data Corporation        2246129-0002
Volume 1, General Description, Operation, Installation
  and Checkout, and Part Data 2246125-0004
Volume 2, Theory, General Maintenance, Trouble
  Analysis, Electrical Checks, and Repair Information    2246125-0005
Volume 3, Diagrams                                       2246125-0006

1/2-Inch Tape Drive MT Publications

3201 1/2-Inch Tape Drive General Description             2537246-0001

380-Megabyte Disk/Tape Enclosure MSU IIA Publications

Mass Storage Unit (MSU IIA)
  Installation and Operation Kit                         2557935-0001

Viper is a trademark of Archive Corporation.
Control Data is a registered trademark and WREN is a trademark of Control Data Corporation.

380-Megabyte Disk Drive Vendor Publications

XT-4000S Product Specification and OEM Manual,
  Maxtor Corporation, part number 1014995
  (DB380 Disk Drive)                                     2554653-0001

1/2-Inch Tape Drive Vendor Publications

Cipher CacheTapelt Documentation Manual Kit
  (Volumes 1 and 2 With SCSI Addendum and,
  Logic Diagram), Cipher Data products                   2246130-0001
1/2-Inch Tape Drive Operation and Maintenance
  (Volume 1), Cipher Data Products                       2246126-0001
1/2-Inch Tape Drive Theory of Operation
  (Volume 2), Cipher Data Products                       2246126-0002
SCSI Addendum With Logic Diagram,
  Cipher Data Products                                   2246126-0003

Printer Publications

Model 810 Printer Installation and Operation Manual      2311356-9701
Omni 800 TM Electronic Data Terminals Maintenance
 Manual for Model 810 Printers                           0994386-9701
Model 850 RO Printer User's Manual                       2219890-0001
Model 850 RO Printer Maintenance Manual                  2219896-0001
Model 850 XL Printer User's Manual                       2243250-0001
Model 850 XL Printer Quick Reference Guide I I           2243249-0001
Model 855 Printer Operator's Manual                      2225911-0001
Model 855 Printer Technical Reference Manual             2232822-0001
Model 855 Printer Maintenance Manual                     2225914-0001
Model 860 XL Printer User's Manual                       2239401-0001
Model 860 XL Printer Maintenance Manual                  2239427-0001
Model 860 XI Printer Quick Reference Guide               2239402-0001
Model 860/859 Printer Technical Reference Manual         2239407-0001
Model 865 Printer Operator's Manual                      2239405-0001
Model 865 Printer Maintenance Manual                     2239428-0001
Model 880 Printer User's Manual                          2222627-0001
Model 880 Printer Maintenance Manual                     2222628-0001
OmniLaser TM 2015 Page Printer Operator's Manual         2539178-0001
OmniLaser 2015 Page Printer Technical Reference          2539179-0001
OmniLaser 2015 Page Printer Maintenance Manual           2539180-0001
OmniLaser 2108 Page Printer Operator's Manual            2546348-0001
OmniLaser 2108 Page Printer Technical Reference          2546349-0001
OmniLaser 2108 Page Printer Maintenance Manual           2546350-0001
OmniLaser 2115 Page Printer Operator's Manual            2546344-0001
OmniLaser 2115 Page Printer Technical Reference          2546345-0001
OmniLaser 2115 Page Printer Maintenance Manual           2546346-0001

Communications Publications

990 Family Communications Systems Field Reference        2276579-9701
E1990 Ethernet R Interface Installation and Operation    2234392-9701
Explorer NuBus Ethernet Controller General Description   2243161-0001
Communications Carrier Board and Options
  General Description                                    2537242-0001

CacheTape is a registered trademark of Cipher Data Products, Inc.
Omni 800 and OmniLaser are trademarks of Texas Instruments Incorporated.
Ethernet is a registered trademark of Xerox Corporation. --------------000105050801000208000208-- From nyef@softhome.net Wed Mar 10 16:55:02 2004 From: nyef@softhome.net (Nyef) Date: Wed Mar 10 16:55:02 2004 Subject: [LMH]Memory board docs? In-Reply-To: <404FC37B.1030003@objs.com> References: <20040311003451.GA10084@miyu.paradiesanalytics.com> <404FC37B.1030003@objs.com> Message-ID: <20040311015143.GA10206@miyu.paradiesanalytics.com> On Wed, Mar 10, 2004 at 08:40:11PM -0500, ford@objs.com wrote: > I have that manual somewhere (I attached the list of the manuals I > have). I'll dig it up and scan the TOC. > > Steve > > Nyef wrote: > > >Hello all. > > > >Does anyone have a copy of the memory board manual? The name and part > >number is: > > > >Explorer Memory General Description (8-megabytes) 2533592-0001 Could I trouble you to scan the pages describing the control space address map and the various registers and latches therein, and anything that describes how the parity checking hardware works or is tested? Thanks. --Alastair From aek@spies.com Thu Mar 11 12:47:01 2004 From: aek@spies.com (Al Kossow) Date: Thu Mar 11 12:47:01 2004 Subject: [LMH]8m mem manual Message-ID: <200403112149.i2BLnF21010709@spies.com> www.bitsavers.org/pdf/ti/explorer/2533592-0001_8M_mem_Aug85.pdf From nyef@softhome.net Thu Mar 11 17:37:00 2004 From: nyef@softhome.net (Nyef) Date: Thu Mar 11 17:37:00 2004 Subject: [LMH] New nevermore version. Message-ID: <20040312023326.GA12175@miyu.paradiesanalytics.com> Hello all. Okay, I just pushed a new version of nevermore to http://www.dridus.com/~nyef/lispm/nevermore/ The big feature this time is that it's faster. Unfortunately, I forgot to thank everyone who helped to make it faster in the README. I'll put that on my list to fix for next version. Sorry guys! I expect to be working on fixing the memory board emulation to pass the self-test over the next couple of days. Maybe then we can see some new screenshots... --Alastair From nyef@softhome.net Sat Mar 20 17:40:02 2004 From: nyef@softhome.net (Nyef) Date: Sat Mar 20 17:40:02 2004 Subject: [LMH] Nevermore status and ROM hunting Message-ID: <20040321023521.GA1265@miyu.paradiesanalytics.com> Hello all. I've been messing with Nevermore again. Some of you may have noticed that the collection of framebuffer images at http://www.dridus.com/~nyef/lispm/nevermore/ now consists of 8 bitmap files, including some showing progress getting more tests to pass the SIB extended diagnostics (my current task as far as Nevermore is concerned). I'm now running Nevermore from SBCL, which now works fairly well (certainly better than the last released version did). To help tide you guys over until the next release, I put my disassembly and symbol files for the boot microcode in the same directory as all the screenshots. The files are prom_disassem and prom_symbols. Feel free to try and figure out the great swaths of uncommented code in there (and feel free to try and fix the Nevermore disassembler to work with the contents of the *prom-memory-a* and *prom-memory-m* arrays instead of requiring a weird 'prom-combined' file, and an actual .el file for working with the disassembly could be neat, as would fixing the disassembler to work on the .mcr files in the ubin/ directory of the explorer src tarball or on a microload partition image... There are a lot of possibilities here for an interested person). The other thing is, does anyone have or could anyone make an image of the Explorer I CPU config ROM? If nobody wants to remove the ROM from their working system, would they (you) be averse to running a short program to read the ROM into a Lisp array and then figuring out how to send that array data to me? Thanks in advance to those at least considering it. (And, since we're on the subject of ROMs, can anyone get images of the ROMs for an Explorer II CPU or MicroExplorer board? Once Nevermore is basically working we might want to try emulating the later systems as well...) Anyway, that's all for now. I'm gonna go back to trying to get a few more of those SIB tests to pass... --Alastair From aek@spies.com Sun Mar 21 06:17:01 2004 From: aek@spies.com (Al Kossow) Date: Sun Mar 21 06:17:01 2004 Subject: [LMH]Re: Nevermore status and ROM hunting Message-ID: <200403211520.i2LFK8xH002556@spies.com> The config rom on the cpu is a surface mount part, and would be difficult to remove. It would be better if someone with a working system could dump it through software. I should be able to get a microexplorer prom dump later today. d From aek@spies.com Sun Mar 21 09:41:01 2004 From: aek@spies.com (Al Kossow) Date: Sun Mar 21 09:41:01 2004 Subject: [LMH]microexplorer config rom Message-ID: <200403211844.i2LIiVPU005307@spies.com> no joy. The part is surface mount as well if someone has a system handy, it would be fastest to just dump the slot config space with macsbug unfortunately, all of my nubus macs are in storage right now From asholz@topinform.de Sun Mar 21 22:29:01 2004 From: asholz@topinform.de (Andreas Holz) Date: Sun Mar 21 22:29:01 2004 Subject: [LMH]Explorer/Microexplorer config ROM dump In-Reply-To: <20040321210101.5362.qmail@kappa.unlambda.com> References: <20040321210101.5362.qmail@kappa.unlambda.com> Message-ID: <405E95A9.4010508@topinform.com> lispm-hackers-request@lists.unlambda.com wrote: >Send LispM-Hackers mailing list submissions to > lispm-hackers@lists.unlambda.com > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.unlambda.com/mailman/listinfo/lispm-hackers >or, via email, send a message with subject or body 'help' to > lispm-hackers-request@lists.unlambda.com > >You can reach the person managing the list at > lispm-hackers-admin@lists.unlambda.com > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of LispM-Hackers digest..." > > >Today's Topics: > > 1. Nevermore status and ROM hunting (Nyef) > 2. Re: Nevermore status and ROM hunting (Al Kossow) > 3. microexplorer config rom (Al Kossow) > >--__--__-- > >Message: 1 >Date: Sat, 20 Mar 2004 21:35:22 -0500 >From: Nyef >To: lispm-hackers@lists.unlambda.com >Subject: [LMH] Nevermore status and ROM hunting > >Hello all. > >I've been messing with Nevermore again. Some of you may have >noticed that the collection of framebuffer images at >http://www.dridus.com/~nyef/lispm/nevermore/ now consists of >8 bitmap files, including some showing progress getting more >tests to pass the SIB extended diagnostics (my current task >as far as Nevermore is concerned). > >I'm now running Nevermore from SBCL, which now works fairly >well (certainly better than the last released version did). > >To help tide you guys over until the next release, I put my >disassembly and symbol files for the boot microcode in the >same directory as all the screenshots. The files are >prom_disassem and prom_symbols. Feel free to try and figure >out the great swaths of uncommented code in there (and feel >free to try and fix the Nevermore disassembler to work with >the contents of the *prom-memory-a* and *prom-memory-m* >arrays instead of requiring a weird 'prom-combined' file, >and an actual .el file for working with the disassembly >could be neat, as would fixing the disassembler to work on >the .mcr files in the ubin/ directory of the explorer src >tarball or on a microload partition image... There are a >lot of possibilities here for an interested person). > >The other thing is, does anyone have or could anyone make an >image of the Explorer I CPU config ROM? If nobody wants to >remove the ROM from their working system, would they (you) >be averse to running a short program to read the ROM into a >Lisp array and then figuring out how to send that array data >to me? Thanks in advance to those at least considering it. > >(And, since we're on the subject of ROMs, can anyone get >images of the ROMs for an Explorer II CPU or MicroExplorer >board? Once Nevermore is basically working we might want to >try emulating the later systems as well...) > >Anyway, that's all for now. I'm gonna go back to trying to >get a few more of those SIB tests to pass... > >--Alastair > >--__--__-- > >Message: 2 >Date: Sun, 21 Mar 2004 07:20:08 -0800 >From: Al Kossow >To: lispm-hackers@lists.unlambda.com >Subject: [LMH]Re: Nevermore status and ROM hunting > > >The config rom on the cpu is a surface mount part, and would be difficult >to remove. It would be better if someone with a working system could dump >it through software. > >I should be able to get a microexplorer prom dump later today. >d > >--__--__-- > >Message: 3 >Date: Sun, 21 Mar 2004 10:44:31 -0800 >From: Al Kossow >To: lispm-hackers@lists.unlambda.com >Subject: [LMH]microexplorer config rom > > >no joy. The part is surface mount as well > >if someone has a system handy, it would be fastest to just >dump the slot config space with macsbug > >unfortunately, all of my nubus macs are in storage right now > > >--__--__-- > > > >http://lists.unlambda.com/mailman/listinfo/lispm-hackers > > > >End of LispM-Hackers Digest > > > > Hello Marc, somethind to do for you! - Andreas From asholz@topinform.de Mon Mar 22 23:33:00 2004 From: asholz@topinform.de (Andreas Holz) Date: Mon Mar 22 23:33:00 2004 Subject: [LMH]Re: LispM-Hackers digest, Vol 1 #257 - 1 msg In-Reply-To: <20040322210101.9839.qmail@kappa.unlambda.com> References: <20040322210101.9839.qmail@kappa.unlambda.com> Message-ID: <405FF624.70106@topinform.com> Hi, sorry from the cryptic Email! I forwarded the Mail to Marc, who has an Exp1 and MicroExplorer running. - Andreas >Hello Marc, > >somethind to do for you! > >- Andreas > > >--__--__-- > > > >http://lists.unlambda.com/mailman/listinfo/lispm-hackers > > > >End of LispM-Hackers Digest > > > > From nyef@softhome.net Wed Mar 31 03:56:01 2004 From: nyef@softhome.net (Nyef) Date: Wed Mar 31 03:56:01 2004 Subject: [LMH] Another documentation request Message-ID: <20040331125053.GA17357@miyu.paradiesanalytics.com> Subject: [LMH] Another documentation request Hello all. Does anyone have documentation on the Explorer keyboards? The SIB documentation doesn't seem to list scancodes or startup behavior and such, the PRIM doesn't seem to want to run with no keyboard, and the comments in KERNEL;KEYBOARD-CHARS are somewhat confusing and wouldn't paint the full picture anyway... Thanks in advance. --Alastair Bridgewater From ford@objs.com Wed Mar 31 04:16:02 2004 From: ford@objs.com (ford@objs.com) Date: Wed Mar 31 04:16:02 2004 Subject: [LMH] Another documentation request In-Reply-To: <20040331125053.GA17357@miyu.paradiesanalytics.com> References: <20040331125053.GA17357@miyu.paradiesanalytics.com> Message-ID: <406AC3FC.5010804@objs.com> Did you check the Display manual? I think there's keyboard info in there. Steve Nyef wrote: >Subject: [LMH] Another documentation request > >Hello all. > >Does anyone have documentation on the Explorer >keyboards? The SIB documentation doesn't seem to >list scancodes or startup behavior and such, the >PRIM doesn't seem to want to run with no keyboard, >and the comments in KERNEL;KEYBOARD-CHARS are >somewhat confusing and wouldn't paint the full >picture anyway... > >Thanks in advance. > >--Alastair Bridgewater > >http://lists.unlambda.com/mailman/listinfo/lispm-hackers > > > From nyef@softhome.net Wed Mar 31 04:52:01 2004 From: nyef@softhome.net (Nyef) Date: Wed Mar 31 04:52:01 2004 Subject: [LMH] Another documentation request In-Reply-To: <406AC3FC.5010804@objs.com> References: <20040331125053.GA17357@miyu.paradiesanalytics.com> <406AC3FC.5010804@objs.com> Message-ID: <20040331134631.GA17442@miyu.paradiesanalytics.com> On Wed, Mar 31, 2004 at 08:13:32AM -0500, ford@objs.com wrote: > Did you check the Display manual? I think there's keyboard info in there. That's certainly a good start, thank you. That should get me quite a bit further. It doesn't seem to mention commands sent to the keyboard or keyboard powerup/reset behavior though. Is that in another manual somewhere? -- Alastair Bridgewater From ford@objs.com Wed Mar 31 08:35:01 2004 From: ford@objs.com (ford@objs.com) Date: Wed Mar 31 08:35:01 2004 Subject: [LMH] Another documentation request In-Reply-To: <20040331134631.GA17442@miyu.paradiesanalytics.com> References: <20040331125053.GA17357@miyu.paradiesanalytics.com> <406AC3FC.5010804@objs.com> <20040331134631.GA17442@miyu.paradiesanalytics.com> Message-ID: <406B00B8.3040309@objs.com> This is a multi-part message in MIME format. --------------080407050701080109010701 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nyef wrote: >On Wed, Mar 31, 2004 at 08:13:32AM -0500, ford@objs.com wrote: > > >>Did you check the Display manual? I think there's keyboard info in there. >> >> > >That's certainly a good start, thank you. That should get me >quite a bit further. > >It doesn't seem to mention commands sent to the keyboard or >keyboard powerup/reset behavior though. Is that in another >manual somewhere? > You might check the Windows System and Field Maintenance manuals. Have you searched through the source code? Steve > >-- Alastair Bridgewater > > > --------------080407050701080109010701 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Nyef wrote:

On Wed, Mar 31, 2004 at 08:13:32AM -0500, ford@objs.com wrote:
  
Did you check the Display manual?  I think there's keyboard info in there.
    

That's certainly a good start, thank you. That should get me
quite a bit further.

It doesn't seem to mention commands sent to the keyboard or
keyboard powerup/reset behavior though. Is that in another
manual somewhere?
You might check the Windows System and Field Maintenance manuals.
Have you searched through the source code?

Steve
 

-- Alastair Bridgewater
--------------080407050701080109010701-- From nyef@softhome.net Wed Mar 3 10:09:00 2004 From: nyef@softhome.net (Nyef) Date: Wed Mar 3 10:09:00 2004 Subject: [LMH] Ooh, look! List traffic! Message-ID: <20040303190611.GA31409@miyu.paradiesanalytics.com> Hello all. At http://www.dridus.com/~nyef/lispm/nevermore/frameimg.bmp is something that might be a little interesting (especially the lower left part of the image). I'm sure you all will be able to figure out what it is. --Alastair Bridgewater From Dan Moniz Wed Mar 3 16:23:00 2004 From: Dan Moniz (Dan Moniz) Date: Wed Mar 3 16:23:00 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <20040303190611.GA31409@miyu.paradiesanalytics.com> References: <20040303190611.GA31409@miyu.paradiesanalytics.com> Message-ID: <91988442.1078334542@localhost> --==========ED1A4104E747F7FDE94B========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday, March 03, 2004 2:06 PM -0500 Nyef wrote: > Hello all. > > At http://www.dridus.com/~nyef/lispm/nevermore/frameimg.bmp is > something that might be a little interesting (especially the > lower left part of the image). > > I'm sure you all will be able to figure out what it is. Cool! Also of interest are the other bitmaps in that directory. ;] --=20 Dan Moniz [http://www.pobox.com/~dnm/] --==========ED1A4104E747F7FDE94B========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: Mulberry PGP Plugin v3.0 Comment: processed by Mulberry PGP Plugin iQA/AwUBQEaE4FmE1hyKYjtREQIX8ACcCShk/ZH9C8N5rbwp4ddQMgr/jRsAoMaY j5D5NlJAbD6vJYnPVGDyZ/yB =f3Pw -----END PGP SIGNATURE----- --==========ED1A4104E747F7FDE94B==========-- From nyef@softhome.net Wed Mar 3 18:41:01 2004 From: nyef@softhome.net (Nyef) Date: Wed Mar 3 18:41:01 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <91988442.1078334542@localhost> References: <20040303190611.GA31409@miyu.paradiesanalytics.com> <91988442.1078334542@localhost> Message-ID: <20040304033822.GA31988@miyu.paradiesanalytics.com> On Wed, Mar 03, 2004 at 05:22:22PM -0800, Dan Moniz wrote: > On Wednesday, March 03, 2004 2:06 PM -0500 Nyef wrote: > > >Hello all. > > > >At http://www.dridus.com/~nyef/lispm/nevermore/frameimg.bmp is > >something that might be a little interesting (especially the > >lower left part of the image). > > > >I'm sure you all will be able to figure out what it is. > > Cool! > > Also of interest are the other bitmaps in that directory. ;] Indeed, but those weren't there when I sent my message to the list. As a data point, all of these images took about 20 minutes each of runtime in the emulator to create. The last thing I did with the code was to put in address decoding for the memory board control space, which was enough to get it to do a thorough test of the low 256k of the memory space, but still fail the board test. That took about three and a half hours to run and generated about 1,054,200 lines of output. And no, that's not a per-instruction trace. It's mainly the CMUCL GC going off and all of the NuBus access requests (and a bit from the mapping hardware, but that doesn't get used much yet). --Alastair Bridgewater From rjs@fdy2.demon.co.uk Thu Mar 4 01:21:01 2004 From: rjs@fdy2.demon.co.uk (Robert Swindells) Date: Thu Mar 4 01:21:01 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <20040304033822.GA31988@miyu.paradiesanalytics.com> (message from Nyef on Wed, 3 Mar 2004 22:38:22 -0500) Message-ID: <200403041017.i24AHKKE082163@ren.fdy2.net> Alastair Bridgewater wrote: >On Wed, Mar 03, 2004 at 05:22:22PM -0800, Dan Moniz wrote: >> On Wednesday, March 03, 2004 2:06 PM -0500 Nyef wrote: >> >> >Hello all. >> > >> >At http://www.dridus.com/~nyef/lispm/nevermore/frameimg.bmp is >> >something that might be a little interesting (especially the >> >lower left part of the image). >> > >> >I'm sure you all will be able to figure out what it is. >> >> Cool! >> >> Also of interest are the other bitmaps in that directory. ;] >Indeed, but those weren't there when I sent my message to the list. >As a data point, all of these images took about 20 minutes each of >runtime in the emulator to create. >The last thing I did with the code was to put in address decoding >for the memory board control space, which was enough to get it to >do a thorough test of the low 256k of the memory space, but still >fail the board test. That took about three and a half hours to run >and generated about 1,054,200 lines of output. And no, that's not >a per-instruction trace. It's mainly the CMUCL GC going off and all >of the NuBus access requests (and a bit from the mapping hardware, >but that doesn't get used much yet). How about a VHDL version ? :-) Robert Swindells From mikemac@mikemac.com Thu Mar 4 04:41:02 2004 From: mikemac@mikemac.com (Mike McDonald) Date: Thu Mar 4 04:41:02 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: Your message of "Wed, 03 Mar 2004 22:38:22 EST." <20040304033822.GA31988@miyu.paradiesanalytics.com> Message-ID: <200403041337.i24DbX905722@saturn.mikemac.com> >To: Dan Moniz >Date: Wed, 3 Mar 2004 22:38:22 -0500 >From: Nyef >The last thing I did with the code was to put in address decoding >for the memory board control space, which was enough to get it to >do a thorough test of the low 256k of the memory space, but still >fail the board test. That took about three and a half hours to run >and generated about 1,054,200 lines of output. And no, that's not >a per-instruction trace. It's mainly the CMUCL GC going off and all >of the NuBus access requests (and a bit from the mapping hardware, >but that doesn't get used much yet). OK, I'm confused now. Are you writing an emulator in Lisp? Can you provide some more info? Thanks. Mike McDonald mikemac@mikemac.com From nyef@softhome.net Thu Mar 4 06:22:01 2004 From: nyef@softhome.net (Nyef) Date: Thu Mar 4 06:22:01 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <200403041337.i24DbX905722@saturn.mikemac.com> References: <20040304033822.GA31988@miyu.paradiesanalytics.com> <200403041337.i24DbX905722@saturn.mikemac.com> Message-ID: <20040304151820.GA32669@miyu.paradiesanalytics.com> On Thu, Mar 04, 2004 at 08:37:33AM -0500, Mike McDonald wrote: > > >To: Dan Moniz > >Date: Wed, 3 Mar 2004 22:38:22 -0500 > >From: Nyef > > >The last thing I did with the code was to put in address decoding > >for the memory board control space, which was enough to get it to > >do a thorough test of the low 256k of the memory space, but still > >fail the board test. That took about three and a half hours to run Did I say three and a half? I meant six and a half. > >and generated about 1,054,200 lines of output. And no, that's not > >a per-instruction trace. It's mainly the CMUCL GC going off and all > >of the NuBus access requests (and a bit from the mapping hardware, > >but that doesn't get used much yet). > > OK, I'm confused now. Are you writing an emulator in Lisp? Can you > provide some more info? Yes, it's in Lisp. The old (late last year) source tarball is up in the same directory as all the screenshots ( http://www.dridus.com/~nyef/lispm/nevermore/ ), and I'm doing some cleanup on the current sources in preparation for releasing them at some point in the next day or so. As fair warning, the old version reqiures a combined microcode image that none of you have. The new version will require rom images for the SIB config rom, the memory board config rom, and all seven boot microcode roms. These files are (in order): 2236662_SIB 2243924-2_27S291.8MB 2236480-03 2236481-03 2236482-03 2236483-03 2236484-03 2236485-03 2236486-03 (here's where being a packrat and downloading every rom file and disk image mentioned on the list over the past couple years helps.) --Alastair Bridgewater From nyef@softhome.net Thu Mar 4 09:06:01 2004 From: nyef@softhome.net (Nyef) Date: Thu Mar 4 09:06:01 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <20040304151820.GA32669@miyu.paradiesanalytics.com> References: <20040304033822.GA31988@miyu.paradiesanalytics.com> <200403041337.i24DbX905722@saturn.mikemac.com> <20040304151820.GA32669@miyu.paradiesanalytics.com> Message-ID: <20040304180316.GA456@miyu.paradiesanalytics.com> On Thu, Mar 04, 2004 at 10:18:20AM -0500, Nyef wrote: > > Yes, it's in Lisp. The old (late last year) source tarball is up in > the same directory as all the screenshots ( > http://www.dridus.com/~nyef/lispm/nevermore/ ), and I'm doing some > cleanup on the current sources in preparation for releasing them at > some point in the next day or so. Fitting action to words, the new version is up as http://www.dridus.com/~nyef/lispm/nevermore/nevermore-9e0304.tgz I am uncertain as to if I will be continuing with this codebase. The speed has reached the point of untenability. --Alastair Bridgewater From rjs@fdy2.demon.co.uk Thu Mar 4 10:05:01 2004 From: rjs@fdy2.demon.co.uk (Robert Swindells) Date: Thu Mar 4 10:05:01 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <20040304180316.GA456@miyu.paradiesanalytics.com> (message from Nyef on Thu, 4 Mar 2004 13:03:16 -0500) Message-ID: <200403041901.i24J1NSg082987@ren.fdy2.net> Nyef wrote: >On Thu, Mar 04, 2004 at 10:18:20AM -0500, Nyef wrote: >> >> Yes, it's in Lisp. The old (late last year) source tarball is up in >> the same directory as all the screenshots ( >> http://www.dridus.com/~nyef/lispm/nevermore/ ), and I'm doing some >> cleanup on the current sources in preparation for releasing them at >> some point in the next day or so. >Fitting action to words, the new version is up as >http://www.dridus.com/~nyef/lispm/nevermore/nevermore-9e0304.tgz >I am uncertain as to if I will be continuing with this codebase. >The speed has reached the point of untenability. I was only half joking about translating it to VHDL. Just having done the analysis of what the microarchitecture needs to do might be useful in the long run. The whole CPU would fit into a $15 FPGA using current technology, add a couple of 16bit SDRAMs and some boot flash and you have a 10x faster microExplorer. Robert Swindells From Dan Moniz Thu Mar 4 17:58:00 2004 From: Dan Moniz (Dan Moniz) Date: Thu Mar 4 17:58:00 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <200403041901.i24J1NSg082987@ren.fdy2.net> References: <200403041901.i24J1NSg082987@ren.fdy2.net> Message-ID: <3344789.1078426623@localhost> --==========12568330DF163FFC5379========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday, March 04, 2004 7:01 PM +0000 Robert Swindells=20 wrote: > Nyef wrote: > > On Thu, Mar 04, 2004 at 10:18:20AM -0500, Nyef wrote: > >> > >> Yes, it's in Lisp. The old (late last year) source tarball is up in > >> the same directory as all the screenshots ( > >> http://www.dridus.com/~nyef/lispm/nevermore/ ), and I'm doing some > >> cleanup on the current sources in preparation for releasing them at > >> some point in the next day or so. > > > Fitting action to words, the new version is up as > > http://www.dridus.com/~nyef/lispm/nevermore/nevermore-9e0304.tgz > > > I am uncertain as to if I will be continuing with this codebase. > > The speed has reached the point of untenability. > > I was only half joking about translating it to VHDL. > > Just having done the analysis of what the microarchitecture needs to > do might be useful in the long run. > > The whole CPU would fit into a $15 FPGA using current technology, add > a couple of 16bit SDRAMs and some boot flash and you have a 10x faster > microExplorer. Which is an interesting point. I wonder how hard it would be to write the=20 emulator (or CPU) in Verilog (being somewhat higher-level and easier to=20 cope with than VHDL, at least for this task). I assume "hard", and that=20 would be an understatement. But possibly worthwhile. Of course, there's the longer term problem of getting a monitor and input=20 devices to talk to it, which would be painful, and disks, file systems, a=20 running install, oh my! Probably, now that I think about it, an FPGA-based Explorer processor on a=20 PCI card, with some interface glue would be the way to go. If someone is willing to buy me a simple Xilinx setup (usable FPGA for this = purpose, test-board, Verilog compiler, etc.), I'll take a crack at it. I=20 won't hold my breath, but this equipment has come down in price. I think=20 the FPGA we'd want/need is more expensive than the one included in their=20 $70 - $100 starter kit. Alastair, I should have asked you this years ago, but I've been somewhat=20 confused for a while as to where exploiter fit into the picture. E3 was=20 supposed to be an emulator, and exploiter was, what, your independently=20 developed emulator? And nevermore is the same sort of thing in CL (Mike=20 already asked this, but I had gathered as much from the code). For a while=20 now I've been confused as to what the relation was between E3 and=20 exploiter, but I never thought to ask. I always thought it was explained in = one of the previous list emails, but in infrequent and rather shallow=20 searching of my personal archive of lispm-hackers over the years, I never=20 found a mail with an explanation. I'm just curious, BTW, because this bit=20 of information has been missing from my picture of the development effort. --=20 Dan Moniz [http://www.pobox.com/~dnm/] --==========12568330DF163FFC5379========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: Mulberry PGP Plugin v3.0 Comment: processed by Mulberry PGP Plugin iQA/AwUBQEfsiFmE1hyKYjtREQKj1wCgnmkaF13v4gDKrPNKQRkDYzfdL6UAoIcF pAg84qLBJLZUflLpICXRS9qT =czNP -----END PGP SIGNATURE----- --==========12568330DF163FFC5379==========-- From nyef@softhome.net Thu Mar 4 19:35:02 2004 From: nyef@softhome.net (Nyef) Date: Thu Mar 4 19:35:02 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <3344789.1078426623@localhost> References: <200403041901.i24J1NSg082987@ren.fdy2.net> <3344789.1078426623@localhost> Message-ID: <20040305043155.GA1126@miyu.paradiesanalytics.com> On Thu, Mar 04, 2004 at 06:57:03PM -0800, Dan Moniz wrote: > > Which is an interesting point. I wonder how hard it would be to write the > emulator (or CPU) in Verilog (being somewhat higher-level and easier to > cope with than VHDL, at least for this task). I assume "hard", and that > would be an understatement. But possibly worthwhile. > > Of course, there's the longer term problem of getting a monitor and input > devices to talk to it, which would be painful, and disks, file systems, a > running install, oh my! Indeed. At this point we're approaching where I'd prefer we had the rights to the source and disk images sorted out. > Probably, now that I think about it, an FPGA-based Explorer processor on a > PCI card, with some interface glue would be the way to go. I'd prefer a PCMCIA card, mainly because I mostly use laptops these days. > Alastair, I should have asked you this years ago, but I've been somewhat > confused for a while as to where exploiter fit into the picture. E3 was > supposed to be an emulator, and exploiter was, what, your independently > developed emulator? And nevermore is the same sort of thing in CL (Mike > already asked this, but I had gathered as much from the code). For a while > now I've been confused as to what the relation was between E3 and > exploiter, but I never thought to ask. I always thought it was explained in > one of the previous list emails, but in infrequent and rather shallow > searching of my personal archive of lispm-hackers over the years, I never > found a mail with an explanation. I'm just curious, BTW, because this bit > of information has been missing from my picture of the development effort. Okay, so here's how it happened... Once upon a time, there was E3. And it was a wonderful idea. It could read a load band and disassemble the first function in it, but that was about all it could do. This is how it was when I stumbled across it. Some months later, after some effort was invested in the standalone-E3 code, and SSDN2 started being converted to text files, E3 could read a load bad and disassemble the first function in it, but that was about all it could do. For the past several months, the discussion had been about how to implement function calling, since the first (well, second) instruction to execute was a function call instruction. Unfortunately, I couldn't work on E3 because it would throw my computer for a loop every time I tried to run it (nasty kernel messages and everything). But I didn't like seeing the complete lack of progress with people talking about how hard the next step was and not doing anything about it. During this time I had done some studying of various things like the load band and the existing E3 source and such, and had some code for looking at a load band a little more meaningfully than as a hexdump. So I wrote a quick hack to read a load band, find the initial function, and then "execute" the first couple instructions, just to see how hard it really was. And it was -easy-. So I posted that first message to the list, trying to say "come on, guys, it's not that hard, just write the damned code." Nothing happened on the E3 side, but my curiousity wouldn't let me leave my own quick hack alone for too long. So a little while later I had quite a bit more working, made a tarball with my sources, and posted the first version of exploiter. And soon another. Now we get into some of the previously-undisclosed history: At this point, John Morrison, by private email, asked about reconciling my work on exploiter with E3 because there now appeared to be two projects where once there was one. I explained my position (more accurately, ranted for a bit), and gave a list of what I felt was wrong with E3. This was Tuesday, May 21, 2002. Other things that happened on this day included me figuring out how to run E3 without breaking my computer, and Robert Swindells sending me the first unsolicited patch against exploiter. On the following Thursday I exchanged emails with John again, with me explaining why I was going to continue with exploiter and not try and fix E3. This wasn't supposed to happen. There was a two and a half week window in which -any- progress on E3 would probably have caused me to drop exploiter, and which I would have welcomed as being a sign of exploiter succeeding at what it was supposed to do. There was a two-day window in which John could have done the same by fixing any two things on my list of complaints (admittedly, neither of us knew that at the time, and he was busy with his day job, and fixing the easiest two problems would have taken a few hours at least). After this point, very few if any changes were made to E3, and exploiter gained a lot of momentum and carried it fairly well for a while. So, from what I see, exploiter was the quick hack originally meant to light the way for E3 that accidentally ended up killing E3 and taking its place. The history of nevermore is actually recorded in the readme file in the source distribution. It was originally a microcode disassembler that ended up becoming an emulator. Unlike E3 and exploiter, nevermore is a microcode emulator, which means that it will likely be slower than E3 or exploiter would have been / will be, but also means that it should be able to run VM1 code if we ever find a disk image that old. There are other implications as well, but I'm not really up to figuring them out right now. This was probably more information than you really asked for, and I don't know if it answered your questions or not, but... Whatever. I'm tired. I'm going to bed. --Alastair Bridgewater From weel@caltech.edu Thu Mar 4 23:22:01 2004 From: weel@caltech.edu (Jaap Weel) Date: Thu Mar 4 23:22:01 2004 Subject: [LMH] Ooh, look! List traffic! Message-ID: <707239AA-6E7D-11D8-9283-000A959B403C@caltech.edu> On 4 Mar 2004, at 18:57, Dan Moniz wrote: > On Thursday, March 04, 2004 7:01 PM +0000 Robert Swindells > wrote: >> I was only half joking about translating it to VHDL. >> [...] >> The whole CPU would fit into a $15 FPGA using current technology, add >> a couple of 16bit SDRAMs and some boot flash and you have a 10x faster >> microExplorer. > > [...] > Of course, there's the longer term problem of getting a monitor and > input devices to talk to it, which would be painful, and disks, file > systems, a running install, oh my! > Probably, now that I think about it, an FPGA-based Explorer processor > on a PCI card, with some interface glue would be the way to go. I don't know if this is applicable, but hey, you never know. When they made OpenGenera (you know, the virtual Symbolics-on-Alpha), they didn't give it any intrinsic knowledge about DEC's hardware. All it knew how to do was to talk on the network. It would then find its filesystem through NSF, display its interface through X11, and in various other ways leverage the fact that there was always a copy of OSF/1 to take care of bit-diddling IO. It's not very purist, but you could do a lot with a network interface, while a $200 Walmart FORTRAN Machine can take care of I/O. > If someone is willing to buy me a simple Xilinx setup (usable FPGA for > this purpose, test-board, Verilog compiler, etc.), I'll take a crack > at it. I won't hold my breath, but this equipment has come down in > price. I think the FPGA we'd want/need is more expensive than the one > included in their $70 - $100 starter kit. In all the following, please keep in mind that I just happen to have become interested in FPGA's like, what, three weeks ago, so don't take any of this to literally: Xilinx development boards are overpriced and geared towards industries, not hackers or students; third-party suppliers are cheaper. Some of their boards come as PCI cards, which would be a Good Thing. There's www.geda.seul.org for various GPL'ed design tools, including a Verilog simulator. Xilinx put out a student edition of their software that you can order on Amazon for $65. It contains VHDL and Verilog tools as well as lower-level tools. It has a limitation on the size of FPGA it can deal with, but I don't think that need be prohibitive. It says for an older version: "any XC9500 CPLD, any Spartan FPGA, any XC4000 FPGA up to an XC4010, or the XCV50 Virtex FPGA." Spartan goes up to 28*42 CLB's with 56kbits on-chip "block ram". The d*(&%^*& Xilinx website is down so I can't check what the limitations on the current version are or how many CLB's are on a Virtex. At the risk of seriously offending the intellect of readers who know computer architecture much better than I do from just reading Hennesy&Patterson: Even though on LISP machines the microcode has the added advantage that it can be reprogrammed easily, the original reason for Microcode as opposed to Hardwired Control is that you could conserve precious silicon area by having a really simple control unit (in the CADR, practically none, since the microcode instruction set is notoriously simple; I don't know much about the Exploder, but I imagine it's similar). This is why I'm not too worried about needing humongous amounts of silicon. Many FPGA's have built-in fast RAM that could contain microcode. Question: What is the Exploder microcode instruction set like? Is it *much* different, conceptually, from CADR microcode? This would determine the amount of FPGA area needed to implement the controller. If it's anything like the CADR, my hunch is: not much. Question: What is the word length on a uExploder again? (I'm sorry, I can't ever keep the word lengths of all different LISP machines detangled in my head.) The size of the datapath part of a design should scale about linearly in the word length. Of course, it also depends on how many different operations you need to do, how many registers you need &c. Question: How much microcode is there? I.e. how much microcode RAM do you need? It is my impression, but then again, I am by no means well-versed in this stuff (yet), that "naive" Verilog coding and then letting a synthesis program figure out which wires go where decreases performance by a factor of something manageable but annoying, and that people prefer to tweak their code, potentially later on in the process, to get better cycle times. For example, the LEON-1 SPARC implementation from ESA (http://www.estec.esa.nl/wsmwww/leon/) is written in portable VHDL, independent of the flavor of silicon. It runs at 45 MHz on a biggish Xilinx, but only "after layout", which I *assume* means after somebody who knew his Xilinx stuff gave extra hints to the Xilinx software as to what to put where and maybe tweaked some of the code. To do that, you would probably need simulation tools that come with your FPGA, which implies buying them from Xilinx. To just get working Verilog code, you could probably use the free Ikaros simulator. I'm trying to get into the whole FPGA thing because I'm supposed to implement a CPU in one for my summer job. There have been various reports from people doing interesting projects in surprisingly little time given the right tools; look up fpgacpu.org for some pointers and lots of FPGA shop talk. Especially his circuit cellar article gives a good idea of the practicalities involved, I think. Once again, he's doing RISC-like hardwired control, not microcoded control. I don't know if anyone has tried microcoded control yet. /jaap ======================================================================== Jaap Weel Campus address: | dorm (626) 795-9748 Caltech, Blacker '05 Caltech MSC #874, Pasadena, CA 91126, U.S.A. www.its.caltech.edu/~weel Permanent address: | home +31-46-4337033 E-mail: weel@caltech.edu Kelderstraat 2-4, 6171 GB Stein, Netherlands ======================================================================== From asholz@topinform.de Thu Mar 4 23:53:01 2004 From: asholz@topinform.de (Andreas Holz) Date: Thu Mar 4 23:53:01 2004 Subject: [LMH]Re: LispM-Hackers digest, Vol 1 #247 - 7 msgs In-Reply-To: <20040304210101.2184.qmail@kappa.unlambda.com> References: <20040304210101.2184.qmail@kappa.unlambda.com> Message-ID: <40483FE5.3040305@topinform.com> Robert, >I was only half joking about translating it to VHDL. > >Just having done the analysis of what the microarchitecture needs to >do might be useful in the long run. > >The whole CPU would fit into a $15 FPGA using current technology, add >a couple of 16bit SDRAMs and some boot flash and you have a 10x faster >microExplorer. > >Robert Swindells > > who can do that? Andreas From rjs@fdy2.demon.co.uk Fri Mar 5 01:05:02 2004 From: rjs@fdy2.demon.co.uk (Robert Swindells) Date: Fri Mar 5 01:05:02 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <3344789.1078426623@localhost> (message from Dan Moniz on Thu, 04 Mar 2004 18:57:03 -0800) Message-ID: <200403051001.i25A1QhX085020@ren.fdy2.net> Dan Moniz wrote: >On Thursday, March 04, 2004 7:01 PM +0000 Robert Swindells > wrote: >> Nyef wrote: >> > On Thu, Mar 04, 2004 at 10:18:20AM -0500, Nyef wrote: >> >> >> >> Yes, it's in Lisp. The old (late last year) source tarball is up in >> >> the same directory as all the screenshots ( >> >> http://www.dridus.com/~nyef/lispm/nevermore/ ), and I'm doing some >> >> cleanup on the current sources in preparation for releasing them at >> >> some point in the next day or so. >> >> > Fitting action to words, the new version is up as >> > http://www.dridus.com/~nyef/lispm/nevermore/nevermore-9e0304.tgz >> >> > I am uncertain as to if I will be continuing with this codebase. >> > The speed has reached the point of untenability. >> >> I was only half joking about translating it to VHDL. >> >> Just having done the analysis of what the microarchitecture needs to >> do might be useful in the long run. >> >> The whole CPU would fit into a $15 FPGA using current technology, add >> a couple of 16bit SDRAMs and some boot flash and you have a 10x faster >> microExplorer. >Which is an interesting point. I wonder how hard it would be to write >the emulator (or CPU) in Verilog (being somewhat higher-level and >easier to cope with than VHDL, at least for this task). I assume >"hard", and that would be an understatement. But possibly worthwhile. It seems to be a pretty standard student project right now to design a CPU. Check out as well. I don't think VHDL is too hard or too low level to be useful. >Of course, there's the longer term problem of getting a monitor and >input devices to talk to it, which would be painful, and disks, file >systems, a running install, oh my! >Probably, now that I think about it, an FPGA-based Explorer processor >on a PCI card, with some interface glue would be the way to go. I wrote "microExplorer" on purpose. >If someone is willing to buy me a simple Xilinx setup (usable FPGA for >this purpose, test-board, Verilog compiler, etc.), I'll take a crack >at it. I won't hold my breath, but this equipment has come down in >price. I think the FPGA we'd want/need is more expensive than the one >included in their $70 - $100 starter kit. The free version of Xilinx ISE will target a big enough Spartan 3. The older PCI card that I'm using at work sells for $200. Robert Swindells From weel@caltech.edu Fri Mar 5 04:30:01 2004 From: weel@caltech.edu (Jaap Weel) Date: Fri Mar 5 04:30:01 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <4048615D.4050702@utopia.com.br> References: <707239AA-6E7D-11D8-9283-000A959B403C@caltech.edu> <4048615D.4050702@utopia.com.br> Message-ID: <826ED1E4-6EA8-11D8-9283-000A959B403C@caltech.edu> Dear Mr. Banffy Somewhat old-fashionedly, the mailing list is set up so that if you hit=20= the reply button in your email client, it replies to the sender, not to=20= the mailing list. This behavior is a near-religious issue with some=20 mailing list administrators that you probably don't want to touch, but=20= for the time being, you should probably use reply-all. I sometimes=20 forget, too. While I'm at it, let me comment on your message. /jaap On 5 Mar 2004, at 03:15, Ricardo L. A. B=E1nffy wrote: > Gentlemen, > > It can't be that hard to emulate a decades-old architecture (late=20 > 80's? 90's? - I remember reading about them at my college library) on=20= > a couple gigahertz current processor. I know the architecture was far=20= > more complex than an ordinary desktop computer of that time (and=20 > probably is now), but I doubt it is beyond the reach of a modern=20 > processor. Being somewhat of a bookworm, I'm always interested in written matters;=20= what was it you found about Lisp machines in your college library? > I remember my Pentium something (in Portuguese we call them Lentiums,=20= > which is not funny in English) could emulate a 68K Macintosh about=20 > twice as fast as a 68K Macintosh could emulate itself. There weren't=20= > more than 5 years between the two computers. Hmm... the joke *is* funny in French. At any rate, you are completely=20 right in this observation. > IIRC, OpenGenera did just that - emulation atop an Alpha. If an Alpha=20= > can do it, a Pentium 4 HT or a PowerPC 970 can. Yes, although OpenGenera *was* extremely well-bummed for speed. It was=20= written in straight alpha assembly, with a Lisp-based macro layer on=20 top, and the programmers took great care to lay out the segments of=20 code in such a way as to minimize cache misses. The crucial trick is=20 that the alpha's L1 cache was fast enough that it could practically=20 function as a microcode store, so that if you kept the simulator in=20 cache at all times, you would loose relatively little performance. That=20= said, time heals all wounds, and Moore's law certainly does, so I=20 wouldn't be surprised if you could do the same thing in a high-level=20 language just fine given a 970 (a.k.a. G5). > Implementing an emulator in software ("C" seems an obvious choice=20 > because of performance and portability, if not elegance) would also be=20= > a nice starting point to any hardware implementations. At least, if=20 > well written (as in "human-readable"), it could serve as a reference=20= > to what, exactly, the hardware should be doing. Sure; programming, as Sussman likes to say, is a way of expressing=20 ideas as much as a way to tell a computer what to do. (I hope I'm=20 quoting this right at 5 in the morning.) > If we are really serious about doing it, the rights to the software=20 > must also be sorted out. How generous are their owners? As I remember, but others know this much better than I do, TI (or=20 whoever bought them) doesn't want to admit that they own the=20 intellectual property to anything Exploder-related without consulting=20 their lawyers, for which you'd have to pay them money. The consensus at=20= the time was to not deal with legal issues until anyone is approaching=20= a working emulator. > We would also need functioning hardware to validate the emulator=20 > against. Can it be provided? I think some people on the list have running TI hardware. > As Alastair pointed out, it is a big, hard and scary thing to do,=20 > until actually doing it proves us wrong. Yes, and the main problem seems to be finding out the details of how=20 the system worked. If the project were to write an emulator for a=20 machine that was completely specified, the project would probably be=20 much further by now; unfortunately the brave hackers that have worked=20 on it so far seem to have to spend a lot of time reverse-engineering. > Jaap Weel wrote: > >> I'm trying to get into the whole FPGA thing because I'm supposed to=20= >> implement a CPU in one for my summer job. There have been various=20 >> reports from people doing interesting projects in surprisingly little=20= >> time given the right tools; look up fpgacpu.org for some pointers and=20= >> lots of FPGA shop talk. Especially his circuit cellar article gives a=20= >> good idea of the practicalities involved, I think. Once again, he's=20= >> doing RISC-like hardwired control, not microcoded control. I don't=20 >> know if anyone has tried microcoded control yet. > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jaap Weel Campus address: | dorm (626) 795-9748 Caltech, Blacker '05 Caltech MSC #874, Pasadena, CA 91126, U.S.A. www.its.caltech.edu/~weel Permanent address: | home +31-46-4337033 E-mail: weel@caltech.edu Kelderstraat 2-4, 6171 GB Stein, Netherlands =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From mark@buttery.org Fri Mar 5 05:47:00 2004 From: mark@buttery.org (Mark J. Dulcey) Date: Fri Mar 5 05:47:00 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <707239AA-6E7D-11D8-9283-000A959B403C@caltech.edu> References: <707239AA-6E7D-11D8-9283-000A959B403C@caltech.edu> Message-ID: <404892AA.2060207@buttery.org> Jaap Weel wrote: > Even though on LISP machines the microcode has the added advantage that > it can be reprogrammed easily, the original reason for Microcode as > opposed to Hardwired Control is that you could conserve precious silicon > area by having a really simple control unit (in the CADR, practically > none, since the microcode instruction set is notoriously simple; I don't > know much about the Exploder, but I imagine it's similar). This is why > I'm not too worried about needing humongous amounts of silicon. Many > FPGA's have built-in fast RAM that could contain microcode. > > Question: What is the Exploder microcode instruction set like? Is it > *much* different, conceptually, from CADR microcode? This would > determine the amount of FPGA area needed to implement the controller. If > it's anything like the CADR, my hunch is: not much. I don't have any direct knowledge of the TI Explorer architecture, but I believe it's similar. > Question: What is the word length on a uExploder again? (I'm sorry, I > can't ever keep the word lengths of all different LISP machines > detangled in my head.) The size of the datapath part of a design should > scale about linearly in the word length. Of course, it also depends on > how many different operations you need to do, how many registers you > need &c. Like all machines in the LMI branch of LispM heritage, the Explorer and uExplorer had 32 bit words. > Question: How much microcode is there? I.e. how much microcode RAM do > you need? True, the CADR, and its direct descendent the LMI Lambda, had fairly simple microcontrollers. They made up for this by using a LOT of microcode. The CADR originally had 8K of 48-bit microwords; the machines were later expanded to 12K, and then to 16K, to accomodate the increasing complexity of the microcode over time. (Later software versions put more functions into microcode.) The Lambda had 16K 64-bit microwords, and used most of it to implement the rather baroque macroinstruction set of the LispM. In addition, the Lambda had a 128K byte RAM - 64K 16 bit words - that was used for brute-force dispatching of the macroinstructions; by then, there were enough different formats that it took quite a few tests just to figure out what type of instruction something was, so the Lambda eliminated the problem with a complete jump table. All of these processors have more microcode than you would find in a modern RISC processor, though perhaps not more than an x86 implementation would have. I don't know how much microcode the TI LispMs had. From nyef@softhome.net Fri Mar 5 06:02:01 2004 From: nyef@softhome.net (Nyef) Date: Fri Mar 5 06:02:01 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <404892AA.2060207@buttery.org> References: <707239AA-6E7D-11D8-9283-000A959B403C@caltech.edu> <404892AA.2060207@buttery.org> Message-ID: <20040305145858.GA1810@miyu.paradiesanalytics.com> On Fri, Mar 05, 2004 at 09:46:02AM -0500, Mark J. Dulcey wrote: > Jaap Weel wrote: > > >Question: What is the Exploder microcode instruction set like? Is it > >*much* different, conceptually, from CADR microcode? This would > >determine the amount of FPGA area needed to implement the controller. If > >it's anything like the CADR, my hunch is: not much. > > I don't have any direct knowledge of the TI Explorer architecture, but I > believe it's similar. It is similar. In some ways more complex, in some ways simpler. > Like all machines in the LMI branch of LispM heritage, the Explorer and > uExplorer had 32 bit words. All Explorers had 32-bit data words. The Explorer I used a 56-bit microinstruction word, and the later systems used a 64-bit microinstruction word. > >Question: How much microcode is there? I.e. how much microcode RAM do > >you need? For the Explorer I, it is #x800 words for the startup microcode and #x4000 words for the writable microcode store. The Explorer I also needs #x40 words of M-memory, #x400 words of A-memory, 16 words of T-memory, #x1000 words of D-memory, 64 words of microstack, #x1000 words of level-1 map memory, #x1000 words of level-2 map control memory, #x1000 words of level-2 map address memory, and #x400 words of PDL-buffer memory. The microcode stores use a 56-bit word, the microstack uses something a bit less than 32 bits (I forget what, was it 17 bits?), and everything else uses 32-bit words. --Alastair Bridgewater From eb@comsec.com Fri Mar 5 10:21:01 2004 From: eb@comsec.com (Eric Blossom) Date: Fri Mar 5 10:21:01 2004 Subject: [LMH]FPGA / microcode In-Reply-To: <707239AA-6E7D-11D8-9283-000A959B403C@caltech.edu> References: <707239AA-6E7D-11D8-9283-000A959B403C@caltech.edu> Message-ID: <20040305191626.GA22608@comsec.com> On Fri, Mar 05, 2004 at 12:04:12AM -0800, Jaap Weel wrote: > On 4 Mar 2004, at 18:57, Dan Moniz wrote: > >On Thursday, March 04, 2004 7:01 PM +0000 Robert Swindells > > wrote: > >>I was only half joking about translating it to VHDL. > >>[...] > >>The whole CPU would fit into a $15 FPGA using current technology, add > >>a couple of 16bit SDRAMs and some boot flash and you have a 10x faster > >>microExplorer. > > > >[...] > >Of course, there's the longer term problem of getting a monitor and > >input devices to talk to it, which would be painful, and disks, file > >systems, a running install, oh my! > >Probably, now that I think about it, an FPGA-based Explorer processor > >on a PCI card, with some interface glue would be the way to go. I've considered the FPGA idea myself a few times. It would be fun ;-) One thing to remember, is that by today's standards, the Explorer's have dinky address spaces. 24MW if I recall correctly. I think that a blind re-implementation of the architecture would be a waste of time. Why spend all the time and end up with something with a dinky address space? Another thing to consider is the basic "back of the envelope calculation". For the sake of argument, assume that you're using a Spartan 2E or Spartan 3 (The spartan 3 has bunches of embedded multipliers. You could really speed up your bignum multiplies with them ;-)). Using the lower speed grades (much cheaper!) you can probably run them at about 125 MHz (hands waving wildly...). This gives you a 125 MHz microinstruction cycle. Of course, you're free to build your memory subsystem as wide as you like, so make it 40-bits or 48-bits or 64-bits... Now, on the other hand, you're competing against 3 GHz Pentiums or AMD64s or Opterons running at 2.6GHz or so. All of these have an incredible amount of internal parallelism. You can easily get 4 or 5 operations going per cycle (this includes address generator updates, ALU ops, floating point adds, mults, loads, etc). Without working hard, this gives you an easy 6M ops/second. It's going to be really hard to get your 125 MHz FPGA implementation to even begin to keep up with these monsters. Perhaps the way to go would be do define yet-another-lisp-virtual-machine, or figure out what symbolics used (or just use Common Lisp with lots of declarations!) and target the AMD64 architecture. It's got twice as many registers as the x86, lots of address space, they keep getting faster and cheaper all the time, and you can order one today, and have it delivered tomorrow. If people really like the idea of running near the metal, consider using something like the L4 microkernel or EROS as the bottom layer. http://os.inf.tu-dresden.de/L4/ http://www.eros-os.org/ EROS implements a persistent single-level store, which would be ideal for lisp. This means everything is addressed the same. All of memory is persistent. There is no "file system", just a directory of objects. EROS is also capability based, which is also very cool, but not directly relevant to this discussion. > I don't know if this is applicable, but hey, you never know. When they > made OpenGenera (you know, the virtual Symbolics-on-Alpha), they didn't > give it any intrinsic knowledge about DEC's hardware. All it knew how > to do was to talk on the network. It would then find its filesystem > through NSF, display its interface through X11, and in various other > ways leverage the fact that there was always a copy of OSF/1 to take > care of bit-diddling IO. It's not very purist, but you could do a lot > with a network interface, while a $200 Walmart FORTRAN Machine can take > care of I/O. This seems like a reasonable approach to me. Otherwise you're always going to be "behind the power curve" when it comes to supporting new peripheral hardware. Let's just use it! Note that this is how the microExplorers work too. NFS and RPC to access the file system and display/mouse/keyboard respectively. The other approach would be to take a decent compiled CL implementation (e.g., SBCL) and start moving it closer to the metal. Let's not forget that compilers are a lot smarter now than they were 15 years ago. I personally think that experimenting with a machine with persistent memory would be fun. FYI, there's a port of SBCL to the AMD64 underway. Eric From rjs@fdy2.demon.co.uk Fri Mar 5 11:00:01 2004 From: rjs@fdy2.demon.co.uk (Robert Swindells) Date: Fri Mar 5 11:00:01 2004 Subject: [LMH]FPGA / microcode In-Reply-To: <20040305191626.GA22608@comsec.com> (message from Eric Blossom on Fri, 5 Mar 2004 11:16:26 -0800) Message-ID: <200403051956.i25JuXKO085976@ren.fdy2.net> Eric Blossom wrote: >> On 4 Mar 2004, at 18:57, Dan Moniz wrote: >> >On Thursday, March 04, 2004 7:01 PM +0000 Robert Swindells >> > wrote: >> >>I was only half joking about translating it to VHDL. >> >>[...] >> >>The whole CPU would fit into a $15 FPGA using current technology, add >> >>a couple of 16bit SDRAMs and some boot flash and you have a 10x faster >> >>microExplorer. >> > >> >[...] >> >Of course, there's the longer term problem of getting a monitor and >> >input devices to talk to it, which would be painful, and disks, file >> >systems, a running install, oh my! >> >Probably, now that I think about it, an FPGA-based Explorer processor >> >on a PCI card, with some interface glue would be the way to go. >I've considered the FPGA idea myself a few times. It would be fun ;-) >One thing to remember, is that by today's standards, the Explorer's >have dinky address spaces. 24MW if I recall correctly. I think that >a blind re-implementation of the architecture would be a waste of >time. Why spend all the time and end up with something with a dinky >address space? The attraction of a LispM over a Lisp system on stock hardware is the integrated environment. It is a lot easier to migrate to a larger address space when you have a running system. >Another thing to consider is the basic "back of the envelope >calculation". For the sake of argument, assume that you're using a >Spartan 2E or Spartan 3 (The spartan 3 has bunches of embedded >multipliers. You could really speed up your bignum multiplies with >them ;-)). Using the lower speed grades (much cheaper!) you can >probably run them at about 125 MHz (hands waving wildly...). This >gives you a 125 MHz microinstruction cycle. Of course, you're free to >build your memory subsystem as wide as you like, so make it 40-bits or >48-bits or 64-bits... The Spartan 3s are cheap in any speed grade. They are in rather short supply at the moment though. >Now, on the other hand, you're competing against 3 GHz Pentiums or >AMD64s or Opterons running at 2.6GHz or so. All of these have an >incredible amount of internal parallelism. You can easily get 4 or 5 >operations going per cycle (this includes address generator >updates, ALU ops, floating point adds, mults, loads, etc). Without >working hard, this gives you an easy 6M ops/second. It's going >to be really hard to get your 125 MHz FPGA implementation to even >begin to keep up with these monsters. I'm not suggesting that a FPGA LispM will compete with a native lisp running on the fastest desktop or server CPUs. The fast CPUs require a lot of cooling and won't run for long on batteries. Think instead of competing with PDA class CPUs, these are 400-500 MHz in-order RISC processors that use ~500mW. I think you are going to see a lot of products released over the next year that use soft CPU cores in FPGAs for embedded applications. Most of these will run something based on Linux, but they could run something else. >Perhaps the way to go would be do define >yet-another-lisp-virtual-machine, or figure out what symbolics used (or >just use Common Lisp with lots of declarations!) and target the AMD64 >architecture. It's got twice as many registers as the x86, lots of >address space, they keep getting faster and cheaper all the time, and >you can order one today, and have it delivered tomorrow. Rather than define another one, why not follow KMP's suggestion and make a business proposal to new Symbolics. Someone, or a small group, could offer to port the VLM to AMD64 in exchange for X number of licences to use the finished product. Robert Swindells From eb@comsec.com Fri Mar 5 11:40:01 2004 From: eb@comsec.com (Eric Blossom) Date: Fri Mar 5 11:40:01 2004 Subject: [LMH]FPGA / microcode In-Reply-To: <200403051956.i25JuXKO085976@ren.fdy2.net> References: <20040305191626.GA22608@comsec.com> <200403051956.i25JuXKO085976@ren.fdy2.net> Message-ID: <20040305203534.GA22931@comsec.com> On Fri, Mar 05, 2004 at 07:56:33PM +0000, Robert Swindells wrote: > Eric Blossom wrote: >> > > The attraction of a LispM over a Lisp system on stock hardware is > the integrated environment. Perhaps I'm missing something? What's stopping us from having an integrated environment on stock hardware? I see that we could have lisp code that directly addresses the frame buffer, or for that matter, lisp code that directly manipulates the page table entries on stock hardware. For that matter, why not just compile the LispM lisp source to AMD64 native instructions? > It is a lot easier to migrate to a larger address space when you > have a running system. Sure. > >Perhaps the way to go would be do define > >yet-another-lisp-virtual-machine, or figure out what symbolics used (or > >just use Common Lisp with lots of declarations!) and target the AMD64 > >architecture. It's got twice as many registers as the x86, lots of > >address space, they keep getting faster and cheaper all the time, and > >you can order one today, and have it delivered tomorrow. > > Rather than define another one, why not follow KMP's suggestion and > make a business proposal to new Symbolics. > > Someone, or a small group, could offer to port the VLM to AMD64 in > exchange for X number of licences to use the finished product. Not a bad idea, but it leaves us in the same mess we're in now: No free software / open source lisp machine. I suggest that we learn from the examples of the past, but start new, with free software all the way to the bottom. We've got good free compilers already. There's McCLIM for the display. There are a couple of emacs-ish editors in CL. We may not actually be that far away. Eric From mikemac@mikemac.com Fri Mar 5 11:47:01 2004 From: mikemac@mikemac.com (Mike McDonald) Date: Fri Mar 5 11:47:01 2004 Subject: [LMH]FPGA / microcode In-Reply-To: Your message of "Fri, 05 Mar 2004 12:35:34 PST." <20040305203534.GA22931@comsec.com> Message-ID: <200403052046.i25KkjR03042@saturn.mikemac.com> >To: Robert Swindells >Date: Fri, 5 Mar 2004 12:35:34 -0800 >From: Eric Blossom > >Not a bad idea, but it leaves us in the same mess we're in now: >No free software / open source lisp machine. > >I suggest that we learn from the examples of the past, but start new, >with free software all the way to the bottom. We've got good free >compilers already. There's McCLIM for the display. There are a >couple of emacs-ish editors in CL. We may not actually be that far >away. Oh no! Not the dreaded "lets write a LispOS from scratch" thread again! :-) The LispM environment is the result of a lot of very smart people putting in a lot of years work on it. It's not something that is easily duplicated. Mike McDonald mikemac@mikemac.com From rbanffy@utopia.com.br Fri Mar 5 12:07:01 2004 From: rbanffy@utopia.com.br (=?ISO-8859-1?Q?Ricardo_B=E1nffy?=) Date: Fri Mar 5 12:07:01 2004 Subject: [LMH] Ooh, look! List traffic! In-Reply-To: <826ED1E4-6EA8-11D8-9283-000A959B403C@caltech.edu> Message-ID: <59B960FC-6EE9-11D8-AEC4-000502C1962C@utopia.com.br> On Friday, March 5, 2004, at 10:25 AM, Jaap Weel wrote: > Somewhat old-fashionedly, the mailing list is set up so that if you > hit the reply button in your email client, it replies to the sender, > not to the mailing list. This behavior is a near-religious issue with > some mailing list administrators that you probably don't want to > touch, but for the time being, you should probably use reply-all. I > sometimes forget, too. While I'm at it, let me comment on your > message. If it is a religious issue, I can live with it ;-) > Being somewhat of a bookworm, I'm always interested in written > matters; what was it you found about Lisp machines in your college > library? Discussions about AI-related stuff and ads featuring machines that looked amazingly cool ;-) > The consensus at the time was to not deal with legal issues until > anyone is approaching a working emulator. We could do something in the political sphere. I bet they don't expect to extract much cash from this, but they could win sympathy. Having said that, the Hercules mainframe emulator keeps coming to my mind. IBM could license more software for hobbyist or education purposes. >> As Alastair pointed out, it is a big, hard and scary thing to do, >> until actually doing it proves us wrong. > Yes, and the main problem seems to be finding out the details of how > the system worked. If the project were to write an emulator for a > machine that was completely specified, the project would probably be > much further by now; unfortunately the brave hackers that have worked > on it so far seem to have to spend a lot of time reverse-engineering. You mean there is no documentation on low level programming?! Oh boy... This may just be a big hard and scary thing to do and actually doing it may prove us right ;-) Have the results of this reverse-engineering been published? I can't find much about it. From eb@comsec.com Fri Mar 5 12:21:01 2004 From: eb@comsec.com (Eric Blossom) Date: Fri Mar 5 12:21:01 2004 Subject: [LMH]FPGA / microcode In-Reply-To: <200403052046.i25KkjR03042@saturn.mikemac.com> References: <20040305203534.GA22931@comsec.com> <200403052046.i25KkjR03042@saturn.mikemac.com> Message-ID: <20040305211652.GA22982@comsec.com> On Fri, Mar 05, 2004 at 03:46:45PM -0500, Mike McDonald wrote: > > >To: Robert Swindells > >Date: Fri, 5 Mar 2004 12:35:34 -0800 > >From: Eric Blossom > > > >Not a bad idea, but it leaves us in the same mess we're in now: > >No free software / open source lisp machine. > > > >I suggest that we learn from the examples of the past, but start new, > >with free software all the way to the bottom. We've got good free > >compilers already. There's McCLIM for the display. There are a > >couple of emacs-ish editors in CL. We may not actually be that far > >away. > > Oh no! Not the dreaded "lets write a LispOS from scratch" thread > again! :-) > > The LispM environment is the result of a lot of very smart people > putting in a lot of years work on it. Agreed. > It's not something that is easily duplicated. Particulary if we never start ;-) However, let's get real. The existing LispM environments are effectively dead. The sources for them are encumbered by various companies, some of which are pretty close to zombies, but which still have stockholders to answer to. Unless the copyright holders release the source we're stuck. Yes, I know the source is around, but we'll never really get this thing off the ground if there isn't good, clear title to the code. The other thing to remember is that those smart people wrote a lot of papers. It's a lot easier to write code when you already know where you're trying to get to. I'm not proposing "let's write a LispOS from scratch", I'm asking "What was it about the lisp machines that made them great?" extrapolate fifteen or twenty years, now how can we get there, only this time with free software? Maybe this is the dreaded "lets write a LispOS from scratch" thread... Eric From weel@caltech.edu Fri Mar 5 12:30:01 2004 From: weel@caltech.edu (Jaap Weel) Date: Fri Mar 5 12:30:01 2004 Subject: [LMH]FPGA / microcode In-Reply-To: <200403052046.i25KkjR03042@saturn.mikemac.com> References: <200403052046.i25KkjR03042@saturn.mikemac.com> Message-ID: <9AC077A2-6EEB-11D8-9283-000A959B403C@caltech.edu> "I was an old fart when I was in my twenties" -- Alan Kay Don't be too offended; just realize that there was a LispOS mailing list that discussed for 2 entire years about CL vs. Scheme, VM vs. native, from scratch vs. Linux-based. The list archive greatly exceeds in size the code that was ever written. Hence, there is a strong feeling among people who have witnessed these endless discussions before that talking about "LispOS" on mailing lists is intrinsically wasteful of time. All that said, please do check out Movitz. /jaap On 5 Mar 2004, at 12:46, Mike McDonald wrote: >> To: Robert Swindells >> >> I suggest that we learn from the examples of the past, but start new, >> with free software all the way to the bottom. We've got good free >> compilers already. There's McCLIM for the display. There are a >> couple of emacs-ish editors in CL. We may not actually be that far >> away. > > Oh no! Not the dreaded "lets write a LispOS from scratch" thread > again! :-) > > The LispM environment is the result of a lot of very smart people > putting in a lot of years work on it. It's not something that is > easily duplicated. > > Mike McDonald From bmastenb@cs.indiana.edu Fri Mar 5 12:38:01 2004 From: bmastenb@cs.indiana.edu (Brian Mastenbrook) Date: Fri Mar 5 12:38:01 2004 Subject: [LMH]FPGA / microcode In-Reply-To: <20040305203534.GA22931@comsec.com> References: <20040305191626.GA22608@comsec.com> <200403051956.i25JuXKO085976@ren.fdy2.net> <20040305203534.GA22931@comsec.com> Message-ID: <43541C80-6EED-11D8-BAE3-000A9599AF88@cs.indiana.edu> > Not a bad idea, but it leaves us in the same mess we're in now: > No free software / open source lisp machine. > > I suggest that we learn from the examples of the past, but start new, > with free software all the way to the bottom. We've got good free > compilers already. There's McCLIM for the display. There are a > couple of emacs-ish editors in CL. We may not actually be that far > away. If you haven't been paying attention, you ought to look at what the rest of the lisp world is doing with cirCLe: http://ww.telent.net/diary/ -- Brian Mastenbrook bmastenb@cs.indiana.edu http://cs.indiana.edu/~bmastenb/ From eb@comsec.com Fri Mar 5 17:14:01 2004 From: eb@comsec.com (Eric Blossom) Date: Fri Mar 5 17:14:01 2004 Subject: [LMH]FPGA / microcode In-Reply-To: <9AC077A2-6EEB-11D8-9283-000A959B403C@caltech.edu> References: <200403052046.i25KkjR03042@saturn.mikemac.com> <9AC077A2-6EEB-11D8-9283-000A959B403C@caltech.edu> Message-ID: <20040306020937.GA23329@comsec.com> On Fri, Mar 05, 2004 at 01:25:20PM -0800, Jaap Weel wrote: > "I was an old fart when I was in my twenties" > -- Alan Kay > > Don't be too offended; just realize that there was a LispOS mailing > list that discussed for 2 entire years about CL vs. Scheme, VM vs. > native, from scratch vs. Linux-based. The list archive greatly exceeds > in size the code that was ever written. Hence, there is a strong > feeling among people who have witnessed these endless discussions > before that talking about "LispOS" on mailing lists is intrinsically > wasteful of time. > > All that said, please do check out Movitz. > > /jaap > Thanks for references to the LispOS list and Movitz. There's a ton clueful discussion in the LispOS list archives. Too bad no lisp LispOS came out of it :-) Eric From hans@huebner.org Sat Mar 6 04:34:00 2004 From: hans@huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sat Mar 6 04:34:00 2004 Subject: [LMH]FPGA / microcode In-Reply-To: <20040305191626.GA22608@comsec.com> References: <707239AA-6E7D-11D8-9283-000A959B403C@caltech.edu> <20040305191626.GA22608@comsec.com> Message-ID: <20040306134112.F78197@exklave.huebner.org> On Fri, 5 Mar 2004, Eric Blossom wrote: > Another thing to consider is the basic "back of the envelope > calculation". For the sake of argument, assume that you're using a > Spartan 2E or Spartan 3 (The spartan 3 has bunches of embedded > multipliers. [...] Speed is not the (major) point which drives the wish for an Explorer emulator. The original Explorer was indeed fast enough for a number of serious tasks, so having an implementation of it which is, say, ten times faster than the original hardware gives a lot of speedup for new applications. Price is much more influencial. If I read the latest comments correctly, a FPGA explorer could cost around $100 in chips, which is really in the (grown-up) toy price range. The reason to want Lisp hardware is the fact that such a CPU would eliminate a lot of complexity levels which are present when using LISP on a general purpose machine. Lisp hardware puts the whole computer, and not only a virtual image of a non-existing system, directly under control of the LISP code you work with in your development environment. If you need to work at high levels of abstraction, you can formulate suitable algorithms readably. If you need to handle interrupts within a certain amount of time, you can again formulate solutions in the same language and environment which is your high-level problem solving tool. Using the Explorer as starting hardware has the beauty that a lot of work has already been done by smart people. For example, TI's Emacs implementation Zmacs seems to be very good - at least from what I read from the excellent documentation. Having a working development environment within the new plattform is a really big plus, since otherwise you almost certainly end up cross compiling from Windows or Unix and having to spend time fixing the broken development environment instead of the target platform. It is true that the limited word length of the Explorer restricts the usefulness of any new implementation to problems of a certain maximum size. Still, I think it would be a excellent platform for applications like mail and personal information management as well as text processing. To me, these applications are not solved satisfactory by current software environments and I'd rather store and process all my email, contact information and appointments within a portable solid-state Lisp system than in Outlook or Unix files. There have been a lot of ambitious open source developments for advanced operating systems and development environments. None of the projects I am aware of have had any significant visibility, unless they have been directly funded and influenced by the industry. Using the existing Explorer code base would have such a funding in form of the intellectual property of TI (or whoever), which truly pushes the whole effort into some uncertainity. I am very curious to see this progress and I hope that enough free energy can be accumulated to get a new Explorer implementation running. Best regards, Hans From james@unlambda.com Sun Mar 7 19:16:01 2004 From: james@unlambda.com (James A. Crippen) Date: Sun Mar 7 19:16:01 2004 Subject: Infrastructure update (was Re: [LMH] Ooh, look! List traffic!) In-Reply-To: <59B960FC-6EE9-11D8-AEC4-000502C1962C@utopia.com.br> (Ricardo =?iso-8859-1?q?B=E1nffy's?= message of "Fri, 5 Mar 2004 18:09:11 -0300") References: <59B960FC-6EE9-11D8-AEC4-000502C1962C@utopia.com.br> Message-ID: Ricardo B=E1nffy writes: > If it is a religious issue, I can live with it ;-) I have it set up that way because it seemed to me when I first set up the list that the world expected mailing lists to be so configured that way. However, one of these days when I'm out from under my enormous pile of papers (taking two history courses and a philosophy course in one semester was in retrospect a stupid thing to do), I'll get back to building a kappa replacement. I have a couple of adequate systems and disks rescued from a dumpster, and I've gotten most of the way towards getting them usable, but I still need to get DNS, qmail, and Mailman running, and copy over the home directories. All that requires that I actually clean a path through the computer room to the computers in question, and that will take at least as much time to do. After kappa is rebuilt and restored I intend to put the temporary computer to use as a file server, which will free up space from kappa's sagging disks and add 10GB to the available storage. I'm also considering converting the repo to Subversion, but that's for later discussion. It seems to be much more efficient and has less problems with firewalls than does CVS. >> Being somewhat of a bookworm, I'm always interested in written matters; >> what was it you found about Lisp machines in your college library? > > Discussions about AI-related stuff and ads featuring machines that looked > amazingly cool ;-) Mine has, for some reason completely unbenknownst to any of the CS faculty, a copy of the INTERLISP manual from the PDP-10 days. I don't recall the exact date, but it didn't mention INTERLISP-D at all. Nobody here actually even knew what INTERLISP was except me. I don't think any of them knew what a PDP-10 was either. Which is one reason why I'm changing schools soon. That one apart from the Winston-Horn book is the only Lisp stuff I could find in our library. Strange. Although I did find a binder labeled "VAX NIL" and another labeled "TI PC Scheme" in the trash one day. No idea where those came from, and they didn't include contents. Kept them for hysterical value. >> The consensus at the time was to not deal with legal issues until anyone >> is approaching a working emulator. > > We could do something in the political sphere. I bet they don't expect to > extract much cash from this, but they could win sympathy. Having said tha= t, > the Hercules mainframe emulator keeps coming to my mind. IBM could license > more software for hobbyist or education purposes. I really think given the current `debates' going on in the wider world about software that we should stick to the original plan of having something working before we start pestering TI for rights. I'd really rather not have some lawyer after me with the DMCA in his hand right now, and I think my name, Alastair's, and John's are the three most well known out there. I suppose if there's still nothing really working (enough to give a working Lisp interpreter) in a couple more years people could start doing whatever they want. But I suspect that both JM and Nyef would like to avoid lawyers as much as I would right now. My father got a call from a lawyer in San Francisco last summer who was asking him about something to do with Lisp. He said he figured the guy got his name from the phone book (we have the same first and last names) and called him. My father gave the guy my number but he never followed up. And that was close enough for me. I want to at least have my degree done before I have to fuss with law. > You mean there is no documentation on low level programming?! Oh boy... T= his > may just be a big hard and scary thing to do and actually doing it may pr= ove > us right ;-) Have the results of this reverse-engineering been published?= I > can't find much about it. Alastair has done an incredible amount of reverse engineering already. I have complete confidence in his skills, even if he doesn't. ;-) I never have the time to help, which is horribly unfortunate, because I'd absolutely love to do so. But if anyone else is really genuinely interested I recommend them reading through all of the threads in which he's posted details, and then reading what he's got done so far very carefully. Then ask him for recommendations on where to start. The real trick is not to see the huge amorphous mass of undefined hardware and microcode, but to look at the system one instruction at a time. Nyef's had really great success with this approach. 'james --=20 James A. Crippen Lambda Unlimited 61.2204N, -149.8964W Recursion 'R' Us Anchorage, Alaska, USA, Earth Y =3D \f.(\x.f(xx))(\x.f(xx)) From james@unlambda.com Sun Mar 7 19:23:01 2004 From: james@unlambda.com (James A. Crippen) Date: Sun Mar 7 19:23:01 2004 Subject: [LMH]FPGA / microcode In-Reply-To: <200403052046.i25KkjR03042@saturn.mikemac.com> (Mike McDonald's message of "Fri, 05 Mar 2004 15:46:45 -0500") References: <200403052046.i25KkjR03042@saturn.mikemac.com> Message-ID: Mike McDonald writes: > Oh no! Not the dreaded "lets write a LispOS from scratch" thread > again! :-) Yes, let's keep it off here, please. People who want a PC Lisp OS should look at Movitz. Hardware hackers can of course do whatever they'd like, but this is probably not the best place to discuss it unless it's a hardware emulator of one of the existing LispMs, in which case it's totally on topic. Not that I mind the list traffic or anything, but I just don't think we should resurrect the LispOS thread. It lowers the S/N ratio far too much. And poor kappa is drowning under spam already... > The LispM environment is the result of a lot of very smart people > putting in a lot of years work on it. It's not something that is > easily duplicated. This is even more true than people often think. Consider that both Symbolics and LMI never abandoned the MIT sources to start over. And TI kept with the MIT sources as well. Even Genera 8.3 still includes an enormous amount of MIT code, because it's far too much work to throw away. People love to talk about creating OSes and OEs from scratch, but very few people seem to enjoy actually doing the work. (I should be one to talk. I never get any of my hacking projects finished. *sigh*) 'james -- James A. Crippen Lambda Unlimited 61.2204N, -149.8964W Recursion 'R' Us Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx)) From nyef@softhome.net Mon Mar 8 05:45:01 2004 From: nyef@softhome.net (Nyef) Date: Mon Mar 8 05:45:01 2004 Subject: Infrastructure update (was Re: [LMH] Ooh, look! List traffic!) In-Reply-To: References: <59B960FC-6EE9-11D8-AEC4-000502C1962C@utopia.com.br> Message-ID: <20040308144117.GA6484@miyu.paradiesanalytics.com> On Sun, Mar 07, 2004 at 07:15:39PM -0900, James A. Crippen wrote: > > I really think given the current `debates' going on in the wider world > about software that we should stick to the original plan of having > something working before we start pestering TI for rights. I'd really > rather not have some lawyer after me with the DMCA in his hand right > now, and I think my name, Alastair's, and John's are the three most > well known out there. I suppose if there's still nothing really > working (enough to give a working Lisp interpreter) in a couple more > years people could start doing whatever they want. But I suspect that > both JM and Nyef would like to avoid lawyers as much as I would right > now. Right now our biggest safeguards is not having working emulators and not having the ROM files easily accessible. Even if they know we're working on it, it's not such a big deal when only a select few people (most of whom would be in the market for the real thing -anyway-) can actually do anything with it. As it stands, I suspect that when we get everything close to working we should have the emulators and ROMs hosted on different sites by different people. And the ROM sites should be hard to get to. Which, admittedly, is just about how things are now. You basically have to ask someone who already has the ROMs and disk images to share. At that point we might consider writing a few academic-looking papers on the design of the emulators and the process of their creation, and try and keep everything as innocent-looking as possible. Or not. > > You mean there is no documentation on low level programming?! Oh boy... This > > may just be a big hard and scary thing to do and actually doing it may prove > > us right ;-) Have the results of this reverse-engineering been published? I > > can't find much about it. > > Alastair has done an incredible amount of reverse engineering > already. I have complete confidence in his skills, even if he > doesn't. ;-) My skills I have confidence in. My patience and continued interest, I don't. James, you aren't the only one who has trouble finishing projects. ^_- And, actually, -some- of the low-level programming information has been turning up. Usually shortly after I figure it out for myself. Amazing synchrony there. Most of what we don't have documentation for now is the internals of the CPU, particularly the ALU setup, and the memory boards. Scans for the SIB, NuPI, CPU, and ethernet boards are available, as are scans of parts of the maintenance manuals. > I never have the time to help, which is horribly > unfortunate, because I'd absolutely love to do so. But if anyone else > is really genuinely interested I recommend them reading through all of > the threads in which he's posted details, and then reading what he's > got done so far very carefully. Then ask him for recommendations on > where to start. For exploiter: Read all of SSDN2, ucode/def-elroy.lisp, ucode/defop.lisp ucode/lroy-qcom.lisp, ucode/lroy-qdev.lisp, ucode/lroy-templates.lisp, the list archives (particularly the Bug in SSDN2 posts), and then run exploiter and start reading through the output trying to line it up to the source tarball (remembering that the load band you use may be out of date with respect to the sources we have). For nevermore: Do the exploiter list (except maybe the bit about running exploiter) and read E1-proc-gen.pdf (except for the stuff about macroinstructions), ucode/ravfmt.lisp, ucode/ravsym.lisp, and anything in the list archives by Steve Krueger. Also hit up the bitsavers.org document archive and grab all the TI Explorer docs. Read anything that sounds like it is about hardware rather than software. Run nevermore for a while by single-stepping through instructions. Figure out how to make the nevermore disassembler work against prom-memory instead of reading from the prom_combined file (that none of you have). Disassemble the boot prom, figure out what it does (having an emulator here helps a -lot-, that's why I wrote nevermore in the first place). Actually, fixing up the disassembler would be a good first project for someone to get involved in nevermore. Making it work on a .mcr file would just be a bonus (now that we know the file format). Wait until I release a new version before starting, though, since I sortof changed some of the data formats... The game plan, if anyone wants to fix the disassembler, is to wait until the new version of nevermore, fix the disassembler as it is now, then I will release my current disassembly and symbol table files, then whoever is working on the disassembler can see about adding .mcr file support for Explorer I microloads (since they will then know what the file format is). > The real trick is not to see the huge amorphous mass of undefined > hardware and microcode, but to look at the system one instruction at a > time. Nyef's had really great success with this approach. That's because this approach is the one that works for me. As an example, instead of looking at the second instruction in the first function in the lisp load band and saying "Oh no, CALL-1-DEST-INDS is a function call instruction, that means we have to implement function calling next", what I do is look at it and say "Hrm... CALL-1-DEST-INDS is a function call instruction, what is it calling in this case? Oh, a DTP-FUNCTION? And what state do I have to set up to start in on the next function? Oh, I need to set up an args pointer, a locals pointer, reserve space for the locals, and set up the new function pointer. Oh, and make sure that the emulator dies with an error message if we try to call anything other than a DTP-FUNCTION. And don't bother saving the information for the return instructions, I'll deal with that when I get to them. I wonder what neat things I'll learn trying to step through this next function?" I stuck all of this in under a check specifically for the CALL-1-DEST-INDS instruction used in that first function. Any other call instruction would stop the emulator with an undefined opcode message. I hack through things this way, just handling the bare minimum of any situation that I don't understand, until I have enough information to go back and do it right. It's not exactly an approach to writing software, it's more an approach to learning about something that creates software as part of the learning process. The upside is that it leaves a record of the understanding gained. The downside is that that record is relatively difficult to interpret. About how long after we get this working do you think it'll be before someone tries to cross-build SBCL from it? ^_^ --Alastair From lars@nocrew.org Mon Mar 8 05:57:00 2004 From: lars@nocrew.org (Lars Brinkhoff) Date: Mon Mar 8 05:57:00 2004 Subject: Infrastructure update (was Re: [LMH] Ooh, look! List traffic!) In-Reply-To: <20040308144117.GA6484@miyu.paradiesanalytics.com> References: <59B960FC-6EE9-11D8-AEC4-000502C1962C@utopia.com.br> <20040308144117.GA6484@miyu.paradiesanalytics.com> Message-ID: <857jxvmlpw.fsf@junk.nocrew.org> Nyef writes: > we might consider writing a few academic-looking papers on the > design of the emulators and the process of their creation, and try > and keep everything as innocent-looking as possible. Sounds much like what Bob Supnik has done with the SIMH project. One strategy could be to release a LispM emulator under the SIMH brand, to make it more legitimate as a historical preservation project. -- Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP Brinkhoff Consulting http://www.brinkhoff.se/ From rbanffy@utopia.com.br Mon Mar 8 19:34:00 2004 From: rbanffy@utopia.com.br (=?ISO-8859-1?Q?=22Ricardo_L=2E_A=2E_B=E1nffy=22?=) Date: Mon Mar 8 19:34:00 2004 Subject: Infrastructure update (was Re: [LMH] Ooh, look! List traffic!) In-Reply-To: <857jxvmlpw.fsf@junk.nocrew.org> References: <59B960FC-6EE9-11D8-AEC4-000502C1962C@utopia.com.br> <20040308144117.GA6484@miyu.paradiesanalytics.com> <857jxvmlpw.fsf@junk.nocrew.org> Message-ID: <404D48F4.7070307@utopia.com.br> Lars Brinkhoff wrote: > Nyef writes: > >> we might consider writing a few academic-looking papers on the >> design of the emulators and the process of their creation, and try >> and keep everything as innocent-looking as possible. > > > > Sounds much like what Bob Supnik has done with the SIMH project. One > strategy could be to release a LispM emulator under the SIMH brand, to > make it more legitimate as a historical preservation project. > But this IS a historical preservation project. Is anyone here expecting to accomplish any real work on emulators? Anyway, I am sure that anything done after Nyef wrote that will never look innocent enough. From james@unlambda.com Tue Mar 9 10:28:01 2004 From: james@unlambda.com (James A. Crippen) Date: Tue Mar 9 10:28:01 2004 Subject: [LMH]Re: Infrastructure update In-Reply-To: <20040308144117.GA6484@miyu.paradiesanalytics.com> (nyef@softhome.net's message of "Mon, 8 Mar 2004 09:41:17 -0500") References: <59B960FC-6EE9-11D8-AEC4-000502C1962C@utopia.com.br> <20040308144117.GA6484@miyu.paradiesanalytics.com> Message-ID: Nyef writes: > About how long after we get this working do you think it'll be before > someone tries to cross-build SBCL from it? ^_^ The same week that the C compiler works. After SBCL is mostly ported some damned fool will try porting GCC. And then of course they will team up with some other evil mongrels and port Linux to it, which will be its (the Exploder's) undoing. But probably a good thing for Linux. 'james -- James A. Crippen Lambda Unlimited 61.2204N, -149.8964W Recursion 'R' Us Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx)) From nyef@softhome.net Wed Mar 10 15:39:00 2004 From: nyef@softhome.net (Nyef) Date: Wed Mar 10 15:39:00 2004 Subject: [LMH]Memory board docs? Message-ID: <20040311003451.GA10084@miyu.paradiesanalytics.com> Hello all. Does anyone have a copy of the memory board manual? The name and part number is: Explorer Memory General Description (8-megabytes) 2533592-0001 It doesn't appear to be on bitsavers.org with the rest of the docs, and I'm somewhat at a loss as to what's going on with the parity tests on the configuration rom. --Alastair From ford@objs.com Wed Mar 10 16:42:00 2004 From: ford@objs.com (ford@objs.com) Date: Wed Mar 10 16:42:00 2004 Subject: [LMH]Memory board docs? In-Reply-To: <20040311003451.GA10084@miyu.paradiesanalytics.com> References: <20040311003451.GA10084@miyu.paradiesanalytics.com> Message-ID: <404FC37B.1030003@objs.com> This is a multi-part message in MIME format. --------------000105050801000208000208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have that manual somewhere (I attached the list of the manuals I have). I'll dig it up and scan the TOC. Steve Nyef wrote: >Hello all. > >Does anyone have a copy of the memory board manual? The name and part >number is: > >Explorer Memory General Description (8-megabytes) 2533592-0001 > >It doesn't appear to be on bitsavers.org with the rest of the docs, >and I'm somewhat at a loss as to what's going on with the parity tests >on the configuration rom. > >--Alastair > >http://lists.unlambda.com/mailman/listinfo/lispm-hackers > > > --------------000105050801000208000208 Content-Type: text/html; charset=ISO-8859-1; name="manuals.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="manuals.html" THE EXPLORER TM SYSTEM SOFTWARE MANUALS I scanned in the manual list for the two major Explorer eras, the original 1985 release of the Explorer (through 1986), and the release of the Explorer II and Release 3.0 in the summer of 1987.  I have copies of the manuals for which there is a Rev date on the right.  I'm willing to scan in TOCs and relatively small numbers of pages upon request, or take one out to be copied.  My scanner's not up to more than that.

Steve

THE EXPLORERTM SYSTEM SOFTWARE MANUALS (May 1986)

Mastering the Explorer Environment

Explorer Technical Summary                               2243189-0001  Rev B May 86
                                                                       Rev C May 87
Explorer Operations Guide                                2243190-0001  Rev A May 86
Explorer Zmacs Editor Tutorial                           2243191-0001
Explorer Glossary                                        2243134-0001  Orig  Jun 85
                                                                       Rev A Jun 87
Explorer Communications User's Guide                     2243206-0001  Rev A Mar 86
Explorer Diagnostics                                     2533554-0001
Explorer Master Index to Software Manuals                2243198-0001  Orig  Jun 85
                                                                       Rev B Jan 88
Explorer System Software Installation                    2243205-0001  Rev B May 86
Explorer System Software Release Information Rel 2.0                   Rev C Mar 86

Programming With the Explorer

Explorer Programming Primer                              2243199-0001  Orig  Jun 85
Common LISP, The Language, by Guy L. Steele, Jr.         2537175-0001
Explorer Lisp Reference                                  2243201-0001
Explorer Zmacs Editor Reference                          2243192-0001
Explorer Programming Concepts and Tools                  2243130-0001  Orig  Jun 85
Explorer Window System Reference                         2243200-0001  Orig  Jun 85
Explorer Command Interface Toolkit User's Guide          2243197-0001  Orig  Jun 85

Explorer Toolkits

Explorer Natural Language Menu System User's Guide       2243202-0001
Explorer Natural Language Menu System Technical Report                 Orig  Jun 85
Explorer Relational Table Management System User's Guide 2243203-0001  Chg 1 Mar 86
Explorer Graphics Toolkit User's Guide                   2243195-0001
Explorer Grasper User's Guide                            2243135-0001
Explorer Prolog Toolkit User's Guide                     2243204-0001
Programming in Prolog, by Clocksin and Mellish           2249985-0001
Explorer Color Graphics User's Guide, Support for the
  Raster Technologies Model One                          2537157-0001
Explorer TCP/IP User's Guide                             2537150-0001

System Software Internals

Explorer System Software Design Notes                    2243208-0001

Explorer is a trademark of Texas Instruments Incorporated.

THE EXPLORERTM SYSTEM HARDWARE MANUALS (May 1986)

System Level Hardware Publications

Explorer Unpacking and Inventory                         2243216-0001  Orig  Apr 85
Explorer 7-Slot System Installation                      2243140-0001  Orig  Apr 85
Explorer System Field Maintenance                        2243141-0001

System Enclosure Hardware Publications

Explorer 7-Slot System Enclosure General Description     2243143-0001  Rev A Jul 85
Explorer 2-Megabyte Memory General Description           2243147-0001
Explorer Memory General Description                      2533592-0001  Orig  Aug 85
Explorer Processor General Description                   2243144-0001  Rev A Oct 85
Explorer Display Unit General Description                2243151-0001  Orig  May 85
Explorer System Interface General Description            2243145-0001  Rev A Oct 85

Mass Storage Hardware Publications

Explorer Mass Storage Enclosure General Description      2243148-0001  Rev A Oct 85
Explorer Winchester Disk Formatter (ADAPTEC) Supplement
  to Explorer Mass Storage Enclosure General Description 2243149-0001  Rev   Sep 85
Explorer Winchester Disk Drive (Maxtor) Supplement to
  Explorer Mass Storage Enclosure General Description    2243150-0001  Rev A Oct 85
Explorer Cartridge Tape Drive (Cipher) Supplement to
  Explorer Mass Storage Enclosure General Description    2243166-0001  Rev A Oct 85
Explorer Cable Interconnect Board (2236120-0001) Supplement
  to Explorer Mass Storage Enclosure General Description 2243177-0001  Rev A Oct 85
Explorer NuBus" Peripheral Interface
  General Description (NUPI board)                       2243146-0001  Rev A Oct 85

Mass Storage Hardware Vendor Publications

Series 540 Cartridge Tape Drive Product Description,
  Cipher Data Products, Inc.,
  Bulletin Number 01-311-0284-IK (1/4-inch tape drive)   2249997-0001
MTO I Tape Controller Technical Manual,
  Emulex Corporation, part number MT0151001
  (formatter for the 1/4-inch tape drive)                2243182-0001
XT-1000 Service Manual, 51/4-inch Fixed Disk Drive,
  Maxtor Corporation, part number 20005
  (5 1/4-inch Winchester disk drive, 112 megabytes)      2249999-0001
ACB-5500 Winchester Disk Controller User's Manual,
  Adaptec, Inc.,
 (formatter for the 51/4-inch Winchester disk drive)     2249933-0001

Optional Equipment Hardware Publications

Explorer NuBus Ethernet R Controller General Description 2243161-0001  Orig  Jun 85
Model 855 Printer Operator's Manual                      2225911-0001
Model 855 Printer Technical Reference Manual             2232822-0001
Model 855/856 Printer Maintenance Manual                 2225914-0001

Explorer and NuBus are trademarks of Texas Instruments Incorporated.
Ethernet is a registered trademark of Xerox Corporation.

THE EXPLORERTM SYSTEM SOFTWARE MANUALS (September 1989)
 

Mastering the Explorer Environment

Introduction to the Explorer System                      2243190-0001  Chg 2 Dec 87
Explorer Zmacs Editor Tutorial                           2243191-0001  Rev A Jun 87
Explorer Networking Reference                            2243206-0001  Rev B Jun 87
Explorer Diagnostics                                     2533554-0001  Rev E Jun 87
Explorer System Software Installation Guide              2243205-0001  Rev E Dec 87
Explorer System Software Release Information Rel 3.0                   Orig  Jun 87
                                             Rel 3.1                   Rev A Oct 87
                                             Rel 3.2                   Rev B Dec 87
microExplorer TM User's Guide                            2552701-0001

Programming With the Explorer

Explorer Programming Concepts                            2549830-0001  Chg 1 Dec 87
Explorer Lisp Reference                                  2243201-0001  Rev C Sep 89
Explorer Input/Output Reference                          2549281-0001  Rev A Jun 87
Explorer Zmacs Editor Reference                          2243192-0001  Rev A Jun 87
Explorer Tools and Utilities                             2549831-0001  Chg 2 Dec 87
Explorer Window System Reference                         2243200-0001
microExplorer Development Software User's Guide          2552702-0001
Explorer System Software Release Information Rel 3.0     2549844-0001  Orig  Jun 87
                                             Rel 3.1                   Rev A Oct 87
                                             Rel 3.2                   Rev B Dec 87
Explorer Software Release Information and Installation
  Guide for microexplorer Delivery Software              2555022-0001
SLE X Window System TM Programmer's Reference            2553272-0001  Orig  Sep 89
SLE Common Lisp Object System                            2559593-0001  Orig  Sep 89

Explorer Options

Explorer Natural Language Menu System User's Guide       2243202-0001
Explorer Relational Table Management System User's Guide 2243203-0001
Explorer Grasper User's Guide                            2243135-0001
Explorer TI Prolog User's Guide                          2537248-0001  Orig  Nov 86
Programming in Prolog, by Clocksin and Mellish           2249985-0001
Explorer Color Graphics User's Guide                     2537157-0001
Explorer TCP/IP User's Guide                             2537150-0001  Rev A Jun 87
Explorer LX TM User's Guide                              2537225-0001
Explorer LX System Installation                          2537227-0001
Explorer NFS TM User's Guide                             2546890-0001  Rev A Jul 87
Explorer DECnet TM User's Guide                          2537223-0001  Orig  Jul 87
Explorer Software Release Information and
  Installation Guide for microExplorer Source Option     2555023-0001
Explorer Software Release Information and Installation
  Guide for microExplorer Development Software           2555024-0001
Explorer SNA II                                          2537281-0001
Personal Consultant TM Plus Explorer                     2537259-0001

System Software Internals

Explorer System Software Design Notes                    2243208-0001  Rev A Jun 87

Explorer, Explorer LX, microExplorer, and Personal Consultant are trademarks of Texas Instruments Incorporated.
X Window System is a trademark of the Massachusetts Institute of Technology.
NFS is a trademark of Sun Microsystems, Inc.
DECnet is a trademark of Digital Equipment Corporation.

THE EXPLORER SYSTEM HARDWARE MANUALS(September 1989)

System Level Publications

Explorer 7-Slot System Installation                      2243140-0001
Explorer System Field Maintenance                        2243141-0001
Explorer System Field Maintenance Documentation Kit      2243222-0001
Explorer System Field Maintenance Supplement             2537183-0001
Explorer System Field Maintenance Supplement
  Documentation Kit                                      2549278-0001
NuBus TM Systems Explorer/Explorer LX Field
  Maintenance Handbook                                   2553315-0001
Explorer NuBus System Architecture
  General Description                                    2537171-0001

System Enclosure Equipment Publications

Explorer 7-Slot System Enclosure General Description     2243143-0001
Explorer Memory General Description (8-megabytes)        2533592-0001
Explorer 32-Megabyte Memory General Description          2537185-0001
Explorer Processor General Description                   2243144-0001
68020-Based Processor General Description                2537240-0001
Explorer II TM Processor and Auxiliary Processor
  Options General Description                            2537187-0001  Orig  Jun 87
Explorer II Plus TM Processor General Description        2553312-0001
Explorer System Interface General Description            2243145-0001
Explorer Color System Interface Board
  General Description                                    2537189-0001  Orig  Dec 87
Explorer NuBus Peripheral Interface
  General Description (NUPI board)                       2243146-0001
Computer Enclosure Installation and Operation            2557942-0001

Display Terminal Publications

Explorer Display Unit General Description                2243151-0001
CRT Data Display Service Manual, Panasonic
  code number FTD85055057C                               2537139-0001
Explorer Color Console General Description               2537195-0001  Orig  Dec 87
TRINITRON R Graphic Display Monitor GDM-1603
  Service Manual, Sony R part number 0-558-986-01        2551107-0001
Model 924 Video Display Terminal User's Guide            2544365-0001

143-Megabyte Disk/Tape Enclosure Publications

Explorer Mass Storage Enclosure General Description      2243148-0001  Rev A Oct 87
Explorer Winchester Disk Formatter (Adaptec)
  Supplement to Explorer Mass Storage Enclosure
  General Description                                    2243149-0001
Explorer Winchester Disk Drive (Maxtor)
  Supplement to Explorer Mass Storage Enclosure
  General Description                                    2243150-0001
Explorer Cartridge Tape Drive (Cipher)
  Supplement to Explorer Mass Storage Enclosure
  General Description                                    2243166-0001
Explorer Cable Interconnect Board (2236120-0001)
  Supplement to Explorer Mass Storage Enclosure
  General Description                                    2243177-0001

Explorer II, Explorer II Plus, and NuBus are trademarks of Texas Instruments Incorporated.
TRINITRON and Sony are registered trademarks of Sony Corporation.

143-Megabyte Disk Drive Vendor Publications

XT-1000 Service Manual, 5 1/4-inch Fixed Disk
  Drive, Maxtor Corporation, part number 20005
  (5 1/4-inch Winchester disk drive, 112 megabytes)      2249999-0001
ACB-5500 Winchester Disk Controller User's
  Manual, Adaptec, Inc., (formatter for the
  5 1/4-inch Winchester disk drive)                      2249933-0001
 

1/4-Inch Tape Drive Vendor Publications

Series 540 Cartridge Tape Drive Product Description,
  Cipher Data Products, Inc., Bulletin Number
  01-311-0284-IK (1/4-inch tape drive)                   2249997-0001
MT01 Tape Controller Technical Manual,
  Emulex Corporation, part number MT0151001
  (formatter for the 1/4-inch tape drive)                2243182-0001
Viper TM Half-High Intelligent 4 1/4-Inch Streaming
  Cartridge Tape Drive SCSI Models 2060S and 2125S,
  Archive Corporation, part number 21136-001             2551106-0001

182-Megabyte Disk/Tape Enclosure MSU II Publications

Mass Storage Unit (MSU II) General Description           2537197-0001

182-Megabyte Disk Drive Vendor Publications

Control Data& WREN TM III Disk Drive OEM Manual,
  part number 77738216, Magnetic Peripherals, Inc.,
  a Control Data Company                                 2546867-0001

515-Megabyte Mass Storage Subsystem Publications

SMD/515-Megabyte Mass Storage Subsystem General
  Description (includes SMD/SCSI con,-roller
  and 515-megabyte disk drive enclosure)                 2537244-0001

515-Megabyte Disk Drive Vendor Publications

515-Megabyte Disk Drive Documentation Master Kit
  (Volumes 1, 2, and 3), Control Data Corporation        2246129-0002
Volume 1, General Description, Operation, Installation
  and Checkout, and Part Data 2246125-0004
Volume 2, Theory, General Maintenance, Trouble
  Analysis, Electrical Checks, and Repair Information    2246125-0005
Volume 3, Diagrams                                       2246125-0006

1/2-Inch Tape Drive MT Publications

3201 1/2-Inch Tape Drive General Description             2537246-0001

380-Megabyte Disk/Tape Enclosure MSU IIA Publications

Mass Storage Unit (MSU IIA)
  Installation and Operation Kit                         2557935-0001

Viper is a trademark of Archive Corporation.
Control Data is a registered trademark and WREN is a trademark of Control Data Corporation.

380-Megabyte Disk Drive Vendor Publications

XT-4000S Product Specification and OEM Manual,
  Maxtor Corporation, part number 1014995
  (DB380 Disk Drive)                                     2554653-0001

1/2-Inch Tape Drive Vendor Publications

Cipher CacheTapelt Documentation Manual Kit
  (Volumes 1 and 2 With SCSI Addendum and,
  Logic Diagram), Cipher Data products                   2246130-0001
1/2-Inch Tape Drive Operation and Maintenance
  (Volume 1), Cipher Data Products                       2246126-0001
1/2-Inch Tape Drive Theory of Operation
  (Volume 2), Cipher Data Products                       2246126-0002
SCSI Addendum With Logic Diagram,
  Cipher Data Products                                   2246126-0003

Printer Publications

Model 810 Printer Installation and Operation Manual      2311356-9701
Omni 800 TM Electronic Data Terminals Maintenance
 Manual for Model 810 Printers                           0994386-9701
Model 850 RO Printer User's Manual                       2219890-0001
Model 850 RO Printer Maintenance Manual                  2219896-0001
Model 850 XL Printer User's Manual                       2243250-0001
Model 850 XL Printer Quick Reference Guide I I           2243249-0001
Model 855 Printer Operator's Manual                      2225911-0001
Model 855 Printer Technical Reference Manual             2232822-0001
Model 855 Printer Maintenance Manual                     2225914-0001
Model 860 XL Printer User's Manual                       2239401-0001
Model 860 XL Printer Maintenance Manual                  2239427-0001
Model 860 XI Printer Quick Reference Guide               2239402-0001
Model 860/859 Printer Technical Reference Manual         2239407-0001
Model 865 Printer Operator's Manual                      2239405-0001
Model 865 Printer Maintenance Manual                     2239428-0001
Model 880 Printer User's Manual                          2222627-0001
Model 880 Printer Maintenance Manual                     2222628-0001
OmniLaser TM 2015 Page Printer Operator's Manual         2539178-0001
OmniLaser 2015 Page Printer Technical Reference          2539179-0001
OmniLaser 2015 Page Printer Maintenance Manual           2539180-0001
OmniLaser 2108 Page Printer Operator's Manual            2546348-0001
OmniLaser 2108 Page Printer Technical Reference          2546349-0001
OmniLaser 2108 Page Printer Maintenance Manual           2546350-0001
OmniLaser 2115 Page Printer Operator's Manual            2546344-0001
OmniLaser 2115 Page Printer Technical Reference          2546345-0001
OmniLaser 2115 Page Printer Maintenance Manual           2546346-0001

Communications Publications

990 Family Communications Systems Field Reference        2276579-9701
E1990 Ethernet R Interface Installation and Operation    2234392-9701
Explorer NuBus Ethernet Controller General Description   2243161-0001
Communications Carrier Board and Options
  General Description                                    2537242-0001

CacheTape is a registered trademark of Cipher Data Products, Inc.
Omni 800 and OmniLaser are trademarks of Texas Instruments Incorporated.
Ethernet is a registered trademark of Xerox Corporation. --------------000105050801000208000208-- From nyef@softhome.net Wed Mar 10 16:55:02 2004 From: nyef@softhome.net (Nyef) Date: Wed Mar 10 16:55:02 2004 Subject: [LMH]Memory board docs? In-Reply-To: <404FC37B.1030003@objs.com> References: <20040311003451.GA10084@miyu.paradiesanalytics.com> <404FC37B.1030003@objs.com> Message-ID: <20040311015143.GA10206@miyu.paradiesanalytics.com> On Wed, Mar 10, 2004 at 08:40:11PM -0500, ford@objs.com wrote: > I have that manual somewhere (I attached the list of the manuals I > have). I'll dig it up and scan the TOC. > > Steve > > Nyef wrote: > > >Hello all. > > > >Does anyone have a copy of the memory board manual? The name and part > >number is: > > > >Explorer Memory General Description (8-megabytes) 2533592-0001 Could I trouble you to scan the pages describing the control space address map and the various registers and latches therein, and anything that describes how the parity checking hardware works or is tested? Thanks. --Alastair From aek@spies.com Thu Mar 11 12:47:01 2004 From: aek@spies.com (Al Kossow) Date: Thu Mar 11 12:47:01 2004 Subject: [LMH]8m mem manual Message-ID: <200403112149.i2BLnF21010709@spies.com> www.bitsavers.org/pdf/ti/explorer/2533592-0001_8M_mem_Aug85.pdf From nyef@softhome.net Thu Mar 11 17:37:00 2004 From: nyef@softhome.net (Nyef) Date: Thu Mar 11 17:37:00 2004 Subject: [LMH] New nevermore version. Message-ID: <20040312023326.GA12175@miyu.paradiesanalytics.com> Hello all. Okay, I just pushed a new version of nevermore to http://www.dridus.com/~nyef/lispm/nevermore/ The big feature this time is that it's faster. Unfortunately, I forgot to thank everyone who helped to make it faster in the README. I'll put that on my list to fix for next version. Sorry guys! I expect to be working on fixing the memory board emulation to pass the self-test over the next couple of days. Maybe then we can see some new screenshots... --Alastair From nyef@softhome.net Sat Mar 20 17:40:02 2004 From: nyef@softhome.net (Nyef) Date: Sat Mar 20 17:40:02 2004 Subject: [LMH] Nevermore status and ROM hunting Message-ID: <20040321023521.GA1265@miyu.paradiesanalytics.com> Hello all. I've been messing with Nevermore again. Some of you may have noticed that the collection of framebuffer images at http://www.dridus.com/~nyef/lispm/nevermore/ now consists of 8 bitmap files, including some showing progress getting more tests to pass the SIB extended diagnostics (my current task as far as Nevermore is concerned). I'm now running Nevermore from SBCL, which now works fairly well (certainly better than the last released version did). To help tide you guys over until the next release, I put my disassembly and symbol files for the boot microcode in the same directory as all the screenshots. The files are prom_disassem and prom_symbols. Feel free to try and figure out the great swaths of uncommented code in there (and feel free to try and fix the Nevermore disassembler to work with the contents of the *prom-memory-a* and *prom-memory-m* arrays instead of requiring a weird 'prom-combined' file, and an actual .el file for working with the disassembly could be neat, as would fixing the disassembler to work on the .mcr files in the ubin/ directory of the explorer src tarball or on a microload partition image... There are a lot of possibilities here for an interested person). The other thing is, does anyone have or could anyone make an image of the Explorer I CPU config ROM? If nobody wants to remove the ROM from their working system, would they (you) be averse to running a short program to read the ROM into a Lisp array and then figuring out how to send that array data to me? Thanks in advance to those at least considering it. (And, since we're on the subject of ROMs, can anyone get images of the ROMs for an Explorer II CPU or MicroExplorer board? Once Nevermore is basically working we might want to try emulating the later systems as well...) Anyway, that's all for now. I'm gonna go back to trying to get a few more of those SIB tests to pass... --Alastair From aek@spies.com Sun Mar 21 06:17:01 2004 From: aek@spies.com (Al Kossow) Date: Sun Mar 21 06:17:01 2004 Subject: [LMH]Re: Nevermore status and ROM hunting Message-ID: <200403211520.i2LFK8xH002556@spies.com> The config rom on the cpu is a surface mount part, and would be difficult to remove. It would be better if someone with a working system could dump it through software. I should be able to get a microexplorer prom dump later today. d From aek@spies.com Sun Mar 21 09:41:01 2004 From: aek@spies.com (Al Kossow) Date: Sun Mar 21 09:41:01 2004 Subject: [LMH]microexplorer config rom Message-ID: <200403211844.i2LIiVPU005307@spies.com> no joy. The part is surface mount as well if someone has a system handy, it would be fastest to just dump the slot config space with macsbug unfortunately, all of my nubus macs are in storage right now From asholz@topinform.de Sun Mar 21 22:29:01 2004 From: asholz@topinform.de (Andreas Holz) Date: Sun Mar 21 22:29:01 2004 Subject: [LMH]Explorer/Microexplorer config ROM dump In-Reply-To: <20040321210101.5362.qmail@kappa.unlambda.com> References: <20040321210101.5362.qmail@kappa.unlambda.com> Message-ID: <405E95A9.4010508@topinform.com> lispm-hackers-request@lists.unlambda.com wrote: >Send LispM-Hackers mailing list submissions to > lispm-hackers@lists.unlambda.com > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.unlambda.com/mailman/listinfo/lispm-hackers >or, via email, send a message with subject or body 'help' to > lispm-hackers-request@lists.unlambda.com > >You can reach the person managing the list at > lispm-hackers-admin@lists.unlambda.com > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of LispM-Hackers digest..." > > >Today's Topics: > > 1. Nevermore status and ROM hunting (Nyef) > 2. Re: Nevermore status and ROM hunting (Al Kossow) > 3. microexplorer config rom (Al Kossow) > >--__--__-- > >Message: 1 >Date: Sat, 20 Mar 2004 21:35:22 -0500 >From: Nyef >To: lispm-hackers@lists.unlambda.com >Subject: [LMH] Nevermore status and ROM hunting > >Hello all. > >I've been messing with Nevermore again. Some of you may have >noticed that the collection of framebuffer images at >http://www.dridus.com/~nyef/lispm/nevermore/ now consists of >8 bitmap files, including some showing progress getting more >tests to pass the SIB extended diagnostics (my current task >as far as Nevermore is concerned). > >I'm now running Nevermore from SBCL, which now works fairly >well (certainly better than the last released version did). > >To help tide you guys over until the next release, I put my >disassembly and symbol files for the boot microcode in the >same directory as all the screenshots. The files are >prom_disassem and prom_symbols. Feel free to try and figure >out the great swaths of uncommented code in there (and feel >free to try and fix the Nevermore disassembler to work with >the contents of the *prom-memory-a* and *prom-memory-m* >arrays instead of requiring a weird 'prom-combined' file, >and an actual .el file for working with the disassembly >could be neat, as would fixing the disassembler to work on >the .mcr files in the ubin/ directory of the explorer src >tarball or on a microload partition image... There are a >lot of possibilities here for an interested person). > >The other thing is, does anyone have or could anyone make an >image of the Explorer I CPU config ROM? If nobody wants to >remove the ROM from their working system, would they (you) >be averse to running a short program to read the ROM into a >Lisp array and then figuring out how to send that array data >to me? Thanks in advance to those at least considering it. > >(And, since we're on the subject of ROMs, can anyone get >images of the ROMs for an Explorer II CPU or MicroExplorer >board? Once Nevermore is basically working we might want to >try emulating the later systems as well...) > >Anyway, that's all for now. I'm gonna go back to trying to >get a few more of those SIB tests to pass... > >--Alastair > >--__--__-- > >Message: 2 >Date: Sun, 21 Mar 2004 07:20:08 -0800 >From: Al Kossow >To: lispm-hackers@lists.unlambda.com >Subject: [LMH]Re: Nevermore status and ROM hunting > > >The config rom on the cpu is a surface mount part, and would be difficult >to remove. It would be better if someone with a working system could dump >it through software. > >I should be able to get a microexplorer prom dump later today. >d > >--__--__-- > >Message: 3 >Date: Sun, 21 Mar 2004 10:44:31 -0800 >From: Al Kossow >To: lispm-hackers@lists.unlambda.com >Subject: [LMH]microexplorer config rom > > >no joy. The part is surface mount as well > >if someone has a system handy, it would be fastest to just >dump the slot config space with macsbug > >unfortunately, all of my nubus macs are in storage right now > > >--__--__-- > > > >http://lists.unlambda.com/mailman/listinfo/lispm-hackers > > > >End of LispM-Hackers Digest > > > > Hello Marc, somethind to do for you! - Andreas From asholz@topinform.de Mon Mar 22 23:33:00 2004 From: asholz@topinform.de (Andreas Holz) Date: Mon Mar 22 23:33:00 2004 Subject: [LMH]Re: LispM-Hackers digest, Vol 1 #257 - 1 msg In-Reply-To: <20040322210101.9839.qmail@kappa.unlambda.com> References: <20040322210101.9839.qmail@kappa.unlambda.com> Message-ID: <405FF624.70106@topinform.com> Hi, sorry from the cryptic Email! I forwarded the Mail to Marc, who has an Exp1 and MicroExplorer running. - Andreas >Hello Marc, > >somethind to do for you! > >- Andreas > > >--__--__-- > > > >http://lists.unlambda.com/mailman/listinfo/lispm-hackers > > > >End of LispM-Hackers Digest > > > > From nyef@softhome.net Wed Mar 31 03:56:01 2004 From: nyef@softhome.net (Nyef) Date: Wed Mar 31 03:56:01 2004 Subject: [LMH] Another documentation request Message-ID: <20040331125053.GA17357@miyu.paradiesanalytics.com> Subject: [LMH] Another documentation request Hello all. Does anyone have documentation on the Explorer keyboards? The SIB documentation doesn't seem to list scancodes or startup behavior and such, the PRIM doesn't seem to want to run with no keyboard, and the comments in KERNEL;KEYBOARD-CHARS are somewhat confusing and wouldn't paint the full picture anyway... Thanks in advance. --Alastair Bridgewater From ford@objs.com Wed Mar 31 04:16:02 2004 From: ford@objs.com (ford@objs.com) Date: Wed Mar 31 04:16:02 2004 Subject: [LMH] Another documentation request In-Reply-To: <20040331125053.GA17357@miyu.paradiesanalytics.com> References: <20040331125053.GA17357@miyu.paradiesanalytics.com> Message-ID: <406AC3FC.5010804@objs.com> Did you check the Display manual? I think there's keyboard info in there. Steve Nyef wrote: >Subject: [LMH] Another documentation request > >Hello all. > >Does anyone have documentation on the Explorer >keyboards? The SIB documentation doesn't seem to >list scancodes or startup behavior and such, the >PRIM doesn't seem to want to run with no keyboard, >and the comments in KERNEL;KEYBOARD-CHARS are >somewhat confusing and wouldn't paint the full >picture anyway... > >Thanks in advance. > >--Alastair Bridgewater > >http://lists.unlambda.com/mailman/listinfo/lispm-hackers > > > From nyef@softhome.net Wed Mar 31 04:52:01 2004 From: nyef@softhome.net (Nyef) Date: Wed Mar 31 04:52:01 2004 Subject: [LMH] Another documentation request In-Reply-To: <406AC3FC.5010804@objs.com> References: <20040331125053.GA17357@miyu.paradiesanalytics.com> <406AC3FC.5010804@objs.com> Message-ID: <20040331134631.GA17442@miyu.paradiesanalytics.com> On Wed, Mar 31, 2004 at 08:13:32AM -0500, ford@objs.com wrote: > Did you check the Display manual? I think there's keyboard info in there. That's certainly a good start, thank you. That should get me quite a bit further. It doesn't seem to mention commands sent to the keyboard or keyboard powerup/reset behavior though. Is that in another manual somewhere? -- Alastair Bridgewater From ford@objs.com Wed Mar 31 08:35:01 2004 From: ford@objs.com (ford@objs.com) Date: Wed Mar 31 08:35:01 2004 Subject: [LMH] Another documentation request In-Reply-To: <20040331134631.GA17442@miyu.paradiesanalytics.com> References: <20040331125053.GA17357@miyu.paradiesanalytics.com> <406AC3FC.5010804@objs.com> <20040331134631.GA17442@miyu.paradiesanalytics.com> Message-ID: <406B00B8.3040309@objs.com> This is a multi-part message in MIME format. --------------080407050701080109010701 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nyef wrote: >On Wed, Mar 31, 2004 at 08:13:32AM -0500, ford@objs.com wrote: > > >>Did you check the Display manual? I think there's keyboard info in there. >> >> > >That's certainly a good start, thank you. That should get me >quite a bit further. > >It doesn't seem to mention commands sent to the keyboard or >keyboard powerup/reset behavior though. Is that in another >manual somewhere? > You might check the Windows System and Field Maintenance manuals. Have you searched through the source code? Steve > >-- Alastair Bridgewater > > > --------------080407050701080109010701 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Nyef wrote:

On Wed, Mar 31, 2004 at 08:13:32AM -0500, ford@objs.com wrote:
  
Did you check the Display manual?  I think there's keyboard info in there.
    

That's certainly a good start, thank you. That should get me
quite a bit further.

It doesn't seem to mention commands sent to the keyboard or
keyboard powerup/reset behavior though. Is that in another
manual somewhere?
You might check the Windows System and Field Maintenance manuals.
Have you searched through the source code?

Steve
 

-- Alastair Bridgewater
--------------080407050701080109010701--