• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

PEx ROM Project

trag

Well-known member
As a slight tangential aside - https://www.downtowndougbrown.com/programmable-mac-rom-simms/ and http://www.bigmessowires.com/mac-rom-inator-ii/

Wonder if something like this is adaptable for later ROM SIMMs....

For now I'm planning to lay out a DIMM reader, but I also have in mind to modify my DIMM design a little so that something similar to Doug's programmer can work on it.

The thing is, these DIMMs are 64 bits wide. Unless the chips on board can be addressed/activated-for-programming one or two at a time, it will get complicated.

On my list of things to do is looking at Doug's design to see if he set it up to program all four chips at once, or one or two at a time.

The thing about Doug's and Rob's work though is that they synergized very nicely. They both happened to be looking at their respective things at the same time. Rob was looking at how to modify some low level things (memory max, startup sounds, RAM disks, bootable ROM images - like the Classic has onboard) and Doug was looking at creating a custom ROM module for the older machines. It may have been Doug who was looking at sound originally. I can't remember any more.

I think it started with someone pulling the IIci ROMs and replacing them with sockets and programmable chips. The work was tracked, as it happened, in a very long thread on this forum, way back when.

But the two sets of work dovetailed with each other and luckily occurred in the same time frame.

There's not really, as far as I can tell, anyone chomping at the bit to modify firmware in the X100 through Beige era machines. At least, not yet. The closest thing is Cheesestraws work on fixing PCI-PCI Bridge support in the Gazelle and maybe the Alchemy boards.

I would like a fix for PCI-PCI bridges in the Umax S900, but that machine doesn't have a ROM slot. Modifying/replacing the four soldered down chips are the only choice on that machine.

Anyway, all that said, it still couldn't hurt to have a programmable ROM module for the whole family of machines. It sure looks like the modules used in the PEx machines are programmable modules -- whether they are programmable while installed in th3 PEx or require some special rig that lived at Apple, I don't know. But they use EEPROM chips and appear to have the Vpp pins wired up, which suggests an intent to reprogram the module.

@jimjamyahauk Why don't you send me your shipping address in PM, or email (trag@prismnet.com). jt will be shipping a couple of what we hope are the Digibarn copies back to me in the next week or two, and then I'll ship them on to you.
 

dougg3

Well-known member
On my list of things to do is looking at Doug's design to see if he set it up to program all four chips at once, or one or two at a time.

Hey trag, I answered that for you in the other thread, I think you might have missed it. I probably should have moved over to this thread too :) The abridged version is that it programs all 4 simultaneously, but you can also program only a specific chip if you want by giving the other chips invalid unlock sequences during the programming process.

I think it started with someone pulling the IIci ROMs and replacing them with sockets and programmable chips. The work was tracked, as it happened, in a very long thread on this forum, way back when.

Here is the thread...unfortunately jt's index at the top doesn't work anymore due to the various forum migrations since then, but I'm just happy that the thread still exists! It all started with a discussion with one of my coworkers about how cool it would be to hack a custom startup chime into my IIci. The only major software stuff I did was the startup chime hacking, everything else with the ROM disk stuff was bbraun. He had the vision to realize the cool stuff that would be possible once we had a ROM larger than 512 KB.

As a slight tangential aside - https://www.downtowndougbrown.com/programmable-mac-rom-simms/ and http://www.bigmessowires.com/mac-rom-inator-ii/

Wonder if something like this is adaptable for later ROM SIMMs....

Anyway, all that said, it still couldn't hurt to have a programmable ROM module for the whole family of machines. It sure looks like the modules used in the PEx machines are programmable modules -- whether they are programmable while installed in th3 PEx or require some special rig that lived at Apple, I don't know. But they use EEPROM chips and appear to have the Vpp pins wired up, which suggests an intent to reprogram the module.

This definitely sounds like an cool idea! I'm unsure whether or not the ROM disk would be possible. It depends on how much of the memory map is reserved for ROM. On later machines with the older ROM SIMM, Apple already had started cutting back on the amount of addressable space. For example the Quadras can't use the full 8 MB of ROM address space that the II series and SE/30 can use.

Hardware-wise, it wouldn't work with my programmer out of the box because the ROM module for the PowerPC Macs had more pins. Also, technically the PowerPC module is a DIMM rather than a SIMM because each side of the module has different signals on the pins. But anyway...my programmer would probably still be a good starting point for someone, from a software/firmware perspective at least. I'm probably already getting too far into the weeds, but one thing that I would suggest, if someone decides to make a programmer for this, is try to find a more modern microcontroller that has enough pins to talk to everything at once. One performance bottleneck with the programmer's current architecture is 16 of the 32 data pins go through an SPI GPIO expander, and the SPI transactions take relatively long. The AVR microcontroller just didn't have enough pins so that was a tradeoff. With the PowerPC module this will become an even bigger problem since it's a 64-bit data bus. Another option would be to figure out some way to address only some of the chips at once...like swap out which set of 16 data pins you are currently interacting with. As long as there's an unlock write cycle sequence during programming/erasing, that should be possible even if the same /WE signal is shared among all the chips on the entire DIMM.

Anyway, this thread is pretty awesome, and it's been fun reading this and watching as you all figure things out :)
 

trag

Well-known member
@dougg3 Hi Doug! I'm glad you joined us. You're right, I missed your other reply. I will nip over there and read it in a bit.

I can't respond as well as I would like to your post without doing a lot of research. :)

Off the cuff:

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.

One may wonder why a cache listing has the ROM pinout. On the X100 machines they used the same slot/form factor for both and the slots are, in fact, interchangeable. They kept the design for the X500/X600 ROM, but changed the X500/X600 cache slot.

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 would require some way of addressing the chips one at a time. But it would also avoid building a purpose-built programmer. At about $60 base cost, I suspect this would be cheaper than rolling my own.

3) If that's not going to work, I'll need to start reading the datasheets for programming the HY29F800 and similar.

I've written a programming routine (in assembly) for a serial SPI Flash on a SPI bus before, so I'm sure I am capable, but those skills are rusty, so it's going to be a creaky process.

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.

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.

The disadvantage to just using four HY29F800s as an intermediate storage is that it limits the ROM module to 4MB.

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.

@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.

256MB is believable, because the later machines never operate in 24 bit mode. So there are 16 of these 256 MB chunks laying around just waiting to be used for something.

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.
 

trag

Well-known member
@dougg3 Okay, read your very helpful posting in the other thread. I'm back.

Yes, if one can control the write/erase commands by code on the data pins, then writing the chips one at a time should be pretty simple. Actually, that would play into my idea of using a TL866II+ programmer and a break-out board too. Assuming the TL866II+ uses that method of programming, and there isn't some alternative that it uses. 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....

Also assuming that it (TL866II+) has enough drive strength when there are four chips on the bus, instead of 1.

I want to build the 16 bits at a time reader break-out board, so I may as well incorporate the programming stuff on it too and see if it works, I guess. I have some rudimentary programmability on the current DIMMs, if I add a few resistors and a couple of rework wires. I think I may have to cut a few traces too. I made notes, thank goodness. I had programming in mind back in 2003, but it was an afterthought. The pads and holes for connecting up WE_ and Vpp aren't great.

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.

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.

Starting to look like a Micro with a CPLD or FPGA.

Ah, well, I can think of about 4 different ways to maybe do this. I need to go read the HY29F800 datasheet and maybe the AM29VF16 (3.3V for the Beige G3) as well.

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.

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..
 

dougg3

Well-known member
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!
 

trag

Well-known member
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 :)

I may be completely wrong, but at some point I picked up the impression that ARM is not completely documented for the user. That there are aspects to the video out and other components that they don't reveal how the bits are moving around in a user's manual/datasheet.

That puts me off of using it. On the other hand, I may have picked up a false impression. Also, it probably doesn't matter in practice. I just don't like supporting the trend towards SOCs that aren't actually properly documented.

Still reading your reply. Just wanted to spew that one out, before I forget.

Also, amused by your concern about the length of your post, considering the two giant posts from me preceding it.
 

trag

Well-known member
First, thank you for all of the information and thoughts regarding the stuff I didn't quote. I'm mulling it over. Mainly, I need to visit some datasheets and do the work part for while, instead of the much more pleasant discussing-it-on-line part. I also need to determine whether I have a datasheet for that ROM DIMM connector and go looking for one if I don't. Failing all that, there's always a ruler....

On the bright side, while the tolerances between pins are very small, these connectors are regular and have a great many pins. So one can usually just take a measurement over 20 or 50 pins and then divide to figure out what kind of pitch they used.

You do want the muxes/latches to be bidirectional though. I'm not sure what kind of a challenge that would add.

I'm pretty sure I've seen datasheets for bi-directional latches. Or buffers of some kind. I might have a reel of them in the attic. More datasheet browsing. I remember a chip with fairly simple data pin arrangement, but a complex set of control pins with states something like: 1) load buffer from side A, 2) load from Side B, 3) output active on Side A and/or Side B, or tristated.

I'm not sure, but I think muxes can always be used in both directions. Set it up one way, and you're controlling the destination for your output. Set it up the same way, and you're controlling the source of your input -- Assuming the two sides are connected to I/O pins and not just I or O. Datasheet again.

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.

I like the idea of setting up an address counter and then just pulsing it's control from the micro. It's more components... But this is mostly for fun. Are the addresses always used sequentially? A counter won't work, if the addresses need to be provided out of sequence.

I threw off that extensible comment without really thinking it through. I doubt there's much in the way of firmware modules wider than 64 bits out there.

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.

I think for at least the first hack, I'll just use discreet components. In theory I can program CPLDs/FPGAs and wrangle VHDL and Verilog. As I was mentioning in another thread, that experience is almost 20 years old, and I have a block/avoidance -- some kind of mental issue with setting up development environments. Hand me an IDE all ready to go, and I'm happy. Tell me I must track one down and get it working, and I'm nearly paralyzed, for some reason. I can probably tackle it if I look at just the next step and don't worry about the bigger picture.

I'm going to blame it on the Systems Programming class in 1985 in which we were told all our work would be in Ada. Um, shouldn't an Ada class have been a pre-requisite?

Okay, off to job work, and eventually, off to peruse the datasheet collection.

Or maybe just off to lay out the board that would use the TL866II+. It won't cost too much to have JLCPCB run off a few boards, and I already have a dozen of the DIMM sockets on hand. I just need some 44 pin DIP headers, and I can try it out. Then move on to more complex things as needed.
 

cheesestraws

Well-known member
ARM is not completely documented for the user

The ARM architecture itself is pretty well documented; the different chips that implement that instruction set, documentation is... variable depending on the predilections of the manufacturer in question. Are you thinking of the BCM ones that the r-pis use? Those have big transparency problems (hah) where the video/GPU isn't properly documented and needs binary blobs to work properly. But this doesn't apply to all ARM SoCs, just that Broadcom is, as usual, being questionable.

mutters darkly about writing ARM code before it was cool ;-)
 

trag

Well-known member
The ARM architecture itself is pretty well documented; the different chips that implement that instruction set, documentation is... variable depending on the predilections of the manufacturer in question. Are you thinking of the BCM ones that the r-pis use? Those have big transparency problems (hah) where the video/GPU isn't properly documented and needs binary blobs to work properly. But this doesn't apply to all ARM SoCs, just that Broadcom is, as usual, being questionable.

mutters darkly about writing ARM code before it was cool ;-)

Ah, yes, thank you. That triggered a memory. I was, in fact, reading about R-pis when I developed this impression. So my problem is probably just with Broadcom and their ilk.
 

cheesestraws

Well-known member
My impression is that the microcontroller sized ARM chips are significantly better documented than the "computer" SoCs, but I may be wrong there. I don't write code for modern ARM, so this is second-hand information. :)
 

CC_333

Well-known member
Warning!! protracted off-topic post ahead!
I'm going to blame it on the Systems Programming class in 1985 in which we were told all our work would be in Ada. Um, shouldn't an Ada class have been a pre-requisite?
I have had similar experiences with programming. It's like a big, impenetrable brick wall to me, which I attribute in part to an instructor I had who decided that everyone -- in a beginner Visual Basic class, no less -- needed to have PhDs in computer science in order to participate properly. He set up the home work accordingly, which made following the class almost impossible for all but the most advanced students (by the end of the semester, there were only three students who hadn't dropped: myself, an acquaintance who subsequently moved out of state, and an expert whose parents were both expert programmers working full time at some software company). The fact that he threw out the text book and refused to follow it didn't help.

If all that weren't bad enough, as a mandatory final assignment, I had to write a fully functional Chess program -- in Visual Basic! -- with virtually no instruction or help. Needless to say, I learned to hate programming in Visual Basic because of that.

My first experience with C++ was no better.

A couple years prior to this disastrous VB experience, I registered for a C++ class, and I was told right up front that, unless I can display originality, which I took to mean a thorough enough understanding to be able to do so, I would only get a B in the class. I dropped after one week.

Much more recently, I took a class in Java, and it wasn't too bad. I actually kind of liked it.

The next class in the series (I needed this one in addition to the Java class in order to graduate), of course, was C++ again. This experience was marginally better, in that at least I managed to muddle through and complete it with a passing grade. It did, however, get me an F in the companion lab class I never had time to work on. I'm still quite unhappy about that.

To this day, I think of trying to program something in a language that isn't HTML/XML, CSS or AppleScript and I freeze with a vague sense of panic. I suspect there's some PTSD going on, which I'll have to overcome someday.

c
 

trag

Well-known member
My first experience with C++ was no better.

In 1991/92 I took a couple of classes in C at the local community college. That was great. But it was also taught by a professional programmer from the local Lockheed office, not an academic. It also helped that I could do my assignments in Think C on my Mac. No threatening environment to configure there.

As with most such things, I'm sure our fears are bigger than the actual difficulties.
 

dougg3

Well-known member
My impression is that the microcontroller sized ARM chips are significantly better documented than the "computer" SoCs, but I may be wrong there. I don't write code for modern ARM, so this is second-hand information. :)

Yep! I completely agree with this. The microcontroller ARM chips (in modern terms this would be the Cortex "M" series) are usually documented extremely well. The architecture itself is heavily documented of course, and then the user manual for the chip, at least what I've seen from ST, NXP, etc. is complete and describes all the registers of every integrated peripheral. On the other hand, you guys are absolutely right about the fancier "computer-like" ARM microprocessors where important peripherals like the GPUs are not documented at all, and the manufacturer just supplies a binary blob for interacting with it. Yeah, that stuff is definitely annoying and I completely understand why you would be hesitant about ARM stuff from that perspective.

I'm pretty sure I've seen datasheets for bi-directional latches. Or buffers of some kind. I might have a reel of them in the attic. More datasheet browsing. I remember a chip with fairly simple data pin arrangement, but a complex set of control pins with states something like: 1) load buffer from side A, 2) load from Side B, 3) output active on Side A and/or Side B, or tristated.

I'm not sure, but I think muxes can always be used in both directions. Set it up one way, and you're controlling the destination for your output. Set it up the same way, and you're controlling the source of your input -- Assuming the two sides are connected to I/O pins and not just I or O. Datasheet again.

That bidirectional latch behavior you're describing sounds perfect! I think you're right about muxes too.

I like the idea of setting up an address counter and then just pulsing it's control from the micro. It's more components... But this is mostly for fun. Are the addresses always used sequentially? A counter won't work, if the addresses need to be provided out of sequence.

