Jump to content
dougg3

Another IIci ROM hack

Recommended Posts

Thanks tt! Good to know. You should also now have choices in the software for the larger ROM SIMM size (and it will remember your last choice between quitting and reopening the app now too)

 

Yes, I'm happy with the design. I have several of them built up right now and they all work fine -- if you're interested in a green one, you can certainly buy one now.

 

I will order a new batch of PCBs soon. The only difference will be the color (I can't remember what the consensus was, but I'll go back and look and order it in that color--blue I think?) and I'll fix the jolly roger -- I had to remove part of it on the programmer for the LED eye, and I reused that graphic without paying attention so it has a big hole in it where the LED was. I'm not planning on adding any LEDs to this board.

Share this post


Link to post
Share on other sites

Hi,

 

I can test in OS X 10.8.2.

 

Also, is there any chance this will work on 10.4, either PPC or Intel?

 

Thank you for making this possible!

 

c

Share this post


Link to post
Share on other sites

Great, thanks! It should work fine in 10.8.2, since that's what my compile machine is running too :)

 

10.4 might be possible in the future, but I'll have to set up one of my older computers with an install of 10.4 first for compiling. I'll check into what it takes to compile Qt programs on 10.4. If you have a 10.4 Intel machine available, I'd actually be very interested in knowing if the binary I made will run. I doubt it will run, but it would be worth a try. PowerPC definitely won't work at this time (newer GCCs supplied with newer Xcode versions no longer generate PPC code--so I'd need some older developer tools to be installed).

Share this post


Link to post
Share on other sites

I see.

 

Is the source code available? Maybe with some guidance, I could try compiling it on a PPC machine to see what happens (I have several available, running Mac OS X 10.4 and 10.5). However, if anything needs to be changed, then someone else (perhaps you?) would need to make those changes first, because I wouldn't know what to change (I don't know too much programming, yet).

 

c

Share this post


Link to post
Share on other sites

Yep, it's all available at the Google Code project. Besides just Xcode installed, you would also need an older version of Qt installed. I may try making it work on my iMac G4 -- just need to install OS X on it. In theory it will compile and work just fine, but in practice who knows...

Share this post


Link to post
Share on other sites

Just downloaded, works great on:

 

iMac 21.5" Core-i5, 8 GiB (OS X.7.5)

MacMini Core2Duo, 2 GiB (OS X.5.8)

 

If needed, I can setup the last machine with the originally supplied version of Tiger, for further testing.

 

Thanks again!

 

PS: Any remarkable improvements in mind for the next batch of SIMMs? If nothing big is gonna change, I could take a couple of the current 8 MiB batch ;)

Share this post


Link to post
Share on other sites

DQ, your SIMMs are so addictive it must be like crack. ::)

I'm tempted to get one of these AND one of the final version, just to have the complete set! :-/

 

BTW, at 28,660 views you're creeping right up there, but your first post here was already ahead on replies and @ p.34 just bested Post your desktop! :approve:

Share this post


Link to post
Share on other sites

Hi,

 

What I like so much about this project is it's completely open source nature.

 

rant>

 

Speaking of open source, isn't QT supposed to be open source as well? For some reason, I can only get a 30 day trial of the latest version; they want me to buy it! I don't want to buy a piece of software I may only use once or twice!

 

Is there some kind of archive where I can find older, free versions? I've done some Yahoo searching with few results.

 

I guess Open Source doesn't necessarily mean free of charge.

 

 

Anyway, I tried the Programmer application on OS X 10.8.1, and it ran (although it couldn't do much without the programmer attached). I will see about actually using it once I get a SIMM and a programmer.

 

c

 

p.s. Pardon my rant!

Share this post


Link to post
Share on other sites

Never fear -- what you're seeing is the commercial version of Qt. It has always been licensed for GPL or commercial use, your choice. Then around the time Qt 4.5 came out, they also made it LGPL (which, IMO, they should have done from the start to increase its exposure--I consider it far superior to GTK).

 

They recently moved the open source part of Qt to its own domain name -- http://qt-project.org/ -- I was confused at first yesterday as well, but that's what happened.

 

All of the newest goodies are still available there, open source as usual :)

 

