Classic II possible ROM bug, weird 68030 instruction

[dougg3]

I'd think the likely suspect for the contents of memory that affects it would be 4(A4).

I wondered about that too, but I can even set all the registers except A1 and A7 to 0, and I still get the same resulting A1 value on the IIci. I wonder if it's some kind of absolute address that it's grabbing?

Also, a thought: CAS and TAS in their legit forms are the only 680x0 instructions that do a special read-modify-write bus cycle so that the operation is not splittable in the middle on a multiprocessor system. Some well-known 68K hardware including the Sega Megadrive/Genesis and some Amigas don't support those cycles and either lock up or do other odd things.

That's an interesting point! I wonder if it would be possible to make something that snoops the PDS and looks for that type of cycle, even just detecting if it's happening would be useful.

One last test here. The original LC with a 68020 also has the exact same code in the exact same location in ROM, so I ran the same test on it. It seems to have wigged out, it didn't like it. Before the instruction:



After stepping:



I tried to repeat it again after that weirdness happened, and now it seems like it accepts the instruction just fine, but it changes A1 in a completely different way -- it went from FFFF8FBA to FFFFBFBE. So I would say the behavior of this instruction on a 68030 seems to be different from what you see on a 68020, especially since it made MacsBug crap out the first time I ran it.

 

[Arbee]

CAS isn't a 68000 instruction.

Of course, but TAS is.

 

[Arbee]

@dougg3 Interesting that it's different on the '020. That certainly makes it seem more like an actual errata in the chip. Probably a bit late to get Motorola to respond though.

 

[eharmon]

Some future 020+ core implementer for FPGA will hopefully stumble upon this thread.

 

[David Cook]

Has someone gone through all possible values (64536?) to see which one result in illegal instruction exceptions? I know it is more complicated than that, but I recall the 6502 and other chips having a list of 'undocumented' instructions and weird variations.

 

[joevt]

My 68K is rusty.

How does stepping work? Does the debugger need to know how many bytes the instruction is in order to stop at the next instruction? Are we sure that the next instruction after *94 is *9A?

Does instruction decode know the length of the instruction just from the first instruction word?

 

[Arbee]

Most instructions you know the length from the first word. There are some where you need to know there's a second word *and* check what its value is to see if there are more words. But it's not as bad as x86.

 

[dougg3]

I'd think the likely suspect for the contents of memory that affects it would be 4(A4).

Also, a thought: CAS and TAS in their legit forms are the only 680x0 instructions that do a special read-modify-write bus cycle so that the operation is not splittable in the middle on a multiprocessor system. Some well-known 68K hardware including the Sega Megadrive/Genesis and some Amigas don't support those cycles and either lock up or do other odd things.

This time I decided to play around with my LC III, and I think you may be onto something here on both counts.

I know that the LC III has ROM mapped at 0x40800000 instead of 0x40A00000, but I left the register setup the same as what we see on the Classic II just for fun, except for the program counter. I just used the PC value that was there when I entered MacsBug (0x2A036) and modified the RAM it points to so it would execute the actual instruction.

When I run it, I get this error:

Bus Error at 0002A036
while reading word (read-modify-write) from 40A09AEA in Supervisor data space

As a reminder, A4 is set to 40A09AE6. So that's 4(A4)! Also, it mentioned that it was doing a read-modify-write and the bus error happened during the read. If I change A4 to 40A09AE8, I get this:

Bus Error at 0002A036
while reading word (read-modify-write) from 40A09AEC in Supervisor data space

If I change A4 so that 4(A4) is a valid address, the instruction acts just like what I've been observing on the other machines, changing the value of A1. And varying the memory it's pointing to does change the resulting A1 value.

• PC=2A036, A7=FC63C, A1=FFFF8FBA, A4=20000, word at 20004=0:
  • The word at 20004 stays at 0
  • A1 becomes 0xF86BE
• PC=2A036, A7=FC63C, A1=FFFF8FBA, A4=20000, word at 20004=FFFF:
  • The word at 20004 becomes 0x6500
  • A1 becomes 0xFAFBE

So yeah. It's doing a read-modify-write, and the value at 4(A4) is involved. Your intuition was correct! I still have no idea exactly what it's doing, but that's another clue. I wonder if the 6500 came from low word of D2? Maybe MacsBug's interpretation is correct in saying that it involves D2?

Despite all of this new knowledge, I'm still seeing different results between my IIci and LC III in terms of what the value of A1 becomes. The RMW cycle seems to be the same and also results in a final stored value of 0 and 0x6500 with the same register setup, but on the IIci, I get final values of A1=F86BC in the first test case and A1=7FFFAFBE in the second.

 

[SuperSVGA]

The MacsBug disassembly is correct. Ignoring the extra bits, the instruction should compare D1 the contents of location A4+4. If they are equal, D2 is written to A4+4. If they are not, then A4+4 is written to D1.

I wonder if A1 is being modified due to the way the silicon is designed, as if having those bits set causes the wrong parts of the processor to activate due shared silicon or minimization in the design.

 

