Quantel Paintbox & 68000 CPU Bus Errors - Page 1
Forum section: electronics / repair

author: dexters_lab
author_rank: Unknown
timestamp: May 18, 2016, 09:28:18 pm
content: i recently picked up a Quantel Paintbox system that is non-functional and i'm looking to fix it upthe paintbox is a broadcast tv / video graphical painting, effects and animation system used worldwide in the 80s and right through the 90sthe unit i have is called Harriet and dates from 1989 from their 2nd generation v-series of hardware, which is basically a load of custom asics, a crazy amount of ram and a motorola 68010, it powers up and boots into a ROM based monitor which is only accessible from a rs232 port, from there it reports a bus error and doesn't boot the main software on the hard diskbefore i start getting into this properly, is there anyone out there with any kind of hardware docs for the paintbox? i know it's a rare beast so this is a long shot but you never know!

author: TerraHertz
author_rank: Super Contributor
timestamp: May 20, 2016, 04:48:46 am
content: Wow. I was working at Fairlight Instruments on their vastly cruder 'Computer Video Instrument' at that time, and was in awe of the Quantel Harry. Saw one in operation at a trade show. How did you get it?Whether I ever obtained any service info on the Harry series, I can't recall. It's unlikely but faintly possible. Will have a look.Pester me if I don't get back with a yes or no in a couple of days.The sad thing is, when Fairlight were looking into doing something better than their CVI, I did a system plan for a video processing 'leggo blocks' architecture, that would have slain both the Harry and a lot of other products at that time. Unfortunately the Fairlight management couldn't grok it. Thought it was 'too complicated' - but really it was much simpler than Harry and other ideas that had been suggested. I just made the mistake of trying to present too many different possible configurations to target different markets with no extra manufacturing cost. Just plug the modules together... They were all Audio Synth guys, and it confused them.With a good product like that, at that time, the company might still be around. Looking at you, Peter Vogel.Faintly related & amusing. When Fairlight was going into receivership, the office pot plants were given to any staff who wanted them. Better than leaving them to die, unwatered. I got a small palm in a pot, about 3 feet high.Pic is that palm in my back yard today. The building adjacent is two stories high.

author: dexters_lab
author_rank: Unknown
timestamp: May 20, 2016, 06:26:14 am
content: one of my youtube viewers offered it to me and we did a swap, he took the NAC HSV-400 high speed camera i looked at a month or so back and i had the Quanteli think Harry is the model down from Harriet it has everything sans the ramcorder, but i'm not sure. There is so little info on them it's really hard to know!The insides seem to be modular, so the higher models just get more cards plugged into them but i also think there were many options which were just softwarei have made a little progress with it, i'll make another post about it and start documenting

author: Dubbie
author_rank: Unknown
timestamp: May 21, 2016, 02:54:03 am
content: I remember using one of these back around '99. Why are you bothering to fix it? Just for the fun of it? It would be worse than useless these days.Sent from my phone using Tapatalk

author: dexters_lab
author_rank: Unknown
timestamp: May 21, 2016, 08:20:03 am
content: yea, just fixing it for funalso would be nice to play around with it, show people what it can and can't do (if i can get it working that is!)i guess the hardware had changed again by the time you were using the paintbox, don't suppose you can remember any details about the one you used can you?

author: Dubbie
author_rank: Unknown
timestamp: May 22, 2016, 10:04:44 am
content: Quote from: dexters_lab on May 21, 2016, 08:20:03 amSorry any knowledge I may have had is well lost to the mists of time!

author: dexters_lab
author_rank: Unknown
timestamp: May 26, 2016, 01:57:13 pm
content: so i have been doing a little more work on this trying to get to grips with iti'm going to detail what i do know below, but if anyone has any ideas or suggestions as to where to start with the bus error tracing that would help enormously. I have tried to get schematics but have been told i can't have them due to NDA nonsense.The hardware is 6 boards that plug into a backplane, looks like VME to me, but i don't know if it follows the spec. One board is the CPU, the other 5 are 'PERSP', 'VIDEO IN', 'VIDEO OUT', 'MAIN STORE 2' & 'DISC STORE 2'. All cards date from around 1989.So if i concentrate on the CPU board as it's more probable the fault lies on this board than the others.It's motorola 68k architecture, using a 68010 CPU and a 68450 DMA controller clocked at 10mhz from a 40mhz oscillator. ROM is a pair of 27C512 EPROMs, RAM is 32 of Fujitsu MB814100-80 (4mbit by 1 bit), there are also two battery backed SRAMs providing 4kbyte of NVRAM (the batteries are flat and they are blank), I/O is provided by two MC68681P Dual UARTs, MC68901 MFP and two WD3393 SCSI controllers.There is a debug serial port on the board and a hex display indicator.When powered the system would normally boot into the ROMs which would bootstrap the main OS from the SCSI hard disk, this of course doesn't happen but instead it drops into the ROM debug monitor and reports a Bus Error to the output.The ROM monitor is accessible from a serial port at 19200/8/N/1, it has a small menu where you can query and write memory locations, manually boot the system, jump and execute code in rom or ram and a few other tasks. I'm connected to this through a USB -> Serial adaptor.What I Do Know:Checked the easy stuff, PSU voltages, reseated ICs & the boards, checked the PCB fuses, physical damage etcThe machine was booting while in the possession of the previous owner, the OS was reporting the SRAM/NVRAM was invalid so the unit was opened, it was after this point it started showing the bus error.The ROM code starts at 0x000000, initialises and tests RAM and does a bit of reading and writing of presumably hardware registers before it begins the boot process, it's in this stage it bus errors which is about 100ms from the release of the reset pin on the CPU.Manually navigating around memory, i can access any part of the ROM, various (large) parts of the 24bit address space / RAM generate bus errors if i attempt to read them but it's always the same locations whenever it's powered on. They don't randomly move about each time it's powered.I do have partial disassembly of the ROMs thanks to a kind YouTube viewer.I have checked the bus error circuit and it does seem to be working properly, it uses a counter which is continually reset by valid activity. Without any activity one of the output stages asserts the BERR pin on the CPU which then traps into the ROM and the bus error is reported.Unfortunately i don't have a logic analyser, only a couple of scopesany thoughts on how i should proceed?

