#debugging

LIVE

SE Exp30

Exp30 Macintosh SE 68030 accelerator card bare circuit boardALT

I ordered some boards for my Mac SE accelerator. I’m quite pleased with how they look.

Exp30 assembled PCB - rearALT
Exp30 assembled PCB - frontALT

Assembly wasn’t too bad. The 0805-size resistors and capacitors can be a bit fiddly to work by hand, but they’re still manageable. In all, it just took a couple hours to put together the first test board.

Exp30 test fit in Macintosh SEALT

It fits in my SE with plenty of clearance between it and the floppy drive cages.

So the big question is — does it work?

Glitched screen on Macintosh SEALT

Of course not! What fun would that be?

First run attempt was just a garbled screen, and not even the infamous checkerboard pattern. I didn’t expect it to be fully functional at first attempt, but that pattern is a new one.

Time for the logic analyzer.

I can see the hand-off working. The accelerator asserts the Bus Request signal to take the SE 68000 off the bus, and waits for the Bus Grant signal in response. Once the 68000 is off the bus, the 68030 is brought out of reset and allowed to take over. That much worked as expected.

Next thing to look at is whether the 68030 is starting up properly. The first thing it’s going to do is load the initial startup vector and stack pointer from ROM. These are 32-bit values, so each will take two access cycles over the 16-bit SE bus. It was getting stuck on these initial read cycles, waiting for a bus termination signal

The 68k processor family has a great asynchronous bus that relies on peripherals providing an appropriate bus cycle termination signal. Macintosh computers generate the termination signal synchronous to the system clock. What I found was the faster 68030 (running at 12MHz for testing) was sometimes ending one cycle and starting the next within a single clock pulse of the main 8MHz SE clock. The SE motherboard logic never saw the new CPU cycle begin.

My first draft of logic was largely asynchronous, and paid little attention to the system clock. But since the SE motherboard logic is synchronous and expecting 68000 bus cycles, I need my logic to better emulate 68000 bus cycles.

So I rewrote nearly all of the logic for the CPLD to roughly emulate 68000 bus cycles.

Sad Mac error code 0x00000001 on Macintosh SEALT

Never thought I’d be happy to see a Sad Mac error. That error means the 68030 is running enough code for the initial ROM checksum to fail. That’s quite an improvement over not even loading the initial vectors.

I’ve got a long way to go on this project, but it’s looking promising. Running any code at all is a great sign. I can already see a the next few logic bugs that need to be addressed, and I’ve found a few hardware bugs that’ll need bodge wires.

Debugging 68030 PCB

I had dared to hope that since this board was created from the same schematic and board file I had made and referenced for my wire-wrap 68030 project, that I could just move the parts over and let it run. If I was really lucky, it might even be able to run faster than the original.

I should know by now it’s never that easy.

The board does indeed run. It starts up, initializes its serial port, copies BASIC into RAM, verifies the copy, then starts running BASIC. It never gets to the BASIC ready prompt though.

Time to pull out the logic analyzer. This would certainly be easier if I had a proper logic analyzer with 64 or even over 100 channels, but there is a lot that can be learned 16 channels at a time. Watching important parts of the address bus I was able to watch it step through the BASIC initialization routines. However just before it got to the point where it would print its first carriage return, it jumped to an address I didn’t expect, and I couldn’t follow where it had gone. Shortly after, it would start accessing invalid addresses and generating bus errors.

The point where I lost it was right when it called a vector to its character print subroutine. This version of BASIC is written to be position-independent, so it has a short vector table for common I/O handlers in its global variable space. When it’s time to call one of these routines, it performs a jump operation using the vector in that table ( jsr voutp(a3)).

I could see it getting that far, recall the vector, and push its return address to stack. But where it ended up was a mystery.

This points to memory corruption somewhere, but where? I had a similar issue when I was building the prototype, before I had properly built out the RAM chip select signals, but that fix is already incorporated into this board.

I started writing some memory test routines. Unsurprisingly, long word write and read back tests all passed (after all it was loading and verifying BASIC the same way already). Byte-level tests also passed without issue. I needed something more thorough.

I put together a simple test that would write a single byte, followed by writing a long word, alternating for 16 total bytes. This would force it to write misaligned long words to confirm RAM addressing was working correctly.

It failed.

The bytes read back were all jumbled, and a couple values were missing altogether. This really was looking like that old problem with the missing chip select signals, but I had already verified those were firing.

This chart from the 68030 manual shows what data will be output for any given write cycle. I went through my memory test one write at a time, writing down what would be present on the data bus and where for each cycle.

The random, nonsensical data read back from RAM immediately made sense. Where a byte write cycle should have written data to the lowest-order bits, the highest-order bits were getting saved, and vice versa.

My chip RAM chip select signals are indeed working — they’re just wired backwards.

Thankfully, that’s an easy fix. I used a CPLD for all the glue logic on this project, so all I really need to do is update the pin assignments for those four signals. I don’t even need a new board.

