#computer troubleshooting

[pumpkinsplicelatte]

I don't know who needs to hear this but:

Restart your computer.

Obviously this doesn't apply to everyone but if you're having computer trouble restart it. It solves like 90% of computer problems because the computer will forget what the problem was and go back to being normal.

[uvaldecomputerrepairsstuff]

Troubleshooting BIOS Issues: When to Repair, Reflash, or Replace

Understanding BIOS Chips and When You Might Need a Replacement When it comes to troubleshooting computer issues, one of the components most people overlook is the BIOS (Basic Input/Output System) chip. This small, unassuming chip is vital for your computer’s operation, storing the essential firmware needed to start up your machine and manage the communication between your operating system and…

[mcyt-cats]

Objective: Pet the Jellie

[cloudruler]

everyone send me good vibes i'm applying for a tech support position in our school district that I'd absolutely KILL at.

[techav]

On Recovering From Disaster

Just before disaster struck with my 68030 homebrew, I had a plan to fork the project and take it in two directions in parallel.

The first would be my minimal Multibasic setup which was running great and was something I would be proud to exhibit at VCFSW '25.

Since that was working well, I didn't want to do anything that might make it not ready for the show. So I had assembled a second main board that I could use with other peripheral cards to continue development. My plan was to rework the memory map to move ROM and I/O addresses to the upper half of the 32-bit address space, which would allow me to use a DRAM card for up to 16MB of contiguous memory starting at address 0 — a perfect setup for running a proper OS

And then I burned up my good mainboard.

I had a spare CPLD on-hand, and I was able to get another 40MHz 68EC040 for cheap. But the 4Mbit SRAM chips are expensive, and I thought that if I was going to be paying for more SRAM, I should get the 12ns parts that would allow me to run RAM with no wait states at 50MHz. Which would require adapter boards, and more pin headers, and would have just driven the cost up even more.

Paralyzed by indecision and the rising cost, I decided to switch gears. I already have the DRAM board I built years ago, I just needed to get it working. And if I'm doing that, I may as well do the work on reorganizing my memory map.

So that's what I did. I made a new branch on my newly cleaned up repository, and set to work. I updated the mainboard bus controller logic to remove the no-longer-needed SRAM control, adjust the ROM address to start at 0x8000,0000, and move the 6850 UART address to 0x8008,0000. This freed up the entire 2GB space between 0x0000,0000 and 0x7FFF,FFFF for the DRAM card to use for main memory (my bus connector layout only allows for up to 16MB main memory, but that's plenty for my purpose).

Next, I needed to build the control logic for my DRAM board. I've done this once before on my Wrap030-ATX project a couple years ago, so I used that logic as a starting point. It … kind-of worked. Sometimes. Maybe.

I was getting random errors all over the place. Sometimes it was able to copy all of ROM into RAM and verify the copy without error, but it would fail when running code from RAM. Sometimes it wouldn't even pass the first two simple tests of writing a longword to RAM and reading it back.

Back to the data sheets to plan out the logic. I drew out a new timing diagram down to 1ns resolution, accounting for the specified propagation time for my CPLDs, and the measured signal delays for my CPU. This gave me the information I needed to build out a new state machine for the DRAM controller. In the process I also caught a few other bugs in my original logic, such as not ensuring the DRAM Write Enable strobe did not get asserted during refresh cycles.

The new state machine worked much better, but I got my timing off a bit. It worked reliably at 16MHz, but not at the intended 25MHz. At least it was working though; I can move forward with 16MHz.

The next thing to do was get my 8-port serial card working with this new setup. Every time the computer tried to access one of the 8 serial ports, it would get a bus error. This was a tough one that had me stuck for a while.

It looked like the serial card was getting addressed and asserting DSACK0# as expected, but I couldn't confirm the signal was making it back to the CPU. Every time I tried to measure the DSACK signals, the probes would increase the line capacitance (I think) too much and cause the whole computer to fail before it even got to the point of trying to address the serial ports.

I have the DSACK signals in a wired-or configuration. The logic on each card connects to the proper DSACK signal via an open-collector buffer, and is able to pull the signal low to signal that card acknowledging the bus cycle. The signal is then pulled back up to +5V by a 1kΩ resistor. This works well enough for small, slow systems, but with long bus wires or lots of chips on the bus, the extra capacitance means it can take a long time for that pull-up resistor to get the signal back up to +5V.

I made a change to my DRAM controller to actively drive the DSACK signals to +5V briefly at the end of a bus cycle before setting the pin to high-impedance. This helps ensure a fast rise time at the end of the cycle so it doesn't disrupt the next bus cycle.

It didn't fix the problem with the serial card, but it did allow me to actual probe the signals live to see what was happening — the Bus Error signal was getting asserted immediately after the CPU addressed the serial card. This didn't make much sense to me. My main board logic will assert Bus Error if no peripherals acknowledge a bus transaction within 64 clock cycles. Nothing should be asserting Bus Error so quickly.

Except … the main board bus controller. My original memory map used the lower half of the address space for the main board, and peripheral cards used the upper half. So my original main board logic was built to assert Bus Error immediately for an unused address in the lower half of the address space. I hadn't properly removed that bit of logic, so it was now asserting Bus Error for any accesses to the upper half of the address space that weren't used by the main board.

The challenges of working on a project after six years. I had forgotten that bit of logic was even there.

With that erroneous Bus Error assertation removed, the machine was finally able to properly load my Multibasic kernel and run BASIC for 8 users again.

