The 909090 pattern means the CPU is running properly and has fetched a RST 7 instruction (0xFF) at some point. Upon fetching RST 7, the CPU jumps to location 0x38 and, in this case, also fetches an RST 7 (0xFF) at that location. From then on, the CPU pushes 0x39, 0x00 onto the stack over and over because it keeps fetching another RST 7 instruction at location 0x38 and 0x0039 is the return address. This eventually fills all of RAM, including video memory, with 0x39 0x00 which results in the 909090 pattern on the display.
I assume you have no RAM at location 0x38 (i.e., no RAM in the S-100 bus), right? That is fine when getting the machine up and running and also ensures we get a 0xFF at location 0x38 as required for some of testing procedures in the manual.
The question to be answered is why is your machine encountering 0xFF during an instruction fetch? There are all sorts of possible reasons for this. For starters:
1) As already mentioned, if the ROM on the personality module does not respond, then 0xFF is seen and that causes the 909090 pattern.
2) If system RAM at 0xC800-0xCBFF is bad, then the first time the SOLOS ROM calls a subroutine, the RET instruction could easily end up in address space with no RAM (all addresses other than 0xC000-0xCFFF). This, in turn, will fetch 0xFF and generate the 909090 pattern.
3) If the PHANTOM circuit is not working properly (look for PHANTOM to go low for four CPU cycles after RESET is released), then the CPU does not execute SOLOS from the personality ROM and, in turn, generate the 909090 display.
4) Related directly to PHANTOM, if any of the ICs in the logic chain for generating the PAGE C0 signal (U24, U22, U34) are bad, the CPU will not execute SOLOS, which, in turn, generates the 909090 display.
5) Issues with the data input muxes or the logic that generates the mux select lines could also result in the CPU seeing 0xFF instead of actual data.
Mike