I may need some help getting this 664 back on it's feet. I was lured in by the colour of the keys.
Cpc664 case.jpg
But inside is a different story.
20221218_202444~2.jpg
And yes, this ROM is dead.
But the Z80 and Gate Array are alive, tested in a 6128.
So at the moment I have bus activity M1, CLK, MREQ, Address etc but a black screen.
I have nothing on VSYNC of the CRTC. In fact nothing much on any pin. CLK is ok.
Crtc.jpg
So I am thinking dead CRTC and maybe ROM.
But look at the PÇB. Does not look good.
Any advice greatly appreciated.
start with cleaning the board down!... give it a good wash even if ya have to wash it under a tap!.. just make sure its perfectly dry before booting it back up!..maybe even use some IPA to displace the water under chips etc...
next try the rom...try the one from ya 6128...
...see if you get anything on the data and address lines at the z80....
check the V and H sync coming from CRTC... (check it going into gate array aswell)
CLK working suggests that the gate array is still ok...but it could also be causing black screen (as the RGB signals are generated from it)
if you have a eeprom burner.. you may want to burn the Amstrad Diagnostics and drop it in the rom socket and boot from it
Quote from: WacKEDmaN on 22:40, 20 December 22start with cleaning the board down!... give it a good wash even if ya have to wash it under a tap!.. just make sure its perfectly dry before booting it back up!..maybe even use some IPA to displace the water under chips etc...
next try the rom...try the one from ya 6128...
...see if you get anything on the data and address lines at the z80....
check the V and H sync coming from CRTC... (check it going into gate array aswell)
CLK working suggests that the gate array is still ok...but it could also be causing black screen (as the RGB signals are generated from it)
if you have a eeprom burner.. you may want to burn the Amstrad Diagnostics and drop it in the rom socket and boot from it
Thanks, board cleaned with ÌPA. Gate Array works in 6128 so should be ok.
But will the CRTC Still generate VSYNC even if the ŔÒM is dead?
Will desolder the ROM, socket and try the lower diagnostics ROM first. I guess given the state of the board that other things will be wrong but encouraged by the fact that the z80 and Gate Array work.
dont quote me...but i dont think CRTC works right without the ROM working as it setups up the required registers for the CRTC that are stored in the ROM... maybe
@Bryce can confirm?..
try the lower rom diagnostics..if you dont get any display id look at replacing the CRTC...
Hi Rabs,
yes, to everything WacKEDmaN just said and yes, the CRTC will only setup properly if you have a working ROM and CPU.
Bryce.
Quote from: Bryce on 08:18, 21 December 22Hi Rabs,
yes, to everything WacKEDmaN just said and yes, the CRTC will only setup properly if you have a working ROM and CPU.
Bryce.
thanks Bryce....
yay i got something right for once! LOL
Quote from: Bryce on 08:18, 21 December 22Hi Rabs,
yes, to everything WacKEDmaN just said and yes, the CRTC will only setup properly if you have a working ROM and CPU.
Bryce.
Thanks for that.
I am a bit concerned about the oxidisation (or what looks like) under the solder mask and the rust on some of the pins but guess there is nothing I can do about that. I will trace some tracks and check for continuity.
Oxidisation.jpg
Yes, that's a little worrying. You need to remove some of the solder mask and see how bad it is.
Bryce.
was that 664 found in a swamp?
Quote from: eto on 14:31, 21 December 22was that 664 found in a swamp?
You would think so looking at the pcb but it is alive. Drawing about 0.8A for the pcb alone, so no shorts but probably not everything is running. The fact that the z80 and Gate Array have survived whatever happened is a good sign.
Quote from: Bryce on 14:11, 21 December 22Yes, that's a little worrying. You need to remove some of the solder mask and see how bad it is.
Bryce.
Thanks I think it may be OK. Removed a bit of ground plane and it looks to be mainly in the mask. The copper underneath looks clean.
SolderMask.jpg
So ROM out and socketed but stuck for now as I dont have any 27C256 compatible EPROMS only 28C256 EEPROMS.
Tried to read the original rom using my TL866-II, selecting a 27C256 device and un-ticking Check ID, which I guess should work? But pin detect error.
Some progress while I wait for an EPROM.
I found a couple of broken data tracks around the CRTC and put a temp fix in place.
I connected an external ROM card with the Lower Diagrom and now I hear one high beep then after a pause 3 low beeps.
What does this mean?
Still no activity on the CRTC sync pins.
the first beep is start of ram test.. the 3 beeps is bad ram..
you should be getting some display..i guess the CRTC is toast if its not putting out syncs...
Quote from: WacKEDmaN on 03:03, 24 December 22the first beep is start of ram test.. the 3 beeps is bad ram..
you should be getting some display..i guess the CRTC is toast if its not putting out syncs...
Thanks, guessed as much. But think this also means the ROM code is running, which means that most of the tracks are ok and because I can hear the beep, the PIO and AY are OK, which is good news. Also as you indicated, if the ROM code is running and setting up the CRTC, then with no pin activity it must be dead. I will double check ÇS etc but think it needs replacing.
Quote from: WacKEDmaN on 03:03, 24 December 22the first beep is start of ram test.. the 3 beeps is bad ram..
you should be getting some display..i guess the CRTC is toast if its not putting out syncs...
It's more likely that there are more broken traces, rather than broken IC's. I wouldn't start changing any IC's until I'd done an awful lot of continuity checking.
Bryce.
Quote from: Bryce on 12:19, 24 December 22Quote from: WacKEDmaN on 03:03, 24 December 22the first beep is start of ram test.. the 3 beeps is bad ram..
you should be getting some display..i guess the CRTC is toast if its not putting out syncs...
It's more likely that there are more broken traces, rather than broken IC's. I wouldn't start changing any IC's until I'd done an awful lot of continuity checking.
Bryce.
Thanks, I will double check and scope all the inputs. I can't see any breaks on the traces I found but don't know what damage has been done under the resist. Are the vias a potential breakdown point?
Vias are no more or less likely to have an issue, but unfortunately traces UNDER IC's are more likely to have issues because they have the potential to trap moisture and dry slower than exposed areas.
How do I know? Because I was mad enough to do this: https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/hardcore-floppy-drive-restoration/
Bryce.
Quote from: Bryce on 15:03, 24 December 22Vias are no more or less likely to have an issue, but unfortunately traces UNDER IC's are more likely to have issues because they have the potential to trap moisture and dry slower than exposed areas.
How do I know? Because I was mad enough to do this: https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/hardcore-floppy-drive-restoration/
Bryce.
I am impressed.
Some progress, CRTC replaced, traces fixed and now I have a display. Looks like RAM passes but DIAG jumps to ROM test, not sure why. Anyway will attach a keyboard next.
20221231_164342~2.jpg
Diag always runs a ROM test on the startup. ..
For obvious reasons if you have the DIAG rom in there, there will be no system rom and no basic ROM.
To be able to test both, you would need to put the DIAG rom in an external ROM module (as an upper ROM or as a lower rom replacement with disablement to test the normal OS and Basic ROMs.
So on with keyboard, stripped, cleaned and membrane replaced with a new one. But some keys still do not work.
I think the problem is the contact pads because I am seeing a higher resistance across the bad keys, about 1.5k, but only 300 for a good key.
I have cleaned the pads with isoprop and some have recovered but struggling with the rest. Any suggestions?
20230106_075205~2.jpg
Forgot to say, testing the keyboard in a known working 664, so either the keys or the membrane and the membrane is new.
Resolved, I took a very very sharp scalpel and very very carefully scrapped the top of the contact pads. All keys are now working, some a bit sticky so may have to go over them again but maybe later, need to get back on with the pcb and connect the keyboard to see if it works.
Looking at the first pictures... :o :o :o
I will never understand how people can treat computers so mean, and especially such a blue keyed beauty! Persons doing that should be put in jail for sure! :-[
But it's great to see that you got this 664 up and running again! :) :) :) :) :) :) :) :) :) :) :) :)
Quote from: GUNHED on 16:40, 06 January 23Looking at the first pictures... :o :o :o
I will never understand how people can treat computers so mean, and especially such a blue keyed beauty! Persons doing that should be put in jail for sure! :-[
But it's great to see that you got this 664 up and running again! :) :) :) :) :) :) :) :) :) :) :) :)
Yes , this one is in a bad way and not quite up and running yet!
When I run the keyboard diag test, the keyboard picture quickly flashes on the screen and looks like some keys have been pressed before it closes as failed.
When I run with the OS and BASIC ROM, it starts up but all I get is the standard banner before it resets, and this is with or without a keyboard. So no BASIC prompt.
20230106_194026.jpg
Given the state of the PCB and the failed CRTC, I suspect more track problems and possibly a chip issue around the PIO or AY.
Can't rule out my OS and BASIC ROM yet, as I programmed it but think it is OK. I am also surprised no RAM has failed but the RAM test passes.
This is going to be a long job :).
If I am not mistaken, then at this point the ROMs are initialized. So maybe the Amsdos Rom fails.
Quote from: eto on 23:00, 06 January 23If I am not mistaken, then at this point the ROMs are initialized. So maybe the Amsdos Rom fails.
Ah that will be because I have removed it :). Completely fogot about that thanks.
That should not be a problem. If you remove the AMSDOS ROM it is simply not there. You should still see the Basic 1.1 message and the ready prompt. You just will not have disk working without AMSDOS.
AMSDOS istself does not output any message.
Quote from: SerErris on 00:22, 07 January 23That should not be a problem. If you remove the AMSDOS ROM it is simply not there. You should still see the Basic 1.1 message and the ready prompt. You just will not have disk working without AMSDOS.
AMSDOS istself does not output any message.
Thanks.
I am going to assume I created the OS + BASIC ROM correctly (I took the 664 16K OS and BASIC ROMs to create a 32K ROM) and concentrate on why the DIAG ROM keyboard test fails. By the way the original ROM is dead.
So could be more track problems. Possible as I have already found broken tracks in this area of the PCB.
Could be the PIO, AY or 74LS145 ICs.
I will start with the tracks but will need to change the battery in my multimeter at this rate.
The state of AY chip is concerning me though.20230107_071023~2.jpg
None of that will stop the CPC to get the computer to the Ready prompt.
If the AY, PIO or LS145 does not work, then you have no (no correct) keyboard input. But you will still see the ready prompt.
The Basic init routine until the Ready prompt should not even read the keyboard. So it probably will only fail after the Ready Prompt with strange characters showing up, or keys not working.
If you get the no Basic prompt it might be, you do not have the correct Basic paired with the correct OS.
You need this OS:
https://www.cpcwiki.eu/imgs/4/4b/OS_664.zip
And you need this Basic
https://www.cpcwiki.eu/imgs/1/10/BASIC_664.zip
Also to test this combination, please pull the AMSDOS rom to ensure, that the init process does not hang at a not working AMSDOS rom.
You can join the files either with a hexeditor or with the EEPROM programmer software also if you have the unpacked roms you could also join them with the good old DOS copy command...
It looks like that you do not reach the INIT part of the BASIC rom. Otherwise you should be the BASIC 1.1 message ... (or any other BASIC message). That could be a lot of reasons.
Again if the AMSDOS is in its socket, it could mean, that it does not work properly, but good enough to get recognized by the ROM init routine and then stuck in it.
Or it could be that the upper rom selection does not work properly ... That could also be a lot of things. Very difficult to troubleshoot from remote.
But I agree that your traces all look pretty bad and the legs of the AY-3-8912 are also very corroded. That still does not need to mean to much, but as the keyboard test in diagrom does not work properly .. that is a good indicator that it is not stable (at least).
Quote from: SerErris on 10:30, 07 January 23None of that will stop the CPC to get the computer to the Ready prompt.
If the AY, PIO or LS145 does not work, then you have no (no correct) keyboard input. But you will still see the ready prompt.
The Basic init routine until the Ready prompt should not even read the keyboard. So it probably will only fail after the Ready Prompt with strange characters showing up, or keys not working.
If you get the no Basic prompt it might be, you do not have the correct Basic paired with the correct OS.
You need this OS:
https://www.cpcwiki.eu/imgs/4/4b/OS_664.zip
And you need this Basic
https://www.cpcwiki.eu/imgs/1/10/BASIC_664.zip
Also to test this combination, please pull the AMSDOS rom to ensure, that the init process does not hang at a not working AMSDOS rom.
You can join the files either with a hexeditor or with the EEPROM programmer software also if you have the unpacked roms you could also join them with the good old DOS copy command...
It looks like that you do not reach the INIT part of the BASIC rom. Otherwise you should be the BASIC 1.1 message ... (or any other BASIC message). That could be a lot of reasons.
Again if the AMSDOS is in its socket, it could mean, that it does not work properly, but good enough to get recognized by the ROM init routine and then stuck in it.
Or it could be that the upper rom selection does not work properly ... That could also be a lot of things. Very difficult to troubleshoot from remote.
But I agree that your traces all look pretty bad and the legs of the AY-3-8912 are also very corroded. That still does not need to mean to much, but as the keyboard test in diagrom does not work properly .. that is a good indicator that it is not stable (at least).
Thanks, I took both the 664 OS and BASIC ROMS from the Wiki as indicated and used a DOS command to join (
copy file1/b+file2/b file3/b), which has always worked before. But will retrace my steps and check,The ÀMSDOS ROM was removed during my tests, the original ROM was dead. One other thing the banner is displayed for a few seconds and then looks like it resets and displays again (this repeats).Ì have never seen the ĎIAG ROM Keyboard Test behave at it does. The keyboard flashes up on the screen looks like some keys are highlighted and quickly closes. I can only imagine it thinks it is getting keyboard input to close.
OK, so I have found no further track problems.
I have checked the Disk Controller CS, RD and associated logic signals, just in case for some reason this was accessing the bus and messing things up but looks ok (as far as I can tell). By the way I have removed the AMSDOS ROM.
So I turned by attention back to the DIAG ROM Keyboard test and why this fails.
I started to check the data signals between the AY and PIO and saw something odd.
I compared this with my working 664 and it looks completely different.
So this test is without a keyboard attached and I get the same results with the DIAG ROM and the OS+BASIC ROM.
D2 (PIN 26) on the AY has a completely different cycle to all the other data pins.
Here is D2
BAD PIN 2.JPG
And the other pins.
BAD PIN 1.JPG
Now compare this with my working 664.
Good PIN 1.JPG
D2 comes from PIO Pin2 A2 - so the address bit. You are right, this looks like the cycle time is not correct (on time to short) and therefore it might happen that the AY ist not fast enough to dedect the change or read a stable value.
So if that would happen, the Dataword to AY would be wrong, and also that could mean, that the programming of the IO port will never work. And if that happens, you will never get any result from the keyboard.
Read is not critical for this process, but I would assume that also read would not work.
So PIO might be damaged, or still the lines between PIO and AY. Did you measure the continuity between A2 and D2? What was that result?
Quote from: SerErris on 13:06, 09 January 23D2 comes from PIO Pin2 A2 - so the address bit. You are right, this looks like the cycle time is not correct (on time to short) and therefore it might happen that the AY ist not fast enough to dedect the change or read a stable value.
So if that would happen, the Dataword to AY would be wrong, and also that could mean, that the programming of the IO port will never work. And if that happens, you will never get any result from the keyboard.
Read is not critical for this process, but I would assume that also read would not work.
So PIO might be damaged, or still the lines between PIO and AY. Did you measure the continuity between A2 and D2? What was that result?
Thanks for the help. Checked all direct connections and basically all 0 ohms. I can see the keyboard scan on port C of the PIO and and input to the 74LS145 but no output as I expect given this is open collector and more importantly no keyboard. What confused me is why I see what I see from the AY with no keyboard connected. Hence my current guess is an AY issue. AY has now been socketed and sourcing a replacement. Do you know if you should get a BASIC prompt with no AY? I don't.
Let me check the basic rom for that.
Okay checked the startupprocedure one 464, but that is actually the same on the 664. The code is slightly different, but the major things are the same.
That is how the init process on the 464 works:
Boot Sequence of the Amstrad CPC (classic)
1. Hardware initialization
- On powerup the reset circuit creates a reset signal that initializes the GateArray as well as the CPU.
- After initialization, the GateArray has mapped both ROMs in (LRom and URom enabled).
- Also the Sequencer in the GateArray is getting initialized and starting all the control signals for the CPC
- For details on the GateArray please see the great work of Gerald from cpcwiki.eu and his great schematic on it https://github.com/MiSTer-devel/Amstrad_MiSTer/blob/master/rtl/GA40010/40010-simplified_V03.pdf
2. CPU starts to execute at address &0000 which is the ROM as the GA is showing both ROMs at this point in time.
3. ROM Init
- Setup ROMs (L ROM enabled, U ROM disabled)
- Initialize PIO
- PortA 00
- PortC 00
- Initialize Printer
- Initialize the CRTC (with 50 or 60 hz settings)
here all registers of the CRTC are getting written with system defaults from tables in the ROM
- choose Upper ROM 00 (NOT activate)
- Clear memory from &B1000 to &B8FF (variable space)
- Set Stack start to &C000
- copy Hi Kernel Jump
- generate Jump block
- Keyboardmanager init
- Sound Reset
- Screen Init
- Txt Init
- Graphics Init
- CAS Init
- Printer Reset
- Output System Message to screen (64 K Microcomputer ... )
- Set Stack Start &C000 (reset stack)
- Start Basic (URom 00 address &C006 via RST#18)
4. Start Basic
- Reset Stackpointer &C000
- Initialize all Upper ROMs from 07 to 00 (464/6128 0F to 00)
- Initialize BASIC RAM Pointers
- Initialize User Vector Table with &C9 (RET) &1B bytes
- Output BASIC 1.1 Message
So you are actually anywhere stuck in between Initialize Upper ROMs and the BASIC 1.1 Message.
Essentially you passed the System Message, which happend after all the initialization of Sound Manager / Keyboard Manager and so on, and the System Message is the last thing that happens before you start BASIC.
The ROM initialization for the URoms is actually happening within the BASIC ROM, not within the System ROM. That is something new for me I learned.
So for me - it looks like it fails in the AMSDOS ROM or if that is not present, then it fails during the ROM init process, where it actually missinterprets a ROM to be present, starting it and then failing, as there is no ROM or you are getting into a BASIC endless loop (you initializing BASIC over and over again, but with no success as you never fully initialize it). It actually loops right at the first step - initialize Upper ROMs.
I am not sure if that is really where it hangs, but it is within BASIC code. And nothing I have seen in this part in the BASIC initialization code is actually depending on the OS. So any of the BASICs would run thus far.
Are you able to create the following EPROM:
Lower = DiagROM Upper = Basic 1.1 from CPC664 ?
Can you please check if DiagROM can actually see the BASIC ROM and generates the correct checksum?
Also, can you please remove the AY ? I am not sure if it is socketed.
Also potentially bad would be if the pullups within the AY do not work. I am not sure if the 664 board has external pullups. If they would have been failed, it would give a permanent output from the keyboard as the line would be low or even worse floating and the AY would interpret the state randomly - giving random input signals to the CPC.
Unfortunately there is nothing to measure here as the pullups are internal and you cannot measure it on the outside of the pins.
A logic analyzer would help to understand what the AY is outputting to the PIO - so to identify if we have a PIO issue or a AY issue. Or none of that.
Quote from: SerErris on 14:33, 13 January 23The ROM initialization for the URoms is actually happening within the BASIC ROM, not within the System ROM. That is something new for me I learned.
So for me - it looks like it fails in the AMSDOS ROM or if that is not present, then it fails during the ROM init process, where it actually missinterprets a ROM to be present, starting it and then failing, as
Interesting. I didn't know that either.
Quote from: SerErris on 14:33, 13 January 23I am not sure if that is really where it hangs, but it is within BASIC code.
Couldn't it also be that the BASIC ROM is simply faulty? The screen message is printed by the firmware and if the handover to the BASIC ROM fails it would also be stuck at that point, right?
Yes, that could also be. For instance - if PIN 14 would not either not get a high signal (always low) or the ROM is broken (PIN 14 internally stuck to low), then you would also never see the basic vector and that also could explain the reset.
You would jump into the Firmware ROM at address 0006 instead to C006.
I simulated that in Winape ... so I made both Lower and Upper ROM 0 the 664ROM (actually lower), and yes it crashes over and over again ...
What happens?
The ROM jumps into the BASIC ROM (which does not exists), the code there by chance does a jump to DE, which evtl. points into 2100ish address and as the Lower rom has been disabled it is RAM .. so lots of NOPs ... and then it gets into the jump blocks again and by chance get to a RET code. At this point in time the stack points to bytes that holds the RET address as 0000 and that is when the reset happens.
So it looks like you have a problem to enable the upper ROM.
Looking at the schematic it seems that nothing is in between the CPU and the ROM. So you can check with your oscilloscope if you see Pin27 of the ROM anytime going to high state. Also you can check continuity and resistance between CPU A14 (PIN4) and ROM A14 (PIN27).
Another thing coming to my mind ... I am not sure how that should be set ... on the 664 I think PIN 1 is not connected. That makes it floating and EPROMS may behave strange with that, as this is
@gerald, can you look at this last question, as I am not sure what the correct handling of PIN1 for an EPROM would be.
@Rabs what eprom type are you using?
Another thing: Have you tried to reread the EPROM you have created? Is that actually giving you the correct output you expected in the Programmer view?
Quote from: SerErris on 16:35, 13 January 23Yes, that could also be. For instance - if PIN 14 would not either not get a high signal (always low) or the ROM is broken (PIN 14 internally stuck to low), then you would also never see the basic vector and that also could explain the reset.
You would jump into the Firmware ROM at address 0006 instead to C006.
I simulated that in Winape ... so I made both Lower and Upper ROM 0 the 664ROM (actually lower), and yes it crashes over and over again ...
What happens?
The ROM jumps into the BASIC ROM (which does not exists), the code there by chance does a jump to DE, which evtl. points into 2100ish address and as the Lower rom has been disabled it is RAM .. so lots of NOPs ... and then it gets into the jump blocks again and by chance get to a RET code. At this point in time the stack points to bytes that holds the RET address as 0000 and that is when the reset happens.
So it looks like you have a problem to enable the upper ROM.
Looking at the schematic it seems that nothing is in between the CPU and the ROM. So you can check with your oscilloscope if you see Pin27 of the ROM anytime going to high state. Also you can check continuity and resistance between CPU A14 (PIN4) and ROM A14 (PIN27).
Another thing coming to my mind ... I am not sure how that should be set ... on the 664 I think PIN 1 is not connected. That makes it floating and EPROMS may behave strange with that, as this is
@gerald, can you look at this last question, as I am not sure what the correct handling of PIN1 for an EPROM would be.
@Rabs what eprom type are you using?
Another thing: Have you tried to reread the EPROM you have created? Is that actually giving you the correct output you expected in the Programmer view?
Thanks Very Much. Starting to make sense I think. :)
Created a new ROM with DIAG + BASIC (good idea thanks).
Start of BASIC looks ok when I read it.
DIAG+BASIC.JPG
ROM is AM27256DC
Test with;
No AMSDOS ROM (i.e. removed)
No AY (i.e. removed)
DIAG + BASIC ROM
DIAG RAM test runs, passes and the main screen is presented. Note the diagnostic program does not recognize the type of CPC. I guess it is looking at the BASIC ROM to do this? And hence I guess it cannot see the BASIC ROM. Clue here? The odd thing is the RAM test then runs again, just like it resets, just like the OS + BASIC ROM.
Will look at the A14 on my scope.
Thanks again.
No the Diag ROM is looking at the OS ROM to identify what it is. As this is the DIAG rom now, it cannot. It would work if you put the DIAG ROM in a M4 Module from Duke or into a Dandanator, as both can disable the Diag rom via Software.
With an EPROM it does not work that way and you always will not be able to see the machine type.
However you should see in ROM scan the BASIC ROM now. What does the ROM page show?
Quote from: SerErris on 17:23, 13 January 23No the Diag ROM is looking at the OS ROM to identify what it is. As this is the DIAG rom now, it cannot. It would work if you put the DIAG ROM in a M4 Module from Duke or into a Dandanator, as both can disable the Diag rom via Software.
With an EPROM it does not work that way and you always will not be able to see the machine type.
However you should see in ROM scan the BASIC ROM now. What does the ROM page show?
Of course, that makes sense....But no AY at the moment, so can't select the ROM test.
Hmm ... that is ugly. But you can put back the other EPROM and monitor A14 on the ROM and check if it every gets high.
Also what does continuity test between CPU A14 and ROM A14 say?
Maybe you have just a broken line here or a high impedance bringing the voltage out of the TTL levels for high.
Or reconnect the keyboard and AY.
Quote from: SerErris on 17:30, 13 January 23Hmm ... that is ugly. But you can put back the other EPROM and monitor A14 on the ROM and check if it every gets high.
Also what does continuity test between CPU A14 and ROM A14 say?
Maybe you have just a broken line here or a high impedance bringing the voltage out of the TTL levels for high.
With the AY in it runs the RAM test then runs the ROM SCAN (the original problem) and ... all ROMS are EMPTY. Let me look at A14.
If all ROMS are empty (BASIC ROM as well) you definately have a problem from A14 reaching the ROMs (both AMSDOS and BASIC). However if AMSDOS is not in yet, then this is normal and you should see in every slot "BASIC 1.1" as this is what the CPU seas when nothing else is in the system.
Oh looking at your screenshots again - EMPTY is not the normal message for "no ROM".
No rom means, it detects the normal basic ROM.
in Slot 00 you would expect BASIC
In Slot 01 you would expect ----
EMPTY means something is there, but at the address that is supposed to have the name, there is a 00 string and the checksum of the ROM is also FFF0 ... (I am not sure how the checksum is calculated here).
So something is seen here and it is not the same as the lower ROM. As I do think that the checksum of the diagrom is not FFF0 (that is I am not sure about it). (I confirmed it in my 6128 putting the lower rom into upper rom slot 4 and yes the checksum is different).
Quote from: SerErris on 17:47, 13 January 23Oh looking at your screenshots again - EMPTY is not the normal message for "no ROM".
No rom means, it detects the normal basic ROM.
in Slot 00 you would expect BASIC
In Slot 01 you would expect ----
EMPTY means something is there, but at the address that is supposed to have the name, there is a 00 string and the checksum of the ROM is also FFF0 ... (I am not sure how the checksum is calculated here).
So something is seen here and it is not the same as the lower ROM. As I do think that the checksum of the diagrom is not FFF0 (that is I am not sure about it). (I confirmed it in my 6128 putting the lower rom into upper rom slot 4 and yes the checksum is different).
Thanks for the help. I can see high pulses on A14 at the ROM and continuity to CPU is good. Odd. Think I need a tea. Thanks again :)
Okay, then just measure all the address lines :-) even If I would not understand how any other address line not working correctly would show this effect.
There is one other chance, that the gatearray does not work correctly on the A14/A15 lines anymore. Those are needed to actually even enable the ROM.
So potentially you want to read from ROM, but the GA does simply not enable the ROMEN line, because it cannot read A14 or A15 correctly?
Then you would actually read C000-FFFF from RAM. And then no wonder that this does not work.
Quote from: SerErris on 19:38, 13 January 23Okay, then just measure all the address lines :-) even If I would not understand how any other address line not working correctly would show this effect.
There is one other chance, that the gatearray does not work correctly on the A14/A15 lines anymore. Those are needed to actually even enable the ROM.
So potentially you want to read from ROM, but the GA does simply not enable the ROMEN line, because it cannot read A14 or A15 correctly?
Then you would actually read C000-FFFF from RAM. And then no wonder that this does not work.
Fixed (sort of, well that bit is fixed).
fixed sort of.jpg
You put me on the right track :laugh: .
I had a broken track between IC205 and IC212 on the Disk Controller side of the PCB.
IC205 PIN 2 AND gate input was floating high, should have been held low by IC212 PIN 5.
IC205 PIN 1 AND gate input is connected to A15
IC203 PIN 3 AND gate output is connected to ROMDIS
Every time A15 went high, the ROM was disabled.
So lower ROM worked, upper ROM was disabled. Took me a while...
I now have a ready prompt but I am seeing characters on the screen with no keyboard and no AY, so PIO fault. Back to problem 2 :)
Thanks for the help. I may need more.
Yeh that looks like random stuff going on on your AY or PIO.
I assume keyboard is still disconnected, right?
So that would mean that it is just a ghost effect from the AY to PIO communication.
This can be:
1. Pullups on AY are mad. All the inputs for the AY on Port A should be pulled up (meanining nothing is pressed) and the AY should always put out FF. That is because all the input pins to Port A are not connected to anything, so nothing will be able to pull them down to 0 volt.
2. However the AY anyhow looks suspekt outputting strange stuff on the one line of its Data bus. So it also could be that it is not the Pullups or Inputs wrong, but actually something wrong with the data output. The data output should not look like that and the uptime of the signal is pretty short.
I do not find any two sources to describe the correct connection between the PIO, the keyboard connector and the AY. All of them have numbers on them, that actually do not make any sense, or cannot be read.
I have a copy of the 664 service manual, that I would assume is in itself correct, but actually it is impossible that it is correct.
It connects the matrix between pin1 and pin 2 of the keyboard connector (that is how I read it), but according to the schematics of the same manual of the PIN 1 and PIN 2 of the connector are both connected to the PIO, which does not make any sense.
PIO is output and and AY is input - so two connected lines cannot sit on the same chip.
Anyone has a single schematic and keyboard matrix for the 664 that actually makes any sense?
Maybe someone can untangle that for me.
I used this service manual:
https://www.cpcwiki.eu/imgs/1/1f/Service.manual.cpc664.ctm644.gt65.pdf
And I have been looking at those two pictures, scratching my head:
Keyboard Matrix.jpg Schematic664.jpg
So lets try to apply some logic:
Pin1 of the matrix applys only to a single key (DEL key and that actually connects on the other side also to a single key.
So Pin 1 is obviously an Y row key and it should not get in conflict with anything else on the keyboard. So it would be best option to assume that pin1 from the Matrix diagram actually is Y10 on the Schematic. logically then the upper row of the matrix corresponds to the top most (Y10 and following down).
Pin2 on the other hand needs to be connected to the AY. One can see that there are only 8 inputs on the AY but 9 lines from the matrix. Howe they did it? They connected two lines from the matrix to the same input line (IO7). So the only reasonable way to not interfere anything here is to have this Pin2 connected to the keyboard with another line, but you can still distinguish the keys because you have different input lines to the matrix. So Del key actually sits on the same sending line as the joystick. And there is no other key from the keyboard connected to this sending line. So that my assumption would be (cannot validate), that actually Pin 2 and Pin3 from the matrix (X8,X9 in the schematic) do share both IO7 on the AY. ...
Then we could assume that Pin4 of the matrix is Y7 and that goes on mirrored .. (left of the matrix is right in the schematic).
But unfortunately I do think you would need to measure this.
I still believe that the AY is the culprit for your keyboard issues - so if you do have another one - just check if that goes away.
Quote from: SerErris on 14:40, 14 January 23Maybe someone can untangle that for me.
I used this service manual:
https://www.cpcwiki.eu/imgs/1/1f/Service.manual.cpc664.ctm644.gt65.pdf
And I have been looking at those two pictures, scratching my head:
Keyboard Matrix.jpg Schematic664.jpg
So lets try to apply some logic:
Pin1 of the matrix applys only to a single key (DEL key and that actually connects on the other side also to a single key.
So Pin 1 is obviously an Y row key and it should not get in conflict with anything else on the keyboard. So it would be best option to assume that pin1 from the Matrix diagram actually is Y10 on the Schematic. logically then the upper row of the matrix corresponds to the top most (Y10 and following down).
Pin2 on the other hand needs to be connected to the AY. One can see that there are only 8 inputs on the AY but 9 lines from the matrix. Howe they did it? They connected two lines from the matrix to the same input line (IO7). So the only reasonable way to not interfere anything here is to have this Pin2 connected to the keyboard with another line, but you can still distinguish the keys because you have different input lines to the matrix. So Del key actually sits on the same sending line as the joystick. And there is no other key from the keyboard connected to this sending line. So that my assumption would be (cannot validate), that actually Pin 2 and Pin3 from the matrix (X8,X9 in the schematic) do share both IO7 on the AY. ...
Then we could assume that Pin4 of the matrix is Y7 and that goes on mirrored .. (left of the matrix is right in the schematic).
But unfortunately I do think you would need to measure this.
I still believe that the AY is the culprit for your keyboard issues - so if you do have another one - just check if that goes away.
Thanks, I will have a read and physically check out the connections.
I don't have a spare AY at the moment but as a last resort I can take one out of my spare 6128. Wonder if there is a small test board out there for the AY?
Thanks again for the help, very much appreciated. Will post again when I have a replacement AY.
Hi
@SerErris.
From the Wiki:
https://www.cpcwiki.eu/index.php/Programming:Keyboard_scanning#Hardware_scancode_table
it can be confirmed that matrix pin 1 is indeed Y10 ( and also matrix pin 13 is Y7 ). I'm sure that more detective work will uncover how the rest work out.
And, effectively, the first joystick is also on matrix pin 1/ Y10.
Quote from: SerErris on 14:40, 14 January 23Maybe someone can untangle that for me.
I used this service manual:
https://www.cpcwiki.eu/imgs/1/1f/Service.manual.cpc664.ctm644.gt65.pdf
And I have been looking at those two pictures, scratching my head:
So lets try to apply some logic:
Pin1 of the matrix applys only to a single key (DEL key and that actually connects on the other side also to a single key.
So Pin 1 is obviously an Y row key and it should not get in conflict with anything else on the keyboard. So it would be best option to assume that pin1 from the Matrix diagram actually is Y10 on the Schematic. logically then the upper row of the matrix corresponds to the top most (Y10 and following down).
Pin2 on the other hand needs to be connected to the AY. One can see that there are only 8 inputs on the AY but 9 lines from the matrix. Howe they did it? They connected two lines from the matrix to the same input line (IO7). So the only reasonable way to not interfere anything here is to have this Pin2 connected to the keyboard with another line, but you can still distinguish the keys because you have different input lines to the matrix. So Del key actually sits on the same sending line as the joystick. And there is no other key from the keyboard connected to this sending line. So that my assumption would be (cannot validate), that actually Pin 2 and Pin3 from the matrix (X8,X9 in the schematic) do share both IO7 on the AY. ...
Then we could assume that Pin4 of the matrix is Y7 and that goes on mirrored .. (left of the matrix is right in the schematic).
But unfortunately I do think you would need to measure this.
I still believe that the AY is the culprit for your keyboard issues - so if you do have another one - just check if that goes away.
it is a bit of a head scratcher...
the numbers on the matrix are keyboard connector pins....they are also listed on the schematic in the middle...
eg pin 1 on the matrix is pin 3 on the 145 or Y3.... pin 4 on the matrix is pin 6 (not 4!) on the 145 and Y6...
X8 and X9 share the same line on the AY (pin7)and they are pins 19 and 16 on the matrix (not pin 2 and 3!)
ive circled the matrix pin numbers in the attached image...(also the arrows on the joystick and X# are pointing the wrong way!)
Quote from: WacKEDmaN on 07:55, 17 January 23also the arrows on the joystick and X# are pointing the wrong way!
The black arrows show the direction of the signal while the white arrows show where it connects.
New AY and now working. :) next the disk drive.
20230117_130910~2.jpg
Hum... I'm sure that will follow a Syntax Error... :-\
Quote from: TotO on 12:37, 17 January 23Quote from: WacKEDmaN on 07:55, 17 January 23also the arrows on the joystick and X# are pointing the wrong way!
The black arrows show the direction of the signal while the white arrows show where it connects.
ahh thanks Tot0... i knew there had to be a reason for it! :P
Quote from: TotO on 15:53, 17 January 23Hum... I'm sure that will follow a Syntax Error... :-\
Hopefully otherwise I've got more problems :)
Still interested to see how the AY failed. It just looked like the io inputs to the ÀY were floating and I did think about adding external pull-ups but these should be in the AY.
But for now I have a working keyboard and sound. Needs more testing though.
So far;
1. AMSDOS ROM dead
2. OS BASIC ROM dead
3. ÇRTC dead
4. AY bad
5. Number of broken tracks
6. Broken keyboard membrane
7. Key contact high resistance issues
Just can't get over how good the key caps looked compared to the PCB and ICs.
Quote from: Rabs on 19:42, 17 January 23So far;
1. AMSDOS ROM dead
2. OS BASIC ROM dead
3. ÇRTC dead
4. AY bad
5. Number of broken tracks
6. Broken keyboard membrane
7. Key contact high resistance issues
Just can't get over how good the key caps looked compared to the PCB and ICs.
thats alot of issues!... id still be at it! :P
really good job getting it back up and running...
Quote from: Rabs on 19:42, 17 January 23Still interested to see how the AY failed. It just looked like the io inputs to the ÀY were floating and I did think about adding external pull-ups but these should be in the AY.
But for now I have a working keyboard and sound. Needs more testing though.
So far;
1. AMSDOS ROM dead
2. OS BASIC ROM dead
3. ÇRTC dead
4. AY bad
5. Number of broken tracks
6. Broken keyboard membrane
7. Key contact high resistance issues
Just can't get over how good the key caps looked compared to the PCB and ICs.
The AY is known to be fragile and it's directly connected to external pins (the joystick port). So a simple static discharge could have caused the chip to fail.
Bryce.
OK, almost done. Disk is working, keyboard and joystick are working and tape is loading, BUT the remote to the tape is not working.
20230124_212252~2.jpg
So last bit, probably another broken track but I can't quite work out the tape circuit from the service manual. Is the relay not involved somewhere?
Oh and my the way, I don't hear the relay click when loading a tape. To load I disconnect the remote cable.
This one is learning experience. It is almost like it knows, like it has some sense to stay dead.
So all working, tape remote fixed, another broken track. Even ran a long soak test.
But Games not loading completely so swapped with my other 664 to check the tape and all OK. So back to this one to try again....and...grey screen.... :picard:
20230126_203849.jpg
Can't believe all the chips failed suddenly but don't think I did anything to cause a failure like this.
Will come back to it tomorrow...maybe it will fix itself :laugh:
gray screen and no memory shown could be the Mux ICs... 74LS153 ...theres 4 of them...finding the bad one is a PITA!
Quote from: WacKEDmaN on 07:22, 27 January 23gray screen and no memory shown could be the Mux ICs... 74LS153 ...theres 4 of them...finding the bad one is a PITA!
Thanks. I suspect it is another track. I did originally fix one track between the CRTC and the multiplexers. I guess, that the tracks are very fragile and continue to deteriorate. On the plus side I have pretty much now learnt how every part of the board operates :laugh:
or you have created a short somewhere.
I just had exactly that when playing around with a new extension and I accidentally created a short - gray screen, all RAMS seemed to be dead. Then I found and fixed the short and all was fine again.
Quote from: eto on 12:14, 27 January 23or you have created a short somewhere.
I just had exactly that when playing around with a new extension and I accidentally created a short - gray screen, all RAMS seemed to be dead. Then I found and fixed the short and all was fine again.
All I did was power it back on! Where do I start? My assumptions are that the main data and address bus are fine because the Diagnostic ROM is running. So any problem lies with either the RAM, the Multiplexers (74LS153) or the the two data buffers (74337 and 74244). I know the pcb is problematic (so I could be chasing ghosts on the tracks) and I have already replaced the CRTC and AY and the two ROMs (so it has had a hard life and something else may have failed). Think I need to scope the RAM data in, out and address lines and see if anything turns up...anything...Good job I have nothing else to do :laugh:
Quote from: Rabs on 15:44, 27 January 23Think I need to scope the RAM data in, out and address lines and see if anything turns up...anything...
Also check CAS and RAMDIS. In my case, I managed to shorten CAS.
I have traced RAS, CAS, WE and RAMDIS and they all look to have activity. I have also traced all Data outputs and again I can see activity. All Address lines also look to have activity.
But A11 from IC104 looks a bit odd to me, like there is another signal superimposed on it and none of the other address lines look like this.
A11.JPG
and when I trace this with A10, again from IC104, it looks to align.
A10_A11.JPG
I have loads of the 74153 ICs so I am tempted to just replace IC104.
It's possessed :o
20230127_184330~2.jpg
I desoldered IC104, tested the chip and it is OK but replaced anyway. No difference :picard:
Is it me or are the PCB holes not quite wide enough for a standard socket?
Anyway, I decided to look more closely at ÌC112 and RAMDIS.
All of a sudden it started working. I did nothing :o
Maybe a correded pin on a chip or a cold solder joint ... You pressed on the culprit, now it works ... until it breaks again.
Quote from: SerErris on 02:34, 28 January 23Maybe a correded pin on a chip or a cold solder joint ... You pressed on the culprit, now it works ... until it breaks again.
Thanks. I noticed that, if I waggled the power connector on the PCB, I could get the Diagnostics ROM to crash. Reflowed the joints and solid now. Hopefully this is it.
Quote from: Rabs on 19:54, 27 January 23Is it me or are the PCB holes not quite wide enough for a standard socket?
More likely that you didn't get every last bit of solder out of every pin hole.
Bryce.
Quote from: Bryce on 12:56, 28 January 23Quote from: Rabs on 19:54, 27 January 23Is it me or are the PCB holes not quite wide enough for a standard socket?
More likely that you didn't get every last bit of solder out of every pin hole.
Bryce.
Thanks, I will look out for that next time but not sure that is it, I had to literally splay the socket pins to fit and only for the smaller 14 and 16 pin sockets. I had no problems with the bigger 28 and 40 pin sockets. Also I have never had a problem with a 6128. My normal process is to reflow all pins first with some fresh solder, then use a Hakko desoldering gun and repeat until the pins look clear then use a dry iron to just make sure each pin clicks loose and if not repeat. So far, I have not had any problems and the ICs all lift only cleanly. But can't believe the pcb has slightly wider hole placement than standard so must be me :)
Right that's it, I am done, back playing F15 Strike Eagle on my resurrected 664.
Thanks everyone for the help, much appreciated.
20230128_162158.jpg
Here are my two working 664s.
20230128_162747.jpg
I swapped the keys onto my other 664, which otherwise is very clean.
What did I learn from this?
What looks like corrosion on a PCB or on the ICs is bad news, get ready to trace tracks for two weeks :)
A black screen could be a dead CRTC or ROM or track problems or all 3 :picard:
If BASIC does not start, check the ROMDIS from the disk circuit.
AY ICs are expensive, they need protection.
Beside a new membrane, the key contacts may need cleaning, check the resistance.
Odd things happen if the power is not stable, always check power is stable.
Again, thanks everyone for the help, off to look for my next project :D
Rabs,
If I understand correctly, you transferred the New looking keyboard to the lower unit, and put the aged - yellowed keyboard into the upper unit? I guess you did this because the "Amstrad and FDD" metal nameplates / badges on the upper unit appear "Scratched" / Damaged? but to me, they appear to still have their plastic protective on them (which has bubbled). Normally you peel this plastic film off when you buy the unit.
As CPC664 are so valuable - and IF you unit still has the plastic film in place on the metal name plates / badges - I'd leave it on!!! (don't peel it off!!!)... :) Still having the protective shipping film on the badges only helps to increase your units value!!! If I'm correct, then I put back the New Keyboard!!! looks like the upper CPC might be really a little used "New" unit still with its protective shipping film!!!
Quote from: RetroCPC on 19:43, 28 January 23Rabs,
If I understand correctly, you transferred the New looking keyboard to the lower unit, and put the aged - yellowed keyboard into the upper unit? I guess you did this because the "Amstrad and FDD" metal nameplates / badges on the upper unit appear "Scratched" / Damaged? but to me, they appear to still have their plastic protective on them (which has bubbled). Normally you peel this plastic film off when you buy the unit.
As CPC664 are so valuable - and IF you unit still has the plastic film in place on the metal name plates / badges - I'd leave it on!!! (don't peel it off!!!)... :) Still having the protective shipping film on the badges only helps to increase your units value!!! If I'm correct, then I put back the New Keyboard!!! looks like the upper CPC might be really a little used "New" unit still with its protective shipping film!!!
Hi, unfortunately not, what you see is corrosion on the metal nameplates. But thanks good to know.
Oh, What a shame - we could have had a good laugh :)
I've seen it before where people have left the film on and then complained how bad it looks years later....
Almost everything I have bought new (not that much) still has the protective film on which seems to upset everyone!!! - everyone seems to have the impulse to want to peel it off!!!
Anyway - well done with the repairs - well impressive list of issues... nice job :)
Also a note regarding the lead Pitch of the IC's - I've heard it said somewhere that Amstrad used a wider IC pitch the standard making it hard to fit IC's sockets - not sure which IC('s)... but have heard it mentioned before...
That is one good-looking 664 you have there.
Quote from: RetroCPC on 20:55, 28 January 23Also a note regarding the lead Pitch of the IC's - I've heard it said somewhere that Amstrad used a wider IC pitch the standard making it hard to fit IC's sockets - not sure which IC('s)... but have heard it mentioned before...
Depends on the model.
In the 6128 it seems to be all non-socketed ICs except for the RAM. In the 464 I have here, it seems to be all non-socketed ICs incl. RAM. In the Plus that I have here, the pitch seems to be the standard width for all ICs.
There were no CPC's produced with socketed RAM. If the RAM is in sockets someone swapped them or you have a prototype. The CPU, PAL and GA were the only IC's that came socketed from Amstrad production. As for the PCB pitch, it's exactly the dimensions it should be. If you varied this you would have major issues with the pick and place machines that populated the PCB in production.
Bryce.
Quote from: Bryce on 12:27, 04 February 23There were no CPC's produced with socketed RAM.
sorry, probably not clear, I meant: for all ICs that are socketed by AMSTRAD (e.g. CPU, Gate Array), the pitch width is "normal". For all ICs that are not in a socket, AMSTRAD used the wider pitch width (e.g. AY-3-8912).
The only exception to that rule (afaik) is the RAM of the 6128: In my 6128s RAM is soldered, but if I remove an IC I can directly put a socket in. With the 464s that I have that won't work. If I remove a RAM IC, a socket will not fit.
Quote from: eto on 15:02, 04 February 23Quote from: Bryce on 12:27, 04 February 23There were no CPC's produced with socketed RAM.
sorry, probably not clear, I meant: for all ICs that are socketed by AMSTRAD (e.g. CPU, Gate Array), the pitch width is "normal". For all ICs that are not in a socket, AMSTRAD used the wider pitch width (e.g. AY-3-8912).
The only exception to that rule (afaik) is the RAM of the 6128: In my 6128s RAM is soldered, but if I remove an IC I can directly put a socket in. With the 464s that I have that won't work. If I remove a RAM IC, a socket will not fit.
That's strange. I've just measured some 464 boards I have here and the footprints (including RAM) are all exactly the correct 2.54 x 7.62/15.24 pitch. In which direction is the pitch incorrect on your 464?
Bryce.