BlueSCSI on Macintosh Portable

[Androda]

Started investigating, was curious whether something was up with the RAM timing. The original spec is 100 nanosecond RAM, Techknight's 8 meg card used 55ns and mine uses 70ns. This doesn't appear to be related at all.

Below are screen captures from my logic analyzer, with my 8 meg card on top and a 3 meg card underneath. This 3 meg card benchmarks around 2 in Speedometer like the above tests.

These are near-identical. 3 meg card has about 8 nanoseconds of delay from valid address + /AS line assertion to the RAM chip being enabled. And my 8 meg card is the same, about 8 nanoseconds. 68000 clock cycles are 62.5ns on the Portable, so it can't even see the skew to begin with.

It's unclear where the performance degradation is coming from, but given that my card is talking on the bus effectively the same as the 3 meg card that benchmarks faster I am more suspicious of memory management code than the card's hardware currently. It could also be a Portable architecture issue or even related to installed software: I note that alxlab's portable seems to handle the 7 meg card better, there's less overall degradation than in sodeburn's case.

Up next will be looking into the strange sleep mode behavior, that should be interesting.

 

[Androda]

This is... odd.

RAM access on the 68000 is controlled by the /AS pin (noted "AS" in the pictures because my analyzer didn't want to let me add a "/"). It means "The address on the bus is valid and the CPU is selecting whatever is there". Normal /AS cycles look like the above images, about 4 full clock cycles (250 nanoseconds).

After waking from sleep, the 3 megabyte card continues on with normal looking /AS cycles.

The 7 meg card? Not so much. Something is making these /AS cycles take *way* longer. Count it with me: about 6 and 1/4 divisions on the top. And each division is 200 nanoseconds! That means 1250 nanoseconds for this /AS cycle.

My RAM card has the /AS line set up as an input only, it does not try to control this pin. That means the CPU is holding /AS low for a very very long time. That, or one of the glue chips maybe - CPU glue and Misc glue chips are connected to this line.

Reading the Portable dev notes, page 6-8 says that there's an adjustable wait state system in place for putting the CPU to 'sleep' by injecting 64 wait states - but this isn't the same as full system sleep. I wonder whether large RAM amounts like this cause problems with that wait state system.

So overall it doesn't appear that the RAM card is directly interfering with bus cycles, and it's this strange /AS behavior is the cause of it all. The question becomes, "why is the system injecting a bunch of wait states?" (by my count about 16).

 

[alxlab]

Regarding the software installed on my Portable for the benchmarks, it's pretty much stock System 6.0.8 with just the Iomega driver extension. I did do the benchmark on 7.1 with update 3 and it was slightly slower.

@Androda regarding the 7MB card performance vs the 3MB, if it's not too hard maybe it would be worth limiting the 7MB card to 3MB in the fpga and see if there's a performance boost.

Maybe I'll run Speedometer with a 1MB ram card and see if that gives different results as well.

 

[SuperSVGA]

My RAM card has the /AS line set up as an input only, it does not try to control this pin. That means the CPU is holding /AS low for a very very long time. That, or one of the glue chips maybe - CPU glue and Misc glue chips are connected to this line.

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.

 

[Androda]

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.

Ah, so it's the cpu glue which controls that. Is there a register or address reference available?

 

[SuperSVGA]

Ah, so it's the cpu glue which controls that. Is there a register or address reference available?

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.

 

[Sideburn]

I dont know what the heck but I haven

Mac OS 6.0.8 with my old 3MB card
View attachment 12817

After sleep:

View attachment 12818


Hmmm maybe the psram on 7MB is being set into a low power/low performance state during sleep and doesn't recover.

Weird, I I haven't been getting notified about posts in there all the sudden..
Interesting so your different third party ram card is also doing it?
Mine is the 7MB form Androda.

 

[Sideburn]

Interes

Started investigating, was curious whether something was up with the RAM timing. The original spec is 100 nanosecond RAM, Techknight's 8 meg card used 55ns and mine uses 70ns. This doesn't appear to be related at all.

Below are screen captures from my logic analyzer, with my 8 meg card on top and a 3 meg card underneath. This 3 meg card benchmarks around 2 in Speedometer like the above tests.

These are near-identical. 3 meg card has about 8 nanoseconds of delay from valid address + /AS line assertion to the RAM chip being enabled. And my 8 meg card is the same, about 8 nanoseconds. 68000 clock cycles are 62.5ns on the Portable, so it can't even see the skew to begin with.

It's unclear where the performance degradation is coming from, but given that my card is talking on the bus effectively the same as the 3 meg card that benchmarks faster I am more suspicious of memory management code than the card's hardware currently. It could also be a Portable architecture issue or even related to installed software: I note that alxlab's portable seems to handle the 7 meg card better, there's less overall degradation than in sodeburn's case.

Up next will be looking into the strange sleep mode behavior, that should be interesting.

View attachment 12819

Interesting.. I did try with bare bones system 6.0.8 off 3.5" floppy install disk..

BTW my screen name is supposed to be SIDEBURN but i typed it in wrong and i cant change it til the 15th!

 

[Sideburn]

So is everyone seeing the same two issues I am and with two different ram cards?

A) slower performance overal
B) even slower performance after waking from sleep