I might take this opportunity to further update the CPLD. I initially built out the logic for this project entirely in Quartus schematic view. I think I could do the same in System Verilog now. I suspect my old CPLD configuration may be partially responsible for my speed problems, so it may do some good to rewrite it.

Separation Anxiety.I was debugging the minimum separation between each boid’s in the flock by

Separation Anxiety.

I was debugging the minimum separation between each boid’s in the flock by drawing only the pixels where boids were overlapping. This resulted in some interesting shapes and–with a bunch of aesthetic adjustments–resulted in images like this.

I’m really enjoying the alternation of visual debugging and then producing something aesthetically pleasing from it.


Post link
image
image

The top photo is a little memento mori I found in the third floor women’s restroom in my dorm building.  It’s a dead moth anchored to the wall in spider’s silk.  Duke is covered in spiderwebs, but somehow I almost never see any spiders at work.  This makes operating in daily life easier, but also somehow, much more disquieting.  Where are all these spiders?  Anyway, it reminded me of the computer bug story, and since there’s still myths going around about this one, I thought I’d post the real, myth-busted account.  This article is from Computerworld, and the log it refers to is pictured above.

It’s an oft-repeated tale that the grand dame of military computing, computer scientist and U.S. Navy Rear Admiral Grace Hopper, coined the terms buganddebug after an incident involving Harvard University’s Mark II calculator.

The story goes like this:

On September 9, 1945, a Harvard technical team looked at Panel F and found something unusual between points in Relay 70. It was a moth, which they promptly removed and taped in the log book. Grace Hopper added the caption “First actual case of bug being found,” and that’s the first time anyone used the word bug to describe a computer glitch. Naturally, the term debugging followed.

Yes, it’s an oft-repeated tale, but it’s got more bugs in it than Relay 70 probably ever had.

For one thing, Harvard’s Mark II came online in summer of 1947, two years after the date attributed to this story. For another thing, you don’t use a line like “First actual case of bug being found” if the term bug isn’t already in common use. The comment doesn’t make sense in that context, except as an example of engineer humor. And although Grace Hopper often talked about the moth in the relay, she did not make the discovery or the log entry.

The core facts of the story are true – including the date of September 9 and time of 15:45 hours – but that’s not how this meaning of the word bug appeared in the dictionary. Inventors and engineers had been talking about bugs for more than a century before the moth in the relay incident. Even Thomas Edison used the word. Here’s an extract of a letter he wrote in 1878 to Theodore Puskas, as cited in The Yale Book of Quotations (2006):

‘Bugs’ – as such little faults and difficulties are called – show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached.

Word nerds trace the word bug to an old term for a monster – it’s a word that has survived in obscure terms like bugaboo and bugbear and in a mangled form in the word boogeyman. Like gremlins in machinery, system bugs are malicious. Anyone who spends time trying to get all the faults out of a system knows how it feels: After a few hours of debugging, any problems that remain are hellspawn, mocking attempts to get rid of them with a devilish glee.

And that’s the real origin of the term “bug.” But we think the tale of the moth in the relay is worth retelling anyway.

vaguely-none:

stan-leigh-bowery:

levanna:

ritavonbees:

until we open the box, the cat has all the genders simultaneously

adjoint-law:

“the gender of all genders that aren’t gendered in terms of themselves”

zordonmlw7:

The number of genders is any set of axioms from which some or all axioms can be used in conjunction to logically derive gender.

personal-scientist:

We can either know where the genders are or how fast they’re moving but never both

saxifraga-x-urbium:

we can either know how many genders there are or what a gender is but never both

dingo-inna-domino-mask:

the number of genders is pi

anaisnein:

there are 3.6 genders; not great, not terrible

footie-pajamas:

Believing in ℵ ₀ genders goes back to believing genders are quantized, but countably infinite

regexkind:

numbers

argumate:

no genders, got it.

eightyonekilograms:

There are ℵ ₀ genders

dagny-hashtaggart:

People who believe that gender is finite and boundless vs. people who believe gender is infinite and bounded

argumate:

people who believe that the number of genders is countable vs. uncountable, knowable vs. unknowable,

cargopantsman:

people who believe genders are contiguous and people who believe genders are quantized

anaisnein:

people who believe the number of genders is imaginary and people who believe the number of genders is complex

dagny-hashtaggart:

There are zero or fewer genders

argumate:

there are zero or more genders

caesarsaladinn:

There is only one gender: people who miscount the number of genders.

argumate:

well, exactly.

greencherenkov:

This is “there are no genders” erasure

argumate:

ah yes the two genders: there are only two genders / there are more than two genders

@stan-leigh-bowery

The act of observing a gender alters it. Genders greater than zero now exist in a different capacity than before this post. This, the purest gender exists as gender = 0.

if you set a breakpoint to observe it, gender won’t occur any longer.

מדבגים לאט

היית מסתכל לי בקוד כשדיבגתי איתךךךךךךךךך

loading