Jump to content

dougg3

6502
  • Content Count

    736
  • 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. I messed a lot with it when I was doing my initial ROM hacking. The startup chime also uses it
  2. Glad you got the installer to run! I wish I could help more, but my Cabletron card is actually a NuBus card in my IIci. Unfortunately I don't know any details about the SE/30 card or how to use it. Hopefully someone with an SE/30 might be able to chime in. I can tell you that my IIci's card has a switch -- the housing of the switch is blue, and the switch itself is white. It's in the down position (toward the RJ-45 jack) and I've been using the RJ-45 jack rather than the AUI port. I'm pretty sure 7.5 should be fine for networking. I use my card in 7.1 with no problems at all. I'm able to ping my IIci from my Windows 10 computer, as long as MacTCP is set up properly. I have noticed that pinging doesn't work until I do something that causes MacTCP to load on the Mac, like running the "MacTCP Ping" program that I use to test pings initiated *from* the IIci. Simply opening the MacTCP control panel isn't enough to get the networking stack to load.
  3. Hi Grog, I ran into this same problem a while ago. Here's how I solved it, I think (seems to work in Basilisk anyway...): Extract cabletron.sit This should result in a folder called "Cabletron Ethertalk Installer" Rename this folder to "Ethertalk Installer" Now you can use the Installer inside of it. If the folder has any other name, it asks for the disk just like you're reporting. You can also create a disk image of the renamed folder using Disk Copy 6.3.3. That also seems to work in my testing.
  4. dougg3

    Mac IIci PSU recap advice

    Yeah, I'm not sure where I originally got them, but those are the same schematics I was looking at. This must have been around the time Apple was transitioning to using the CUDA chip for power control. I think it's in control of the PRAM, so that's probably why the battery can power it too...maybe limiting current to minimize battery draw? Dunno. Not sure why the 12V part of the supply is involved at all. Well, darn. I was hoping it was going to be as simple as that diode having a problem.
  5. dougg3

    Mac IIci PSU recap advice

    I did some digging on schematics, and the IIsi logic board has a resistor in series with a diode going from /PFW to 5V similar to the IIci. On the IIsi: R115 is a 3.3k resistor that should be connected to /PFW on one end, and D3 on the other end. D3 goes to 5V. Might be worth a check...
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. Thanks! You're right...time flies! That is crazy.
  11. 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.
  12. 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...
  13. 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.
  14. 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.
  15. 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!
×