Jump to content
dougg3

Another IIci ROM hack

Recommended Posts

Note that in Dennis's diagram, the address lines from top to bottom are 24, 26, 25, 27, 28, 29...

 

The swapping of 25 and 26 is kind of critical to making the circuit work.

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.

Share this post


Link to post
Share on other sites
Speaking of which: DQ, you wouldn't have any reject programmer boards on hand would you? I don't need a functional board for the feasibility study, just the patchable thru-holes/connections between the header pads and SIMM connectors.

 

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

 

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. [}:)]]'>

 

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!

Share this post


Link to post
Share on other sites

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):

testcard.jpg.cc95da15250d79e4fdb606c552c59c22.jpg

 

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.

Share this post


Link to post
Share on other sites
If you need any of the above, just let me know and I will be happy to send them your way!

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. [:o)]]'>

 

p.37 and we're just getting started here gang!

Share this post


Link to post
Share on other sites
However, everything else (including /OE) seems to be correct, and not getting anywhere.

 

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.

 

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. [:o)]]'>

 

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.

Edited by Guest

Share this post


Link to post
Share on other sites

S'all right! [:o)]]'>

 

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Did you try reversing polarity of the shields, or running an inverse tachyon beam?

 

:lol:

 

Thanks. I ordered 74125's and maybe that'll help. Unfortunately, monday seems to be a holiday, so probably no progress for a while.

 

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

Share this post


Link to post
Share on other sites

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.

 

5a1d03faeb718_AdapterTest_02.jpg.ca1267286043f3a3eb72e2fa0313dc60.jpg

Share this post


Link to post
Share on other sites
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...:-)

 

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

 

Life is strange.

 

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? :-)

Share this post


Link to post
Share on other sites
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...:-)

Note that using a single transistor will invert the signal.

 

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
Here's an article about modding the ROM SIMM's sockets for installation: Installing a PLCC EEPROM Socket onto a MOBO

 

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

 

Does this sound doable in the SIMM Slot of your programmer, DQ?

 

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

Share this post


Link to post
Share on other sites

A PDS card would be nice so it can support other Macintosh machines too.

 

The cool thing about this development board is that the FPGA code to support the DDR2 chip and Flash, and VGA port and 10/100 ethernet is already written. All that's really needed is to interface those components with the Macintosh bus.

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.

 

A 100 MHz processor has a clock cycle every 10 nanoseconds. So if a 100 MHz processor is monitoring the address bus, basically that leaves us around 25 clock cycles for the microcontroller program to do something before it has to be ready for the next ROM read cycle.

The IIfx apparently has a ROM access rate of 64 MB/sec (equivalently, a real read speed of 16 MB/sec). At 16 MB/sec, there's a read every 62.5 nanoseconds. The 8 MB chips are still fast enough...in fact, the older 2 MB SIMM chips might be breaking timing guidelines on the IIfx if my math is correct because I think the other chips I'm using have a minimum access time of 70 nanoseconds. This example is actually making me doubt my math -- anyone want to double check to make sure I'm not full of crap? Anyway, at 62.5 nanoseconds, a 100 MHz processor will only have 6 cycles available between ROM accesses.

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.

Share this post


Link to post
Share on other sites
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.

 

I wasn't analyzing how fast of an FPGA it would need (I'm actually clueless on that front). I was analyzing why a microcontroller would be a bad idea and an FPGA would probably be required. The FPGA will have an easier time catching the hardware signals on the bus saying "a write happened" or "a read was requested". A microcontroller running at the high clock rate of 100 MHz would still be pretty stressed at high data rates just handling the accesses and decoding the addresses, while an FPGA should be perfectly capable of handling it -- that's what my big write-up was about.

 

Is it possible that the microcontroller can handle it? Maybe -- definitely not in the ROM SIMM slot because there's no mechanism for the card to slow down read accesses to it, but it might work in a PDS slot where the PDS card has to acknowledge that a read has completed as I'm seeing with bbraun's latest hardware work. But with the idea of a ROM SIMM card with a microcontroller in it, I'm just saying that a microcontroller is a bad idea and an FPGA is the way to go.

Share this post


Link to post
Share on other sites
That article describes *exactly* what I do to the PLCC sockets on the 2 MB SIMM :-)

LOL! I thought you'd get a kick out of that one. [;)]]'> I figured it was a good reference for this monster thread.

 

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

1) this is where you've lost me, I've never had to spec ICs and I've never shopped for any I couldn't get at CrapShack.

2) I'm only familiar with the ROM packages for the systems I mentioned, suggestions for any others ought to be made now.

 

