CPU bug?

This section is for discussing everything about Next hardware and latest updates.
slingshot
Posts: 40
Joined: Mon Mar 22, 2021 12:21 pm

Re: CPU bug?

Postby slingshot » Tue Mar 30, 2021 2:45 pm

It's better now:
im2ack_good.png
im2ack_good.png (48.11 KiB) Viewed 1986 times

Alcoholics Anonymous
Posts: 777
Joined: Mon May 29, 2017 7:00 pm

Re: CPU bug?

Postby Alcoholics Anonymous » Tue Mar 30, 2021 2:52 pm

slingshot wrote:
Tue Mar 30, 2021 12:52 pm
Alcoholics Anonymous wrote:
Mon Mar 29, 2021 12:23 am
...The 128K cycle length, eg, is most likely different because they put a small capacitance in the int line in addition to the 480 / 660 ohm series resistor used to separate the ula int from exp bus int on 48K models.
It explains the +1 cycle (36->37), but not 32->36. It should be different logic in the ULA.
I am not so sure about that. What is the test program actually measuring? It's not the length of the int pulse, it's the time that it's released is it not?

The 128K schematic has an RC with time constant 470ns on the int line and the cpu clock period is about 282ns. If the int line is initially charged up to 5V and we need to get to 0.8V to sense a 0 then the time to do that is about 861ns or 2-3 clock periods. In the other direction you have to get up to 2V to see a 1 so the time to do that is about 240ns or almost 1 clock period. If you have the same 32 period interrupt length then this adds up to 3+32+1 = 36 cycles before the int line is seen to release. These are coarse calculations as the real situation is the int line may not be charged all the way to 5V, the ula has finite drive strength which is weaker in the + direction and the threshold where 0 or 1 is seen from other direction is fuzzy.

A couple of observations. Different ula logic that counts 36 clock periods for int length is more complicated than something that counts 32; I think it unlikely. Secondly, I don't know how other spectrum cores deal with the 128K interrupt onset but the Next core delays it by two cycles in comparison to the 48K -- this is the 861ns delay mentioned in the first paragraph. Without doing that, timing critical programs will not display correctly.

The best way to know these things for sure is to put a scope on the line and measure it.
Actually timings could be fixed without adjusting the INT length. I've sent another merge request with the fixes so far (INT cycle is TODO). As it implies a slight size increase, you should decide if it's acceptable or not.
Cheers I will look at it. But the RC delays are fixed real time and we're adding some onto the expansion bus due to level conversion circuitry so it's very likely we have to adjust the pulse length for various scenarios. I don't want the situation to be different just because someone turned on the expansion bus with nothing attached :)
Last edited by Alcoholics Anonymous on Tue Mar 30, 2021 3:36 pm, edited 1 time in total.

Alcoholics Anonymous
Posts: 777
Joined: Mon May 29, 2017 7:00 pm

Re: CPU bug?

Postby Alcoholics Anonymous » Tue Mar 30, 2021 2:59 pm

slingshot wrote:
Tue Mar 30, 2021 2:45 pm
It's better now:
im2ack_good.png
Yes it is :)

Are you able to run arbitrary programs and look at signals? If so would you be able to check if an interrupt vector is being picked up properly?

slingshot
Posts: 40
Joined: Mon Mar 22, 2021 12:21 pm

Re: CPU bug?

Postby slingshot » Tue Mar 30, 2021 5:52 pm

Alcoholics Anonymous wrote:
Tue Mar 30, 2021 2:59 pm
slingshot wrote:
Tue Mar 30, 2021 2:45 pm
It's better now:
im2ack_good.png
Yes it is :)

Are you able to run arbitrary programs and look at signals? If so would you be able to check if an interrupt vector is being picked up properly?
The time when the input is latched didn't change at all, it's just a bit cosmetics on the IORQ output. The internals of the T80n does not even know about the change. The example I've tried gets FF, and the vector then loaded from F2FF (+F300), so it's OK. How can I encounter anything which doesn't get an FF without external peripherals?

In the code, when MState=1, LDZ='1' (in t80n_mcode.vhd), and the TmpAddr low byte (vector address) is loaded at TState=3. That means the vector address is set when IORQ goes high. Seems it's correct.

Alcoholics Anonymous
Posts: 777
Joined: Mon May 29, 2017 7:00 pm

Re: CPU bug?

Postby Alcoholics Anonymous » Tue Mar 30, 2021 6:34 pm

slingshot wrote:
Tue Mar 30, 2021 5:52 pm
The time when the input is latched didn't change at all, it's just a bit cosmetics on the IORQ output.
That is ok as long as the vector is sampled at the right place.
The example I've tried gets FF, and the vector then loaded from F2FF (+F300), so it's OK. How can I encounter anything which doesn't get an FF without external peripherals?
I think I am always seeing FF. The Next has 14 internal peripherals that can be programmed to use im2 with vectors so we can test with that but that depends on whether you can see the signals while running a program that sets up im2 on the Next core?
In the code, when MState=1, LDZ='1' (in t80n_mcode.vhd), and the TmpAddr low byte (vector address) is loaded at TState=3. That means the vector address is set when IORQ goes high. Seems it's correct.
The vector should be sampled at the end of T2, ie the rising edge of T3.

https://drive.google.com/file/d/14Yxq-i ... sp=sharing

LDZ causes the vector to be read when TState=3 ( https://gitlab.com/SpectrumNext/ZX_Spec ... .vhd#L1166 ). If you scroll way up ( https://gitlab.com/SpectrumNext/ZX_Spec ... n.vhd#L422 ) this appears to be on the rising edge of the cpu clock (the inverted clock which is in all timing diagrams) which means the vector gets loaded at the end of T3 unless I am mistaken?

slingshot
Posts: 40
Joined: Mon Mar 22, 2021 12:21 pm

Re: CPU bug?

Postby slingshot » Tue Mar 30, 2021 7:15 pm

Hmm, looks like it picks up the D_i at the middle of T3:

Code: Select all

      if CLK_n'event and CLK_n = '0' then
         if TState = "011" and BUSAK_n_i = '1' then
--          DI_Reg <= to_x01(D);
            DI_Reg <= D_i;
         end if;
      end if;
Which is definitely wrong here (half cycle after IORQ goes up). The loading of DI_reg into TmpAddr is not that important as long as it happens after loading DI_reg.
Now it gets tricky, as D_i for the intack cycle should be sampled at the different edge of the clock, so DI_Reg could not be used.

Yeah, any software which uses IM2 with the external peripherals? CTC maybe?

slingshot
Posts: 40
Joined: Mon Mar 22, 2021 12:21 pm

Re: CPU bug?

Postby slingshot » Tue Mar 30, 2021 7:50 pm

Ok, I think it's really good now:
im2ack_really_good.png
im2ack_really_good.png (45.78 KiB) Viewed 1945 times

Alcoholics Anonymous
Posts: 777
Joined: Mon May 29, 2017 7:00 pm

Re: CPU bug?

Postby Alcoholics Anonymous » Tue Mar 30, 2021 8:00 pm

That looks really promising. Things are so much easier when there is someone familiar with the t80 about :)
I have some simple test sw for the ula and ctc on vectors that can be tried but I can't post until later tonight.
Last edited by Alcoholics Anonymous on Tue Mar 30, 2021 8:04 pm, edited 1 time in total.

slingshot
Posts: 40
Joined: Mon Mar 22, 2021 12:21 pm

Re: CPU bug?

Postby slingshot » Tue Mar 30, 2021 8:03 pm

T80 is scary at the first sight, but it's not that bad at the second :)
Another bug: NMI ack cycle should not have auto wait cycles inserted.

Alcoholics Anonymous
Posts: 777
Joined: Mon May 29, 2017 7:00 pm

Re: CPU bug?

Postby Alcoholics Anonymous » Tue Mar 30, 2021 10:56 pm

I found it on this computer so I won't have to wait until I am home:

https://drive.google.com/file/d/1pI-gC2 ... sp=sharing

I'll post in a bit what is supposed to happen after reviewing the source code. A lot is happening that could go wrong (software and hardware) but maybe it will work on the first try :) Run it after a fresh reset.

Edit:

You must press a key to get an update. If you press U then the ula interrupt will be toggled on and off.

The time is supposed to be measuring "minutes:seconds.hundredths". These are completely ctc driven via interrupt and depend on ctc0 acting as a timer counting 0.0001s and the ctc1-3 acting as cascaded counters counting hundredths then seconds then minutes. The counting functions are not known to work and I believe the repo has been updated with changes after your grab.

The failed isr count counts how often an unexpected vector is used.

The ctc counts are not interrupt driven. These are watching the status registers in a tight loop looking to see transitions and are updated while the printf is not executing. A ctc generating a signal will set the status bit and a reti corresponding to the ctc will reset it. The counts are looking for 0->1 transitions.


Who is online

Users browsing this forum: No registered users and 9 guests