Thank you TF.terriblefire wrote: ↑Fri Jan 14, 2022 8:00 am I cant comment on boot times. If you've added the ehide.device during your startup it might time out for 30 seconds waiting for a drive on one firmware vs the other.
In order to compare boot times fairly use this completely clean HD image.
https://wordpress.hertell.nu/files/WB31Clean.zip
I have downloaded the image and written it to a boot CompactFlash card.
I am able to reproduce the same underlying issue. The following is wildly different on OFW vs alpha, with the alpha being observably slower (same exact steps for both tests):
1. boot the image
2. open a shell
3. maximize shell window to full screen
4. Go to sys:mutools
5. MuFastRom off
6. dir (watch the window draw/scroll speed)
Admittedly, mufastrom masks / obfuscates the issue, but it is there -- at least on my hardware. I don't know if it's *worth* fixing or what causes it. More importantly I don't know how many people will care. Most critically, do you think it's worth addressing?
I think it's a potential consideration for anyone wants to keep the MMU available for non-MMULib purposes. This was my original intent.
I don't know if the underlying issue can affect any real-world software with MuFastROM on. Probably, but it would clearly be an edge case.
I don't consider this a deal breaker of any sort since most people will be completely happy running MuFastRom and may never even notice this.
Based on prior tests, bustest (with no MuFastROM) isn't picking up on the reason for this. It clearly reports worse chip and rom access speeds for OFW // better for alpha. I am at a loss to explain the cause.
I am personally happy with using MuFastRom for general use, but I am trying to give detailed feedback.
My goal here is detailed feedback. Please do with it what you wish.
Regardless of this anomaly, the card in its current state w/MuFastROM on is freaking awesome.
Greg