Hey trag! Long reply ahead, hope I'm not going too far into the weeds
1) IIRC, the WE_ pins on the ROM DIMM operated on 32 bits at a time. I think the CE_ pins do as well, and if they don't go to the same pairs, that would be an easy win. I have the pin out so that will be an easy check.
BTW, I posted my laboriously created-by-ohmmeter pinout in the Wiki here. However, the pinout for the Cache module listed in the X100 (NuBus PowerMacs) Hardware Developer Note contains almost all the same information and a little bit more. The main thing it lacks (because they hadn't done it yet) is listing the 3.3V Vcc pins. Those are unused in the cache listing.
Interesting...I
think that "32 bits at a time" fact might help simplify things, like you really only need 32 bits and you twiddle the OE/CS/WE pins to decide which half of the SIMM you're working on. I didn't realize the cache and ROM slots were identical on the NuBus PowerMacs....very interesting! Yeah, I had seen your work in the wiki on that pinout -- nice job!
2) What I would really like to do, if I can figure a scheme, is to use a TL866II+ as the programmer. Build a card with a ROM DIMM socket on top, and four sets of DIP header pins underneath. To program, plug one set of pins into the TL866II+ DIP socket, choose the appropriate chip. Program. Repeat 3 more times with different sets of header pins.
This is definitely an interesting thought. I felt like one of the big advantages of the programmer doing all the chips in one go was that it made it much quicker to try code changes when hacking the ROM. I'm pretty sure bbraun mentioned that a few times in the old IIci hacking thread as he was working on the ROM disk driver. It can get very tedious to swap things around in order to program the whole SIMM/DIMM. However, your point about the drawback of it being a purpose-built device also makes a lot of sense!
As long as there's some kind of unlock sequence per chip (as opposed to VPP) it should be possible to do one 8- or 16-bit chip at a time through the method you're thinking of with your external programmer. If VPP was the only thing unlocking writes though, you'd be in trouble because you'd be unlocking all the chips at once rather than just the one you currently have the data pins hooked to on the programmer.
Are there any 64 bit microcontrollers? I haven't looked at the Atmel line a while. The 9s12 and family doesn't go there. I'm not sure they ever got past 16 bit.
I've been wanting to learn to use Coldfire. In the past the development kit prices put me off (~$500) but I'm doing better these days. I think the individual chips were in the ~$30 so not bad for a programming board once the development is done.
You wouldn't really need to worry about the "bit-ness" of the microcontrollers for something like this. It's more about the number of free GPIO pins. Rather than using an external memory controller where you're actually doing read/write cycles, you're just twiddling GPIO pins to pretend that you're on a parallel bus. "Bit-banging" would be a good term for it. (Regardless, I'm not aware of any 64-bit MCUs but I wouldn't be surprised if they do exist somewhere...)
ColdFire seems like a pretty ancient architecture these days, although the 68k connection probably makes it a fun thought. I'd personally pick ARM, but that's just me
4) Hmmmm. But how many control lines does the microcontroller really need to operate?
It occurs to me that if one had some form of 64 bit wide storage device available, all the microcontroller really needs to do is to tell the storage device to deliver the data at the correct time. This could be as simple as a bank of 4 HY29F800 on the programmer. The programming process would be to program them one at a time from the controller (8bits or 16bits at a time), then after all four are programmed, have them output to the DIMM module as the programming data is needed for the whole the DIMM.
That's an interesting point. You could also do something like a shift register. That is basically what I did with my SPI GPIO expander too. It was just slower because serializing out the data took longer. To be honest, it seems like it would be kind of wasteful to program a set of flash chips on the programmer just for the purpose of sending the data out to another set of flash chips on the SIMM. (I see further down that you also thought about muxes and latches...those would make more practical sense for sure)
5) Apple stopped including memory maps in the Hardware Developer documentation in their later machines. Sigh. Something I read somewhere suggested to me that the ROM is allocated 256MB of address space. But it's vague and I can't remember where I read that. There's also some suggestion of repeating images -- which happens when the machine ignores intermediate address pins -- and that can get messy.
That would be interesting to find out. It definitely would depend on the number of available address lines in the ROM socket too.
@dougg3 Didn't you run into some issues/problems with repeating ROM images in the address space at some point? I sort of remember us having a discussion about it -- well mainly you explaining to me what you had found. I can go back and read the old thread to find it.
I do remember that! It's in the huge thread somewhere. The IIci's stock motherboard ROM repeats its 512 KB ROM, but only every 1 MB. So it repeats in chunks of <512 KB ROM> + <512 KB of emptiness>. I remember there being some kind of weirdness in the way it was wired on the motherboard. One of the address lines was hooked up to the motherboard ROM chip selects I think. It was really strange. The ROM SIMM socket itself didn't have any strangeness though. It'll just repeat over and over again inside of the 8 MB space if your SIMM is smaller than 8 MB. The weirdness was unique to the DIP ROMs. I'm pretty sure I traced one of the address lines to the DIP chip select pin.
6) The ambition to build larger capacity DIMM modules will be severely limited by what 5V Flash chips are still available. I think there were still some 16Mbit chips available on Ebay a while back, but I don't see them now. Availability of those chips was a major factor in Steve discontinuing the 8MB ROMinatorII, he said.
Yeah, it might be necessary to figure out some kind of level shifting if you need to do any higher capacity stuff. You're right. the 5V flash chip that I originally picked for the 8 MB SIMM (which Steve was using in the 4/8 MB ROMinator II models) was discontinued by Micron :-( Everything is headed toward 3.3V and less.
Only 16 data pins on the module would be getting signals of any kind. The other 48 wouldn't be connected. Might need to rig a little harness to stop them floating....
Yeah...floating might be okay, as long as they don't get interference from the signals that are actually being controlled. The unlock sequence is opposite bit patterns of 0xAAAAAAAA and 0x55555555, which is likely done on purpose to try to eliminate accidental unlocks. I'm not sure what it would take to tie the other ones to GND/power to prevent them from floating. It seems like a tricky problem (although I'm more of a software guy, so maybe it's simple from a hardware perspective and I just don't realize it)
Also assuming that it (TL866II+) has enough drive strength when there are four chips on the bus, instead of 1.
Good point!
The idea of a fairly simple microcontroller controlling a 64 bit data source is also interesting, but from reading your posting on the other thread, it's not that simple. One would have to intersperse the content on the data pins with these command codes.
Is the timing critical? I'm starting to think muxes and latches/data buffers.
I feel like it wasn't that difficult when it came down to it, although I definitely documented the struggle in the thread. It was also the first board using a microcontroller that I've ever designed myself, so there was a big learning curve just due to that fact. What it does is pretty simple compared to a lot of other embedded devices I've worked on though.
Timing wasn't really critical at all -- the MCU toggles the pins slowly enough that I don't need to be thinking about setup/hold times. On a faster MCU this might become more of an issue, but at that point you just have to add some delay code to meet the timing requirements. The most important part of the timing that I dealt with was just trying as hard as possible to minimize how long read and write cycles took. The longer they take, the longer the SIMM/DIMM will take to program. Steve was able to take my original firmware and optimize it down to only taking about a quarter of the original 8+ minute time to fully program an 8 MB SIMM.
One advantage of the mux/latch design concept is that it is, in theory, infinitely extensible, from an 8 or 16 bit Micro. So, if you're enjoying making the code more general, this would be a way one could add some parameters and have the thing program basically any width module.
I guess there would be a limit based on how many mux Select signals you could control at once.
Hmmm. And I wasn't even thinking about addresses. An 8Mbit, 16 bit wide chip has 512K addresses which is 19 address lines, I think. Could get dicey. Although, if the programming is purely sequential, that could be handled with an external counter, controlled from the Micro.
Right, mux/latch would help minimize the number of actual pins on the MCU needed -- at the expense of taking a bit longer to do each read/write cycle. It's all a trade-off. It still sounds like it would be much faster than serializing it through SPI so that would still be a big win. Yes, you definitely need a lot of address lines. It's not too difficult to find MCUs with a ton of pins though (well, other than the fact that we're in the middle of a chip shortage right now...)
You do want the muxes/latches to be bidirectional though. I'm not sure what kind of a challenge that would add. Sometimes you're writing to the flash, sometimes you're reading back. (The flash tells you when it's finished programming/erasing....although you can also just time it based on what the datasheet says...but trusting the chip to tell you it's done is probably safer and more future-proof if you change chip brands)
If you wanted to make the programmer more extensible, you'd almost just want to give it a ton of address lines, a ton of data lines (through muxes/latches/whatever if necessary), along with a few chip selects, OEs, WEs, etc. At that point it seems like you could make various little add-in cards for 64-pin SIMMs, 160-pin DIMMs, etc. I almost feel like I'm talking about designing a new generic flash programmer at this point, haha. But it seems like that strategy could help address concerns about it being too much of a single-purpose device. With the right set of plugin boards, it could be used for generic flash programming. I'm sure it's much more complicated than I'm making it sound though (different voltages, different pinouts, etc.) Wow I'm way off in the weeds now!
Starting to look like a Micro with a CPLD or FPGA.
I would recommend avoiding CPLD/FPGA unless absolutely necessary. Yes, you could probably do the read/write cycles a lot faster and actually make use of the full maximum speed of the flash IC...but it also turns it into a much more complex project. On the other hand, if you are an expert with those technologies, then ignore me! Where I work, we got into the FPGA stuff on a project and it was way over our heads and took a lot longer to complete than it otherwise would have. The final product was very nice...but it took a long time to figure it all out.
BTW, I like Micron chips, because Micron datasheets are usually the most clear about things like programming and (for DRAM) refresh and such. But I have hundreds of these other chips on hand.
I've been pretty impressed with Micron's datasheets too.
Another post that I wrote last night, right after the previous one, but somehow never clicked "Post". Nice that the forum or the browser saved it for me..
Gotta love it, I've done that all the time too. I think the new forum is a lot smarter about remembering stuff like that. It also seems much snappier now!