-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
Another IIci ROM hack
- Thread starter dougg3
- Start date
Dennis Nedry
Well-known member
Yes I should have mentioned that - it would be very easy to not notice. I did it that way to avoid crossing wires in the diagram.
I don't have any spare programmer boards...fortunately all 10 of my original programmer PCBs were successes!
I'm completely out of programmers right now aside from my test unit. I have 50 programmer PCBs on order from Seeed Studio, but it's a Chinese holiday and they're closed this whole week. No idea when the PCBs will arrive...That actually is doable -- I have a ton of 64-pin SIMM sockets (thanks to olePigeon) and a ton of bare 2 MB SIMM PCBs (I ordered 100 of them, and I'm figuring most people are going to want the 8 MB version in the future, so I probably have a bunch of mostly useless 2 MB bare PCBs...) If you need any of the above, just let me know and I will be happy to send them your way!Heh, come to think of it, just a bare reject SIMM Board and SIMM Connector would be good enough for an indescribably fugly, minimalist, but workable test cable. [}
Thanks for all the pointers. dougg3, thanks for pointing out my /CE error, I did have that backwards. However, everything else (including /OE) seems to be correct, and not getting anywhere.
So, I made a test card that plugs into this card, where I can test different addresses to make sure my decoding works (it seems to):
I have DQ0-7 of the flash going to D24-31 on the PDS card. I had A1-A18 from the PDS going to the flash, but I'm suspecting that's incorrect. D24-31 is bytelane 0, which would be addressed at 0xFAFFFFFC. With A1-A18 going to the same lines on the flash, that wouldn't be the same thing. So I moved all the address lines over 2, so A3-21 go to flash, and A1 & 2 are not connected. But that doesn't seem to affect anything either.
So, I made a test card that plugs into this card, where I can test different addresses to make sure my decoding works (it seems to):
I have DQ0-7 of the flash going to D24-31 on the PDS card. I had A1-A18 from the PDS going to the flash, but I'm suspecting that's incorrect. D24-31 is bytelane 0, which would be addressed at 0xFAFFFFFC. With A1-A18 going to the same lines on the flash, that wouldn't be the same thing. So I moved all the address lines over 2, so A3-21 go to flash, and A1 & 2 are not connected. But that doesn't seem to affect anything either.
Trash80toHP_Mini
NIGHT STALKER
That'd be great, I've simplified my requirements to just two ATA-133 Cables and matching double-header rows for the interface. By avoiding the cable ground lines on pins 2,19, 26, 30 and 40 on both cables, everything turns up roses. The interleaving 40 shielding lines of each cable's 80 lines are tied to those 5 ground connections on the cable.
Doing it this way yields 80 alternating ground lines connected to the 10 traditional ATA connections scattered about . . .
. . . yielding 70 discrete lines for the interface using two cheap cables. :approve:
You've got my address, DQ, if you send me two blank boards and two connectors for them, I'll build two bus extenders and send one back to you for reliability testing. Send three of each and I'll forward one to Sancho Panza. [
)] ]'>p.37 and we're just getting started here gang!
Just a thought to maybe add some simplicity to it all...what about wiring the address pins of the flash chip all to ground, so you don't have to worry about the flash address pin part of the circuitry yet? That would just repeat the first byte stored in the flash chip throughout the first byte of each word of assigned address space. I guess either way it should be working though--you'd be getting *some* byte from the chip, so maybe that's not really necessary to change...
I'm looking at the reference for the 030 PDS in GttMFH. Is there more complicated circuitry required to put something onto the bus? I notice there are a bunch of extra lines available in the PDS such as /DSACK (indicates completion of a data transfer operation), R/W (indicates whether an access is a read or write), and /DS (data strobe). Do you maybe have to decode some of those or perhaps provide an output on one of them to indicate you have successfully put data onto the bus? I'm just trying to think of what might cause it to not work. I know pretty much nothing about the PDS, this is just an idea...
I'm just wondering if maybe the Mac's address decoding logic is doing some extra control line twiddling in between the SIMM socket and the processor pins...I guess the real answer to that question would be in the 68030 manual.
OK, I will try to do that soon! Probably won't be able to get stuff out until next week. Might as well do three...so you will need three blank SIMM boards and three 64-pin SIMM sockets? Just want to make sure I get everything right.You've got my address, DQ, if you send me two blank boards and two connectors for them, I'll build two bus extenders and send one back to you for reliability testing. Send three of each and I'll forward one to Sancho Panza. [
Last edited by a moderator:
Trash80toHP_Mini
NIGHT STALKER
S'all right! [)] ]'>
It's too bad nobody ever made a NuBus or PDS version of the ISA ProtoTyping boards they had at JDR back in the day. You could get them with or without the standard bus interface all laid out and ready to populate. I guess that's sort of what you're developing here
Hey, Sancho! Are you doing a IIci Cache Card test or a dead stock SE/30/IIsi 68030 PDS interface for your feasibility study?
That IIci Cache Slot is hinky.
)] ]'>It's too bad nobody ever made a NuBus or PDS version of the ISA ProtoTyping boards they had at JDR back in the day. You could get them with or without the standard bus interface all laid out and ready to populate. I guess that's sort of what you're developing here
Hey, Sancho! Are you doing a IIci Cache Card test or a dead stock SE/30/IIsi 68030 PDS interface for your feasibility study?
That IIci Cache Slot is hinky.
The problem, I suspect, is I need to generate a /DSACK0-1 signal when the data is on the bus. Tying /DSACK0-1 to /OE -> not bootable. /DSACK0-1 to OE -> not bootable. Am I supposed to somehow tristate these? Not that I'd know how to do that.
DSACK being acknowledge of the /DS data strobe, and using the two signals determines the size of the bus (I want 32bits, so need both).
As for what slot I'm doing, I'm using the bare minimum of the 030 PDS. I haven't compared to the IIci cache slot, but so far it's using a common subset of signals between SE/30, IIsi, and IIfx. I would guess it'd work on IIci too, which is to say it would not-work the same way on all of the above machine.
My test system at the moment is IIsi.
DSACK being acknowledge of the /DS data strobe, and using the two signals determines the size of the bus (I want 32bits, so need both).
As for what slot I'm doing, I'm using the bare minimum of the 030 PDS. I haven't compared to the IIci cache slot, but so far it's using a common subset of signals between SE/30, IIsi, and IIfx. I would guess it'd work on IIci too, which is to say it would not-work the same way on all of the above machine.
My test system at the moment is IIsi.
Trash80toHP_Mini
NIGHT STALKER
Great choice, pure vanilla slot, open top and lots of room to play inside the box. :approve:
Just my thoughts, could be wrong:
Since multiple things are all going to be hooked up to the /DSACK pins (so that each "thing" has the capability to acknowledge a data request when it is being addressed), you're probably right. I'm guessing the /DSACK pins each have a pull-up resistor on them, and all the outputs connected to them are supposed to be open drain (meaning when they want to drive it low, they drive it low, but when they are not asserting it, they tristate it, allowing the pull-up resistor to pull it up). It's the same scheme that, for example, allows a bunch of different I2C devices to be connected to the same I2C bus--it avoids the contention that would occur if one device tried to drive it high when another device at the same time tried to drive it low.
So by pulling it down or up completely, you might be messing with the signaling that the rest of the system uses. I *think* what you're looking for is called a tri-state buffer. Basically when your ROM is active I think you want it to go low, but when your ROM is not active you want to leave it floating. I don't know if DSACK is supposed to go low with a delay to allow the chip to put its data on the bus first though...
But anyway, with the tri-state buffer (assuming no delays are needed), I think you'd connect the input side to ground, the output side to each DSACK pin (assuming you want to drive both of them down to 0, which I think you do), and the control line to OE or /OE, whichever is correct. So that way the DSACK pins would be driven low when OE is asserted, but left tristated when OE is deasserted.
P.S. I'm not a hardware engineer so if I've butchered terms like open drain, forgive me! I just know that's basically what they do...
Edit: This link might be useful--kind of has an overview of how someone made a card for the LC PDS slot. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.194.9943&rep=rep1&type=pdf
Since multiple things are all going to be hooked up to the /DSACK pins (so that each "thing" has the capability to acknowledge a data request when it is being addressed), you're probably right. I'm guessing the /DSACK pins each have a pull-up resistor on them, and all the outputs connected to them are supposed to be open drain (meaning when they want to drive it low, they drive it low, but when they are not asserting it, they tristate it, allowing the pull-up resistor to pull it up). It's the same scheme that, for example, allows a bunch of different I2C devices to be connected to the same I2C bus--it avoids the contention that would occur if one device tried to drive it high when another device at the same time tried to drive it low.
So by pulling it down or up completely, you might be messing with the signaling that the rest of the system uses. I *think* what you're looking for is called a tri-state buffer. Basically when your ROM is active I think you want it to go low, but when your ROM is not active you want to leave it floating. I don't know if DSACK is supposed to go low with a delay to allow the chip to put its data on the bus first though...
But anyway, with the tri-state buffer (assuming no delays are needed), I think you'd connect the input side to ground, the output side to each DSACK pin (assuming you want to drive both of them down to 0, which I think you do), and the control line to OE or /OE, whichever is correct. So that way the DSACK pins would be driven low when OE is asserted, but left tristated when OE is deasserted.
P.S. I'm not a hardware engineer so if I've butchered terms like open drain, forgive me! I just know that's basically what they do...
Edit: This link might be useful--kind of has an overview of how someone made a card for the LC PDS slot. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.194.9943&rep=rep1&type=pdf
:lol:
Ah, rats. If you happen to have a transistor that might work too...see the diagram of the open collector output on Wikipedia. Someone like Dennis Nedry or techknight should probably make sure I'm not completely full of it too...
Trash80toHP_Mini
NIGHT STALKER
8-o Great idea, oP, but the tachyon beam isn't introduced until next season. [] ]'>
Great link, I tried to get through the abstract while the coffee machine was running, I had to htt the reset button (my nose) to uncross my eyes. Skipped to the conclusion after half a cup of coffee and got a big kick out of it.
It's a bit ironic that the PDS lamed low end pro Macs and consumer level PDS Macs appear to be more easily ramped up by application of today's tech than the Pro Level NuBus Macs.
Had the Mac II dirty ROM fiasco never happened, you'd likely not have the crack available for wedging your ROM SIMM hackery into so many machines, DQ. Few would be game for desoldering/socketing their MoBo ROMs the way you got started.
Life is strange.
] ]'>Great link, I tried to get through the abstract while the coffee machine was running, I had to htt the reset button (my nose) to uncross my eyes. Skipped to the conclusion after half a cup of coffee and got a big kick out of it.
It's a bit ironic that the PDS lamed low end pro Macs and consumer level PDS Macs appear to be more easily ramped up by application of today's tech than the Pro Level NuBus Macs.
Had the Mac II dirty ROM fiasco never happened, you'd likely not have the crack available for wedging your ROM SIMM hackery into so many machines, DQ. Few would be game for desoldering/socketing their MoBo ROMs the way you got started.
Life is strange.
techknight
Well-known member
the posted PDF does help, but if you look at the actual 68030 datasheet/processor doc, the entire bus cycle is listed, and its timing diagrams.
My electrical/computer engineer coworker informs me that a P-channel MOSFET could convert the generated /OE signal into an open drain output, but the tri-state buffer should work too. Either way, you'll need to use two of them so you don't connect the two /DSACK pins together (I was envisioning only needing one tri-state buffer in my head that controlled both pins, but he corrected me on that and it makes sense now...)Ah, rats. If you happen to have a transistor that might work too...see the diagram of the open collector output on Wikipedia. Someone like Dennis Nedry or techknight should probably make sure I'm not completely full of it too...
You can say that again! And you're absolutely right...if the dirty ROM thing had never happened, who knows what weird project I would be spending my time on instead?
Dennis Nedry
Well-known member
Note that using a single transistor will invert the signal.Ah, rats. If you happen to have a transistor that might work too...see the diagram of the open collector output on Wikipedia. Someone like Dennis Nedry or techknight should probably make sure I'm not completely full of it too...
With N-Channel:
input -> output
0 -> high-impedance (open circuit)
1 -> 0
With P-Channel:
0 -> 1
1 -> high-impedance
To achieve all 3 states, you would need 2 separate signals whether you use transistors or a tri-state chip. Connecting the outputs of an N and P together:
n, p -> output
0, 0 -> 1
0, 1 -> high impedance
1, 0 -> 'BANG' + magic smoke
1, 1 -> 0
Trash80toHP_Mini
NIGHT STALKER
Just as a aside on the ROM SIMM Programmer front:
Here's an article about modding the ROM SIMM's sockets for installation: Installing a PLCC EEPROM Socket onto a MOBO
I've been looking more and more into fabbing a few PCBs in house for the extender project . . . it's already growing in scope and size. 8-o
I figured that I'm roughing out the connections between the two halves of the extender as if they were one long extender in and of themselves. It occurred to me at work this evening that I should add pads for a few accessories while I'm at it. A 28 Pin ZIF Socket to handle the Quartz Windowed DIP EPROMs common on NuBus and PDS Cards, the PLCC sockets for the EEPROMs on my Radius Cards, the DuoDock, Duo MiniDock and the whatchamahoozit socket for the ZIF mounted EEPROM in the DuoDock+ just for schiznits-n-giggles.
Basically, I'd like to be able to install the ROM SIMM end of this contraption into the SIMM Programmer's Slot and install one of the above (E)EPROMs into the appropriate socket to read and copy to disk for hacking and/or just writing it to another ROM. Getting the DuoMiniDock DeclROM repackaged and into the DuoDocks has been a long term goal of mine. [}] ]'>
Does this sound doable in the SIMM Slot of your programmer, DQ?
@ trag - ISTR you saying that the FRP Copper Clad from the likes of CrapShack was too thick for your IIfx RAM SIMMs and that gamba had to file them down to get them to fit. I was thinking about running a linearly ganged set of blanks across my router table to remove that excess thickness before etching. I'm assuming that this should be done across the component side, just far enough back so as to clear the slot? Should it be done to the back side instead? Do you recall the thickness differential?
Here's an article about modding the ROM SIMM's sockets for installation: Installing a PLCC EEPROM Socket onto a MOBO
I've been looking more and more into fabbing a few PCBs in house for the extender project . . . it's already growing in scope and size. 8-o
I figured that I'm roughing out the connections between the two halves of the extender as if they were one long extender in and of themselves. It occurred to me at work this evening that I should add pads for a few accessories while I'm at it. A 28 Pin ZIF Socket to handle the Quartz Windowed DIP EPROMs common on NuBus and PDS Cards, the PLCC sockets for the EEPROMs on my Radius Cards, the DuoDock, Duo MiniDock and the whatchamahoozit socket for the ZIF mounted EEPROM in the DuoDock+ just for schiznits-n-giggles.
Basically, I'd like to be able to install the ROM SIMM end of this contraption into the SIMM Programmer's Slot and install one of the above (E)EPROMs into the appropriate socket to read and copy to disk for hacking and/or just writing it to another ROM. Getting the DuoMiniDock DeclROM repackaged and into the DuoDocks has been a long term goal of mine. [}
] ]'>Does this sound doable in the SIMM Slot of your programmer, DQ?
@ trag - ISTR you saying that the FRP Copper Clad from the likes of CrapShack was too thick for your IIfx RAM SIMMs and that gamba had to file them down to get them to fit. I was thinking about running a linearly ganged set of blanks across my router table to remove that excess thickness before etching. I'm assuming that this should be done across the component side, just far enough back so as to clear the slot? Should it be done to the back side instead? Do you recall the thickness differential?
That article describes *exactly* what I do to the PLCC sockets on the 2 MB SIMM
I did experiment briefly with solder paste and leaving the bottom of the socket intact, but that didn't end up working out. I suppose in a toaster oven it would have worked, but I haven't played extensively with the toaster oven soldering yet. I did get a thermocouple to monitor temperatures and tried unsuccessfully to reflow an iMac MXM graphics card from a 2008 Aluminum iMac, so I have the tools, but toaster oven soldering is something for the future...If you wire the sockets up to one of the four available bytes (D0-D7, D8-D15, D16-D23, or D24-D31) it should work just fine. It will need firmware and software support, but I can definitely make it work. If at all possible, please use D16-23 or D24-31 -- those two bytes are connected directly to the SIMM programmer's AVR, which would bypass the need for the (relatively) slow SPI communication to the GPIO expander chip (which is in control of D0-D7 and D8-D15). In other words, I could flash the chip MUCH faster than I can now if you use D16-23 or D24-31. Wire the address pins of the sockets starting at A2, just like I have done on my SIMM -- A0 and A1 which are on SIMM pins 2 and 3 are unused, and the chip's A0 connects to the SIMM A2, and so on. If you do that, it should definitely work with some simple changes to the firmware and software.
You have to use single-supply EEPROMs/flash chips -- it won't work with chips that need a high programming voltage. It has to be a chip that only needs a single 5V supply, like the Am29F040 or the SST39SF040 (and their smaller brethren). Hopefully this doesn't limit the options too much...
LOOM
Well-known member
A PDS card would be nice so it can support other Macintosh machines too.
Regarding to the USB (mass storage) port(s) in the back; OSX can't write to MFS volumes any more, so you had to build in filesystem support. I'm not sure if that's a bigger project than what we anticipated.
Adding a VGA (with normal, up to date resolutions) would be amazing!
Regarding to the USB (mass storage) port(s) in the back; OSX can't write to MFS volumes any more, so you had to build in filesystem support. I'm not sure if that's a bigger project than what we anticipated.
The Iici (and the other computers) have a 25mHz bus and a MC68030 CPU. Why can they read perfectly fine to/from ROM/RAM/CPU/HDD, but we need a 100 MHz FPGA to do the same? I've never seen a 3rd party add-on card that needs a FPGA with a MHz ratio of 4:1 to the host computer to work before(??). I'm not sure if I understand this.
Similar threads
