Quantum Atom Challenge

discussion of games, software, hardware & emulators relating to the Acorn Atom
User avatar
hoglet
Posts: 6979
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Quantum Atom Challenge

Postby hoglet » Wed Apr 11, 2018 3:32 pm

Hi all,

I've got a little challenge for you all to try to figure out.

Here's a short Atom machine code program.

Code: Select all

   10 DIM LL10
   20 P=#2800
   30[
   40:LL0
   50 LDA @#80
   60 CLC
   70 ADC #B002
   80 BCS LL0
   90 BMI LL0
  100 RTS
  110]
  120 LINK #2800
  130 P.$7
  140 END

Here's the assembly listing so you can verify the actual op-codes:

Code: Select all

2800          :LL0
2800 A9 80     LDA @#80
2802 18        CLC
2803 6D 02 B0  ADC #B002
2806 B0 F8     BCS LL0
2808 30 F6     BMI LL0
280A 60        RTS

In theory this program should never exit.

Why?

Because program will only exit if C=0 and N=0 after the ADC. But because the accumulator is starting off at #80, this condition should be impossible.

i.e. Any value in #B002 that is large enough to cause the accumulator to become positive again should also have caused carry to be set.

You can work through the two cases in more detail:
- if #B002 was in the range #00..#7F, then C=0 and the result is #80-#FF so N=1
- if #B002 was in the range #80..#FF, then C=1 and the result is #00-#7F so N=0

On Atomulator it never exits.

But on a real Atom, after some time (maybe hours) it will eventually exit.

How can this be possible?

Dave

User avatar
roland
Posts: 2872
Joined: Thu Aug 29, 2013 8:29 pm
Location: Born (NL)
Contact:

Re: Quantum Atom Challenge

Postby roland » Wed Apr 11, 2018 9:00 pm

The first thing that pops into my mind is a glitch in the cpu or hardware. Perhaps a memory read error (bpl opcode 0x10 instead of bpl opcode 0x30 which has only one diiferent bit).

I didn't run the routine yet, but is there any difference on what type of real Atom you run this? Original, Atom2k15, fpga Atom?

The Atom is well known for similar situations like an Atom with a prompt which gives an error message out of the blue. That is mostly caused by bad contacts.
256K + 6502 Inside
MAN WOMAN :shock:

User avatar
hoglet
Posts: 6979
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Quantum Atom Challenge

Postby hoglet » Thu Apr 12, 2018 6:23 am

roland wrote:I didn't run the routine yet, but is there any difference on what type of real Atom you run this? Original, Atom2k15, fpga Atom?

I have only tried in on my original Atom.

I would be very interested to see if only my Atom has this "issue".

I can also try it on a New 2015 Atom.
roland wrote:The Atom is well known for similar situations like an Atom with a prompt which gives an error message out of the blue. That is mostly caused by bad contacts.

This Atom is actually very reliable. It's running modern/fast memory (YARRB actually). I've never seen a "random" error message appear.
Last edited by hoglet on Thu Apr 12, 2018 10:01 am, edited 2 times in total.

User avatar
hoglet
Posts: 6979
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Quantum Atom Challenge

Postby hoglet » Thu Apr 12, 2018 9:35 am

I've tried the above test on a New 2015 Atom and I can make that fail as well. But so far I have only seen a failure with a NMOS 6502 (specifically a 1MHz SY6502) CPU, not (yet) with the 2MHZ CMOS R65C02.

Any more speculation as to what might be going on here?

For any non-atom people, #B002 bit 7 is the VSync signal, which is connected to port C bit 7 of an 8255 PIA. Most of the time the value is #F7, but during VSync it reads as #77.

Here's another data point...If you change the program from:

Code: Select all

2800          :LL0
2800 A9 80     LDA @#80
2802 18        CLC
2803 6D 02 B0  ADC #B002
2806 B0 F8     BCS LL0
2808 30 F6     BMI LL0
280A 60        RTS

to

Code: Select all

2800          :LL0
2800 AD 02 B0  LDA #B002
2803 18        CLC
2804 99 80     ADC @#80
2806 B0 F8     BCS LL0
2808 30 F6     BMI LL0
280A 60        RTS

it never exits.

Dave

User avatar
roland
Posts: 2872
Joined: Thu Aug 29, 2013 8:29 pm
Location: Born (NL)
Contact:

Re: Quantum Atom Challenge

Postby roland » Thu Apr 12, 2018 10:49 am

Just a speculation, without any investigation of the datasheets: can it be caused by #B002 changing during the execution of the ADC #B002 instruction?
256K + 6502 Inside
MAN WOMAN :shock:

User avatar
hoglet
Posts: 6979
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Quantum Atom Challenge

Postby hoglet » Thu Apr 12, 2018 11:29 am

roland wrote:Just a speculation, without any investigation of the datasheets: can it be caused by #B002 changing during the execution of the ADC #B002 instruction?

:D getting warmer I think...

According to the data sheet, the 8255 latches VSYNC (Port C bit 7) on the rising edge of Phi2 and the 6502 then reads it on the falling edge 500ns later.

You would think that would be good enough, wouldn't you?

User avatar
hoglet
Posts: 6979
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Quantum Atom Challenge

Postby hoglet » Sat Apr 14, 2018 12:32 pm

Here's some more data:
IMG_1307.JPG

The scope is consistently triggering on the access to #B002, and is in infinite persistence mode, capturing data over about an hour.

The top trace is Phi2, the bottom trace is D7 being driven by the 8255.

Some of these levels are definitely not very digital!

Dave