-
Some may find my project to get this 6809 based single board computer operational of interest.
It's called a Compacta Uniboard, and I built it from a kit back in the early 1980s.
I plan on trying to get it going again (I it ever did run, I can't remember actually using it), and hopefully get the Flex Operating System running on it.
Pictures of it in another thread:-
https://www.eevblog.com/forum/projects/compacta-uniboard-6809-sbc-found-the-schematic!/msg1877885/#msg1877885
In this first video, I simply describe the board, and in the next video, I'll try powering it up.
-
To those interested in the schematic for this board...
I don't know if it's just happening for me, but FileHosting.org is not sending me the links for the Uniboard Documentation.
The link for the schematic on David Wien's page:-
http://www.sardis-technologies.com/oth6809/uniboard.htm
is also not working for me, so I've uploaded the schematic again to:-
-
In this video, I apply power to the Uniboard.
Unfortunately, there are issues, but I find and fix some of them.
Along the way, my understanding of how it should work improves.
Hopefully, the remaining problems can be rectified in a future video...
-
The "Compacta Uniboard" 6809 based Single Board Computer that I have been working on came as a bare kit with just the PCB and 4 pre-programmed parts.
Two of those were ROMs for the monitor program and the video character generator, which I was able to read with my device programmer and so was able to save their contents for posterity, and also to help with understanding, testing, debugging, and eventually using and possibly modifying the board.
But the other two parts were Programmable Array Logic (PAL) chips - a PAL12L6 and a PAL10L8, which my programmer could not read.
To save their programming in case it were ever lost, to check that they were still good, and to help understand the Uniboard, I needed to read them somehow.
I used an Arduino Nano to to that, and in the process realized that there were considerations that were not apparent to me at first.
Going from setting port bits inside the Arduino's AVR chip, then through several sets of pins, and finally to signals on the Uniboard, needed to be accounted for in the process, and I show how my PAL reader software dealt with these "mappings" (4 of them).
But the sequence of bit patterns presented to the PAL also needs some thought, as that is critical to getting meaningful results.
The reader software also has a mechanism for helping with that.
Finally, I found a piece of software called "Logic Friday" that can also help with understanding the results of reading these PALs.
-
I've run out of steam on this thing for now, so this project will probably move to the back burner.
But I would be very interested in any thoughts, suggestions or insights you nay have as to what to check for next, or what approach to take in getting this board working.
I suspect the problem is in the RAM, and that the random junk showing on the screen:-
Is because the monitor initialization is not getting to the section where it clears the Video RAM.
It appears to set up the CRT controller, so that the display format is correct, but does not return from that (very first) subroutine call because the RAM is not remembering the return address from the stack (and so it never goes on to clear the display RAM).
I have:-
* Read out the Monitor and Character Generator ROMS, and they are good.
* Checked that the RAM RAS and CAS signals appear to match the timing diagrams in the manual.
* Fixed a couple of issues that were causing false interrupt request signals.
* Read out the contents of the 2 PALs (which look sensible. One I'm sure is correct, the other is hard to tell)
* Replaced all the chips involved in the RAM and video interface (basically all the core, non-I/O device stuff).
* Tested the 4116 RAM chips, and found 3 duds (but they were in lower memory, and not needed for initial testing)
* Modified the board to use 4164 RAM chips. Which changed the random display:-
But not much else.
Any ideas on where to go with this?
Front & back of PCB:-
The schematic is shown earlier in this thread, and all documentation is at:-
http://www.sardis-technologies.com/oth6809/uniboard.htm
My partial disassembly of the Monitor ROM:-
https://pastebin.com/yNnw5Fuh
Video of my latest blunderings:-
Thanks in advance for any bright ideas! -
adrian's digital basement https://www.youtube.com/user/craig1black/videos does a lot of videos about (mostly) 8-bit computer hardware debugging/repair. Maybe you could watch some to get useful ideas... in case you didn't already. And yes, RAM chips (and some brand more than others) are very prone to failure.
Maybe you could also check the signals (for voltage level) on address and data buses (on µP as well as on RAM) making sure none is weak (or weird) or held high or low. -
adrian's digital basement https://www.youtube.com/user/craig1black/videos does a lot of videos about (mostly) 8-bit computer hardware debugging/repair. Maybe you could watch some to get useful ideas... in case you didn't already. And yes, RAM chips (and some brand more than others) are very prone to failure.
Maybe you could also check the signals (for voltage level) on address and data buses (on µP as well as on RAM) making sure none is weak (or weird) or held high or low.
I watched a few videos, I think they were Adrian's, but I'll look again.
The few signals I've looked at seem to have good levels (except the 32MHz, but I put that down to the probe - it gets divided down, and then looks good)
But there's a lot I haven't looked at, so yes, I'll do that.
Thanks for the suggestions! -
What happened to the ceramic IC (U15 I think)? It's looks like it has modeling cement all over it.
-
Not sure at what point you took the pictures of the board, it appears dusty. Did you clean it and did you contact cleaned the sockets and re-seated the ICs?
-
Which PAL read correctly and which do you only suspect did?
How do you know?
Can you provide those dumps so we can perhaps see if they make sense for address decoding? -
Sorry guys, I thought the thread had gone dormant, and haven't looked in for a while.
(There are some serious distractions atm...)What happened to the ceramic IC (U15 I think)? It's looks like it has modeling cement all over it.
Yes, the metal lid is a little corroded.
It's a 6844 DMA controller, and used for disk I/O.
I've left it out and it makes no difference in or out. It shouldn't be needed just to get a clear video screen with the monitor prompt.Not sure at what point you took the pictures of the board, it appears dusty. Did you clean it and did you contact cleaned the sockets and re-seated the ICs?
It does look a little worse in the photos than it is. It's been brushed down and washed with IPA.
As I've replaced just about all the IC's that appear to be required for basic video operation, they have been reseated. The socket pins have oxidation where they are exposed, but clean where they contact the IC pins.Which PAL read correctly and which do you only suspect did?
I'm 99.9% sure of the address decoder PAL (U32) because it's outputs are chip select signals, and they match the memory map given in the documentation.
How do you know?
Can you provide those dumps so we can perhaps see if they make sense for address decoding?
With the other PAL (40), it's much harder to tell, but I have no reason to believe it's not also good. Because:-
* U32 is good
* It's contents seem to be some orderly patterns of values
* These chips are robust TTL, programmed by burning metallic fuses.
Unlike more delicate MOS devices, or EPROMs that do eventually leak away the charges used to store the data.
Here are the PAL dumps:-
U32: https://pastebin.com/k7SLcLCq
U40: https://pastebin.com/XeirNesj
The pin dumps at the end of these are probably the most useful parts.
I plan to do some more signal inspections with a CRO, but my next plan of attack is to come up with a ROM emulator using RAM.
With this I can store short test programs into the RAM, and have the processor run them as if from the ROM.
Starting out testing very basic things such as just the CPU, and then individual devices, building up to more complex subsystems such as the dynamic RAM, and the video. This should be much more orderly and systematic than using the monitor ROM which assumes all subsystems are operational.
Part of developing the ROM emulator will need a working system to test it on, and I have a Tandy CoCo to use for that, but it's not working either. (having a bad run with 6809 based systems atm!) I've just bought another CoCo, so I'm about to see if that works (seller said it had issues), and maybe use it to get the first CoCo going. -
Quote from: intabits
plan of attack is to come up with a ROM emulator using RAM
The simplest Rom emulator (that I know of) is done by soldering 330 ohms resistors between Vcc or Gnd and D0-D7 to form the instruction NOP (0x12 on the 6809).
The trick is described in this video at 19:33
But I think you already knew... -
But I think you already knew...
Not really. The idea does ring a bell from way back in the dim-dark, but it certainly wasn't in my conscious mind as a possible service aid.
Thanks for that - I think I'll be giving it a try.
The 6809 has it's own built in NOP generator, the HCF (Halt and Catch Fire) instruction ($not sure), that screams through all addresses.
But I like the NOP generator better, as the processor is running normally, and it also does some data bus testing. -
I also have a 6809 Compacta Uniboard, with the same issues! I have not had it on the bench for a few months (got sidetracked with a SWTPC 6800 system), but a collaboration might be helpful!
This one was, at one time running; it came to me about 10-years ago, a friend here was down-sizing and I adopted it. Not run since. I have a Ball Brothers monitor, ASCII keyboard, two half-height 5.25" drives, power supplies and documentation.
I think I might take a look at the docs again, to see if there is a switch or jumper set incorrectly; it has the ability to have either a serial console (external terminal) or the on-board video and 'parallel' keyboard interface. BUT, you would think that the monitor would put up a 'hello' message despite the other console selected?
Thanks for the thread - and the pictures. I will take a few myself in the next few days - when I get it back on the bench!
-Matt W0MJ
-
CONTACT!
I am not alone in the universe!
Great to hear that there is someone else with one of these, and looking forward to seeing if we can help each other.
I've currently gone down the PDP11 rabbit hole, so it might be a while before I get back to the UniBoard.
I had decided that to take this further, I wanted to make a ROM emulator to load very short and simple snippets of test code to check out each subsystem on the board. Basic things first like CPU loops, then chip select signals. And not using RAM (no subroutines) to see if the basics are working. Then test the RAM a little (still without subroutines). That sort of stuff...
I also have a Color Computer 2 that I want to test similarly.
But I've been thrashing about in circles about how to implement the ROM emulator, and haven't settled on a final design yet.
I'll keep an eye out for your pictures.
-
Ive repaired a few old type boards in my time and found the 138 chip and 244/5 are quite prone to failure might not apply to these boards but worth a try
-
Ive repaired a few old type boards in my time and found the 138 chip and 244/5 are quite prone to failure might not apply to these boards but worth a try
Since everything is socketed, I've tried replacing every chip that I had/could get spares for.
I should have kept a record of which were swapped, but I'm almost certain that the 244/5's were, and highly likely the 138/9's were also. -
>Since everything is socketed, I've tried replacing every chip that I had/could get spares for.
My suggestions:
- Rather than replacing chips, *remove* all socketed chips that are not essential to basic operation. Especially the DMA chip. Then run with either the NOP generator, or burn simple test routines into an EPROM.
- Slow down the clock to the minimum that is supported by the parts (i.e. 100 KHz, or whatever). Remove the xtal and drive U17.1 with a suitable function generator. If you don't have a function generator, whip something up with a 555 timer (or similar).
- Assuming that you can see some basics that are working, make your test code more sophisticated by using the 6551 to output debug information. Output single letters as "checkpoints", to find out exactly where things go bad. You can learn a LOT about the state of things this way. Along this line of thinking, verifying the 6551 should happen before messing with RAM and other things.
Pete
-
My suggestions:
I did remove all the major/non-essential chips, but my idea of "essential basic operation" was to get something sensible on the video.
- Rather than replacing chips, *remove* all socketed chips that are not essential to basic operation. Especially the DMA chip. Then run with either the NOP generator, or burn simple test routines into an EPROM.
- Slow down the clock to the minimum that is supported by the parts (i.e. 100 KHz, or whatever). Remove the xtal and drive U17.1 with a suitable function generator. If you don't have a function generator, whip something up with a 555 timer (or similar).
- Assuming that you can see some basics that are working, make your test code more sophisticated by using the 6551 to output debug information. Output single letters as "checkpoints", to find out exactly where things go bad. You can learn a LOT about the state of things this way. Along this line of thinking, verifying the 6551 should happen before messing with RAM and other things.
Pete
But I do like your idea to achieve that via the serial port instead, being simpler and not requiring the RAM to work. I'll give that a go.
It's been put away for now, but I'll also be trying the NOP generator next time I look at it.
I was trying to avoid the burning EEPROMs merry-go-round with a ROM emulator, but I've been thrashing about on the design of it, discarding my "final design" many times and restarting. For the effort I've put into that, burning a bunch of EEPROMs would have been much easier after all. Let's see if it ever gets finished it before I next look at the Uniboard, or if I finally give up and just go for EEPROMs.
Why do you suggest slowing the clock? To uncover marginal timing issues, or to make things easier to see? I don't think I'll bother with that unless there are problems with even the very basic stuff, but I'll keep it in mind as a possible angle of attack.
Thanks for your suggestions.
-
I was trying to avoid the burning EEPROMs merry-go-round with a ROM emulator, but I've been thrashing about on the design of it, discarding my "final design" many times and restarting. For the effort I've put into that, burning a bunch of EEPROMs would have been much easier after all. Let's see if it ever gets finished it before I next look at the Uniboard, or if I finally give up and just go for EEPROMs.
EPROMs or EEPROMs or emulator: I've thought about making an emulator also, but never started it. Instead I made an EPROM/EEPROM burner, as a daughter board on an MSP430 eval board (T.I. is my fav MCU vendor these days). I know you have Arduino experience.
Why do you suggest slowing the clock? To uncover marginal timing issues, or to make things easier to see? I don't think I'll bother with that unless there are problems with even the very basic stuff, but I'll keep it in mind as a possible angle of attack.
My burner is mostly just wires going to a ZIF socket, but with two additions:
1) clamping diodes on the Data Bus lines, since the MCU is 3.3V, but the PROM chips are 5V. This protects the MCU, and everything works fine.
2) Two pairs of transistors to allow the MCU to control the 5V power to the PROM, and to control the Vpp.
The MCU has lots of non-volatile memory in-chip, so I can download up to five 8KB images that are stored inside the burner. The burner is powered by 5V USB power, except for the Vpp required for UV EPROMs - I do that with a bench power supply (thought about putting a boost regulator on-board, but realized that I won't actually do EPROMs very often - mostly just EEPROMs). The burner currently supports EEPROMs (2KB and 8KB), and three types of UV-erase EPROMs. I wrote a simple C++ program to run on my PC, to download/upload image files to/from the burner via the USB virtual COM port. For example, I write MACRO-11 code for my LSI-11 system, assemble it on the PC in a DOS window, download the image to the burner, and a couple minutes later I have a chip ready to test. I burned a pair of 2716's with some bootloader code, installed in an MXV11 module in my LSI-11.
I can share any of the details of this setup if you're interested.
Slowing the clock: Yes, to eliminate(?) any possible timing issues, and to make it easy to see the details of bus transactions (unless you have a suitable logic analyzer). Probably more useful on a homebrew board, not so much on a "known-good design". Some old MCU's (such as the DEC T-11) let you slow the clock to "0", so you can see all bus activity at your leisure.
Pete
-
One other thing: You mentioned false interrupts. I would take steps to disable ALL interrupts (in HW) until you know that more things are working correctly.
Pete
-
Good point about slowing the clock so that (slower) logic analyzers can see everything.
I have one of those (TL866C?) MiniPro programmers, though I haven't used it burn any EPROMs yet.
The 6809 inhibits interrupts at reset, so simple test code snippets that do nothing to enable them should work fine.
Still blundering about with ROM emulator PCB design... -
Might have posted in the wrong place, but ... i put a reply right after the Color Computer posts...
Thx,
-Matt W0MJ -
Returning the discussion to here from: https://www.eevblog.com/forum/vintage-computing/tryout-and-teardown-of-two-tandy-colour-computer-2s/msg3063376/#msg3063376
I've just come up for air from PCB design (which is mainly to help with these two 6809 systems), and there's been some good progress, I'm glad to see.
Your first picture shows two familiar sights: another Uniboard, and its faulty display.
Congratulations on getting it working!
I've removed and re-seated all (I think) the ICs, but did not do the eraser and Deoxit thing (I must get some of that stuff). My DIP switch is also definitely dodgy, so I'll be replacing that.
Can't help you with the keyboard chip, but it sounds like you're well on the way to sussing it out.
BTW: Did you see this monitor ROM disassembly, partially commented, that I posted to Pastebin? Might be helpful: https://pastebin.com/yNnw5Fuh
-
Uniboard EPROM monitor: I used a SWTPC 69K 6809 system with Dynamite disassembler (Thanks, Phil!) to 'bust' the monitor EPROM... and have added comments as i find things and make changes.
Replaced the U32 and U40 PAL sockets with 'machined pin' sockets and i was able to select the FDC chip and 'start' the diskette drives, but no data read.
i used the monitor command R(ead sector) to test, and when i saw data i tried B(oot).
The last key to the puzzle was the buffers from the FDC to the drive, U29 (74LS241, a few bad buffers) and U88 (7406 also bad buffer), re-seating U51 (the WD1691); and strapping the drives correctly (BOOT ERROR message).
Made a cable for one 5.25" drive and one 3.5" drive, and copied everyrthing i have for the Uniboard over to 3.5" diskettes - reliably boots now.
Keyboard is next, then the open-frame monitor...
Last, to mount the Uniboard, power supply, keyboard and monitor on a piece of plywood, so it will not be a haywire setup.
Let me (us) know how it goes, when you get back to it.
Color Computers - i was a Radio Shack CSR (6616-02) in the late 1970's, and used Dynamite to 'bust' the CoCo EPROM in 1979 or so (it was a development copy of the code, Phil L. is a college friend). It helped figure-out the SAM chip, and others, and what they did; and the external cartridge port .
i also did a lot of programming on the Model-II and Model-III - in BASIC and assembler (my native language!).
-Matt W0MJ