[ymk]

What other machines result in a bad table index?

 

[dougg3]

The MacsBug disassembly is correct. Ignoring the extra bits, the instruction should compare D1 the contents of location A4+4. If they are equal, D2 is written to A4+4. If they are not, then A4+4 is written to D1.

Ahh, got it. Thanks! I feel like I'm not totally seeing that exact result. It matches what I'm seeing on test 2 with the 0x6500 from D2, but what about test 1 where A4+4 is 0 and D1 is not 0? It's not writing 0x6500 to A4+4 in that case. Either way, knowing what I'm looking for, I might do some more tinkering to see if I can make any more sense of it.

I wonder if A1 is being modified due to the way the silicon is designed, as if having those bits set causes the wrong parts of the processor to activate due shared silicon or minimization in the design.

That makes sense.

What other machines result in a bad table index?

It's easier to list what doesn't result in a bad table index. Anything with boxFlag greater than 15 will result in an out-of-bounds jump, but to a different location that won't hit this particular instruction. This exact instruction is only hit by the Classic II.

These machines are accounted for in the table, identified with the help of the SuperMario sources:

• II
• IIx
• IIcx
• SE/30
• Portable
• IIci
• boxFourSquare
  • This is interesting, the comments in SuperMario say this about it: a Four Square (030, 68882, 6 slots, MDU, 2 IOPs, SCSI DMA) (never shipped)
• IIfx
  • For comparison against boxFourSquare, here is what the comments say about this: a F19 (030, 68882, 6 slots, OSS, BIUs, MC, 2 IOPs, SCSI DMA)
• boxAuroraCX16
  • Comment: Aurora 16MHz 3 slot package (never shipped)
  • A comment next to IIci identifies it as "Aurora 25MHz 3 slot", so this is likely an unreleased 16 MHz IIci, despite the boxFlag name implying IIcx.
• boxAuroraSE25
  • Comment: Aurora 25MHz SE30 package (reserved for future)
• boxAuroraSE16
  • Comment: Aurora 16MHz SE30 package (reserved for future)
  • Maybe the two above are unreleased IIci-based SE/30s?
• Classic
• IIsi
• LC
• Quadra 900
• PowerBook 170

In the fixed version of the table in the IIvx ROM, all the newly added table entries including the Classic II just do the same thing that it does for the LC (nothing at all).

 

[dougg3]

Ahh, got it. Thanks! I feel like I'm not totally seeing that exact result. It matches what I'm seeing on test 2 with the 0x6500 from D2, but what about test 1 where A4+4 is 0 and D1 is not 0? It's not writing 0x6500 to A4+4 in that case. Either way, knowing what I'm looking for, I might do some more tinkering to see if I can make any more sense of it.

I don't see any interaction with D1 at all. D2 is definitely what it grabs from to write to A4+4 sometimes, so it's likely the update operand. But I'm not seeing the behavior depend on what I have in D1 at all. With this setup:

• PC=0x2A036, random RAM location where I can put instructions.
• D0-D7 are all 0, except D2=0x1234
• A0-A6 are all 0xF0000000, except A4=0x20000. This is to prove that the instruction doesn't perform any memory accesses with the other address registers.
• A7 = 0xFC63C, needs to be RAM because otherwise MacsBug will get mad when it displays the stack.

If the word at 0x20004 is set to 0, 0x5678, 0x8000, or 0xFFFE, A1's value gets transformed to 0x28034 and the word at 0x20004 is unchanged.
If the word at 0x20004 is set to 0xFFFF, A1's value gets transformed to 0xF002A036 and the word at 0x20004 is changed to 0x1234. This seems to kind of follow the process of what the instruction does, but also not really.

Kind of seems like whatever the compare operand is, it's resolving to 0xFFFF?

 

[alectrona6400]

