Jump to content

powermax

6502
  • Content count

    77
  • Joined

  • Last visited

Profile Information

  • Gender
    Male
  • Location
    Germany
  • Interests
    Software Development, Vintage Computing

Recent Profile Visitors

97 profile views
  1. CUDA, EGRET, HC6805 Hacking

    Glad to know, thanks! IIUC, I'd need an extra account to access the Wiki, right? Is there any ASIC-related Wiki section there? I didn't see any. Where may I post such information to?
  2. Frankly spoken, I'm out of my depth now. I think you need to gather more data on the failure of your Quadra board. Can you do some electrical analysis of your board and compare the signals it generates with a known working board? That would be very helpful. Otherwise, we won't be able to go a step beyond guessing. Moreover, I don't think that any blind IC replacement would be a good idea, especially when the ICs in question are vintage ASICs you'll probably not be able to find any replacement for...
  3. Free 68k (dis)assembler for Mac?

    Thank you for pointing me to FDisasm that I'm aware of. I personally never considered to give it a try because I don't use Mini vMac emulator I never seen any ROM formatting files for the ROMs of my interest (PowerMacintosh 6100 and newer) MAME/MESS offered me anything I need in just one package. Moreover, MAME's source code is a superb and the most complete documentation on the proprietary Macintosh hardware ever available I'm glad to hear that your disassembler offers some annotation functions one could find in only few advanced tools like IDA Pro. It looks like we need to consolidate our efforts on MacROM-related tools. BTW, are you aware of the cdg5 ("countdown to G5") project started by a small team off the macos9lives forum? The goal of this project is to hack Mac OS 9 to run on unsupported Macintosh hardware (PowerMac with newer G4/G5 processors). These guys have created their own toolchain, vaguely similar to yours (Python-based disassembler/annotator + MPW for rebuilding the ROM). You can take a look at this repository. Sure! My preferred workflow is to use a debugger coupled with an annotated assembly. Some tricks like memory mirroring simply cannot be coped with by the static analysis alone...
  4. This would be possible if your board had EEPROM or Flash storage. It's a well-known fact that all Apple desktops in the 90s use 3.6V lithium batteries to maintain non-volatile memory. That means that PRAM (NVRAM) is actually a small amount of CMOS RAM powered either by the mains or the battery. In the case ALL power is lost (that's it - the battery was pulled and the power supply is off), the whole PRAM content is also lost. It's difficult to imagine what kind of magic TechToll can do beyond that... FYI, PRAM is a part of the RTC IC (U92). Its part number is either 343S0042 (Motorola-made) or 344S042 (VLSI-made). I don't know which one sits on your board...
  5. CUDA, EGRET, HC6805 Hacking

    What's about the 68kmla Wiki?
  6. Free 68k (dis)assembler for Mac?

    If you're going to gather some knowledge about a specific ROM or ROMs, the question is if the static analysis (i.e. disassembly/hex dump) would be the right tool for the job. You can surely run a disassembler over your ROM dumps. The problem is that the most disassemblers are just dumb tools (the older the worse) - you'll get a lot of night-impossible-to-understand garbage out of them for a couple of reasons, among them: disassemblers cannot fully automatically distinguish between data and code (and Mac ROMs mix them a lot!). This problem has been proven unsolvable, see this discussion on the Halting problem. That's why all modern disassemblers implement various pattern matching based heuristics to identify code and offer interactive features as a last resort so humans can step in and guide the disassembler. IDA is a good example of such a tool. ROM dumps don't contain any human-readable function and variable names. Memory-mapped hardware can vary greatly between machines. One ROM usually has support for a group of machines and contain a lot of machine-dependent code. a whole bunch of old Mac hardware remains fully or partially undocumented. I therefore recommend you to try some sort of dynamic analysis - that is, an interactive debugger with disassembling capability. Because you're targeting 68k ROMs, you can try out MAME/MESS emulator. It's capable of emulation practically every 68k Macintosh including its hardware. The best part - it contains an integrated low-level debugger so you can even set breakpoints in ROM (that's what you cannot do in a real Mac!!!), dump hardware's internal state etc. You'll need a fast modern host computer (Linux, Mac or Windows) but that's the price for its almost luxurious RE features. Just ping me if you need any additional information on MESS (what a stupid name ) and its tools. Cheers Max
  7. Yes, I agree. Mouse movements involve interrupt signals. That's indeed smth you want to check next...
  8. I don't think it's possible. It's true that the ADB as a single-line bus requires precise time slices. But this leads to the following logical conclusion: if this timing is somehow broken, the whole ADB communication will become broken. Any partial failure can only happen after the ADB transceiver/decoder, either in hardware (between the ADB decoder and the CPU) or in software. BTW, the mouse you're using, is it a compatible one? Does it work with the other Q700 board as expected? Do you have an oscilloscope/logic analyzer?
  9. These markings are often confusing and mostly meaningless. If I had to guess, it looks like a Motorola-fabricated clock driver IC (MC74F803), similar to those used in Amiga, see this Wiki page. It seems to provide clocks for the CPU. You'll find the datasheet MC74F803 for on the above mentioned page.
  10. Please tell us the part number or post a picture...
  11. CUDA, EGRET, HC6805 Hacking

    Is there any place around here where I can dump all CUDA-related stuff (including pictures, schematics, firmware disassembly etc) I gathered so far? A kind of editable Wiki?
  12. CUDA, EGRET, HC6805 Hacking

    368 is the correct amount of required RAM. 386 was a typo. Sorry.
  13. CUDA, EGRET, HC6805 Hacking

    Sure. I attached three different binary dumps. Disassembly including my personal comments aren't included there. I need to take some precautions and don't post those here because they're surely copyrighted... CUDA Firmware dumps.zip
  14. CUDA, EGRET, HC6805 Hacking

    CUDA Firmware actually uses 386 bytes of RAM. It's divided into two main partitions as follows: $0090 - $00FF various local variables $0100 - $01FF 256 bytes of PRAM --> yes, PRAM is simply a part of the CUDA's internal RAM; since it's always powered (either by the mains or the battery) it doesn't lose its contents
  15. PM 6100 logic board

    Some pictures of my PM 6100 logic board.
×