author: PA0PBZ
author_rank: Super Contributor
timestamp: May 26, 2016, 02:16:15 pm
content: What happens if you try to boot it after removing (some of) the other boards?What exactly does the bus error circuit do, can it be fooled into thinking everyting is fine/can you isolate the BERR pin?I know you will probably not get a working system by defeating the bus error logic but it could maybe tell you a bit more about what's going on.

author: dexters_lab
author_rank: Unknown
timestamp: May 26, 2016, 02:43:02 pm
content: Quote from: PA0PBZ on May 26, 2016, 02:16:15 pmi took out all the other boards and get the same resultsQuoteit flags a pin on the CPU called BERR if the bus hangs up for some reason, this makes the CPU abort and jump to an exception vector, which is in ROM.I have tried isolating BERR but the system just hangs up, it doesn't do anything at all... which is not surprising.Quoteindeed, it was the first thing i thought of checking too, if the bus error was maybe a false positive. But no, it seems to be real

author: Tomorokoshi
author_rank: Super Contributor
timestamp: May 26, 2016, 05:22:35 pm
content: Manuals are here:http://www.nxp.com/search?client=nxp_search_all_results&site=nxp_en&proxystylesheet=nxp_search_style_fe&sort=date%3AD%3AL%3Ad1&oe=UTF-8&ie=UTF-8&ud=1&output=xml_no_dtd&exclude_apps=1&callback=ss_show&lang_cd=en&filter=0&getfields=*&baseUrl=http%3A%2F%2Fwww.nxp.com%2Fwebapp&SEARCH_OPERATOR=Contains&attempt=-1&rc=1&hl=en&dnavs=&q=68010The last one is the "MC68000UM.pdf" users manual. Part 5.4 through 5.6 has information on the Bus Error.Is any address information provided in the monitor?Generally the bus error is a timeout if an external device did not assert *DTACK. There are a couple common ways for *DTACK to be asserted:1. By address decoder logic that asserts the *CS to something.2. By logic in a peripheral that needs time to do processing after being selected by its *CS.*BERR might be asserted by either some kind of watchdog circuit or by some kind of error detection circuit. With 2 banks of 16 Zig-Zag memories I'm guessing that it does not have a parity bit for memory.Are those ST parts on the processor board battery-backed SRAM?

author: PA0PBZ
author_rank: Super Contributor
timestamp: May 26, 2016, 06:08:25 pm
content: After a BERR the stack should contain the PC and the offending address, but even if you can dump the stack it will not tell you a lot without at least a memory map of the thing or many hours with IDA and the ROM dump. On the other hand you say that the previous owner opened it because of the NVRAM error and that's when it started. Are you still in touch? Can they remember anything they did what could cause this behavior? That would be the best direction for now, considering the lack of documentation.

author: timb
author_rank: Super Contributor
timestamp: May 26, 2016, 06:33:11 pm
content: Dexter, do you want a logic analyzer? I've got a late 80's vintage Sony/Tektronix analyzer I can send you. It's a small unit and I've only got one pod for it (you can pickup a second on eBay for ~$10). It does serial, parallel and signature analysis.

author: Tomorokoshi
author_rank: Super Contributor
timestamp: May 26, 2016, 06:41:11 pm
content: Looking at the hi-res picture:1. The NOVRAMs are different. Was one replaced? Is the replaced one legitimate or counterfeit? If original is it still working?2. A lot of memory-mapped devices seem to have a jumper on a "BSx" terminal. However, there is not one on the 16 x 2 Zig-Zag memory bank. Perhaps a jumper there will indicate something.3. What is going on with the rework by the 10 MHz crystal?

