derkom's attempt

[czietz]

One of the first things TOS does is executing the RESET instruction. That makes the CPU pull the RESET line down for ca. 15 µs. This is expected.

[exxos]

One of the first things TOS does is executing the RESET instruction. That makes the CPU pull the RESET line down for ca. 15 µs. This is expected.

Thanks. That's that mystery solved at least :thumbup:

[derkom]

There seems a lot of bus activity, does the floppy light come on on the keyboard ?

Nope.

What happens after the image you posted ? Does it die totally later ?

It just sits there repeatedly bus erroring:

berr.png

I notice when I trigger on BERR and just watch it do it over and over again, A23 is the only active address line (well, of A14 and up, as those are connected to LA right now). A14-A22 are sitting idle before each bus error, although they do wake up afterwards.

I feel like unless there's a specific path of diagnosis you want to follow here, maybe it's better to wait for some other builds to complete, so we have more data on whether this is a problem with my build or a general problem. I have no problem at all continuing to do whatever you'd like for diagnosis, but I don't want to dominate a lot of time and attention if you'd rather wait and see what happens with other boards.

[derkom]

One of the first things TOS does is executing the RESET instruction. That makes the CPU pull the RESET line down for ca. 15 µs. This is expected.

Aha. Well, hmm then. That certainly makes it look like the machine is loading TOS then. Curious indeed.

[czietz]

Aha. Well, hmm then. That certainly makes it look like the machine is loading TOS then. Curious indeed.

It certainly is loading TOS. A few microseconds after RESET becomes high again you can see in your trace A18 going low and A17 simultaneously going high. This the access to 0xFA0000 to check for the presence of the diagnostic cartridge.

[exxos]

@derkom can you get the whole address bus saved just before the bus error ? If we can get the address its trying to access it may give us a clue...

[derkom]

@derkom can you get the whole address bus saved just before the bus error ? If we can get the address its trying to access it may give us a clue...

Sure. I'll have to do a couple of passes to get the whole bus, and I'll capture several examples of each bank I'm recording, just to make sure the address is the same. Gimme a few and I shall return. There will some ice cream consumed as well, so allow a few minutes extra for that. :roll:

[exxos]

No rush. Teatime for me soon, then be driving home after. Though if you can get the binary number from the address bus and convert to hex, then check in the memory map PDF and see if anything is at the address the CPU is trying to access.

[PhilC]

What version of Tos are you trying to boot with Derkom?

[derkom]

Okay. The answer is simple, but perhaps not helpful. Everything is low except A22, every bus error.

EDIT: Actually I don't quite know what to report, because the whole bus is going silent before the errors:

berr1.png

berr2.png

Ignore RESET, ROM_CE, and DTACK in the second picture, as the probes aren't connected.

Everything looks basically identical before and after each bus error, except A22 and A23, which are usually quiet pre-"silent time", but occasionally not. I grabbed screenshots at moments when they were not. And oops, I seem to have skipped A13, but I doubt it's going to be instructive anyway.

Unless there are other ideas, or other things I should probe, I think the best thing right now might be to resolder all the address and data lines, whilst waiting for someone else to try booting a board. :)