Jump to content

bbraun

6502
  • Content Count

    606
  • Joined

  • Last visited

3 Followers

Contact Methods

  • Website URL
    http://synack.net/~bbraun/

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. bbraun

    Q605/LC475 (onboard) ram upgrade.

    The 630 can take up to a 128mb SIMM in a 32x32 configuration, I believe. The second simm slot, on boards that have it, can only take up to 64mb (I think you need to use the 128mb SIMM, and only 64 of that is visible). There's several threads about it, and trag has described the SIMMs to use. It should be the same 128mb simms that work in the 605.
  2. It's probably fine to upgrade the soldered ram and not have to use the expansion card. But going above 4mb seems tough.
  3. Just because the Classic, LC, and IIsi were released together doesn't mean they share any architectural similarities. The IIsi uses the MDU memory controller found in the Iici. The Classic uses the BBU memory controller (well, calling it a memory controller is a stretch, it acks some bus accesses and moves physical ram around so the machine can boot out of ROM) found in the SE. The LC was the first with the new memory controller also used in the LCII. The physical locations of hardware are also their logical locations in machines without an MMU. Hardware lives at physical addresses, those don't change. An MMU, the processor can present a logical view that differs from the Physical view. Without an MMU, the two are necessarily the same. The memory controller in all macs going back to the 128k do some amount of moving the address space around, for example although ROM physically lives at 0x400000, the memory controller makes it available at 0x0 on boot so the processor can boot from it, then moves the bottom of RAM to address 0x0. The II and the LC memory controllers do a little bit more to allow the 24bit/32bit views of the world. The Classic has SCSI at 0x580000, SCC registers at 0x900000, IWM and VIA above that. They don't live at the same locations as on a Portable. The LC, supporting 32bit accesses, has things arranged more along the lines of the Mac II and subsequent 32bit capable machines. The hardware lives in the 0xF00000 range in 24bit mode.
  4. The address map for the Classic puts ROM at the 4mb mark, so it's kinda stuck to 4mb. All the 68000 macs use this address arrangement, with the exception of the Portable. The Portable is the odd one here, where it maps ROM at the 9mb mark. In the 68000 machines you can't really rearrange addresses since there's no MMU. You can't remap the hardware registers, so things are kind of stuck.
  5. bbraun

    Q605/LC475 (onboard) ram upgrade.

    JFYI, with the 610 series, you can't interleave RAM SIMMs because of the way they arranged the banks. It has half the SIMM slots, and rather than just leaving off the top 2 SIMMs, they've split things up so every other bank will be empty, preventing any interleaving of the SIMM slots. 8mb soldered is still interleaved, but the SIMM slots are gimped. I never thought much of the 650 and 800 machines until I started messing with the memory controller. Now, they're pretty much my favorite 040's. Solder on a ROM SIMM slot, put a modified ROM on there to disable the RAM check and enable the 128mb SIMMs, and just have fun with a ~300MB RAM disk.
  6. bbraun

    Q605/LC475 (onboard) ram upgrade.

    The memory controller on the 605 supports interleaving, but the 4mb of onboard ram is not interleaved because it is just 4mb in a single bank. The RAM SIMM will nearly always span banks and therefore be interleaved. Interleaving can give up to 10-15% speed improvement depending on how it is being accessed. The onboard video will always come from the onboard RAM (if there is any), so it will always use the "slower" RAM. You can also see this on the Centris/Quadra 610 and 650's. If you get one with 4mb soldered, it'll be non-interleaved, and if you get one with 8mb soldered, that'll be interleaved and therefore faster.
  7. bbraun

    LC 1 Ram Upgrade

    I don't have an LC, but I looked at the ROM disassembly a bit. There are definitely limitations in ROM, and from the ROM, it is likely the VISA memory decoder is limited to 10mb. The LC entry in the table the ROM has to tell it about the machine, says there are 2 banks of RAM: one up to 8mb, and one up to 2mb. The routine that figures out how much RAM is installed in each bank assumes always 2mb in the 2nd bank. The LCII uses the same memory controller, but has 4mb soldered on. I also do not have an LCII, but everymac says it is limited to 10mb, although you can install up to 12mb (2x4mb SIMMs + 4mb soldered), but only 10mb will be recognized. Looking at the LCII ROM, the LC's table entry is unchanged, but the memory sizing routine now detects 4mb vs. 2mb soldered RAM. So, if you changed the LC's table entry to expand the 2nd bank size up to 4mb, it might be able to detect 4mb soldered. However, that doesn't expand the total memory available. In the case of an LCII with 12mb installed, the missing 2mb comes out of the soldered RAM, not the SIMMs. When sizing memory, the onboard RAM gets temporarily relocated to 8mb, meaning the max RAM that could possibly be detected, even if the various tables are updated, is 8mb. Additionally, when the 4mb of onboard LCII RAM gets relocated to 8mb, it can no longer access the top 2mb of that RAM, which seems to me to indicate a limitation in the VISA memory controller. So, given all of that, it would appear the memory controller is limited to 10mb, but even if it is not, there are several places in the ROM that limit available RAM on the LC & LCII.
  8. bbraun

    LC1/2 Roms in a Macintosh II mainboard?

    Isn't there solder points for a ROM SIMM socket underneath those DIP sockets? Desolder the DIPs and solder in a ROM SIMM socket, and use a dougg3 ROM SIMM!
  9. bbraun

    SCSI2SD Project - anyone interested ?

    To program them, you pretty much need a miniprog3, which is about $90. It's only used once in the initial programming, since mmcmaster has the software update via usb working. He's made it so any jtag or swd programming device should work, but I haven't found any software other than the Cypress stuff that knows how to program these chips, and the device support for the Cypress stuff is limited. After fighting for a while to get my jlink2 device to program these things, I decided it was much more expedient to just get the miniprog3. Especially with being the first set of devices I assembled and not sure if it's my assembly or the software that was the problem. If you buy PCBs in quantity of 10, I think it ran about $3/board shipped. Then the rest of the parts come to about $30-$40 depending on quantity ordered, I think. The most expensive individual part is the processor, which is about $10 or so depending on where you get it and quantity. Unfortunately, it's also the most difficult to solder correctly by hand. I've messed up one or two, which is kind of a bummer but hey, that just means I could use the practice, right? The good news is, after assembling a couple of these, the floppyemus seemed easy!
  10. bbraun

    SCSI2SD Project - anyone interested ?

    That seems about right to me. Using the SCSI to CF setups, formatting a 4GB CF card on an SE/30 takes long enough that I just kick it off and go do something else for a while. Easily a couple hours. Those low level formats + verify takes a while.
  11. bbraun

    SoftRAID Level 5 for OS9, suggestions, possibilities?

    Maybe time for a sanity check? Ok, I've got a lot to say about these statements, some of which was covered by Gorgonops, but mostly I can't reconcile it with the later statement: The initial argument is don't do software raid because of performance, then recommending USB 1.1? Trash's initial concerns about controller failure are extremely valid, and IMO, one of the best reasons to use software raid, and acknowledges the performance tradeoffs. I see nothing wrong with the initial premise, although if you've got a small enough data set to fit on a single disk (or can be easily split between disks), avoiding RAID entirely would be preferable, and then doing as Cory suggested with manually mirroring data between disks with retrospect, or file copies, or whatever you find easiest, is going to be a better solution. This is OS9 we're talking about, with HFS, which does have a tendency to eat the filesystem and lose data during power failures, OS hangs/crashes, or just whenever. That old HFS isn't journaled or anything, so putting all your eggs in one volume isn't that hot, even if the underlying storage is fault tolerant. And for that reason, probably the single best thing you could do for data safety is putting it on a more modern system.
  12. bbraun

    IIsiColorPivotII_PDS_Card_HackProjectâ„¢

    Veering off topic here, but speaking of higher resolutions for older machines... The PCI ATI Radeon 7000 64MB can drive 1920x1200 over DVI. The PC version of the card can be had for cheap, but the EEPROM on the board is too small and needs to be swapped for a larger version. After that, it can be flashed for System 7 use. System 7 at 1920x1200 DVI is niiiice.
  13. bbraun

    SCSI2SD Project - anyone interested ?

    Awesome, thanks, that's what I needed. Sorry about the confusion there, I even looked at the schematic while assembling it, and it says "22". I just figured "22k" and went on my merry way. I've got one fully working, the other one probably just needs some touchups. Thanks again!
  14. bbraun

    SCSI2SD Project - anyone interested ?

    dougg3 had a similar thought. He found these chips have nonvolatile latches, but they don't seem relevant this particular problem, and from what I can tell, should be included in the hex files (which also encode the processor type and other metadata, not just the binary code).
×