Jump to content

Grumps

New Members
  • Content Count

    19
  • Joined

  • Last visited

Community Reputation

5 Neutral

About Grumps

  • Rank
    Space Invader

Profile Information

  • Location
    Reading, UK

Recent Profile Visitors

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

  1. Ah, the aliexpress gamble. Have you had good experience with chips from them? Or anybody else?
  2. OK. If Pokey is in place then the machine doesn't get to the blue screen. Looks like it's time for a new Pokey. And I'm pretty sure PIA is dead(ish) too. Constantly asserts IRQ. Why are there so many dead chips on this board?! Power supply is OK, so I don't know why so much has died.
  3. Yes, there is a pull up. If Pokey and PIA are not inserted, then IRQ is pulled high. Also, I put my new Sally in and there is some progress. First time power on and I got the standard blue screen with a white block cursor. No READY though. Then I tried that diagnostic ROM (link posted earlier). The attached shows the results. But, after a few more power cycles I cannot get the board to boot even a little. Just a flickering screen, but no discernible image.
  4. I have previously tested continuity between IC pins and solder side of the board. This took quite some time. All was OK, so I assume the sockets are too. But in addition I also removed all chips and use Kontakt Chemie 60 to remove any corrosion. If, for example, the PIA has power and ground (which it has), and has a valid RST signal (which it also has), and the other control signals are correct (which they are), then it should not assert IRQ (which it sadly does). All signals have been scoped directly on the PIA's pins. Does anyone know of a ready supply of PIA (or compatible) parts?
  5. I'm not even sure an Antonia board would solve the numerous problems I'm seeing. The more I investigate (which I am enjoying), the more questions/problems I have. E.g. When the system is powered on, immediately IRQ becomes active. No delay. If I remove both the PIA and Pokey, then IRQ is pulled high as it should be. Sally still doesn't read the RST vector from the OSROM though (it gets data bit D1 wrong), but I can see using the scope that D1 is good and proper. According to the PIA datasheet, all registers are cleared when RST - this would mean it should not assert IRQ, but it does. So this means a new PIA (in addition to Sally which is on order). Pokey is not blameless either. Without the PIA present, it looks as if Pokey is doing something bad with IRQ. Not low, nor high, but wobbling about mid-state! And, the whole data bus is continuously pulled up about 0.8V when Pokey is present. How far through boot does it go without a PIA and Pokey present?
  6. Thanks all for you kind offers of help. Update: I re-soldered ALL IC pins and then gave it a good clean using a foaming cleaner designed to remove flux/rosin residue, then a rinse and dry. Screen is still red - as expected really. Then I removed all chips and used Kontakt Chemie 60 on the sockets and IC pins. Waited. And re-tested. Screen still red. So, then I dug out my old (unused for a very long time) HP logic analyzer. Of course I must've put it away in a non-working state as it needed a new fuse. So, I have the analyser looking at the address and data busses, and all of the PAL outputs, and IRQ, and RST. I can see that immediately after a RST (the reset pin going high) that Sally starts to push 3 bytes onto the stack. The stack address is most often 0x14C, but sometimes 0x1FF. It looks like she's not sure what she's doing! Then she reads the RST vector from 0xFFFC/0xFFFD. I can see the correct vector coming from the ROM (I've got a rev02) as address 0xC2AA. Sometimes Sally will start to execute from this address, and sometimes she will execute from address 0xC0A8. This looks like she didn't see data bit 1 correctly from the vector location. She also does 3 more pushes to the stack, then reads the IRQ vector from 0xFFFE/0xFFFF. The IRQ pin is definitely not active. And then sometimes just stops executing, or just goes off into oblivion. It's been quite fun, but also tricky to see exactly what's going on as ANTIC is on the bus regularly reading display stuff I assume. So, if the panel agrees, I'm going to try a new Sally.
  7. I'd like to. I'd also like to try another CPU. But am having difficulty finding spares in UK/EU. I'd also like to try and burn the MMU (PAL/GAL) myself, but my programmer needs an upgrade to do that.
  8. So I've tried both a new OSROM and that ROM based tester. Still only have a red screen. I have checked continuity from the IC pins (directly on the devices) to the solder side of the board, and ALL connections are good. There is obvious corrosion/discoloration of the pins though, so maybe the next step is to replace ALL of the sockets.
  9. Will do. I've downloaded the latest ROM file. Should be able to try later today. Ta.
  10. My PROM programmer doesn't support GALs. I don't know how many chips are bad. All I can tell is that the OSROM reads OK in the programmer. And there is the correct clock from the crystal to GTIA, then from GTIA to ANTIC, and then from ANTIC to 6502. The original old power supply is giving 5.1V and appears smooth using the scope.
  11. Does removing and re-inserting the chips (all of them) clean any corrosion from the pins?
  12. How do I test the MMU? I haven't got another to swap. I do have a scope and the circuits, so can probe around if I know what I should be looking for. Perhaps I should bite the bullet and dig my old logic analyser out and put it on the OSROM and see if the 6502 actually attempts to execute any code. That'd be fun - sort of.
  13. Just a quick update. I took the OS ROM out of the 600XL and read it using the EPROM programmer. The contents verify with the REV02.ROM file I found on the 'net. Whilst this doesn't mean that it 100% working (it may not read at full speed), should I be looking elsewhere for my red screen fault? How far through booting would the machine get if there was bad DRAM?
  14. Thanks. We'll see what happens later tonight. Bit14/pin27 should be connected straight to 5V, according to both the 600XL & 800XL circuits, so it shouldn't toggle. I'll repeat the same 16KB as you suggest to be safe. 200ns+? So I may need to slow the 150ns EEPROM down?
  15. As it turns out all of my EPROMs are not blank, so I've gambled on an AT28C256 EEPROM. The only difference between the 27C128 is that pin 1 is address bit 14 and pin 27 is write_enable. Both of these pins are tied to Vcc on the 600XL, so it should just appear to be a 16k x 8 ROM. My programmer will program the AT28C256 - so fingers crossed.
×
×
  • Create New...