Thread
Another IIci ROM hack
Yes, my super long Mario startup chime comes close to filling up the entire 2 MB address space of the SIMM. So the IIci definitely has the whole ROM address space mapped at some point early on in the boot process.
Also, the reset vector (the second 32-bit word in the ROM) of the IIci is $4080002a. So it's definitely using the 32-bit address space, and because that's the reset vector that *Apple* used, I think it's safe to assume the ROM repeats inside of the $40000000 to $50000000 space when it's in 32-bit mode. Edit: It also implies the IIci supports a maximum of 8 MB of ROM space, which would match up with the number of address pins in the SIMM socket -- I left 2 unused, which would bring my current 2 MB up to 8 MB of space.
The weirdness with the address line was that I discovered one of the address lines is tied to the DIP ROMs' OE or CS (can't remember which--the jumper controls the other one). The net effect is that the DIP ROMs are only mapped every other 512 KB in the address space--the other half of the time they don't respond. So for example, $40800000 to $40880000 contains the DIP ROMs, but $40880000 to $40900000 does not. The SIMM does not have this limitation though--otherwise my startup chime wouldn't work, and I've checked the pins with my continuity tester anyway. I have no idea if the SE/30 or IIsi or anything else are also mapped in this funky way, but I doubt it matters when you have the SIMM in place anyway.
When I boot my IIci into System 7.0.1, dumping memory addresses above 40900000 (or maybe it was 40880000, I can't remember) in MicroBug causes MicroBug to crash. I think the same thing happens in other sections of the $40000000 to $50000000 space where it's supposed to repeat other than $40800000 to $40880000. When I'm in 7.6, those addresses don't cause a crash. Both are using 32-bit addressing. So I think there's a difference in how 7.6 and 7.0.1 set up the MMU or something. Is it possible that we just need to figure out how to set up the MMU correctly? My fear is that older OSes set up the MMU without the extra available address space and that might be part of the problem. I didn't think about 24-bit addressing though, good call--the OS could definitely be doing something funny when it first boots up like putting it back into 24-bit addressing temporarily.
Also, the reset vector (the second 32-bit word in the ROM) of the IIci is $4080002a. So it's definitely using the 32-bit address space, and because that's the reset vector that *Apple* used, I think it's safe to assume the ROM repeats inside of the $40000000 to $50000000 space when it's in 32-bit mode. Edit: It also implies the IIci supports a maximum of 8 MB of ROM space, which would match up with the number of address pins in the SIMM socket -- I left 2 unused, which would bring my current 2 MB up to 8 MB of space.
The weirdness with the address line was that I discovered one of the address lines is tied to the DIP ROMs' OE or CS (can't remember which--the jumper controls the other one). The net effect is that the DIP ROMs are only mapped every other 512 KB in the address space--the other half of the time they don't respond. So for example, $40800000 to $40880000 contains the DIP ROMs, but $40880000 to $40900000 does not. The SIMM does not have this limitation though--otherwise my startup chime wouldn't work, and I've checked the pins with my continuity tester anyway. I have no idea if the SE/30 or IIsi or anything else are also mapped in this funky way, but I doubt it matters when you have the SIMM in place anyway.
When I boot my IIci into System 7.0.1, dumping memory addresses above 40900000 (or maybe it was 40880000, I can't remember) in MicroBug causes MicroBug to crash. I think the same thing happens in other sections of the $40000000 to $50000000 space where it's supposed to repeat other than $40800000 to $40880000. When I'm in 7.6, those addresses don't cause a crash. Both are using 32-bit addressing. So I think there's a difference in how 7.6 and 7.0.1 set up the MMU or something. Is it possible that we just need to figure out how to set up the MMU correctly? My fear is that older OSes set up the MMU without the extra available address space and that might be part of the problem. I didn't think about 24-bit addressing though, good call--the OS could definitely be doing something funny when it first boots up like putting it back into 24-bit addressing temporarily.
Thanks for clearing up the info about the address pin dougg3. We know for a fact that it works properly again. (I forgot some details where you already proved it!)
So I guess the OS version seems pretty much involved in this ROM Disk issue:
- MicroBug crashes when accessing past the 1MB mark in certain OS versions
- ROM Disks fail past the 1MB mark
For the ROM Disk problem, our theory here is that the ROM's OE / CS is controlled by the MMU and that the MMU is being goofed at some point by the OS. That would certainly screw up the ROM Disk, but this theory does not particularly jive with MicroBug crashing. If the MMU screwed up our extra address space and prevented the ROM chips from talking on the data bus at those addresses, would those addresses not return zeros or garbage or something in MicroBug? It's very odd that it would crash.
What intervention, version-dependent, could the OS possibly have with those addresses when running MicroBug? I am very much confused by this.
If there is an interrupt caused by trying to read from beyond the 1MB mark, then the interrupt handler, or lack thereof, could be crashing. I am not aware of any interrupts that are caused by reading from memory though.
Another possibility is that the act of reading from those addresses, itself, goofs the MMU, which would then bork MicroBug.
So I guess the OS version seems pretty much involved in this ROM Disk issue:
- MicroBug crashes when accessing past the 1MB mark in certain OS versions
- ROM Disks fail past the 1MB mark
For the ROM Disk problem, our theory here is that the ROM's OE / CS is controlled by the MMU and that the MMU is being goofed at some point by the OS. That would certainly screw up the ROM Disk, but this theory does not particularly jive with MicroBug crashing. If the MMU screwed up our extra address space and prevented the ROM chips from talking on the data bus at those addresses, would those addresses not return zeros or garbage or something in MicroBug? It's very odd that it would crash.
What intervention, version-dependent, could the OS possibly have with those addresses when running MicroBug? I am very much confused by this.
If there is an interrupt caused by trying to read from beyond the 1MB mark, then the interrupt handler, or lack thereof, could be crashing. I am not aware of any interrupts that are caused by reading from memory though.
Another possibility is that the act of reading from those addresses, itself, goofs the MMU, which would then bork MicroBug.
Well, I'm a liar.
System 7.0.1 dumps the entire ROM address space fine too -- WHEN I'm in 32-bit addressing mode. I wasn't paying attention the first time and failed to realize I was in 24-bit addressing. I also noticed System 7.6 reboots once (almost immediately after the Happy Mac) before finally completing the boot (because my PRAM battery is not installed). I'm thinking that's because the default value in PRAM is 24-bit addressing. Perhaps the purpose of that first reboot is to force the system into 32-bit mode. 7.6 won't let you go back to 24-bit mode, so that would make sense...
In 24-bit mode, dumping $40800000 works, and so does $40880000. But $40900000 causes MicroBug to exit. Let's see--in 24-bit addressing mode, the upper byte of addresses would be ignored, so I would really be dumping $800000, which as Dennis Nedry pointed out, is the ROM location in the 24-bit map. $40900000 would not be the extra ROM space, but rather NuBus slot $9 mapped at $900000. So THAT mystery is solved, I think.
This might also explain why Apple picked $40800000 rather than $40000000--it's valid in both 24- and 32-bit modes.
Still doesn't help with bbraun's boot disk project, but I'm feeling better with regard to my sanity...the system version probably doesn't matter after all.
System 7.0.1 dumps the entire ROM address space fine too -- WHEN I'm in 32-bit addressing mode. I wasn't paying attention the first time and failed to realize I was in 24-bit addressing. I also noticed System 7.6 reboots once (almost immediately after the Happy Mac) before finally completing the boot (because my PRAM battery is not installed). I'm thinking that's because the default value in PRAM is 24-bit addressing. Perhaps the purpose of that first reboot is to force the system into 32-bit mode. 7.6 won't let you go back to 24-bit mode, so that would make sense...
In 24-bit mode, dumping $40800000 works, and so does $40880000. But $40900000 causes MicroBug to exit. Let's see--in 24-bit addressing mode, the upper byte of addresses would be ignored, so I would really be dumping $800000, which as Dennis Nedry pointed out, is the ROM location in the 24-bit map. $40900000 would not be the extra ROM space, but rather NuBus slot $9 mapped at $900000. So THAT mystery is solved, I think.
This might also explain why Apple picked $40800000 rather than $40000000--it's valid in both 24- and 32-bit modes.
Still doesn't help with bbraun's boot disk project, but I'm feeling better with regard to my sanity...the system version probably doesn't matter after all.
Here is a photo of my test rig for ROM testing. I have to say that the programmer hardware/software is very easy to use. It allows quick flashing and testing of the ROM, dougg3 did a great job!!
I guess I'm the troublemaker here... I tried to fit System 7.1.1 onto the 1.5MB disk image, but it wouldn't boot. A few times at boot, the screen would show a floppy with a flashing 'X' and other attempts I would get a "sad mac". My SE/30 can boot off a IIsi ROM (no disks attached as shown above) with the modifications bbraun outlined and System 6 or whatever you can fit within 512KB.
Nice test setup! I love seeing pictures of the programmer/SIMMs out in the line of duty... 
Out of curiosity, is the Sad Mac error code 0000000F 0000000A?
Just checked--It's 0000000F 00000001.
woot! p.30 :approve:
IDRemember, has anyone figured out how to change a Machine ID in ROM or on the MoBo? :?:
ISTR somebody posting that RocketWare checks for presence of the IIsi ID and then refuses to run, giving a notification that it is incompatible with the IIsi. Sounds about right, Radius likely implemented this to avoid emanation of magic smoke with unprecedented regularity from the sadly underpowered PSUs afflicting the Flat/30.
Anybody got any ideas for a firmware hack along the lines of I Wish I Were?
IDRemember, has anyone figured out how to change a Machine ID in ROM or on the MoBo? :?:
ISTR somebody posting that RocketWare checks for presence of the IIsi ID and then refuses to run, giving a notification that it is incompatible with the IIsi. Sounds about right, Radius likely implemented this to avoid emanation of magic smoke with unprecedented regularity from the sadly underpowered PSUs afflicting the Flat/30.
Anybody got any ideas for a firmware hack along the lines of I Wish I Were?
Thanks to tt and dougg3 for testing, I think I've finally gotten the full 1.5MB issues worked out.
And man is it awesome! Nice work bbraun!
I've successfully booted from 7.5.3 and 7.6 Disk Tool disks appended to the end of the ROM. It's nowhere near as fast of a boot as the System 6 one in my video, but I would imagine it's still much faster than a floppy boot would be.
I'm thinking the IIsi ROM is probably the best one to be hacking. It's still only 512 KB so plenty of space for hacking, plus it can boot all Macs compatible with the ROM SIMM except for the Quadra 700. (I think--the IIsi ROM can boot a IIfx, right?) The next step for me is to figure out how to customize the startup chime in the IIsi ROM. It's probably just a matter of being the same code at a different offset.
I've successfully booted from 7.5.3 and 7.6 Disk Tool disks appended to the end of the ROM. It's nowhere near as fast of a boot as the System 6 one in my video, but I would imagine it's still much faster than a floppy boot would be.
I'm thinking the IIsi ROM is probably the best one to be hacking. It's still only 512 KB so plenty of space for hacking, plus it can boot all Macs compatible with the ROM SIMM except for the Quadra 700. (I think--the IIsi ROM can boot a IIfx, right?) The next step for me is to figure out how to customize the startup chime in the IIsi ROM. It's probably just a matter of being the same code at a different offset.
Glad to help out- great work!
In case someone else tries it with a diskless setup... I was a little confused when I found it booted from ROM automatically. Bbraun explained if the boot process could not find a disk in the first pass, it would try again, and then would enable the ROM disk even with no 'r' key pressed. I was able to boot System 7.0.1 (with an SE/30)...seemed pretty fast to me.
I'm trying to figure out what the minimum requirements for Bbraun's HTTP boot disk are http://synack.net/~bbraun/68khttpdisk.html. If it can work under 6.0.8, then I think there's enough space to add supporting extensions/control panels, otherwise I think there may not be enough room in 1.5MB of space. Even if currently read only mode works reliably, it would still be pretty awesome! 8-o
In case someone else tries it with a diskless setup... I was a little confused when I found it booted from ROM automatically. Bbraun explained if the boot process could not find a disk in the first pass, it would try again, and then would enable the ROM disk even with no 'r' key pressed. I was able to boot System 7.0.1 (with an SE/30)...seemed pretty fast to me.
I'm trying to figure out what the minimum requirements for Bbraun's HTTP boot disk are http://synack.net/~bbraun/68khttpdisk.html. If it can work under 6.0.8, then I think there's enough space to add supporting extensions/control panels, otherwise I think there may not be enough room in 1.5MB of space. Even if currently read only mode works reliably, it would still be pretty awesome! 8-o
So I'm thinking that the hardware part of this hack still isn't complete. There is room in the SIMM pinout for up to 8 MB of ROM space. The programmer board has the extra pins wired up too--it's only the SIMM that has to be changed. (And possibly a firmware update for the programmer if the chip uses a different programming standard). This is all assuming that I can find larger parallel flash chips that don't need any special programming voltages and just operate with data lines, address lines, and /CS, /OE, and /WE control lines.
It makes me sad because I have close to 100 bare 2 MB SIMM PCBs here, but I know the bigger 8 MB size makes a huge difference in capabilities for stuff like ROM disk booting.
Should we start thinking about an 8 MB SIMM? The main problem I'm having with early research is it's hard to find 5V chips in bigger sizes. Everything's moving toward 3.3V now.
It makes me sad because I have close to 100 bare 2 MB SIMM PCBs here, but I know the bigger 8 MB size makes a huge difference in capabilities for stuff like ROM disk booting.
Should we start thinking about an 8 MB SIMM? The main problem I'm having with early research is it's hard to find 5V chips in bigger sizes. Everything's moving toward 3.3V now.
Can all compatible machines map 8MB of space? If finding chips for 8MB is difficult, what about 4MB? The question of more room I suppose will always come up as being desired... 1.5MB of free space seems a little on the tight side to enable networking and System 7. It probably could be done though, but the disk image would be fairly bare bones.
What are the tradeoffs regarding SIMM form factors, EEPROM parts and physical limitations in terms of using more ICs on a larger SS eight IC SIMM or going to a DS Eight IC layout for increasing capacity?
There is room for 8 MB of ROM space in all supported models. The ROM is mapped from $40000000 to $50000000 in the SE/30, II, IIx, IIcx, IIci, and IIfx. The IIsi developer note says it's mapped from $40000000 to $42000000 with $42000000 to $50000000 being "reserved ROM space". The Mac generally considers $40800000 to be the ROM base address, which would suggest a maximum usable size of 8 MB--also corresponds to the number of SIMM address lines available.
Anyway, bottom line is we should be able to use the 8 MB of space from $40800000 to $41000000 on all of those models.
That may also be doable -- I'll have to check. If at all possible, I'd like to maximize the amount of available space, and 8 MB seems to be the true upper limit of the SIMM socket.
I thought about this and it's also a definite possibility -- it would require some programmer firmware changes (and possibly some simple logic gates on the SIMM too) because I would end up having to use address lines as chip selects. For example, if I found some 8 megabit (1 megabyte) chips, I could connect A0 through A19 to all eight chips, but then I would have to use A20 as a chip select -- if A20 was low, half of the chips would be activated, and if it was high, the other half of the chips would be activated. I could probably get this working properly with some gates--haven't thought the logic through in my head, but I would probably combine A20 with the SIMM chip select line, NOTing and ANDing and ORing as appropriate to generate a high and low chip select to actually hook up to the chips' CS pins (half high, half low). I know pin 63 is labeled as being some kind of an alternate chip select, but I have no clue if it actually does anything in any of the Macs. If it already works, that would be fantastic (and would sadly require a programmer board hardware change).
The M29F160FT5AN6F2 is a possible chip -- it's a 16 megabit chip, so I would need four of them, and it can be addressed on an 8-bit bus. So basically it would behave like a larger version of the chips I'm using now. I *believe* from a quick look at this chip that it would be completely compatible with the current programmer with no software changes at all if I wired it up correctly. Digi-Key lets you order it, although it's not in stock, so I have no idea what the lead time would be or how long the chip will be around in the future. It's also pretty expensive--$4 per chip and it would need to be soldered directly to the SIMM.
Micron is sounding more and more like the manufacturer to go with. They still make 5V chips for the automotive industry. Plus, I went on a tour to Micron's headquarters in Boise, Idaho when I was in high school and it was cool, so that has to mean something, right? 
Octopart.com is a very interesting site that lets you search for components to find places that have them in stock. Using it combined with Micron's list of active parts, I found that Avnet has a bunch of M29F160FB5AN6E2 chips in stock still and they only cost $2.66 in quantities of 1.
These are 16 megabit chips, so four of them would add up to the required 8 MB of space. I'm fairly sure this part would require no software changes if I wired it up correctly. I'm very tempted to start exploring this possibility now...
Octopart.com is a very interesting site that lets you search for components to find places that have them in stock. Using it combined with Micron's list of active parts, I found that Avnet has a bunch of M29F160FB5AN6E2 chips in stock still and they only cost $2.66 in quantities of 1.
These are 16 megabit chips, so four of them would add up to the required 8 MB of space. I'm fairly sure this part would require no software changes if I wired it up correctly. I'm very tempted to start exploring this possibility now...
That sounds v-e-r-y interesting . . . but not schtupid!< /Laugh In >
You could make a ROM card for the IIci's cache slot with a multitude of ROM SIMM slots, each multiplexed out to a separate address space. Then populate it with a handful of your ROM SIMMs. I bet you could fit 8 of your 2MB SIMMs on there for 16MB ROM -- which is possible because the cache slot has access to way more address lines.
A less aggressive approach could be to make a ROM SIMM adapter board that plugs into the ROM SIMM slot and provides 4 multiplexed slots, not unlike a RAM SIMM Saver. It seems that this might not fit physically into many Macs, but you never know.
It may be possible, albeit HAZARDOUS, to run a ribbon cable from the SIMM slot to this adapter board to relocate it. But it's certainly something to consider as a prototype especially if it can gobble up a few of these ROM SIMM boards.
A less aggressive approach could be to make a ROM SIMM adapter board that plugs into the ROM SIMM slot and provides 4 multiplexed slots, not unlike a RAM SIMM Saver. It seems that this might not fit physically into many Macs, but you never know.
It may be possible, albeit HAZARDOUS, to run a ribbon cable from the SIMM slot to this adapter board to relocate it. But it's certainly something to consider as a prototype especially if it can gobble up a few of these ROM SIMM boards.
That's an interesting idea to just reuse multiple old SIMMs! The physical space issue could be a problem though as you pointed out. For maximum compatibility with everything I'm definitely going to create an 8 MB SIMM and stay with that.
Hmmm, that cache slot does have interesting possibilities for IIci-specific hacking though. You could make a HUGE ROM...there's $10000000 of available space which comes out to 256 MB. That would be a ton of NOR flash...I think the 8 MB SIMM is probably more practical
I'd love to figure out a way to use serial storage devices like SPI flashes or SD cards instead, but I think they're too slow to parallelize the data fast enough for the Mac. I would be delighted to be proven wrong on that point though!
Hmmm, that cache slot does have interesting possibilities for IIci-specific hacking though. You could make a HUGE ROM...there's $10000000 of available space which comes out to 256 MB. That would be a ton of NOR flash...I think the 8 MB SIMM is probably more practical
I'd love to figure out a way to use serial storage devices like SPI flashes or SD cards instead, but I think they're too slow to parallelize the data fast enough for the Mac. I would be delighted to be proven wrong on that point though!
256MB of ROM could provide for some interesting hardware-level video projects.
The only reasonable way I can imagine to get that much ROM is to use a serial ROM, like that from a flash drive. To make it parallel, the only reasonable thing I can imagine is to put a program into a small parallel ROM that copies the serial ROM contents into RAM, then passes execution off into RAM. I have no idea what this would do to the OS!! Not good things. But if you don't want to use an OS, then maybe it's okay.
I'm just thinking out loud here.
The only reasonable way I can imagine to get that much ROM is to use a serial ROM, like that from a flash drive. To make it parallel, the only reasonable thing I can imagine is to put a program into a small parallel ROM that copies the serial ROM contents into RAM, then passes execution off into RAM. I have no idea what this would do to the OS!! Not good things. But if you don't want to use an OS, then maybe it's okay.
I'm just thinking out loud here.
HRMMM????????? [}] ]'> IIci Cache Card in a PowerCache Adapter?
The unused PDS of the IIfx also comes to mind, as does the Luggable, which was specifically designed for ROM expansion.
] ]'> IIci Cache Card in a PowerCache Adapter?The unused PDS of the IIfx also comes to mind, as does the Luggable, which was specifically designed for ROM expansion.
The Micron part you found is probably a more satisfying choice -- goes all the way to 8 MB -- but I figured I'd mention that I have several hundred HY29F800 chips on hand. They're in a PSOP package instead of the TSOP so they're a little larger 16 X 28mm vs. 12 X 20mm, but they're also easier to solder.
That would get you up to 4MB with four of them.
I have almost 500 of an SST brand 16Mbit part on hand, but they're 3.3V, darn it.
How complicated, robust or efficient need a 5V->3.3V step down circuit be for that small a load? :?:
I knew there was a thought in my head trying to get out...
Doug, if you don't mind using the PSOP44 package (what Micron calls the SO44) then you could lay out a board to use either the parts I have on hand, or the full capacity Micron parts. If there's a call for the 8MB capacity you could get the Micron parts, but as long as 4MB is satisfactory, it would be a little cheaper, and get me closer to that day when my attic is empty, to use the HY29F800s that I have on hand.
The downside is that your SIMM will probably be bigger with PSOP44 parts as opposed to TSOP48. The up side is that the pins are almost twice as big and twice as far apart.
jt, it would probably require a full level translator for every pin. That's not terrible, as I think they are available in a X16 package, but that would be roughly two level translator chips per Flash chip. That's a lot of extra stuff on the board. I checked the 39VF016 datasheet, because sometimes the IOs on 3.3V chips are 5V tolerant, but these aren't. The IO pins are rated for Vdd +/- .5V. So 2.8V to 3.8V. Or, if one pushes Vdd up to the maximum of 3.6V, then 3.1V to 4.1V. But 4.1 is still a distance from 5V. Anyway, if the I/Os were 5V tolerant, then one would just need a voltage regulator on board to change the 5V supply to 3.3V, and the I/Os could be hooked up directly, but no such luck. Some 5V memory DIMMs were built like that with 3.3V (but 5V tolerant) parts.
Doug, if you don't mind using the PSOP44 package (what Micron calls the SO44) then you could lay out a board to use either the parts I have on hand, or the full capacity Micron parts. If there's a call for the 8MB capacity you could get the Micron parts, but as long as 4MB is satisfactory, it would be a little cheaper, and get me closer to that day when my attic is empty, to use the HY29F800s that I have on hand.
The downside is that your SIMM will probably be bigger with PSOP44 parts as opposed to TSOP48. The up side is that the pins are almost twice as big and twice as far apart.
jt, it would probably require a full level translator for every pin. That's not terrible, as I think they are available in a X16 package, but that would be roughly two level translator chips per Flash chip. That's a lot of extra stuff on the board. I checked the 39VF016 datasheet, because sometimes the IOs on 3.3V chips are 5V tolerant, but these aren't. The IO pins are rated for Vdd +/- .5V. So 2.8V to 3.8V. Or, if one pushes Vdd up to the maximum of 3.6V, then 3.1V to 4.1V. But 4.1 is still a distance from 5V. Anyway, if the I/Os were 5V tolerant, then one would just need a voltage regulator on board to change the 5V supply to 3.3V, and the I/Os could be hooked up directly, but no such luck. Some 5V memory DIMMs were built like that with 3.3V (but 5V tolerant) parts.
Curses, foiled again!
)
Since the SIMM Slot appears to (at least to this noob?) address the EEPROMs in banks, would gating the address line translators add to, or reduce, the acreage of the step down circuitry?
Maybe the notion could be useful for the proposed Cache Slot card? :?:
Designing that one from the ground up for higher capacity EEPROMS rather than additional SIMMs/Connectors seems like it would be a much more elegant approach. The IIfx PDS notion got me thinking about a card with thru-holes on top and bottom for a dual purpose PCB design . . .
< over the top mode >
. . . if not provision for different interface connectors on all four sides of a square card! [}] ]'>
< /over the top mode >
) Since the SIMM Slot appears to (at least to this noob?) address the EEPROMs in banks, would gating the address line translators add to, or reduce, the acreage of the step down circuitry?
Maybe the notion could be useful for the proposed Cache Slot card? :?:
Designing that one from the ground up for higher capacity EEPROMS rather than additional SIMMs/Connectors seems like it would be a much more elegant approach. The IIfx PDS notion got me thinking about a card with thru-holes on top and bottom for a dual purpose PCB design . . .
< over the top mode >
. . . if not provision for different interface connectors on all four sides of a square card! [}
] ]'>< /over the top mode >
Rats, it's too bad the I/Os aren't 5V-tolerant. That's a really good idea and I should probably be checking other various 3.3V parts to see if any of them are 5V-tolerant. I'm assuming here that the voltage regulator wouldn't draw too much current...I don't want to start burning up people's logic boards!
Thanks for the info on your PSOP parts trag! I actually can't make the SIMM any bigger, or much bigger anyway. It will run into clearance problems in the SE/30 otherwise--at least that's what I understood when I was designing the original SIMM. I would be interested in leaving pads for both TSOP and PSOP on a SIMM if I could get them to fit, but it looks like the TSOP and PSOP pinouts are totally different so it would require some trace routing.
I was going to ask the same question about the feasibility of level shifting, so I'm glad you already asked it jt! I don't know anything about level shifting.There are 32 data lines and 24 other shared control lines (21 address lines plus WE,CE,OE), so I'd need a total of 56 pins level shifted. It could be done right near the bottom of the SIMM near the pads that go into the socket. If there are chips with 16, looks like it would take four of them total. I think the easier route (and what I'll probably do) is stick with 5V parts though.
Thanks for the info on your PSOP parts trag! I actually can't make the SIMM any bigger, or much bigger anyway. It will run into clearance problems in the SE/30 otherwise--at least that's what I understood when I was designing the original SIMM. I would be interested in leaving pads for both TSOP and PSOP on a SIMM if I could get them to fit, but it looks like the TSOP and PSOP pinouts are totally different so it would require some trace routing.
I was going to ask the same question about the feasibility of level shifting, so I'm glad you already asked it jt! I don't know anything about level shifting.There are 32 data lines and 24 other shared control lines (21 address lines plus WE,CE,OE), so I'd need a total of 56 pins level shifted. It could be done right near the bottom of the SIMM near the pads that go into the socket. If there are chips with 16, looks like it would take four of them total. I think the easier route (and what I'll probably do) is stick with 5V parts though.
If you are ever thinking about using a regulator to go from 5V down to 3.3-ish V, you can use series diodes instead of a regulator. Unlike series resistors, diodes will have the pretty much the same voltage drop over a range of different currents. The regulator will get you closer to 3.3, but in a pinch, try the diodes!
*like*< over the top mode >
. . . if not provision for different interface connectors on all four sides of a square card! [}
< /over the top mode >
You'll probably hate me for the suggestion, but... Aside from some address decoding, would it be a huge stretch from ROM SIMM to PDS? Not quite the same thing, but even easier to make bootable (for machines with a PDS slot).
And then put the programmer board and the flash on the same card.
Then again, maybe that can go on the list after the SIMM is done.
And then put the programmer board and the flash on the same card.
Then again, maybe that can go on the list after the SIMM is done.
Most PDS machines have different signals on the slots, that's why the electronics are so different on the PowerCache adapters. There are very few that are actually the same, I think Apple mixed it all up on purpose.
Thanks Dennis Nedry for the diode suggestion! That's a great idea and very simple.
I have no idea about the PDS at all...anything like that would have to come after the big SIMM Also, I'm limited by the cheap version of EAGLE. Maybe I'll have to learn KiCad to do more complicated (bigger, or more than 2 layer) boards. I noticed that iTead Studio is doing 4 layer PCBs now...they are very similar to Seeed Studio. So they are a possibility if we need something really fancy.
I hand-routed all 32 data lines, power, and ground. I'm running the auto-router now because frankly this board is harder to route than the 2 MB SIMM. With such a fine-pitch device, there's no room between pads to run lines. I'm probably going to ditch the LEDs on this iteration to make things simpler. Looks like even after the autorouter is done, I'm going to have to manually route some traces it couldn't route. Fun fun fun... 8-o
I have no idea about the PDS at all...anything like that would have to come after the big SIMM
Also, I'm limited by the cheap version of EAGLE. Maybe I'll have to learn KiCad to do more complicated (bigger, or more than 2 layer) boards. I noticed that iTead Studio is doing 4 layer PCBs now...they are very similar to Seeed Studio. So they are a possibility if we need something really fancy.I hand-routed all 32 data lines, power, and ground. I'm running the auto-router now because frankly this board is harder to route than the 2 MB SIMM. With such a fine-pitch device, there's no room between pads to run lines. I'm probably going to ditch the LEDs on this iteration to make things simpler. Looks like even after the autorouter is done, I'm going to have to manually route some traces it couldn't route. Fun fun fun... 8-o