author: dexters_lab
author_rank: Unknown
timestamp: May 26, 2016, 06:50:12 pm
content: Quote from: PA0PBZ on May 26, 2016, 06:08:25 pmyes i am still in contact with them, they have been helping me, he claims he touched nothing and only opened it to gain access to the internal serial port that i'm usingi am not too concerned with looking at the exact details of the software and what it was doing, from my checking i would say more than 50% of the installed ram is not accessible because of the bus error so i recon there must be something fundamentally wrong with the logic gluing it together

author: dexters_lab
author_rank: Unknown
timestamp: May 26, 2016, 07:05:55 pm
content: Quote from: Tomorokoshi on May 26, 2016, 06:41:11 pmboth appear to be blank, they look fine to me. The date/batch code look slightly different... butQuotei noticed this too, i will buzz these pins out and see what they connect toQuotewell spotted! That is a small link that connects the binary counter i mentioned earlier to an inverter to assert the BERR on the CPU, without it the CPU never sees any BERR. It does seem to be intentional, there are two vias that come up and don't go anywhere. Myself and the previous owner speculated it's there for debugging purposes but not 100% on that, there's flux around it from when i removed and reinstalled it to see what happened.

author: dexters_lab
author_rank: Unknown
timestamp: May 26, 2016, 07:14:18 pm
content: Quote from: timb on May 26, 2016, 06:33:11 pmthanks Tim, how small is small? - Thinking about postage costs...

author: timb
author_rank: Super Contributor
timestamp: May 26, 2016, 07:23:50 pm
content: Quote from: dexters_lab on May 26, 2016, 07:14:18 pmForgot you were in the UK! Let me measure and weigh it. From the US to UK, I imagine ~$30 via Parcel Post, as it's not that heavy, but let me verify.If it's much more than that, you might be better picking up something like a Saleae unit.

author: PA0PBZ
author_rank: Super Contributor
timestamp: May 26, 2016, 07:53:06 pm
content: Quote from: dexters_lab on May 26, 2016, 07:05:55 pmWell spotted! It should not take a lot of time trying a jumper on both positions and see what happens.

author: Rasz
author_rank: Super Contributor
timestamp: May 26, 2016, 08:31:23 pm
content: Quote from: dexters_lab on May 26, 2016, 01:57:13 pmlove your YT channelits like Daves one from 4 years ago before he got fat and lazyQuote from: dexters_lab on May 26, 2016, 01:57:13 pmhttp://www.seeedstudio.com/depot/preorder-open-workbench-logic-sniffer-p-612.html?cPath=75ZX spectrum memory bus debugging with this thing:its highly underrated due to somewhat crude opensource frontend, but does the job at a fraction of the price.

author: dexters_lab
author_rank: Unknown
timestamp: May 26, 2016, 10:29:59 pm
content: Quote from: Rasz on May 26, 2016, 08:31:23 pmlol, thanks!Quoteinteresting, i'll take a looki would probably look at one of the 32 channel hantek units, but i'm always open to suggestions

author: Anks
author_rank: Frequent Contributor
timestamp: May 26, 2016, 11:48:05 pm
content: When you isolated the BERR line did you force it high or low or just leave it floating? Regardless if this really is a bus error and isn't the ram it's the logic in between. You need to force pins high and check there output. I fixed many a logic board that I had no schematic for using reasonable logic. You look at it and you will have 74x255 etc chips doing the bus multiplexing. Either something is stuck or the ram is fucked.

author: dexters_lab
author_rank: Unknown
timestamp: May 30, 2016, 09:18:54 am
content: Thanks for all the repliesSo i have been looking at this a bit more, it is a bit of a royal PITA it is huge thing filling my desk and is also designed to be force air-cooled which only happens when the two halves of the box are together... the video in and out boards seem to get steaming hot so i have a large pedestal fan running right next to me trying to keep it cool while it's turned on.Quote from: Anks on May 26, 2016, 11:48:05 pmthere is an inverter after that link and before the CPU so the BERR pin itself would not have been floating, but the input to the inverter might have been. But yea i am just struggling a bit as i have never attempted anything like this before so it's a steep learning curve!So here is what i did:setup my scope with the ext trigger input onto the BERR pin, CH2 onto the AS (Address Strobe) line and i can use CH1 to see any of the other lines. So i can correlate AS to anything else. I thought to read out what the address & data bus when it BERR. With that setup i can scroll back on the scope about 6.5us after the BERR i can find the last AS transition and the state of each of the other pins.it looks like it's a write of 0x64 to 0x7CB000, but that doesn't really tell me anything anyway and reading/writing to this address using the serial console works without any BERRif anyone has tips about how to look at the glue logic?

