Re: M7264 Troubleshooting
> From: Allison > ODT for the two systems are very different. .. KDF-11 the ODT is part > of the higher level code. The larger cards (11/23 and 23+) boot to > resident (ep)rom. Ah, no. (Well, the KDF11 CPU's can boot to EPROM, which in the -11/23+ can be on the CPU card; the -11/23 is a dual card and has no functionality on the CPU card except the CPU.) The ODT in the KDF11's (and KDJ11's) is, just like in the LSI-11's, microcode, not macro-code. From the 1982 'microcomputers and memories' handbook, pg. 161 (in Chapter 7, "Octal Debugging Technique (Microcode ODT)"): "The console emulator Octal Debugging Technique (ODT)is a portion of the processor microcode ... The console ODT implemented on the LSI-11/23, PDP-11/23 and PDP-11/23-PLUS is identical." and on pg. 154: "Unlike the LSI-11 and LSI-11/2, the LSI-11/23 does not enter console ODT upon occurrence of a double bus error" >From which I think is quite clear that the KDF11's have microcode ODT. Noel
Re: M7264 Troubleshooting
On 06/08/2019 07:08 PM, Noel Chiappa via cctalk wrote: > A follow-up to close out something: > > > OK, now a picture of the bus with no console card: > > > http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/BSYN-BDAL_NoMem.jpg > [Note: image re-named, to correctly say what it's showing] > > > It's a bit hard to interpret what's going on here .. The long assertion > > of BSYNC is undoubtly the CPU trying to get the console CSR to respond, > > and eventually timing out. Not sure what the short assertion following > > it is - without looking at the ucode for the ODT, there's no way to know > > what the CPU's doing. > > > Even harder to understand is what the BDAL line is doing. It looks like > > it's un-asserted (0, i.e. +3V) on the falling (electrically - rising, > > logically) edge of BSYN (which would be incorrect - see above). And then > > it hops around while BSYNC is asserted, which makes no sense at all to > > me. > > So this makes a little more sense now. > > This is actually showing a NXM cycle to main memory (apparently to address 0), > hence the '0' on BDAL10. (The second assertion of BSYNC must be somehow > associated with the NXM.) Apparently it doesn't even try to talk to the > console card unless the memory is there OK; if it can't see the memory, it > must just reset and try again. > > Here: > > > http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/BSYN-BDAL_NoCon.jpg > > is a system with memory, but without a console. A very similar picture, but > here BDAL10 _is_ '1', as expected. > > > So the original picture did in fact indicate what the problem was - had I > known enough to know how to interpret it! Schaeffer's Law strikes again! > > Although I still don't understand why the LSI-11 wants to see main memory on > the bus, in order for ODT to run. ODT doesn't use memory at all; ODT on the > KDF11 CPUs will run without any memory. ODT for the two systems are very different. The LSI-11 ODT is microcode in the base CPU MICOM set and very low level. Also the 11/2 cpu (dual width is a bit differnt), KDF-11 the ODT is part of the higher level code. The larger cards (11/23 and 23+) boot to resident (ep)rom. Also consider the difference between the restart/run between the two. If memory serves The KDF11 requires enough ram to have a few of the key addresses in low memory operational. There is a lot going on with the LSI-11 as it also initializes internal and external RAM. At the time memory nearly always dynamic and require refresh cycles before it is "on line". The manuals detail it well. Allison > Noel >
Re: M7264 Troubleshooting
A follow-up to close out something: > OK, now a picture of the bus with no console card: > http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/BSYN-BDAL_NoMem.jpg [Note: image re-named, to correctly say what it's showing] > It's a bit hard to interpret what's going on here .. The long assertion > of BSYNC is undoubtly the CPU trying to get the console CSR to respond, > and eventually timing out. Not sure what the short assertion following > it is - without looking at the ucode for the ODT, there's no way to know > what the CPU's doing. > Even harder to understand is what the BDAL line is doing. It looks like > it's un-asserted (0, i.e. +3V) on the falling (electrically - rising, > logically) edge of BSYN (which would be incorrect - see above). And then > it hops around while BSYNC is asserted, which makes no sense at all to > me. So this makes a little more sense now. This is actually showing a NXM cycle to main memory (apparently to address 0), hence the '0' on BDAL10. (The second assertion of BSYNC must be somehow associated with the NXM.) Apparently it doesn't even try to talk to the console card unless the memory is there OK; if it can't see the memory, it must just reset and try again. Here: > http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/BSYN-BDAL_NoCon.jpg is a system with memory, but without a console. A very similar picture, but here BDAL10 _is_ '1', as expected. So the original picture did in fact indicate what the problem was - had I known enough to know how to interpret it! Schaeffer's Law strikes again! Although I still don't understand why the LSI-11 wants to see main memory on the bus, in order for ODT to run. ODT doesn't use memory at all; ODT on the KDF11 CPUs will run without any memory. Noel
Re: HP9816 PAL16L8
On Sat, Jun 8, 2019 at 6:18 PM Alan Hightower via cctech wrote: > > > L series are combinatorial only. You (or someone who has a working one) Not so. The 16L8 has feedback connectoionsfrom the outputs to the logic array. So while there are no registers (D types), you can make SR type circuits in it. -tony
Re: HP9816 PAL16L8
L series are combinatorial only. You (or someone who has a working one) should be able to figure out a logic map by either running through all the input permutation or putting it in a reader that will do the same (vs reading the fuse data). -Alan Good luck. On 2019-06-08 11:05, Piero Andreini via cctech wrote: desperately looking for jedec file of PAL16L8 position U69 part # 1820-2991 for my HP9816
Re: HP9816 PAL16L8
Do you have a schematic that shows what it does. You could write your own file is not really complicated for a 16L8. I wrote my own for my 6532to6530 adapter for the KIM-1. I'll admit I did a logic mistake the first time but I'd have done the same with palasm. Dwight From: cctech on behalf of Alan Hightower via cctech Sent: Saturday, June 8, 2019 10:18 AM To: General Discussion: On-Topic Posts Subject: Re: HP9816 PAL16L8 L series are combinatorial only. You (or someone who has a working one) should be able to figure out a logic map by either running through all the input permutation or putting it in a reader that will do the same (vs reading the fuse data). -Alan Good luck. On 2019-06-08 11:05, Piero Andreini via cctech wrote: > desperately looking for jedec file of PAL16L8 position U69 part # > 1820-2991 for my HP9816
Re: HP98035 Real Time clock and AC5954N clock chip
On Friday (06/07/2019 at 11:01AM -0700), CuriousMarc via cctalk wrote: > > > > I wondered if it's actually a digtal watch chip (2.5V could have been a > > couple > > of mercury cells in series, LED watches were not uncommon back then). > > > > In which case it would not normally have come in a 0.6" wide DIP. Perhaps > > normally it was a bare chip directly mounted on the watch circuit board or > > something. > > > > The DIP version would be unusual, which is perhaps why we can't find data > > on it. > > > > -tony > > I think you are on to something. That would make perfect sense. FWIW, there was an article in Kilobaud magazine, perhaps 1977 or '78 that described connecting a TI LED digital watch to the SS-30 bus in the SWTPC 6800. I built this then, wrecking the TI watch as a watch but it made an excellent RTC for this machine. Two AA size NiCADs were used to power the watch and charged through a simple trickle charge when the machine was powered up. The interface to the host was through a 6820 PIA, with just the segment lines and a couple of output bits. The output bits indeed "pressed" the buttons on the watch and the code would set it just like a human would by stepping through each digit in sequence and "pressing" the other button to increment that digit. When reading the clock, the code would pretend to set the watch but never increment any digit. It would just press the button to advance to the next digit, stepping through all of the digit positions until it had read them all (both time and date) and then return this buffered result. By pretending to set the clock but not actually changing it, it allowed the code to know which digit was being displayed and therefore it did not need to have the digit select lines brought into the host. Chris -- Chris Elmquist
Re: Palm usage was Re: Modems and external dialers.
You know I miss (A LOT) Palm desktop simplicity!? Wish I could have the same functionality on my android phone. Everything was SO simple and straightforward... ---8<---Corte aqui---8<--- http://www.tabajara-labs.blogspot.com http://www.tabalabs.com.br ---8<---Corte aqui---8<--- Em qui, 6 de jun de 2019 às 14:45, Cameron Kaiser via cctalk < cctalk@classiccmp.org> escreveu: > > > ...I was never a big fan > > > of PalmOS, TBH. Too limited for me as a former Psion user, and the > > > Palm devices were always very tied to a PC -- they were meant to be a > > > way to take your Outlook (or whatever) address book and diary with you > > > in your pocket. > > > > Interesting view of Palm usage that I hadn't considered. > > > > > I didn't use Outlook or a desktop PC PIM at all. > > > > Nor did I. When I carried a Palm Pilot every day, I was using UNIX > > 'mail' for work e-mail and did all local edits of my calendar on the > > Palm. I did backup my Palm Pilot, to my Linux Laptop (I still have > > backups files from 1999 in an archive folder). > > Not sure if this counts as "connected" but I used Palm Desktop itself for > my personal scheduling. I never used my Palms (an m505 and a Zire 72) for > E-mail, though. It did mostly note-taking, calendar and pharmacy work, and > some programming (in Plua). > > -- > personal: > http://www.cameronkaiser.com/ -- > Cameron Kaiser * Floodgap Systems * www.floodgap.com * > ckai...@floodgap.com > -- If elected, I will win. -- Pat Paulsen for President > --- >
Re: Palm usage was Re: Modems and external dialers.
I was curious about the opinion and reply :-) Sent from my Apple /c >> >> Cameron, how did you like Plua and what did you do with it? >> > > Oops, sorry for sending this out to the list
Re: M7264 Troubleshooting
On 06/08/2019 12:07 PM, Mister PDP via cctalk wrote: > On Fri, Jun 7, 2019 at 7:35 PM Noel Chiappa wrote: > >> PS: Might be useful to check that the DLV11-J works; having a stock of >> known-good >> boards you can swap in is such a tool for QBUS debugging. > > > Tried that one out too, and it works. In fact, unlike my M8017, it will > actually respond to my inputs on my terminal. I'm pretty sure I may just > have the card configured incorrectly, but I'm not going to worry about that > for now. Right now I am working on getting a TU58 emulator set up. You > wouldn't happen to know where I could find detailed instructions > (Address/Vector, Bootstrap, etc..) on how to do this would you? > LSI-11 (or PDP-11) Microcomputer handbook there were many versions over the years earlier maybe more useful to LSI-11 users. First you really want the DLV11J as you need the ports. Configure it with the standard address for DD(TU58) and its vector. There is a list in the various Qbus LSI/PDP11 manuals. Note to boot anything from TU58 you will need a boot program and unless you add a MRV11 (eprom card) that means hand entry via ODT. See http://retrocmp.com/tools/tu58fs/265-tu58fs-pdp-11-boot-loader-operation for details. Also you will want not less that 16Kbytes of memory more its very desirable the upper limits is about 28K words as the upper 4K words is reserved mostly for boot (ep)roms and device addresses. Most common easily loaded OS is RT-11 V3 though 5.4. The most common devices: RX01 floppy LP11 Parallel printer, this can also be a port on the DLV11 for a serial printer. And of course the console VT52 or VT100 were the time frame for LSI-11 but any of the later VT2xx,3xx and later terminals work well. LSI-11 Boot, terminator card (there are variants depending on the bootable devices. ONE LAST REMINDER: LSI-11 was first of its kind and while Qbus did become a standard it did not remain completely in the original format. There is Q16, Q18, and Q22 and that specified both level of change and the address bus width. Not all cards work right in LSI-11 level bus with LSI-11 cpu and some of the older cards common to LSI-11 do not in the newer buses with 11/23 or later cpus. Some of the backplanes did specific incompatible things with the CD portion of the connector chain and in some cases had a EF connector (HEX width). Use care, read up, and have fun. Allison
HP9816 PAL16L8
desperately looking for jedec file of PAL 16L8 position U69 part # 1820-2991
HP9816 PAL16L8
desperately looking for jedec file of PAL16L8 position U69 part # 1820-2991 for my HP9816
Re: M7264 Troubleshooting
On Fri, Jun 7, 2019 at 7:35 PM Noel Chiappa wrote: > PS: Might be useful to check that the DLV11-J works; having a stock of > known-good > boards you can swap in is such a tool for QBUS debugging. Tried that one out too, and it works. In fact, unlike my M8017, it will actually respond to my inputs on my terminal. I'm pretty sure I may just have the card configured incorrectly, but I'm not going to worry about that for now. Right now I am working on getting a TU58 emulator set up. You wouldn't happen to know where I could find detailed instructions (Address/Vector, Bootstrap, etc..) on how to do this would you?
RE: Old CoCos and similar things
Cindy, CoCo's have linear PSUs so you could soft power up using a variac, but I can't think of anything special to try Dave > -Original Message- > From: cctalk On Behalf Of Electronics Plus > via cctalk > Sent: 07 June 2019 16:49 > To: 'General Discussion: On-Topic and Off-Topic Posts' > > Subject: Old CoCos and similar things > > I have a few of these that need to be tested. I am certain they have not been > plugged in for many years. > > Is the anything special I need to do before I just plug them in and turn them > on? > > > > Cindy Croxton > > Electronics Plus > > 1613 Water Street > > Kerrville, TX 78028 > > 830-370-3239 cell > > sa...@elecplus.com > > > > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus
