Designing a new Atom main board

discussion of games, software, hardware & emulators relating to the Acorn Atom and Acorn System machines.
User avatar
sirmorris
Posts: 776
Joined: Wed Feb 11, 2009 12:18 pm
Location: oxfordshire uk
Contact:

Re: Designing a new Atom main board

Post by sirmorris » Sat Dec 27, 2014 9:37 pm

It's been a bumpy ride - but 100% worth it!

I can't wait to see what everyone else does with their boards!

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

Re: Designing a new Atom main board

Post by roland » Sat Dec 27, 2014 9:59 pm

hoglet wrote: Does it flicker at any times other than when the SID is being used?
I was playing a text mode game with the name racer and also here I noticed the flickering. So it might nothing have to do with SID. I didn't notice it when doing other tests, making disassembly's, printing long listings etc. Also when playing games like Flappy Bird, Repton, Snapper, Space Invaders there is no flickering.

Then I realised that the BEEBSID program and the racer game both use graphical characters in CLEAR 0. I wrote a small test program which draws a line of graphical characters and then scrolls one line. And repeat this action.
Well .... the flickering is back. You can see it in a small video at http://youtu.be/BnxL_j8mswc

So there might be something else than using the SID. I hope this gives you a clue....
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

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

Re: Designing a new Atom main board

Post by roland » Sat Dec 27, 2014 10:08 pm

sirmorris wrote:It's been a bumpy ride - but 100% worth it!
Absolutely, even 200% worth it :lol:
sirmorris wrote:I can't wait to see what everyone else does with their boards!
If the *CAT and flickering issues are solved then it's ready for shipment. There are three boards reserved, if somebody else has become enthusiastic, just start a new topic like the CoPro. Although I don't expect such a big rush :roll:
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:


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

Re: Designing a new Atom main board

Post by hoglet » Sun Dec 28, 2014 9:12 am

roland wrote:Then I realised that the BEEBSID program and the racer game both use graphical characters in CLEAR 0. I wrote a small test program which draws a line of graphical characters and then scrolls one line. And repeat this action.
Well .... the flickering is back. You can see it in a small video at http://youtu.be/BnxL_j8mswc

So there might be something else than using the SID. I hope this gives you a clue....
It's all useful input. :D

I just tried this same program with my real Atom/GODIL, and also with my AtomFPGA (which uses the same design internally). Neither showed any signs of flicker, which is going to make me debugging this one a bit tricky.

It seems the trigger in this case is the PRINT ' scrolling the screen.

Can you tell if the problem is transient (e.g. maybe the video read address is incorrect for a while)? Or it is that the scroll operation is actually corrupting the screen memory? From the video, it looks transient. If so, this would narrow it down to the address generation on the "B" side of the video RAM.

The only theory I have at this point in time is that somehow the hardware scrolling is getting temporarily engaged.

I'm wondering why this only happens with graphics characters? Maybe during the scroll the GODIL registers controlling hardware scrolling are accidentally getting written, briefly enabling hardware scrolling. This is bit 6 of BDE0. Can you see if it only happens when bit 6 of the character is set?

In the SID case, it might be the VU Graph in the top right corner having the same effect.

This might suggest some timing differences on your board mean that sometimes a write to RAM is being seen as a write to the GODIL registers.

Another test you could do is to dump the GODIL registers, run the program, dump the registers again, and see if any have got corrupted.

Is it the same at 1MHz and at 2MHz?

Dave

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

Re: Designing a new Atom main board

Post by hoglet » Sun Dec 28, 2014 9:34 am

A quick test you could do is to force the nBDXX input of the GODIL high, and see if the flickering stops. This would confirm it was GODIL registers being written unexpectedly.

Dave

User avatar
oss003
Posts: 3185
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: Designing a new Atom main board

Post by oss003 » Sun Dec 28, 2014 10:31 am

Hi Roland,

to make testing the *CAT problem easier, I attached a Basic version of *CAT.

Greetings
Kees