IOW . . . HELP!!!!! 8-o can someone (besides DQ, we're making this a community development project after all) do the research on any different ROM packages that it would be good to add to this board? Checking parts availability per DQ's spec for the ones mentioned above, I've never determined the IC package type for the DuoDock+ ROM. I've had the spec for the MiniDock/DuoDock ROM on hand for a few years.

 

< . . . slurps down the beginnings of second cup of coffee, bops wetware reset button. :scrambled: >

 

I may be overdoing/under-over-thinking this . . .

 

The first thing I'm going to add to the PCB will be the pins for the DIP socket equivalent of the expansion headers on DQ's programmer. Standard form factor (not pinout) adapter modules can be user fabbed for additional ROM types as needed.

 

I still want to do socket pads for a basic set of Mac ROM packages . . . so . . . help!!!!! :I

Share this post


Link to post
Share on other sites
The first thing I'm going to add to the PCB will be the pins for the DIP socket equivalent of the expansion headers on DQ's programmer

 

AFAIK, 29F040 (what I'm using) is the DIP equivalent.

Share this post


Link to post
Share on other sites

Pictures work better for me than .TXT, so:

 

In order to add pads to the extender board to create a ROM SIMM adapter when the extender is plugged in B@$$@ckw@rd$. These are the packages I've babbled about above. The old 28 pin EPROM socket's not a problem, I may even have one or two ZIF Sockets stashed away somewhere. All the early DeclROMs for NuBus Cards and a few peripherals used this DIP Package

 

Duo MiniDock DeclROM _________________________________________

minidockdeclromfront.jpg.3bf91f5f7c849ba074fa5261d8eb7193.jpg

This appears to be a lower profile SMT socket = too hard to work with . . . :p

 

 

MiniDock DeclROM thru-hole socket _____________________________

 

minidockdeclromprotosoc.jpg.2af793c12390ed7d116b76772c85a23c.jpg

This is what I'm looking for, if not its ZIF equivalent. I don't need the machine pin extended wire wrap adapted version, the socket pictured is a standard thru hole socket mounted to an adapter PCB. This is the wire wrap equivalent of the "Machine Pin Hack" I've been proposing in the SuperIIsi thread.

 

 

DuoDock DeclROM______________________________________________

 

duodockdeclrompowerhack.jpg.7de023498d9827f49d922010fb0dc4de.jpg

 

 

DuoDock+ DeclROM_____________________________________________

 

ddiideclromtopzif.jpg.4d5ec16a37497d0c4c3ba88570e81672.jpg

Now that I'm looking at it again, is this a ZIF socket for the same SMT package in the DuoDock DeclROM pic above?

 

My eyes stopped working after counting the socket connections on an Apple Video Card24AC to compare them with the MiniDock DeclROM . . .

. . . yep, they're the same package! [:D]]'>

Share this post


Link to post
Share on other sites

http://www.jameco.com/Jameco/Products/ProdDS/104012.pdf

 

Thanks, Sancho! That's one more, but I'll still put the big'ole .01" DIP socket (a pair of 32s I have in stock) on the board in constricted, alternating pin for pin series with the SIMM expansion headers customizing. That'll make for easier fcustomization of adapter-adapters as well. :approve:

 

I'll need to have the pinout conversion from your EEPROM to the Programmer's expansion headers for the necessary switcharoonies.

 

The same is true for the rest of the pinout conversions, my brain doesn't work that way, this is a graphic art project for me, I've always had a hardware/software guy feed me the pinouts and my noggin converts that into postscript paths in illustrator. Matter of fact, I'm toying with the notion of having a buddy of mine who's still in the sign business up in NYC do the board's edge connector thicknessing, "etching" and drilling for me on one of his engraving machines. [}:)]]'>

 

p.s. I counted pins in the pics above and it looks to me like the 'Dock & the 'Dock+ use the same ROM package: now for sourcing that ZIF socket to retrofit my DuoDock MLB and, preferably, in thru hole as well for the extender/adapter.

Share this post


Link to post
Share on other sites

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.

 

Because the FPGA of today is the VLSI of back then. its glue logic, all it is. And its programmable while VLSI was masked. Nearly every PDS/nubus card you see or has been made has PAL/GAL or some form of VLSI on it. THIS IS WHY...

 

So you replace PAL/GAL/VLSI with an FPGA. and you can take over all the roles with the single IC as things are much more highly integrated today than they were back then.

 

and 100mhz means thats the speed the logic is capable of running at.

 

sure you can do everything in discrete glue logic, if you want 30 ICs on your card.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×