Jump to content

Mu0n

6502
  • Content Count

    180
  • Joined

  • Last visited

Recent Profile Visitors

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

  1. Mu0n

    LCIII battery 'splosion

    I got 4 OTP ICs in the mail (AT27C1024) and burned one of them with the high byte of every word, but I think I have a much larger problem now 1) I wanted to solder legs 11 and 12 of the U36 chip on the back of the logic board but I don't think I have a trace to grab onto. I used a schematic I found but am not 100% certain of where these specific pins lead. Some of them are easy (ground) or go to the big SCSI connector pins and work well. ( I can provide the pdf if you want) 2) I still tried to smoke test it despite that, without a battery replacement and I may or may not have smelled a very slight burning smell (I'm only 30% sure). I hear the disk drive move a little, no bong. 3) I tried plugging in the 2 monitors I have (a small 12 inch monochrome and a 14 inch color), which both power on, but remain pitch black (uh oh). I haven't used these in like 14 years easy. does the LCIII require a pram battery to attempt booting? I don't remember.
  2. Mu0n

    LCIII battery 'splosion

    Your question confuses me even more. How am I supposed to write + verify a replacement chip if it can't read that type of chip? Or are you implying that reading off an old chip is a totally independent thing than the verification step after writing to a new chip? Which begs the question, is the choice of which new chip I can buy and write to extremely narrow or can many choices work?
  3. Mu0n

    LCIII battery 'splosion

    Ok, this is not making me confident. I tried reading off of one of my Lciii Roms (the least damaged one) and I went through all the 40 pin chips supported by the Xgpro software. My first choice was in the ATMEL section, but the software complained that the pins didn't match. I did not make an error with the notch. About 80% of the other choices had the same error. The few models that did allow me to get a read going yielded almost all FFFF bytes, except in a few places where it showed up at FF8F. What am I doing wrong and is this just plain not supported? Has no one reburned lciii Rom chips here?
  4. Mu0n

    LCIII battery 'splosion

    I'm trying to remember the steps. Is that how you load each half of the 1 MB LCIII rom file (2nd and 3rd pull-down menu options)
  5. Mu0n

    LCIII battery 'splosion

    I found this: https://l.facebook.com/l.php?u=https%3A%2F%2Fwww.newark.com%2Fmicrochip%2Fat27c4096-90pu%2Fone-time-programmable-otp-eprom%2Fdp%2F68T4285%3Ffbclid%3DIwAR36vSFRAWv1CFKjT4qBZAbBZDC_VsLyh43BzG6CGHq4IXDUZVbV2KggB9Q&h=AT21QIRd0wPho2SCqDAu5YW33lRXazlHhBq7lJVLorKcUyoUOhNNyTS3OmN3RozDHn5BcEcRxbwgGby_FvCzvGvnnC0Pqlg6hvyMqVEE3C9EFNtQaFSIO13ygERm8YCJuA&__tn__=R]-R&c[0]=AT2V_LZrMcZD0hiZh5qhwtm5uDrG4toQqZeTEAlUhI9vF4No76TRSxT6BFjerPDcGXVUcJCwsXEUU_ltI5X5IgJb4DXd2fLRMsCOp3WYbi5wERi1NIZWEHfWx1n9PoBllwVr7MwWv1YNpY1bDy4fkrhN5-8yfYEX6_sww-GxyPKwFVcfDK7cIs4 but, I don't have an UV EPROM burner. I only have the popular TL866 EEPROM burner everyone has, and a bunch of W27C512-45Z DIP28, which were perfect for a Mac Plus. So one chance at it and pray I didn't mess up the HI and LO separation?
  6. I always tell people to remove batteries ASAP and resist using them ad nauseum. I opened up my LCIII this morning with the goal of seeing if it had these SMT caps that I would replace with tantalums, just like I did for my SE/30 and Mac Classic (yep it does). Lo and behold, the battery had been left in and was exploded. I half-heartedly submerged it in soapy water to see if I would go on wih a restoration or not, so I didn't take before pics. Fortunately, the worst area was near the HD cable (which I wasn't using, this machine had no internal HD) and it went away for the most part with no affected trace in that vicinity. As you can see, the single RAM SIMM has one side with heavy corrosion, but with enough brushing w/ IPA, and then a bit of slow and deliberate nose-plier scratching, I think its leads create a good contact, pin per pin, with its socket. Who knows before booting, right? This is after a first pass with light steel brush. One of the ROM chips has lost one of its legs in the chip socket. I have an EEPROM burner, I've done the whole HI/LO separation with the software for a Mac Plus, but I don't own 40 pins empty EEPROM. Initial searches aren't making me optimist at finding an new IC for this. Any pointers? All in all, the restoration looks doable. The most damaged area (the empty gray socket in the center which I assume is for a math coprocessor?) has a couple of eaten away leads inside it and the HD connector is damaged on the other side of the board - but I wasn't planning on using it anyway. All I need to do is to put in some tantalums and deal with the ROM chip and hope for the best. All in all, if one of my machines had to give up the ghost, it was this one. It's the one I'm least attached to, but it would still be a bummer if I lost it - it's the only old Mac that gives me access to color! I had plans to trade it out eventually though. I can live with emulators for my color access.
  7. I also revisited your mouse code yesterday. What I'm experiencing: -cursor movement is somewhat a little slow during normal operation, but it's ok -when in combat in Archon, mouse scrolling speed has no impact - the game only detects the direction of movement and the characters move to some pre-planned speed according to the game rules -It's very hard to go into purely horizontal or vertical directions with a deadzone of 30. Most of the time, diagonal movement is done and it forces me to fight with these lines of approach and throws away pure horizontals and verticals. Kind of like in real life with a physical mouse, but even worse So, I played around with the code a bit, and did: -push up the minimal movement threshold to 40 instead of 30 -first check that a direction is dominating (dominating threshold of 200) WHILE the other IS NOT dominating to only push for a movement in that solo dominating direction; then check the other with an else if -when no direction is dominating, do what was done initially, which is allow both directions to act at the same time What I get is noticeably better in Archon combat (I'm able to hit those x-only and y-only shots more often), but noticeably worse during normal cursor operation: I get feeble movement whenever both directions are involved. I get slightly faster movement when only one direction is involved. The strangest thing is that I can still get a small movement in the non-dominating direction. // The quadrature phases to output const bool waveform1[] = {HIGH, LOW, LOW, HIGH}; const bool waveform2[] = {HIGH, HIGH, LOW, LOW}; const int doNothingTolerance = 40; //no movement if you don't reach this miminal threshold const int pureDirectionTolerance = 200; //if a direction has that, but the other doesn't, lock it in the direction that has it int xGPIOs[] = {6, 5}; int yGPIOs[] = {4, 3}; const int xAnalogue = 3; const int yAnalogue = 2; const int clickOutGPIO = 10; const int clickInGPIO = 11; // Two digital outputs set permanently to high and low, respectively, to reference // the variable resistors with const int hiRefGPIO = 13; const int loRefGPIO = 12; // the timestamps (in milliseconds) when the axis last was updated unsigned long xTimestamp = 0; unsigned long yTimestamp = 0; // the indexes into the waveforms int xIdx = 0; int yIdx = 0; int xIsStill() { return analogueValueIsStill(analogRead(xAnalogue)); } int yIsStill() { return analogueValueIsStill(analogRead(yAnalogue)); } long xDelay() { return analogueValueToDelay(analogRead(xAnalogue)); } long yDelay() { return analogueValueToDelay(analogRead(yAnalogue)); } int xDirection() { return analogueValueToDirection(analogRead(xAnalogue)); } int yDirection() { return analogueValueToDirection(analogRead(yAnalogue)); } int xShouldAdvance() { unsigned long now = millis(); // if the joystick is in the "still" region, don't update if (xIsStill()) { return 0; } if ((xTimestamp + xDelay()) < now) { xTimestamp = now; return 1; } else { return 0; } } int yShouldAdvance() { unsigned long now = millis(); // if the joystick is in the "still" region, don't update if (yIsStill()) { return 0; } if ((yTimestamp + yDelay()) < now) { yTimestamp = now; return 1; } else { return 0; } } int xIsWellEstablished() { unsigned long now = millis(); // if the joystick is in the "dominating" region if (analogueValueIsDominating(analogRead(xAnalogue))) { return 1; } } int yIsWellEstablished() { unsigned long now = millis(); // if the joystick is in the "dominating" region if (analogueValueIsDominating(analogRead(yAnalogue))) { return 1; } } void dealWithButton() { int btn = digitalRead(clickInGPIO); digitalWrite(clickOutGPIO, btn); } int analogueValueIsStill(int value) { if (value > (512 + doNothingTolerance)) { return 0; } if (value < (512 - doNothingTolerance)) { return 0; } return 1; } int analogueValueIsDominating(int value) { if (value > (512 + pureDirectionTolerance)) { return 1; } if (value < (512 - pureDirectionTolerance)) { return 1; } return 0; } int analogueValueToMagnitude(int value) { return abs(value - 512); } int analogueValueToDirection(int value) { if (value < 512) { return -1; } return 1; } long analogueValueToDelay(int value) { const long minDelay = 4; long mag = analogueValueToMagnitude(value); return ((512 - mag) / 32) + minDelay; } void writeQuadrature(int gpios[], int idx) { digitalWrite(gpios[0], waveform1[idx % 4]); digitalWrite(gpios[1], waveform2[idx % 4]); } void setup() { Serial.begin(9600); // set up quadrature outputs pinMode(xGPIOs[0], OUTPUT); pinMode(xGPIOs[1], OUTPUT); pinMode(yGPIOs[0], OUTPUT); pinMode(yGPIOs[1], OUTPUT); pinMode(clickInGPIO, INPUT_PULLUP); pinMode(clickOutGPIO, OUTPUT); pinMode(hiRefGPIO, OUTPUT); digitalWrite(hiRefGPIO, HIGH); pinMode(loRefGPIO, OUTPUT); digitalWrite(loRefGPIO, LOW); digitalWrite(xGPIOs[0], HIGH); digitalWrite(xGPIOs[1], HIGH); digitalWrite(yGPIOs[0], HIGH); digitalWrite(yGPIOs[1], HIGH); digitalWrite(clickOutGPIO, HIGH); Serial.print("initialised...\n"); } void loop() { dealWithButton(); //clear cut x movement only if (xShouldAdvance() && xIsWellEstablished() && !yIsWellEstablished()) { xIdx = (xIdx + xDirection()) % 4; if (xIdx < 0) { xIdx += 4; } writeQuadrature(xGPIOs, xIdx); return; } //clear cut y movement only else if (yShouldAdvance() && yIsWellEstablished() && !xIsWellEstablished()) { yIdx = (yIdx + yDirection()) % 4; if (yIdx < 0) { yIdx += 4; } writeQuadrature(yGPIOs, yIdx); return; } //weak x if(xShouldAdvance()) { xIdx = (xIdx + xDirection()) % 4; if (xIdx < 0) { xIdx += 4; } writeQuadrature(xGPIOs, xIdx); } //weak y if(yShouldAdvance()) { yIdx = (yIdx + yDirection()) % 4; if (yIdx < 0) { yIdx += 4; } writeQuadrature(yGPIOs, yIdx); } // DEBUG: //Serial.print("x: "); //Serial.print(analogRead(xAnalogue)); //Serial.print("y: "); //Serial.print(analogRead(yAnalogue)); //Serial.print("button: "); //Serial.print(digitalRead(clickInGPIO)); //Serial.print("\n"); }
  8. Moving on to the next gamepad that would use the 4C4P RJ11 cable, replacing a keyboard. I've quoted the appropriate section of Inside Macintosh but I'm at a loss of how to make it work in Arduino. I admit I don't know that much about the arduino architecture. -I imagine I need to use digital pins and not analog pins, since I only need to create 5V pulses to create the bits. -at 9600 bps, we get 104 microseconds at the smallest unit of change, but we need control over creating data pulses that happen 40 microseconds before the clock pulse ticks, so I must use a faster speed? -so far, all the arduino code I've seen configures GPIO pins as either WRITE or READ. But Inside Macintosh clearly says the data wire needs to be able to send and receive both according to its unique specific protocol. How do I set this up in Arduino? I found this website that sheds some light on setting up communications with another board (outside of the arduino ecosystem), but it looks pretty similar: http://www.synack.net/~bbraun/mackbd/index.html
  9. I should be getting my DB9 cable today, as well as some very needed heat srink cable tubes.
  10. First iteration's problems: -stick is a smidge too high and will cause friction with the opening's edges -the cylinder riser pins broke very early and just can't be used, and the risers themselves broke off after minimal lateral force -the cable hole was too small -I think the back and front cable holes could just be improved if the middle separation goes to their centers -the arduino's placement is just bad in the dead center, it creates too many problems during assembly with the cables I have. -I need to find a way to create one 4-way node and one 5-way node. I don't have those simple through-hole breadboards, so....solder wires "in the air"? Link towards revised version: -fat cylinders for screws -"cradle" + glue approach instead of risers to hold the pcbs -arduino on the side instead of center https://a360.co/2X7DvxZ
  11. I'm about to send my STL file to a friend so he can start the 3d printing for me. Check it out: assembly with 4 screws. I'm hoping the holes are big enough for the button and stick. in-browser model viewer: https://a360.co/2X7DvxZ Side analysis:
  12. Got my stuff (except the DB-9 cable) and a prototype is working! The caption for this video is: "Confinement Day 75"
  13. This is my first Fusion360 project so I'm FOR SURE, overthinking a few things in it. Here are my steps and wants: -Added an image of the Arduino micro 5V I ordered (order still en route) where I tried using the website's image provided in a shot that also had an american quarter, so I deduced the dimensions as best I could -The general size of the controller is very slightly smaller than an xbox360 controller and it's pretty silly since it'll have the one button -the button hole on the right is only temporarily sized, I have no idea yet which of the button types I'll be using -same for the stick hole, I'm waiting to receive my analog sticks to decide how large to make it -I have 3 little "walls" to prevent the board to wiggle out. I made such little gaps around it and I'm thinking about giving it more space but I have no experience on how much is enough and how much is too much -the arduino board gives 3 mounting holes which I made little riser posts for it (still need to do a larger part of the post undernearth the board). -the hole in the back will attempt to be of the proper size for some cable securing nut-thing I got off digikey -hole in front for the micro-usb connector that comes with the board, I'm only guesstimating the size right now -one of the last steps I'll do is to split the top and bottom half of this thing so that they can be printed separately so that I can properly assemble it anyway. -dunno which button I'll use, I need to have them in hand to decide based on ClickFeel -I might be forced to get rid of the concave aspect of the outer shell underneath it, because it would just be too hard to 3d Print. It's a bummer, unless some of you have an idea You can check out and move around the model with this public link: https://a360.co/2X7DvxZ Parts ordered status: -10x small clicky buttons from Amazon (received): https://www.amazon.ca/-/fr/gp/product/B07FKB6648/ -3x Adafruit 5V Trinket 16 Mhz from BuyaPi.ca (en route): https://www.buyapi.ca/product/adafruit-pro-trinket-5v-16mhz/ -3x Analog sticks (en route) from BuyaPi.ca: https://www.buyapi.ca/product/analog-2-axis-thumb-joystick-with-select-button/ -1x 16 mm illuminated green button from BuyaPi.ca (en route): https://www.buyapi.ca/product/16mm-illuminated-pushbutton-green-momentary/ -1x ?? mm red button (en route) from BuyaPi.ca: https://www.buyapi.ca/product/3a-125v-momentary-push-button-switch/ -2x cable glands (received) from DigiKey: https://www.digikey.ca/en/products/detail/bud-industries/IPG-2227/5291485 -2x DB-9 cables (en route) from monoprice: https://www.monoprice.com/product?c_id=301&cp_id=30112&cs_id=3011201&p_id=442&seq=1&format=2
  14. Mu0n

    twenty one pilots - level of concern - new lyric video

    Was about to post this if it wasn't already. Love the video! The disk swapping part is so just for show and accomplishes nothing
  15. Still waiting for my parts, but I started some progress with my ATMega arduino board and checking out your mouse code. I believe the only difference I needed for the Plus is to reverse the boolean on the mouse click output. You used a pullup input and it was constantly trying to eject the disk drive when I first plugged it in. Reversing it did the trick.
×