Login

Forum Help Post Your Message Username: (Login) Topic: Message:   Previous Messages Posted By siz on 2011-03-17 12:12:46  Re: Plus/4 C16 diagnostics and TED partial failure modes That looks good for me. In the case you have no screen nor screen flash "error code" you know that you should try swapping the major chips because at least one of them is most probably faulty. (or something in the address and/or data bus drives) Posted By crock on 2011-03-17 11:17:10  Re: Plus/4 C16 diagnostics and TED partial failure modes The very first test is a RAM test which makes no use of the zero page or stack, so running purely using the 4 available cpu registers. Without a lot of hacks to the address bus (see previous discussions with TLC), the usefulness is limited in cartridge form as the cartridge is bootstrapped by the kernal, at which point we are already relying on the RAM being good as a JSR's puts the return address on the stack. So that is why the optimum solution is to put the diag rom in place of the kernal. When the cpu reset's it starts the machine by jumping to the location stored at ($FFFC.) In the normal kernal this then sets about reseting the TED, working out how much ram is present etc. In my ROM, this is the start location of the RAM test. It writes a test pattern to all locations from $0002->$0fff and then reads back the contents, XOR'ing the result with the test pattern. Any non zero result indicates a fault situation and the screen flashes 'n' times, where 'n' is the lowest bit set in the result of the XOR, identifying which data line on the bus is at fault and thus usually which RAM chip is at fault. There is practical limits to what a rom based solution can achieve. If the CPU, TED or PLA are totally dead - the computer will be completely non functional and the only course of action will be a scope/logic meter or start swapping chips. It will however find RAM, ROM and I/O related problems with good results. rob Posted By siz on 2011-03-17 09:44:54  Re: Plus/4 C16 diagnostics and TED partial failure modes Just to satisfy my curiosity: how do you report failures that prevent screen initialization? For example what happens if you find a faulty RAM chip? I'm really interested. Posted By crock on 2011-03-17 08:36:18  Re: Plus/4 C16 diagnostics and TED partial failure modes After holidays in Tenerife and a week designing a kitchen and employing contractors, I've got some time to continue with this. If there's enough interest, I'll make up sets of dongles for cost price plus postage. I would guess that'll be in the region of 20 euro's which'll get you the serial, cassette, two joystick, user port and 2 keyboard dongles (one for the +4/116 and one for the C16) and the rom. After my conversations with TLC, I've decided that the easiest solution is to supply the ROM on a chip that can either go in the Kernal socket *or* in a generic cartridge if the user has one with sockets. It's easy to modify a standard Commodore cart if you are so inclined. The better option will be to put it in the kernal socket as it'll be better equiped to catch RAM issues. Csabo - had any more thoughts on the TED tests we discussed? Can you reply to this thread or PM me if you'd like a set of dongles so I can guage interest. cheers, Rob Posted By TLC on 2011-02-24 19:01:30  Re: Plus/4 C16 diagnostics and TED partial failure modes Individual Computers used to sell a "universal" prototype board called 8-bit baby (universal = a considerably large matrix through hole board with edge-connectors on its side... it's suitable for C64, Plus/4, VIC-20 and the CBM-II series IIRC... although, you have to modify it a bit in order to use it with the Plus/4 and VIC-20). As for the final, production level board... I have no ideas about a presumably easy way for that. ...Unless you could obtain a series of empty/flexible enough standard ROM cartridge PCBs, you'll need to design a PCB + find some company to manufacture the board. (The pure "oldschool" 2-side through-hole styled design + its slightly larger tolerance requirements may still help keeping costs at an acceptable level even in this case, though). ...Well, after thinking all that over again (and again), I must admit, your original idea (ie. producing the tester in the form of a simple ROM chip replacing the Kernal ROM) has considerably strong advantages here. ...No PCB; avoiding the Kernal Reset routine is evident without any additional fiddling; ...whatever... Posted By crock on 2011-02-24 18:01:06  Re: Plus/4 C16 diagnostics and TED partial failure modes Postscript is/was fine. I just converted it with Irfanview. Some of the labels are a bit tricky to read but no real issue. Biggest issue still the source of cartridge boards... Posted By TLC on 2011-02-24 16:58:37  Re: Plus/4 C16 diagnostics and TED partial failure modes Rob: I did a quick-fix and update just the day after I originally uploaded the file (the second flip-flop was mistakently set by r/w' on the schematics). Another note: the file was in postscript format; I can also supply a png image or the original KiCad sch file if that makes life easier. Other than that, the circuit should work. I also couldn't reduce the component count any further, unless some programmable logic were to be involved (or some functionality sacrificed)... so yes, IMHO it's at a local optimum of some sort ATM Posted By crock on 2011-02-23 18:59:59  Re: Plus/4 C16 diagnostics and TED partial failure modes Thanks for the positive feedback from both Plus4world and Commodore16.com. It's really appreciated! One of the aspects of the design I wasn't happy with was my inability to fashion a KB dongle for the plus4. For the C16 it's easy to butcher a 40 pin IDE cable to use as a dongle but I couldn't find any 'stiff' ribbon cable connectors for a sensible price. I just had this nagging feeling that there must be a suitable bit of 'junk' in the man-cave somewhere! Then, this afternoon, a moment of inspiration: http://www.inchocks.co.uk/c64/P4_keyboard_dongle.jpg Works brilliantly, on the third attempt though. :-/ Someone at C= deserved a slap for not mapping columns 0-7 of the keyboard matrix to ports 0-7 of the 6529 respectively. No - that would have been too obvious ! TLC, are you happy enough with your kernal bypass circuit for me to prototype it? I'll order a couple of logic chips which will hopefully have arrived while I'm away next week. Rob Posted By TLC on 2011-02-23 14:06:39  Re: Plus/4 C16 diagnostics and TED partial failure modes You're obviously making great progress... Posted By crock on 2011-02-22 19:38:34  Re: Plus/4 C16 diagnostics and TED partial failure modes **** As promised, here is a video with a brief description and demo of the diagnostics: **** http://www.youtube.com/watch?v=BCw3PD5cb88 ******* Posted By TLC on 2011-02-18 18:22:12  Re: Plus/4 C16 diagnostics and TED partial failure modes Ambivalent feelings , this time, for similar reasons having had explained by Csabo (I'm also cooking something... not exactly a release, but it takes most of my freetime ATM nevertheless). Though, doing a small sketch won't be hard, I'll see today. (Now gotta leave for my train, sorry ). Edit: having done some sketches, I'm not yet satisfied with the results. As things currently stand, the circuit would take about 3 or 4 TTL chips (a flip-flop, a 8-input NAND, and some NAND and/or NOR gates). ...I feel that a bit overkill. Edit: Hmmm, 2 TTL gates (a 74HCT74 -- dual D flip-flop -- and a 74HCT30 (8-input NAND). I've uploaded a sketch to here. I had to diverge from the original idea a bit. First, realized that if A8 was held low, then there'd be no way to write to $fddx. $fddx is needed to map in the cartridge rom, so bad luck... Second, I spent some time figuring out the "optimal" way of switching the circuit off, once it did its task. At the end, I decided to use both flip-flops of the 7474, and chose some clever way to turn the thingy off. -- Upon reset, both flip-flops are cleared. The first of them is responsible for holding A8 low. This flip-flop will be set, ie. A8 will be released upon the first 0-->1 transition of R/W'. (Ie. after the first write operation). -- The second flip-flop is responsible for enabling the mapping-in of a 256 byte long slice of the EPROM to $fe00-$feff. This slice is decoded by the NAND gate. A8 is not taken into account here -- it's assumed that it is held down by the other flip-flop. The output of the NAND is "wire and"-ed with the original ROM CS' of the EPROM (I assumed C1 LOW', as you mentioned that you're experimenting with a 16k EPROM, and the fact that some EPROM needs to be mapped to $8000 in order to be recognized by the boot process). I could have used an AND gate here instead -- but didn't want to increase chip count, thus this seemingly ugly solution. The resistor might be smaller (2k2?...), 3k3 appeared good. The diodes are small schottkies... I'd presume simple 1n4148s would work equally well here (with slightly larger forward voltage drop... thus the cautiousness). This flip-flop is set by first accessing C1 LOW', _after_ having written something at least once. How this should work? -- The reset vector should reside at $befc/$befd (from your 16k cartridge ROM's point of view). It should point to some address between $fe00-$feff (as, the $be00-$beff slice will be mirrored at $fe00 upon power-up). The first commands of the reset routine must reside on this slice, and the reset vector must point to this routines start address. -- The code should execute some write command first, in order to release A8. The destination of the write should not point to the $fe00-$feff range. -- Map-in your cartridge ROM, by writing to $fdd0 + the bank config number. -- Jump to your code (between $8000-$bfff). The $fe00-$feff ROM slice disappears, as soon as the first byte from the regular cartridge ROM was fetched. ...At this point, you have a "stock" machine, with all hacks switched off. That's all ATM. Posted By crock on 2011-02-17 20:11:13  Re: Plus/4 C16 diagnostics and TED partial failure modes I'll reply in more detail in the morning (it's 02:10 for me) but I love your idea TLC, if it can be cost effective. My thought process is that those who care about their 264's would not break into a sweat if they had to swap out ther 318004 for the diag chip. I personally would love to have a crack at doing it that way though, but I am not a digital circuits guy by trade. If someone could draw up a circuit I'd happily prototype and test it.... rob Posted By TLC on 2011-02-17 06:46:19  Re: Plus/4 C16 diagnostics and TED partial failure modes Some time ago I also bought a couple of 8501s from a Hungarian reseller (hqvideo.hu... I didn't know about this source even though I'm Hungarian and that I used to buy components there sometimes... it was pointed out by Pepax in this forum). They sold "old stock" chips ie. from that last production run (...I assume they kept them on stock for about 20 years... they're the sort of replacement-part resellers... small stocks, very large palette, rare-ish (...and obsolete-ish) components at a slightly expensive price). I bought a small stock for my needs and bought/sent chips to people who asked. By now it looks someone finally bought up the whole remaining stock (by the time I bought 8501 chips there for the last time, which was last summer, they still had around 20 pieces or so). I can only hope that it was someone "amongst us" and not someone with some speculative intents... It's interesting to note that the fact that you could buy that stock from China... well... seem to suggest (...I'm not sure, but I can't find a better explanation) that our Chinese friends could somehow get hold of a number of 264 series machines. ...Should that mean, that a presumably large number of machines ended up there via these dispose/recycle programs of so-called "developed" countries?... ...I feel like the guy in the traditional joke (..."absolute ambivalent feeling" = when your mother-in-law writes off your brand new car in an accident ). ...At least, a lot of valuable chips have been salvaged... Cartridge: although most of us "creative" people usually have more ideas than time/intent to realize them (...at least I assume so ), so we're usually pretty flooded by ideas and don't really need others' (...what we'd need was time and effort instead ), I'd present some ideas that you might or might not use in your design... that's up to you from now. There's the problem of the cartridge relying on the Kernal and (more importantly, because it fails more often) the RAM. You could probably avoid that. The basic idea: the CS' signals are generated by the TED, the PLA, and a couple of TTLs. None of them know about the CPU -- they only know about the address bus. Even if the CPU addresses $fffc, the address bus doesn't neccessarily need to reflect that. Second: the CPU is an NMOS device (ie. generates strong L and weak H levels). You can pull any of its outputs to low anytime, without major (physical) consequences. Let's suppose you intentionally pull A8 low externally, when the reset mechanism starts. What happens? The CPU first reads $fffc, then $fffd. You pulled A8 low. This doesn't harm the CPU, but as a result, the address bus reflects $fefc and $fefd, respectively -- and so will see the whole decoding logic in the machine. $fef0-$feff is reserved for the first 1551 drive TIA -- it's certainly empty space if no 1551 is connected to the machine. In short, first, the memory fetch avoids the Kernal ROM. Kernal' certainly won't be activated. Second, at this point, the fetch reads from nowhere -- but that's only one more step, to map some external ROM here. All in all, the Kernal can be avoided... it only takes some TTL logic to hold A8 low when it's needed, and map ROM to $fe00-$feff (again, when it's needed). I would most probably use an RS flip-flop to hold the internal state. This flip-flop would be activated by Reset' (which is predictably low upon power-on reset). The active state of the flip-flop pulls A8 low through an OC output or just simply a series diode. It also activates a small extra address decoding circuit (might be a greatly simplified one) whose output ANDs with "cartridge 1 hi'", ie. enables the cartridge ROM to be active at $fe00-$feff too, but only if the RS flip-flop is set. The reset mechanism fetches then from $fefc-$fefd ie. your mapped-in cartridge ROM, your program can start in your ROM, and can also turn this little present off. (As a simplification, I'd probably reset the flip-flop by R/W' -- predictably, no writes occur before the CPU attempts to do so, and the code will sooner or later attempt to do that I'd presume --, but it could probably also be done by some decoding logic + respective CPU instruction). With that, the need for a useable kernal rom chip + ram can be avoided... at the expense of a slightly more complex digital logic. Edit: R/W' is probably not suitable (...alone), because the cartridge ROM needs to be mapped in, which already needs writing (...it won't be good to pull the $fe00-$feff rom slice off at the moment the sta $fddx happens... ). ...But you get the idea. Posted By crock on 2011-02-16 19:35:01  Re: Plus/4 C16 diagnostics and TED partial failure modes The ones from China were socket pulls and they were not cheap by the time I payed shipping and Swiss customs charges. It was a painful business and after swapping emails with someone in CHina with very little English, transferring a not insignificant amount of USD into their Paypal account, I thought there was a very real chance I was throwing my money away. You can imagine how pleased I was that I receieved a parcel from Shenzen via DHL three days later. I bought their entire stock of 19 chips. Sadly, as they were pulls and they obviously did not even know what they were, let alone be able to test them, only 11 worked, but that still left me with 11 chips. I have used three to repair my duff ones so I now have 8 spare I think. They were good enough to credit my paypal account for the cost of the non-working ones, but the net cost per chip is probably still more than most would be willing to pay, so I'm not going to look to sell them for profit. Interestingly, I do have a 1490 8501 and it runs noticeably cooler than the others! I swapped a couple of emails with Bil Herd last month and one of his suppositions on the fragility of the cpu's was a hot spot on the design - maybe that was fixed with the later runs? rob Posted By TLC on 2011-02-16 18:18:55  Re: Plus/4 C16 diagnostics and TED partial failure modes Seems like you're already cooking... so I wish you good luck with your project! Hmmm, did I understand that correctly -- was it possible to order true (working...) 8501 chips from China?... :o That's very interesting news! Did they ship new chips or "old stock" (1990)? (The manufacturing code of the last production run of 8501 chips I know of is 1490). I have a Plus/4 that I just refurbished (...better said: rebuilt) recently. It had originally been a school computer (...as you might possibly heard, the Plus/4 made it to a great majority of secondary schools of HU in the mid- to late '80s). ...Well... Amongst other things, the machine appeared to have had the tape port simply broken off of the motherboard once, long before it stopped working for good... it appeared to have been dealt with pretty rough, to say the least... :/ I don't know all details, since I had bought this machine as a wreck at the first place, with some chips already missing. Yet, I can say that the 9V fuse was blown, and both U5 (6529B, $fd10) and (as turned out later) U6 (74LS04, 4 gates used for User Port I/O) were dead... The 6529B was so dead that putting it back to its place caused the machine not to boot up at all. I can probably risk the assumption that the kids shorted some pins of the User Port... or gave the port some shock anyways, which caused the initial "problem" of not booting up (and handing the machine over to a local service, that I bought the wreck from later). ...Although IMHO not a very fragile chip, the pins of the 6529B are exposed on the User Port directly, without any protection (no FBs, no pullup resistors... directly on a large edge connector)... I wouldn't be surprised if that were behind these problems. ...Well, to be honest, I'm not absolutely sure... Posted By crock on 2011-02-16 17:12:43  Re: Plus/4 C16 diagnostics and TED partial failure modes Thanks TLC for a very useful post. I was aware of the latch issue and had read Solders articles on the joysticks but i hadn't specifically coded to catch it, which I will now do. Like the feedback of (albeit rare) partial failures, will leave those to Csabo to ponder on. Even if they are rare, it's become a bit of a labour of love for me now. I feel the pain with CPU's, I have half a dozen dead ones now (and some recently acquired good ones from China!!) Interestingly, I have two which function as a CPU, but some of the ports are dead. The ram test does exactly that, and will indicate the duff bit(s) and thus probably which IC's are dead. I have to date found two dead 6529's on the user ports. No idea what caused them. Rob Posted By TLC on 2011-02-16 15:38:04  Re: Plus/4 C16 diagnostics and TED partial failure modes There's probably only one "typical" partial TED failure (the one siz has already pointed out). There's a "latch", sampling the K0-K7 lines at the moment of writing $ff08. ...Under normal circumstances, you'd use that feature to select either the keys, the joysticks, or both, to be scanned. (Writing something different from $ff to $fd30 selects some part of the keyboard matrix, doing so with $ff08 selects joystick(s), either or both; you can get a picture about how the joystick port scan works if you check how the joyport select' signals are generated). You can "kill" that latch in the TED (with some shock or so), but unlike you'd guess, the keyport doesn't die then -- it'd become "transparent" instead. Ie. no sampling happens at the moment $ff08 is written to... you'd get what's on the port anytime you read $ff08. The keyboard will still work in that case, but not the joysticks... these will obviosly stop working, unless the respective select' signal of the port (...or the joystick adapter) is hardwired to GND. At the heart of Solders "TED protector", there's a bus driver chip which is gated by the select' line. That way, no shocks could come 'round from the joystick and harm the TED keyport. (...In fact, it does more: from that on, the digital part of the standard DB-9 joystick port provided by the adapter becomes fully "C64 compatible", in the sense that it has fixed GND and VCC... unlike the "wired" joystick adapter, whose "GND" is the select' line... So with Solders circuit, "any" C64-specific gadgets will also work with the Plus/4... one good example is the 1350 mouse). I could only name some very rare other "typical" TED partial problems (if at all...). I have seen maybe two TEDs whose "24-rows screen" capability broke. (Ie. even though you clear bit 3 of $ff06, the top and bottom 4-4 rasterlines won't disappear ie. won't be covered with border). One TED whose "blank screen" capability (again, $ff06, bit 4) acted fuzzy... sometimes the screen "under" the blanked screen flashed in for a frame... One single TED that had a stuck bit somewhere in its color logic (one bit of the color code of the characters appearing on the screen became "1" regardless of the contents of color ram). One TED that had serious problems addressing the screen memory, still maintaining all other functionality (screen, colors, registers, all -- but that one doesn't count, that chip has been a victim of some experimenting ie. most probably a shock :-/, not regular operation). All the rest, hopelessly dead, with no signs of life at all. Way less typical than known examples of partially dead VIC-II and SID chips. (...Thinking that over, that's probably one of the reasons I never started designing a test cartridge myself... If you open a faulty 264-series machine, you have about 70-80% percent chances to find a dead CPU, with the rest being PLA, RAM, and TED. From that, all but the RAMs are socketed...in the worst case, you can test all of them whether they work by some swapping to-from a known-to-work machine. (...True, finding out which RAM chip from the bank of 8 chips has failed would be handy...) If there's anything more/different that you find blown, that's usually a strong sign of the machine having been a victim of some shock... shorting pins around the User Port, tape port, joystick ports, accidentally or intentionally, whatever... As a rule of thumb, ROMs, the 6529Bs and most TTLs basically never fail -- unless the component was subjected to some shock.) Posted By crock on 2011-02-16 10:56:40  Re: Plus/4 C16 diagnostics and TED partial failure modes Thankyou Csabo, appreciated. No, the keyboard would not usually be available as there *should* be a dongle attached that loops back all the rows to columns to test the keyport at fd30 and the keyboard latch on the TED. My preference would be to let them cycle automatically. Not super urgent, a work in progress. There is already a timer test but only from the perspective of checking they correctly raise IRQ's. I will upload a video to youtube later with a demo. rob Posted By Luca on 2011-02-16 04:14:41  Re: Plus/4 C16 diagnostics and TED partial failure modes - Sound test (FF0E-FF12) (I'm looking like my older uncle while time passes, uh? :) ) Posted By Csabo on 2011-02-15 21:51:09  Re: Plus/4 C16 diagnostics and TED partial failure modes Well, I don't have anything that's this specific, but it wouldn't be hard to put something together. It's a very interesting task. I think each TED register should have a simple effect on it's own, with some text on screen describing what the expected result is. By the time the software gets to that point, is it safe to assume that keyboard is present? I guess it doesn't matter, I think it should be written so that you could either cycle through the tests (by pressing a key), or they would progress on their own after a few seconds. Here are the test I'm thinking of: - Video mode test (various registers, turn on hires, multi, ECM, char, gfx, etc.) - Timer test (FF00-FF05) - Vertical scroll test (FF06) - Horizontal scroll test (FF07) - Sound test (FF0E-FF11) - Graphics scrolling test (FF1A-FF1B) Plus probably others. I'm definitely interested in doing this, I'm just busy at the moment: we have a party coming up next month (with overseas travel for me) and I'd like to get some stuff ready until then. Is this something that you need super urgently? Posted By crock on 2011-02-15 17:37:07  Re: Plus/4 C16 diagnostics and TED partial failure modes" "...you probably should a test for each TED register, not just colors and sounds." Ahh, well.... Csabo my friend? I have neither the creativity or patience to code demo's. Would you happen to have a couple of compact routines I could include that would 'stretch TED's legs' a bit? Maybe something in hi-res/extended colour mode. As it will run from ROM, no self modifying code either Obviously included with due credit... rob Posted By siz on 2011-02-15 11:07:12  Re: Plus/4 C16 diagnostics and TED partial failure modes I seem to remember some TED keyboard/joystick latch failure caused by some "autofire" capable joysticks. There was a TED protector circuit that tried to prevent this kind of damage but I don't remember the symptoms nor the problem itself it caused in TED. Posted By Csabo on 2011-02-15 09:37:13  Re: Plus/4 C16 diagnostics and TED partial failure modes Sounds like you're making good progress I don't think I've ever heard of just one specific TED register to have a problem. If it's like what you said about the VIC, then I guess it could happen. Therefore you probably should a test for each TED register, not just colors and sounds. Posted By crock on 2011-02-15 08:39:56  Plus/4 C16 diagnostics and TED partial failure modes Guys - I've been working on a diagnostic harness for the plus/4 and C16 to help me with my rediscovered collection of C= hardware. I know there were 'official' ones out there, but I couldn't source one so I decided to develop my own. It's modelled on the existing harnesses that Commodore developed for the VIC20 and C64 for their service centres. It now includes a ram test, rom test, io port test and audio/visual test. For development, I sacrificed a 'Strange Odyssey' cartridge and fitted a socket for a standard 16k x 8 EPROM. As documented in another thread, this is not ideal because not only does the kernal have to be good, so does the ram, as the stock kernal makes use of the stack before jumping into the cartridge. Unless something inspirational crops up, the final version will probably involve temporarily replacing the kernal rom with the diagnostic rom. This way the ram test will run even if ALL the ram is dead. So far I have tests for ram (incl zp and stack), rom checksums (incl. all known kernal versions) and interrupt sources (TED and 6551). Through the use of hardware loopbacks (aka dongles) I have tests for the cassette, serial, joysticks, 6529 user port and 6551 rs232 port. Unfortunately I haven't automated the keyboard test, which tests the 6529 at FD30 and the TED keyboard latch, because I can't find a suitable way of putting loopbacks on the keyboard connector on a plus/4 without destroying a keyboard, something most would be unwilling to do. ** If someone knows a source of +4 keyboard connectors, please let me know!!! From experience, most video controller (vic & vicII) failures tend to be complete but I’ve seen occasional partial failures where maybe sprites are missing, a voice is distorted etc. which can't be tested for programmatically and rely on the user seeing or hearing anomalies. ** Does anyone have any experience of what, if any, partial failures occur on TED's for which a suitable test could usefully be included? So far I just have play a musical scale on each voice and display a cycling colour pallete. Feedback appreciated, Rob Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon