• Please review our updated Terms and Rules here

Einstein

Gary C

Veteran Member
Joined
May 26, 2018
Messages
2,300
Location
Lancashire, UK
Next up is a Tatung Einstein

Its been doing its duty for the last 12 months, booting Elite from disk for the amusement of the visitors but is now locking up during boot.

If no disk is present, it starts up in the MOS fine. Disk tested on my machine and works fine.

Diag ROM installed and no faults noted

1711527525679.png

So a disk fault ?

From MOS you can read a disk. Command R 100 200 0000 0 reads 100h bytes from track 0 sector 0 head 0 and then T 0100 0200 shows the memory. Did this and the contents of sector 0 track 0 read perfectly into memory so no fault with disk drive.
 
As the disk is reading fine, then its probably an error executing the boot code once its in memory.

Reading the manual, the ROM starts up and first writes FF to every memory location in the 64K of RAM, copies a bunch of vectors into memory from FB00h and Z80 break vectors from 0000h and maps out the ROM. Quick swap of ROM's and the faulty machine still wont boot but the good machine still can. So its not the ROM.

Looking though the memory of the faulty machine, I can see the data from FB00h but I can also see data from F800h which isn't there on the good machine. Looks like a smoking gun.

Filling F800 to F8FF with FF caused a crash of the monitor. Dumping memory also shows a bunch of FFs appearing at FC00 which weren't there before.

Changing F800 to 5E results in FC00 changing to 5E. Changing FC00 to 22 results in F800 changing to 22.

So an addressing issue and looking like a problem with A10

F800 = 1111 1000 0000 0000
FC00 = 1111 1100 0000 0000

Of course it will affect other address ranges.
 
The diagnostic ROM obviously doesn't catch this type of error so I've had a look at the code but

It has a strange command that ASM80 really doesn't like

checkPSG_3:
; select register 'B' + 0D
LD A, B
ADD 0Dh
LD C, 0FFh
CALL checkPSGRegister
JP NZ, PSGResetError
DJNZ checkPSG_3

What on earth is ADD 0Dh ? ASM80 quite rightly complains its missing a parameter. Odd.
 
Ah. the old Z80 ADD issue...

Try:

ADD A,0Dh ; A := A + n. A := A + 0Dh.

Some assemblers require the 'A' register, others do not. Go figure...

There are a few other Z80 instructions in the same category.

Dave
 
Just a complier difference ?

it just assumes the Acuumulator ref is there rather than using normal mnemonics ?
 
Last edited:
Confused

So writing to address 0 changes address 0400
writing to address F800 changes address FC00

From the binary

0000 = 0000 0000 0000 0000
0400 = 0000 0100 0000 0000

0C00 = 0000 1100 0000 0000
0800 = 0000 1000 0000 0000

1000 = 0001 0000 0000 0000
1400 = 0001 0100 0000 0000

1800 = 0001 1000 0000 0000
1C00 = 0001 1100 0000 0000

F800 = 1111 1000 0000 0000
FC00 = 1111 1100 0000 0000

So A10 seems to be the obvious choice as faulty but it appears to be working fine to the RAM's

Wonder if its a RAS/WR/CAS timing issue
 
Humm

The address MUX's seem ok (Ironically 74LS157;s) which seemed to be the obvious candidates.

Or do you mean something else ?
 
Its strange, I can see the select changing and A10 and A2 data passing through the MUX fine on the scope and the LA, and as it aligns to A10 its not being latched properly on read and/or write.

As RAS to CAS is governed by a resistor/capacitor I'm going to check the DRAM timing next as I can't think what else to do at the moment.

1711916894631.png
 
Oh well, time to eat my words

Set up my logic analyser on RAS, CAS, WR, all address lines and keyed in a small bit of code to continuously write to F800 which should have address A10 low and behold, pin 6 of the RAM is high when CAS falls even though A10 on the Z80 is low. Few more probes onto IO07 pins 1, 9,10,11 and its obvious that when Select goes low, pin 9 goes high even with pins 10 & 11 low and there are ghost pulses feeding back through pins 10 & 11.

Convinced it was ok using the scope as normal but I must have made a mistake.
 
>>> Convinced it was ok using the scope as normal but I must have made a mistake.

That's the way it goes...

Dave
 
At least I got to play with my Logic Analyser and now know a lot about the way the Einstein generates RAS/CAS signals.
 
Back
Top