68kMLA Classic Interface

This is a version of the 68kMLA forums for viewing on your favorite old mac. Visitors on modern platforms may prefer the main site.

Click here to select a new forum.
Overclock LC475/P475/Q605 without soldering or spicy-o-clock
Posted by: MrFahrenheit on 2024-08-12 11:17:01
Our good friend here, @Phipli (who runs the Elephant and Chicken website), has compiled some nifty software from this project:


The software consists of a system extension, and a 'control panel' type application, which is used for setting the parameters of the overclock inside the extension.
Posted by: MrFahrenheit on 2024-08-12 12:57:16
Tried the setup made by Phipli on my mystic upgraded Color Classic, which has a full 68040 CPU inside. I managed to get 40mhz in there as well.
Posted by: zigzagjoe on 2024-08-12 13:15:44
Can confirm that I replicated the same black screen behavior while changing resolution at 40mhz, though the OS was still running and could be gracefully shut down by the keyboard. On reboot it came up with the new resolution just fine.

A QOL change that could be good to implement is detect if the monitors applet is running and temporary back off clocks while it's open in order to allow dynamic resolution changes to work. Or, if you can hook whatever the OS does immediately before calling cscSwitchMode.
Posted by: Mustermann on 2024-08-12 14:20:29
I read some parameters to set for each frequency from ROM:

Configuration 0x50F0E030
RefreshInterval 0x50F0E034
FrameBufferConfiguration 0xF9800010

BIOSTimeout 0x50F18600
BIOSConfig 0x50F18000

Configuration, RefreshInterval, and FrameBufferConfiguration are well understood from MEMCjr datasheet.

BIOSTimeout and BIOSConfig are not written to MEMCjr but to SCSI controler 53C96 if I am right.
Does anyone know what register of 53C96 were populated by these values?
Posted by: Arbee on 2024-08-14 08:52:56
Those aren't 53C96 registers. Those are for the "TurboSCSI" implementation, which inserts wait states when accessing the 53C96.

Bits 8 and 9 are the read wait states (0 and 1 = 5, 2 = 4, 3 = 3), and bits 11 and 12 are the write wait states (same units).

BIOSTimeout is the delay for deciding the 53C96 has died if it stops responding.
Posted by: Powerbase on 2024-08-14 16:06:13
Awesome, just awesome. Ya'll put a smile on my stressed face. The 475 does have nice and speedy video.

IMG_20240814_175743954_HDR.jpg
Posted by: Byrd on 2024-08-15 02:09:25
Hang on, did I se LC575 is supported too? Does the utility have any issue with old school overclocked 33Mhz LC475s?
Posted by: Mustermann on 2024-08-15 03:40:22
GestaltID of overclocked 475 ist different from standard. Need to be in the list of the tool.
Posted by: MrFahrenheit on 2024-08-15 04:27:45
Hang on, did I se LC575 is supported too? Does the utility have any issue with old school overclocked 33Mhz LC475s?

I’ve tested the system extension made by Phipli on a stock 475 and on a resistor swapped (overclocked to 33mhz) 475, as well as a stock 575 inside my Color Classic. It works!

The software overclock might also work on the 630 and 580 machines, too. I haven’t tested those myself, yet.
Posted by: Powerbase on 2024-08-15 05:30:15
I’ve tested the system extension made by Phipli on a stock 475 and on a resistor swapped (overclocked to 33mhz) 475, as well as a stock 575 inside my Color Classic. It works!

The software overclock might also work on the 630 and 580 machines, too. I haven’t tested those myself, yet.

Yeah, my 475 was resistor-swapped to 33MHz. It runs fine from the initial benchmarking I did. I was honestly surprised. Hopefully that LC040 runs a little cooler too, compared to a full 040 at 40MHz. Still just a smidge below a 840av, though, ughh.
Posted by: Mustermann on 2024-08-18 12:06:35
I read some parameters to set for each frequency from ROM:

BIOSConfig 0x50F1800

Those aren't 53C96 registers. Those are for the "TurboSCSI" implementation, which inserts wait states when accessing the 53C96.

Bits 8 and 9 are the read wait states (0 and 1 = 5, 2 = 4, 3 = 3), and bits 11 and 12 are the write wait states (same units).

BIOSTimeout is the delay for deciding the 53C96 has died if it stops responding.
Thank you for the reply.
ROM is writing only bit 0 to register 0x50F1800 (BIOSConfig) and register seems to be 8 bit long. I'm confused because things don't fit together.

