Another IIci ROM hack

[tt]

GttMFH says that the ROM access rate on the SE/30 is 15.67 MB/sec. Each ROM access reads 4 bytes, so it's really only a 3.9175 MB/sec access rate.

Why is the access rate getting derated to another rate and how would it compare to SCSI, does that get derated too?

 

[dougg3]

I can't speak for SCSI but the reason I'm dividing by 4 is because there are 4 ROM chips responding simultaneously--so the real rate of the SE/30 would be 3,917,500 four-byte words per second. So each chip is individually being accessed at 3.9275 MB/sec, and that's the read rate that would have to be met. I think that's right...

 

[Trash80toHP_Mini]

You could read and write reliably from a ROM Emulator interface connection to the board on the end of 200 FEET of 25 twisted pair TelCo cables daisy-chained together using 74LS series cable drivers back around 1989, IIRC. We didn't do that, but I did test that, I wanted that sucker to be reliable.

I was thinking more along the lines of having your jump-start ROM and a microcontroller based interface setup on the SIMM Card. But if you're going for a parallel cable straight from the socket's pins to the FDD Bay, that'll work. You can use a, battery backed, laptop SRAM module to emulate the ROM without skipping a beat. Then you don't need the programmer, just a USB connection to the "emulator" to write anything you want to the SRAM in the FDD Bay which is then accessed as if it were the ROM SIMM. A rechargeable battery circuit shouldn't be too bad, but button cells would work as well, if not better . . . KISS!

We used DIP SRAM ICs to emulate the identically packaged Font EPROMs back then . . . four at a time . . .

. . . that let us use a ZIF socket for one of the SRAM ICs to double it up as an EPROM reading station. }

No processors back then, just software on the PC, with cables and TTL stretching from an ISA slot to the four EPROM sockets in the target machine's expansion card! [] ]'>

 

[Trash80toHP_Mini]

Yeah, that's a good idea! 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.

If you want I can build the adapter, but it'd be better if it were in your hands for testing along the way, I'm just an electron plumber

How I'd go about it:

00 _ determine longest path from ROM Socket to farthest FDD Bay

01 _ multiply by 2.25 or 4.25

02 _ cut the lengths SCSI or IDE wide ribbon cable, doubling the SIMM pin count

03 _ split-n-strip 4" on both sides of the cables

04 _ bundle the alternate ground lines together at each end

05 _ solder one side of the cables to the expansion header of an unpopulated programmer board

______solder power and ground lines to (I've got a big supply of these) DPST DIP cutoff switch for cable's power and ground

______solder wires from HDD Y adapter cable to appropriate points on programmer board

06 _ solder the other end of the cable to the pads for the matching signals on a SIMM card

______where available, the VIAs for appropriate lines will be a tad less messy, easier to find and more durable contact points

______do P&G DPST DIP cutoff switch hack on this end - no need for P&G input source

07 _ do one last continuity test of signals from board to board

08 _ double-check the alternate P&G source test circuit

09 _ install your SIMM socket on the bare programmer board

10 _ check continuity of that, obviously, but I'm trying to be thorough here . . . [] ]'>

11 _ choose your least favorite (testable) Mac

12 _ install horrific looking kluge in SIMM slot of sacrificial offering to Thor . . .

13 _ program ROM SIMM with sampled custom test startup sound

14 _ install tested ROM SIMM in mutilated programmer board

15 _ flip power switch/hit power on button

16 _ listen for startup MUAHAHAHAHAHAHAAAAAAAAA!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [}] ]'>

17 - you know the drill . . . if you don't hear the right sound . . . watch for magic smoke emanations . . . drop back fifteen and punt . . .

18 _ . . . . whatever. [] ]'>

If your timing/alternate power source feasibility study results are positive, have someone else add cable drivers and buffering where appropriate to both ends of a simplified pair of PCBs. Add in SCA(?) sockets, internal cable headers for least expensive cable/connector combo or some such to reduce assembly time if they are allowable electrically.

p.s. trying to be thorough does not preclude every opportunity for silliness. [)] ]'>

 

[Trash80toHP_Mini]

Just thought I should hammer home the fact that this kluge is an effective RFI multiplier.

We were operating at about 8MHz with a maximum ribbon cable length of something like 12" between SRAM and EPROM Sockets, IIRC. On the MicroQuadras, Dr. Bob called a much shorter version of something similar to this applied to DRAM SIMMs in a MicroQuadra the "Evil Memory Hack" back in the heyday of 'fritter.

That said, do I recall seeing IDE cables that were standard connectors with .05 pitch, alternating ground line, ribbon cables? A pair of those could work nicely.

What are the accumulated fudge factors for increasing the height, width on either side and the thickness of the SIMM Card, after cookie cutting the various volume restrictions of all supportable Macs? I remember you discussing this somewhere in the thread, DQ.

Would anybody like to post indexing links for the balance of this thread so I can edit them into the the bookmarks I hacked into the IP . . . pretty please? :-/

 

[Trash80toHP_Mini]

Game of connect the dots, anyone? :lol:

 

[dougg3]

