Jump to content

Another IIci ROM hack


Recommended Posts

BTW, while adding the "verify while write" functionality, I learned a thing or two about port pins. If I didn't have a SIMM plugged in at all, it was passing the verification test. It turns out if you write a value to a pin, then read the pin back really fast (and nothing else writes to the pin in the meantime), it tends to stay at the same value you wrote to it. It's really undefined because nothing is driving the pin, but it tends to stay where you left it. So to remedy it, right before verifying, I write the opposite (NOT'ed) data to the data pins. This makes sure if the data is really valid, it will overwrite the opposite data that I left on it last. Weird, but understandable.

I just pulled out the datasheet for the Atmel AT90USB647:

 

If PORTxn is written logic one when the pin is configured as an input pin, the pull-up resistor is activated.

So the port values in fact affect the pull-up resistors when in the input direction. I would recommend writing all 1s to the ports to activate the pull-ups when reading. This should return all 1s whenever polling the ports with no SIMM inserted. Then just use the PINx registers to read the input values. This differs from other microcontrollers - I am used to using the PORTx registers for both reading and writing data.

Link to post
Share on other sites
  • Replies 1k
  • Created
  • Last Reply

Top Posters In This Topic

Thanks for the suggestion Dennis Nedry! I'm well aware of the pull-ups and their register layout and everything. I actually tried turning the pull-ups on at first, but it only fixed the problem on the 16 pins that are controlled through my GPIO expander chip--the 16 pins controlled by the AVR still had problems. I figured the AVR pull-ups just weren't responding fast enough and moved on to my other technique. (I now realize I was wrong...)

 

When you reminded me that the PORT bits are what control the pull-ups (I knew that but I made my own library routines that do it for me so I wasn't thinking about the register layout at all), you jogged my memory. The reason it worked on the GPIO expander was because it has a separate pull-up enable register. I was only configuring the pull-ups at the start of the program, so the AVR's pull-ups were getting changed around every time I wrote data to the chips (but the GPIO expander's pull-ups were being left alone -- that's why it worked on them). I just changed the code to disable the weird inverted write, and instead ensure all pull-ups are enabled on every read cycle, and now it works fine. :-) This also has the effect of making the chip ID sequence return 0xFF when a chip is not present (instead of 0x90, which is the last byte I write to the chips to initiate the identification sequence). I was wondering why it was doing that, but it never bothered me enough to think about it).

 

It all makes sense now! And I feel foolish. :-) In my next firmware release I'll probably use the technique you listed instead, so everything will have a defined value of all 1s as you mentioned. Thanks again!

Link to post
Share on other sites
I thought a Microcontroller with enough I/O to do a parallel interface to same in the FDD bay was the obvious jumpoff point in terms of NOT having anything hanging outside the case with the added ability to pop storage media in-n-out of the case from the most readily available of access points.

I see now... I thought you meant some external box like an ExpanSE (sp?) the Nubus expansion chassis, though I wouldn't mind having that dangling off the machine if it worked with normal cards. It sounds like the ROM transfer rate wouldn't be too much faster than SCSI, so one option available now is to mount an Artmix CF/SCSI board in the FDD bay and stick A CF card through the floppy slot.

Link to post
Share on other sites

Everyone loves to argue about benchmarks. CF speed benchmarks seems to be one of this forum's favorite things to argue about. But, we may as well argue over actual data instead of theoreticals, right? :)

 

Over lunch I wrote this set of tests. I am by no means a qualified benchmark writer, but I'll give it a go anyway.

The 3 tests involve copying data, in 256KB chunks read a long word at a time, into RAM, then flushing the data cache, and doing it again in a loop 1000 times. The 3 tests are doing this from RAM to RAM, ROM to RAM, and Slot to RAM. The slot test is using the slot manager to find a card then directly read the last 256KB from the card's standard address space, which is where the declrom lives. It just takes the first non-zero slot it finds.

 

