Apricot Xi PC « modelrail.otenko

27Aug/240

Apricot Xi PC

This Apricot Xi (further info) (Service Manual) appeared on eBay and the seller was willing to ship it! He descibed it as the following:

It was tested to power up only. The hard drive spins up and a red light is visible inside through the floppy drive slot. It did not appear to boot. A minute or so after first powering up some caps blew in the power supply, likely filter capacitors. It did not stop and later could be powered up again to the same state.

That latter concept of why not try turn it on again after it exploded left me a little bemused... but what could I lose by trying to get it going?

The tear-down was nice and simple. A few screws here and there and things just nicely came apart.

The power supply was out first and the damage was blindingly obvious.

Those two nuts on the wall were not fun to remove, but with them out the base board came out cleanly.

With the new capacitors back in, the unit was re-assembled.

Of note, in the middle shot above, make sure to line up the carry-handle with the slot it fits through. In the last shot, make sure to re-connect the speaker cable to the motherboard before screwing down the drive-bay plate.

With it all together, voltages were checked and the 12v rail was quite high! With no load, this was mildly expected. I slapped in a sacraficial HDD and hit the power... it spun up and the motherboard speaker even beeped! I was good to continue the testing.

Video Out

Long-story-short... it's a 71.9hz vertical sync signal at 15.978khz horizontal. This doesn't match MDA, CGA or EGA... let alone anything higher.

The video port is a 9-pin male DB-9 with both syncs, video and a dangerous -12v pin. Don't just hook this up to anything non-Apricot!

I attempted with some logic to invert the vertical sync as it was mentioned somewhere that it might be negative and needs to be positive, but that didn't work.

The GBS-8200 didn't work either! So, what to do? Let's test something that's been on the shelf for a while...

I hadn't tested out the oscilliscope before and I still don't know how to use it. I was happy to see it seeing signals... but I couldn't work out if the frequencies were at the numbers I needed. I then realised my retro-corner LCD supports 15khz and threw together a test-wire straight through to VGA plug:

Hello there! It's totally failing to work out the vertical refresh rate... but that's fine... this thing is running a VGA vertical refresh with an EGA horizontal... it was never expected to 100% work without some kind of conversion. Just for fun, here's the specifications:

----CRT DATA DISPLAY SPECIFICATIONS---
PHYSICAL CHARACTERISTICS
Dimension	174mm max.
Height	241 ±1.5 mm
Width	226±5.0 mm
Depth	6.2 Ibs (2.8 kg)
Weight	240AMB39 polish
Picture Tube	Visual 9" 90° def. 20 mm dia.
Tilt	10° ± 1°
ELECTRICAL CHARACTERISTICS OF CRT DISPLAY MONITOR
Power Requirements	DC 11.8V 1.0A
Video Input Signal Requirements	Black level = 0 + 0.4 -O.OV White level = 4 ± 1.5V
Input Impedance	300 ohms min 40pF max.
VERTICAL INPUT SYNC SIGNAL REQUIREMENTS
Active Polarity	Positive
Pulse Rate	71.9 Hz
Pulse Width	158us
Amplitude	Low = 0 + 0.4 -O.OV High = 4 ± 1.5V
Input Impedance	1 Kohm min. 40pF max.
HORIZONTAL INPUT SYNC SIGNAL REQUIREMENTS
Active Polarity	Positive
Pulse Rate	15.79 kHz
Pulse Width	8.0us
Amplitude	Low = 0 + 0.4 -O.OV High = 4 ± 1.5V
Input Impedance	2 Kohms min. 40pF max.
Video Amplifier Band Width	25 MHz typ
Resolution	>= 800 TV Lines at center >= 650 TV Lines at corner
Vertical Character Area	120 ±5mm
Horizontal Character Area	150 ±5mm * According to the attached timing chart * +B = 11.8 ± 0.05V
BLANKING TIME REQUIREMENTS
Vertical	1200us min.
Horizontal	lOus min.
Vertical Deflection Linearity	10%
Horizontal Deflection Linearity	10% ((max - min)/(max + min) x 100)

So, what next? Find someone else that's built a 15khz VGA adapter. Writing this now, after building the MCEBlaster, I can't help but wonder if I should not have gone the simpler route and built the qiqitori analog-RGB to VGA adapter?

The MCEBlaster is multi-purpose for MDA/CGA/EGA, but none of those suit this display output! MDA is close, but it's still a reach from the resolution this unit is outputting. Using qiqitori's adapter, I could've just customised the code directly for this machine.

REGARDLESS, I didn't have this hindsight and built the MCEBlaster. In fact, I built it to the the schematic... expecting my video pin display data to be fed into all three coloured RGB TTL lines at once...

This was wrong, and with code changes forcing the EGA lines to 72hz vertical (which the code was picking up as the input signal, correctly), I got the following:

With a silly amount of tinkering (as this was never going to work as EGA is too limited to display the full EGA picture), I eventually got quite a bit of the picture to display!:

As mentioned, trying to fit 800x400 in 320x240 was never going to work. We're an MDA-esque signal and the board had full provision for such. I should have, from the start, fed the image into the input as if it was an MDA plug. This meant we needed to input video data on pin 7 and intensity on pin 6.

Unfortunately, the Apricot doesn't output an intensity pin, so pin 6 can be grounded. My wiring between the 74LVC245 and Pico could stay, as per the schematic, as the Pico knew to look on pins 26 and 27 if the vertical frequency was correct. I adjusted the MDA modeline config to look for 72hz (rounded-up) sync and we started getting somewhere...

I already had that encroaching feeling of Why am I doing this? If/when it works, what will I do with it?... so this was a good enough video output to test the rest of the peripherals. The error shown above is Error 31 and it means that Keyboard diagnostics failed.

Keyboard Input

As always, someone has already done this before. I built the circuit and plugged everything together expecting things to just-work, but I still got Error 31!

With the arduino connected, there was no data showing as coming from the Apricot? I checked the MAME source code for the Apricot keyboard and you could see that the keyboard was meant to receive a reset command from the computer and respond with an ACK:

		case CMD_KEYBOARD_RESET:
			logerror("System requests keyboard reset\n");
			transmit_byte(ACK_DIAGNOSTICS);
			break;

The computer stayed silent towards everything I threw at it. No amount of forced-sending of control codes from the keyboard to the computer worked, so I hooked up the oscilloscope to the data pin 2 of the keyboard port and yeah, the transmit signal from the computer to the keyboard was held high and had a not of noise. Interestingly though, pressing CTRL+ALT+DEL on the keyboard actually did reset the Apricot? The apricot-kbd arduino code has a special block where sees a reset request and holds the transmission line to ground for 100ms. Is this the required signal? I checked the schematics again and noticed that there was a special path for a system reset request.

Above, you can see the keyboard connector in the green box on the left. The two standard paths are orange and blue and they travel through respective MC1489/MC1488 paths to the Z80 SIO/0. I'm getting nothing from, and seemingly sending nothing to, this chip... so the only reason reset would work is via the purple path down the bottom.

Just for fun, I dismembered the trace between the SIO and the MC1488 on the outbound TX line to see if the MC1488 was the issue. Doing so still saw a high and messy voltage on the Z80A SIO/0 side, meaning something was wrong it, or with a chip further towards the CPU. Whilst doing all this, I happened to press my finger down on the SIO and found that it was hot enough to fry an egg! No wonder it's lid is so smooth and shiny.

It was a very quick removal. A socket was installed and... I found a pair of ICs (supposedly new-old-stock) on eBay. The machine was put back in the corner of the room... unscrewed, but neatly stacked. The ICs came in due course and one was installed.

And...?

PS2 to Xi
Value FA - Status Bits 0  Code 0xFA [�]   --  .
Value AA - Status Bits 0  Code 0xAA [�]   --  5F
Value 2B - Status Bits 0  Code 0x2B [+]   --  60
Value 802B - Status Bits 80  Code 0x2B [+]   --  FFFFFFE0
Value 2B - Status Bits 0  Code 0x2B [+]   --  60
Value 802B - Status Bits 80  Code 0x2B [+]   --  FFFFFFE0
Value 2B - Status Bits 0  Code 0x2B [+]   --  60
Value 802B - Status Bits 80  Code 0x2B [+]   --  FFFFFFE0
Value 2B - Status Bits 0  Code 0x2B [+]   --  60
Value 802B - Status Bits 80  Code 0x2B [+]   --  FFFFFFE0
----------From Apricot:
0 [] 
Value 2B - Status Bits 0  Code 0x2B [+]   --  60
Value 802B - Status Bits 80  Code 0x2B [+]   --  FFFFFFE0
Value 2B - Status Bits 0  Code 0x2B [+]   --  60
Value 802B - Status Bits 80  Code 0x2B [+]   --  FFFFFFE0
Value 11E - Status Bits 1  Code 0x1E []   --  40
Value 811E - Status Bits 81  Code 0x1E []   --  FFFFFFC0
----------From Apricot:
E8 [�] 
----------From Apricot:
E8 [�] 
----------From Apricot:
E2 [�] 
----------From Apricot:
D0 [�] D4 [�] AA [�] E3 [�] 0 [] E2 [�] 81 [�] 52 [R] 41 [A] 4D [M] 20 [ ] 35 [5] 31 [1] 32 [2] 4B [K] 
Value 11E - Status Bits 1  Code 0x1E []   --  40
Value 811E - Status Bits 81  Code 0x1E []   --  FFFFFFC0

Wowzers... it's reporting 512K RAM to the non-existent Keyboard LCD! The paired values are from the PS/2 Keyboard keypresses and the data from the Apricot is self-explanatory once you've read the opcodes over here.

  if (Serial1.available()) {
    Serial.println("----------From Apricot:");
    while (Serial1.available())
    {
      uint16_t b = Serial1.read();
      Serial.print(b, HEX);
      Serial.print(" [");
      Serial.print((char)(b & 0xff));
      Serial.print("] ");

      switch (b)
      {
        //keyboard reset. just ACK
        case 0xe8: Serial1.write(0xfb); break;

      }
    }
    Serial.println("");
  }
}

Above is the only bit I changed when compared to the git repo.

Floppy Disk

This thing is a monstrosity, and didn't work at the start. It wasn't until I replaced the ZIO above that the floppy started seeking on boot and showing other signs of life. I haven't got a floppy disk formatted for this unit yet, but it really does seem that a catastrophic event occurred to wreck a whole bunch of chips in this machine. With one fixed, the data bus may well have been free'd up to communicate. It does still seem that once the machine has warmed up, that more faults start occurring. I'm guessing RAM? Either way, here's the beast of a drive:

If I can get it working more-consistently then I'll use apridisk to write disk images and have fun... but that's for another post. This one has gone on long enough!

Heat-Activated Gremlins

It seems that there are still issues with this machine. With the keyboard responding with an ACK, the system is finally reporting System OK on a cold boot, but starts to lose it once it's warmed up. After hitting enter at the prompt, the following message was displayed:

You can tell it's coded into the autoexec.bat file. Whilst trying to search for files on the Winchester Disk that others may have left behind, I initially received proper disk directory listings... until I didn't.

Letting the machine cool down again saw those same error'd directories list fine... so it's not the HDD itself... it's heat. I left the machine on for 20 minutes and touched all the chips... only the main CPU and its friend were (burningly) hot.