OK, I see what you're saying. Actually I'm cool with leaving the flash chips (and possibly an FPGA) on the SIMM as well and then putting other stuff in a FDD bay, or even something closer to what you described in your instructions (very nice detail, thanks, I get it!)

I think I'm going to have to leave the hardware hacking/testing for someone else to do though if they want I'd be glad to supply the bare SIMM PCB, the bare SIMM programmer PCB, and the SIMM socket...although I don't have any programmer PCBs available right now (they're on order and I think a Chinese holiday is just beginning so it'll be a while).

As for the height restrictions, I believe it was tt who said the current SIMM height is pretty close to the limit for what can fit into an SE/30. I'd imagine the SE/30 would be the one we have to look out for most. I know the IIci has plenty of clearance in every direction for the SIMM. I don't have any other ROM SIMM Macs available to look at, but I'd imagine we could make the PCB wider.

We have to keep in mind that level shifting is almost certainly going to be necessary as early as possible on the SIMM. This is going to add to the routing nightmare on the SIMM PCB. I like the idea of getting power from a Molex Y adapter (rather than the SIMM socket) as you said earlier.

I'd like to see a more community oriented project than me just making it all this time...I'm getting pretty worn out from circuit board design!

 

[bbraun]

Speaking of community project, just so I know about such things, the 2MB ROM SIMM is in FreePCB format from the downloads section of the google code site, and the programmer PCB is in Eagle format:

http://code.google.com/p/mac-rom-simm-programmer/downloads/list

Have you gotten a chance to make the 8MB version available?

Would it make sense to check the files into the repo? They wouldn't be easily diffable, but the history and changelog would be there, and the repo might make it easier for collaboration.

I'd also like to say thanks for all the work you've done on this. Supporting other people and trying to meet their demands and expectations in your free time can be a wearing experience, and I'm very appreciative of your work on the project. You've not just created a useful project, you've enabled a whole new class of projects previously unobtainable.

 

[dougg3]

Excellent idea, I hadn't thought of that before (checking the PCB files into the repository)! I'll try to do that soon. Especially now that Eagle 6 stores its files in an XML format, I think it will be easier to use in a repository.

