Search results

Anything like MacTerminal or Red Ryder probably should work fine. Proper settings should be 9600 baud, 8 bits, 2 stop bits. Be warned that linked documentation is missing most of the commands and has some commands that aren't in the Portable ROM. For example to run a march test on the first...

If you're feeling adventurous and have the means to hook up a serial cable and ground pin 7 on J22, you can likely get into the test mode and possibly isolate the bad RAM there, assuming there isn't an issue with data bit 4 across all of the RAM.

I guess there's also the CudaLite with PS/2 support, and whatever Cuda version was in the early iMac.

Those solder bridges are actually a form of bodge. There's line numbers next to the pads on the edges, and there are corresponding line numbers on pads connected to the driver chips on the opposite end of the board. If for some reason there's a bad connection, this allows you to connect the same...

Sure, go ahead and mail it over if you'd like. I could probably draw up a basic schematic as well. As for the Portable logic boards, I can look at them if you want but I imagine you could probably get them running pretty easily as well. I think the only thing I have compatible with the Radius...

Well I can't tell for sure since some traces are either under ICs or on inner layers, but here's some guesses on the card and notes on RAM cards in general, if anyone cares: Since it's using 512K x 8 chips, you'll have a pair of them on the 16-bit data bus for 1MB. Because of this you only...

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.