Any remarkable improvements in mind for the next batch of SIMMs? If nothing big is gonna change, I could take a couple of the current 8 MiB batch

 

The only change is going to be the color of the PCB and a slightly improved silkscreen Jolly Roger because I accidentally screwed up the one I used for this batch. Thank you for testing the software with OS X 10.5.8. Looks like whatever I did, I did it correctly again :)

 

DQ, your SIMMs are so addictive it must be like crack.

 

Haha, thanks jt! Once you start hacking the ROMs you just can't stop! :-D

Share this post


Link to post
Share on other sites
Once you start hacking the ROMs you just can't stop!

 

Tell me about it.

 

I've been using the new app on 10.6.8 with the 2MB ROMs today without problem.

I took a look at the source today too, and it looks like it opens and reads the file every time I click the 'write to simm' button? Which is good since it means I can modify the ROM image and not need to do anything but hit the write button again. The only other feature would be the ability to modify the file name. I frequently do something like "filename#.bin" and increment the number for any substantive change. Being able to type in the filename field would be spiffy.

Share this post


Link to post
Share on other sites

Yep, I intentionally designed it that way because of the exact same use case you just described :-)

 

I think I also intentionally disabled modifying the write/read filenames--not sure what I was thinking. I can easily change that and will do so in the next version. Thanks for the ideas!

 

BTW, another change is it will now remember your choice for the SIMM size and "verify contents after write" checkbox between program launches.

Share this post


Link to post
Share on other sites

Nice! I actually always verify, which has been the default. I've had a few verification failures over the maybe 200 writes I've done, most seem due to improper seating of the SIMM. It's much better to spend the time on the verification rather than spending time trying to debug something that could have been caught by enabling a checkbox. :)

I've also done stupid things like accidentally writing without a SIMM in place because I got out of my test cycle groove. It seems like write without verify doesn't complain in that case.

If it's easy to interleave the verification with every couple dozen flash blocks, it might be able to catch the common failure modes faster than doing a full write (especially with 8MB!) followed a verify. I'm thinking of the improperly seated SIMM and the no-SIMM cases.

Share this post


Link to post
Share on other sites

I verify every time too and I agree with everything you said. Your verify errors should be more interesting with the latest software because it tries to identify which chips are acting up. I don't do any kind of extra data verification so I guess it's also possible a byte got skipped during the USB transfer too. I'd love to make it identify specific data/address lines on each chip that are acting up too (not sure if that's even possible for address lines though :) )

 

I'm going to look into adding verification while writing (very good idea!). It shouldn't be that hard. I already have to do a bunch of read cycles after writes (polling for the finished write), so it would just be a case of checking to make sure the byte read back matched what I wrote. I seem to recall reading in a datasheet that you should read back an extra time or two after the polling algorithm has finished to ensure you read the correct data back from the chip. Anyway, I'm adding these as issues so I don't forget.

Share this post


Link to post
Share on other sites
I'm tempted to get one of these AND one of the final version, just to have the complete set!

Me too, I think I'll wait for the second batch to save on shipping...feeling a little tight budget-wise ATM. :-/

 

I am wondering, is anyone tracking down the boot chime changes for the IIsi ROM since it has sort of become the "golden" ROM?

Share this post


Link to post
Share on other sites

8 MB is the limit of the ROM slot, after that you have to start adding clips for more address lines, if it can work that way. Each clip would double the max ROM if the memory controller allows this.

 

