Search results

I can't tell from the picture, is that the 74AC138 that the bodge is on? If part of the RAM on the card is disabled it may change the card's start address, which would could be why it's not working.

That's correct, it shouldn't need anything special. Either there's a fault on the card or something else is preventing it from being added as valid memory. I'm not sure if it's just the picture, but that's a very sketchy looking bodge running over that chip. Did someone try to modify the...

That would be a modem, not sure which one as it doesn't look like the standard Apple ones.

The first card is just 1MB, the second looks like probably 6MB.

The Caboose file doesn't seem to be in that ROM set, and I think it's missing a few CUDA versions as well. 341S0853 appears to be what's on the Quadra 900's board.

It seems to work pretty good in Ghidra at least, most of the work is just matching functions up to pins to identify what the code is doing. From what I've found so far it looks like the only difference between Caboose and Egret is the addition of control for the Quadra 900 (and 950?) key switch.

The ROMs aren't very hard to decompile, you could probably reverse engineer the entire thing and recreate it on something more modern. Picking a modern chip is the fun part, as you'll likely need to adapt it to fit the footprint. I believe there's actually a third one as well, an Egret...

So I did some more testing with the BlueSCSI v2, and I believe the issue is the transceivers or buffers are asserting control lines as the SCSI controller initializes, because the SCSI controller initialization is happening before the RP2040 finishes initialization. Here's the BlueSCSI v2...

Just got my test boards in, still need to do some more experimenting but: Here's the 7MB card after sleep with manually generated /DTACK: You can actually push it even further since the RAM is fast enough by generating /DTACK even sooner: Still need to get around to doing some testing...

I'll order one of the new cards and see if I can do some testing, since I can't replicate the exact issue on my other cards. I'll also try and setup a BlueSCSI v2 and see if I can narrow down the exact issue, I have a suspicion of what it might be but will need to test it to be sure.

//--------------------------------------------------- // HcMac Clock Change Addresses //--------------------------------------------------- #define Clock16M $FE0000 // Go to sixteen megahertz clock throughput #define Clock1M $FE0002...

So from what I understand /DTACK is different above the first 5MB of address space, I think it has more wait states due to longer timing on peripheral addresses. This shouldn't be that much of a problem though, because the the problem would appear on first boot and not just sleep/wake. You can...

I'm not quite sure which address it's at just looking through the ROM, I'll see if I can dig through some sources.

The number of wait states (and therefore the length of time that /AS is asserted) should be controlled exclusively by when the CPU GLU asserts /DTACK. It seems like the CPU GLU must be getting set to the wrong number of wait states somehow.

Here should be ground points and SEL in red:

So after discovering connecting the logic analyzer fixes the issue, it seems like it's something with the SEL line. Putting a capacitive load on it seems to partially resolve the issue. I put a 10nF capacitor from SEL to ground, and it will wake from sleep after a few minutes just fine. There...

Well, I hooked up my SCSI debug board in between the Portable and the SCSI emulator and somehow just having that connected makes the issue go away. Now I just need to see which component on there is doing it, because the only things connected are a diode, power LEDs, and passive termination that...

No, it only needs the 5V.

I just did another test, and it seems leaving the SCSI emulator powered externally lets it wake up without issue. Without the external power when the issue is occurring, jumping to InitSCSI using G 900732 gets it going again, so my guess at the moment is when InitSCSI is initially called during...

Right, power comes up immediately, I even checked with the scope to make sure the power was clean, but there's never any SCSI activity at all until the time passes.