If you have to do an unlock sequence, a counter probably isn't going to work. Part of the unlock sequence on the chips I've used (which is needed for each byte programmed) involves writing 0xAA to address 0x55555555, and then writing 0x55 to address 0xAAAAAAAA. (Obviously this address varies based on how many address pins there actually are, but you catch my drift). For example, here is the code in my SIMM programmer that writes data to the flash chips. On the non-Micron chips, you have to do an unlock sequence prior to writing each byte into the chip. The Micron chips have a shortcut that allows you to do a bunch of writes sequentially, but you still have to do the unlock sequence to get the whole process started.

I think for at least the first hack, I'll just use discreet components. In theory I can program CPLDs/FPGAs and wrangle VHDL and Verilog. As I was mentioning in another thread, that experience is almost 20 years old, and I have a block/avoidance -- some kind of mental issue with setting up development environments. Hand me an IDE all ready to go, and I'm happy. Tell me I must track one down and get it working, and I'm nearly paralyzed, for some reason. I can probably tackle it if I look at just the next step and don't worry about the bigger picture.

Makes sense! Whatever you are most comfortable with is the smartest way to go! You are obviously more comfortable with actual circuits than me too, which means you are well ahead of my knowledge level in regard to the electronics background needed for VHDL/Verilog stuff. :cool: I've actually come to enjoy getting dev environments set up, but what I've found is it's hard to please everybody -- everyone has their own preferences on how they want their IDE to work.

I'm going to blame it on the Systems Programming class in 1985 in which we were told all our work would be in Ada. Um, shouldn't an Ada class have been a pre-requisite?

Haha, wow...that's a pretty dirty trick for them to pull. I want to learn Ada or Rust someday. I've heard they're a lot better for writing more secure code.

To this day, I think of trying to program something in a language that isn't HTML/XML, CSS or AppleScript and I freeze with a vague sense of panic. I suspect there's some PTSD going on, which I'll have to overcome someday.

Sounds like it! Maybe start with something a bit more forgiving like Python to gradually work your way into it? My first exposure to computer programming was typing in Commodore VIC-20 programs (in BASIC) from the user manual. I made a typo, and the VIC-20 spit out the message: "SYNTAX ERROR". I was a kid at the time, and it gave me nightmares. I sometimes think that getting past the evil syntax error is part of what motivated me to become a programmer...
 

trag

Well-known member
If you have to do an unlock sequence, a counter probably isn't going to work.

I. Right you are!

I spent some time with the datasheet last night. Programming sequence is: 1) Add = 555, Data = AA; 2) Add = 2AA, Data = 55; 3) Add = 555, Data = A0; 4) Add = PA; Data = PD.

So a straight counter to the address pins wouldn't work. I could set up three sources to a 3:1 mux which funnels to the Address pins. One would be tied to 555, one tied to 2AA and the third would be that counter. That would still reduce the number of micro pins needed. The 555 and 2AA wouldn't increase the component count any, as those are just wires tied to Vcc or Gnd.

The micro would have two select pins to the MUX to control the address source, and one or two pins to the counter, one for Advance and maybe one for Reset.

II. I also spent some time with my PCB software open looking at my old module design. Turns out that Write Enable is grouped (U1, U3), (U2, U4) while Output Enable is grouped (U1, U2), (U3, U4). So I can get only one chip at a time to experience the proper programming sequence if I want. That would support the TL866II+ concept.

I'm a little worried about floating values, though. The adapter/programming board could tie all four WE/OE weakly high, but then that would consume a little more of the TL866II+'s already overworked drive strength for those two signals.

I could also just include some DIP switches on the programming board for tieing high. Not elegant, but it would work. Hmmm. I'll do that on the prototype. Then I can check whether the TL866II+ can still drive WE/OE even when they're tied high, and if it can't I can still enable/disable the tie selectively.

Another question for the TL866II+ programming concept, is whether the TL866II+ uses the Reset pin at all. It shouldn't need to. And on my module, Reset is tied High. But if it does some weird operations during programming where it wants the Reset pin, it's not going to get it.