Code: Select all

   10 DIM S20;N=0
   20 
   30 REM PREPARE WRITE DATA
   40  ?#B400=#21;GOS.i
   50 
   60 REM SEND NAME
   70  ?#B403=0;GOS.i
   80 
   90 REM OPEN DIR
  100  ?#B400=0;GOS.w
  110  IF X>64;P."ERR1:"&X;END
  120 
  130 REM READ DIR
  140  ?#B400=1;GOS.w 
  150  IF X>64;P."ERR2:"&X;END
  160  IF X=64;G.280
  170 
  180 REM PREPARE READ DATA
  190  ?#B400=#20;GOS.i
  200 
  210 REM GET NAME
  220  I=0
  230  D=?#B402;IF D<>0;I?S=D;I=I+1;G.230
  240  I?S=13;P.$S'
  250 
  260 G.130
  270 
  280 P.'"NR OF FILES:"N';END
  290 
  300iREM INTERWRITE DELAY
  310 WAIT;R.
  320 
  330wREM WAIT WHILE BUSY
  340 DOX=?#B400;U.X&#80=0
  350 R.
Attachments
CAT.zip
(467 Bytes) Downloaded 45 times

User avatar
oss003
Posts: 3185
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: Designing a new Atom main board

Post by oss003 » Sun Dec 28, 2014 11:06 am

Hi Roland,
roland wrote:Well .... the flickering is back. You can see it in a small video at http://youtu.be/BnxL_j8mswc
Maybe the flickering is triggered by putting the characters on the screen. If you look at the video, scrolling is ok after you typed HEX 0 but there were semigraphic characters on the top of the screen and there was no flickering.

Can you repeat the test without scrolling?

Greetings
Kees
scroll.png

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

Re: Designing a new Atom main board

Post by roland » Sun Dec 28, 2014 11:31 am

Hi Dave and Kees,

Thanks for your suggestions. I will try them tomorrow or so because today I'm going out for a family visit.

This morning I did some mechanical stuff:
atom-in-kast.jpg
The wires need some cutting, however, one doesn't notice that spaghetti once the case is closed:
utlimate.jpg
And a look at the back side:
achterkant.jpg
A little bit tweaking has to be done, but it looks like the ultimate Atom setup to me 8)

Greetings and have a nice Sunday,
Roland
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

User avatar
oss003
Posts: 3185
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: Designing a new Atom main board

Post by oss003 » Sun Dec 28, 2014 11:38 am

Can the Atom case be closed?

Kees

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

Re: Designing a new Atom main board

Post by roland » Sun Dec 28, 2014 12:34 pm

The Atom case can almost be closed. I just need to shorten the two shafts, where the long screws fit, a little bit. There are two pcb's over each other at that point so that's why there is a gap at the moment.
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

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

Re: Designing a new Atom main board

Post by roland » Sun Dec 28, 2014 12:59 pm

oss003 wrote: To make testing the *CAT problem easier, I attached a Basic version of *CAT.
I had just enough time left for this test. I changed all the REM statements to PRINT statements so I can easily see where it gets stuck.

The output is:

Code: Select all

PREPARE WRITE DATA
INTERWRITE DELAY
SEND NAME
INTERWRITE DELAY
OPEN DIR
WAIT WHILE BUSY


And then it is busy until escape is pressed.

I'll read the sources of the PIC firmware to see if I can find any clue. Strange problem because everything else works fine.... :-k
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

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

Re: Designing a new Atom main board

Post by hoglet » Sun Dec 28, 2014 1:16 pm

roland wrote: The output is:

Code: Select all

PREPARE WRITE DATA
INTERWRITE DELAY
SEND NAME
INTERWRITE DELAY
OPEN DIR
WAIT WHILE BUSY


And then it is busy until escape is pressed.

I'll read the sources of the PIC firmware to see if I can find any clue. Strange problem because everything else works fine.... :-k
My guess is the GetWildcard() in wfnDirectoryOpen() is where the PIC is hanging.

