Reviving an Orchid PCturbo 286e Accelerator Card

[th3bar0n]

I have two non-working PCturbo accelerator boards that I’ve been trying to revive. These boards are particularly interesting as they do not use a cable to connect to the CPU socket but are instead able to control the 8088 and use it for I/O. On startup the PCturbo board holds the 286 in reset. You then need to run a driver program called “turbo.com” that sets up a shared memory location (default E000h) and copies across to the board an 8K bios image embedded in its .com file. It then takes the 286 out of reset and at this point execution switches to the board and you now running on the 286.

I’ve been building on this initial work of @per and have setup a Github repository (https://github.com/retrobyte83/pcturbo) where I now have a reasonably complete disassembly of turbo.com and a partial disassembly of the bios code, made using IDA. I also have a partial schematic from buzzing out most of the key traces, including everything that goes to the two 40-pin extension headers (address lines, data lines etc).

Board 1

This is the board I first talked about here. When I got it, I found that the 286 had been installed in the wrong orientation. I’ve subsequently tested the CPU in another machine and it is fine. I’ve also debugged the startup to the point where the bios has been copied across to the PCturbo and the CPU starts running on the board, but after a bit it halts and the turbo.com driver errors out with “PCturbo not responding”.

Board 2

This board I got recently from @Mike1978 . It was DOA when he first got it, and having done some testing myself I can confirm there are no signs of life. The turbo.com driver errors out with “Cannot access the PCturbo”, which is what it would do if no board was installed.


My hope (with some help!) is to try and use the different behaviour of both boards to progress the troubleshooting. My focus is currently on board 2, since it doesn’t seem to even get anywhere. I’m hoping if I can fix this initial issue, maybe it will spring into life or at least it might give me some direction on board 1. Given they behave differently, I’ve extracted a minimal code path from turbo.com into a small test executable “turbochk.com” which runs to the point where the behaviour diverges. It does some initialisation and then tests writing and reading back some bytes at the start of E000h. On Board 2 this check fails, but on board 1 it succeeds (and would start to copy across the bios beyond this point).

Unfortunately, I’m still a relative novice when it comes to x86 assembly, and it’s not clear to me exactly what is happening in the code to ensure the board maps memory to E000h, so that the read/write check passes. I’ve attached the code (turbochk.asm) and would welcome any thoughts. My next step in the meantime, is to swap the memory extension between the boards but I’m loathed to do too much further swapping around of parts until I better understand exactly what is going on.

 

[Mike1978]

I have two non-working PCturbo accelerator boards that I’ve been trying to revive. These boards are particularly interesting as they do not use a cable to connect to the CPU socket but are instead able to control the 8088 and use it for I/O. On startup the PCturbo board holds the 286 in reset. You then need to run a driver program called “turbo.com” that sets up a shared memory location (default E000h) and copies across to the board an 8K bios image embedded in its .com file. It then takes the 286 out of reset and at this point execution switches to the board and you now running on the 286.

I’ve been building on this initial work of @per and have setup a Github repository (https://github.com/retrobyte83/pcturbo) where I now have a reasonably complete disassembly of turbo.com and a partial disassembly of the bios code, made using IDA. I also have a partial schematic from buzzing out most of the key traces, including everything that goes to the two 40-pin extension headers (address lines, data lines etc).

Board 1

This is the board I first talked about here. When I got it, I found that the 286 had been installed in the wrong orientation. I’ve subsequently tested the CPU in another machine and it is fine. I’ve also debugged the startup to the point where the bios has been copied across to the PCturbo and the CPU starts running on the board, but after a bit it halts and the turbo.com driver errors out with “PCturbo not responding”.

Board 2

This board I got recently from @Mike1978 . It was DOA when he first got it, and having done some testing myself I can confirm there are no signs of life. The turbo.com driver errors out with “Cannot access the PCturbo”, which is what it would do if no board was installed.


My hope (with some help!) is to try and use the different behaviour of both boards to progress the troubleshooting. My focus is currently on board 2, since it doesn’t seem to even get anywhere. I’m hoping if I can fix this initial issue, maybe it will spring into life or at least it might give me some direction on board 1. Given they behave differently, I’ve extracted a minimal code path from turbo.com into a small test executable “turbochk.com” which runs to the point where the behaviour diverges. It does some initialisation and then tests writing and reading back some bytes at the start of E000h. On Board 2 this check fails, but on board 1 it succeeds (and would start to copy across the bios beyond this point).

Unfortunately, I’m still a relative novice when it comes to x86 assembly, and it’s not clear to me exactly what is happening in the code to ensure the board maps memory to E000h, so that the read/write check passes. I’ve attached the code (turbochk.asm) and would welcome any thoughts. My next step in the meantime, is to swap the memory extension between the boards but I’m loathed to do too much further swapping around of parts until I better understand exactly what is going on.

Watching and hoping for some success for you

 

[per]

If you can get code running and modifying RAM on the 286, that's a good start. Then you can execute small bits of code on the 286, and read the result back on the host. In this case, the first thing I'd do is to get together a small program for the 286 to test all the RAM.

A bit more thorough approach would be to pull out a classic logic analyzer, preferably a good brand and with enough ports to cover the card's internal system bus, then try to trace out exactly from where in the BIOS code the 286 halts.

 

[th3bar0n]

Thanks Mike and Per.

At the moment I'm not getting far enough for code to run on the 286. I think board 1 might be close, but it goes off track soon after the Orchid bios code starts running. However, I've set that board aside for now and am focusing on board 2 which does.. pretty much nothing at all.

I've narrowed down the precise code in turbo.com that enables the shared memory window at E000h, but this does nothing when run on board 2.

byte_var db 20h port_300h dw 300h addr_E000h dw 0E000h mov ax, [addr_E000h] mov cl, 4 shr ah, cl sub ah, 8 or byte [byte_var], ah or byte [byte_var], 10h mov dx, cs:port_300h add dl, 4 mov al, 0 out dx, al mov dx, cs:port_300h add dl, 3 mov al, cs:byte_var out dx, al mov dx, cs:port_300h mov al, 0FFh out dx, al

My next step is to trace the ISA lines into the board and try and and use my logic analyser to see any differences in behaviour when I run the above code. Any pointers that might narrow down the search would be great!

 

[per]

I see!
Yes, checking where the IO write ends up is what I'd do too. I would suspect it ultimately ends up at the gate array chip at some point. If you trace the signal all the way to the gate array, along with the accompanying address and data paths/control signals, if you got the tools and are willing to take the risk you may try to swap gate-array between the two cards.

 

[th3bar0n]

Ok, there have been some developments!

I’m still working on tracing the ISA bus through the card (progress so far attached). As you suggested Per, it looks like it will end at the gate array after passing through some of the “TU-“ PAL chips.

However, while buzzing out the non-working board I’ve found that the IRQ 5 line is shorted to ground, and it definitely isn’t on the “working” board. There is no obvious trace damage, but it’s a multi-layer board and for a time it seems like that trace is running on a middle layer somewhere. Ultimately it goes to the D71059C, so perhaps that is shorting internally.

I’ve ordered a replacement but it will be a few days before it arrives. I think in either scenario I’m going to have to desolder it, and at least see if that clears the short.

 

[per]

I see you use symbols with package-based layout. Down the road, the schematic may be easier to read using symbols with a logic layout instead. For instance, for the 74LS273, if the symbol groups all the inputs in order on one side and all the outputs in order on the other side.

 

[Mike1978]

Ok, there have been some developments!

I’m still working on tracing the ISA bus through the card (progress so far attached). As you suggested Per, it looks like it will end at the gate array after passing through some of the “TU-“ PAL chips.

However, while buzzing out the non-working board I’ve found that the IRQ 5 line is shorted to ground, and it definitely isn’t on the “working” board. There is no obvious trace damage, but it’s a multi-layer board and for a time it seems like that trace is running on a middle layer somewhere. Ultimately it goes to the D71059C, so perhaps that is shorting internally.

I’ve ordered a replacement but it will be a few days before it arrives. I think in either scenario I’m going to have to desolder it, and at least see if that clears the short.

Great find !

Here’s hoping

 

[th3bar0n]

Good point Per on the schematic, I will definitely switch to logical layout now I've got a handle on the routing.

I've desoldered the Interrupt Controller from Board 2 but unfortunately the short remains, so somewhere the IRQ5 line and ground must still be touching. Closer inspection of the exact tracing has definitely yielded something interesting though.

-The IRQ5 line runs from the ISA connector to a via (points A to B in attachment 1).
-The via is then connected to the lower pin (C) of the “5” jumper of the IRQ jumper block in attachment 2. This pin is then connected to the right-most pin of jumper block J1 (D).
-In attachment 3, the pin to the left (E) is connected to another via (F), I think through a mid-layer as I can’t see any obvious trace. Then finally a trace runs from the via to pin 23 of the interrupt controller (G).

The most suspicious part is the trace between points C and D in attachment 2, as it runs incredibly close to a via that I’ve circled in attachment 4. Buzzing it out shows that via is connected to IRQ5 and ground.

Checking the Board 1 yields a bit of a surprise, that via has been completely removed and the trace is severed! Basically, there is a hole in the board (attachment 5), and then a patch wire on the back (attachment 6) linking the two jumper blockers (points C and D)

This is all pretty strange, was there a manufacturing defect on some of the boards? One of these boards has the fix and the other doesn’t?

@per, I’m hoping you can help shed some light! Ideally before messing with this board further, it would be great to know if your board has this mod, and if not, is that via connected to IRQ5 or ground, or both?!

 

[per]

Sounds like they had a problem with the PCB, does the via stay in the signal-path when IRQ7 is used? It may be they didn't bother fixing the IRQ5 option for cards that shipped set to use IRQ7... Or maybe it took some time before they figured out the problem.

 

[Mike1978]

Good point Per on the schematic, I will definitely switch to logical layout now I've got a handle on the routing.

I've desoldered the Interrupt Controller from Board 2 but unfortunately the short remains, so somewhere the IRQ5 line and ground must still be touching. Closer inspection of the exact tracing has definitely yielded something interesting though.

-The IRQ5 line runs from the ISA connector to a via (points A to B in attachment 1).
-The via is then connected to the lower pin (C) of the “5” jumper of the IRQ jumper block in attachment 2. This pin is then connected to the right-most pin of jumper block J1 (D).
-In attachment 3, the pin to the left (E) is connected to another via (F), I think through a mid-layer as I can’t see any obvious trace. Then finally a trace runs from the via to pin 23 of the interrupt controller (G).

The most suspicious part is the trace between points C and D in attachment 2, as it runs incredibly close to a via that I’ve circled in attachment 4. Buzzing it out shows that via is connected to IRQ5 and ground.

Checking the Board 1 yields a bit of a surprise, that via has been completely removed and the trace is severed! Basically, there is a hole in the board (attachment 5), and then a patch wire on the back (attachment 6) linking the two jumper blockers (points C and D)

This is all pretty strange, was there a manufacturing defect on some of the boards? One of these boards has the fix and the other doesn’t?

@per, I’m hoping you can help shed some light! Ideally before messing with this board further, it would be great to know if your board has this mod, and if not, is that via connected to IRQ5 or ground, or both?!

I had wondered if these bodge wires may have at some stage come away for some of these cards.. they will have had an interesting life since the time they were made. This one crossed the pond at least once!

Mike

 

[Digitalman]

I have two of these and been spending the past week trying to get them going. I'm creating a small video demonstrating the board running in a Commodore PC 10-II. One of mine does work, although glitchy to say the least. The other board hangs when the TURBO bios is loaded. So I'll be interested in your findings. If you want me to do any testing on my end let me know. I can't help much with the assembly side of things unfortunately.

 

[th3bar0n]

I have two of these and been spending the past week trying to get them going. I'm creating a small video demonstrating the board running in a Commodore PC 10-II. One of mine does work, although glitchy to say the least. The other board hangs when the TURBO bios is loaded. So I'll be interested in your findings. If you want me to do any testing on my end let me know. I can't help much with the assembly side of things unfortunately.

That's great to hear! Having more boards to compare behaviour to will definitely be helpful. Are you able to attach some pictures of both boards, front and back?
Also, I've read the boards are very picky about dos versions, as I think the driver messes directly with some data structures in memory. I think Dos 3.3 should be ok but if you are running anything else that might be a source of glitchiness.

Per - That via only sits on the IRQ5 path. I agree the board should in theory work fine using IRQ7. In fact I've removed all the IRQ related jumpers and my test program still works fine on the first board, so I know this is not the main issue.

Next step is to finish the schematic for the address and data lines (and switch to logical pinouts), then start comparing behaviour with the logic analyser.

 

[Digitalman]

yeah...I originally had DOS 4.01 installed...it would just hang every time. I was able to get it to launch with the original system disk (DOS 2.11) but I want it to load from hard disk and the HD support on that version is limited at best. I was able to get it going on DOS 3.3 (smaller partitions) but it launches. However it is glitchy. Sometimes it just reboots the machine, sometimes it loads fine but will cause the command prompt to register odd keystrokes when typing, like deleting a character or not accepting keystrokes, and sometimes it loads perfectly fine!

Anyway, here are the photos. Hope they are clear enough. Board1 is not working. it always hangs when the driver is loaded. Board2 works, and has a 80287 Math-co. I am curious if there may be a RAM issue. I think i will swap RAM boards to test further. These MT DRAM chips are used on the Commodore 8-bits from time to time and are notorious for failure. Thoughts?

 

[Digitalman]

Just want to add to my previous message...a little more troubleshooting on my end... My working card, usually on the first boot (and a few subsequent) will restart the machine as soon as the DISK CACHE is executed. I wonder if this is just a bug, as I believe it uses all of the native RAM for caching in TURBO mode. Because it does eventually run. When I do a memory test using CHECKIT while the turbo is running all RAM checks out. Also I don't believe me swapping RAM boards between units is a good idea. The extension only accounts for half the RAM.

 

[th3bar0n]

Many thanks for the pictures - very interesting.

Your boards seem to be a slightly later revision, with the 286 in a plcc package, and one of the pals seems to have an update (labelled TU-21 vs TU-20 on my boards).

Also, that pesky via is now gone! Pretty clear that was a factory issue on the earlier ones.


To see how "dead" your not working board is, are you able to run the attached turbochk.com and tell me what it prints out?
Run it on a clean boot without any of the Orchid drivers being run.

NOTE - To do so you will first need to change the jumpers on the SW1 switch block to set it to port 300h. Just move jumper 6 to position 1.

 

[Digitalman]

Thanks! Sorry for the lengthy message but…. You started a rabbit hole of testing...lol... and frankly a hole of utter confusion. So, interestingly enough, I did not try the "bad board" using the default config. doh! Poor troubleshooting on my end. Since the "working" board seemed to function with custom settings (IO:208h, IRQ3) I assumed the other board was faulty. It may well be still, but when I ran your "check" program it stated "Ready to load bios" (using defaults). Problem is, my XTIDE interface has a fixed IO address of 300-31Fh which basically negates all other options on the PCturbo other than 208h (am i wrong?). So with this in mind, I have been using my DOS 2.11 boot disk, removed the XTIDE, and both cards initialize successfully. In fact, using the defaults and DOS 2.11 the card initialized every time.

Now the confusion....

Not much I can do with the card and floppy only (360k). I can only run CheckIt 1.0 from floppy and it would give all sorts a bizarre results. CPU speed checks were good, but it would lock up on DMA tests, and RAM test was giving errors. Tried on my “working” card, same results! CheckIt 2.1 tests good with my “working” card but I have to run it from the hard drive.

I decided to see if I could modify your “turbochk.com” to use base 208 and see if it would generate a different output. I’m pretty sure I found the right bytes, created a new file called turbo208.com, set the jumpers on the bad board to 208h and IRQ3, launched it… and to my surprise, I got the “read to load BIOS” message? Huh? Ran your check file, same message? Huh? Was not expecting that (see photo). When I tried it originally with the wrong settings I got a message that it couldn’t see the board. Then I launched TURBO.COM with the new settings and it booted? …triple HUH?! Not only is the “bad” board starting with custom config, I was able to boot from hard drive!? I must have tried this 50 times before and now it is working. …well sort of… the system is crashing when I launch various programs that were working with the “good” board. See photo of the “illegal op code..may not be compatible with 80286..” messages when I load CheckIt 2.1.

Well now completely confused, I put back in the “good” card, set the IO address to 208h, and IRQ3. First I used your turbochk.com… got the message Cannot access board… whew… that’s what I expect. Ran my turbo208.com and got the message Ready to load BIOS… see photo. Ok that’s more like it.

So what to take away from all of this? My “bad” board is flaky..I don’t know what your thoughts are. .. it’s like the memory space is not locked in or floating or something. Could I be dealing with bad RAM? Some faulty logic chips? The “good” board is flaky too but a lot more consistent. Or maybe it’s the PC?

Anyway, thanks again for making that file up…it really help me open up my troubleshooting.

 

[th3bar0n]

Apologies, I should probably have mentioned a couple of things.

Firstly I use a SCSI setup, so I'd forgotten about the port clash with XTIDE. Nice job working around it!

The other thing is the way that turbochk.com works. It does a very simple set of writes that (somehow) triggers the board to map the E000h segment as shared memory between the host and the turbo board. The message "Ready to load bios" signifies that memory block is now writeable. The problem is if you run it again, that memory location will still be writable (there is no code to unmap it if you see what I mean). Maybe that is what is happening here,



turbo208.com is actually failing, but the memory check still passes because turbochk.com successfully mapped the memory in initially. Are you sure the board was not set to port 300h when you ran this?

It's hard to say on the cause of the flakiness.. could be anywhere (and everywhere), I mean neither of my boards work for a start! Could be solder joints starting to fail, bad ram chips, failing logic chips. I don't think these boards were bullet proof even when brand new. I do think it's encouraging though that we now have four boards in various states of operation which we can use to cross-check between (five if Per joins the party!). I'm hoping to have more time this weekend to make progress on my side.

 

[Digitalman]

turbo208.com is actually failing, but the memory check still passes because turbochk.com successfully mapped the memory in initially. Are you sure the board was not set to port 300h when you ran this?

I understand what you are saying. For sure IO was mapped to 208h in this case. Does the mapping hold on a warm reset (CTRL+ALT+DEL)? Might explain a few things. It was definitely more consistent with the other board, as in the photo, the turbochk.com fails. But of course this could be because of a hard reboot at that time.

Thanks for the feedback. I'll start poking around some more. So many logic chips on these things, hard to know where to start. Do you know if all DRAM is made the same? Hard to find this exact type, MT 1259-12 but there are similar options (256k, 120ns, DIP16) out there.

 

[Digitalman]

One thing I've discovered, that illegal opcode message is a PCTurbo error message and not produced by DOS.