Also, all four Chip Enables are connected together, so that's not so great, but I think OE and WE take care of it well enough.

III. In Apple's design, Write Enable goes to pins 37 and 117 on the DIMM module. That's good because I don't have to steal Vcc pins. It's bad because I don't know what Apple machines do with pins 37 and 117 on the logic board. I'll need to check that.

On my module, I currently have Write Enable tied to Vcc. I included a method where I could cut a trace for each Flash Chip, and install two resistors, and then the Write Enable pins will go to 37 and 117.

But if I do that, will WE still be held high? Only if the motherboard holds pins 37 and 117 high. It should, as that's Apple's pinout for the module, but I'm not sure. I'll need to check some motherboards or maybe just test it with a module wired for WE.

IIIb. So the Operations Truth Table shows that Reads happen when Output Enable is Low, and Write Enable is High.

But I wonder what does the chip do if Output Enable is Low and Write Enable is Low. That's not covered as a used state on any of the tables. Would Reads still work?
 

trag

Well-known member
I've been pretty impressed with Micron's datasheets too.

When I was reading the HY29F800 datasheet last night I was having a hard time relating the concepts of a Write Operation and the Programming Command.

Finally tracked down a Micron datasheet for their 29F800. They used almost the exact same words as the Hyundai sheet, but they arranged them just a little differently, or maybe added one extra short sentence, and suddenly it was all clear.

I love MIcron datasheets....

Also National Semiconductor.
 

dougg3

Well-known member
So a straight counter to the address pins wouldn't work. I could set up three sources to a 3:1 mux which funnels to the Address pins. One would be tied to 555, one tied to 2AA and the third would be that counter. That would still reduce the number of micro pins needed. The 555 and 2AA wouldn't increase the component count any, as those are just wires tied to Vcc or Gnd.

Ahh, that's a really good point! I guess that makes sense; there are only 2 special addresses. If you're erasing only a specific block in a flash chip you also might need to be able to jump to that block's start address, but that's probably not really an important feature to have for this.

II. I also spent some time with my PCB software open looking at my old module design. Turns out that Write Enable is grouped (U1, U3), (U2, U4) while Output Enable is grouped (U1, U2), (U3, U4). So I can get only one chip at a time to experience the proper programming sequence if I want. That would support the TL866II+ concept.

Interesting...that's a clever strategy to group them differently.

III. In Apple's design, Write Enable goes to pins 37 and 117 on the DIMM module. That's good because I don't have to steal Vcc pins. It's bad because I don't know what Apple machines do with pins 37 and 117 on the logic board. I'll need to check that.

I feel like if Apple tied them to anything other than VCC or a WE signal, that would be bad...I'm guessing it's VCC, unless they have some secret internal ROM DIMM programming mode. It will be interesting to hear what you discover!

But I wonder what does the chip do if Output Enable is Low and Write Enable is Low. That's not covered as a used state on any of the tables. Would Reads still work?

That's funny, I was actually asking myself that same question a couple of weeks ago! I've been updating my SIMM programmer's firmware so you can run it on PC as a simulation. It's completely pointless from a functionality standpoint, but it allows you to test things out without needing a physical programmer, and it's a fun way to show off the hardware abstraction layer in the code. As part of that I've been writing code for emulating flash chips, and that question came up while I was writing the emulation. I came to the same conclusion, it's not covered in any of the tables. I would consider it undefined behavior; even if it works for what you need on the chips you test with, it's probably not safe to rely on it being the same across different flash chips...my two cents anyway!
 

trag

Well-known member
I feel like if Apple tied them to anything other than VCC or a WE signal, that would be bad...I'm guessing it's VCC, unless they have some secret internal ROM DIMM programming mode. It will be interesting to hear what you discover!

I hope you're right. I need to clear a space where I can do the testing. I got going on soldering up the modules to get this project going again by using the hardware lab at work...

That's funny, I was actually asking myself that same question a couple of weeks ago!
Great minds thinking alike and all that.... I'm tempted to whip up a little PSOP-44 to DIP44 board, just so I can solder one chip down and easily test it with stuff.