Sources are included, so feel free to inspect what is going on, make changes, etc.

 

I ran it on a 660av with a nubus adapter populated with a video card, and a IIx with a nubus video card. Both video cards were being used as the active head for the machine.

660av:
Starting RAM test
RAM test copied 250 MB in 26 seconds
Starting ROM test
ROM test copied 250 MB in 27 seconds
Testing Slot: e
Address: fe000000
Address: fefbffff
Slot test copied 250 MB in 324 seconds

IIx:
Starting RAM test
RAM test copied 250 MB in 48 seconds
Starting ROM test
ROM test copied 250 MB in 48 seconds
Testing Slot: 9
Address: f9000000
Address: f9fbffff
Slot test copied 250 MB in 143 seconds

 

If the test is run for longer (there's an ITERATIONS macro at the top of the source file), the gap between ROM and RAM speeds becomes more noticeable.

 

And just to throw more ideas into this pot, thinking about tt's idea for custom SIMMs, I'd be interesting to see if we can still address something in the SIMM slot, even if the memory controller has not recognized it as RAM. I'm thinking of the Sun SS20, which takes nonvolatile storage for disks, and a framebuffer in its DIMM slots.

Link to post
Share on other sites

Oh, one other thing about the ROM accesses. Only the first 1MB of ROM is mapped into 24bit address space, so anything beyond that will need to be 32bit accesses. Which means an addressing mode swap before and after accesses. So the above is kind of a best case on ROM access times.

Link to post
Share on other sites

Well, I played with the RAM thing a bit on a IIx.

Out of the box, the mac plays the bad chimes if you have an invalid memory configuration (one simm in a bank of 4, in the IIx). So, I patched out the check. Then, the MMU setup is only mapping in the RAM that was detected, and setting up a memory hole and then mirroring the RAM all the way up to 0x40000000. The single simm wasn't included in the detected RAM (this is good, we don't want it added to available memory), so wasn't included in what was mapped in. I was able to patch in a hard coded chunk, but it seems the GLU decoder is generating a bus error when trying to access that range.

So, I didn't have much luck with abusing the RAM slots.

 

I used the new SIMM Programmer for this with the 8MB SIMM, and the verify while writing is very cool. Thanks dougg3!

Link to post
Share on other sites
  • 68kMLA Supporter

Re: Microcontroller vs. FPGA

I think that an FPGA will just work better in every way. The only disadvantage of using an FPGA is that folks who are likely to help also probably have more experience with microcontrollers. Oh, and microcontroller development systems are (usually) less expensive, but that's a one-off purchase for anyone developing. Doug's analysis of data rates is salient. It is difficult to have a microcontroller keep up with the I/O and still do other useful work, especially at the speeds typically available.

 

An FPGA can have several blocks all operating simultaneously, accomplishing the many contemporaneous tasks required.

 

Re: PCB Software:

I am not familiar with KiCAD. What are the benefits of using it? I like and have used Osmond PCB, which is not free, but the only limitation on the free download is the ability to output data in fabrication format (PDF and Gerber). For collaborators, if some of them are really broke, only one person would need the paid version, which I have. However, in my experience, the auto-routing is not very good, so if KiCAD has good auto-routing....

 

Osmond runs on the Mac and there is a System 8 and System 9 version available as well as versions for 10.4 and 10.5. Also, Mr. Chavez has always been super responsive to any emails about his product. I hit a bug one time, sent him before and after saves of my board where the bug was occurring, and he identified the bug and had a fix out within a couple of days. He's been developing this for ten years or so.

 

http://www.osmondpcb.com/index.html

http://www.osmondpcb.com/download.html

 

Re: USB on a SIMM

Take a look at this chip:

http://www.nxp.com/products/interface_and_connectivity/usb_host_controllers/SAF1760BE.html

 

Hmmm, seems hard to find. Or this chip:

http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_Vinculum-II.pdf

 

