Why calculate, when you could just read it?
On M24 I use it with simple flat cable extension, I forgot to tell you.
Also now that I think about this wasn't there something buried in either the AT&T or Olivetti service manual or even the owners manual about the different steps in POST?
2. The 8086 CPU test is performed. Interrupts are disabled. First, the CPU's status flags are tested using the accumulator and the processor control and conditional control transfer instruction classes. Second, the CPU's general and segment registers are tested with a test pattern. Third, a typical instruction from each of the CPU's data transfer, arithmetic, logical, and string manipulation instruction classes are tested. Fourth, a set of the CPU's addressing modes are tested on ROM. Fifth, the stack segment and pointer registers are initialized to address the ROM stack, and the call/return instructions are tested. Testing the CPU's software-interrupt instruction capability is postponed until after the ROM and RAM modules have been tested. The CPU's hardware-interrupt diagnostics are postponed until after the 8253 real-time clock channel, the 8041 Keyboard peripheral interface, and the 8259 interrupt controller have been initialized and tested, because all three are involved in the testing.
3. The Keyboard peripheral interface chip (8041 or 8741) is programmed and initialized, the lights go off, and a beep is heard.
4. The Display Controller Board is programmed for monochrome 80 by 25 text mode.
5. The parallel printer port and the display are used to report the successful completion of each diagnostic test. The check point bytes are not strobed to the parallel port, so that an attached printer will not confuse the check point information with actual printable data.
6. The parallel printer port and the display are sent confirmation that the CPU test has been successful. If the CPU test fails, an attempt is made to send a "CPU (i8086) Fail" error message to the display, and the CPU is halted.
@Trixter: You need to find out what fails at POST 44h. Have a look at the theory of operations manual, the DMA controller and sourrounding is explained there.
an I locate a bad chip by piggybacking?
Well, since the 6300 is an 8086 box, does anyone have a spare ICE to lend?
There's always the logic analyzer route as well.
There were some very strong piggybacking opinions both for and against in this thread a year ago. If no chips have obvious shorts (are hot to the touch), and piggybacking is not reliable, then what do most people usually do after that? Replace all the RAM with sockets and swap in known good chips, or is there a more elegant way to diagnose bad 4164s?
I generally remove the 4164s, install sockets, put the old desoldered 4164s in the sockets and replace them one at a time.
I like to do that in most cases as soon as there is a RAM problem; I like to have sockets at that point, but that's just me
That is what I told you above. Parallel port POSt codes come before monitor init. It beeps and then BIOS message on the monitor comes up.As it turns out, you're right. The relevant portion in the 6300 Service Manual starting on page 4-10 states the following:
So part of the POST completes before the display has been initialized, and you only see the codes output via the LPT port. After some components are tested, the display is initialized, the keyboard controller is initialized, and the system beeps. Then the later POST begins, including a full memory test after printing some text onscreen.
The POST codes output to the LPT port are not documented in any manual I have access to, which is why I've been disassembling and commenting the BIOS POST routines. The last code I see is 43h. Based on my reverse engineering of the BIOS, the code between 43h and 44h tests the DMA channel functionality, and also the first 64K of RAM on the system board.
I don't think it is likely that the DMA channels are faulty, but I do think it is likely that some of the RAM is bad. It looks like the first two banks are 9 x 4164s -- can I locate a bad chip by piggybacking?
Are the BIOS ROMs/EPROMs in sockets? Could you write your own memory diagnostics and burn those into your own EPROMs and output your own diagnostic code to indicate which bits are bad if your diagnostics are able to determine that? That might be a more fun project from my own point of view than breaking out a soldering iron to unsolder and socket a bunch of DRAM chips.
In theory if you disregard the ram piggybacking discussion you could disable the second bank and use it to piggyback the other bank but in my machine this failed to yield any changes.
I can cut chips out and install sockets even away from my bench and still end up with a professional job.
How do you get the clipped legs out without access to the other side of the board?