Jump to content

dougg3

6502
  • Content count

    723
  • Joined

  • Last visited

6 Followers

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Have you tried searching for the PC Exchange control panel? I think that's what it did -- allow access to FAT filesystems. I want to say that 7.5 came with it, but I can't remember for sure. I'm pretty sure it's possible to install it on 7.1.
  2. dougg3

    Fitting a SCSI2SD in a 68k Mac

    It's doing a low-level format, which takes a while. There is actually a way to skip the low-level formatting in newer versions of Apple HD SC Setup including 7.3.5. If you hold down the command key when you press Initialize, it skips the low-level formatting and does a quick format instead.
  3. Agreed, I would also guess it has to be something simple like reordering the data and/or address lines. Oh for sure...I have enough trouble remembering things from 2 years ago! Good to know! So it has to be some kind of simple "encryption" if we even want to call it that.
  4. I *think* that's the case anyway. I don't remember if we ever determined with 100% certainty that they're actually encrypted, but that would definitely explain why the dumps you obtained look like they're corrupted. I'm not sure if anyone has ever tried copying one of your dumped ROMs and putting it into a Turbo 040.
  5. Thanks! You're right...time flies! That is crazy.
  6. From what I remember, the content of the ROM chip on the Turbo 040 is encrypted, so you won't see what the actual Turbo 040 ROM contents are by dumping the chip. If you need to make a copy of the ROM to put in another Turbo 040, then yes, you'd need to do it this way. But you can actually dump the unencrypted ROM contents while booted into the Mac OS. Since the processor has to be able to read the ROM to execute code from it, you can read the contents of it too. You do this by dumping the 128 KB immediately after the 512 KB Mac ROM. I believe I actually made such a program a long time ago for olePigeon when were examining things to figure out what was going on. I determined that one of the Mac ROM patches that the Turbo 040 applies added code that jumped into that region so I was able to deduce that the Turbo 040 ROM was mapped there. Sure enough, when we tried to dump it, there it was. Thanks! Unfortunately not all the pages are there, but it's fun to be able to go back and look at some of it.
  7. Yeah, it's super frustrating -- that thread really had a lot of cool stuff in it. It's sad not being able to go back and see it. If I had known this would happen I would have archived that whole thread so I could go back and look at it someday. Nope, I mean the ROM checksum I think you may be right that the RAM checksum was also disabled (maybe the Turbo 040 actually has its own configurable feature to do that too?). The thing about the ROM checksum is that I used to just change it to be correct after hacking the ROM, rather than patching out the checksum test. What I discovered was that certain things look at the ROM checksum to determine what Mac model it is, or at least what ROM it is. The Turbo 040 is one of those. So the Turbo 040 ROM hack for olePigeon was where I started disabling the ROM checksum test rather than fixing it up to be correct. Sorry, but I just don't have the time. My day job keeps me busy enough that I don't have time to do any classic Mac hacking these days. That's partly the reason that I stopped selling ROM SIMMs too and let BMOW take over. I also don't have an SE/30. I do have a couple of IIcis and a IIfx, but no SE/30. I'd be happy to provide any knowledge I can to help, but as far as actually hacking, testing, or doing any coding, I don't have the time. By cache do you mean a cache card, or a Turbo 040 accelerator plugged into the cache card slot? A cache card won't change the ROM, but the Turbo 040 should. I know we witnessed it on olePigeon's IIci -- a ROM dump on his machine differed from a stock IIci ROM, because the Turbo 040 patched in several places where the Mac ROM jumps into the Turbo 040's ROM. I believe it also disabled the RAM checksum test, ROM checksum test, and some other stuff. Might have even provided a custom Daystar Happy Mac logo...now I'm starting to remember that maybe we couldn't patch the Happy Mac icon because the Turbo 040 did its own patch of that same icon? I can't remember...
  8. I made olePigeon's Turbo 040 ROM image. There's nothing really special about it -- it's a stock IIci ROM with a couple of minor changes. I disabled the ROM checksum test and gave him a custom startup chime (I think) and happy mac logo. I did all of this before bbraun's ROM disk driver existed, so it doesn't support the ROM disk driver. A stock IIci or IIsi ROM would probably also have worked with the Turbo 040, as far as I know. A lot of this was documented in my original "Another IIci ROM hack" thread which mysteriously disappeared after the forum upgrade. I don't have the time these days to play with Turbo 040 compatibility, and I would be a bad person for developing it anyway because I don't have one. But I will share what I know in case someone else wants to try to figure it out. The Turbo 040 patches the Mac's ROM, so you have to be careful not to change anything in locations that the Turbo 040 patches. I don't know if any of the Turbo 040's patches overlap with the ROM disk driver, because I did it before the ROM disk driver existed. Someone can pretty easily see the locations that the Turbo 040 patches by dumping the Mac's ROM with and without the Turbo 040 installed and comparing the two. Also, the Turbo 040 maps its own ROM to some of the space directly after the Mac's 512 KB ROM, which is going to overlap with the start of the ROM disk that gets appended to the end of the ROM if you're trying to use bbraun's ROM disk driver. So if someone were to fix it to work with the Turbo 040, they'd need to change the ROM disk driver to look for the ROM disk after the Turbo 040's ROM as well (I'm recalling the Turbo 040's ROM is 128 KB in size, but I can't remember for sure). So you would have to make the ROM disk a little bit smaller because of that. We'd also have to hope that the Turbo 040 does not repeat its ROM in the ROM space afterward (where the ROM disk usually goes), because that would waste a large chunk of space in the area of memory where the ROM disk usually resides.
  9. dougg3

    IIfx 16MB SIMMs -- Thanks Doug!

    Awesome! I like the color you picked Also, I have to give kudos to trag for his original research on IIfx RAM which you can find on this site in various threads. His info was very valuable as I was designing the PCB.
  10. It was me, over on the mac68k.info forum. I just haven't had time to complete it. Hardware-wise, it works great. It's a BeagleBone Black cape. It uses an SCC driven by a microcontroller, which talks to the BeagleBone Black through a UART. I have a driver written for it that creates an "lt0" network interface in Linux. I had it working as a LocalTalk-Ethernet bridge using netatalk. The biggest hurdle I was running into (aside from finding free time and motivation to work on the project) was that nobody has been testing LocalTalk interfaces in Linux in a long time, and I believe I was running into kernel bugs related to that, and was starting to get in over my head looking at the kernel's networking internals. I hope to someday finish it up. I know that mactjaap was very interested in it, but unfortunately I just haven't been able to work on projects lately. It would be a perfect match for mactjaap's amazing work!
  11. dougg3

    Macintosh IIcx 7.5.x freeze

    You're welcome! Glad it worked! I'm going to let Steve know so he can add it to his support info.
  12. dougg3

    Macintosh IIcx 7.5.x freeze

    Try the same hack, but instead of changing the 0003 after the 0009 to 0005, try changing the 0003 after the 0008 to 0005. The 0009 corresponds to the SE/30, and the 0008 corresponds to the IIcx. No guarantees -- I've never tried it. But logically it makes sense. It would be good to know if it works so we could get it added to BMOW's FAQ.
  13. dougg3

    FPU and SCSI2SD for LC550

    From what I can tell, the molex connector on the SCSI2SD is upside-down from how it would be oriented on a hard drive.
  14. Glad it works in your other machine Matt! uniserver: The problem you're talking about is due to the thickness of the 8 MB ROM SIMM. My supplier made the 8 MB SIMMs much thinner than the 2 MB SIMMs (even though they were both ordered at the same thickness of 1.2 mm), so it has had contact problems in some sockets. The 2 MB SIMMs are thicker and never have the problem. At least some people with SE/30s have trouble with that, but I haven't heard of anybody seeing that problem in newer machines. I've been able to add solder to the contacts to fix the problem for at least one person. Also, the 8 MB SIMM uses more traces than the 2 MB SIMM which uses more traces than the stock SIMM, so it's potentially possible that a machine could have damage on one of the higher address pins and nobody would know until they tried one of my SIMMs. On the next batch I have made (whenever I get around to it), I'll try to make sure that the PCBs end up thicker so that particular contact issue doesn't happen. Anyway, that particular issue is totally different from the issue Matt is seeing, which is almost certainly a broken trace/pin somewhere...
  15. The ASC is the Apple Sound Chip. If your headphone jack is working OK, I think it's doubtful that the ASC is the problem, because it's clearly generating sound. I'll be curious to hear how the SIMM does in the other SE/30. It should be fine...*crosses fingers along with you*
×