BTW that is awesome you have a logic analyzer for System 6 ?

 

[alxlab]

Performance my 1MB apple card

After sleep:

These are the cards I tested. 1MB left and 3MB right

 

[alxlab]

So is everyone seeing the same two issues I am and with two different ram cards?

A) slower performance overal
B) even slower performance after waking from sleep

I only see that issue with the new 7MB ram card I got.

 

[Sideburn]

Performance my 1MB apple card
View attachment 12827
After sleep:
View attachment 12828

These are the cards I tested. 1MB left and 3MB right
View attachment 12829

ahh yep that’s no change. And around 2.0 is the expected speed. 2X a Mac plus @ 8mhz resulting in 1.0 speed.

 

[Androda]

I created a "quick and dirty" test firmware for the CPLD. It reports as 3 megs of expansion (but provides 3.5mb because chip select logic is complicated). The Portable doesn't know what to do with half-meg increments and generally leaves it alone.

The results? 2.08 CPU performance rating. And after sleep, the rating is basically the same (2.x).


This seems to indicate that it's not the RAM card directly causing system slowdown. Something in the Portable's system software or hardware architecture is the cause of the slowness. Likely the CPU glue is being told to inject too many wait states as mentioned by SuperSVGA.

 

[Androda]

Overall it appears that any slowdown after a cold boot is probably due to system overhead with the memory manager.

The strange behavior after sleep is because of a bug with the glue chip's wait states.

My next step is to tweak the firmware again to increase available memory and see where the perf degradation reappears. It's possible Apple never intended these cards to be greater than 3 megabytes at all, and that other large RAM cards would have the same wake-from-sleep issue.

 

[Sideburn]

I created a "quick and dirty" test firmware for the CPLD. It reports as 3 megs of expansion (but provides 3.5mb because chip select logic is complicated). The Portable doesn't know what to do with half-meg increments and generally leaves it alone.

The results? 2.08 CPU performance rating. And after sleep, the rating is basically the same (2.x).
View attachment 12830

This seems to indicate that it's not the RAM card directly causing system slowdown. Something in the Portable's system software or hardware architecture is the cause of the slowness. Likely the CPU glue is being told to inject too many wait states as mentioned by SuperSVGA.

Cool. So why is a factory OEM card working? Do you think it’s the same but the factory card is just less RAM so it’s not noticeable and this is a bug in the firmware since day one and the more memory you add is just amplifying the issue?

 

[Sideburn]

Overall it appears that any slowdown after a cold boot is probably due to system overhead with the memory manager.

The strange behavior after sleep is because of a bug with the glue chip's wait states.

My next step is to tweak the firmware again to increase available memory and see where the perf degradation reappears. It's possible Apple never intended these cards to be greater than 3 megabytes at all, and that other large RAM cards would have the same wake-from-sleep issue.

Ahh you just basically answered my question.

I’m cool with 3MB or whatever a factory ram card gave us.

Is there a way for us to flash the card with new code if you come up with a fix?

 

[Androda]

Is there a way for us to flash the card with new code if you come up with a fix?

I don't know if there's an easy way for you to flash the update. This is something I'd have to look into, because it's not friendly or convenient like an STM32 or Raspberry Pi Pico. This CPLD uses JTAG for flashing, which is a lot less common.

 

[Sideburn]

I don't know if there's an easy way for you to flash the update. This is something I'd have to look into, because it's not friendly or convenient like an STM32 or Raspberry Pi Pico. This CPLD uses JTAG for flashing, which is a lot less common.

I’ve got some I do rp24 development etc.

I have some jtags / picoprobe Esp32 stuff

 

[Sideburn]

Ok so maybe I can but ya hmm not a good way to upgrade everyone..

 

[Androda]

It also depends on whether people want an update.

Based on all my investigation, there's nothing wrong with the RAM card. It's performing exactly as it should.

All these side effects of increased overhead due to memory management and the bug in CPU wait states are from things that are not necessarily under my direct control.