Black Screen 664

[Rabs]

Looking at the first pictures... 
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.

You cannot view this attachment.

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  .

[eto]

If I am not mistaken, then at this point the ROMs are initialized. So maybe the Amsdos Rom fails.

[Rabs]

If 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.

[SerErris]

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.

[Rabs]

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.

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.You cannot view this attachment.

[SerErris]

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).

[Rabs]

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).

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.

[Rabs]

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

You cannot view this attachment.


And the other pins.

You cannot view this attachment.

Now compare this with my working 664.

You cannot view this attachment.

[SerErris]

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?

[Rabs]

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?

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.

[SerErris]

Let me check the basic rom for that. 

[SerErris]

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)

Code Select Expand

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?

[SerErris]

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.

[eto]

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

Interesting. I didn't know that either.

I 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?

[SerErris]

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?

[Rabs]

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?

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.

You cannot view this attachment.

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.

[SerErris]

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?

[Rabs]

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?

Of course, that makes sense....But no AY at the moment, so can't select the ROM test.

[SerErris]

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.

[Rabs]

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.

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. 

[SerErris]

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.

[SerErris]

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).

[Rabs]

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).

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 

[SerErris]

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.

[Rabs]

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.

Fixed (sort of, well that bit is fixed).

You cannot view this attachment.

You put me on the right track .

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.