Jump to content

ZaneKaminski

6502
  • Content Count

    186
  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

535 profile views
  1. ZaneKaminski

    Cheap USB mouse adapter for 128k/512k/Plus?

    This guy sells one: https://www.tinkerboy.xyz/product/tinkerboy-usb-mouse-to-mac-converter-adapter-for-macintosh-with-db9-mouse-port/ Not too expensive and the case design is quite professional! Nobody seems to be talking about it; the designer posted on AppleFritter several times, but last I saw, there were no replies in his threads.
  2. ZaneKaminski

    Help with LCII Repair

    It’s complicated...I puzzled it out a bit more. The LC II has no less than four signals called reset. Two “power-on reset” signals are generated by U12, which is an MC34064 “undervoltage detection chip.” U12’s function is to pulse those reset signals when the power is turned on or recovers from a brownout. One power-on-reset goes to the video system and the other reset goes to the Egret. This power-on-reset going to the Egret doesn’t directly reset the Egret MCU. The Egret has its own internal brownout detection circuitry. Instead, software in the Egret monitors this signal and others and decides to assert the system reset. This system reset is a 68030 pin as you mentioned, and it also goes to many of the I/O chips on the LC. The idea is that the Egret receives multiple reset sources (ADB, brownout, reset button, etc.) and resets the system when any of these are active. So pin 12 on the Egret is the power-on-reset coming from the brownout detector U12, and that signal tells the Egret if the power has dropped too low. That should always be low when the PSU is on. Pin 2 on the Egret is the Egret’s own reset signal. It’s pulled up to 5V (meaning the Egret always runs) and has a big capacitor to filter out any glitch pulses that might accidentally reset the Egret. The reset button on the case is connected to the Egret’s reset as well. So that pin should always be a logic high after power-up unless you press the reset button. Pin 15 on the Egret is the system reset which the Egret generates and sends to the 68030 and PDS and I/O chips. So check with the scope if that is low right after power is applied but then goes to logic high within a second. That’s what it’s supposed to look like.
  3. ZaneKaminski

    Help with LCII Repair

    Wow! I did not know this. I thought it would not be possible to dump it from the Mac. Maybe the Egret is the same as one of these 6805 MCUs, and if so, we could burn another: http://www.bitsavers.org/components/motorola/6805/Single_Chip_Microcontrollers.pdf The Egret has 28 pins and evidently 4.25 kB of ROM, judging from the ROM dumps. None of the MCUs in that list seem to match. Some have 4.5 kB of ROM though.
  4. ZaneKaminski

    Help with LCII Repair

    The system runs when reset is high (above 2.0 V) and doesn't run when reset is low (below 0.8 V). When the computer powers on, reset should be low, but then it should go high and that in turn causes the processor to work, startup chime, etc. So if it's always low or going back and forth, the Egret is resetting the system when it shouldn't be. I don't think it'll be easy--the Egret MCU is not only a custom Apple chip, but there's a program inside that I don't think anyone has an image for, even if you could buy a similar blank microcontroller. So I think the only source is to pull it off of another LC II or Mac with the same chip. It's certainly possible. Moisture builds up in chips over time and when soldered with hot air, the water inside can boil quickly and expand, cracking the chip or otherwise deforming the package. This is called "popcorning." Here's a picture I found showing some extreme examples, but it's not necessarily visible from the outside: I didn't believe popcorning was a major issue until some time ago, when I made a batch of Commodore 64 geoRAM clones using an old CPLD chip. After reflow soldering in the oven, every single board failed. Baking the chips for a day at 100 degC fixed the issue in the next production run. So you've often gotta bake the chips/board before using hot air. The LC II board probably can't handle 100 degC so you can do 50 degC or something for longer. (next time, that is) As for iron temperature, I don't think it's an issue. I typically use a Hakko FX-951 soldering iron at 800-840 degC. (Higher than 840 is technically brazing, not soldering.) Even at that high of a temperature, I don't think you end up holding the iron on the pins for long enough to heat the chip up enough to get the popcorning failure, since nobody talks about it with hand-soldering.
  5. ZaneKaminski

    Help with LCII Repair

    Looking at the schematic briefly, it seems that U10 6805 microcontroller drives the system reset low, since the physical reset button on the LC II is hooked up to the 6805's reset input. I would check if the system reset (available on the PDS slot) is ever going high with a multimeter or something. If reset is always low that suggests that U10 is not working right.
  6. Good news! The 8MB SIMM works! Thanks to all of the testers for their diligent work on the 2 MB SIMM! @JDW uncovered a significant defect in the 2 MB SIMM which is possibly the reason it didn’t work in his SE/30. Fortunately the 8 MB SIMM doesn’t have this issue, so hopefully that will fix the incompatibility with his machine. So 8 MB SIMMs are going out to testers soon! If the 8 MB SIMM testing goes better than the 2 MB testing (which went okay from a software perspective, but there were too many mechanical issues in SE/30s), we will be able to finalize the disk images and the release plan. One question about MacsBug—I included MacsBug 6.6.3 in the 7.5 MB ROM disk with System 7.1. MacsBug loaded fine in my brief testing when booting from ROM, but when I enabled the RAM disk, MacsBug wouldn’t load. The error was something along the lines of “can’t allocate enough memory below BufPtr.” I was running on a IIsi with 17 MB RAM in 32-bit addressing mode. The ROM disk driver allocates a 7.5 MB buffer in high memory, and the traditional minimum value of BufPtr is like 1/2 of the memory size. I would think there would be another megabyte available below BufPtr, less anything else allocated in high memory. So does MacsBug 6.6.3 make a ~1 meg allocation in high memory at boot? I’ll investigate the issue a little more later, but hopefully someone knows something about the memory requirements of MacsBug that’ll explain it. Right now I’ve packaged up all the 8MB SIMMs we have in preparation to send ‘em to testers, so I don’t have one to play with in a system with more RAM like my SE/30 or IIci.
  7. Thanks! What I mean is a little different than what you’re saying though. I’m talking about when an application has a DMA disk card read into an a buffer owned by the app. This buffer will often be in expansion RAM. So for a read operation that moves a disk block from the card into an application's buffer, the data flow will go from the disk card, onto the peripheral bus, through to the fast bus, and then onto the RAM card. This is the situation which needs a bit more testing.
  8. Oops, didn't see the posts on page 4 earlier when I replied... Ooh, I will look into MindExpander, including just personally. Hm yes, I would like to, but BareBones still exists so I will have to ask them. Hopefully they agree. Unfortunately it's still ~600 kB, which is a lot heavier than some of the more basic utilities which may weigh in at just 8-32 kB. But it's worth it to include.
  9. Hi everyone, My friend Garrett Fellers and I design, manufacture, and sell vintage hardware through his Garrett's Workshop brand. One of our products that's been out for a while is our GW4201-series "RAM2GS" RAM expansion card for Apple IIgs. (eBay link: https://www.ebay.com/itm/Apple-IIgs-4-MB-RAM-Expansion-Low-Power-New-2020-Production-GW4201B-/254230319800) We have a new 8MB version of this card in the release-candidate stage and are looking for some testers to make a final pass trying it out before we release the card. In particular we are looking for users with IIgs machines and at least one card which does IIgs-aware DMA. Examples are the MicroDrive Turbo and the Apple High-Speed SCSI card (as differentiated from the "regular" SCSI card). If you have such a card and are interested in trying our new RAM, please let me know. The testing we are interested in basically consists of running GS/OS using the card, copying files to/from a RAM disk, running programs from the RAM disk, etc.--nothing fancy or complicated. If interested, we will send you a card free of charge, which you can of course keep once we're done with testing. Edit: I figured I'd attach a picture of the RAM2GS II as well:
  10. Sorry for my absence--please check your PMs. Yes, it should have been programmed when sent to you, but a mixup could have happened. I am not sure if the programmer can program my ROM SIMM, but it can certainly read it out (if indeed it originally supported that feature). The ROM is here, named rom2M.bin: https://github.com/garrettsworkshop/MacIIROMDiskDriver/tree/dev/bin No unfortunately it's not possible to program them from the host machine. If the dougg3 programmer does not work with the SIMM, it would just be a software issue that can be rectified with an update. I will look into this after we send the 8MB SIMM out since the chips are not socketed on that one. Yeah, I have included AppleTalk on the 7.1 image (for the 8MB ROM) as well as the 6.0.8 image (for the 2MB ROM). I think we have enough testers right now, but we have more gizmos planned in the future so there will be opportunities to test other things. Ooh yes, this is a good idea. I am getting sick of having to transfer stuff between my old Macintoshes and new Macs as binhex files on a FAT-format floppy. Yes, I've been seeing it as a disk tools replacement too but didn't think to articulate it that way. I unfortunately even had to remove TattleTech, sadly, since the latest version comes in at 1.4 MB... too big considering everything else that must fit into the 7.5 MB image. I've got everything you mentioned except the Zip disk drivers and the ethernet drivers. I can include the Iomega Zip disk driver, but there are quite a few manufacturers of ethernet cards and even more card models. Unless someone has some kind of universal driver for all of the adapters with a particular chipset, I don't think ethernet drivers should be included. BMoW's SIMM has compression, so you can evidently get 50% more space, but that requires a lot of RAM to decompress the image into, so we prefer to target ours a little differently and not implement any kind of compression. So unfortunately we're stuck with 7.5 MB. Oh, on a funny note, I just graduated from college in May, and while putting the 8MB ROM disk together, I noticed one of my professors credited in the about screen of Disinfectant! How funny, in the "small world" kind of way--he is in the mathematics department at The Ohio State University, not even in the computer science or EE department. I'm gonna write him a note about it.
  11. The memory manager only moves memory when you make a call to allocate a pointer or handle, or when you call a (toolbox) routine which does the same. Memory never gets moved at interrupt time, so it’s not like you can be going through the code and all of a sudden the memory you were using has moved. And like Mu0n said, if you wanna make a call to allocate memory but don’t want something moved, you lock it with HLock and then the memory manager won’t move it.
  12. Yes, but I think it's better to have 6.0.8 on the 2MB and 7/7.1 on the 8MB. The RAM disk (which of course you don't have to use) requires 7.5MB of RAM on the 8MB SIMM but only 1.5MB on the 2MB, so it's sort of fitting that the 6.0.8 version has a smaller RAM requirement to use the RAM disk. Ooh, but that reminds me, the driver still requires 9.5MB on 6.0.8 because of how the RAM is allocated. (And who has 9.5MB? That basically means 16MB is required.) I've gotta fix this in the driver before shipping. Ooh yes, looks like I made a mistake too... I forgot to add the thickness on both sides. This is perfect as long as they aren't thinning the core of the board. I'm so excited if this solves the problem! I'll try this on the next batch. Okay, I'll try that instead of the Apple one. Mmm yes, good call on Macsbug. Thanks. I think the purpose might be to reassign ADB addresses after startup. If you plug in two devices of the same type in and boot the Mac, they initially have the same device address. The start manager reassigns the address of one of the devices and records this change in the ADB Manager's device table. If you unplug and re-plug the device which has had its address reassigned, its address goes back to default, but the ADB manager doesn't know about this, so the Mac keeps trying to talk to that device using its old address. Of course, hot-swapping is not allowed, but some people do it anyway, and there's the KVM use case as well. I've gotta look into this as well. I wanna choose the software I include carefully. Obviously Apple has demonstrated that they are okay with distributing their abandonware, but I'm weary of companies that currently exist and may become litigious over the inclusion of their abandonware in these kinds of collections. Games are off-limits as well, since they're just as fun as they were back then, so the case for their inclusion being fair use on the basis of low commercial viability is more difficult than for StuffIt, for example. I also think that it's an embarrassment that there isn't an open-source StuffIt clone! Maybe I will start a StuffIt clone project and we can all contribute. Ooh yeah, good point about the read-onlyness. Will do.
  13. Yes, I believe so, but you have to break it up into its own function like so: asm void foo() { ... }
  14. For the record, CodeWarrior 6 works quite well on my unaccelerated SE/30, and I recently used it to develop the control panel for my ROM disk. My impression is that CodeWarrior is basically a THINK C clone but the compiler is a bit more modern. Only issue was that I had to hook up a SCSI CD-ROM drive (which I do not normally use) to install CW6 from a burned CD. THINK C is smaller and will be easier to install if you are using a Floppy Emu or similar, although the CodeWarrior 6 CD includes something like 30 1.44MB floppy images to install the software from floppy disk.
  15. Wow, that’s interesting about the virtual memory manager. I didn’t realize it did that. But what about the need to keep an application’s RAM contiguous? Surely the VMM can’t split an application partition across multiple 1MB chunks—or can it, and then just suffer the resulting fragmentation, as if there was a big nonrelocatable block in the way? See, I don’t think it works this way because this kind of behavior reflects a big change to the memory manager. It’s doubtful that the accelerator vendors would have rewritten the memory manager to do that, and the traditional 68k Mac memory map would only give you 4MB of contiguous RAM before ROM gets in the way, so you still can’t have a 4MB contiguous app partition anyway. In order to get 8MB of contiguous RAM, ROM and the 5380 SCSI chip have to get moved to above 0x800000. Is the ROM all relocatable code? Clearly the boot stuff can be relocated to address 0 after reset, but is everything in ROM relocatable? If so then we could make an accelerator that changes the high-order address bits to move the ROM to 0x800000-8FFFFFF. To be clear, what I mean is that when the 68030 on an accelerator accesses 0x8XXXXX, the accelerator hardware drives the address 0x4XXXXX to the Mac board below. If the ROM really is all relocatable, then all that’s needed is to change the 5380’s address in the same way as the ROM and change the SCSIbase global variable. That would give a hypothetical accelerator with this memory map 8MB of contiguous RAM, which would be a pretty good enhancement for an SE or Plus.
×