At the moment it is running stable at 24MHz on my 25MHz-rated full 68030. It may not be the 50MHz high I was at, but after the frustration and disappointment of the past few weeks, I'm absolutely taking that as a win. 24MHz is incredible.

[spaciebabie]

not only am i sexy but i am also good at solving my own problems ohhh yeah babyyyy

[rohirric-hunter]

.

[transgnckon]

I HATE PROCTORED EXAMS

[esmeraldablazingsky]

federico giallo fixes your computer for you while explaining exactly what was wrong with it and how to fix it next time asmr

[charlies-trainhopping]

WHY TF DID MY TUMBLR AUTOMATICALLY SWITCH BACK TO LIGHT MODE?! I CANT FUCKING FIX ITTTT

[mercerousmerc]

how do I tumbler

helo

[melodybottles]

oc piece from 2022 i never finished but found recently & quite like :]

[paradoxlemonade]

the duality of the computer user: successfully clones and compiles a github program for the first time. Immediately following this, has to google how to make a desktop shortcut for the new program.

[bonestrouslingbones]

crawls away from my keyboard covered in blood and pissed off but satisfied at the fact that i finally enabled windows firewall

[techav]

On Catastrophic Failures

After working through a silly design mistake and then having to reverse engineer my own project to make up for my own bad habits, my 68030 homebrew computer was running great. Better than ever, in fact — I finally had it running stable at 50MHz. It was absolutely flying.

The only thing keeping the machine from running faster was my 8-port serial card, which really needed another wait state to surpass the 50MHz mark. Luckily, I had designed the board with this need in mind and had included a jumper to select between 0 to 3 wait states. Unfortunately I had missed a single exclamation point in the logic equations for that wait state generator and so the signals were inverted. Not to worry — it's reprogrammable. I just need to add the missing mark, recompile, and re-burn the chip.

And that's when everything went wrong.

All I did was swap out the logic chip for the serial card, why won't the computer boot anymore? I haven't even changed the jumper setting yet. Swapping that chip shouldn't have affected anything else.

... It's not booting even with the serial card disconnected.

Out comes the oscilloscope. Reset is good, but nothing else is moving. All the bus signals are holding steady instead of doing their jobs.

Lower the clock speed; still nothing. Double-, triple-check power supply and bus connections; still nothing. Check the clock pin on the CPU ... nothing.

There's no clock signal on the CPU, so it can't do anything.

A quirk of this design, coming from my limited knowledge when I first started building it, is that the bus control CPLD drives the CPU clock, not the oscillator directly (the original intent was to divide the bus clock for the CPU — something that was more common in the 8-bit era). If there is no CPU clock something must be wrong with the CPLD.

That CPLD seems awfully warm.

I pulled the CPLD and dropped it in my programmer. ATMISP reported that the chip was not blank. That meant it was at least responding to some JTAG queries. I tried erasing the chip and it reported success. I tried reflashing my bus controller configuration. It failed verification every time. Nothing left to do but pull it and try another chip.

That's when I noticed not only was it getting quite hot, but it was drawing enough current that the LED on my programming adapter wasn't even lit. Something in that chip had shorted and was causing excessive current draw. Luckily I have some spares. New chip burns without any problems. Drop in into the main board and success — we have clock and bus signals!

But it's still not booting.

Out comes the oscilloscope again. Address strobes are working as expected. Cycle termination is happening as expected. ROM read & enable strobes are working as expected. RAM and the on-board serial port are never getting selected.

Time for the logic analyzer. After working through bus signals 16 at a time, I finally got to the point where I was watching enough of the address bus to see what it was loading.

The CPU was stuck in an odd loop. It would load the initial stack pointer & reset vector as normal, then start fetching & executing instructions. But before it had even finished fetching the second instruction, it would go back to loading the reset vector, then start again with fetching & executing instructions. Then it would go back to the beginning with loading the initial stack pointer & reset vector, and just continue on in this fashion endlessly.

There is nothing I'm aware of in the documentation that describes this behavior. It is possible to halt the CPU on startup by trying to use a misaligned stack pointer or reset vector, but it's not indicating a halt.

Thoroughly stumped, I turned to Discord for help. One user, [arminius97] had encountered something similar with the 68020 that ultimately required replacing the CPU. Another user well-versed in the 68030, [transistorfet], helped me walk through possibilities, and ultimately we came to the conclusion that something is very wrong with this CPU.

So something burned up my CPLD and my CPU.

I have one other 68030 CPU — a full-featured ceramic-package chip rated for 25MHz (it was my plastic-package 40MHz 68EC030 that failed). Time to swap chips around and see what happens.

A memory error.

It was running code! But it was also consistently reporting a memory error on startup at address 0x00000084. Always the same location, always the same bad byte. So I swapped around SRAM chips. The error followed. I have a bad memory chip.

So that's a CPLD, a CPU, and an SRAM chip that all failed at the same time.

This is quite a setback, especially because it had been running better than ever before. I don't even have any spare 4mbit SRAM chips I can test with. Repairs will be expensive.

Perhaps this is a good time to spring for some 15ns or faster SRAM and run with no wait states for main memory. Or perhaps I could finally finish building & testing the 72-pin SIMM board I assembled for this machine years ago.

I plan on exhibiting this build running the multi-user BASIC setup this June at VCFSW, so I do have a bit of a ticking clock to get it up and running again. I'm sure I'll figure something out.

[highretrogamelord]

B.A.T. for DOS