Trying to fix Mikro's wrecked TT board

[dml]

That is a very good question. I see an fmove pretty early on even in TOS 3.00.

Golden rule of fixing stuff - solving any mystery will immediately produce two more, both of which will be stranger and more obscure than the original one.

[dml]

On the FPU requirement for TOS 3.xx - I have been wondering if the FPU is being checked on a cold boot - but the reset vector has already been initialised and pointing to a resume point beyond the FPU check.... if so, that could explain why:

- I was able to reach the desktop without an FPU fitted
- It always cold-boots to a black screen but continues to boot on a warm reset

I have done nothing to confirm this yet but next time I return to it I'll investigate...

[dml]

I think I might have tentatively confirmed this now.

Fitted an FPU and the machine is behaving differently.

Previously, a cold boot would present a black screen. A warm boot would present a white screen, then a disk controller error dialog, then Desktop.

Now a cold boot presents a white screen with Atari logo and STRam memory test!

:)

[dml]

....and a new twist to the TT adventure....

The daughterboard apparently does not work :/ or at least, I'm just getting a black screen with it installed. Hitting reset a bunch of times didn't help.

I did check the orientation of the oscillator jumper so it's not that.

I swapped the board back out for the test CPU and I get the Atari logo again.

So I have more work ahead it seems! And I'll need my scope to do much more with that so I'll probably need to shelve the project for a bit until I deal with that problem.

There are two PAL chips on that board, which is a concern. I can change the CPU but those PALs I am less sure about, especially if no images were taken from them by now...

[stephen_usher]

As "all" the daughter board is doing is running the CPU at 32MHz rather than the 16MHz the rest of the system is running at I'd imagine that the PALs are pretty simple. One probably just generates the clock.

I seem to remember that your oscilloscope fault is on the trigger circuit, so checking to see if the clock is being generated, even if you can't get any measurement, would be possible with it in that state. i.e. you can check two of the three basics, clock and power, are getting to the CPU socket on the board even if you can't really check the reset.

[dml]

As "all" the daughter board is doing is running the CPU at 32MHz rather than the 16MHz the rest of the system is running at I'd imagine that the PALs are pretty simple. One probably just generates the clock.

Yes there are only some LS logic and two PALs there - so no cache etc. It should be 'easy to debug' (famous last words).

I seem to remember that your oscilloscope fault is on the trigger circuit,

The state of the Tek scope is hilariously bad - not sure I'll get it back in usable condition without a serious amount of poking around. I'll try to post a pic later.

The Fluke I think just has a bad encoder, ignoring it. I have a spare front panel to steal one from so I'll probably just do that. Hopefully it's not more than that.

so checking to see if the clock is being generated, even if you can't get any measurement, would be possible with it in that state. i.e. you can check two of the three basics, clock and power, are getting to the CPU socket on the board even if you can't really check the reset.

I have other toy-class scopes and I could scrape by with what I have - even with the nontriggering one - but I'd rather just get the scope resolved while I have a bit of time for it. I'm more likely to need it at short notice than the TT currently :)

[dml]

hmm.png

:coffee:

[stephen_usher]

Very 1950s/60s!

[PhilC]

I do love those old round CRT scopes.

[Darklord]

Haven't we seen that in a few grade B sci-fi flicks?

Mad scientists, and all?! :)