This is a USB host controller with a configurable microprocesser interface (instead of PCI), 16 and 32 bit selectable, and PIO and DMA selectable. The nxp package is 128 pins (routing nightmare) in a 23 X 17 mm package.

 

I think an achievable goal might be to build a ROM SIMM with this chip on it and a USB port or two. The USB ports will probably need to be at the end of wires which solder to the card, as there's probably not room on the card for actual USB sockets.

 

Write the USB driver to only support mass storage, at least at first. That will get USB sticks into the Mac as storage devices.

 

The board would almost certainly have to be four or more layers to handle the routing. I would suggest using the Flash chips Doug has in 16bit wide mode, putting two of them on one side, and using the other side of the board and the rest of the space for the USB circuitry.

 

And, as Doug surmised, it would need level shifters for the I/Os. I/O only goes up to 3.3V although it will run off of a 5V supply.

 

Anyway, I think this might be an interesting first project, which probably would not require an FPGA or CPLD, although without doing a thorough analysis, I'm not sure it would interface to the 68030 bus gluelessly. Probably need a small PLD at least to decode the addresses to a couple of Chip Enables.

 

I have considered interfacing this chip to a 68K Macintosh before, but the lack of anyone to write drivers always stopped me.

 

Re: Super Duper Do Everything Project

Start with this Xilinx Spartan 3AN Development Board ($200):

 

http://www.xilinx.com/products/boards-and-kits/HW-SPAR3AN-SK-UNI-G.htm

 

Which, if I read correctly is also the one Bigmessofwires used to build his Mac 512 hardware emulator. If we could get him to help...

 

http://68kmla.org/forums/viewtopic.php?p=158134#p158134

 

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.

 

Build a circuit board to interface between the development board's I/Os and the PDS slot of the Macintosh. Use the existing devices on the development board and the FPGA code which comes from Xilinx to drive them and then write code to interface those devices to the Macintosh PDS slot interface.

 

Ultimately, we would do our own board with the desired devices, but this would kick development off quickly, which is what a development board is meant to do...

 

The development board has DDR2 memory, parallel flash, Serial Flash, and 10/100 ethernet with PHY. Also crude VGA video out.

 

There is no USB however (well a slave interface for programming the board, but no host).

 

The Xilinx XC3S700AN chip alone costs about $40 each and has the blocks and I/O pins to do anything we could ever imagine. However, it is a BGA part, so soldering it down is problematical.

 

But I've looked at the QFP options, and generally, by the time you've interfaced them to the Macintosh bus, there just aren't enough I/O pins left to do very much cool stuff.

 

See this thread, if you have the patience for it...

http://68kmla.org/forums/viewtopic.php?p=156907#p156907

 

and these:

http://68kmla.org/forums/viewtopic.php?p=155790#p155790

http://68kmla.org/forums/viewtopic.php?p=156600#p156600

 

Is it feasible/safe/reliable to take all of the parallel ROM SIMM signals directly from there to the expansion bay/slot? That would be pretty slick if so and would remove all of the bandwidth limitations. Heck, I (or someone else) could probably get a prototype working with a bare ROM SIMM PCB and some ribbon cable.

 

I looked at doing something similar with the 68030 processor, and it turns out to be either a pain or expensive, or both to find usable cabling for such a project. At least that was my conclusion. You're considering fewer signals, so it might be more doable, but by the time you build an off-SIMM board, I think you might as well go full PDS slot.

 

http://68kmla.org/forums/viewtopic.php?p=60709#p60709

http://68kmla.org/forums/viewtopic.php?p=60790#p60790

 

 

Re: Time

I'd love to work on either the USB SIMM or the full bore FPGA development kit interface idea, but

trag is showing an enviable ability to concentrate on the most important things in life, family and the work that supports himself and his. You go guy! [;)]]'>

 

