exxos's Atari, Amiga & retro forum

BERR is high when the CPU is halted.

Without CPU, when on addr 0, DTACK is low.

Memory locations beyond 0, I ran through the first few addresses. I assume I'm counting in binary here: all pins low is location 0, A1 high is location 1, A2 high is location 2, A1 + A2 high is location 3, etc.

What I get at the various locations ... definitely does not match what's in the diagnostic thread.

          data
          1111 11
          5432 1098 7654 3210

addr 0    0110 0000 0010 1110 == 0x602e
     1    0000 0001 0000 0100 == 0x0104
     2    0000 0000 1111 1100 == 0x00fc
     3    0000 0000 0011 0000 == 0x0030
     4    FFFF FFFF FFFF FFFF == 0xffff
     5    FFFF FFFF FFFF FFFF == 0xffff
     6    FFFF FFFF FFFF FFFF == 0xffff
     7    FFFF FFFF FFFF FFFF == 0xffff
     8    FFFF FFFF FFFF FFFF == 0xffff

(I kept reading, wondering if A3 high was somehow important, but A3 is low to get addr 8.)

Does that imply bad contacts to the ROM or a bad ROM? I don't have other ROM chips in this form factor to try in the socket.

In doing this, I now realise the TOS selector should be unjumpered for 1.04. Previously I had this unjumpered and I read out 0x0206 when I started putting together this post, and that felt suspicious :lol: Everything above has the TOS selector jumpered though.

That looks like the ROM is blank. But I don't really see how that can be possible because I do verify them all, generally twice as well.But I guess it cannot be ruled out at this point.

I think the only other test is to wire the address bus to one of the addresses which is coming back as FFFF and check that ROM_CE is low on the ROM IC itself. As if the ROM chip is not enabled and is not going to be driving the bus and will be FFFF anyway.

stween wrote: 28 Nov 2022 04:15

addr 0    0110 0000 0010 1110 == 0x602e
     1    0000 0001 0000 0100 == 0x0104
     2    0000 0000 1111 1100 == 0x00fc
     3    0000 0000 0011 0000 == 0x0030
     4    FFFF FFFF FFFF FFFF == 0xffff
     5    FFFF FFFF FFFF FFFF == 0xffff
     6    FFFF FFFF FFFF FFFF == 0xffff
     7    FFFF FFFF FFFF FFFF == 0xffff
     8    FFFF FFFF FFFF FFFF == 0xffff

This looks correct to me for TOS 1.04 at 0xFC0000.

Remember there's no A0, so addres 1 is actually address 2.

That means you're getting data for address 0x00, 0x02, 0x04, 0x06. Those first four words are mapped to ROM and should return exactly what you're seeing.

At 0x08 (your position 4) you're into RAM. It's all uninitialised, so FFs all the way.

I think this is spot on.

BW

Badwolf wrote: 28 Nov 2022 13:54 At 0x08 (your position 4) you're into RAM. It's all uninitialised, so FFs all the way.

Ah yes. Thanks pointing that out.

Indeed he needs to match the addresses from 0xFC0000 to see if those are working correctly. The first few addresses should match and then not be FFFF onwards like he is seeing now.

exxos wrote: 28 Nov 2022 10:33 That looks like the ROM is blank. But I don't really see how that can be possible because I do verify them all, generally twice as well.But I guess it cannot be ruled out at this point.

I think the only other test is to wire the address bus to one of the addresses which is coming back as FFFF and check that ROM_CE is low on the ROM IC itself. As if the ROM chip is not enabled and is not going to be driving the bus and will be FFFF anyway.


Capture.PNG

Based on that: on a quick check it looks like when I check addr 0, pin 22 is low; when I check addr 8, pin 22 is high.

edit: ahh, missed the new posts until I refreshed!

Indeed he needs to match the addresses from 0xFC0000 to see if those are working correctly. The first few addresses should match and then not be FFFF onwards like he is seeing now.

What should I check here?

stween wrote: 28 Nov 2022 14:46 Based on that: on a quick check it looks like when I check addr 0, pin 22 is low; when I check addr 8, pin 22 is high.

Yes that is actually correct behaviour.

As @Badwolf Rightly pointed out, it is RAM which is causing the FFFF numbers. FC0000 is actually mapped to the first few bytes In the memory map as well. So you should see the same sequence if you change the address bus to go from FC0000.. But instead of seeing FFFF on the higher addresses, you should be able to continue the sequence as posted on my diagnostic thread.

Sorry for the misunderstanding, I'm not very awake in the mornings :lol: :roll:

Ah, okay! Understood.

I set the top 6 bits high (A23, 22, 21, 20, 19, 18) and started counting up from there. I definitely do not see the same memory mapped into place. I only tried a couple of offsets once the pattern was clear but I get all ones back on the data lines:

          data
          1111 11
          5432 1098 7654 3210

addr 0    FFFF FFFF FFFF FFFF == 0xffff (ROM_CE is high)
     1    FFFF FFFF FFFF FFFF == 0xffff
     8    FFFF FFFF FFFF FFFF == 0xffff

So the upper bits are now 5v. So check on the glue those bits are also 5v.

Looks like you're getting close to the problem.

exxos wrote: 29 Nov 2022 08:54 So the upper bits are now 5v. So check on the glue those bits are also 5v.

And also that all the lower bits are zero!

BW

exxos wrote: 29 Nov 2022 08:54 So the upper bits are now 5v. So check on the glue those bits are also 5v.

Badwolf wrote: 29 Nov 2022 10:18 And also that all the lower bits are zero!

BW

Yup: the highs are high and the lows are low on the glue. Matches precisely what I set manually.