I will upload the 8 MB SIMM design files soon. They are in Eagle format (once I figured out how to use Eagle, I realized it has much more capability than FreePCB [except for the fact that it's limited to 2 layers] )

P.S. I'm about halfway done implementing verify-while-writing capability. The GUI is either completely done or almost done, and the firmware is all that remains. Woohoo And thanks for your kind words--your software hacks enabled by the SIMM have been incredible too.

 

[tt]

I think I'm going to have to leave the hardware hacking/testing for someone else to do though if they want....I'd like to see a more community oriented project than me just making it all this time...I'm getting pretty worn out from circuit board design!

Sounds like a good call. Feature creep is inevitable, and it usually makes more sense to go there if the additional features are an extension of building on previous work, such as going from 2MB to 8MB SIMMs. Hacking the ROM slot to have cables and daughter cards seems like a big shift in complexity and probably cost as well (and elegance). If something like that were to be done, then it probably is best to make a PDS card instead. I could see the FPGA and flash storage on ROM SIMM idea sort of being an extension, but also a big shift in complexity.

I'd also like to say thanks for all the work you've done on this. Supporting other people and trying to meet their demands and expectations in your free time can be a wearing experience, and I'm very appreciative of your work on the project. You've not just created a useful project, you've enabled a whole new class of projects previously unobtainable.

Yes, I'd like to also thank Doug and Rob for their contributions!!! I hope my posts haven't seemed too demanding, I'm just really excited about these developments, but I do really appreciate what everyone has done here. :b&w: Before this topic showed up here, I don't think we would have thought these new developments would have been a reality today. I can now boot my machine with more features/convenience and also have another area to tinker. This project has and will inspire and enable more hacking and discovery in the future.

 

[Trash80toHP_Mini]

Hacking the ROM slot to have cables and daughter cards seems like a big shift in complexity and probably cost as well (and elegance).

Agreed, but wouldn't it be nice to change the ROM SIMM in an SE/30 without pulling the MoBo? :?:

If you'll recall, the Apple ][ world had an external expansion slot adapter that did exactly the same thing.

 

[tt]

Agreed, but wouldn't it be nice to change the ROM SIMM in an SE/30 without pulling the MoBo?

I don't really like stuff hanging off the machine, that's partially why I am stubbornly trying to adapt the PDS pass-through (another thread to come) on the Asante MacCon PDS card so I can have everything inside. Otherwise I would have gotten the ethernet/SCSI option. At the moment, I have the whole logic board outside the machine for testing ROMs and other hardware. Once it's more final (8MB Explorer ROM), I would want to just put it back together and not have to open it up too often.

 

[dougg3]

For everyone's info I have updated the SIMM Programmer software to version 1.0.2. It includes support for verify while writing (requires another firmware update) and also lets you edit the read/write filenames manually in the main window.

Thanks to CC_333 we also have a version of 1.0.1 that works on OS X 10.4 (PPC or Intel). I'm not sure if he has tested it on a programmer board yet, but as long as I didn't do anything stupid with byte endianness (and I'm usually very careful about stuff like that), it should work fine on PPC. CC_333, would you mind making a new binary of version 1.0.2 and uploading it? The source code is on the repository--just use "git pull" to update your copy to the latest. I'll make it a featured download.

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.

One more edit: the SIMM and programmer CAD files are now in the Google Code project repository. Anybody interested in doing anything with them (or the software, for that matter), let me know and I'll add you as a developer to the project!

 

[Trash80toHP_Mini]

Personally, the PDS, NuBus, DeclROM Slot Option is my first choice, but I've read both books and it's beyond the scope of what I can do. I didn't suggest breaking the entire ROM SIMM into the FDD bay, DQ misunderstood my intent and liked the notion of the down-n-dirtiest of implementations for the interface. I've got some experience with this kind of thing so I outlined the process for the test unit he poroposed.

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'm not pushing the brute force expansion bay option for the ROMM SIMM, but without Microprocesser/FPGA/CPLD or AoG (act of God) support, that's the only thing I can do to help.

Barring someone developing a Declaration ROM for the Slot Manager way of doing things, dougg3's ROM expansion approach is the only way anything is going to get done at this point.

bbraun has backed off the DeclROM/board development path for need of PCB tools, design and testing support . . . as I understand his postings.

techknight is regrouping after exploring the 2.5" SCSI SSD Project microcontroller implementation, as I understood his posts regarding that great project.

BMOW appears to be off exploring new interests after his design ideas for a SD-card floppy emulator/Floppy Emu: an SD Card Floppy Emulator project threads.

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! [] ]'>

That said:

The only thing I can think of offhand that might be worth looking into, now that ROM hacking is becoming possible, is really off the wall. Go figure. :

This has been a pet project of mine, for ten years now, for hacking the 2300. The T-REX ASIC, sits on the PBX bridged '030 bus of the PowerBooks: 190, 5300, and 1400. It's on the MoBo along with the PCMCIA Card Cage in the first two cases. T-REX is on a a very handy DaughterCard in the 1400, however, along with those same PCMCIA Slots that it supports along with the IR Talk hardware.

By tracing the 16bits of data and addressing back to PBX from T-REX, it should be easy enough to header the entire assembly to a PDS Card in the same way I've wanted to connect it to the Duo's full 32 bit, PBX bridged expansion Bus

It's my working assumption that the High and Low 16 bits of the PBX '030 bridge are split into the 16bit limited Video/EtherNet subsystems and the 16 bit limited PCMCIA/I/R-Talk subsystems of these PowerBooks.

1400s and their hinges are failing faster than ever these days and the T-REX Daughtercard is easily borrowed from a working specimen put into mothballs for safekeeping.

The question is: can we hack the ROMs of the earlier Macs to support PCMCIA, or is support for it already built into the very fabric of the NuBus/PDS-Slot Manager Architecture?

Dunno? :?:

 

[bbraun]

FWIW, I've got custom, written from scratch, copyright free DeclROMs working, and a little library for POSIXy systems to assemble the ROM images. Pick your favorite Nubus or PDS card with a removable EPROM, and a custom DeclROM can be thrown on there. If a community project is stuck because a new DeclROM needs to be written, let me know.

Until a new card is made that needs one I don't think there's a whole lot that needs doing. Which is why I had made some motions about a PDS card with some flash on it, since that seemed like the lowest barrier to overcome.

I was also thinking about the limitations of what can be done in declrom vs. system ROM. Yesterday I wrote some PRAM modifying apps that enable/disable a feature of the AV ROMs that copies the ROM contents into RAM, and runs all ROM code from RAM that way, which kind of kicked off this idea.

Early in boot, the Slot Manager in the system ROM runs initialization code from the declrom in each card. To behave nicely, this should be <2K of code, and run within some timing constraints, a very limited environment, and maybe with interrupts disabled. The point is to just do early initialization of any hardware, video cards display their grey screen, etc. But, I'm kind of toying with the idea of whether it's feasible to just load your own system ROM (or copy the existing system ROM into RAM, and patch it on the fly, avoiding copyright issues) and never return to the original ROM. I'm kind of wondering if this might be what some accelerators might be doing.

Anyway, that wouldn't be able to do things like enable/disable ROM CRC checks, the POST RAM test, or the memory sizing change I did for the djMEMC machines, but it would allow mucking with the boot device selection process, loading new drivers, etc. Anyway, just an idea that'll be added to the end of a very long TODO list.

 

[Trash80toHP_Mini]

The Radius Rocket writes the host's ROM to onboard RAM on the first boot and then boots from it for the, WHOOSSSHHHH!!!!!!!! re-boot.

Radius was licensed to do so, eliminating a major bottleneck, IDK of any other such ROMcopy to RAM offhand, outside the actual Macs, of course.

 

[Dennis Nedry]

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.

 

[dougg3]

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!

 

[tt]

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.

 

[Dennis Nedry]

We should quantify ROM vs. paged ROM vs. RAM vs. SCSI vs. NuBus speeds. If you can get the data there fast enough (i.e. parallel ROM like dougg3's current designs), ROM should be the fastest but by how much I'm not sure.