author: SL4P
author_rank: Super Contributor
timestamp: May 31, 2016, 04:28:29 am
content: I know this is probably be irrelevant and too simple - but a lot of that era gear - despite being a common-buss backplane they were 'slot-specific'. So make sure that you have all the modules (e.g. disk controller etc), and they're in the 'right' slots...!Sorry for dragging the conversation down a step - but I knew a couple of techs back in the day - that didn't really 'get' this !

author: dexters_lab
author_rank: Unknown
timestamp: May 31, 2016, 09:17:14 am
content: Quote from: SL4P on May 31, 2016, 04:28:29 amall suggestions welcome!AFAIK they are all in the right slots, the previous owner has had a couple of these units so i can only assume they are correct! Although the cards are marked, the slots are not.complete lack of hardware documentation makes it difficult to know simple things like this

author: TerraHertz
author_rank: Super Contributor
timestamp: May 31, 2016, 12:00:06 pm
content: The first two pics below are definitely in the 'not helpful, shut up' category. CPU emulator pods for the 6809, 68008, 68000 and 68010 CPUs. These work with a HP 1630G logic analyzer (and the disassemblers on disk), and I got a lot of use out of these over the years. Too bad you don't live nearby, as you could borrow them. But not going to ship overseas.What might be helpful, is a tip for looking at digital system bus, with a simple hack that lets you see where individual bus lines are tristate and where driven.Normally when you look at a running bus with a scope (or logic analyzer) when a line is floating where it should be driven, you can't tell. Because the intervals are so brief that the signal just drifts at approximately whatever last voltage it was driven to.The last pic is of a couple of improvised 'does it float?' probes. Each one has two wires to the tip; one direct and one via a 1K resistor (inside the probe, next to the tip.) Yes, they are made of biro pens, and the tips are gramophone needles soldered into the brass pen point. In use you connect the direct one to a scope input, and the 'via 1K' wire to the output of a signal generator. Set the sig gen to sine or triangle output, with the p-p range between zero and 3V (for 5V TTL), and freq doesn't matter much. Say 10KHz.When you put the probe on a bus pin, the 1K series resistor is too high to upset the correct logic drives. (Actually one of those probes has a button to select between 10K and 1K series R, for picky circuits.) But when the bus line is floating, the oscillator drives it up and down, async to the bus operation. This should not make any difference to the digital system's normal operation.Visually on the scope, the result is that tristate intervals on the bus look 'shaded-in'. It's very obvious,and quite useful.You can run along the address and data bus, and look for any that seem particularly different to others. Best if you can trigger the scope on some CPU action, such as reads or writes to a particular device.This little thing is good for when looking at something for which you have zero documentation. Like your Harriet.Btw, I checked and couldn't find any info on it in my archives.Oh, and you can look up the data for major chips on the board, find which are their chip select lines, and use a logic probe or scope on single shot, to see which ones are ever accessed during startup before the bus fault. If you can find one that is accessed right when the bus fault occurs, that should be a good clue. Can do this with a scope: channel 1 & trigger on the CS, ch 2 on the buserr. Which might be asserted some way into accessing the chip (or address range.)Can you tell if the ram banks have parity error checking?I think the worst case could be that one of the many PALs has died. Something to do with address decoding or bus logic. Have you checked the usual bitsavers, etc sites to see if anyone posted data on this machine?Edit: forgot to mention that the oscillator hack works with an analog scope, that visually averages many traces. Digital ones would need to be set to an equivalent averaging mode, if available.

author: CJay
author_rank: Super Contributor
timestamp: May 31, 2016, 02:50:54 pm
content: Quote from: dexters_lab on May 30, 2016, 09:18:54 amI find it suspicious that BERR is set on a boundary like that, especially as you can write to it without causing BERR, are you sure 0x7CB000 isn't a memory mapped peripheral that it's trying to set up and be ACK'd on/from one of the peripheral cards (would explain why it happens with no cards installed too)?Might be worth writing a simple memory test in the monitor to get some idea of how the memory is mapped and how much the CPU can 'see', then tally that up to the amount indicated by a count of the chips?

author: TerraHertz
author_rank: Super Contributor
timestamp: May 31, 2016, 04:08:57 pm
content: Another idea: if you improvise something to cause a reset pulse triggered by BERR, the board will continuously cycle through the process leading to the fault. This makes for easier poking around with a scope.At the very minimum, it will show if the stages and timing are identical each cycle.

author: dexters_lab
author_rank: Unknown
timestamp: June 02, 2016, 09:04:59 pm
content: Quote from: CJay on May 31, 2016, 02:50:54 pmi have a guy in .AU doing a sterling job of disassembling the rom code which is helping a lot to build a memory map. Every day reveals new info.He believes that ram starts at 0x800000 which is exactly the same spot as the 1st generation paintbox. There is no MMU on the system (we have a DMA controller though) so we have only 16Mb of addressable space yet ram starting at 0x800000 means we have 8Mb until we hit ramtop. Yet we have 16Mb of dram installed on the CPU board (and more on the peripheral boards), so we think there is some banking going on but we're not sure how that's working yet.your thoughts on the BERR could well be the case... just don't have enough info at this point