Regarding those bidirectional latches we were discussing earlier. The official name is "registered transceiver" and the part number is 74xxx543, where xxx is whatever logic family they're in. So, for example, SN74F543 for TI's plain 5V version. Or PI74FCT543 for Pericoms fast 5V version. They support eight bits at a time.

The 16 bit version is 16543 instead of 543.

Useful little things. I only have 16 of the 5V 543 on hand. The thing I have 2000 of are bidirectional buffers (162245) but those don't have a storage element. I guess they might be good if I wanted to build 5V FPM DIMMs from scratch. I have about 1500 of Pericom's 74LPT16543 on hand, which would be great if I wanted to translate from 5V to 3.3V or just operate at 3.3V.

A couple of datasheets are attached.
 

Attachments

  • sn74f543.pdf
    782.7 KB · Views: 1
  • sn74lvt16543.pdf
    825.3 KB · Views: 1
Last edited:

Trash80toHP_Mini

NIGHT STALKER
If you're going to make an adapter, why not do a ROM DIMM layout for them? You've probably got plenty of height available in the case for it? I have room for a PCI card height board in my caseless PEx-in-a-Drawer setup.

I've seen plenty of SMT->DIP header adapters for prototyping and programmers available on eBay. Maybe they're available for your chips?

Using those basic, cheap as boards you could experiment to your heart's content with single chips or four up on the BigDIMM board in the machine.

Splaying your existing DIMM layout to create a BigDIMM should be duck soup? No wasted chips, the BigDIMM in my proposed Plexi picture frame case would be very cool indeed should you not wish to keep it on hand when all is said and done. ;)
 

trag

Well-known member
Well, part of what's driving the "adapter" idea is to actually build a mechanism that will let me directly read any ROM DIMM for these three and a half (plus ANS) generations of Macs.

Programming them in place is a nice to have, but, e.g., if we find that there's still some issue with converting PEx dumps into DIMM chips, I'd like a little board, where someone could just plug in a standard Apple DIMM and read out the contents ready to program into four chips.

That way, if we can't get someone to loan us their ROM, we might be able to convince them to let us send them a DIMM/chip reader device.

Also, would allow me to read that 9150 ROM module in the bag in my closet, without dragging a 9150 out of the attic.

But yours is a good point. It would be worth checking the clearances available in various machines. Most of the ROM DIMMs are close enough to the CPU card, that they have several inches of height clearance.

That wouldn't be true though in the Beige G3, e.g. and certainly not in the PM6100.

Your idea would also allow one to do away with the need for a DIMM style socket for every programmer.

Remember this form factor is used in the NuBus Powermacs, X500, X600, Beige G3, PEx, and ANS.

However, I may split off the design for the Beige G3.

The Beige uses 3.3V instead of 5V, and making the DIMM module dual voltage means I must install 15 extra SM resistors on every module to choose the voltage. Also takes up a substantial amount of board space near the base.

@Trash80toHP_Mini jt, PM sent. I mention it here, because you suggested once that you weren't getting PM notifications.
 

bigmessowires

Well-known member
IIIb. So the Operations Truth Table shows that Reads happen when Output Enable is Low, and Write Enable is High.

But I wonder what does the chip do if Output Enable is Low and Write Enable is Low. That's not covered as a used state on any of the tables. Would Reads still work?

You're using HY29F800? It seems similar to other 5V Flash ROMs like the SST39SF, and the datasheet for that chip says more about what happens if /OE and /WE are both asserted. "Write Inhibit Mode: Forcing OE# low, CE# high, or WE# high will inhibit the Write operation. This prevents inadvertent writes during power-up or power-down." Later it says that when /OE is asserted (regardless of the other control pins) the DQ pins will be High Z/ DOUT.

I would interpret all this as meaning with /OE and /WE both asserted it definitely won't write anything, and you probably won't be able to read anything either.
 
Top