Try:
*CAT M*
or
*CAT *
and see if these both hang as well.

Dave

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

Re: Designing a new Atom main board

Post by roland » Sun Dec 28, 2014 11:20 pm

I didn't do the tests yet (just got home) but is the firmware easy to debug with an in-circuit debugger from Microchip? I know somebody here in the neighborhood who has such tools. He's very willing to support me...
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

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

Re: Designing a new Atom main board

Post by roland » Mon Dec 29, 2014 10:35 pm

Again a big step forward: the flickering has completely gone ( =D> for me :lol: )

I did several tests but I could not really understand when the flickering happened. In fact there were two situations when flickering occurred:
  • excessive screen access with red semi-graphic characters. It didn't occur with the yellow ones. When scrolling it was worse than when only writing characters to the screen. It also only occurred in text access, in graphical mode I never saw any flickering.
  • SID access: also when playing Reptune the flickering occurred while there is completely no screen access.
The Beebsid players use both of them so then the flickering was heavy.

I tried it also at address #9Exx, but no difference. Disabled BDxx, no improvement. Then I thought of the this:
hoglet wrote:Can you tell if the problem is transient (e.g. maybe the video read address is incorrect for a while)? Or it is that the scroll operation is actually corrupting the screen memory? From the video, it looks transient. If so, this would narrow it down to the address generation on the "B" side of the video RAM.
So maybe it occurs when the address lines are changing during a clock cycle. I added Phi2 to the VDG signal:

Code: Select all

if (Addr(15 downto 13) = "100" or Addr(15 downto 8) = x"BD") and Phi2 = '1' then
     nVDG <= '0';
else
     nVDG <= '1';
end if;


And the problem was solved. In fact, we talked about Phi2 missing here on December 11th:
hoglet wrote:
roland wrote:Another difference is that on Kees' diagram the vdg signal has a phi2 component in it. Mine doesn't.
This shouldn't matter, because inside the GODIL VGD and NWDS are OR'd together, and the rising edge is used to time the RAM write pulse. But it's worth keeping in mind in case we run out of other things to try.
The Atom has been playing "Always on my mind" for 15 minutes now and I don't have seen a single flicker. I also noticed a feature (maybe a bug), try this at home:

Code: Select all

>$#9D00 = "READ THIS"
>PRINT $#BD00
READ THIS>
But that only happens with addresses that are not within the GODIL's register space. The GODIL registers are only accessible at #BDC0 - #BDFF. I don't mind about this feature, just want to inform you about this.

So now, let's focus on the last issue before heaven is here: *CAT. I tried your suggestion to *CAT * or *CAT M* but that also makes the Atom hang. Is it possible to debug the firmware with an in-circuit debugger?
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

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

Re: Designing a new Atom main board

Post by roland » Mon Dec 29, 2014 11:03 pm

Just discovered something that might give the experts a clue:

As you know, *CAT hangs. BUT: if I remove the SD card, press BREAK, and then re-insert the SD card, *CAT works. I can CWD into different directories, no problem. And this works until I press break again.

Something worth noticing: my reset pulse is active for about 1 second. The CPLD does this, to deal with bouncing of the break key. And it makes my Atom always starting without having to hit break.

Maybe this will ring a bell somewhere :-k
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

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

Re: Designing a new Atom main board

Post by hoglet » Tue Dec 30, 2014 8:00 am

roland wrote:Again a big step forward: the flickering has completely gone ( =D> for me :lol: )
Great news!

I'm really pleased this is coming together so well.
hoglet wrote: This shouldn't matter, because inside the GODIL VGD and NWDS are OR'd together, and the rising edge is used to time the RAM write pulse. But it's worth keeping in mind in case we run out of other things to try.
I just went back and checked this, and while this is true for RAM access, it is not true for register access. So, this is likely why your fix was necessary.
roland wrote: I also noticed a feature (maybe a bug), try this at home:

Code: Select all

>$#9D00 = "READ THIS"
>PRINT $#BD00
READ THIS>
If you look at the expression for dout, you can see why this is happening:

Code: Select all

  dout <= sid_do  when sid_cs  = '1' and CimplSID  else
            uart_do when uart_cs = '1' and CimplUart else
            reg_do  when reg_cs  = '1'               else
            douta;
The default value is douta, which is port A of the video Ram.

To fix this, I would need to add a ram_cs signal into the core.
roland wrote: So now, let's focus on the last issue before heaven is here: *CAT. I tried your suggestion to *CAT * or *CAT M* but that also makes the Atom hang. Is it possible to debug the firmware with an in-circuit debugger?
I have no experience of doing this. Maybe Charlie has.

This *CAT bug is getting weirder by the minute....

Just to rule it out, can you try a different SD Card that has been newly formatted with just a small number of files on it.

Dave

User avatar
sirmorris
Posts: 776
Joined: Wed Feb 11, 2009 12:18 pm
Location: oxfordshire uk
Contact:

Re: Designing a new Atom main board

Post by sirmorris » Tue Dec 30, 2014 8:21 am

I sometimes see card initialisation fail which requires taking out and reinserting the card. I don't think this is the case here, though. If you see your green LED flash then the card has been detected. The PIC resets on the falling edge so I don't think the second-long reset pulse is an issue.

Can the serial output of the PIC be connected to a terminal? Maybe some printf debugging is necessary. PICKit debugging is a painful affair when it works and is perhaps best avoided. It also requires a debug build of the code.

I should start a thread/post on a wiki about setup and operation of the PIC compiler chain so that it's less painful for people to work on the firmware. I could even set up a VM if that would be preferable. I'm back at work now so time is tight but if anyone would find that useful I can make it happen.

C

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

Re: Designing a new Atom main board

Post by hoglet » Tue Dec 30, 2014 9:05 am

Roland,

I can't remember if you tried this already, but is the *CAT bug present with the 2.9 version of the Firmware?

Dave

User avatar
oss003
Posts: 3185
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: Designing a new Atom main board

Post by oss003 » Tue Dec 30, 2014 11:13 am

Hi Roland,

Did you try pressing CTRL-BREAK and then type LINK #EFCC

This way you initialize the SD card manually.

Greetings
Kees
Last edited by oss003 on Tue Dec 30, 2014 3:19 pm, edited 1 time in total.

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

Re: Designing a new Atom main board

Post by roland » Tue Dec 30, 2014 11:14 am

I'm looking all over this forum, but I cannot find the firmware 2.9 any more :(

I did try a development version that Kees posted during the random access development and then *CAT was working. But random files were failing.

Kees, if you still have firmware 2.9, can you please add it to the topic AtoMMC2 rom.
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

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

Re: Designing a new Atom main board

Post by roland » Tue Dec 30, 2014 11:18 am

Hi Kees,
oss003 wrote: Did you try pressing CTRL-BREAK and then type LINK #EFCC
This way you initialize ths SD card manually.
I tried this, but the *CAT doesn't work after that. It also doesn't work if I press break without CTRL and then LINK #EFCC. It respons with ATOMMC 2.97E.

Greetings,
Roland
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

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

Re: Designing a new Atom main board

Post by hoglet » Tue Dec 30, 2014 12:35 pm

roland wrote:I'm looking all over this forum, but I cannot find the firmware 2.9 any more :(

I did try a development version that Kees posted during the random access development and then *CAT was working. But random files were failing.

Kees, if you still have firmware 2.9, can you please add it to the topic AtoMMC2 rom.
Roland, here is version 2.9 rebuilt from the source I have I github:
atommc25.zip
(10.82 KiB) Downloaded 32 times
Dave

PhilYoung
Posts: 203
Joined: Sun Jun 12, 2011 4:55 pm
Contact:

Re: Designing a new Atom main board

Post by PhilYoung » Tue Dec 30, 2014 1:40 pm

roland wrote:Just discovered something that might give the experts a clue:

As you know, *CAT hangs. BUT: if I remove the SD card, press BREAK, and then re-insert the SD card, *CAT works. I can CWD into different directories, no problem. And this works until I press break again.

Something worth noticing: my reset pulse is active for about 1 second. The CPLD does this, to deal with bouncing of the break key. And it makes my Atom always starting without having to hit break.

Maybe this will ring a bell somewhere :-k
It rings a small bell with me. At one point on a real Atom and MMC, *CAT straight after BREAK was causing a complete freeze. However a *CWD to a directory known to exist and then *CWD back to the root directory restored normal operation if done immediately after BREAK.

Perhaps you could try this, I think it was around the time of v2.94.

Cheers,

Phil Young

User avatar
oss003
Posts: 3185
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: Designing a new Atom main board

Post by oss003 » Tue Dec 30, 2014 3:47 pm

Roland,

if you type *CFG does your Atom reply #FF?
This means that the PIC controller is generating an IRQ at BREAK and jumps to #A000 which it doesn't have to do if the AtoMMC ROM is at #Exxx.

Code: Select all

*CFG (value)

Will show the configuaration byte currently stored in EEPROM if no value is specified, else the interface's config will be changed. The default value is $FF. The following bits have an effect:

5  ($20) - Enable Interrupts
6  ($40) - Shift-Break Action
7  ($80) - Enable Bootloader
Can you try it with IRQ disabled: *CFG C0

PS Can you check if the IRQ line is pulled down at BREAK?

Greetings
Kees

User avatar
sirmorris
Posts: 776
Joined: Wed Feb 11, 2009 12:18 pm
Location: oxfordshire uk
Contact:

Re: Designing a new Atom main board

Post by sirmorris » Tue Dec 30, 2014 8:12 pm

I think Roland should ship out the boards to everyone and enlist the community debug team ;)

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

Re: Designing a new Atom main board

Post by roland » Tue Dec 30, 2014 9:14 pm

sirmorris wrote:I think Roland should ship out the boards to everyone and enlist the community debug team ;)
Indeed, the time is coming to ship the three "pre-ordered" boards. I want to keep the fourth board for a little while because I want to build it with a minimal Atom Video Circuit. And if that works, I'll sell it to somebody who's interested in it.

I'll try the other suggestions as well but I'm quite sure that the *CWD doesn't change the behaviour, although I don't recall *CWD back to the root. So I'll try that.

I am sure that the PIC cannot generate an interrupt because the IRQ and NMI outputs of the PIC are not connected to the cpu.
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

User avatar
oss003
Posts: 3185
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: Designing a new Atom main board

Post by oss003 » Wed Dec 31, 2014 8:58 am

Hi Roland,
roland wrote:I am sure that the PIC cannot generate an interrupt because the IRQ and NMI outputs of the PIC are not connected to the cpu.
Looks like the IRQ and NMI lines are connected to pins 25/26 on your schematic?
Did you make some changes?
schema.png
Greetings
Kees

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

Re: Designing a new Atom main board

Post by roland » Wed Dec 31, 2014 9:45 am

Yes, I made a little change: I didn't route those tracks on the pcb because of board space. And the interrupts are not used if the rom is at Exxx.
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

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

Re: Designing a new Atom main board

Post by roland » Wed Dec 31, 2014 1:27 pm

Today I did these tests:
  1. *CFG C0 -> *CAT hangs
  2. *CWD \SYSTEM then *CWD \ and then *CAT still hangs
  3. Downgrade to firmware 2.9 -> *CAT works
So somewhere during developing the random access support something was changed which causes my (online mine?) AtoMMC to fail at *CAT. I'll have a look in the github sources if I can find something.

In the mean time, maybe some other people could do the upgrade to firmware 2.A to see if their *CAT is failing also. This is without any risk of damaging your AtoMMC because with the AtoMMC2.9 firmware on this page you can easy go back to the previous version.
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:

Post Reply