author: dexters_lab
author_rank: Unknown
timestamp: June 02, 2016, 09:15:12 pm
content: Quote from: TerraHertz on May 31, 2016, 04:08:57 pmgood call, especially if i want to debug the logic

author: valgamaa
author_rank: Contributor
timestamp: June 03, 2016, 10:35:13 am
content: Quote from: dexters_lab on June 02, 2016, 09:04:59 pmThere is 16Mb of RAM, which gives you 8M words, as the bus is 16 bits wide. What you are detecting is therefore correct.

author: Rasz
author_rank: Super Contributor
timestamp: June 03, 2016, 11:31:40 am
content: Quote from: valgamaa on June 03, 2016, 10:35:13 amprocessor has 24 bit address bus and you need to fit everything there, that means ram, peripherals, exception vector table, firmware roms etcobviously there is some banking involved or part of ram is only reachable thru intermediaries (like on TMS9918 video controller for example)

author: dexters_lab
author_rank: Unknown
timestamp: June 03, 2016, 11:53:29 am
content: Can you have 16mbytes of word addressible ram, thereby halving the address space needed and making use of the 16 bit data bus?

author: valgamaa
author_rank: Contributor
timestamp: June 03, 2016, 01:33:31 pm
content: Quote from: Rasz on June 03, 2016, 11:31:40 amAgreed that the address bus is 24 bits (32 actually, but only 24 were bonded-out), but the data bus is 16-bits wide. As a result you have 16Mb of addressable memory, which is arranged as 8M*words*.Edit: Just remembered that only 23 address lines are bonded-out (It's 20 years since I last used a 68000), so I see the issue now. With memory starting at 0x800000 with 24 address lines there would not be a problem.The 68000 had a bus operation that required the destination (memory, peripheral) to acknowledge the data to complete the cycle, so the time-outs you are seeing may be due to the processor writing to an unexpected memory location. Are you able to capture the address value when the error interrupt is generated?

author: CJay
author_rank: Super Contributor
timestamp: June 03, 2016, 02:55:49 pm
content: Quote from: dexters_lab on June 02, 2016, 09:04:59 pmGiven that RAM starts at 0x800000 and BERR is asserted on a write to 0x7CB000 then that is to my mind fairly good proof that the CPU is trying to talk to a peripheral and not a RAM location, I'd definitely be trying to trace out the BERR logic at this point to see what could be triggering it.As the 68K is fully static it is possible to single step it so you can work out which peripheral you're looking at by single stepping it and watching control lines on peripherals.It occurs to me that it may be possible to single step the BERR/DTACK logic and work out where the signals come from

author: Rasz
author_rank: Super Contributor
timestamp: June 03, 2016, 03:08:34 pm
content: Quote from: valgamaa on June 03, 2016, 01:33:31 pmall 24 bits are usable, A0 is just replaced by UDS and LDSmore on memory addressinghttp://webpages.uncc.edu/~sjkuyath/MC68000/decode.htmseriously, $50 logic analyser would solve this mistery in one evening/weekend

author: bktemp
author_rank: Super Contributor
timestamp: June 03, 2016, 03:29:19 pm
content: Quote from: CJay on June 03, 2016, 02:55:49 pmAccording to the datasheet a clock frequency of at least 4MHz is necessary. I have tried it myself, and below a couple of 100kHz the processor stops working correctly.

author: Rasz
author_rank: Super Contributor
timestamp: June 03, 2016, 03:51:24 pm
content: Quote from: bktemp on June 03, 2016, 03:29:19 pmnot all 68K were static, C variant was late in the game, but you can step one instruction at a time with HALT inputstill (and again) why bother when even cheapest logic analyser can stream whole bus into your computer over USB 2.0

author: CJay
author_rank: Super Contributor
timestamp: June 03, 2016, 05:57:46 pm
content: Quote from: Rasz on June 03, 2016, 03:51:24 pmNope, you're right, getting mixed up with the bondout variant on the ICE I had back in the day.Yes, a reasonable LA would really help but working with the tools he has is fun too.

author: dexters_lab
author_rank: Unknown
timestamp: June 03, 2016, 08:04:02 pm
content: right, ok ok, logic analyser then!was eyeing up the hantek 4032L

author: CJay
author_rank: Super Contributor
timestamp: June 03, 2016, 09:34:49 pm
content: Quote from: dexters_lab on June 03, 2016, 08:04:02 pmYou'll thank us when you have shiny new toys to play with.

author: dexters_lab
author_rank: Unknown
timestamp: June 11, 2016, 09:15:03 pm
content: so my Hantek 4032L logic analyser arrived and i have done some more workthe faulting memory address i found has been confirmed to be what i thought, though i had not understood the UDS and LDS signals so the address is not 7CB000 but F96000, close to a whole load of other mapped peripherals we have already identified at the upper regions of the address space.there are a few places in the address space that cause a BERR which all seem to correlate to a set of 2 or 3 address lines so i am hoping i will find some duff jellybean 74x when i start looking at them in a few daysone thing i can't get to work on the LA is the advanced triggering, it would be nice to trigger on an a value based on the address lines but i can't seem to get it to work, anyone have any experience with the 4032?

author: Rasz
author_rank: Super Contributor
timestamp: June 11, 2016, 11:14:34 pm
content: Quote from: dexters_lab on June 11, 2016, 09:15:03 pmyou said that in last video and it hit me, last owner probably removed all the cards, one of the connectors must of cracked solder joints. 7400 logic dying just because someone looked at it funny is not common. Have you buzzed all the bus connectors with continuity tester?Quote from: dexters_lab on June 11, 2016, 09:15:03 pmthis is why I recommended barebones Openbench Logic Sniffer, app might look shitty, but it has amazing triggering capabilitiesI seem to remember there being independently developed app for the hantek somewhere?another alternative is usb streaming LAs (saleale and clones) where you dont need any triggers because you capture all of the things and can filter later in python/excel/whatever you fancybtw just learned USBee maker CWAV went bankrupt last yearhttp://www.usbee.com/company.htmSo saleaelae $200 USB logic analyser killed CWAV, and now $100 chinese LAs are killing Salaeae, ah the circle of life.

author: dexters_lab
author_rank: Unknown
timestamp: June 12, 2016, 10:31:53 am
content: Quote from: Rasz on June 11, 2016, 11:14:34 pmhe assures me he didn't remove or change anything other than a hex switch. The PO did have an identical working system so he knew what he was doing with it, it was opened to change a hex switch selector that tells the rom not to autoboot but to go into the serial monitor so he could deal with the flat batteries in the NVRAMSadly there are 1,152 pins on the backplane connectors spread across the 6 boards, so yea... i don't fancy that option yetQuotesigrok has support for the 4032L planned

author: Rasz
author_rank: Super Contributor
timestamp: June 13, 2016, 11:54:15 am
content: Quote from: dexters_lab on June 12, 2016, 10:31:53 amI mean someone on eevblog wrote alternative app for hantek, just not sure which model

author: SeanB
author_rank: Super Contributor
timestamp: June 13, 2016, 06:16:55 pm
content: Mark, got around to watching your video today, very nice machine there. Looking at the storage boards I can guess the 6 big PLCC chips are used with the ram chips, 8 per PLCC, to implement a emulated 1M by 16 static ram on the bus. this is likely the framestore on the unit and the playback memory for the stored images and effects.3 banks of 6M of memory over the 2 storage boards, with the small SRAM section being the current frame and next frame store for the video DAC to play out while getting the following frames and doing the effects on them in real time. 2 SCSI interfaces so you can have 2 concurrent disk IO operations using DMA to read from the external drive for the video data ( slow SCSI drive and uncompressed video there) while getting the operation sequence from the internal drive.Have you tried the simplest thing of trying pressing down on all the PLCC socketed chips and seeing if any creaked a little and seated further in the socket. That might be the reason one bank is not reading correctly as it is missing a signal due to a poor contact in the socket.

author: dexters_lab
author_rank: Unknown
timestamp: June 13, 2016, 09:09:18 pm
content: thanks Sean,i have tried re-seating all the socketed ICs with the exception of the plcc's on the store boards. Although i have a plcc extractor tool these sockets have eject holes on the base of the socket not in the top like normal and i can't get anything in there to pop them out. They have been pushed home though.i did wonder if the sram might be the framestore, it's about 2x the speed of the dram and i wondered if they could read out the frame in between the main clock but it's not big enoughi think there is more magic happening in those quantel ICs, having watched a few videos of the paintbox in use it is very fast. In my experience with atari's i would say it's faster than a 68000 should be able to handle, even if it was all written in assembleri might have a lead on some documentation though, a former quantel designer has responded to a post on another forum, fingers crossed

author: Astrodev
author_rank: Regular Contributor
timestamp: June 13, 2016, 10:11:34 pm
content: I have just come across what you are doing and used to have dealings with Quantel way back as the company I worked for used to supply them with peripherals that they integrated into the systems.But reading through the posts made me remember a really peculiar fault we used to get on a 68010 based system that used to have battery backed SRAM modules with integral non rechargeable batteries, what seemed to happen was that when the batteries went very low but still with some energy in them the SRAM's would end up locking in an indeterminate state and totally screw up the processor as they would put a loading on the data bus that screwed it up causing incorrect data to be presented to the processor, unfortunately I can't see if the SRAM modules are the same or not but they will definitely be the right vintage, the fix we had was to replace them and as this fixed the problem we never went too deeply into why.

author: Tomorokoshi
author_rank: Super Contributor
timestamp: June 13, 2016, 11:23:10 pm
content: Quote from: Astrodev on June 13, 2016, 10:11:34 pmThat reminds me of an incident I encountered a long time ago. It was the first day of my new job, and Mr. L asked me if I knew anything about NOVRAMs. I did not. They were losing their data "randomly", which was used for calibration. Big problem for field service.Another engineer tracked down the problem. It turned out that when turning the system on, there was a brief negative spike on the power supply. This corrupted the data. I don't recall what the fix was, but it may have involved specifying a different supply.

author: dexters_lab
author_rank: Unknown
timestamp: June 14, 2016, 07:51:33 am
content: Quote from: Astrodev on June 13, 2016, 10:11:34 pmthanks for the suggestionalthough i don't have replacements for the nvrams yet i did try removing them completely and it made no difference to the bus error. It was worth a try though.I suspect these nvrams have been flat for a long time. We found some log files on the disk that say it was probably last used about 14 years ago

author: PA0PBZ
author_rank: Super Contributor
timestamp: June 14, 2016, 09:51:42 am
content: Quote from: dexters_lab on June 14, 2016, 07:51:33 amThat could either indicate that the problem is indeed with the nvram or that it occures earlier in the boot routine.

author: CJay
author_rank: Super Contributor
timestamp: June 14, 2016, 10:15:16 am
content: Quote from: PA0PBZ on June 14, 2016, 09:51:42 amI think the NVRAM is a red herring, I'd be of the opinion that the other unit the friend has is also of similar vintage and that the NVRAM batteries would be similarly flat.With some kind of idea where they're mapped in memory it should be possible to read them using the monitor but if not you can verify they work by reading them in an EPROM programmer that supports them (I have one if you need one)You may be able to replace them with a plain old 6116 or similar as a temporary measure

author: bktemp
author_rank: Super Contributor
timestamp: June 14, 2016, 10:48:32 am
content: Correct me if I'm wrong, but from my understanding BERR is generated by the counter when too many wait states are inserted (DTACK not going inactiv).For simple bus devices like SRAMs or the NVRAMs no or only a fixed number of wait states are necessary. Accessing shared memories or DRAM where a refresh cycle could be active, additional wait states are inserted until the memory is ready.Therfore the DTACK signal is generated somewhere depending on the bus address, either by using a simple delay counter or by the accessed device itself. For simple memories the bus shouldn't even notice if the memory chips are removed from the board. I doubt the NVRAMs cause a bus error unless their content somehow affects the bus address being accessed.There must be logic somewhere decoding the bus address and either generating the DTACK signal using a counter or selecting an external wait signal from the accessed device. Most likely one of the programable logic devices is used as a bus address decoder and for DTACK generation.

author: dexters_lab
author_rank: Unknown
timestamp: June 14, 2016, 11:50:12 am
content: yea, it is not the NVRAMs causing the issue, i only tried because it very easy to do. I can also read and write to the NVRAM in the monitor, it works but obviously loses it's memory after a few seconds without power.The BERR happens very early into the boot into the ROM code where it initialises various hardware peripherals and before it checks the NVRAM to be valid.I mentioned before the fault that stops this booting properly is a write access to 0xF96000 which is probably some of the quantel custom devices as we have mapped just about everything else.i've attached my memory map, which is work-in-progress BTW!You'll see there are a few regions of space that cause the BERR and why i am suspicious of A16-A19.It's just a bit of a daunting task for a noob like me to try and do this, but i like a challenge!

author: bktemp
author_rank: Super Contributor
timestamp: June 14, 2016, 12:47:44 pm
content: Quote from: dexters_lab on June 14, 2016, 11:50:12 amWhy do you think A19-A16 are faulty? Some regions may be unused, therefore not decoded and not acknowledged when accessed.Do you know if the address bus decoding for all the peripherals is done on the CPU board or does each card has its own bus decoder looking at a matching address?For decoding the region where the bus error occurs, at least A23-A16 are necessary. I am no expert in debugging computer systems, but I would start at looking for parts where A23-A16 are connected to and see if those parts generate a chip select signal when the region is being accessed (most likely the PALs).Let's assume the region where the bus error is generated is connected to one of the quantel ascis. That means either the chip itself does not acknowlege the bus cycle or the acknowlege signal does not reach the cpu. Possible faults could be the address bus decoder/DTACK signal mux not working correctly.But it could also be a problem with the chip itself: Maybe the accessed asic is not working correctly, because of a missing clock or a stuck reset line?You have to identify the chip mapped to the region and start looking at its signals to see if the problem is the chip itself (or some surrounding circuit) or if there are some problems with the address bus.Without having a schematic or block diagram it is probably hard work to trace all the address lines to each card.

author: CJay
author_rank: Super Contributor
timestamp: June 14, 2016, 01:26:37 pm
content: Quote from: dexters_lab on June 14, 2016, 11:50:12 amI like a challenge too, plus, 680x0, takes me back to the days when I repaired Macs and Amigas for a living.Given the system places the peripherals at 'page' boundaries (I may be using the term loosely) of 0xyyy000 etc. I think it confirms my theory that it's a peripheral not responding or somehow being verified as present (unable to write or read from etc.)So, you've mapped all the identifiable devices, can you trace control lines from the decode logic to the custom devices in the same way you should be able to for the 'known' devices?Are the customs duplicated or is there only one of each in the system?

author: dexters_lab
author_rank: Unknown
timestamp: June 14, 2016, 01:27:45 pm
content: Quote from: bktemp on June 14, 2016, 12:47:44 pmi can't think of a reason why regions 080000 to 0FFFFF and EE0000 to EFFFFF should not be accessible, the physical ram is there for itQuotei don't knowQuoteall very valid points!Quoteindeed, i have actually slowed my efforts in the vain hope that some documentation might come to light

author: dexters_lab
author_rank: Unknown
timestamp: June 14, 2016, 01:36:15 pm
content: Quote from: CJay on June 14, 2016, 01:26:37 pmthe task of finding addresses for the peripherals so far was done through the disassembly of the ROM code, thanks to a nice guy called Nicolas in Australia who offered to help.We have a long list of unknown 0xFxxxxx addresses that are read/written to.on the main board there are a couple of types of PAL and some Atmel PLDs, they all appear to have individual identifiers so i'm guessing they are all unique

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: June 14, 2016, 01:50:58 pm
content: Could it be that it's trying to acess optional peripherals that the corrrupt NVRAM is saying should be present but actually aren't ?

author: dexters_lab
author_rank: Unknown
timestamp: June 14, 2016, 03:43:14 pm
content: Quote from: mikeselectricstuff on June 14, 2016, 01:50:58 pmhi Mikeno, NVRAM isn't read until after this access

author: grumpydoc
author_rank: Super Contributor
timestamp: June 14, 2016, 04:25:18 pm
content: Quote from: dexters_lab on June 14, 2016, 03:43:14 pmOne would hope for a better error message in that case than "bus error"

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: June 14, 2016, 04:28:59 pm
content: Quote from: grumpydoc on June 14, 2016, 04:25:18 pm

author: TerraHertz
author_rank: Super Contributor
timestamp: June 18, 2016, 11:15:47 am
content: I don't suppose you have access to a device programmer that does the PALs and PLDs used?If you are lucky their configuration may be readable. In which case if you can talk your contact with the working machine into letting you read the ones in his machine, you can verify if yours are all working. Another way would be to put your suspect PALs into his working machine (if he's incredibly trusting and the machines are identical.) But I doubt he'd go for that.If you are unlucky, they won't be readable because readback not supported or security bits set.Verifying the PALs would be good, because almost certainly the high address decoding and bus state logic will be done in those PALs.One caution, that I'm sure you'd be aware of without my mentioning, but I will anyway. To read the programmable chip types you'll need to remove (or partially peel) the Quantel part number labels. Don't get them mixed up, as many can be the same chip type. But of course once programmed they are different. Best way is to write the board location on the bottom of each chip as you remove it, and keep a list of board locations, chip types and Quantel part numbers on the labels.From your description of the original 'cause' ("just opened the case to change a DIP switch, and it stopped working, honest") it could be that he static-zapped it with his gerfingerpoken. In which case it could be anything (or multiple things) that's dead.

author: dexters_lab
author_rank: Unknown
timestamp: July 19, 2016, 06:58:08 am
content: video update to this from a couple of weeks agoit's not looking likely i'm going to get the service manual after several possible leads on getting it, looks like the next step might be to start tracing everything out by hand to find where the faulting address physically decodes to. Not something i really wanted to do

author: vaualbus
author_rank: Frequent Contributor
timestamp: July 19, 2016, 08:52:36 pm
content: So have you fine any progressi so far?

author: dexters_lab
author_rank: Unknown
timestamp: October 07, 2016, 03:44:57 pm
content: the saga continues slowly... still no sign of service manuals. I keep still keep getting hints of being in contact with ex Quantel employees but nothing has come of that yet.In a vain attempt to do something i'm swapping out some of the buffers/transceiver ICs for the CPU bus.

author: SeanB
author_rank: Super Contributor
timestamp: October 07, 2016, 07:08:19 pm
content: Tip for those folded pin DIP devices is to simply cut all the legs flush with the board on the IC side, and simply unsolder the stub of folded leg. That saves the board a heat cycle, and then you simply solder in a turned pin socket ( or buy a whole lot of 0.1 pitch SIL turned socket strip and make your own). If you want to reuse the IC simply solder it to a socket ( place it into another so the melting and softening does not deform it too much) and plug into the new socket on the board.Been there, done that, and as the TTL IC generally is a lot cheaper than the board, throwing them away is not too much of an issue.