CPU bug?

This section is for discussing everything about Next hardware and latest updates.
azesmbog
Posts: 16
Joined: Mon May 29, 2017 9:12 pm

Re: CPU bug?

Postby azesmbog » Thu Mar 25, 2021 4:05 pm

DanyPPC wrote:
Thu Mar 25, 2021 3:10 pm
by I have this message on screen:
Just one mistake, were there any more ??
Completed all 35 tests ??

DanyPPC
Posts: 63
Joined: Thu Feb 27, 2020 7:27 am

Re: CPU bug?

Postby DanyPPC » Thu Mar 25, 2021 4:15 pm

Yes, completed all 35 tests, only one failed.

I repeated all the tests 3 times.

azesmbog
Posts: 16
Joined: Mon May 29, 2017 9:12 pm

Re: CPU bug?

Postby azesmbog » Thu Mar 25, 2021 4:58 pm

DanyPPC wrote:
Thu Mar 25, 2021 4:15 pm
Yes, completed all 35 tests, only one failed.
Which company bought the Sinclair brand in 1986?:

DanyPPC
Posts: 63
Joined: Thu Feb 27, 2020 7:27 am

Re: CPU bug?

Postby DanyPPC » Fri Mar 26, 2021 7:01 am

azesmbog wrote:
Thu Mar 25, 2021 4:58 pm
Which company bought the Sinclair brand in 1986?:
Amstrad, obviously. :)

I also own a Just Speccy 128k from Zaxxon in a 48k Plus case.
Good machine.

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

Re: CPU bug?

Postby slingshot » Fri Mar 26, 2021 8:24 pm

Alcoholics Anonymous wrote:
Thu Mar 25, 2021 3:43 pm

There is supposed to be a memory refresh cycle in the interrupt acknowledge for IM0/IM1. This could be different for IM2 as there is no instruction actually executed but it could be there as well. The first machine cycle for IM0 is six cycles and for IM1/IM2 it is seven cycles. If IM2 does not have the refresh cycle then the bus is idle for the refresh cycles seen in IM1. A missing refresh cycle could explain R being off by one.

I don't know if the vhdl T80 implements this -- you would probably know better. The UNO is using the verilog T80 implementation.
Yes, there's a refresh cycle in the intack cycle. I think the timings of the interrupt acknowledge are OK. There's one cpu clock cycle delay until the int is accepted, that might cause an issue. However I found a bigger issue: the interrupt length should be 64 pixels, but it's just 61. It can cause problems in the test (not much in real world). The pulse_count signal doesn't do its job as intended. Here's a capture:
Attachments
badintlength.png
badintlength.png (31.73 KiB) Viewed 2218 times

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

Re: CPU bug?

Postby slingshot » Fri Mar 26, 2021 8:29 pm

@dannyppc: can you run the attached test on the +2?
Attachments
minfo.zip
(831 Bytes) Downloaded 62 times

DanyPPC
Posts: 63
Joined: Thu Feb 27, 2020 7:27 am

Re: CPU bug?

Postby DanyPPC » Sat Mar 27, 2021 6:40 am

This is what I get:
CC.jpg
CC.jpg (60.37 KiB) Viewed 2197 times

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

Re: CPU bug?

Postby slingshot » Sat Mar 27, 2021 9:44 am

DanyPPC wrote:
Sat Mar 27, 2021 6:40 am
This is what I get:
CC.jpg
Thanks, this confirms the different INT length on 128K.

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

Re: CPU bug?

Postby Alcoholics Anonymous » Mon Mar 29, 2021 12:23 am

slingshot wrote:
Fri Mar 26, 2021 8:24 pm
Yes, there's a refresh cycle in the intack cycle. I think the timings of the interrupt acknowledge are OK. There's one cpu clock cycle delay until the int is accepted, that might cause an issue. However I found a bigger issue: the interrupt length should be 64 pixels, but it's just 61. It can cause problems in the test (not much in real world). The pulse_count signal doesn't do its job as intended. Here's a capture:
An im2 response might be better to look at. The iorq signal is occurring too early in the int ack sequence -- it should be asserted in the middle of the third cycle after m1 comes down and last just 1.5 cycles. In an im2 ack this is important as the time between m1 coming down and iorq coming down is used to settle the im2 daisy chain which is a bunch of logic distributed in series on external boards. I don't think this is going to impact the Next as the im2 daisy chain is internal to the fpga so the propagation time is actually quite fast. I do see the im2 interrupt response jumping to the wrong isr addresses but I haven't had time to see if that is because the vector is not there to pick up or if the cpu is reading the vector at the wrong time. I have checked the im2 logic a few times so lean to a problem in the cpu.

Yes the cycle length of int is a known issue. There is more to it than generating an exact cycle length and that is the pulse length can change if peripherals are attached to the expansion bus. 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. On the +3 the amstrad ula drives the int line of the z80 directly with a passive pullup on the line.

When the next turns on its expansion bus the int signal is fed out to the expansion bus pin "int" but it is also read in from the same expansion bus pin and it's this read value that drives the z80's int pin. It's done this way because some peripherals can override the int signal generated by the ula and we're trying to duplicate this by allowing an external peripheral to force the signal high. The signal goes through a level conversion process that adds a certain amount of capacitance. So the cycle length adjustment probably has to take into account whatever circuit we settle on, whether the expansion bus is on and which model is currently active. The pulse counter allows the length to be easily adjusted.

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

Re: CPU bug?

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

Alcoholics Anonymous wrote:
Mon Mar 29, 2021 12:23 am

An im2 response might be better to look at. The iorq signal is occurring too early in the int ack sequence -- it should be asserted in the middle of the third cycle after m1 comes down and last just 1.5 cycles. In an im2 ack this is important as the time between m1 coming down and iorq coming down is used to settle the im2 daisy chain which is a bunch of logic distributed in series on external boards. I don't think this is going to impact the Next as the im2 daisy chain is internal to the fpga so the propagation time is actually quite fast. I do see the im2 interrupt response jumping to the wrong isr addresses but I haven't had time to see if that is because the vector is not there to pick up or if the cpu is reading the vector at the wrong time. I have checked the im2 logic a few times so lean to a problem in the cpu.
Indeed, it's wrong. IORQ should go down at +20, not at +8. I think it's not hard to fix it. The cycle length is OK (19 cycles).
im2ack.png
im2ack.png (59 KiB) Viewed 2069 times
Yes the cycle length of int is a known issue. There is more to it than generating an exact cycle length and that is the pulse length can change if peripherals are attached to the expansion bus. 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. On the +3 the amstrad ula drives the int line of the z80 directly with a passive pullup on the line.
It explains the +1 cycle (36->37), but not 32->36. It should be different logic in the ULA.
When the next turns on its expansion bus the int signal is fed out to the expansion bus pin "int" but it is also read in from the same expansion bus pin and it's this read value that drives the z80's int pin. It's done this way because some peripherals can override the int signal generated by the ula and we're trying to duplicate this by allowing an external peripheral to force the signal high. The signal goes through a level conversion process that adds a certain amount of capacitance. So the cycle length adjustment probably has to take into account whatever circuit we settle on, whether the expansion bus is on and which model is currently active. The pulse counter allows the length to be easily adjusted.
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.


Who is online

Users browsing this forum: No registered users and 10 guests