a little off topic, have you ever figured out how the death chime works on these? i know its not PCM but the PCM ones ive always found thru raw data input in audacity. these i know do it differently with a sequenced startup, crash, and simple beep sound, likely from the ASC (though it sounds different on other machines like the macintosh II lineup, and allegedly if you use the ASC with something like the LC580 in MAME (which i still haven't figured out for the life of me.)

 

[Arbee]

a little off topic, have you ever figured out how the death chime works on these? i know its not PCM but the PCM ones ive always found thru raw data input in audacity. these i know do it differently with a sequenced startup, crash, and simple beep sound, likely from the ASC (though it sounds different on other machines like the macintosh II lineup, and allegedly if you use the ASC with something like the LC580 in MAME (which i still haven't figured out for the life of me.)

The original ASC has two modes: PCM stereo playback and 4-channel wavetable synthesis. The wavetable mode is what generates the classic original Mac II boot and death chimes. In wavetable mode, it loops the contents of the FIFO and you can freely adjust the pitch and volume of each of 4 voices based on that sample. None of the follow-on chips have that capability (EASC or the (E)ASC clones inside V8/Eagle/Spice/Tinkerbell/VASP/Sonora/IOSB/PSC/PrimeTime).

 

[alectrona6400]

The original ASC has two modes: PCM stereo playback and 4-channel wavetable synthesis. The wavetable mode is what generates the classic original Mac II boot and death chimes. In wavetable mode, it loops the contents of the FIFO and you can freely adjust the pitch and volume of each of 4 voices based on that sample. None of the follow-on chips have that capability (EASC or the (E)ASC clones inside V8/Eagle/Spice/Tinkerbell/VASP/Sonora/IOSB/PSC/PrimeTime).

would be interesting if we could get the samples/instruments from these old mac ROMs or the ASC. because i'd love to mess around with em.

 

[dougg3]

I haven't had a chance to mess with the funky instruction any more, but I have a plan for verifying 100% that it's also happening on hardware. I bought a Classic II. There weren't any pics of the inside, and it was pretty ugly on the outside, but luckily it was not battery bombed. In fact, I'd guess it probably still had its original battery (blue Sonnenschein) given that the battery had a date code of 03/91 and the computer was made later the same year.

I'm going to clean/recap the logic board and use an RGBtoHDMI for testing instead of the actual analog board/CRT because I want to tinker with ROM chips and CRTs are still scary to me. Plus, it sounds like the analog boards on these things are a PITA, so I want to take that out of the equation for now.

Fortunately, this is a rev A logic board with 4 ROM chips and I have some SST29EE010 EEPROMs that perfectly match the pinout. I wrote a little 68k ASM snippet that displays the value of A1 on the screen and hangs forever. Now I've got a couple of modified ROM images that I can test out as soon as the board is working. One of them replaces the invalid CAS instruction with a jump to the A1 display code. The other one replaces the move.b #$90,$1C00(a1) instruction that causes the Sad Mac in MAME.

So...if everything's executing as I think it is on hardware, we should see the first custom ROM image display 0xFFFF8FBA for A1, and the second custom ROM image should display some other valid value that allows the move.b instruction to not crash the machine. If that comes out as expected, then I will be completely confident that this was really a bug in the Classic II's ROM that the 68030 was accidentally protecting against.

Anybody have any tips for recapping the Classic II logic board? Dang, it's really cramped. I'm not sure my iron will fit in there. I'm wondering if maybe protecting everything around it and using hot air to solder my new tantalums will be the ticket.

 

[obsolete]

Installing tantalum caps with hot air is bad news unless they've been properly baked beforehand. The packages readily absorb moisture which will expand when subjected to soldering heat, resulting in a "popcorn" effect. When it's really bad, you can hear them pop, and the top of the part may be visibly bulged afterward.

Impressively, even after this happens, they often still work, but you can expect their capacitance to be reduced and their lives significantly shortened.

I haven't worked on a Classic II board, but I think a smaller and/or longer-reach iron tip would be my first choice. If you're set on installing with hot air, check the part specs and bake them out accordingly first.

 

[dougg3]

Installing tantalum caps with hot air is bad news unless they've been properly baked beforehand. The packages readily absorb moisture which will expand when subjected to soldering heat, resulting in a "popcorn" effect.

Thanks! I'm well aware of the dangers of hot air and popcorning, which is why I also prefer using the soldering iron unless I can't. I haven't had any trouble with ICs popcorning when I install them with hot air -- are the tantalum caps even more prone to it than chips?

The main issue is the proximity to some through-hole parts that stick up quite a bit. Maybe to be safer, if I can't fit my smallest iron tip in there, I can just temporarily remove the problematic parts with my desoldering gun.

 

[zigzagjoe]

Thanks! I'm well aware of the dangers of hot air and popcorning, which is why I also prefer using the soldering iron unless I can't. I haven't had any trouble with ICs popcorning when I install them with hot air -- are the tantalum caps even more prone to it than chips?

The main issue is the proximity to some through-hole parts that stick up quite a bit. Maybe to be safer, if I can't fit my smallest iron tip in there, I can just temporarily remove the problematic parts with my desoldering gun.

Yes, Tantalum caps are extremely susceptible to heat damage even if not externally visible ("popcorning"). Just about any other component you can really cook with a hotair gun and typically be fine, tantalum caps are the only component that I will not re-use after it's been removed from a board. It's not worth courting their spectacular failure mode in order to save a few cents.

In general tantalum caps should never be installed with hotair rework tools unless you're using solder paste and are able to apply the air directly to the lead/paste, not the body. Even when hand soldering you need to reduce the heat applied to the cap to the minimum required; there is a direct correlation between overheated caps and premature or immediate failure. Avoid touching up the leads or reheating the cap if at all possible.

At a quick glance it looks to me like there's enough clearance to get a tip in there without too much trouble. A tip shape like this should work well.

 

[dougg3]

Thank you both, that’s good to know. I didn’t realize they were so sensitive. I have a Hakko BR02 tip that’s shaped similarly to that, but not nearly as long. I’ve been using it for my other recaps. Hopefully it’ll fit okay!