LEA BIOSAddr,A2 ; get base of BIOS
MOVE.L BIOS_Config(A2),d0 ; get Config register value
andi.b #$F7,d0 ; drop old D0{0:0} value
or.b (@BIOS_Config,d3.w),d0 ; only change bit 0 of this register
MOVE.L d0,BIOS_Config(A2) ; and write it out (only bottom 8-bits "stick")
...
; BIOS Configuration Register initialization values <h28>

@BIOS_Config
@BIOS_Config20 dc.b %00000001 ; BCLK_25 = 1 <H28>
@BIOS_Config25 dc.b %00000001 ; BCLK_25 = 1 <H28>
@BIOS_Config33 dc.b 0 ; BCLK_25 = 0 <H28>
@BIOS_Config40 dc.b 0 ; BCLK_25 = 0 <H28>
Posted by: Arbee on 2024-08-18 19:04:04
The andi.b #$f7, d0 clears bit 3 of d0, not bit 0. $f7 is binary 11110111.

I was looking at the wrong thing earlier. BIOSConfig is 8 bits.
b7 = 0 to use BIOS's internal SWIM2, 1 for external
b6 = 0 to make MACE accesses take 2 MACE clocks, 1 for 3 MACE clocks (no BIOS machine has MACE)
b5 = 0 if the Ethernet chip is SONIC, 1 if it's MACE
b3 = 0 for SCC accesses to meet timing requirements for an 8 MHz SCC, 1 for a 16 MHz SCC
b2 = 0 for BIOS built-in ASC, 1 for external
b1 = 0 for external ADB handling, 1 to use BIOS's built-in ADB Master Cell (which doesn't work and didn't work until the G3 timeframe, at which point MacOS never used it anyway)
b0 = 0 for BCLK > 25 MHz, 1 for 25 MHz or less
Posted by: Mustermann on 2024-08-19 10:43:10
The andi.b #$f7, d0 clears bit 3 of d0, not bit 0. $f7 is binary 11110111.

b0 = 0 for BCLK > 25 MHz, 1 for 25 MHz or less
You are right about $f7. So there is a typo at several copies of this code that can be found in the internet.

I understood that the bit the ROM was changing
b0 = 0 for BCLK > 25 MHz, 1 for 25 MHz or less
according the clock resistors soldered on the 475/605.

But what is this setting doing for or in which chip?
Is it related to SCSI (or something else)?
Ok I can just set it, as done by the ROM but I prefer to understand what is going on.
Posted by: Arbee on 2024-08-20 12:09:27
There aren't details available, but I'm gonna guess setting it wrong could glitch all of the things IOSB/BIOS handles (SCSI, serial/LocalTalk, sound, floppy, the VIA interface to Cuda).
Posted by: Mustermann on 2024-08-20 13:10:40
No need - just wrap the actual register fiddling in SwapMMUMode calls. I should have put this in my extension; forgot I was running 7.6.1 which is 32 only. SwapMMUMode will do nothing if already in 32 (ie. harmless).

char busMode = 1;

SwapMMUMode(&busMode); // go 32 bit, if in 24 bit
(register stuff);
SwapMMUMode(&busMode); // return to original MMU mode
I tried to add this code but compiler throw an "function has no prototype" error.
Seems I need to include something, but I do not know what.

Someone can help?
Posted by: zigzagjoe on 2024-08-20 13:13:42
I tried to add this code but compiler throw an "function has no prototype" error.
Seems I need to include something, but I do not know what.

Someone can help?
Try OSUtils.h

You may also use true32b instead of 1 for the busMode - that's the proper apple constatnt (which is 1), I was just lazy, and it's not like it's going to be changing.
Posted by: Mustermann on 2024-08-20 13:22:07
OSUtils was the missing information!

#include <OSUtils.h>
...
signed char busMode = true32b;
SwapMMUMode(&busMode);

was compileable without errors or warnings.
Posted by: MacKilRoy on 2024-08-21 05:23:11
All of the raw code talk has me wondering what the discussion is about. Are you adding more things that can be adjusted with the speed settings besides just CPU speed? Like keeping the SCSI controller chip from running so fast it freezes the machine? Or serial ports not functioning after a certain speed as is common?
Posted by: Mustermann on 2024-08-21 07:38:56
Things like that are what this thread is about, if I am right.
Posted by: Arbee on 2024-08-21 09:57:41
More importantly, if the SCSI chip is accessed too fast it could potentially damage data on your writable SCSI devices.
< 4 >