Search results

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.

The original Conner drive seems to work fine, or at least last time I tried it. It just seems to be my custom SCSI emulator that I'm getting the problem on, which is odd because it seems like the Conner drive would take longer to start up. Theoretically just hitting the interrupt should...

I can't find a BlueSCSI around at the moment to test with. Just out of curiosity, see what happens if you hit the interrupt button and type G 900732 when it's stuck, that gets it going on mine.

Just ran a test, here seems to be where it's stopping: Seems to be looping at 0x907284, which I guess is checking 0xF90040 which is a SCSI controller address, and decrementing D1 and D5 for reasons I'm not sure why. The other odd thing with the three minute wait is it's based on execution...

I think I have had this happen before, but I thought it was because of my custom made SCSI emulator. I don't think I waited the three minutes though, I just gave up and reset the computer. I may try and get a BlueSCSI v2 to see if I can replicate the problem again. I would guess that maybe...

Have you tried using the Mac Plus configuration from https://ini.bluescsi.com?

Interesting, it works fine in Infinite Mac, but not in Mini vMac with ImportFL, even when using the same version of Stuffit. The files are there though...

Which files are broken? I opened a few from that link and they all extracted fine.

Looks like it was much simpler than I thought. I decided to do some probing with the scope, and looks like it's outputting 5V TTL at 7200 baud: Here's the pinout from what I can see: [ 2 ] [ X ] [ 6 ] [ 8 ] [ 10 ] [ 12 ] [ XX ] [ 1 ] [ X ] [ 5 ] [ 7 ] [ 9 ] [ 11 ] [ 13 ] 1 - LED? 2 -...