Jump to content
  • Posts

    • @rplacd the VIA is the main interface chip, at least in the original 68000 based macs - it's a Rockwell (typically) 6522, or these days, the 65C22N from WDC.
    • Here's what i lifted from the inside macintosh hardware reference books - vol III, it's referencing the Mac 512k/Plus RTC which is only 20 bytes of PRAM, but other than that, the rest of the chip is identical. The 1-sec output doesn't drive a clock, it drives the 65C22's interrupts every second, so not having an exact 1sec output is a no-go. Running the MCU off the external 32.768Khz clock should still be doable, though, it doesn't have to do much 'heavy lifting'. I'm also trying to have a look to see if there's any I2C chips that would work in this config - most seem to have an almost identical pinout, just not more than 64 bytes of EEPROM for PRAM for almsot all of them.   The Macintosh real-time clock is a custom chip whose interface lines are available through the VIA. The clock contains a four-byte counter that's incremented once each second, as well as a line that can be used by the VIA to generate an interrupt once each second. It also contains 20 bytes of RAM that are powered by a battery when the Macintosh is turned off. These RAM bytes, called parameter RAM, contain important data that needs to be preserved even when the system power is not available. The Operating System maintains a copy of parameter RAM that you can access in low memory. To find out how to use the values in parameter RAM, see chapter 13 of Volume Il. Accessing the Clock Chip The clock is accessed through the following bits of VIA data register B (vBase+vBufB): rTCData .EQU 0 ;real-time clock serial data line rTCClk .EQU 1 ;real-ti.me clock data-clock line rTCEnb .EQU 2 ;real-time clock serial enable These three bits constitute a simple serial interface. The rTCData bit is a bidirectional serial data line used to send command and data bytes back and forth. The rTCClk bit is a data-clock line, always driven by the processor (you set it high or low yourself) that regulates the transmission of the data and command bits. The rTCEnb bit is the serial enable line, which signals the real-time clock that the processor is about to send it serial commands and data. To access the clock chip, you must first enable its serial function. To do this, set the serial enable line (rTCEnb) to 0. Keep the serial enable line ~ow during the entire transaction; if you set it to 1, you'll abort the transfer. Warning: Be sure you don't alter any of bits 3-7 of VIA data register B during clock serial access. A command can be either a write request or a read request. After the eight bits of a write request, the clock will expect the next eight bits across the serial data line to be your data for storage into one of the internal registers of the clock. After receiving the eight bits of a read request, the clock will respond by putting eight bits of its data on the serial data line. Commands and data are transferred serially in eight-bit groups over the serial data line, with the high-order bit first and the low-order bit last. To send a command to the clock, first set the rTCData bit of VIA data direction register B (vBase+vDirB) so that the real-time clock's serial data line will be used for output to the clock. Next, set the rTCClk bit of vBase+vBufB to 0, then set the rTCData bit to the value of the first (high-order) bit of your data byte. Then raise (set to 1) the data-clock bit (rTCClk). Then lower the data-clock, set the serial data line to the next bit, and raise the data-clock line again. After the last bit of your command has been sent in this way, you can either continue by sending your data byte in the same way (if your command was a write request) or switch to receiving a data byte from the clock (if your command was a read request). To receive a byte of data from the clock, you must first send a command that's a read request. After you've clocked out the last bit of the command, clear the rTCData bit of the data direction register so that the real-time clock's serial data line can be used for input from the clock; then lower the data-clock bit (rTCClk) and read the first (high-order) bit of the clock's data byte on the serial data line. Then raise the data-clock, lower it again, and read the next bit of data. Continue this until all eight bits are read, then raise the serial enable line (rTCEnb }, disabling the data transfer. The following table lists the commands you can send to the clock. A 1 in the high-order bit makes your command a read request; a 0 in the high-order bit makes your command a write request. (In this table, "z" is the bit that determines read or write status, and bits marked "a" are bits whose values depend on what parameter RAM byte you want to address.) Command byte Register addressed by the command z000000l Seconds register 0 (lowest-order byte) z0000101 Seconds register 1 z0001001 Seconds register 2 z000l101 Seconds register 3 (highest-order byte) 00110001 Test register (write only) 00110101 Write-protect register (write only) z010aa01 RAM address 100aa ($10-$13) zlaaaaOl RAM address Oaaaa ($00-$0F) Note that the last two bits of a command byte must always be 01. If the high-order bit (bit 7) of the write-protect register is set, this prevents writing into any other register on the clock chip (including parameter RAM). Clearing the bit allows you to change any values in any registers on the chip. Don't try to read from this register; it's a write-only register. The two highest-order bits (bits 7 and 6) of the test register are used as device control bits during testing, and should always be set to 0 during normal operation. Setting them to anything else will interfere with normal clock counting. Like the write-protect register, this is a write-only register; don't try to read from it. All clock data must be sent as full eight-bit bytes, even if only one or two bits are of interest. The rest of the bits may not matter, but you must send them to the clock or the write will be aborted when you raise the serial enable line. It's important to use the proper sequence if you're writing to the clock's seconds registers. If you write to a given seconds register, there's a chance that the clock may increment the data in the next higher-order register during the write, causing unpredictable results. To avoid this possibility, always write to the registers in low-to-high order. Similarly, the clock data may increment during a read of all four time bytes, which could cause invalid data to be read. To avoid this, always read the time twice (or until you get the same value twice). Warning: When you've finished reading from the clock registers, always end by doing a final write such as setting the write-protect bit. Failure to do this may leave the clock in a state that will run down the battery more quickly than necessary. The One-Second Interrupt The clock also generates a VIA interrupt once each second (if this interrupt is enabled). The enable status for this interrupt can be read from or written to bit 0 of the VlA's interrupt enable register (vBase+vIER). When reading the enable register, a 1 bit indicates the interrupt is enabled, and 0 means it's disabled. Writing $01 to the enable register disables the clock's onesecond interrupt (without affecting any other interrupts), while writing $81 enables it again. See chapter 6 of Volume Il for more information about writing your own interrupt handlers. Warning: Be sure when you write to bit 0 of the VIA's interrupt enable register that you don't change any of the other bits.  
    • Seems like I hear a lot about people having a dead Egret chip?  
    • SWIM, RTC, and SND is a good bet – you get them on many models.   What is the VIA chip, by the way? I've had Maxell bombs get them on Classics, but after doing some research I notice that many models have them.
    • I am restoring an SE/30. Before posting, I have browsed the forums and read many similar accounts. The main theme so far is “recap” first and foremost, followed by cleanup, patience, perseverance and hopefully, kind collaboration.   SO, one issue at a time and some background info: This is late-model 1991 SE/30 with 8 megs of RAM, all SIMM slots populated. It has an intact, working lithium battery, and was discovered to have leaked electrolytic capacitors. It boots, has a working floppy and what looks like maybe an 80-meg SCSI HDD. System 7.x. Initial problems: Electrolyte around all of the sliver caps — NOW REPLACED. (before I even booted the system, I re-capped the logic board, cleaned everything in soapy water, isopropyl alcohol, dried.  Now recapped and cleaned: 1. Booted without a chime, just a mild speaker pop. 2. Booted fine, though screen a little bit “shimmery” with a few rows of pixles shifting right a pixel-wdith ever few moments here and there. This is difficult to see, and it seems to settle down as it warms up a bit. 3. Attempts to play alert sounds result in abbreviated playback followed by a freeze. Cmd-Opt-ESC lets me force quit and relaunch Finder. Basically, audio triggers usually lock the application. This has evolved over a week or so. At one point, it was letting me play every alert except Simple Beep, which froze the system. Later, it let me play other sounds three times in a row, but by the third time, it would freeze. I have NEVER heard a boot chime. I once removed all SIMMS, and it plays a steady continuous chord. 4. Avoiding the sound issues, I have been able to load floppies, connect to the MacIPpi Gateway via AppleTalk (phoneNet, AsanteTalk bridge, ethernet, pi). 5. Finally, while transferring files successfully via AppleTalk, the screen flickered a second and BAM, I have “Jailhouse Mac”. Vertical bars are now obscuring the entire screen every eighth inch or so—three pixels on, four or five black—column after column.   I know I have a long way to go—awaiting shipment of desoldering alloy to remove some chips. I was intending to follow @PotatoFi’s recent example by removing the ASC and cleaning pads etc. as our audio issues are/were identical. But the jailhouse vertical bars are a setback. The system still boots fine, it still works on the network without issue—I just cannot read stuff!   SO, I am posting a picture of the screen and asking for some input. Where should I start? I assume this is probably corrosion issues around the caps I replaced. I have read other examples here where advice is given to buzz traces. I can start with some of this now as I have a meter, but what is my best reference? Should I be using the Apple schems from the MacintoshRepository.org or is there a better reference list of point-to-point continuity tests I should use? I have seen reference to traces A(0) and A(1) for example, but what are these? Should I spend some time learning to read the schematics? Am I seeing this referenced as lines from the ROM SIMM?   Any sage advice is welcome, as I have all the time I need (great stuff for lockdown, eh?) and naturally hoping to learn a ton. I am not afraid to do replace stuff, as I think I did a fine job on the caps. I have a decent iron, solder, flux, wick, loupe. No reflow station or heat or anything too advanced. . . and I await some de-soldering alloy.   This could go in several directions (and probably will) but it is the video issue that has me posting this here now. Is that a good place to start?   Thanks!