On May 3, 2021, at 3:19 AM, Rob Jarratt via cctalk <cctalk at classiccmp.org> wrote: Is the Sunsite archive still online? I seem to recall there being some documentation there. Zane

On May 3, 2021, at 2:23 PM, Rob Jarratt via cctalk <cctalk at classiccmp.org> wrote: Sadly my machine is not at the point where I can attach a console of any kind. The CPU is being reset every 13us by a bus error. I am having trouble working out why though. I have got as far as working out that is the CT2 TIME OUT signal, but just why that is active isn't entirely clear to me. It would help to have a working machine to compare it to! Regards Rob

That sounds like it's trying to access the boot ROM and not getting an answer. paul

-----Original Message----- From: cctalk <cctalk-bounces at classiccmp.org> On Behalf Of Bjoren Davis via cctalk Sent: 03 May 2021 20:45 To: cctalk at classiccmp.org Subject: Re: Documentation for F11 Chipset? Hello Paul and Rob, The next thing I did was to hook up a logic analyzer to the address lines on the ROM. This told me how far I got with the boot sequence before it restarted. I disassembled the ROM and have some portions of it semi-decoded so that may be helpful. If you like I can send you the text file I have. Another helpful thing for me was to take the Xhomer emulator https://xhomer.isani.org/xhomer/ and instrument it to give me a "good" ROM boot sequence (correlated nicely with device accesses) and compare that with what I saw with my logic analyzer. That's how I figured out my ROM was failing to see an interrupt from the EPCI (I think the ROM was running the EPCI in loopback mode) and so it was resetting. I have to say: the POST on the PC3XX is impressively thorough, but the mechanism for reporting failures is absolutely atrocious (4 LEDs and, if you're lucky, a cryptic octal error code on the screen).

I do have a functional 350 that I can instrument, so let me know if I can help.

--Bjoren On 5/3/2021 2:29 PM, Paul Koning via cctalk wrote: wrote: kind. The CPU is being reset every 13us by a bus error. I am having trouble working out why though. I have got as far as working out that is the CT2 TIME OUT signal, but just why that is active isn't entirely clear to me. It would help to have a working machine to compare it to! answer. > > paul > >

<cctalk at classiccmp.org> trouble TIME would help answer. I have been looking at this and I think you are right. But the reason is odd. It looks like the ROMs are never being selected by the ROM address decode. I can't find on the printset anything that says what the boot address would be, perhaps that is burned into the F11 chipset? However, from the Pro technical manual the ROM addresses are in the ranges 17730000-17767776, so I think the top 7 bits of the address should all be 1s. It looks like I never get anything other than 0s, when the address strobe (CT6 RCV AS H on the printset) is asserted. There is activity on the F11 chips, so I think they are working.

Rob, The start address on the DEC Pro is physical address 017760000. As a virtual addresses this is at the beginning of the I/O page (0160000). This mapping extends up 4 KiB (to physical 017767777 or virtual 0167777). But, of course, the ROM is actually 16 KiB long.? So where are the other 12 KiB? They're at physical addresses 017730000..017757777.? These physical addresses are not mapped into virtual address space at reset, but the boot ROM does map them during its execution to exactly where you'd expect: 0130000..0157777. Now, just to top off this confusion, the mapping of CPU-perspective physical addresses to ROM address lines is a little odd. It's really best described a table, which I hope doesn't get mangled by email formatting (all values in octal): Virtual???? Physical????? ROM offset 0130000*??? 017730000???? 030000 0137777*??? 017737777???? 037777 0140000*??? 017740000???? 000000 0147777*??? 017747777???? 007777 0150000*??? 017750000???? 010000 0157777*??? 017757777???? 017777 0160000+??? 017760000???? 020000 0167777+??? 017767777???? 027777 * = mapped later by boot ROM into virtual address space + = low half of I/O page -- mapped at CPU reset time So you can see the low 14 bits of physical address are fed directly to the ROM.? It makes for a slightly lumpy looking layout. The decode for this is on page CT10 of the schematic.? You can see the "ROM ADDRESS DECODER" section which has a NAND of address lines 21..15 being used as an enable on a 3-to-8 negative-output decoder and a 3-input negative-input OR on outputs 3,4,5.? This selects physical addresses 0177[3,4,5]XXXX.? Then E114 decodes the I/O page locations when A12 is low (017760000..017767777). This is the crucial reset-time ROM selection decoder. As to why the CPU starts at 0160000...I swear I saw that once in the documentation somewhere but I can't immediately find it again.? I believed that the CPU is presented with some kind of word at reset time that tells it where to start executing.? I believe that you can see this word constructed by E3 and half of E17 on page CT2 of the schematic, but I can't find the documentation that describes the layout of the word.? You can see the word would be 0b11100000LXXXX010 where L is ~(CT2 LPOK 1 L) and X is undefined.? Notice that the high bits decode to 0160000, and I think that's where the start address comes from. I hope that answers your question. --Bjoren