Coaching my son's Fall Baseball team right now. Then PEX DIMM. Then, maybe... You guys are way more energetic on this stuff than I can manage. I hope some of my past ramblings/conceptual designs are helpful.

Edited by Guest
Link to post
Share on other sites

Interesting notion:

 

1. If we're powering my ROM SIMM extender cable from a Molex Y Adapter, this frees up a considerable number of pins for the adapted SIMM Slot.

 

2. None of the targeted Macs have DMA, as I understand it, this means the mac cannot be using the Bank, Row or Chip Select lines of System Memory at the same time we're banging on the ROM SIMM. Neh?

 

3. Pins 1,13 and 46 become redundant +5V sources and Pins 10, 30 and 64 become redundant Ground lines as well.

 

4. Patch wiring the proper lines from the System Memory Bank Subsystem to the extender card could allow for a HUGE VM SPACE becoming addressable given the correct system patch/driver, would it not?

 

< . . . HEH! HEH! HEH! }:) . . . >

Link to post
Share on other sites
I am not familiar with KiCAD. What are the benefits of using it?

 

I'm a total newbie on the hardware side. More than a decade ago I took some lower division digital logic classes, and that's been about it. But hey, I'm willing to give it a shot.

So, I have nothing for or against KiCAD and hadn't heard of Osmond PCB before. I had heard of FreePCB, Eagle, and KiCAD had showed up on a google search. I started messing around with the free version of Eagle and really enjoyed the parts library. The reason I started looking at other solutions was the hobby edition is limited to 160mmx100mm. For an 030 PDS slot using the 120 pin connector, that's about 120mm on its own. I'm sure that'd be plenty of space for someone more experienced, but I was looking at DIP parts because I can actually solder them, and that eats a lot of PCB space. It looks like the Professional edition of Eagle allows 4mx4m boards, but costs $1700. Which isn't exactly pocket change, but I'm starting to think isn't that bad...

 

KiCAD and OsmondPCB look good to me for the simple reason that they run on OSX. I have a Win7 VM, but I find the experience of doing actual work within the VM to be less than enjoyable. However, the first thing I want to do is add the 120pin PDS connector, which no one other than Eagle seems to have in their parts library. I go to create the part, and it comes up with a window for me to manually create each pin individually and freehand lay out the spacing on the grid for 120 pins. I see that and then go back to Eagle and start to wonder how much my time an sanity are worth. :)

 

But like I said, I'm all new to this, and it's entirely possible I'm missing something.

Link to post
Share on other sites
  • 68kMLA Supporter
I was reading in another thread about hacking the ROM in the Quadra so it could use 256MBs of RAM (2x128MBs.) Could the same be done for the IIci? Stick in 8 32MB SIMMs? I don't know what I'd do with 256MBs of RAM, but it sounds like silly fun. :)

 

128MB of RAM is a hardware limitation of the memory controller in the IIci. 30 pin SIMMs have 12 address lines. The address is multiplexed (the address lines are used twice, once for row, once for column) so the addressable space on a 30 pin SIMM is 12 X 2 = 24 bits. 24 bits of address space gives 2^24 addresses => 16 Million addresses.

 

The 30 pin SIMM is 1 byte wide. It supplies 8 bits of data (or writes 8 bits of data) at a time. 16 million addresses times 1 byte width equals 16 MB of capacity.

 

So the largest possible capacity for a 30 pin SIMM is 16 MB. There are no additional address lines available to expand its hardware capacity.

 

Now, all that said, it might be possible to build some kind of hardware device which maps more memory into the IIci's address space, but the physical memory for it would have to live on a card, such as a NuBus or PDS card.

Link to post
Share on other sites
  • 68kMLA Supporter
However, the first thing I want to do is add the 120pin PDS connector, which no one other than Eagle seems to have in their parts library. I go to create the part, and it comes up with a window for me to manually create each pin individually and freehand lay out the spacing on the grid for 120 pins. I see that and then go back to Eagle and start to wonder how much my time an sanity are worth. :)

 

