From hans@huebner.org Sun May 2 05:25:02 2004 From: hans@huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sun May 2 04:25:02 2004 Subject: [LMH]microExplorer keyboard overlay Message-ID: <20040502141852.V92217@exklave.huebner.org> Hi, does anyone have a scanned version of the microExplorer keyboard overlay or a complete listing of the mappings? I have found most of the keys, but some are still missing (notably TERM, but propably others, too). The TI microExplorer documentation mentions the keyboard overlay, but it does not reproduce it and has no listing, as it seems. Thanks in advance, Hans From cshapiro@panix.com Sun May 2 15:05:02 2004 From: cshapiro@panix.com (Carl Shapiro) Date: Sun May 2 14:05:02 2004 Subject: [LMH]microExplorer keyboard overlay In-Reply-To: <20040502141852.V92217@exklave.huebner.org> (message from =?ISO-8859-1?Q?Hans_H=FCbner?= on Sun, 2 May 2004 14:24:11 +0200 (CEST)) References: <20040502141852.V92217@exklave.huebner.org> Message-ID: <200405022204.i42M4FL01444@panix3.panix.com> From: =?ISO-8859-1?Q?Hans_H=FCbner?= Sender: lispm-hackers-admin@lists.unlambda.com The TI microExplorer documentation mentions the keyboard overlay, but it does not reproduce it and has no listing, as it seems. I don't know what documentation you are working from, but I learned all of the key mappings for the microExplorer through its manual. You should be able to find a picture of the keyboard with the magic keys labeled. If you haven't done so already, you should experiment with the function keys, as the keys you are probably interested in are located there. Unfortunately, all of my Explorer manuals are 3000 miles away from me, and there is little chance I will be able to refer to them on your behalf any time soon. Which manual are you looking at? Are you working from a scanned document, or a hard copy original? From hans@huebner.org Mon May 3 00:13:00 2004 From: hans@huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sun May 2 23:13:00 2004 Subject: [LMH]microExplorer keyboard overlay In-Reply-To: <200405022204.i42M4FL01444@panix3.panix.com> References: <20040502141852.V92217@exklave.huebner.org> <200405022204.i42M4FL01444@panix3.panix.com> Message-ID: <20040503090350.J55958@exklave.huebner.org> On Sun, 2 May 2004, Carl Shapiro wrote: > Which manual are you looking at? Are you working from a scanned > document, or a hard copy original? I'm looking at the scanned copy of the "Development Software User's Guide" which I found on bitsavers.org. It has a description of many keystroke equivalents, but I have not found a complete reproduction of the full keyboard layout. I do get along, but if anyone has the full list, I'd be thankful. -Hans From brad@heeltoe.com Mon May 10 15:59:00 2004 From: brad@heeltoe.com (Brad Parker) Date: Mon May 10 14:59:00 2004 Subject: [LMH]kick me Message-ID: <200405102258.i4AMw7707622@mwave.heeltoe.com> Hi, I'm probably going to step into it deep, but since this has become a serious addiction, I'll start with, "Hi, My name is Brad, and I have two lisp machines..." I'm on a journey through the original Symbolics patent, which expires this year, on my birthday :-). I've been OCR'ing all the code in it, which includes code to produces the microcode, and perhaps, the microcode simulator. I've been running some of it, and making some progress. My lawyer friend says that I can get away with distributing the text of the entire patent, and a script which edits the patent text into usable lisp files, and not violate any copyright issues. We'll see. I don't expect to do anything which this, except have fun. In my journey I've run into Tom Knight's thesis and several papers. And of course, the CONS and CADR machines. My question is this: how close is the Explorer to the CADR? Was there a lisp based microcode simulator for the CADR? How close is the "machine code" of a CADR, an Explorer and a 36xx? sorry if this is wildly divergent... feel free to yell if this is too off topic. -brad From james@unlambda.com Mon May 10 17:24:01 2004 From: james@unlambda.com (James A. Crippen) Date: Mon May 10 16:24:01 2004 Subject: [LMH]kick me In-Reply-To: <200405102258.i4AMw7707622@mwave.heeltoe.com> References: <200405102258.i4AMw7707622@mwave.heeltoe.com> Message-ID: Brad Parker writes: > I'm probably going to step into it deep, but since this has become a > serious addiction, I'll start with, "Hi, My name is Brad, and I have two > lisp machines..." Hi Brad! Try the coffee. It's not too bad, but don't spill it on your keyboard. > I'm on a journey through the original Symbolics patent, which expires > this year, on my birthday :-). Really? Honest? Schw33t! > I've been OCR'ing all the code in it, which includes code to > produces the microcode, and perhaps, the microcode simulator. I've > been running some of it, and making some progress. My lawyer friend > says that I can get away with distributing the text of the entire > patent, and a script which edits the patent text into usable lisp > files, and not violate any copyright issues. We'll see. Are you really sure about that? I think that the copyright still applies outside of the context of the patent, thus redistribution of the patent per se is legal, but the files which are contained within it are also copyrighted outside of the patent as well. Hmm. Interesting legal problem. Glad I'm not a lawyer. > I don't expect to do anything which this, except have fun. Well, yeah. Us too. Of course, I have an ulterior motive as well. Someday I will take over the world with my evil LispM-powered giant robot hordes. But that's later. > My question is this: how close is the Explorer to the CADR? Closer than the Symbolics 3600. The Exploder is a 32 bit macrocode engine, as is the CADR. Many opcodes are similar. > Was there a lisp based microcode simulator for the CADR? There was one implemented in MACLISP on ITS. It was used to design the microcode and bootstrap the original CADR and maybe for some other purposes. It never lasted very long, being supplanted quickly by the Real Thing. > How close is the "machine code" of a CADR, an Explorer and a 36xx? Like I said above, the 36xx macrocode is quite different from teh CADR/Exploder. It's 36 bit, whereas the CADR is 32 bit. The Ivory is 40 bit. Note that there's a difference between two types of 'machine code'. The macrocode is what you get if you DISASSEMBLE some random compiled function. The microcode you can't see, it's what implements the macrocode engine. The macrocode machine doesn't really exist, it's like a VM that is implemented in the microcode which is the real hardware underneath. Thus, there are (currently) two simulators/emulators of the Exploder series. The first is Exploiter, which is a macrocode emulator of the Exploder II. The second is Nevermore, which is a microcode emulator of the Exploder I. Very different, the two of them. There are *two* {sim,em}ulators for the Symbolics Ivory. The first, which everyone hears about all the time (relatively speaking) is OpenGenera, an emulator of the Ivory macrocode on the Alpha running DEC Unix. The second is only heard of in rumors, but is another macrocode emulator running on the Mac G5. Both of these are presumably commercial, and I know that the former costs about five kilodollars. > sorry if this is wildly divergent... feel free to yell if this is too > off topic. You're so on topic that it would make Kibo's head explode if he only knew. So don't tell him. -- 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 brad@heeltoe.com Mon May 10 19:38:00 2004 From: brad@heeltoe.com (Brad Parker) Date: Mon May 10 18:38:00 2004 Subject: [LMH]kick me In-Reply-To: Your message of "10 May 2004 16:23:22 -0800." Message-ID: <200405110237.i4B2b0P09461@mwave.heeltoe.com> James A. Crippen wrote: > >> I've been OCR'ing all the code in it, which includes code to >> produces the microcode, and perhaps, the microcode simulator. I've >> been running some of it, and making some progress. My lawyer friend >> says that I can get away with distributing the text of the entire >> patent, and a script which edits the patent text into usable lisp >> files, and not violate any copyright issues. We'll see. > >Are you really sure about that? I think that the copyright still >applies outside of the context of the patent, thus redistribution of >the patent per se is legal, but the files which are contained within >it are also copyrighted outside of the patent as well. sure I'm not :-) I'm told that, as you say, redistribution of the patent is legal. And, distribution of a script which operates on the patent files is legal. so, as long as the script is run by someone else (and they don't redistribute the files), I'm ok. does that sound better/more plausible? I respect copyrights and don't wish to violate them. But I also like the notion of "hobbiest/academic use", so I'm trying to strike a balance. -brad ps: > >Of course, I have an ulterior motive as well. Someday I will take over >the world with my evil LispM-powered giant robot hordes. But that's >later. well, sure, of course. me too. :-) From asholz@topinform.de Wed May 12 00:07:01 2004 From: asholz@topinform.de (Andreas Holz) Date: Tue May 11 23:07:01 2004 Subject: [LMH]Symbolics patent Message-ID: <40A1CCDA.9010707@topinform.com> Hi Brad, when the day is you birthday, please let me know! - Andreas From nyef@sc.am Thu May 20 09:48:01 2004 From: nyef@sc.am (nyef@sc.am) Date: Thu, 20 May 2004 03:48:01 -0500 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: <200405201616.i4KGGRN10765@mwave.heeltoe.com> References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> Message-ID: <20040520084759.GA24272@sc.am> On Thu, May 20, 2004 at 12:16:27PM -0400, Brad Parker wrote: > > Hi, Hello. > Some dumb questions (which I think I sent before but seem to have gone > into the bit bucket) > > - is there a list of names which describes an Explorer I,II & cpu names, > i.e. raven, hummingbird, etc??? Not an explicit list, no. Of the ones you explicitly asked about, Raven is the processor from the Explorer I and Hummingbird is the processor used in the Explorer II and the microExplorer. > - is an Explorer I essentially a CADR? Will an E1 run CADR microcode? > (I thought I read that it would/could) No, but I hear tell that it is essentially an LMI Lambda (microcode compatible, at least). > - I was fooling around with exploiter and got it past the previous disk > problem but crashed in to needing support for lexical closures. I > thought "I'll just look at the microcode". But, ahem, no microcode > source. The SSDN2 is good but no substitute for definative microcode. If this is at any point past the scheduler initialization you should realize that the stack-group switch doesn't work properly, especially in regards to the binding stack (specpdl). > How come there is no source to the E1 or E2 microcode? Can that nice person > from TI on the list dig it up, even older versions? The nice person from TI with the microcode listing has, if memory serves, the VM1 (pre-release-3) sources in hardcopy only. > Seems obvious, so there must be good historical reasons - please pass > the clues :-) Yeah, the reason we don't have the microcode, the microcode assembler, or the genasys utility is that nobody could find a copy. Gone. All gone. > -brad --Alastair From pf@ti.com Thu May 20 19:52:40 2004 From: pf@ti.com (Paul Fuqua) Date: Thu, 20 May 2004 13:52:40 -0500 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: Msg of May 20, 2004 03:48:01 (-0500) from nyef@sc.am References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> <20040520084759.GA24272@sc.am> Message-ID: <16556.65144.499575.362611@glazed04.dal.design.ti.com> Date: Thu, 20 May 2004 03:48:01 -0500 From: nyef@sc.am Not an explicit list, no. Of the ones you explicitly asked about, Raven is the processor from the Explorer I and Hummingbird is the processor used in the Explorer II and the microExplorer. Projects were being named after birds at that time. Raven was the original Explorer codename. Somewhere along the line it was semi-officially renamed Chaparral, that being a more "Southwestern" bird; some folks have little Chaparral pins from those days. Then marketing got it and named it Explorer. Microcoders are stubborn people, so files and features were named Raven (ravsym, #+raven) to the end. Hummingbird was the Explorer 2 processor because it was small and moved very fast (relatively speaking). It was also part of the DARPA Compact Lisp Machine project so sometimes there are references to that. No, but I hear tell that it is essentially an LMI Lambda (microcode compatible, at least). My understanding was that the original LMI Lambdas were indeed CADRs. The later Lambda/E model was a rebadged Explorer. I think we had LMI microcode running on Explorers -- certainly LMI did -- but I don't know what degree of porting was required. Yeah, the reason we don't have the microcode, the microcode assembler, or the genasys utility is that nobody could find a copy. Gone. All gone. Yep, nobody had the foresight to snapshot it before the division where the machine holding the master source lived was sold off. There are persistent rumors that somebody has it on a brick or tape in a box somewhere, but they haven't panned out yet. What we do have are some paper copies of VM1 microcode source, and some Explorer 1 microcode development tools, and scattered fragments of other stuff. I thought Genasys was part of the regular system source, but then that just builds the load band, it's not part of the microcode system. I did disassemble enough of the Explorer 1 microcode to answer some questions, but I'm in a delicate position as a TI employee using TI tools to fiddle with TI intellectual property, so it isn't public yet. Paul Fuqua Texas Instruments, Dallas, Texas pf@ti.com From nyef@sc.am Thu May 20 10:49:58 2004 From: nyef@sc.am (nyef@sc.am) Date: Thu, 20 May 2004 04:49:58 -0500 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: <16556.65144.499575.362611@glazed04.dal.design.ti.com> References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> <20040520084759.GA24272@sc.am> <16556.65144.499575.362611@glazed04.dal.design.ti.com> Message-ID: <20040520094958.GA1134@sc.am> On Thu, May 20, 2004 at 01:52:40PM -0500, Paul Fuqua wrote: > > Projects were being named after birds at that time. Raven was the > original Explorer codename. Somewhere along the line it was > semi-officially renamed Chaparral, that being a more "Southwestern" > bird; some folks have little Chaparral pins from those days. Then > marketing got it and named it Explorer. Well, that explains the process-scheduler-for-chaparral thing. I had originally written that off as being a custom hack for some specific person that ended up in the main system, not realizing that it was a bird name, but this makes more sense. > What we do have are some paper copies of VM1 microcode source, and > some Explorer 1 microcode development tools, and scattered fragments > of other stuff. I thought Genasys was part of the regular system > source, but then that just builds the load band, it's not part of the > microcode system. Hey, while I've got your attention, do you know anything about the way that unmapped memory accesses on Raven update the memory maps? One of the VMA tests is checking for it fairly explicitly, but it's not doing it with sufficient coverage for me to figure out what's going on, and the only other reference I've found is a couple figures in SSDN2 which provide descriptions of the various bit positions that need updating (the last-access-mapped bit in the level-1 map and the TM0 and TM1 bits in the level-2 map). As near as I can tell, the TM0 and TM1 bits are always going to be 0 for a mapped access (since it's wordwise), but beyond that I'm kindof at a loss. --Alastair From mark@buttery.org Thu May 20 20:27:58 2004 From: mark@buttery.org (Mark J. Dulcey) Date: Thu, 20 May 2004 15:27:58 -0400 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: <16556.65144.499575.362611@glazed04.dal.design.ti.com> References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> <20040520084759.GA24272@sc.am> <16556.65144.499575.362611@glazed04.dal.design.ti.com> Message-ID: <40AD06BE.3040803@buttery.org> Paul Fuqua wrote: > My understanding was that the original LMI Lambdas were indeed > CADRs. The later Lambda/E model was a rebadged Explorer. I think we > had LMI microcode running on Explorers -- certainly LMI did -- but I > don't know what degree of porting was required. The LMI Lambda evolved from the CADR, but it was not identical. It used a 64-bit microword word (longer than the CADR, which was either 48 or 56 bits; I don't remember), and supported 64K words of microcode instead of the 16K supported by the CADR. The larger microcode store was meant to allow use of the microcompiler (a compiler that turned Lisp into microcode, with a lot of data type restrictions), but I don't think anybody ever did much with that. The other novel feature of the Lambda was the macro IR decode RAM (a 64K-word RAM with an entry for every possible 16-bit instruction pattern!) -- a brute force solution to the problem of decoding the rather baroque LM instruction set. > Yeah, the reason we don't have the microcode, the microcode assembler, > or the genasys utility is that nobody could find a copy. Gone. All gone. It's a pity that nobody seems to have turned up a working Lambda. Those routinely shipped with full system sources, all the way down to the microcode, though some customers didn't bother with the full sources because they didn't have enough disk space for them. From brad@heeltoe.com Thu May 20 20:42:51 2004 From: brad@heeltoe.com (Brad Parker) Date: Thu, 20 May 2004 15:42:51 -0400 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: Message from "Mark J. Dulcey" of "Thu, 20 May 2004 15:27:58 EDT." <40AD06BE.3040803@buttery.org> Message-ID: <200405201942.i4KJgpJ13017@mwave.heeltoe.com> "Mark J. Dulcey" wrote: > >It's a pity that nobody seems to have turned up a working Lambda. Those >routinely shipped with full system sources, all the way down to the >microcode, though some customers didn't bother with the full sources >because they didn't have enough disk space for them. I'm tracking down some alleged "lambda sources" on 9-track. We'll see what's on the tape (if if they can even be read, he said, crossing his fingers). I'll certainly speak up if the tapes yield something. It will be some time in June. I've also found someone who claims to have some T300 platters from a CADR and "wants them read". Al Kossow has the only CADR I know of which might be able to read them - another adventure... I've been searching high and low for "CADR sources". No luck yet. (never thought of looking for a *working* lambda :-) good idea!) -brad From nyef@sc.am Thu May 20 09:48:01 2004 From: nyef@sc.am (nyef@sc.am) Date: Thu, 20 May 2004 03:48:01 -0500 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: <200405201616.i4KGGRN10765@mwave.heeltoe.com> References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> Message-ID: <20040520084759.GA24272@sc.am> On Thu, May 20, 2004 at 12:16:27PM -0400, Brad Parker wrote: > > Hi, Hello. > Some dumb questions (which I think I sent before but seem to have gone > into the bit bucket) > > - is there a list of names which describes an Explorer I,II & cpu names, > i.e. raven, hummingbird, etc??? Not an explicit list, no. Of the ones you explicitly asked about, Raven is the processor from the Explorer I and Hummingbird is the processor used in the Explorer II and the microExplorer. > - is an Explorer I essentially a CADR? Will an E1 run CADR microcode? > (I thought I read that it would/could) No, but I hear tell that it is essentially an LMI Lambda (microcode compatible, at least). > - I was fooling around with exploiter and got it past the previous disk > problem but crashed in to needing support for lexical closures. I > thought "I'll just look at the microcode". But, ahem, no microcode > source. The SSDN2 is good but no substitute for definative microcode. If this is at any point past the scheduler initialization you should realize that the stack-group switch doesn't work properly, especially in regards to the binding stack (specpdl). > How come there is no source to the E1 or E2 microcode? Can that nice person > from TI on the list dig it up, even older versions? The nice person from TI with the microcode listing has, if memory serves, the VM1 (pre-release-3) sources in hardcopy only. > Seems obvious, so there must be good historical reasons - please pass > the clues :-) Yeah, the reason we don't have the microcode, the microcode assembler, or the genasys utility is that nobody could find a copy. Gone. All gone. > -brad --Alastair From pf@ti.com Thu May 20 19:52:40 2004 From: pf@ti.com (Paul Fuqua) Date: Thu, 20 May 2004 13:52:40 -0500 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: Msg of May 20, 2004 03:48:01 (-0500) from nyef@sc.am References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> <20040520084759.GA24272@sc.am> Message-ID: <16556.65144.499575.362611@glazed04.dal.design.ti.com> Date: Thu, 20 May 2004 03:48:01 -0500 From: nyef@sc.am Not an explicit list, no. Of the ones you explicitly asked about, Raven is the processor from the Explorer I and Hummingbird is the processor used in the Explorer II and the microExplorer. Projects were being named after birds at that time. Raven was the original Explorer codename. Somewhere along the line it was semi-officially renamed Chaparral, that being a more "Southwestern" bird; some folks have little Chaparral pins from those days. Then marketing got it and named it Explorer. Microcoders are stubborn people, so files and features were named Raven (ravsym, #+raven) to the end. Hummingbird was the Explorer 2 processor because it was small and moved very fast (relatively speaking). It was also part of the DARPA Compact Lisp Machine project so sometimes there are references to that. No, but I hear tell that it is essentially an LMI Lambda (microcode compatible, at least). My understanding was that the original LMI Lambdas were indeed CADRs. The later Lambda/E model was a rebadged Explorer. I think we had LMI microcode running on Explorers -- certainly LMI did -- but I don't know what degree of porting was required. Yeah, the reason we don't have the microcode, the microcode assembler, or the genasys utility is that nobody could find a copy. Gone. All gone. Yep, nobody had the foresight to snapshot it before the division where the machine holding the master source lived was sold off. There are persistent rumors that somebody has it on a brick or tape in a box somewhere, but they haven't panned out yet. What we do have are some paper copies of VM1 microcode source, and some Explorer 1 microcode development tools, and scattered fragments of other stuff. I thought Genasys was part of the regular system source, but then that just builds the load band, it's not part of the microcode system. I did disassemble enough of the Explorer 1 microcode to answer some questions, but I'm in a delicate position as a TI employee using TI tools to fiddle with TI intellectual property, so it isn't public yet. Paul Fuqua Texas Instruments, Dallas, Texas pf@ti.com From nyef@sc.am Thu May 20 10:49:58 2004 From: nyef@sc.am (nyef@sc.am) Date: Thu, 20 May 2004 04:49:58 -0500 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: <16556.65144.499575.362611@glazed04.dal.design.ti.com> References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> <20040520084759.GA24272@sc.am> <16556.65144.499575.362611@glazed04.dal.design.ti.com> Message-ID: <20040520094958.GA1134@sc.am> On Thu, May 20, 2004 at 01:52:40PM -0500, Paul Fuqua wrote: > > Projects were being named after birds at that time. Raven was the > original Explorer codename. Somewhere along the line it was > semi-officially renamed Chaparral, that being a more "Southwestern" > bird; some folks have little Chaparral pins from those days. Then > marketing got it and named it Explorer. Well, that explains the process-scheduler-for-chaparral thing. I had originally written that off as being a custom hack for some specific person that ended up in the main system, not realizing that it was a bird name, but this makes more sense. > What we do have are some paper copies of VM1 microcode source, and > some Explorer 1 microcode development tools, and scattered fragments > of other stuff. I thought Genasys was part of the regular system > source, but then that just builds the load band, it's not part of the > microcode system. Hey, while I've got your attention, do you know anything about the way that unmapped memory accesses on Raven update the memory maps? One of the VMA tests is checking for it fairly explicitly, but it's not doing it with sufficient coverage for me to figure out what's going on, and the only other reference I've found is a couple figures in SSDN2 which provide descriptions of the various bit positions that need updating (the last-access-mapped bit in the level-1 map and the TM0 and TM1 bits in the level-2 map). As near as I can tell, the TM0 and TM1 bits are always going to be 0 for a mapped access (since it's wordwise), but beyond that I'm kindof at a loss. --Alastair From mark@buttery.org Thu May 20 20:27:58 2004 From: mark@buttery.org (Mark J. Dulcey) Date: Thu, 20 May 2004 15:27:58 -0400 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: <16556.65144.499575.362611@glazed04.dal.design.ti.com> References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> <20040520084759.GA24272@sc.am> <16556.65144.499575.362611@glazed04.dal.design.ti.com> Message-ID: <40AD06BE.3040803@buttery.org> Paul Fuqua wrote: > My understanding was that the original LMI Lambdas were indeed > CADRs. The later Lambda/E model was a rebadged Explorer. I think we > had LMI microcode running on Explorers -- certainly LMI did -- but I > don't know what degree of porting was required. The LMI Lambda evolved from the CADR, but it was not identical. It used a 64-bit microword word (longer than the CADR, which was either 48 or 56 bits; I don't remember), and supported 64K words of microcode instead of the 16K supported by the CADR. The larger microcode store was meant to allow use of the microcompiler (a compiler that turned Lisp into microcode, with a lot of data type restrictions), but I don't think anybody ever did much with that. The other novel feature of the Lambda was the macro IR decode RAM (a 64K-word RAM with an entry for every possible 16-bit instruction pattern!) -- a brute force solution to the problem of decoding the rather baroque LM instruction set. > Yeah, the reason we don't have the microcode, the microcode assembler, > or the genasys utility is that nobody could find a copy. Gone. All gone. It's a pity that nobody seems to have turned up a working Lambda. Those routinely shipped with full system sources, all the way down to the microcode, though some customers didn't bother with the full sources because they didn't have enough disk space for them. From brad@heeltoe.com Thu May 20 20:42:51 2004 From: brad@heeltoe.com (Brad Parker) Date: Thu, 20 May 2004 15:42:51 -0400 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: Message from "Mark J. Dulcey" of "Thu, 20 May 2004 15:27:58 EDT." <40AD06BE.3040803@buttery.org> Message-ID: <200405201942.i4KJgpJ13017@mwave.heeltoe.com> "Mark J. Dulcey" wrote: > >It's a pity that nobody seems to have turned up a working Lambda. Those >routinely shipped with full system sources, all the way down to the >microcode, though some customers didn't bother with the full sources >because they didn't have enough disk space for them. I'm tracking down some alleged "lambda sources" on 9-track. We'll see what's on the tape (if if they can even be read, he said, crossing his fingers). I'll certainly speak up if the tapes yield something. It will be some time in June. I've also found someone who claims to have some T300 platters from a CADR and "wants them read". Al Kossow has the only CADR I know of which might be able to read them - another adventure... I've been searching high and low for "CADR sources". No luck yet. (never thought of looking for a *working* lambda :-) good idea!) -brad From mark@buttery.org Thu May 20 21:35:54 2004 From: mark@buttery.org (Mark J. Dulcey) Date: Thu, 20 May 2004 16:35:54 -0400 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: <200405201942.i4KJgpJ13017@mwave.heeltoe.com> References: <200405201942.i4KJgpJ13017@mwave.heeltoe.com> Message-ID: <40AD16AA.40105@buttery.org> Brad Parker wrote: > I've also found someone who claims to have some T300 platters from a > CADR and "wants them read". Al Kossow has the only CADR I know of which > might be able to read them - another adventure... Why would you need a CADR to read them? Any machine with a working T300 drive (admittedly a challenge to find in itself) should be able to get data from the platters. CADRs didn't really have a filesystem; the loadable "bands", or system images, were just stored in big contiguous blocks on the hard disk. (As an analogy, imagine a PC where the partition table is the only mechanism for carving up the hard disk.) Actually, there were two LispM-native file systems developed at MIT; LMFS, written by people who later went to Symbolics, and FC, which I think was written by Richard Stallman. But the majority of CADRs didn't run either of them; files other than the bootable images were normally stored on other systems and loaded over Ethernet. The LispM knew about ITS (the Incompatible Timesharing System, a locally developed OS), Tenex, TOPS-20/Twenex, Unix, and Multics file syntax, as well as the two LispM-native file systems, and could open and close files over a network from any of them. So a CADR may not have source code on its hard disk. At MIT, where they were developed, the sources were kept on a central TOPS-20 server, not on the CADRs themselves. At LMI, the Lambdas also got their source code from a central server, but the systems prepared for customers usually had a source code partition. That partition was handled by the 68000 that acted as a system manager and I/O processor, not by the LispM itself; LMI didn't use a LispM-native file system on the Lambda. They DID use LMFS on the CADRs they manufactured; those are the most likely CADRs to have source code on their hard disks. I don't think Symbolics supplied full source code with the LM-2 CADR clones they built. From hans@huebner.org Sun May 2 05:25:02 2004 From: hans@huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sun May 2 04:25:02 2004 Subject: [LMH]microExplorer keyboard overlay Message-ID: <20040502141852.V92217@exklave.huebner.org> Hi, does anyone have a scanned version of the microExplorer keyboard overlay or a complete listing of the mappings? I have found most of the keys, but some are still missing (notably TERM, but propably others, too). The TI microExplorer documentation mentions the keyboard overlay, but it does not reproduce it and has no listing, as it seems. Thanks in advance, Hans From cshapiro@panix.com Sun May 2 15:05:02 2004 From: cshapiro@panix.com (Carl Shapiro) Date: Sun May 2 14:05:02 2004 Subject: [LMH]microExplorer keyboard overlay In-Reply-To: <20040502141852.V92217@exklave.huebner.org> (message from =?ISO-8859-1?Q?Hans_H=FCbner?= on Sun, 2 May 2004 14:24:11 +0200 (CEST)) References: <20040502141852.V92217@exklave.huebner.org> Message-ID: <200405022204.i42M4FL01444@panix3.panix.com> From: =?ISO-8859-1?Q?Hans_H=FCbner?= Sender: lispm-hackers-admin@lists.unlambda.com The TI microExplorer documentation mentions the keyboard overlay, but it does not reproduce it and has no listing, as it seems. I don't know what documentation you are working from, but I learned all of the key mappings for the microExplorer through its manual. You should be able to find a picture of the keyboard with the magic keys labeled. If you haven't done so already, you should experiment with the function keys, as the keys you are probably interested in are located there. Unfortunately, all of my Explorer manuals are 3000 miles away from me, and there is little chance I will be able to refer to them on your behalf any time soon. Which manual are you looking at? Are you working from a scanned document, or a hard copy original? From hans@huebner.org Mon May 3 00:13:00 2004 From: hans@huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Sun May 2 23:13:00 2004 Subject: [LMH]microExplorer keyboard overlay In-Reply-To: <200405022204.i42M4FL01444@panix3.panix.com> References: <20040502141852.V92217@exklave.huebner.org> <200405022204.i42M4FL01444@panix3.panix.com> Message-ID: <20040503090350.J55958@exklave.huebner.org> On Sun, 2 May 2004, Carl Shapiro wrote: > Which manual are you looking at? Are you working from a scanned > document, or a hard copy original? I'm looking at the scanned copy of the "Development Software User's Guide" which I found on bitsavers.org. It has a description of many keystroke equivalents, but I have not found a complete reproduction of the full keyboard layout. I do get along, but if anyone has the full list, I'd be thankful. -Hans From brad@heeltoe.com Mon May 10 15:59:00 2004 From: brad@heeltoe.com (Brad Parker) Date: Mon May 10 14:59:00 2004 Subject: [LMH]kick me Message-ID: <200405102258.i4AMw7707622@mwave.heeltoe.com> Hi, I'm probably going to step into it deep, but since this has become a serious addiction, I'll start with, "Hi, My name is Brad, and I have two lisp machines..." I'm on a journey through the original Symbolics patent, which expires this year, on my birthday :-). I've been OCR'ing all the code in it, which includes code to produces the microcode, and perhaps, the microcode simulator. I've been running some of it, and making some progress. My lawyer friend says that I can get away with distributing the text of the entire patent, and a script which edits the patent text into usable lisp files, and not violate any copyright issues. We'll see. I don't expect to do anything which this, except have fun. In my journey I've run into Tom Knight's thesis and several papers. And of course, the CONS and CADR machines. My question is this: how close is the Explorer to the CADR? Was there a lisp based microcode simulator for the CADR? How close is the "machine code" of a CADR, an Explorer and a 36xx? sorry if this is wildly divergent... feel free to yell if this is too off topic. -brad From james@unlambda.com Mon May 10 17:24:01 2004 From: james@unlambda.com (James A. Crippen) Date: Mon May 10 16:24:01 2004 Subject: [LMH]kick me In-Reply-To: <200405102258.i4AMw7707622@mwave.heeltoe.com> References: <200405102258.i4AMw7707622@mwave.heeltoe.com> Message-ID: Brad Parker writes: > I'm probably going to step into it deep, but since this has become a > serious addiction, I'll start with, "Hi, My name is Brad, and I have two > lisp machines..." Hi Brad! Try the coffee. It's not too bad, but don't spill it on your keyboard. > I'm on a journey through the original Symbolics patent, which expires > this year, on my birthday :-). Really? Honest? Schw33t! > I've been OCR'ing all the code in it, which includes code to > produces the microcode, and perhaps, the microcode simulator. I've > been running some of it, and making some progress. My lawyer friend > says that I can get away with distributing the text of the entire > patent, and a script which edits the patent text into usable lisp > files, and not violate any copyright issues. We'll see. Are you really sure about that? I think that the copyright still applies outside of the context of the patent, thus redistribution of the patent per se is legal, but the files which are contained within it are also copyrighted outside of the patent as well. Hmm. Interesting legal problem. Glad I'm not a lawyer. > I don't expect to do anything which this, except have fun. Well, yeah. Us too. Of course, I have an ulterior motive as well. Someday I will take over the world with my evil LispM-powered giant robot hordes. But that's later. > My question is this: how close is the Explorer to the CADR? Closer than the Symbolics 3600. The Exploder is a 32 bit macrocode engine, as is the CADR. Many opcodes are similar. > Was there a lisp based microcode simulator for the CADR? There was one implemented in MACLISP on ITS. It was used to design the microcode and bootstrap the original CADR and maybe for some other purposes. It never lasted very long, being supplanted quickly by the Real Thing. > How close is the "machine code" of a CADR, an Explorer and a 36xx? Like I said above, the 36xx macrocode is quite different from teh CADR/Exploder. It's 36 bit, whereas the CADR is 32 bit. The Ivory is 40 bit. Note that there's a difference between two types of 'machine code'. The macrocode is what you get if you DISASSEMBLE some random compiled function. The microcode you can't see, it's what implements the macrocode engine. The macrocode machine doesn't really exist, it's like a VM that is implemented in the microcode which is the real hardware underneath. Thus, there are (currently) two simulators/emulators of the Exploder series. The first is Exploiter, which is a macrocode emulator of the Exploder II. The second is Nevermore, which is a microcode emulator of the Exploder I. Very different, the two of them. There are *two* {sim,em}ulators for the Symbolics Ivory. The first, which everyone hears about all the time (relatively speaking) is OpenGenera, an emulator of the Ivory macrocode on the Alpha running DEC Unix. The second is only heard of in rumors, but is another macrocode emulator running on the Mac G5. Both of these are presumably commercial, and I know that the former costs about five kilodollars. > sorry if this is wildly divergent... feel free to yell if this is too > off topic. You're so on topic that it would make Kibo's head explode if he only knew. So don't tell him. -- 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 brad@heeltoe.com Mon May 10 19:38:00 2004 From: brad@heeltoe.com (Brad Parker) Date: Mon May 10 18:38:00 2004 Subject: [LMH]kick me In-Reply-To: Your message of "10 May 2004 16:23:22 -0800." Message-ID: <200405110237.i4B2b0P09461@mwave.heeltoe.com> James A. Crippen wrote: > >> I've been OCR'ing all the code in it, which includes code to >> produces the microcode, and perhaps, the microcode simulator. I've >> been running some of it, and making some progress. My lawyer friend >> says that I can get away with distributing the text of the entire >> patent, and a script which edits the patent text into usable lisp >> files, and not violate any copyright issues. We'll see. > >Are you really sure about that? I think that the copyright still >applies outside of the context of the patent, thus redistribution of >the patent per se is legal, but the files which are contained within >it are also copyrighted outside of the patent as well. sure I'm not :-) I'm told that, as you say, redistribution of the patent is legal. And, distribution of a script which operates on the patent files is legal. so, as long as the script is run by someone else (and they don't redistribute the files), I'm ok. does that sound better/more plausible? I respect copyrights and don't wish to violate them. But I also like the notion of "hobbiest/academic use", so I'm trying to strike a balance. -brad ps: > >Of course, I have an ulterior motive as well. Someday I will take over >the world with my evil LispM-powered giant robot hordes. But that's >later. well, sure, of course. me too. :-) From asholz@topinform.de Wed May 12 00:07:01 2004 From: asholz@topinform.de (Andreas Holz) Date: Tue May 11 23:07:01 2004 Subject: [LMH]Symbolics patent Message-ID: <40A1CCDA.9010707@topinform.com> Hi Brad, when the day is you birthday, please let me know! - Andreas From Elisabeth Brown Mon May 17 01:43:01 2004 From: Elisabeth Brown (Elisabeth Brown) Date: Mon May 17 00:43:01 2004 Subject: [LMH]www.unlambda.com Message-ID: <200405170850.i4H8oare026799@localhost.localdomain> This is a multi-part message in MIME format --3307e23d-3c0a-45ee-84b3-26731167a527 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =
   
 
3D"Guaranteed
  3D"Your
 
   
Hi,

I visited http://www.unlambda.com, and noticed that you're not listed on some search engines! I would like to introduce to you an affordable = service where we can help enhance your online presence globally.

Search engine submission is an integral part of the success of = your web site. Building a web presence means more than just = having the right keywords. We offer a star solution that will produce = guaranteed results. Our unique search engine positioning technology helps = submit your website to over 300,000 search engines and directories = every month.

It takes only minutes to sign up for our service. We'll do the = rest! You'll be surprised how simple it is to now reach out to an = international market and increase the visibility of your website.

 

Do let me = know how I may assist you better with workmiracle.com!

Best Regards,
Elisabeth Brown
 
Sales and = Marketing
E-mail: Elisabethbrown@workmiracle.com
http://www.workmiracle.com
 
 
  Not interested in our = www.workmiracle.com service? To be taken off our mailing list, please follow the = instructions here.
--3307e23d-3c0a-45ee-84b3-26731167a527-- From dseagrav@sakura.lunar-tokyo.net Mon May 17 11:21:01 2004 From: dseagrav@sakura.lunar-tokyo.net (Daniel Seagraves) Date: Mon May 17 10:21:01 2004 Subject: [LMH]www.unlambda.com In-Reply-To: <200405170850.i4H8oare026799@localhost.localdomain> References: <200405170850.i4H8oare026799@localhost.localdomain> Message-ID: Oshits, you mean we aren't listed on spywaresearchportal.com? No wonder none of the emulators are finished yet! Better fix this fast. (Now, back to my rock for more hiding under!) From james@unlambda.com Mon May 17 17:38:01 2004 From: james@unlambda.com (James A. Crippen) Date: Mon May 17 16:38:01 2004 Subject: [LMH]www.unlambda.com In-Reply-To: References: <200405170850.i4H8oare026799@localhost.localdomain> Message-ID: Daniel Seagraves writes: > Oshits, you mean we aren't listed on spywaresearchportal.com? > No wonder none of the emulators are finished yet! Better fix this fast. > > (Now, back to my rock for more hiding under!) I'm signing up with them right away. -- 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 rjs@fdy2.demon.co.uk Wed May 19 14:30:01 2004 From: rjs@fdy2.demon.co.uk (Robert Swindells) Date: Wed May 19 13:30:01 2004 Subject: [LMH]Nevermore Message-ID: <20040519212737.03C8E14D6@fdy2.demon.co.uk> Are there any plans to put nevermore into CVS ? I have made a start on adding Explorer-II support to it along with some code to parse microcode files. Robert Swindells From nyef@sc.am Thu May 20 08:36:02 2004 From: nyef@sc.am (nyef@sc.am) Date: Thu May 20 07:36:02 2004 Subject: [LMH]Nevermore In-Reply-To: <20040519212737.03C8E14D6@fdy2.demon.co.uk> References: <20040519212737.03C8E14D6@fdy2.demon.co.uk> Message-ID: <20040520060749.GA17487@sc.am> On Wed, May 19, 2004 at 10:27:37PM +0100, Robert Swindells wrote: > > Are there any plans to put nevermore into CVS ? Not really, no. I still don't like CVS. > I have made a start on adding Explorer-II support to it along with > some code to parse microcode files. Oho. On the theory that because all of the other hardware is the same it should just be a matter of writing a new CPU emulator? One of the main reasons I was concentrating on Raven was that we're closer to having a full romset for Raven than we are for Hummingbird (either the ExpII or the MX), but I'm certainly open to the idea of emulating both. Starting a microload without having the STBM code will be... interesting. Particularly if you start by loading the primitive. I can think of a couple things I'd want to change if we're going to support Hummingbird in the same codebase. NuBus handling, for starters. Breaking the CPU emulation out into a separate package from everything else as well... We might also want to look for a better name. Poe never wrote about a Hummingbird that said 'Nevermore'. ^_- Have you been concentrating on parsing the microload and a disassembler, or do you have some instruction emulation as well? And would you mind sending me a patch? I may as well at least put together another release this weekend or something. And, of course, the inevitable documentation and ROM request: Does anyone have manual part number 2248114-0001 (32-Bit Lisp Microprocessor Specification), ROM dumps from an Explorer II, or a working Explorer II system? (I suspect that we may need to write our own microload to read the IROM and EPROM, and we should certainly be able to write a Lisp function to dump a NuBus declaration ROM...) > Robert Swindells --Alastair From brad@heeltoe.com Thu May 20 09:18:01 2004 From: brad@heeltoe.com (Brad Parker) Date: Thu May 20 08:18:01 2004 Subject: [LMH]Nevermore (well, exploiter actually) In-Reply-To: Message from nyef@sc.am of "Thu, 20 May 2004 01:07:49 CDT." <20040520060749.GA17487@sc.am> Message-ID: <200405201616.i4KGGRN10765@mwave.heeltoe.com> Hi, Some dumb questions (which I think I sent before but seem to have gone into the bit bucket) - is there a list of names which describes an Explorer I,II & cpu names, i.e. raven, hummingbird, etc??? - is an Explorer I essentially a CADR? Will an E1 run CADR microcode? (I thought I read that it would/could) - I was fooling around with exploiter and got it past the previous disk problem but crashed in to needing support for lexical closures. I thought "I'll just look at the microcode". But, ahem, no microcode source. The SSDN2 is good but no substitute for definative microcode. How come there is no source to the E1 or E2 microcode? Can that nice person from TI on the list dig it up, even older versions? Seems obvious, so there must be good historical reasons - please pass the clues :-) -brad From rjs@fdy2.demon.co.uk Thu May 20 09:33:01 2004 From: rjs@fdy2.demon.co.uk (Robert Swindells) Date: Thu May 20 08:33:01 2004 Subject: [LMH]Nevermore In-Reply-To: <20040520060749.GA17487@sc.am> (nyef@sc.am) Message-ID: <20040520163112.81655157A@fdy2.demon.co.uk> Alastair Bridgewater wrote: >On Wed, May 19, 2004 at 10:27:37PM +0100, Robert Swindells wrote: >> >> Are there any plans to put nevermore into CVS ? >Not really, no. I still don't like CVS. >> I have made a start on adding Explorer-II support to it along with >> some code to parse microcode files. >Oho. On the theory that because all of the other hardware is the same it >should just be a matter of writing a new CPU emulator? One of the main >reasons I was concentrating on Raven was that we're closer to having a >full romset for Raven than we are for Hummingbird (either the ExpII or >the MX), but I'm certainly open to the idea of emulating both. I took a look at it because I know that I have matching MX load and microcode bands. The other reason was that I don't know the format of the ExpI microload. I started by trying to parse the microload, I then realized that it wouldn't fit into the 56 bit wide arrays. Once I had started modifying them I thought I might as well start on the microengine and disassembler. I saw in an old message that you had worked out the ExpI ROM format, have you had any thoughts on the likely format of an ExpI microload ? >Starting a microload without having the STBM code will be... >interesting. Particularly if you start by loading the primitive. The source to the Macintosh loader program is supplied with the microExplorer tree. It doesn't seem to be doing very much to start the board up. >I can think of a couple things I'd want to change if we're going to >support Hummingbird in the same codebase. NuBus handling, for starters. >Breaking the CPU emulation out into a separate package from everything >else as well... We might also want to look for a better name. Poe never >wrote about a Hummingbird that said 'Nevermore'. ^_- I have broken the ExpII versions of things out into their own files. >Have you been concentrating on parsing the microload and a disassembler, >or do you have some instruction emulation as well? Both. I have only really done the bits that have moved around slightly within the microword. I have added handling of immediate a-mem values to the microengine, but not to the disassembler yet. >And would you mind sending me a patch? I may as well at least put >together another release this weekend or something. Ok, I'll put it together later. >And, of course, the inevitable documentation and ROM request: Does >anyone have manual part number 2248114-0001 (32-Bit Lisp Microprocessor >Specification), ROM dumps from an Explorer II, or a working Explorer II >system? (I suspect that we may need to write our own microload to read >the IROM and EPROM, and we should certainly be able to write a Lisp >function to dump a NuBus declaration ROM...) I have had a go at reading the ROM in my microExplorer. What I can't tell is whether the diagnostic microload ought to be mapped into the NuBus address space or whether this is part of the reason for the board not working. I'll send you a copy of the dump. Robert From nyef@sc.am Thu May 20 11:16:01 2004 From: nyef@sc.am (nyef@sc.am) Date: Thu May 20 10:16:01 2004 Subject: [LMH]Nevermore (well, exploiter actually) In-Reply-To: <200405201616.i4KGGRN10765@mwave.heeltoe.com> References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> Message-ID: <20040520084759.GA24272@sc.am> On Thu, May 20, 2004 at 12:16:27PM -0400, Brad Parker wrote: > > Hi, Hello. > Some dumb questions (which I think I sent before but seem to have gone > into the bit bucket) > > - is there a list of names which describes an Explorer I,II & cpu names, > i.e. raven, hummingbird, etc??? Not an explicit list, no. Of the ones you explicitly asked about, Raven is the processor from the Explorer I and Hummingbird is the processor used in the Explorer II and the microExplorer. > - is an Explorer I essentially a CADR? Will an E1 run CADR microcode? > (I thought I read that it would/could) No, but I hear tell that it is essentially an LMI Lambda (microcode compatible, at least). > - I was fooling around with exploiter and got it past the previous disk > problem but crashed in to needing support for lexical closures. I > thought "I'll just look at the microcode". But, ahem, no microcode > source. The SSDN2 is good but no substitute for definative microcode. If this is at any point past the scheduler initialization you should realize that the stack-group switch doesn't work properly, especially in regards to the binding stack (specpdl). > How come there is no source to the E1 or E2 microcode? Can that nice person > from TI on the list dig it up, even older versions? The nice person from TI with the microcode listing has, if memory serves, the VM1 (pre-release-3) sources in hardcopy only. > Seems obvious, so there must be good historical reasons - please pass > the clues :-) Yeah, the reason we don't have the microcode, the microcode assembler, or the genasys utility is that nobody could find a copy. Gone. All gone. > -brad --Alastair From nyef@sc.am Thu May 20 11:41:02 2004 From: nyef@sc.am (nyef@sc.am) Date: Thu May 20 10:41:02 2004 Subject: [LMH]Nevermore In-Reply-To: <20040520163112.81655157A@fdy2.demon.co.uk> References: <20040520060749.GA17487@sc.am> <20040520163112.81655157A@fdy2.demon.co.uk> Message-ID: <20040520091254.GB24272@sc.am> On Thu, May 20, 2004 at 05:31:12PM +0100, Robert Swindells wrote: > > I started by trying to parse the microload, I then realized that it > wouldn't fit into the 56 bit wide arrays. Once I had started modifying > them I thought I might as well start on the microengine and > disassembler. Mmm... I suppose it wouldn't hurt to at least change the cached microinstruction storage to be 64 bits wide globally... > I saw in an old message that you had worked out the ExpI ROM format, > have you had any thoughts on the likely format of an ExpI microload ? Ages back. See dise1uc.lisp, disassemble-mcr-partition for some of the details. I also posted a partially-commented disassembly of the STBM code to my webspace a while back ( http://www.dridus.com/~nyef/lispm/ ), which has the code to start a microload running on the machine. > >Starting a microload without having the STBM code will be... > >interesting. Particularly if you start by loading the primitive. > > The source to the Macintosh loader program is supplied with the > microExplorer tree. It doesn't seem to be doing very much to start > the board up. Heh. Is it just using the micronet interface to indicate the presence of a microload and having the STBM take it from there? > >I can think of a couple things I'd want to change if we're going to > >support Hummingbird in the same codebase. NuBus handling, for starters. > >Breaking the CPU emulation out into a separate package from everything > >else as well... We might also want to look for a better name. Poe never > >wrote about a Hummingbird that said 'Nevermore'. ^_- > > I have broken the ExpII versions of things out into their own files. Right, but there are a few things that should be common to both that are in files with 'raven' in the name. > I have only really done the bits that have moved around slightly > within the microword. I have added handling of immediate a-mem > values to the microengine, but not to the disassembler yet. Oh, neat. A-Immediates look like they'd make a good improvement over the A-CONSTANT stuff from the Raven microloads. One question I have, though, is if they sign or zero extend... > I have had a go at reading the ROM in my microExplorer. > > What I can't tell is whether the diagnostic microload ought to be > mapped into the NuBus address space or whether this is part of the > reason for the board not working. There's a specific diagnostic for the MX, right? Are you writing a replacement set of interface routines, or are you using the 'correct' ones? > I'll send you a copy of the dump. Cool, thanks. > Robert --Alastair From pf@ti.com Thu May 20 11:54:01 2004 From: pf@ti.com (Paul Fuqua) Date: Thu May 20 10:54:01 2004 Subject: [LMH]Nevermore (well, exploiter actually) In-Reply-To: Msg of May 20, 2004 03:48:01 (-0500) from nyef@sc.am References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> <20040520084759.GA24272@sc.am> Message-ID: <16556.65144.499575.362611@glazed04.dal.design.ti.com> Date: Thu, 20 May 2004 03:48:01 -0500 From: nyef@sc.am Not an explicit list, no. Of the ones you explicitly asked about, Raven is the processor from the Explorer I and Hummingbird is the processor used in the Explorer II and the microExplorer. Projects were being named after birds at that time. Raven was the original Explorer codename. Somewhere along the line it was semi-officially renamed Chaparral, that being a more "Southwestern" bird; some folks have little Chaparral pins from those days. Then marketing got it and named it Explorer. Microcoders are stubborn people, so files and features were named Raven (ravsym, #+raven) to the end. Hummingbird was the Explorer 2 processor because it was small and moved very fast (relatively speaking). It was also part of the DARPA Compact Lisp Machine project so sometimes there are references to that. No, but I hear tell that it is essentially an LMI Lambda (microcode compatible, at least). My understanding was that the original LMI Lambdas were indeed CADRs. The later Lambda/E model was a rebadged Explorer. I think we had LMI microcode running on Explorers -- certainly LMI did -- but I don't know what degree of porting was required. Yeah, the reason we don't have the microcode, the microcode assembler, or the genasys utility is that nobody could find a copy. Gone. All gone. Yep, nobody had the foresight to snapshot it before the division where the machine holding the master source lived was sold off. There are persistent rumors that somebody has it on a brick or tape in a box somewhere, but they haven't panned out yet. What we do have are some paper copies of VM1 microcode source, and some Explorer 1 microcode development tools, and scattered fragments of other stuff. I thought Genasys was part of the regular system source, but then that just builds the load band, it's not part of the microcode system. I did disassemble enough of the Explorer 1 microcode to answer some questions, but I'm in a delicate position as a TI employee using TI tools to fiddle with TI intellectual property, so it isn't public yet. Paul Fuqua Texas Instruments, Dallas, Texas pf@ti.com From nyef@sc.am Thu May 20 12:18:01 2004 From: nyef@sc.am (nyef@sc.am) Date: Thu May 20 11:18:01 2004 Subject: [LMH]Nevermore (well, exploiter actually) In-Reply-To: <16556.65144.499575.362611@glazed04.dal.design.ti.com> References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> <20040520084759.GA24272@sc.am> <16556.65144.499575.362611@glazed04.dal.design.ti.com> Message-ID: <20040520094958.GA1134@sc.am> On Thu, May 20, 2004 at 01:52:40PM -0500, Paul Fuqua wrote: > > Projects were being named after birds at that time. Raven was the > original Explorer codename. Somewhere along the line it was > semi-officially renamed Chaparral, that being a more "Southwestern" > bird; some folks have little Chaparral pins from those days. Then > marketing got it and named it Explorer. Well, that explains the process-scheduler-for-chaparral thing. I had originally written that off as being a custom hack for some specific person that ended up in the main system, not realizing that it was a bird name, but this makes more sense. > What we do have are some paper copies of VM1 microcode source, and > some Explorer 1 microcode development tools, and scattered fragments > of other stuff. I thought Genasys was part of the regular system > source, but then that just builds the load band, it's not part of the > microcode system. Hey, while I've got your attention, do you know anything about the way that unmapped memory accesses on Raven update the memory maps? One of the VMA tests is checking for it fairly explicitly, but it's not doing it with sufficient coverage for me to figure out what's going on, and the only other reference I've found is a couple figures in SSDN2 which provide descriptions of the various bit positions that need updating (the last-access-mapped bit in the level-1 map and the TM0 and TM1 bits in the level-2 map). As near as I can tell, the TM0 and TM1 bits are always going to be 0 for a mapped access (since it's wordwise), but beyond that I'm kindof at a loss. --Alastair From mark@buttery.org Thu May 20 12:29:01 2004 From: mark@buttery.org (Mark J. Dulcey) Date: Thu May 20 11:29:01 2004 Subject: [LMH]Nevermore (well, exploiter actually) In-Reply-To: <16556.65144.499575.362611@glazed04.dal.design.ti.com> References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> <20040520084759.GA24272@sc.am> <16556.65144.499575.362611@glazed04.dal.design.ti.com> Message-ID: <40AD06BE.3040803@buttery.org> Paul Fuqua wrote: > My understanding was that the original LMI Lambdas were indeed > CADRs. The later Lambda/E model was a rebadged Explorer. I think we > had LMI microcode running on Explorers -- certainly LMI did -- but I > don't know what degree of porting was required. The LMI Lambda evolved from the CADR, but it was not identical. It used a 64-bit microword word (longer than the CADR, which was either 48 or 56 bits; I don't remember), and supported 64K words of microcode instead of the 16K supported by the CADR. The larger microcode store was meant to allow use of the microcompiler (a compiler that turned Lisp into microcode, with a lot of data type restrictions), but I don't think anybody ever did much with that. The other novel feature of the Lambda was the macro IR decode RAM (a 64K-word RAM with an entry for every possible 16-bit instruction pattern!) -- a brute force solution to the problem of decoding the rather baroque LM instruction set. > Yeah, the reason we don't have the microcode, the microcode assembler, > or the genasys utility is that nobody could find a copy. Gone. All gone. It's a pity that nobody seems to have turned up a working Lambda. Those routinely shipped with full system sources, all the way down to the microcode, though some customers didn't bother with the full sources because they didn't have enough disk space for them. From brad@heeltoe.com Thu May 20 13:05:02 2004 From: brad@heeltoe.com (Brad Parker) Date: Thu May 20 12:05:02 2004 Subject: [LMH]Nevermore (well, exploiter actually) In-Reply-To: Message from "Mark J. Dulcey" of "Thu, 20 May 2004 15:27:58 EDT." <40AD06BE.3040803@buttery.org> Message-ID: <200405201942.i4KJgpJ13017@mwave.heeltoe.com> "Mark J. Dulcey" wrote: > >It's a pity that nobody seems to have turned up a working Lambda. Those >routinely shipped with full system sources, all the way down to the >microcode, though some customers didn't bother with the full sources >because they didn't have enough disk space for them. I'm tracking down some alleged "lambda sources" on 9-track. We'll see what's on the tape (if if they can even be read, he said, crossing his fingers). I'll certainly speak up if the tapes yield something. It will be some time in June. I've also found someone who claims to have some T300 platters from a CADR and "wants them read". Al Kossow has the only CADR I know of which might be able to read them - another adventure... I've been searching high and low for "CADR sources". No luck yet. (never thought of looking for a *working* lambda :-) good idea!) -brad From mark@buttery.org Thu May 20 13:37:01 2004 From: mark@buttery.org (Mark J. Dulcey) Date: Thu May 20 12:37:01 2004 Subject: [LMH]Nevermore (well, exploiter actually) In-Reply-To: <200405201942.i4KJgpJ13017@mwave.heeltoe.com> References: <200405201942.i4KJgpJ13017@mwave.heeltoe.com> Message-ID: <40AD16AA.40105@buttery.org> Brad Parker wrote: > I've also found someone who claims to have some T300 platters from a > CADR and "wants them read". Al Kossow has the only CADR I know of which > might be able to read them - another adventure... Why would you need a CADR to read them? Any machine with a working T300 drive (admittedly a challenge to find in itself) should be able to get data from the platters. CADRs didn't really have a filesystem; the loadable "bands", or system images, were just stored in big contiguous blocks on the hard disk. (As an analogy, imagine a PC where the partition table is the only mechanism for carving up the hard disk.) Actually, there were two LispM-native file systems developed at MIT; LMFS, written by people who later went to Symbolics, and FC, which I think was written by Richard Stallman. But the majority of CADRs didn't run either of them; files other than the bootable images were normally stored on other systems and loaded over Ethernet. The LispM knew about ITS (the Incompatible Timesharing System, a locally developed OS), Tenex, TOPS-20/Twenex, Unix, and Multics file syntax, as well as the two LispM-native file systems, and could open and close files over a network from any of them. So a CADR may not have source code on its hard disk. At MIT, where they were developed, the sources were kept on a central TOPS-20 server, not on the CADRs themselves. At LMI, the Lambdas also got their source code from a central server, but the systems prepared for customers usually had a source code partition. That partition was handled by the 68000 that acted as a system manager and I/O processor, not by the LispM itself; LMI didn't use a LispM-native file system on the Lambda. They DID use LMFS on the CADRs they manufactured; those are the most likely CADRs to have source code on their hard disks. I don't think Symbolics supplied full source code with the LM-2 CADR clones they built. From rjs@fdy2.demon.co.uk Thu May 20 15:36:02 2004 From: rjs@fdy2.demon.co.uk (Robert Swindells) Date: Thu May 20 14:36:02 2004 Subject: [LMH]Nevermore In-Reply-To: <20040520091254.GB24272@sc.am> (nyef@sc.am) Message-ID: <20040520223409.EB73F15C7@fdy2.demon.co.uk> Alastair Bridgewater wrote: >On Thu, May 20, 2004 at 05:31:12PM +0100, Robert Swindells wrote: >> >> I started by trying to parse the microload, I then realized that it >> wouldn't fit into the 56 bit wide arrays. Once I had started modifying >> them I thought I might as well start on the microengine and >> disassembler. >Mmm... I suppose it wouldn't hurt to at least change the cached >microinstruction storage to be 64 bits wide globally... They are also a different length... >> I saw in an old message that you had worked out the ExpI ROM format, >> have you had any thoughts on the likely format of an ExpI microload ? >Ages back. See dise1uc.lisp, disassemble-mcr-partition for some of the >details. I also posted a partially-commented disassembly of the STBM >code to my webspace a while back ( http://www.dridus.com/~nyef/lispm/ ), >which has the code to start a microload running on the machine. I don't seem to have that function in dise1uc.lisp. I had downloaded the STBM listing already. >> >Starting a microload without having the STBM code will be... >> >interesting. Particularly if you start by loading the primitive. >> >> The source to the Macintosh loader program is supplied with the >> microExplorer tree. It doesn't seem to be doing very much to start >> the board up. >Heh. Is it just using the micronet interface to indicate the presence of >a microload and having the STBM take it from there? I think it must be. See what you think when you get the tarball. >> >I can think of a couple things I'd want to change if we're going to >> >support Hummingbird in the same codebase. NuBus handling, for starters. >> >Breaking the CPU emulation out into a separate package from everything >> >else as well... We might also want to look for a better name. Poe never >> >wrote about a Hummingbird that said 'Nevermore'. ^_- >> >> I have broken the ExpII versions of things out into their own files. >Right, but there are a few things that should be common to both that are >in files with 'raven' in the name. Feel free to merge any shared stuff back together. >> I have only really done the bits that have moved around slightly >> within the microword. I have added handling of immediate a-mem >> values to the microengine, but not to the disassembler yet. >Oh, neat. A-Immediates look like they'd make a good improvement over the >A-CONSTANT stuff from the Raven microloads. One question I have, though, >is if they sign or zero extend... I was hoping that the encoding of immediates would be obvious once we started disassembling the microload. >> I have had a go at reading the ROM in my microExplorer. >> >> What I can't tell is whether the diagnostic microload ought to be >> mapped into the NuBus address space or whether this is part of the >> reason for the board not working. >There's a specific diagnostic for the MX, right? Are you writing a >replacement set of interface routines, or are you using the 'correct' >ones? My MX won't boot, so I'm just poking at it from the Macintosh side. The ExpII processor document states that the NuBus config ROM contains the STBM. I was just guessing that the MX was the same, but couldn't see anything that looked meaningful. Robert From amoroso@mclink.it Fri May 21 00:37:00 2004 From: amoroso@mclink.it (Paolo Amoroso) Date: Thu May 20 23:37:00 2004 Subject: [LMH]Nevermore (well, exploiter actually) In-Reply-To: <16556.65144.499575.362611@glazed04.dal.design.ti.com> (Paul Fuqua's message of "Thu, 20 May 2004 13:52:40 -0500") References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> <20040520084759.GA24272@sc.am> <16556.65144.499575.362611@glazed04.dal.design.ti.com> Message-ID: <87r7tex42s.fsf@plato.moon.paoloamoroso.it> Paul Fuqua writes: > Projects were being named after birds at that time. Raven was the > original Explorer codename. Somewhere along the line it was > semi-officially renamed Chaparral, that being a more "Southwestern" > bird; some folks have little Chaparral pins from those days. Then > marketing got it and named it Explorer. Given that Xerox marketing called their LispMs Dandelion and Dandetiger, I wonder how the techies called them... :) Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From cshapiro@panix.com Fri May 21 00:42:00 2004 From: cshapiro@panix.com (Carl Shapiro) Date: Thu May 20 23:42:00 2004 Subject: [LMH]Nevermore (well, exploiter actually) In-Reply-To: <87r7tex42s.fsf@plato.moon.paoloamoroso.it> (message from Paolo Amoroso on Thu, 20 May 2004 21:59:23 +0200) References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> <20040520084759.GA24272@sc.am> <16556.65144.499575.362611@glazed04.dal.design.ti.com> <87r7tex42s.fsf@plato.moon.paoloamoroso.it> Message-ID: <200405210741.i4L7fbh12667@panix3.panix.com> From: Paolo Amoroso Date: Thu, 20 May 2004 21:59:23 +0200 Given that Xerox marketing called their LispMs Dandelion and Dandetiger, I wonder how the techies called them... :) Those *are* the "technie" names. Perhaps you have noticed that all Xerox products are not named, but numbered? (In the aformented case that would be the 1108 and 1109, respectively). From nyef@sc.am Fri May 21 06:56:01 2004 From: nyef@sc.am (nyef@sc.am) Date: Fri May 21 05:56:01 2004 Subject: [LMH]Nevermore In-Reply-To: <20040520223409.EB73F15C7@fdy2.demon.co.uk> References: <20040520091254.GB24272@sc.am> <20040520223409.EB73F15C7@fdy2.demon.co.uk> Message-ID: <20040521042753.GA29701@sc.am> On Thu, May 20, 2004 at 11:34:09PM +0100, Robert Swindells wrote: > > Alastair Bridgewater wrote: > >On Thu, May 20, 2004 at 05:31:12PM +0100, Robert Swindells wrote: > >> > >> I saw in an old message that you had worked out the ExpI ROM format, > >> have you had any thoughts on the likely format of an ExpI microload ? > > >Ages back. See dise1uc.lisp, disassemble-mcr-partition for some of the > >details. I also posted a partially-commented disassembly of the STBM > >code to my webspace a while back ( http://www.dridus.com/~nyef/lispm/ ), > >which has the code to start a microload running on the machine. > > I don't seem to have that function in dise1uc.lisp. Oop. Yeah, that's in my current version. I tried to send you a tarball of my WIP directory, but I guess that didn't go through. > >Heh. Is it just using the micronet interface to indicate the presence of > >a microload and having the STBM take it from there? > > I think it must be. > > See what you think when you get the tarball. The first thing that comes to mind is "Dear lord this is nasty". The most horribly K&R C I've seen in ages, half of the system in Pascal as well, it -is- a NuPI simulator, and they depend absolutely on the system not only being 24-bit capable (not true of the later machines) but also running in 24-bit mode (if memory serves, not true of System 7). It might be possible to get an MX running on a more recent machine (possibly even a powermac), but it'd require basically rewriting all of the MacOS-side code. > Feel free to merge any shared stuff back together. Yeah, I'm thinking separate packages for nevermore itself, the raven emulation, and the hummingbird emulation. > >Oh, neat. A-Immediates look like they'd make a good improvement over the > >A-CONSTANT stuff from the Raven microloads. One question I have, though, > >is if they sign or zero extend... > > I was hoping that the encoding of immediates would be obvious once we > started disassembling the microload. Actually, the encoding is fairly obvious just from looking at humfmt.lisp. The constants can be either left- or right-justified, and will sign extend if they are right-justified. The only question I have is if the sign bit is chopped off if they are left-justified (I doubt it, it'd be hard to justify that decision). Well, and what it looks like to the assembler. I am kindof concerned about the 4-deep instruction pipeline and the cache setup. Figuring them out without better documentation could be a little difficult. > >There's a specific diagnostic for the MX, right? Are you writing a > >replacement set of interface routines, or are you using the 'correct' > >ones? > > My MX won't boot, so I'm just poking at it from the Macintosh side. > > The ExpII processor document states that the NuBus config ROM contains > the STBM. I was just guessing that the MX was the same, but couldn't > see anything that looked meaningful. Mmm... That config ROM image doesn't look right at all. It looks to be short a byte, and shouldn't it be longer if you're doing word-wise dumps and the bytelanes value is #xE1? (at least, I assume that's the bytelanes value...) What would be really nice is if one of the nice TI people would stumble across a copy of the 256-word IROM code from the hummingbird chip. Otherwise we may have to write a custom microload to extract the code once we have access to a working system... I suppose it doesn't really matter for now, we can probably fake something up to get it working in the meantime... > Robert --Alastair From rjs@fdy2.demon.co.uk Fri May 21 07:30:02 2004 From: rjs@fdy2.demon.co.uk (Robert Swindells) Date: Fri May 21 06:30:02 2004 Subject: [LMH]Nevermore In-Reply-To: <20040521042753.GA29701@sc.am> (nyef@sc.am) Message-ID: <20040521142741.981271643@fdy2.demon.co.uk> Alastair Bridgewater wrote: >On Thu, May 20, 2004 at 11:34:09PM +0100, Robert Swindells wrote: >> >> Alastair Bridgewater wrote: >> >On Thu, May 20, 2004 at 05:31:12PM +0100, Robert Swindells wrote: >> >> >> >> I saw in an old message that you had worked out the ExpI ROM format, >> >> have you had any thoughts on the likely format of an ExpI microload ? >> >> >Ages back. See dise1uc.lisp, disassemble-mcr-partition for some of the >> >details. I also posted a partially-commented disassembly of the STBM >> >code to my webspace a while back ( http://www.dridus.com/~nyef/lispm/ ), >> >which has the code to start a microload running on the machine. >> >> I don't seem to have that function in dise1uc.lisp. >Oop. Yeah, that's in my current version. I tried to send you a tarball >of my WIP directory, but I guess that didn't go through. When did you send it ? My outgoing email was being sent with an incorrect reply address for a few days. >> >Heh. Is it just using the micronet interface to indicate the presence of >> >a microload and having the STBM take it from there? >> >> I think it must be. >> >> See what you think when you get the tarball. >The first thing that comes to mind is "Dear lord this is nasty". The >most horribly K&R C I've seen in ages, half of the system in Pascal as >well, it -is- a NuPI simulator, and they depend absolutely on the system >not only being 24-bit capable (not true of the later machines) but also >running in 24-bit mode (if memory serves, not true of System 7). It >might be possible to get an MX running on a more recent machine >(possibly even a powermac), but it'd require basically rewriting all of >the MacOS-side code. It is pretty ugly. There are warnings in the documentation about not using the network from MacOS and the MX at the same time, so it would be worth rewriting it anyway. >> >There's a specific diagnostic for the MX, right? Are you writing a >> >replacement set of interface routines, or are you using the 'correct' >> >ones? >> >> My MX won't boot, so I'm just poking at it from the Macintosh side. >> >> The ExpII processor document states that the NuBus config ROM contains >> the STBM. I was just guessing that the MX was the same, but couldn't >> see anything that looked meaningful. >Mmm... That config ROM image doesn't look right at all. It looks to be >short a byte, and shouldn't it be longer if you're doing word-wise dumps >and the bytelanes value is #xE1? (at least, I assume that's the >bytelanes value...) I'll take a look at how I'm mapping it later. I probably stopped one byte too soon. I can easily dump out the whole 16MB if I need to, I have written a NetBSD driver for it. >What would be really nice is if one of the nice TI people would stumble >across a copy of the 256-word IROM code from the hummingbird chip. >Otherwise we may have to write a custom microload to extract the code >once we have access to a working system... I suppose it doesn't really >matter for now, we can probably fake something up to get it working in >the meantime... It seemed fairly easy to unpick the ExpII microload, I would suggest just setting the micro PC to the correct address and letting it go. It made sense for you to use the ExpI roms to debug Nevermore, but 256 words doesn't really seem a big enough sample to help much with an ExpII variant. Robert From robmyers@mac.com Fri May 21 08:19:01 2004 From: robmyers@mac.com (Rob Myers) Date: Fri May 21 07:19:01 2004 Subject: [LMH]Nevermore Message-ID: <11539255.1085152702459.JavaMail.robmyers@mac.com> On Friday, May 21, 2004, at 05:27AM, wrote: >The first thing that comes to mind is "Dear lord this is nasty". The >most horribly K&R C I've seen in ages, half of the system in Pascal as >well, it -is- a NuPI simulator, and they depend absolutely on the system >not only being 24-bit capable (not true of the later machines) but also >running in 24-bit mode (if memory serves, not true of System 7). It >might be possible to get an MX running on a more recent machine >(possibly even a powermac), but it'd require basically rewriting all of >the MacOS-side code. Hello to the list. I'm new to this, but very interested, and I know Macs. :-) System 7 *can* do 24-bit (there's a radio button in the memory manager control panel) but IIRC only on 68k Macs.So the most recent machine would be a Quadra (68040), not a PowerMac. Only very early PowerMacs had NuBus (all 68ks did), more recent ones have PCI. 68k code is interpreted transparently by the 68k virtual machine on PowerPC MacOS up to MacOS 9.X and under Classic on MacOS X. You can run System 7 under Mac-on-Linux under PowerPC Linux, but only the PowerPC version (obviously...). There are 68k Mac software emulators available. What in particular does the system rely on the Mac running in 24-bit mode for? If it's using the MacOS APIs, the calls to strip handles (etc) become do-nothings under 32-bit MacOS. - Rob. From nyef@sc.am Fri May 21 09:02:01 2004 From: nyef@sc.am (nyef@sc.am) Date: Fri May 21 08:02:01 2004 Subject: [LMH]Nevermore In-Reply-To: <11539255.1085152702459.JavaMail.robmyers@mac.com> References: <11539255.1085152702459.JavaMail.robmyers@mac.com> Message-ID: <20040521063403.GA32398@sc.am> On Fri, May 21, 2004 at 04:18:22PM +0100, Rob Myers wrote: > On Friday, May 21, 2004, at 05:27AM, wrote: > > Hello to the list. Hello. > I'm new to this, but very interested, and I know Macs. :-) Believe it or not, so do we. Mr. Swindells and myself are both on the NetBSD/mac68k mailing list, and have been known to do the occasional bit of kernel hacking. > What in particular does the system rely on the Mac running in 24-bit mode for? If it's using the MacOS APIs, the calls to strip handles (etc) become do-nothings under 32-bit MacOS. The calls to SetMMUMode() are used to set the mode to 24 or 32 bits explicitly and they don't save the current mode setting. Beyond that I suspect it was just that the machines at the time didn't support 32-bit mode for user code. I'd make an unflattering comment, but the people who did the damage might see it and I might need their help later. ^_- > - Rob. --Alastair From nyef@sc.am Fri May 21 09:45:01 2004 From: nyef@sc.am (nyef@sc.am) Date: Fri May 21 08:45:01 2004 Subject: [LMH]Nevermore In-Reply-To: <20040521142741.981271643@fdy2.demon.co.uk> References: <20040521042753.GA29701@sc.am> <20040521142741.981271643@fdy2.demon.co.uk> Message-ID: <20040521071742.GA9474@sc.am> On Fri, May 21, 2004 at 03:27:41PM +0100, Robert Swindells wrote: > > >Oop. Yeah, that's in my current version. I tried to send you a tarball > >of my WIP directory, but I guess that didn't go through. > > When did you send it ? My outgoing email was being sent with an incorrect > reply address for a few days. Yeah, just looked in my sent folder, the email address was wrong. Do you want me to send it to you now, or would you rather wait for me to put together a proper release this weekend? > It made sense for you to use the ExpI roms to debug Nevermore, but > 256 words doesn't really seem a big enough sample to help much with > an ExpII variant. How about an argument about accuracy-in-emulation? The real thing boots from that 256-word ROM, why shouldn't the emulator? > Robert --Alastair From robmyers@mac.com Fri May 21 12:16:02 2004 From: robmyers@mac.com (Rob Myers) Date: Fri May 21 11:16:02 2004 Subject: [LMH]Nevermore In-Reply-To: <20040521063403.GA32398@sc.am> References: <11539255.1085152702459.JavaMail.robmyers@mac.com> <20040521063403.GA32398@sc.am> Message-ID: <44436FA0-AB5B-11D8-A111-00306590A6B6@mac.com> On 21 May 2004, at 07:34, nyef@sc.am wrote: > Mr. Swindells and myself are both on the > NetBSD/mac68k mailing list, and have been known to do the occasional > bit > of kernel hacking. That's some knowing. :-) > The calls to SetMMUMode() are used to set the mode to 24 or 32 bits > explicitly and they don't save the current mode setting. Ew. Does this have anything to do with getting data over the NuBus or is it just a software system? - Rob. From nyef@sc.am Fri May 21 12:20:01 2004 From: nyef@sc.am (nyef@sc.am) Date: Fri May 21 11:20:01 2004 Subject: [LMH]Nevermore In-Reply-To: <44436FA0-AB5B-11D8-A111-00306590A6B6@mac.com> References: <11539255.1085152702459.JavaMail.robmyers@mac.com> <20040521063403.GA32398@sc.am> <44436FA0-AB5B-11D8-A111-00306590A6B6@mac.com> Message-ID: <20040521095243.GA22726@sc.am> On Fri, May 21, 2004 at 08:15:48PM +0100, Rob Myers wrote: > On 21 May 2004, at 07:34, nyef@sc.am wrote: > > >The calls to SetMMUMode() are used to set the mode to 24 or 32 bits > >explicitly and they don't save the current mode setting. > > Ew. > Does this have anything to do with getting data over the NuBus or is it > just a software system? AFAIK the mode is switched during the disk emulation to transfer disk commands and data to and from the microExplorer board memory. So yes, a NuBus data transfer. > - Rob. --Alastair From pf@ti.com Fri May 21 16:56:01 2004 From: pf@ti.com (Paul Fuqua) Date: Fri May 21 15:56:01 2004 Subject: [LMH]kick me In-Reply-To: Msg of May 10, 2004 22:37:00 (-0400) from Brad Parker References: <200405110237.i4B2b0P09461@mwave.heeltoe.com> Message-ID: <16558.38581.828837.756209@glazed04.dal.design.ti.com> Date: Mon, 10 May 2004 22:37:00 -0400 From: Brad Parker I'm told that, as you say, redistribution of the patent is legal. And, distribution of a script which operates on the patent files is legal. I just had an AKCL flashback. pf From nyef@sc.am Mon May 24 07:27:01 2004 From: nyef@sc.am (nyef@sc.am) Date: Mon May 24 06:27:01 2004 Subject: [LMH] Nevermore status update Message-ID: <20040524045855.GA11970@sc.am> Hello all. A brief status update. No new release last weekend. We were supposed to get internet access at the house working again by noon on saturday, but that just didn't happen. At least I didn't completely waste the time... I split out most of the Raven CPU emulation and disassembler to a new package. There's still some cleanup left, mostly around the nubus interface, but at least that first step is done. I put together an initial implementation of the DISPATCH instruction. I came up with a workable theory as to how the GCVF bit works. To the point where EXPT now passes the GCVF tests. I updated the README file a bit. Probably some other stuff, too. So anyway, all this, and then I discover this morning that my kernel doesn't have FAT filesystem support, so I can't even carry a release tarball in without fixing the home network (which I destroyed while trying to get the internet connection working). New release tomorrow or wednesday. I hope. --Alastair From nyef@sc.am Mon May 24 07:35:01 2004 From: nyef@sc.am (nyef@sc.am) Date: Mon May 24 06:35:01 2004 Subject: [LMH] Oldspace? Message-ID: <20040524050736.GA13259@sc.am> Hello all. Just a quick question. For DISPATCH on the Oldspace bit, is this the level-1 map from the last read or write through VMA, the level-1 map from the current contents of VMA, or the level-1 map indexed from the current contents of MD? --Alastair From nyef@sc.am Tue May 25 13:34:00 2004 From: nyef@sc.am (nyef@sc.am) Date: Tue May 25 12:34:00 2004 Subject: [LMH] Nevermore status update In-Reply-To: <20040524045855.GA11970@sc.am> References: <20040524045855.GA11970@sc.am> Message-ID: <20040525110614.GA8562@sc.am> On Sun, May 23, 2004 at 11:58:56PM -0500, nyef@sc.am wrote: > New release tomorrow or wednesday. I hope. And 'tomorrow' it was. For yesterdays value of tomorrow... http://www.dridus.com/~nyef/lispm/nevermore/nevermore-9e0525.tgz > --Alastair From stevelisp@grape-krueger.com Tue May 25 21:52:01 2004 From: stevelisp@grape-krueger.com (Steve Krueger) Date: Tue May 25 20:52:01 2004 Subject: [LMH] Oldspace? References: <20040524050736.GA13259@sc.am> Message-ID: <40B4225D.1050804@sbcglobal.net> Alastair, Pointers to oldspace are never permitted inside the machine, so if the data being read is a pointer to oldspace, the object it points to must be transported to newspace and the pointer changed to a pointer to the new object. Of course, if the object read was an immediate type like a fixnum, you don't do any of the extra stuff. Here is how it works on Explorer I: After a memory read, the level 1 memory map is run again on the data returned in order to get the oldspace bit. This bit is bit 10 (decimal) of the Level 1 map. The Q-DATA-TYPE field plus the oldspace bit are used for the transport dispatch microinstruction. The resulting dispatch table has an even and an odd entry for each data type. Pointer types send the microcode off to the transporter to copy the object to newspace and fixup the pointer in MD. The transporter dispatch also uses a special feature DISPATCH-STACK-OWN-ADDRESS. Call transfers from the transporter dispatch stack the return address of the transporter dispatch rather than of the next microinstruction or the one after that (depending on XCT-NEXT). This allows a forwarding pointer (DTP-GC-FORWARD that the transporter leaves behind in oldspace when it evacuates an object, or DTP-ONE-Q-FORWARD, etc.) to loop following forwarding pointer. Neat trick. On Explorer II (Hummingbird-based), we split off the region bits in the memory map into a separate address space map. The AS map was addressed by MD always and the VM map was addressed by VMA. The oldspace bit (being a region property) was in the AS map. The AS map was run after the data was returned to get the oldspace bit so that it was set up for the transporter dispatch. In all other ways, it was the same as described above. I just dashed this off. I hope it isn't too cryptic. -Steve nyef@sc.am wrote: >Hello all. > >Just a quick question. For DISPATCH on the Oldspace bit, is this the >level-1 map from the last read or write through VMA, the level-1 map >from the current contents of VMA, or the level-1 map indexed from the >current contents of MD? > >--Alastair > >http://lists.unlambda.com/mailman/listinfo/lispm-hackers > > > From nyef@sc.am Wed May 26 06:59:01 2004 From: nyef@sc.am (nyef@sc.am) Date: Wed May 26 05:59:01 2004 Subject: [LMH] Oldspace? In-Reply-To: <40B4225D.1050804@sbcglobal.net> References: <20040524050736.GA13259@sc.am> <40B4225D.1050804@sbcglobal.net> Message-ID: <20040526043134.GA8959@sc.am> On Tue, May 25, 2004 at 11:51:41PM -0500, Steve Krueger wrote: > Alastair, > > Here is how it works on Explorer I: > > After a memory read, the level 1 memory map is run again on the data > returned in order to get the oldspace bit. This bit is bit 10 (decimal) > of the Level 1 map. Okay, that's about what I was hoping for. Now, for the GCVF stuff, the EXPT tests set up the level-2 map values, do a memory read (?), do the ((MD) SETM MD) thing just as for a write, set up the level-1 map values, and then dispatch. I'm assuming then that any read or write activity caches the level-2 map value from VMA and then the dispatch compares the GCV fields from the cached level-2 map and the level-1 map for the contents of MD at dispatch time to find the GCVF value. Does this model bear more than a passing resemblance to reality? > I just dashed this off. I hope it isn't too cryptic. Not at all. Exactly what I wanted to know, and some extra background information. Thank you. > -Steve --Alastair From stevelisp@grape-krueger.com Thu May 27 18:34:00 2004 From: stevelisp@grape-krueger.com (Steve Krueger) Date: Thu May 27 17:34:00 2004 Subject: [LMH]GC Volatility Message-ID: <40B696E3.7080908@sbcglobal.net> --------------020402070808060700070307 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit One correction from my previous message. The map on Explorer-I always looks at MD, except that just after a read or write is started it is switched temporarily to map the contents of VMA instead. The chief observable behavior is that you can write MD and then (after a small delay) do a transporter dispatch (a sequence that does indeed occur if I remember anything close to what's in the microcode). My answer is below the question. nyef@sc.am wrote: >Now, for the GCVF stuff, the EXPT tests set up the level-2 map values, >do a memory read (?), do the ((MD) SETM MD) thing just as for a write, >set up the level-1 map values, and then dispatch. I'm assuming then that >any read or write activity caches the level-2 map value from VMA and >then the dispatch compares the GCV fields from the cached level-2 map >and the level-1 map for the contents of MD at dispatch time to find the >GCVF value. Does this model bear more than a passing resemblance to >reality? > Actually, it doesn't sound familiar :-( The GC volatility property is computed from 3 bits in the level 1 map and 2 bits in the level 2 map. When a memory access is started and VMA is temporarily mapped by the level 1 and level 2 mapper, the level 2 GCV bits (LVL2[34:33]) are latched. After the mapper flips back to mapping MD, logic computes the GCV fault bit from the 2 latched LVL2 bits and the three bits from LVL1 (LVL1[9:7}). Here is the only lines of the logic truth table that give a fault: LVL1 BITS LVL2 BITS GCV FAULT 9 8 7 34 33 0 1 1 0 0 1 0 1 0 0 x 1 0 0 1 1 0 1 0 0 1 0 x 1 0 0 0 x x 1 Note that in LVL1, a code of 00 is the most volatile region while in LVL2, a code of 11 is the most volatile region. The GVC fault test is for the LVL1 volatility being greater than or equal to the LVL2 volatility. GCV is tested on Explorer-I by setting microinstruction bit 10 in a dispatch instruction. This bit OR's this GCV fault bit into the dispatch address. Microinstruction bit 11 in a dispatch instruction does the same with the oldspace bit. The transporter dispatch for boxed data being read into the machine tests the data type and the oldspace bit. The GC-WRITE-TEST dispatch similarly is used to test the data type and GCV fault bit. If a pointer is being written that points to a more volatile region than the region to which it is being written, the GC write test calls a routine to move the object to the less volatile region and update the pointer in MD, then restart the write. There are several variations of the transporter dispatch table (D-TRANSPORT) to handle several situations. Value cells are read with a slightly different transport dispatch because they can have EVCPs, for example. OK, I hope that gets you going again. BTW, Explorer-II separated the map into two parts, one for address generation and the other for the GC properties. The GC properties map was call the address space map (AS Map). Because it only needed to map region quanta (which are 32 kilowords), and because SRAM devices had gotten larger, it was a complete map of the entire address space. This improved performance by several percent as we found that the two level map structure had a high map fault rate, in part because it needed to map both the addresses and the region properties. Because of these changes, the details are a bit different for Explorer II but the concepts are almost exactly the same. Oh, and the maps weren't contained in the Hummingbird chip, but rather were on the processor board, built with standard SRAMS and PALs. > > >>I just dashed this off. I hope it isn't too cryptic. >> >> > >Not at all. Exactly what I wanted to know, and some extra background >information. Thank you. > > Great! -Steve --------------020402070808060700070307 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
One correction from my previous message.  The map on Explorer-I always looks at MD, except that just after a read or write is started it is switched temporarily to map the contents of VMA instead.  The chief observable behavior is that you can write MD and then (after a small delay) do a transporter dispatch (a sequence that does indeed occur if I remember anything close to what's in the microcode).

My answer is below the question.

nyef@sc.am wrote:
Now, for the GCVF stuff, the EXPT tests set up the level-2 map values, 
do a memory read (?), do the ((MD) SETM MD) thing just as for a write, 
set up the level-1 map values, and then dispatch. I'm assuming then that 
any read or write activity caches the level-2 map value from VMA and 
then the dispatch compares the GCV fields from the cached level-2 map 
and the level-1 map for the contents of MD at dispatch time to find the 
GCVF value. Does this model bear more than a passing resemblance to 
reality?
Actually, it doesn't sound familiar :-(

The GC volatility property is computed from 3 bits in the level 1 map and 2 bits in the level 2 map.

When a memory access is started and VMA is temporarily mapped by the level 1 and level 2 mapper, the level 2 GCV bits (LVL2[34:33]) are latched.  After the mapper flips back to mapping MD, logic computes the GCV fault bit from the 2 latched LVL2 bits and the three bits from LVL1 (LVL1[9:7}).

Here is the only lines of the logic truth table that give a fault:

LVL1 BITS      LVL2 BITS        GCV FAULT
9  8  7               34  33
0  1  1                 0    0                            1
0  1  0                 0    x                            1
0  0  1                 1    0                            1
0  0  1                 0    x                            1
0  0  0                 x    x                            1

Note that in LVL1, a code of 00 is the most volatile region while in LVL2, a code of 11 is the most volatile region.  The GVC fault test is for the LVL1 volatility being greater than or equal to the LVL2 volatility.

GCV is tested on Explorer-I by setting microinstruction bit 10 in a dispatch instruction.  This bit OR's this GCV fault bit into the dispatch address.  Microinstruction bit 11 in a dispatch instruction does the same with the oldspace bit.

The transporter dispatch for boxed data being read into the machine tests the data type and the oldspace bit.

The GC-WRITE-TEST dispatch similarly is used to test the data type and GCV fault bit.  If a pointer is being written that points to a more volatile region than the region to which it is being written, the GC write test calls a routine to move the object to the less volatile region and update the pointer in MD, then restart the write.

There are several variations of the transporter dispatch table (D-TRANSPORT) to handle several situations.  Value cells are read with a slightly different transport dispatch because they can have EVCPs, for example.

OK, I hope that gets you going again.

BTW, Explorer-II separated the map into two parts, one for address generation and the other for the GC properties.  The GC properties map was call the address space map (AS Map).  Because it only needed to map region quanta (which are 32 kilowords), and because SRAM devices had gotten larger, it was a complete map of the entire address space.  This improved performance by several percent as we found that the two level map structure had a high map fault rate, in part because it needed to map both the addresses and the region properties.

Because of these changes, the details are a bit different for Explorer II but the concepts are almost exactly the same.  Oh, and the maps weren't contained in the Hummingbird chip, but rather were on the processor board, built with standard SRAMS and PALs.

  
I just dashed this off.  I hope it isn't too cryptic.
    

Not at all. Exactly what I wanted to know, and some extra background 
information. Thank you.
Great! 
	-Steve
--------------020402070808060700070307-- From nyef@sc.am Thu May 20 09:48:01 2004 From: nyef@sc.am (nyef@sc.am) Date: Thu, 20 May 2004 03:48:01 -0500 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: <200405201616.i4KGGRN10765@mwave.heeltoe.com> References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> Message-ID: <20040520084759.GA24272@sc.am> On Thu, May 20, 2004 at 12:16:27PM -0400, Brad Parker wrote: > > Hi, Hello. > Some dumb questions (which I think I sent before but seem to have gone > into the bit bucket) > > - is there a list of names which describes an Explorer I,II & cpu names, > i.e. raven, hummingbird, etc??? Not an explicit list, no. Of the ones you explicitly asked about, Raven is the processor from the Explorer I and Hummingbird is the processor used in the Explorer II and the microExplorer. > - is an Explorer I essentially a CADR? Will an E1 run CADR microcode? > (I thought I read that it would/could) No, but I hear tell that it is essentially an LMI Lambda (microcode compatible, at least). > - I was fooling around with exploiter and got it past the previous disk > problem but crashed in to needing support for lexical closures. I > thought "I'll just look at the microcode". But, ahem, no microcode > source. The SSDN2 is good but no substitute for definative microcode. If this is at any point past the scheduler initialization you should realize that the stack-group switch doesn't work properly, especially in regards to the binding stack (specpdl). > How come there is no source to the E1 or E2 microcode? Can that nice person > from TI on the list dig it up, even older versions? The nice person from TI with the microcode listing has, if memory serves, the VM1 (pre-release-3) sources in hardcopy only. > Seems obvious, so there must be good historical reasons - please pass > the clues :-) Yeah, the reason we don't have the microcode, the microcode assembler, or the genasys utility is that nobody could find a copy. Gone. All gone. > -brad --Alastair From pf@ti.com Thu May 20 19:52:40 2004 From: pf@ti.com (Paul Fuqua) Date: Thu, 20 May 2004 13:52:40 -0500 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: Msg of May 20, 2004 03:48:01 (-0500) from nyef@sc.am References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> <20040520084759.GA24272@sc.am> Message-ID: <16556.65144.499575.362611@glazed04.dal.design.ti.com> Date: Thu, 20 May 2004 03:48:01 -0500 From: nyef@sc.am Not an explicit list, no. Of the ones you explicitly asked about, Raven is the processor from the Explorer I and Hummingbird is the processor used in the Explorer II and the microExplorer. Projects were being named after birds at that time. Raven was the original Explorer codename. Somewhere along the line it was semi-officially renamed Chaparral, that being a more "Southwestern" bird; some folks have little Chaparral pins from those days. Then marketing got it and named it Explorer. Microcoders are stubborn people, so files and features were named Raven (ravsym, #+raven) to the end. Hummingbird was the Explorer 2 processor because it was small and moved very fast (relatively speaking). It was also part of the DARPA Compact Lisp Machine project so sometimes there are references to that. No, but I hear tell that it is essentially an LMI Lambda (microcode compatible, at least). My understanding was that the original LMI Lambdas were indeed CADRs. The later Lambda/E model was a rebadged Explorer. I think we had LMI microcode running on Explorers -- certainly LMI did -- but I don't know what degree of porting was required. Yeah, the reason we don't have the microcode, the microcode assembler, or the genasys utility is that nobody could find a copy. Gone. All gone. Yep, nobody had the foresight to snapshot it before the division where the machine holding the master source lived was sold off. There are persistent rumors that somebody has it on a brick or tape in a box somewhere, but they haven't panned out yet. What we do have are some paper copies of VM1 microcode source, and some Explorer 1 microcode development tools, and scattered fragments of other stuff. I thought Genasys was part of the regular system source, but then that just builds the load band, it's not part of the microcode system. I did disassemble enough of the Explorer 1 microcode to answer some questions, but I'm in a delicate position as a TI employee using TI tools to fiddle with TI intellectual property, so it isn't public yet. Paul Fuqua Texas Instruments, Dallas, Texas pf@ti.com From nyef@sc.am Thu May 20 10:49:58 2004 From: nyef@sc.am (nyef@sc.am) Date: Thu, 20 May 2004 04:49:58 -0500 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: <16556.65144.499575.362611@glazed04.dal.design.ti.com> References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> <20040520084759.GA24272@sc.am> <16556.65144.499575.362611@glazed04.dal.design.ti.com> Message-ID: <20040520094958.GA1134@sc.am> On Thu, May 20, 2004 at 01:52:40PM -0500, Paul Fuqua wrote: > > Projects were being named after birds at that time. Raven was the > original Explorer codename. Somewhere along the line it was > semi-officially renamed Chaparral, that being a more "Southwestern" > bird; some folks have little Chaparral pins from those days. Then > marketing got it and named it Explorer. Well, that explains the process-scheduler-for-chaparral thing. I had originally written that off as being a custom hack for some specific person that ended up in the main system, not realizing that it was a bird name, but this makes more sense. > What we do have are some paper copies of VM1 microcode source, and > some Explorer 1 microcode development tools, and scattered fragments > of other stuff. I thought Genasys was part of the regular system > source, but then that just builds the load band, it's not part of the > microcode system. Hey, while I've got your attention, do you know anything about the way that unmapped memory accesses on Raven update the memory maps? One of the VMA tests is checking for it fairly explicitly, but it's not doing it with sufficient coverage for me to figure out what's going on, and the only other reference I've found is a couple figures in SSDN2 which provide descriptions of the various bit positions that need updating (the last-access-mapped bit in the level-1 map and the TM0 and TM1 bits in the level-2 map). As near as I can tell, the TM0 and TM1 bits are always going to be 0 for a mapped access (since it's wordwise), but beyond that I'm kindof at a loss. --Alastair From mark@buttery.org Thu May 20 20:27:58 2004 From: mark@buttery.org (Mark J. Dulcey) Date: Thu, 20 May 2004 15:27:58 -0400 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: <16556.65144.499575.362611@glazed04.dal.design.ti.com> References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> <20040520084759.GA24272@sc.am> <16556.65144.499575.362611@glazed04.dal.design.ti.com> Message-ID: <40AD06BE.3040803@buttery.org> Paul Fuqua wrote: > My understanding was that the original LMI Lambdas were indeed > CADRs. The later Lambda/E model was a rebadged Explorer. I think we > had LMI microcode running on Explorers -- certainly LMI did -- but I > don't know what degree of porting was required. The LMI Lambda evolved from the CADR, but it was not identical. It used a 64-bit microword word (longer than the CADR, which was either 48 or 56 bits; I don't remember), and supported 64K words of microcode instead of the 16K supported by the CADR. The larger microcode store was meant to allow use of the microcompiler (a compiler that turned Lisp into microcode, with a lot of data type restrictions), but I don't think anybody ever did much with that. The other novel feature of the Lambda was the macro IR decode RAM (a 64K-word RAM with an entry for every possible 16-bit instruction pattern!) -- a brute force solution to the problem of decoding the rather baroque LM instruction set. > Yeah, the reason we don't have the microcode, the microcode assembler, > or the genasys utility is that nobody could find a copy. Gone. All gone. It's a pity that nobody seems to have turned up a working Lambda. Those routinely shipped with full system sources, all the way down to the microcode, though some customers didn't bother with the full sources because they didn't have enough disk space for them. From brad@heeltoe.com Thu May 20 20:42:51 2004 From: brad@heeltoe.com (Brad Parker) Date: Thu, 20 May 2004 15:42:51 -0400 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: Message from "Mark J. Dulcey" of "Thu, 20 May 2004 15:27:58 EDT." <40AD06BE.3040803@buttery.org> Message-ID: <200405201942.i4KJgpJ13017@mwave.heeltoe.com> "Mark J. Dulcey" wrote: > >It's a pity that nobody seems to have turned up a working Lambda. Those >routinely shipped with full system sources, all the way down to the >microcode, though some customers didn't bother with the full sources >because they didn't have enough disk space for them. I'm tracking down some alleged "lambda sources" on 9-track. We'll see what's on the tape (if if they can even be read, he said, crossing his fingers). I'll certainly speak up if the tapes yield something. It will be some time in June. I've also found someone who claims to have some T300 platters from a CADR and "wants them read". Al Kossow has the only CADR I know of which might be able to read them - another adventure... I've been searching high and low for "CADR sources". No luck yet. (never thought of looking for a *working* lambda :-) good idea!) -brad From nyef@sc.am Thu May 20 09:48:01 2004 From: nyef@sc.am (nyef@sc.am) Date: Thu, 20 May 2004 03:48:01 -0500 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: <200405201616.i4KGGRN10765@mwave.heeltoe.com> References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> Message-ID: <20040520084759.GA24272@sc.am> On Thu, May 20, 2004 at 12:16:27PM -0400, Brad Parker wrote: > > Hi, Hello. > Some dumb questions (which I think I sent before but seem to have gone > into the bit bucket) > > - is there a list of names which describes an Explorer I,II & cpu names, > i.e. raven, hummingbird, etc??? Not an explicit list, no. Of the ones you explicitly asked about, Raven is the processor from the Explorer I and Hummingbird is the processor used in the Explorer II and the microExplorer. > - is an Explorer I essentially a CADR? Will an E1 run CADR microcode? > (I thought I read that it would/could) No, but I hear tell that it is essentially an LMI Lambda (microcode compatible, at least). > - I was fooling around with exploiter and got it past the previous disk > problem but crashed in to needing support for lexical closures. I > thought "I'll just look at the microcode". But, ahem, no microcode > source. The SSDN2 is good but no substitute for definative microcode. If this is at any point past the scheduler initialization you should realize that the stack-group switch doesn't work properly, especially in regards to the binding stack (specpdl). > How come there is no source to the E1 or E2 microcode? Can that nice person > from TI on the list dig it up, even older versions? The nice person from TI with the microcode listing has, if memory serves, the VM1 (pre-release-3) sources in hardcopy only. > Seems obvious, so there must be good historical reasons - please pass > the clues :-) Yeah, the reason we don't have the microcode, the microcode assembler, or the genasys utility is that nobody could find a copy. Gone. All gone. > -brad --Alastair From pf@ti.com Thu May 20 19:52:40 2004 From: pf@ti.com (Paul Fuqua) Date: Thu, 20 May 2004 13:52:40 -0500 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: Msg of May 20, 2004 03:48:01 (-0500) from nyef@sc.am References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> <20040520084759.GA24272@sc.am> Message-ID: <16556.65144.499575.362611@glazed04.dal.design.ti.com> Date: Thu, 20 May 2004 03:48:01 -0500 From: nyef@sc.am Not an explicit list, no. Of the ones you explicitly asked about, Raven is the processor from the Explorer I and Hummingbird is the processor used in the Explorer II and the microExplorer. Projects were being named after birds at that time. Raven was the original Explorer codename. Somewhere along the line it was semi-officially renamed Chaparral, that being a more "Southwestern" bird; some folks have little Chaparral pins from those days. Then marketing got it and named it Explorer. Microcoders are stubborn people, so files and features were named Raven (ravsym, #+raven) to the end. Hummingbird was the Explorer 2 processor because it was small and moved very fast (relatively speaking). It was also part of the DARPA Compact Lisp Machine project so sometimes there are references to that. No, but I hear tell that it is essentially an LMI Lambda (microcode compatible, at least). My understanding was that the original LMI Lambdas were indeed CADRs. The later Lambda/E model was a rebadged Explorer. I think we had LMI microcode running on Explorers -- certainly LMI did -- but I don't know what degree of porting was required. Yeah, the reason we don't have the microcode, the microcode assembler, or the genasys utility is that nobody could find a copy. Gone. All gone. Yep, nobody had the foresight to snapshot it before the division where the machine holding the master source lived was sold off. There are persistent rumors that somebody has it on a brick or tape in a box somewhere, but they haven't panned out yet. What we do have are some paper copies of VM1 microcode source, and some Explorer 1 microcode development tools, and scattered fragments of other stuff. I thought Genasys was part of the regular system source, but then that just builds the load band, it's not part of the microcode system. I did disassemble enough of the Explorer 1 microcode to answer some questions, but I'm in a delicate position as a TI employee using TI tools to fiddle with TI intellectual property, so it isn't public yet. Paul Fuqua Texas Instruments, Dallas, Texas pf@ti.com From nyef@sc.am Thu May 20 10:49:58 2004 From: nyef@sc.am (nyef@sc.am) Date: Thu, 20 May 2004 04:49:58 -0500 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: <16556.65144.499575.362611@glazed04.dal.design.ti.com> References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> <20040520084759.GA24272@sc.am> <16556.65144.499575.362611@glazed04.dal.design.ti.com> Message-ID: <20040520094958.GA1134@sc.am> On Thu, May 20, 2004 at 01:52:40PM -0500, Paul Fuqua wrote: > > Projects were being named after birds at that time. Raven was the > original Explorer codename. Somewhere along the line it was > semi-officially renamed Chaparral, that being a more "Southwestern" > bird; some folks have little Chaparral pins from those days. Then > marketing got it and named it Explorer. Well, that explains the process-scheduler-for-chaparral thing. I had originally written that off as being a custom hack for some specific person that ended up in the main system, not realizing that it was a bird name, but this makes more sense. > What we do have are some paper copies of VM1 microcode source, and > some Explorer 1 microcode development tools, and scattered fragments > of other stuff. I thought Genasys was part of the regular system > source, but then that just builds the load band, it's not part of the > microcode system. Hey, while I've got your attention, do you know anything about the way that unmapped memory accesses on Raven update the memory maps? One of the VMA tests is checking for it fairly explicitly, but it's not doing it with sufficient coverage for me to figure out what's going on, and the only other reference I've found is a couple figures in SSDN2 which provide descriptions of the various bit positions that need updating (the last-access-mapped bit in the level-1 map and the TM0 and TM1 bits in the level-2 map). As near as I can tell, the TM0 and TM1 bits are always going to be 0 for a mapped access (since it's wordwise), but beyond that I'm kindof at a loss. --Alastair From mark@buttery.org Thu May 20 20:27:58 2004 From: mark@buttery.org (Mark J. Dulcey) Date: Thu, 20 May 2004 15:27:58 -0400 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: <16556.65144.499575.362611@glazed04.dal.design.ti.com> References: <20040520060749.GA17487@sc.am> <200405201616.i4KGGRN10765@mwave.heeltoe.com> <20040520084759.GA24272@sc.am> <16556.65144.499575.362611@glazed04.dal.design.ti.com> Message-ID: <40AD06BE.3040803@buttery.org> Paul Fuqua wrote: > My understanding was that the original LMI Lambdas were indeed > CADRs. The later Lambda/E model was a rebadged Explorer. I think we > had LMI microcode running on Explorers -- certainly LMI did -- but I > don't know what degree of porting was required. The LMI Lambda evolved from the CADR, but it was not identical. It used a 64-bit microword word (longer than the CADR, which was either 48 or 56 bits; I don't remember), and supported 64K words of microcode instead of the 16K supported by the CADR. The larger microcode store was meant to allow use of the microcompiler (a compiler that turned Lisp into microcode, with a lot of data type restrictions), but I don't think anybody ever did much with that. The other novel feature of the Lambda was the macro IR decode RAM (a 64K-word RAM with an entry for every possible 16-bit instruction pattern!) -- a brute force solution to the problem of decoding the rather baroque LM instruction set. > Yeah, the reason we don't have the microcode, the microcode assembler, > or the genasys utility is that nobody could find a copy. Gone. All gone. It's a pity that nobody seems to have turned up a working Lambda. Those routinely shipped with full system sources, all the way down to the microcode, though some customers didn't bother with the full sources because they didn't have enough disk space for them. From brad@heeltoe.com Thu May 20 20:42:51 2004 From: brad@heeltoe.com (Brad Parker) Date: Thu, 20 May 2004 15:42:51 -0400 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: Message from "Mark J. Dulcey" of "Thu, 20 May 2004 15:27:58 EDT." <40AD06BE.3040803@buttery.org> Message-ID: <200405201942.i4KJgpJ13017@mwave.heeltoe.com> "Mark J. Dulcey" wrote: > >It's a pity that nobody seems to have turned up a working Lambda. Those >routinely shipped with full system sources, all the way down to the >microcode, though some customers didn't bother with the full sources >because they didn't have enough disk space for them. I'm tracking down some alleged "lambda sources" on 9-track. We'll see what's on the tape (if if they can even be read, he said, crossing his fingers). I'll certainly speak up if the tapes yield something. It will be some time in June. I've also found someone who claims to have some T300 platters from a CADR and "wants them read". Al Kossow has the only CADR I know of which might be able to read them - another adventure... I've been searching high and low for "CADR sources". No luck yet. (never thought of looking for a *working* lambda :-) good idea!) -brad From mark@buttery.org Thu May 20 21:35:54 2004 From: mark@buttery.org (Mark J. Dulcey) Date: Thu, 20 May 2004 16:35:54 -0400 Subject: [LMH] Re: [LMH]Nevermore (well, exploiter actually) In-Reply-To: <200405201942.i4KJgpJ13017@mwave.heeltoe.com> References: <200405201942.i4KJgpJ13017@mwave.heeltoe.com> Message-ID: <40AD16AA.40105@buttery.org> Brad Parker wrote: > I've also found someone who claims to have some T300 platters from a > CADR and "wants them read". Al Kossow has the only CADR I know of which > might be able to read them - another adventure... Why would you need a CADR to read them? Any machine with a working T300 drive (admittedly a challenge to find in itself) should be able to get data from the platters. CADRs didn't really have a filesystem; the loadable "bands", or system images, were just stored in big contiguous blocks on the hard disk. (As an analogy, imagine a PC where the partition table is the only mechanism for carving up the hard disk.) Actually, there were two LispM-native file systems developed at MIT; LMFS, written by people who later went to Symbolics, and FC, which I think was written by Richard Stallman. But the majority of CADRs didn't run either of them; files other than the bootable images were normally stored on other systems and loaded over Ethernet. The LispM knew about ITS (the Incompatible Timesharing System, a locally developed OS), Tenex, TOPS-20/Twenex, Unix, and Multics file syntax, as well as the two LispM-native file systems, and could open and close files over a network from any of them. So a CADR may not have source code on its hard disk. At MIT, where they were developed, the sources were kept on a central TOPS-20 server, not on the CADRs themselves. At LMI, the Lambdas also got their source code from a central server, but the systems prepared for customers usually had a source code partition. That partition was handled by the 68000 that acted as a system manager and I/O processor, not by the LispM itself; LMI didn't use a LispM-native file system on the Lambda. They DID use LMFS on the CADRs they manufactured; those are the most likely CADRs to have source code on their hard disks. I don't think Symbolics supplied full source code with the LM-2 CADR clones they built.