I'm messing around overclocking the 30. Surprisingly, just replacing the xtal more or less works (with an external video card obviously!!). I'm looking for someone to shed a bit of light on a couple of issues.
the SE30 derives more or less everything from a single 31ish mhz xtal (realtime clock is separate). The mac two's use one xtal for bus clock, and a couple of other xtals for other things. Does anyone know for sure what the other things are (I assume video and possibly ADB / Serial / SCSI???
The rom has the ability to determine what kind of mac it's installed in and sets up a bunch of things (eg MMU present, memory map, VIA's etc).
1: how does it determine what hardware it's installed in?
2: is one of the things it sets up (perhaps global timing variables) related to the bus clock speed? eg, "im in an SE30, therefore I'm going to assume a 16mhz clock"..."I'm in a IISI therefore 20mhz"
the reason I ask is twofold
1: the mouse doesn't work but keyboard does so I'm assuming the ADB clock is out of spec when I change from 16 to a 20mhz bus speed. I can feed a separate clock signal in here as long as there's no sync issues with the via timing..
2: the sound is sped up (even the startup chime is an octave or so higher).. I'm assuming this is related to global timing variables / rom as the sony sound chippy seems to have it's own clock... If it was OS related, I'd assume startup chime would be OK.
For the ROM detecting which machine it is on, it varies over time as machines evolved, but for the SE/30 it is detected from VIA1 pins PA6 (a value of 1) and VIA2 pin PB3 (a value of 0). These values are used to index into a table that contains how to configure the machine. Which memory decoder is being used, address map, VIA initialization, etc. However, don't put too much stock into that table. It's important, but not as important as you might think. Although it contains things like whether an FPU is present, not all code checks the table. A lot of code still checks things at runtime, FPU being an obvious one. It also doesn't actually have any timing variables, a lot of that timing is driven by external circuitry (like the VIAs and/or memory controller depending on the machine and memory controller capabilities).
I believe the SE/30's ADB is driven (bit banged) by VIA2. The 60Hz timer that is important for mouse movement, and probably also the ADB bit banging is driven by VIA2 as well. If the clock is off for VIA2 (or VIA1 for that matter), I'd expect all kinds of things to be off.
The SCC's have important timing considerations as well. The serial speed and localtalk speed are dependent upon the SCC's having a 3.6864 MHz input clock. This speed should be consistent across virtually all macs with an SCC chip, although whether they get it through dividing the processor's clock, or using a different oscillator varies by model, I think.
The floppy is also timing sensitive, and there have been problems with CPU accelerators requiring driver changes to make the floppy work reliably.
Also, just pretending to be a IIsi is going to result in an unbootable system, since the IIsi has a very different architecture. The IIsi has the MDU memory controller, which includes the video and a very different emulation of a VIA2 than the SE/30's. It also has the egret controller for ADB access instead of bit banging off VIA2. So trying to alter the hardware detection to pretend to be a different machine would be pretty bad.
Thanks for that.
Rather than a wholesale change to say 'I'm a IISI', I was hoping there would be a place in the lookup that laid out bus speed. Given that the VIA's are used in two or three different motherboards with various speeds, there's got to be something that sets up the 60hz clock from the VIA's.. (or uses a separate xtal)
The sound is interesting too, there's a separate xtal for the sonysound chip, but the sound pitch increasing I did not expect. I'll re-read all the things you guys discovered about the sound circuit again.
The SE30 schematics are missing page 9, which is where a couple of signals 'ADB-SCLK and ADB-DIO' seem to originate from and feed VIA1 and the ADB proc.
Any hints as to what could be on page 9.?...
BTW. Enjoying your bootrom BBraun... really nice work..
I'm traveling this week, so don't have access to all the documents I have at home, but from what I have access to here, VIAs (across all models AFAICT) expect an input clock of 783360 Hz, and the constant for this is exported in MPW's asm interfaces I think. A timer in VIA2 is then set to fire once per millisecond, which is then used to calibrate things like SCSI access timings. But since the VIA clock is constant, there's no special calibration for the 60Hz timer. The SE/30 uses VIA2 timers to generate the interrupt, which feeds into VIA1, which then interrupts the processor for the 60Hz VBL timer.
Now that I'm back, I checked my schematics, and the VIA clocks are generated by the GLU, from the 15.6<etc>MHz cpu clock.
So it might be possible to sever the trace coming from the GLU to the 2 VIAs and replace that with the needed 783360 Hz clock.
Regarding bus timings, those are baked into the hardware in most cases. They just figured out how many wait states a VIA1 access needed to generate on a new machine and did it, so accelerators needed to not touch the bus clock. This also means the system software doesn't adjust timing loops per machine; they assume the hardware will generate enough wait states to make things work. The late 030 and 040 machines were somewhat configurable in that respect, but not usually to a useful extent (the chipset in the IIvx/IIvi let you configure the two speeds those machines came in, no other options).
Yeah, a 25% change seems pretty big. How stable is it?
So accelerator boards that are available for the SE/30 let the stock clock keep controlling the ICs attached to the bus, and just instructions sent to the CPU are accelerated? With an accelerator installed, the sound changes too. I am guessing it is running in some kind of raw PWM-like mode and is thus affected by the CPU speed at boot. I think otherwise the sound is normal.
I also changed out the 030 for a 40mhz version. It's really consistent in failure, runs for about 1/2 an hour with after dark screen saver pottering away then throws a bus error. At that point it won't soft boot (reset switch throws immediate 00000F 00000D error) (or it might be F, A, i've been distracted)...
I've just landed a 40mhz 882 copro, so I'll wrangle around with disabling the onboard and putting the copro in an expansion card (IISI riser)...
I dont have a scope currently, so can't even see if VBL or such is running. It may be simply stack overflowing, heap collision or something that's not being picked up by the housekeeping tasks....
It's tough with old hardware and stability, since it really could be just about anything. But with the wait states to sync up with the other parts of the system being baked into the GLU, I'm skeptical all the bus signals are going to line up correct every time. It seems like even with all the slop involved, you'll eventually get unlucky and have a bus error. Or end up with weird ADB data that exercises edge cases in the ADB handling code. This is always running in the background, the computer polls the last ADB device at like 100Hz, and we already know the ADB timing is off, so if the ADB devices aren't locking up/resetting with the garbage data, the device may be sending back garbage responses even while the machine is "idle". Also, the host side of ADB timings is much more stringent than device timings, so ADB devices could be getting upset.
I'd probably start with the clocks coming out of the GLU and replace those with fixed oscillators for the intended speeds.
As for whether the VBL is firing, if the cursor is updated at all, the VBL is running.
Completely agree on the vagueness of old hardware.
I'm pursuing a train of thought that the F,A error is an F trap exception, ergo I have a co-proc heat related problem, hence disabling the onboard and putting a faster co-pro on the expansion card.
the regularity and stability of the failure gives me hope. I wont attack the clocks just yet...
Tell me, how do apple derive the 3.672mhz clock for the ADB and Serial from a 31.3 ish source in the SE30???
I know it's done in the GLUE, but it's not a whole number multiple....
Small update, replacing 31.3 with a 32mhz xtal is stable and ADB works for an entire 350khz overclock.... I'm also running the co-pro on the Radius video card in the PDS slot. Onboard Copro is disabled. Onboard video is disabled. External video is 640/480. It's actually quite quick, netscape 3 is very useable (as long as you're not rendering big jpg's), warcraft just hums along, afterdark is smooth...sieveahl (ahl) consistently reports just over 800
I now want to generate the ADB clock from a separate source and keep upping the main clock as much as it will take. Ultimately it's got to be better with the ram /rom running same speed as the CPU/copro...
I know, I know, 'Woo hoo Tim, you've just created a IICI" :-D