But like I said, I'm all new to this, and it's entirely possible I'm missing something.

 

Well it is a bit of a pain to create new parts, but once they're created, the work is done.

 

For example, I have a 64 pin SIMM edge connector in my Osmond Library which I laid out. There's no reason for me to remake all those pads every time I draw a IIfx or ROM SIMM.

 

Anyway, here's what I would do (from memory, so I'm probably leaving out details; there's a pretty good tutorial with a section on creating parts).

 

First look over the dimensions of the 120 pin connector. Then launch Osmond. Click on the Create Part button. Set the snap to grid to something that makes sense given the spacing of the connector's pins. Pick out the appropriate sized through hole/via. Check your labeling. Osmond will automatically increment the label number, so it saves time to do this up front so all your pin holes get the numbers/labels you want on the part.

 

Then lay out the through holes/vias on the grid in the order that makes sense. It really shouldn't take very long if you use the snap to grid to help.

 

Then draw an outline of the physical connector housing on the silk screen layer. Add a label you might like to have appear when you add the part to a board. And save the part.

 

Or something like that. It'll probably take two or three tries to get it just right the first time, but each try should not take more than ten or fifteen minutes, especially if you work through the Osmond Tutorial first.

Link to post
Share on other sites

Thanks! On the last page of the tutorial, it shows the format for parts and net lists. That was a major breakthrough for me. It's a very simple text file, and I can configure all the pins, give them names, define the part name from the part type, and then configure connections, giving each connection a name, all with text files. That's something I'm way more comfortable with.

I was able to define the EuroDIN120 in a couple minutes from that, and connect up data and address signals to a 29F040 in a couple more.

 

Since I'm brand new to all this, I'm taking baby steps. My initial goal is 030 PDS to a single 29F040 flash chip. That's only 8 bits of data, but the slot manager is more than happy to work with limited byte lanes (practically all nubus and pds cards have a single 27C256 as their declrom), so simplest that still works is great.

For addressing, I was just going to use 7404's and 7408's to NOT A24 and A26, then AND those with A25, A27, & A28-A31, to get accesses to 0xFA0000000, being standard slot space for slot A. Then connect that to /OE. /WE and /CE to VCC.

 

I got an extra burst of motivation this evening and attempted to wire it up:

front.jpg.1a00c035954fc00388661141bf89647f.jpg

back.jpg.8e30016d2e9cda7dab846323155320a4.jpg

 

But, I put it in a IIsi and nothing. The machine boots fine, just nothing there. I poked around with macsbug, and there's nothing in slot A's address space.

 

Oh well. I managed to create quite a rat's nest in there.

Link to post
Share on other sites

Hey, cool idea for a test! I saw you said you connected /CE to VCC--just to double check, you did mean GND right? Otherwise the chip won't respond.

 

BTW, although I don't design PCBs as part of my job, some of my coworkers do. From what I've gleaned, it's pretty standard to have to make your own components for things the software doesn't already include. A necessary evil I guess you can say...

Link to post
Share on other sites

Straight up wire wrap sockets for PDS and NuBus would be a big help for my SuperIIsi™ project. Some ROM SIMM Sockets for the extension cable project would be fabulous.

 

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.

 

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

Link to post
Share on other sites
  • 68kMLA Supporter
Hey, cool idea for a test! I saw you said you connected /CE to VCC--just to double check, you did mean GND right? Otherwise the chip won't respond.

 

Good catch Doug. Also, your logic for decoding /OE... You'll want that to have a low result on valid addresses and a high result otherwise. The /OE, /CE and /WE are all active on low/ground.

 

Finally, double check the datasheet for the Flash you're using. Some of them have a /Reset pin which must be held high in order to access the chip. If you leave it floating, the chip usually just stays in reset. This bit me on the AT29F800, IIRC. Not all Flash have a /Reset pin, but some do.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...