Tatung Computer Forum

Hi

In process of diagnosing a boot failure.

The machine runs the diagnostic ROM and shows no errors but fails to boot.

Now, with a known good file in a Gotek, I can boot one machine ok but the troublesome machine just hangs at the *****einstein***** logo.

Thing is, from MOS if I use R 100 300 0000 0, it reads the disk into memory from 0100 but only the first four bytes, however the same happens on the working machine. I was assuming this command would read the whole 512 bytes of track 0 sector 0 into memory.

Am I using the read command incorrectly ?

Might be ROM bitrot of course, thats on the list of things to check as I note the diagrom doesn't do a CRC on the main rom ?

So i was looking at the wrong disk !

The BBC lanuguage disk does indeed have SectorID 0 track 0 having 00 E1 00 FB 00 FA 00 FF and the rest of the sector filled with FF

So, I have a machine that wont boot yet I can load into memory, the first sector of the disk with no errors.

Roms swapped with no change.

Now thats odd

MOS startup fills all memory with FF I believe then vectors setup from FB00 onwards. In the good machine this is so, but in the bad machine I have data in the memory map from F800 onwards which suggests I have an address decoding or ghosting RAM problem.

At least its a step forward.

Ha

if I write something to F800, FC00 changes to the same value and vice versa

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

Looks like a problem with address A10

Interesting behaviour!

The bytes you mention are the addresses where the DOS tracks from the disk are stored and executed in RAM.

E100 is the start address of DOS code copied from track 0
FB00 is the end address of the DOS code
FA00 is the execution address for DOS after loading

These addresses vary by DOS system.

DOS code itself starts at track 0 sector 4, by the way, not sector 0 as might be expected!

I’d see if the DOS code is loading correctly into RAM as this is the next thing that happens in the boot sequence after the logo display. Loading can be checked manually with the MOS READ command. Once loaded, you can run DOS manually with the GOTO command and see if both machines behave in the same way.

I’d also suggest trying out the other DOS versions. If you’re booting from a gotek as your Drive 0, I’d also check your physical drive jumpers are set correctly on both machines in case that’s causing an issue and perhaps even try a physical boot disc in the physical drive too.

Worth mentioning the system uses some RAM addresses above DOS as stratchpad locations so RAM in that region can’t really be relied upon as values are changed by the system.

Hope you unravel the mystery!

Richard

Confused


So writing to address 0 changes address 0400

writing to address F800 changes address FC00 and every 400h step

From the binary, changing one address changes the other

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

Line A10 makes it through the multiplexer IO07 fine so its not a simple stuck bit. The fact that all 8 bits are being transcribed into two address ranges (or being read from two ranges) then all 8 RAM's are being affected.

Next I need to check the timings of RAS to WR to CAS

I think I’m more confused than you are!

Given the RAM has passed the diagnostic rom tests, such behaviour does not make a lot of sense!

The related binary and hex numbers that you list do seem equivalent so I’m not seeing an issue.

Can I check what MOS command/s you are using to check and modify RAM?

The DOS/MOS Introduction Manual contains a full explanation of all the MOS commands.

Damn, it was A10 but I was looking for failure to go high when it turned out to be a failure to go low.

Setup my logic analyser on RAM address lines, RAS, WR & CAS, wrote a small bit of code to constantly write to F800 and found that when CAS became active low, A2 was high which it should not have been.

Checking pin 40 of the Z80, A10 is low so obvious candidate is back to IO07, quick check and its faulty. Swapped and its working.

I was looking in inverse, I was looking for A10 being low when It should have been high (Which was 'working') rather than high when it should have been low (which was the actual fault)

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

The Einstein diag ROM would never find this error because it only checks individual memory locations, so when it writes to F800 and that changes FC00 it wont know because when it reads back from F800 it gets FC00 and cant tell the difference.

It would need writing to implement something like a MARCH-C test but even then it can miss things. My PET 8032SK was passing Dave's MARCH-C test but would crash as soon as you tried to do anything. In the end it was the refresh circuit and the memory test was writing so quickly it was not allowing the lack of refresh to show itself.

Great that you’ve unravelled the mystery. Good to know another Einstein is saved and is now working as it should!

Yes, it all makes sense now. Many thanks for the explanation.

I was struggling to reconcile the behaviour with the fact that the diagnostic rom hadn’t thrown up any issues and the MOS disk routines also seemed to be fine!

Am looking forward to visiting the North West Computer Museum later this year. I believe you’ve built the Apple 1 replica on display there!

Your welcome to come and visit

Yes, we have an Apple-1 replica that I built a couple of years ago. It works, though its actually a really limited computer due to its display using a big shift register rather than using RAM.

We have quite a few 80's machines on display and working. We want to make things hands on so we have about 30 machines up and running for the public to use.

Hardest part is advertising, so please, tell everyone you know to come and see us.

Northwest computer museum
Leigh Spinners Mills,
Park Lane,
Leigh
WN7 2LB

(near Manchester UK)