Max ROM SIMM = 8 MB * 2 ^ (# of clips)

 

We also talked about using some sort of large flash drive/CF/SD card, but this presents a problem because they are serial and the Mac expects parallel ROM. It would be difficult to convert serial to parallel fast enough for that to work.

Share this post


Link to post
Share on other sites

I've thought about it, but there are a couple of problems:

 

The ROM SIMM slot pinout only provides for 8 MB of space, so you'd have to do extra hardware hacks to get more address lines. Might be better to do a PDS type card instead because of that.

 

You have to get the data off the CF card and onto the data bus fast enough. It's going to require some kind of controller/FPGA/whatever in between to read from the CF card and stick it on the bus fast enough, or use RAM or . I think on the past couple of pages people were discussing ways to make it happen -- but that 8 MB limit is still a problem.

 

I was thinking if a ROM disk was the main reason we wanted to use the extra space, a ROM disk driver could change between different 7.5-MB pages by writing to a register (which would be handled by the FPGA) to pick the selected page. This is how 16-bit microcontrollers handle addressing more than 64 KB of space, for example. So you'd still only need the 8 MB of address lines in that case. It would be pretty complicated to get working though. I believe this is also how Nintendo games were able to address larger amounts of program space as well.

 

Edit: What Dennis Nedry said. :-)

 

Edit2: I forgot the "write" line doesn't come out to the SIMM. It would have to be something like what bbraun described. Maybe a read from a specific address followed by another read to select a bank or command or something?

Edited by Guest

Share this post


Link to post
Share on other sites

One could still use the ROM slot for more storage though. Put some registers somewhere in the 8MB addressable space, and a device driver (we're already using one as it stands) could access an arbitrarily large backing store through polled access of those registers. It'd work more efficiently through an interface that had an interrupt line, but still seems doable just through the ROM slot. And of course it doesn't necessarily even need to be accessing storage, it could be accessing a USB device, or network, or even another processor. :)

Share this post


Link to post
Share on other sites

Device drivers sounds cool. Is it possible to put extensions on the ROM SIMM? Would be cool if SCSI, Zip, Jaz, or MO drivers were loaded on ROM so you don't need to have any extensions on the machine. Someone mentioned putting SCSI Manager on the ROM?

Share this post


Link to post
Share on other sites

As far as what can be put in the ROM, in theory anything can. It's only software, right? ;)

When I typically use the term 'device driver' on Mac OS, I'm referring to resources of type 'DRVR'. Those conform to a specific interface and can be manipulated by system API. The only thing that's required for those to work in the ROM is they be added to the resource section of the ROM, and some code somewhere needs to call _Open with the device driver's name (in theory). My ROM Disk driver does this by replacing the unused .netBOOT driver in the resource section of the ROM, and the ROM already has code to call _Open on that driver, so all of that happens for "free".

There's only so many unused entries in the ROM resource section to be repurposed. Eventually, it may be necessary to move the entire resource section past the end of the regular ROM so it has room to grow. The resources within the ROM should be self referential (as in, not have relative offsets to other parts of the ROM outside themselves), so moving the entire thing is probably going to be safer than trying to grow it in place and move code that comes after it, which is definitely being referenced through relative offsets from elsewhere in the ROM.

 

But, resources of type 'DRVR' are only a specific set. Extensions are things that have resources of type 'INIT', which is a code resource that gets run at specific times during OS boot. That all gets a little more tricky, especially since the 'INIT' code typically loads other resources within the extension file, like icons to display at boot time, or just to load and run 'DRVR' drivers. Those might be evaluated on a case by case basis, I think.

 

Anyway, the gist of the whole thing is: maybe? :)

Specific instances can be investigated on a case by case basis, I think.

Share this post


Link to post
Share on other sites

Just brainstorming here after pondering Dennis Nedry and bbraun's replies...

 

How about leaving the first 4 MB of ROM SIMM space as regular ROM? It is still connected directly to a flash chip, so no problems booting at all -- it's already all parallelized and ready to go right off the bat. Connect the SIMM /OE pin and the appropriate SIMM address pin to an AND gate's input, and connect the AND gate's output to the ROM chips' /OE pins -- I think that would be sufficient to disable the ROM chips' outputs in the second half of the ROM SIMM space. Maybe not an AND gate, but whatever gate is appropriate (too lazy to think about it right now).

 

Then, drivers patched into that ROM space read from various locations in the second 4 MB of ROM SIMM space to do things. To "write" to it, you could read from a certain address inside that space, followed by four consecutive reads from a 256-byte space to specify the address, and another four consecutive reads to specify the data. Example:

 

