-
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
Trash80toHP_Mini
NIGHT STALKER
Dynamite, bbraun is playing Software Panza to your Doug Quixote act there, buddy! The work the two of you are doing in tandem is nothing short of amazing. :approve:
If I ever get the Rocket to work in there, a silent 7.0.1 or 7.1 initial boot for the SuperIIsi™ with the striped Ultra SCSI 160s finally spinning up in the StudioArray when the SCSI II DaughterCard wakes up upon the WHOOOSH!!!!! reboot will be almost perfect.
An initial boot startup sound with screen shot boot image from the likes of the countdown sequence from a movie like Apollo 13 or something with a more modern, triumphal, score like Armageddon will be the icing on the cake for that impossible dream.
Go, dawgs go! [8D]
If I ever get the Rocket to work in there, a silent 7.0.1 or 7.1 initial boot for the SuperIIsi™ with the striped Ultra SCSI 160s finally spinning up in the StudioArray when the SCSI II DaughterCard wakes up upon the WHOOOSH!!!!! reboot will be almost perfect.
An initial boot startup sound with screen shot boot image from the likes of the countdown sequence from a movie like Apollo 13 or something with a more modern, triumphal, score like Armageddon will be the icing on the cake for that impossible dream.
Go, dawgs go! [8D]
Yeah, bbraun is doing some really amazing software hacking!
OK -- I'm pretty happy with the 8 MB SIMM now. It works and it's easy to build! No copper braid needed anymore. I got a "hoof" tip for my soldering iron:
This thing makes soldering fine pitch ICs a breeze. The hardest part of the whole process is lining the chip's pins up with the PCB pads. Once it's lined up perfectly, simply tack it in place with solder on two corner pins, apply a generous amount of flux to all of the pins, put just enough solder onto the hoof to cover its surface, and drag along the pins. No shorts or anything...amazing. I don't know exactly how it works, but I think it's because the tip has a ton of surface area so the solder would rather stay on the tip than bridge across the pins.
They also make convex hoof tips that supposedly work even better--probably by increasing the surface area even more. I have one on the way. Apparently they are somewhat more difficult to find in the US because of a patent.
Anyway, if anyone is interested in a revision 1, 8 MB green ROM SIMM, let me know. I know some people will probably want to hold out for the final version with a different color and that's fine. I don't really plan on changing anything except the color though. I also need to fix the Jolly Roger graphic because I forgot part of it had been clipped out for the SIMM programmer's version of it.
The 8 MB SIMM's price will be $30.
BTW, I've been messing with DDR2 memory timings on a project at work this past week. I don't ever want to make a circuit board that does anything with high speed signals...ever. I also don't ever want to write any software that sets up a memory controller
OK -- I'm pretty happy with the 8 MB SIMM now. It works and it's easy to build! No copper braid needed anymore. I got a "hoof" tip for my soldering iron:
This thing makes soldering fine pitch ICs a breeze. The hardest part of the whole process is lining the chip's pins up with the PCB pads. Once it's lined up perfectly, simply tack it in place with solder on two corner pins, apply a generous amount of flux to all of the pins, put just enough solder onto the hoof to cover its surface, and drag along the pins. No shorts or anything...amazing. I don't know exactly how it works, but I think it's because the tip has a ton of surface area so the solder would rather stay on the tip than bridge across the pins.
They also make convex hoof tips that supposedly work even better--probably by increasing the surface area even more. I have one on the way. Apparently they are somewhat more difficult to find in the US because of a patent.
Anyway, if anyone is interested in a revision 1, 8 MB green ROM SIMM, let me know. I know some people will probably want to hold out for the final version with a different color and that's fine. I don't really plan on changing anything except the color though. I also need to fix the Jolly Roger graphic because I forgot part of it had been clipped out for the SIMM programmer's version of it.
The 8 MB SIMM's price will be $30.
BTW, I've been messing with DDR2 memory timings on a project at work this past week. I don't ever want to make a circuit board that does anything with high speed signals...ever. I also don't ever want to write any software that sets up a memory controller
My concave (not convex, what was I thinking?) hoof tip arrived today so I was able to play with it too. It also works really well to prevent bridging, but it didn't seem like it was any better than the first one I tried that didn't have the concavity. Either way, very cool stuff. The right tools make the job way easier
If I get bored, maybe I'll post a video of how they are assembled sometime.
If I get bored, maybe I'll post a video of how they are assembled sometime.
I just posted updated binaries (the zip files include the latest firmware too) to the Google Code project. (Woo for 4G LTE, much faster for uploads than my home internet...) Would anybody with (or without) a SIMM programmer mind running the program on OS X or Windows to ensure that it still runs? I'm especially interested in the Mac results. I lost the steps I used last time to compile it for Mac so I had to redo it from scratch on Mountain Lion. (And this time I saved my instructions on the Google Code wiki!) I'm hoping the binary still works on systems as old as 10.5 (Intel only -- 32 bit or 64 bit).
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.
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.
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).
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).
CC_333
Well-known member
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
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
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...
zuiko21
Well-known member
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
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
Trash80toHP_Mini
NIGHT STALKER
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:
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:
CC_333
Well-known member
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!
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!
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
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
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
Haha, thanks jt! Once you start hacking the ROMs you just can't stop! :-D
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.
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.
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.
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.
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.
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.
)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.
Similar threads
