From brad@heeltoe.com Mon Oct 17 16:05:37 2005 From: brad@heeltoe.com (Brad Parker) Date: Mon, 17 Oct 2005 11:05:37 -0400 Subject: [Lispm-hackers] test message Message-ID: <200510171505.j9HF5buf024591@mwave.heeltoe.com> test message From brad@heeltoe.com Mon Oct 17 22:21:45 2005 From: brad@heeltoe.com (Brad Parker) Date: Mon, 17 Oct 2005 17:21:45 -0400 Subject: [LMH] test Message-ID: <200510172121.j9HLLj2i025356@mwave.heeltoe.com> test From brad@heeltoe.com Tue Oct 18 00:41:36 2005 From: brad@heeltoe.com (Brad Parker) Date: Mon, 17 Oct 2005 19:41:36 -0400 Subject: [LMH] Re: [LispM] Nevermore release In-Reply-To: Your message of "Mon, 17 Oct 2005 20:28:01 BST." <20051017192801.7E11C18734@tech.vm.bytemark.co.uk> Message-ID: <200510172341.j9HNfaDW002973@mwave.heeltoe.com> >nyef@lisphacker.com wrote: > >Let's see... Menu, disk A, Diagnostic, disk C, partition B, cpu tests, >selected test menu, dispatch test. That seems about right, except that I >only use one disk image on which I patched the partition table to make the >diagnostics available (a single-bit change). I wrote a simple C program to dump the parition table and allow you to "mark" the parition table with the diag bit. I'll put it up on the web tomorrow. >SSDN2, section A describes, among other things, the volume label and >partition table layouts. yup - it had everything I needed. -brad From ipmonger@delamancha.org Tue Oct 18 06:16:56 2005 From: ipmonger@delamancha.org (Jon Allen Boone) Date: Tue, 18 Oct 2005 01:16:56 -0400 Subject: [LMH] Re: subscribe In-Reply-To: <0374FFD2-853C-4B46-A12C-4A4A9B37574F@delamancha.org> References: <0374FFD2-853C-4B46-A12C-4A4A9B37574F@delamancha.org> Message-ID: <29F76517-DCF8-4C0C-8FB8-469D6F33B592@delamancha.org> Sorry for this bogosity. --jon From water@tunes.org Tue Oct 18 06:59:27 2005 From: water@tunes.org (Brian Rice) Date: Mon, 17 Oct 2005 22:59:27 -0700 Subject: [LMH] Re: [LispM] LMH list back up In-Reply-To: <200510172118.j9HLIPeb025089@mwave.heeltoe.com> References: <200510172118.j9HLIPeb025089@mwave.heeltoe.com> Message-ID: I disagree. Keep it here, as there's little else left to do with lisp machines. On Oct 17, 2005, at 2:18 PM, Brad Parker wrote: > > Hi, > > There has been growing interest in the various lisp machine emulation > projects, so I decided to revive the old "lispm-hackers" list. > > The mailing list is "lispm-hackers@mail.unlambda.com" (although, I > think > lispm-hackers@unlambda.com should work also). > > The signup page is at > > http://www.unlambda.com/mailman/listinfo/lispm-hackers > > I never had a list of who was on the old list, unfortunately. > > I did find I had a mail archive from last summer and tried to add > to it > things I had in my inbox which were from the [LMH] list. So, the > archive should be reasonably complete. > > I don't like to hijack other peoples mailing lists, but it doesn't > seem > like the tunes lispm list was the right place to be for lisp machine > emulation projects. As always, feel free to disagree... > > -brad > > _______________________________________________ > LispM mailing list > LispM@tunes.org > http://lists.tunes.org/mailman/listinfo/lispm > -- -Brian From brad@heeltoe.com Tue Oct 18 12:28:54 2005 From: brad@heeltoe.com (Brad Parker) Date: Tue, 18 Oct 2005 07:28:54 -0400 Subject: [LMH] nevermore diags Message-ID: <200510181128.j9IBSs8n030987@mwave.heeltoe.com> ok, I think I finally figured out how to run diags with nevermore. - I had to hack the partition table of my disk (c2-d0.dsk) to set the diag bit in the EXPT entry. (see ssdn2/sectA.txt) I wrote a simple C program to print the parition table and hack it with the "-m" option. http://www.unlambda.com/download/nevermore/epart.c - Each keyboard entry had to be made twice before continuing, i.e. (nevermore::sib-keyboard-stuff-keypress #\M) (nevermore::sib-keyboard-stuff-keypress #\M) I'm using a stock SBCL but I had to find "asdf.lisp" on the net and then compile it. Here's my simple startup (load "../clisp/asdf.fasl") (load "nevermore.asd") (asdf:operate 'asdf:load-op :nevermore) (in-package :nevermore) (setf *rom-file-path* #p"/home/brad/lispm/Meroko/proms/") (load-romfiles) (setf *nupi-scsi0-0-disk-file* #p"../../Meroko/X1-DISKS/c0-d0-hacked.dsk") (sib-init-character-recognizer) (sib-init-keypress-stuffer) (in-package :raven) (microengine-initialize) (microengine-step) (microengine-run-to -1) When it stops I enter the key twice and continue (i.e. hit "0"). It does halt at one point so I do (microengine-step) (microengine-run-to -1) which shows it's halting at 40, which is to be expected. I used the sequence "MADA" to get the diags loaded. And, I got tired of the huge screenshots and hacked this (defun sib-text-nonblankline (y) (dotimes (x 70) (if (not (eq (sib-recognize-character x y) #\ )) (return t)) nil)) (defun sib-text-short-screenshot () (let ((max (do ((y 60 (- y 1))) ((or (< y 0) (sib-text-nonblankline y)) y)))) (dotimes (y (1+ max)) (dotimes (x 70) (format t "~A" (sib-recognize-character x y))) (terpri)))) Now, if I could just figure out why the WCS parity is broken. Nevermore doesn't calculate it but Meroko does and it fails there also. -brad From dseagrav@lunar-tokyo.net Wed Oct 19 21:28:27 2005 From: dseagrav@lunar-tokyo.net (Daniel Seagraves) Date: Wed, 19 Oct 2005 15:28:27 -0500 (CDT) Subject: [LMH] nevermore diags In-Reply-To: <200510181128.j9IBSs8n030987@mwave.heeltoe.com> References: <200510181128.j9IBSs8n030987@mwave.heeltoe.com> Message-ID: On Tue, 18 Oct 2005, Brad Parker wrote: > Now, if I could just figure out why the WCS parity is broken. Nevermore > doesn't calculate it but Meroko does and it fails there also. My ALU implementation is broken, and may be affecting this. I've been trying to figure out how it's supposed to work. The ALU broken-ness seems to be affecting the T-memory test (at least) - That's why I am seeing references to Condition 17. I don't understand how it's broken yet. I commited a few attempts at fixing it to svn (Other bad stuff was going on, like subtraction wouldn't roll negative and such) but it hasn't changed any of the test results yet. I was able to make the VMA test error count change by messing with the ALU, so I think my wierd VMA fault stuff is an ALU fault as well. From brad@heeltoe.com Mon Oct 17 16:05:37 2005 From: brad@heeltoe.com (Brad Parker) Date: Mon, 17 Oct 2005 11:05:37 -0400 Subject: [Lispm-hackers] test message Message-ID: <200510171505.j9HF5buf024591@mwave.heeltoe.com> test message From brad@heeltoe.com Mon Oct 17 22:21:45 2005 From: brad@heeltoe.com (Brad Parker) Date: Mon, 17 Oct 2005 17:21:45 -0400 Subject: [LMH] test Message-ID: <200510172121.j9HLLj2i025356@mwave.heeltoe.com> test From brad@heeltoe.com Tue Oct 18 00:41:36 2005 From: brad@heeltoe.com (Brad Parker) Date: Mon, 17 Oct 2005 19:41:36 -0400 Subject: [LMH] Re: [LispM] Nevermore release In-Reply-To: Your message of "Mon, 17 Oct 2005 20:28:01 BST." <20051017192801.7E11C18734@tech.vm.bytemark.co.uk> Message-ID: <200510172341.j9HNfaDW002973@mwave.heeltoe.com> >nyef@lisphacker.com wrote: > >Let's see... Menu, disk A, Diagnostic, disk C, partition B, cpu tests, >selected test menu, dispatch test. That seems about right, except that I >only use one disk image on which I patched the partition table to make the >diagnostics available (a single-bit change). I wrote a simple C program to dump the parition table and allow you to "mark" the parition table with the diag bit. I'll put it up on the web tomorrow. >SSDN2, section A describes, among other things, the volume label and >partition table layouts. yup - it had everything I needed. -brad From ipmonger@delamancha.org Tue Oct 18 06:16:56 2005 From: ipmonger@delamancha.org (Jon Allen Boone) Date: Tue, 18 Oct 2005 01:16:56 -0400 Subject: [LMH] Re: subscribe In-Reply-To: <0374FFD2-853C-4B46-A12C-4A4A9B37574F@delamancha.org> References: <0374FFD2-853C-4B46-A12C-4A4A9B37574F@delamancha.org> Message-ID: <29F76517-DCF8-4C0C-8FB8-469D6F33B592@delamancha.org> Sorry for this bogosity. --jon From water@tunes.org Tue Oct 18 06:59:27 2005 From: water@tunes.org (Brian Rice) Date: Mon, 17 Oct 2005 22:59:27 -0700 Subject: [LMH] Re: [LispM] LMH list back up In-Reply-To: <200510172118.j9HLIPeb025089@mwave.heeltoe.com> References: <200510172118.j9HLIPeb025089@mwave.heeltoe.com> Message-ID: I disagree. Keep it here, as there's little else left to do with lisp machines. On Oct 17, 2005, at 2:18 PM, Brad Parker wrote: > > Hi, > > There has been growing interest in the various lisp machine emulation > projects, so I decided to revive the old "lispm-hackers" list. > > The mailing list is "lispm-hackers@mail.unlambda.com" (although, I > think > lispm-hackers@unlambda.com should work also). > > The signup page is at > > http://www.unlambda.com/mailman/listinfo/lispm-hackers > > I never had a list of who was on the old list, unfortunately. > > I did find I had a mail archive from last summer and tried to add > to it > things I had in my inbox which were from the [LMH] list. So, the > archive should be reasonably complete. > > I don't like to hijack other peoples mailing lists, but it doesn't > seem > like the tunes lispm list was the right place to be for lisp machine > emulation projects. As always, feel free to disagree... > > -brad > > _______________________________________________ > LispM mailing list > LispM@tunes.org > http://lists.tunes.org/mailman/listinfo/lispm > -- -Brian From brad@heeltoe.com Tue Oct 18 12:28:54 2005 From: brad@heeltoe.com (Brad Parker) Date: Tue, 18 Oct 2005 07:28:54 -0400 Subject: [LMH] nevermore diags Message-ID: <200510181128.j9IBSs8n030987@mwave.heeltoe.com> ok, I think I finally figured out how to run diags with nevermore. - I had to hack the partition table of my disk (c2-d0.dsk) to set the diag bit in the EXPT entry. (see ssdn2/sectA.txt) I wrote a simple C program to print the parition table and hack it with the "-m" option. http://www.unlambda.com/download/nevermore/epart.c - Each keyboard entry had to be made twice before continuing, i.e. (nevermore::sib-keyboard-stuff-keypress #\M) (nevermore::sib-keyboard-stuff-keypress #\M) I'm using a stock SBCL but I had to find "asdf.lisp" on the net and then compile it. Here's my simple startup (load "../clisp/asdf.fasl") (load "nevermore.asd") (asdf:operate 'asdf:load-op :nevermore) (in-package :nevermore) (setf *rom-file-path* #p"/home/brad/lispm/Meroko/proms/") (load-romfiles) (setf *nupi-scsi0-0-disk-file* #p"../../Meroko/X1-DISKS/c0-d0-hacked.dsk") (sib-init-character-recognizer) (sib-init-keypress-stuffer) (in-package :raven) (microengine-initialize) (microengine-step) (microengine-run-to -1) When it stops I enter the key twice and continue (i.e. hit "0"). It does halt at one point so I do (microengine-step) (microengine-run-to -1) which shows it's halting at 40, which is to be expected. I used the sequence "MADA" to get the diags loaded. And, I got tired of the huge screenshots and hacked this (defun sib-text-nonblankline (y) (dotimes (x 70) (if (not (eq (sib-recognize-character x y) #\ )) (return t)) nil)) (defun sib-text-short-screenshot () (let ((max (do ((y 60 (- y 1))) ((or (< y 0) (sib-text-nonblankline y)) y)))) (dotimes (y (1+ max)) (dotimes (x 70) (format t "~A" (sib-recognize-character x y))) (terpri)))) Now, if I could just figure out why the WCS parity is broken. Nevermore doesn't calculate it but Meroko does and it fails there also. -brad From dseagrav@lunar-tokyo.net Wed Oct 19 21:28:27 2005 From: dseagrav@lunar-tokyo.net (Daniel Seagraves) Date: Wed, 19 Oct 2005 15:28:27 -0500 (CDT) Subject: [LMH] nevermore diags In-Reply-To: <200510181128.j9IBSs8n030987@mwave.heeltoe.com> References: <200510181128.j9IBSs8n030987@mwave.heeltoe.com> Message-ID: On Tue, 18 Oct 2005, Brad Parker wrote: > Now, if I could just figure out why the WCS parity is broken. Nevermore > doesn't calculate it but Meroko does and it fails there also. My ALU implementation is broken, and may be affecting this. I've been trying to figure out how it's supposed to work. The ALU broken-ness seems to be affecting the T-memory test (at least) - That's why I am seeing references to Condition 17. I don't understand how it's broken yet. I commited a few attempts at fixing it to svn (Other bad stuff was going on, like subtraction wouldn't roll negative and such) but it hasn't changed any of the test results yet. I was able to make the VMA test error count change by messing with the ALU, so I think my wierd VMA fault stuff is an ALU fault as well. From brad@heeltoe.com Fri Oct 21 12:14:16 2005 From: brad@heeltoe.com (Brad Parker) Date: Fri, 21 Oct 2005 07:14:16 -0400 Subject: [LMH] e1 tag diag Message-ID: <200510211114.j9LBEGjM023704@mwave.heeltoe.com> Hi - Both meroko and nevermore pass the E1 tag diag (#7) but both report a bad condition code for condition 17. I thought it was an ALU bug in meroko but I noticed nevermore does that same thing. I looked at the microcode and I am wondering if it's a bug int he microcode which no one noticed. Below is a little history trace when the problem occurs. The code at 10131 and 10132 make sense. It sets the tag memory address in the read at 10132. The code at 10134 & 10135 does not make sense. It does the imod-low setting with (L=5 C=10) but then it does an alu instruction. This doesn't seem right at all. The (L=5 C=10) field is for a jump. I suspect that the diag passed on the real hardware and no one ever noticed this bug. [this is more for Daniel & Alastair and anyone else who's hacking on meroko and nevermore] -brad CONDITION-17-USED last imod hi 318 lo 3c00 [10135] (M-31) SETA OBus-Normal IF 17 ---- 9: 002000000000000016040 [9579] JUMP 0 IF ALWAYS 10: 002003545422554006040 [9587] JUMP 9580 IF NOT-EQ 11: 100043500140072616310 [9580] (M-29) ADD OBus-Normal IF ALWAYS 12: 000000056640002616050 [9581] (M-1) SETA OBus-Normal IF ALWAYS 13: 102040000022566016000 [9582] Jump-XCT-Next 9590 IF ALWAYS 14: 100040104146000616310 [9583] (M-0 MF-MD) ADD OBus-Normal IF ALWAYS 15: 000000045600002616050 [9590] (M-1) SETA OBus-Normal IF ALWAYS 0: 001000100101401416722 [9591] (M-0 MF-IMod-Low) Deposit-Byte (L=14 C=18) IF ALWAYS 1: 002000000000000016040 [9592] JUMP 0 IF ALWAYS 2: 001003500100012416274 [10129] (M-5) Load-Byte (L=5 C=28) IF ALWAYS 3: 101040500100013416271 [10130] (M-5) Deposit-Byte (L=5 C=25) IF ALWAYS 4: 001003500101401416252 [10131] (M-0 MF-IMod-Low) Deposit-Byte (L=5 C=10) IF ALWAYS 5: 102040500022571040000 [10132] Jump-XCT-Next 9593 TM-Rd-0 (Bit 0 ) 6: 000000004000076616050 [10133] (M-31) SETA OBus-Normal IF ALWAYS 7: 001003500101401416252 [10134] (M-0 MF-IMod-Low) Deposit-Byte (L=5 C=10) IF ALWAYS 8: 000000004000076616050 [10135] (M-31) SETA OBus-Normal IF ALWAYS 37777777777 36000 36xxx 000000004000076616050 [10135] (M-31) SETA OBus-Normal IF ALWAYS From dseagrav@lunar-tokyo.net Fri Oct 21 12:44:50 2005 From: dseagrav@lunar-tokyo.net (Daniel Seagraves) Date: Fri, 21 Oct 2005 06:44:50 -0500 (CDT) Subject: [LMH] e1 tag diag In-Reply-To: <200510211114.j9LBEGjM023704@mwave.heeltoe.com> References: <200510211114.j9LBEGjM023704@mwave.heeltoe.com> Message-ID: On Fri, 21 Oct 2005, Brad Parker wrote: > Both meroko and nevermore pass the E1 tag diag (#7) but both report a > bad condition code for condition 17. I thought it was an ALU bug > in meroko but I noticed nevermore does that same thing. Aha, OK. I thought Nevermore DIDN'T do this! That's why I was so convinced it was a broken ALU implementation. From nyef@lisphacker.com Fri Oct 21 15:14:27 2005 From: nyef@lisphacker.com (nyef@lisphacker.com) Date: Fri, 21 Oct 2005 15:14:27 +0100 Subject: [LMH] e1 tag diag In-Reply-To: <200510211114.j9LBEGjM023704@mwave.heeltoe.com> References: <200510211114.j9LBEGjM023704@mwave.heeltoe.com> Message-ID: <20051021141427.900441877C@tech.vm.bytemark.co.uk> Brad Parker writes: > Hi - > > Both meroko and nevermore pass the E1 tag diag (#7) but both report a > bad condition code for condition 17. I thought it was an ALU bug > in meroko but I noticed nevermore does that same thing. > > I looked at the microcode and I am wondering if it's a bug int he microcode > which no one noticed. > > Below is a little history trace when the problem occurs. The code at > 10131 and 10132 make sense. It sets the tag memory address in the > read at 10132. > > The code at 10134 & 10135 does not make sense. It does the imod-low setting > with (L=5 C=10) but then it does an alu instruction. This doesn't seem > right at all. The (L=5 C=10) field is for a jump. The condition field (BYTE-FIELD 5 10) is live on all instructions other than DISPATCH instructions. But you're right that it doesn't make sense. There's no direct reference to this code, but my disassembly shows: L-10129 ((M-5) LDB (BYTE-FIELD 5 28) M-29 M-2) L-10130 ((M-5) DPB (BYTE-FIELD 5 25) M-5 M-2) L-10131 ((M-0 IMOD-LOW) DPB (BYTE-FIELD 5 10) M-29 M-2) L-10132 (JUMP-XCT-NEXT L-9593 IF-IN-CLASS M-5) L-10133 ((M-31) SETA A-64) L-10134 ((M-0 IMOD-LOW) DPB (BYTE-FIELD 5 10) M-29 M-2) L-10135 ((M-31) SETA A-64) L-10136 (JUMP-XCT-NEXT L-9593) L-10137 ((M-31) SETZ) It would almost make sense if there were an ABJ on L-10135, but there isn't. And the next bit of code is L-10138, which doesn't have a direct reference in the code, but looks like it does a write to tag classifier memory. I do see both addresses in A-memory (at #x27e and #x274), though. I think that passing this test was a no-brainer for both of us, as we'd have put all the machinery in back at the beginning (L-348 to L-364 in the STBM PROM contains a loop that tests the tag classifier memory and this has to pass long before anything appears in the SIB framebuffer). > I suspect that the diag passed on the real hardware and no one ever noticed > this bug. That may well be the case. If we get Lisp to run, we'll probably just muffle the diagnostics on that condition. > [this is more for Daniel & Alastair and anyone else who's hacking on meroko > and nevermore] > > -brad --Alastair Bridgewater From dseagrav@lunar-tokyo.net Fri Oct 21 15:57:32 2005 From: dseagrav@lunar-tokyo.net (Daniel Seagraves) Date: Fri, 21 Oct 2005 09:57:32 -0500 (CDT) Subject: [LMH] I dumped out EXPT... In-Reply-To: <20051021141427.900441877C@tech.vm.bytemark.co.uk> References: <200510211114.j9LBEGjM023704@mwave.heeltoe.com> <20051021141427.900441877C@tech.vm.bytemark.co.uk> Message-ID: There's a dump and disassembly of EXPT at http://www.lunar-tokyo.net/~dseagrav/EXPT.txt It's just a dump of WCS when EXPT is loaded. From nyef@lisphacker.com Fri Oct 21 16:52:52 2005 From: nyef@lisphacker.com (nyef@lisphacker.com) Date: Fri, 21 Oct 2005 16:52:52 +0100 Subject: [LMH] I dumped out EXPT... In-Reply-To: References: <200510211114.j9LBEGjM023704@mwave.heeltoe.com> <20051021141427.900441877C@tech.vm.bytemark.co.uk> Message-ID: <20051021155252.409F71877C@tech.vm.bytemark.co.uk> Daniel Seagraves writes: > There's a dump and disassembly of EXPT at > http://www.lunar-tokyo.net/~dseagrav/EXPT.txt > > It's just a dump of WCS when EXPT is loaded. I have a similar file in my private collection, but I obviously used a different disassembler. I have since found that the disassembly isn't complete without a dump of A-Memory as well. There are a number of jump tables with indices in A-Memory, for example. Oh, and some parts of WCS actually contain ASCII data. Have a look at L-1134 through L-1165 and L-13590 through L-15058. Runs about 6 characters to an I-Memory word (the top byte basically contains parity information, strings are NUL-terminated). --Alastair Bridgewater From dseagrav@lunar-tokyo.net Fri Oct 21 16:51:33 2005 From: dseagrav@lunar-tokyo.net (Daniel Seagraves) Date: Fri, 21 Oct 2005 10:51:33 -0500 (CDT) Subject: [LMH] I dumped out EXPT... In-Reply-To: <20051021155252.409F71877C@tech.vm.bytemark.co.uk> References: <200510211114.j9LBEGjM023704@mwave.heeltoe.com> <20051021141427.900441877C@tech.vm.bytemark.co.uk> <20051021155252.409F71877C@tech.vm.bytemark.co.uk> Message-ID: On Fri, 21 Oct 2005 nyef@lisphacker.com wrote: > I have a similar file in my private collection, but I obviously used a > different disassembler. I have since found that the disassembly isn't > complete without a dump of A-Memory as well. There are a number of jump > tables with indices in A-Memory, for example. Done, dump now includes A and M memory. > Oh, and some parts of WCS actually contain ASCII data. Have a look at L-1134 > through L-1165 and L-13590 through L-15058. Runs about 6 characters to an > I-Memory word (the top byte basically contains parity information, strings > are NUL-terminated). I suspected that. I'll have to make the disassembler smarter to handle that. From nyef@lisphacker.com Fri Oct 21 17:53:50 2005 From: nyef@lisphacker.com (nyef@lisphacker.com) Date: Fri, 21 Oct 2005 17:53:50 +0100 Subject: [LMH] I dumped out EXPT... In-Reply-To: References: <200510211114.j9LBEGjM023704@mwave.heeltoe.com> <20051021141427.900441877C@tech.vm.bytemark.co.uk> <20051021155252.409F71877C@tech.vm.bytemark.co.uk> Message-ID: <20051021165350.539BA1877C@tech.vm.bytemark.co.uk> Daniel Seagraves writes: > On Fri, 21 Oct 2005 nyef@lisphacker.com wrote: > >> I have a similar file in my private collection, but I obviously used a >> different disassembler. I have since found that the disassembly isn't >> complete without a dump of A-Memory as well. There are a number of jump >> tables with indices in A-Memory, for example. > > Done, dump now includes A and M memory. Some more information for you: The Diagnostic Engine Interpreter opcode interpreter (the bit that picks a handler based on the opcode value) is at L-682. This is basically the same code as in the STBM and probably BOOT. >> Oh, and some parts of WCS actually contain ASCII data. Have a look at L-1134 >> through L-1165 and L-13590 through L-15058. Runs about 6 characters to an >> I-Memory word (the top byte basically contains parity information, strings >> are NUL-terminated). > > I suspected that. I'll have to make the disassembler smarter to handle > that. I should probably see about souping up my disassembler. Mine can do symbol substitution for memory locations (in A-, M-, and I- memory), but it's a rather underused feature. I also have some code to re-disassemble a file to regenerate the disassembly based on new symbol table entries while leaving comments undisturbed. I should be able to rig that to operate on a region instead... --Alastair Bridgewater From dseagrav@lunar-tokyo.net Fri Oct 21 17:17:09 2005 From: dseagrav@lunar-tokyo.net (Daniel Seagraves) Date: Fri, 21 Oct 2005 11:17:09 -0500 (CDT) Subject: [LMH] I dumped out EXPT... In-Reply-To: <20051021165350.539BA1877C@tech.vm.bytemark.co.uk> References: <200510211114.j9LBEGjM023704@mwave.heeltoe.com> <20051021141427.900441877C@tech.vm.bytemark.co.uk> <20051021155252.409F71877C@tech.vm.bytemark.co.uk> <20051021165350.539BA1877C@tech.vm.bytemark.co.uk> Message-ID: On Fri, 21 Oct 2005 nyef@lisphacker.com wrote: > I should probably see about souping up my disassembler. Mine can do symbol > substitution for memory locations (in A-, M-, and I- memory), but it's a > rather underused feature. I also have some code to re-disassemble a file to > regenerate the disassembly based on new symbol table entries while leaving > comments undisturbed. I should be able to rig that to operate on a region > instead... Oh, is there symbol data here or did you get the symbol data from somewhere else? From nyef@lisphacker.com Fri Oct 21 20:46:27 2005 From: nyef@lisphacker.com (nyef@lisphacker.com) Date: Fri, 21 Oct 2005 20:46:27 +0100 Subject: [LMH] I dumped out EXPT... In-Reply-To: References: <200510211114.j9LBEGjM023704@mwave.heeltoe.com> <20051021141427.900441877C@tech.vm.bytemark.co.uk> <20051021155252.409F71877C@tech.vm.bytemark.co.uk> <20051021165350.539BA1877C@tech.vm.bytemark.co.uk> Message-ID: <20051021194627.A8B3A188E5@tech.vm.bytemark.co.uk> Daniel Seagraves writes: > On Fri, 21 Oct 2005 nyef@lisphacker.com wrote: > >> I should probably see about souping up my disassembler. Mine can do symbol >> substitution for memory locations (in A-, M-, and I- memory), but it's a >> rather underused feature. I also have some code to re-disassemble a file to >> regenerate the disassembly based on new symbol table entries while leaving >> comments undisturbed. I should be able to rig that to operate on a region >> instead... > > Oh, is there symbol data here or did you get the symbol data from > somewhere else? No, no. I can assign a symbol once I figure out what something does. M-ZEROS and M-ONES are obvious, and I can assign (M-CONSTANT 2) and such. Or mark L-18 as SELFTEST-ERROR, as seen in my STBM disassembly. I assign the symbol, either in the disassembly or in a separate symbol table file, and then run the disassembly through the reprocessor to produce a new disassembly with the updated symbol references. --Alastair Bridgewater From brad@heeltoe.com Sat Oct 22 23:48:57 2005 From: brad@heeltoe.com (Brad Parker) Date: Sat, 22 Oct 2005 18:48:57 -0400 Subject: [LMH] E1 MCR interrupt bits? Message-ID: <200510222248.j9MMmvG4023442@mwave.heeltoe.com> Can someone explain know the interrupt scheme on the E1 works? I assume the e00000-e0003e register space on the cpu is for interrupt testing only, i.e. nubus cards don't write to this space, only the diags do. Do the NUPI and SIB assert a nubus hardware interrupt? Does the cpu hardware see than and place it in it's list of pending interrupts? I see that the cpu manages pending interrupts on a priority basis from 15-0 with 0 being the highest. I don't quite get how the microcode resets the pending interrupts or how the are asserted in the normal case. -brad From nyef@lisphacker.com Sun Oct 23 04:30:44 2005 From: nyef@lisphacker.com (nyef@lisphacker.com) Date: Sun, 23 Oct 2005 04:30:44 +0100 Subject: [LMH] E1 MCR interrupt bits? In-Reply-To: <200510222248.j9MMmvG4023442@mwave.heeltoe.com> References: <200510222248.j9MMmvG4023442@mwave.heeltoe.com> Message-ID: <20051023033044.93A3B188E5@tech.vm.bytemark.co.uk> Brad Parker writes: > Can someone explain know the interrupt scheme on the E1 works? > > I assume the e00000-e0003e register space on the cpu is for interrupt > testing only, i.e. nubus cards don't write to this space, only the > diags do. Bad assumption, I'm afraid. SSDN2, section 3.2 says that NuBus cards do exactly this. > Do the NUPI and SIB assert a nubus hardware interrupt? Does the cpu > hardware see than and place it in it's list of pending interrupts? No, the NuPI and SIB are bus-master-capable, and are instructed by the CPU as to which word address they are to write the value 1 to when they wish to signal for attention. > I see that the cpu manages pending interrupts on a priority basis from > 15-0 with 0 being the highest. I don't quite get how the microcode > resets the pending interrupts or how the are asserted in the normal > case. Pending interrupts are reset by writing a 0 to the appropriate spot in the CPU register space. > -brad --Alastair Bridgewater