I want to write $12345678 to $ABCDEF00 (which might be a register I've created in the FPGA for something--a memory page selection register or an SD card controller register or whatever). The "begin write" register is at $40C00000, and the "write address/data" registers are from $40C00100 to $40C001FF.

 

So I start by reading from $40C00000. The FPGA notices this and starts listening for reads from the "write address/data registers" registers. Next, I read from $40C001AB, $40C001CD, $40C001EF, and $40C00100, in that order. Now the FPGA knows I want to write to the address $ABCDEF00, and waits for 4 more read cycles to figure out the data to write. So I read from $40C00112, $40C00134, $40C00156, and $40C00178. Now the FPGA knows both the address and the data I wanted to write, so it does the write. Finally, there could be some kind of a status register to poll to determine completion of the write (if necessary).

 

Obviously, this is slow because it takes 9 read cycles to do a single "write cycle". Is that a big problem? For faster performance, I could reserve a 64K space rather than a 256-byte space and do two bytes at a time. That would only require 5 read cycles. I could probably cut it down to 4 read cycles by combining the first $40C00000 read cycle with the first "write address" read cycle, perhaps in a new 64K space so I still have sync information to know when a read begins.

 

Using this technique, I'm pretty sure we could do *anything* we want with the ROM SIMM slot, no extra hardware mods required. Map a huge CF card, SD card, or any other peripheral like bbraun pointed out.

 

Of course, routing the board would be tricky, but it could probably be done...may need 4 layers to fit the FPGA/sockets/etc. on the board though.

 

Wow...I think my mind is about to explode now.

Share this post


Link to post
Share on other sites
Wow...I think my mind is about to explode now.

Haha, mine too! Clever idea. I was thinking of using SLC flash chips to make an SSD on ROM SIMM. If it were done that way, and everything can keep up, you could get an order of magnitude of speed over native SCSI for most of the compatible machines (15-20MB/s according to GTTMFH).

Share this post


Link to post
Share on other sites

I don't foresee any particular problems with that approach from the software side as long as there are synchronization registers to know that the results of any particular command are ready.

Worst case, the driver would be called from an interrupt handler, but I'm not seeing anything particularly problematic. This is a really simple interface, which makes it safe in a variety of situations.

 

I'm up for a driver. :)

 

The ROM SIMM interface will be slower than PDS, but it'd certainly work on more machines. That seems like a plus to me.

 

For the specifics of the access pattern, it would be easiest and fastest from the driver perspective to do as much as possible on the FPGA side, reducing what needs to be done by the host processor. Plus it's pretty much guaranteed the FPGA is going to be faster than the host processor anyway. But, the tradeoff there is making the access pattern application specific vs. generic and modular.

For both size constraints and modularity, would it be reasonable to put the FPGA on the SIMM, and have a connector and separate board for the components the FPGA exposed (microSD/CF/whatever)? My thinking is that CF probably won't fit within the size constraints of the current ROM SIMM, and there are quite a few different ideas of what could be exposed.

 

Anyway, just some thoughts.

Share this post


Link to post
Share on other sites

On the hardware size limitations/design front, it looks to me like it's time to just add a microprocessor to your ROM SIMM, DQ. ::)

 

Breaking the rest of the circuitry out to a header cable (USB?) leading to a daughtercard stand-off'd inside an FDD Chassis seems a no-brainer to me. That's your prototyping area with physical I/O accessed through the Floppy Slot, probably from a second prototyping board. This physical I/O form factor is common to every FDD era Mac and conveniently positioned as well. [:)]]'>

 

Dunno, maybe the cable from the SIMM should be designed from the start as a DaughterCard headered to a square prototyping board with pads for four I/O connector combination choices to be aimed at the floppy slot from its standoffs, in said standardized sheet metal expansion bay housings?

 

Dunno, I'm just piping into the brainstorming session where I can at this point, my head already exploded a few pages back! 8-o

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

×