Interfacing an Atom to a Raspberry Pi Pico

emulators, hardware and classic software for atom + system machines
User avatar
cjm
Posts: 96
Joined: Fri Sep 01, 2017 3:19 pm
Location: Woking, Surrey
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by cjm »

hoglet wrote:
Fri May 21, 2021 1:45 pm
Let me know what your thinking is about merging the vga80 branch back into master.

(I did the work on a branch because I wasn't convinced it would be successful. In git it's good to avoid unnecessary active development on multiple branches, as if they diver too much merging can be a pain).
It works very well - I think the vga80 branch should be merged into the master. I agree that we should keep the number of active branches to a minimum.
hoglet wrote:
Fri May 21, 2021 1:45 pm

Things that need attention are:

1. PIO Delays

The PIOs need additional delay to run at faster system clocks (as you mentioned above). I wasn't sure what to tweak. DIviding by 2 (as I currently do) isn't the right answer, as this breaks reads at 2MHz.
Agreed. Also, for reads, acquiring the address earlier in the cycle might help.
hoglet wrote:
Fri May 21, 2021 1:45 pm
2. VGA Mode Changing

What do you think about trying to run in 320x200 for the normal Atom modes, and 640x480 for the VGA80 mode?

Although it sounds like that will break your VGA to HDMI adapter, and you might get sync glitches when changing mode.

If we stick with 640x480 for eveything, the existing code I think can be sped up by writing 32-bit words (2 pixels per word).
I'm happy with 640x480 for everything. Maybe it even looks better on my monitor than 320x240. I submitted a change earlier that enables the exiting code to support 640x480 at 150MHz. Will that do?

Chris
Atom + YARRB + Noise Killer + HDMI adapter + Homebrew RPi-MMC AtoMMC V4
User avatar
hoglet
Posts: 10353
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by hoglet »

cjm wrote:
Fri May 21, 2021 3:25 pm
It works very well - I think the vga80 branch should be merged into the master. I agree that we should keep the number of active branches to a minimum.
I've just merged vga80 back into master.
cjm wrote:
Fri May 21, 2021 3:25 pm
I'm happy with 640x480 for everything. Maybe it even looks better on my monitor than 320x240. I submitted a change earlier that enables the exiting code to support 640x480 at 150MHz. Will that do?
Yes, that looks a good change.

FYI, this is the data in the default font:

Code: Select all

      2 0x0E
      2 0x2C
      4 0x1A
      4 0x36
      5 0x26
      5 0x30
      5 0x32
      5 0x38
      6 0x0C
      6 0x28
     12 0x12
     14 0x1E
     14 0x24
     17 0x2A
     18 0x18
     19 0x14
     22 0x3C
     25 0x3E
     29 0x04
     34 0x10
     37 0x02
     43 0x1C
     63 0x20
     92 0x08
    113 0x22
    556 0x00
So optimising 0x00 (and it's inverse) is a big win.

If we need more cycles in the future, we could explore other optimizations then.

Interesting that you can see a difference with 320x240 - my understanding was that the video format being output was identical. i.e. the scan video PIO is handling the 2x scaling in X and Y. But if your VGA adapter behaves differently, that's evidence there is more too it. Any ideas what's different?

Dave
User avatar
cjm
Posts: 96
Joined: Fri Sep 01, 2017 3:19 pm
Location: Woking, Surrey
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by cjm »

hoglet wrote:
Fri May 21, 2021 3:54 pm
FYI, this is the data in the default font:

Code: Select all

      2 0x0E
      2 0x2C
      4 0x1A
      4 0x36
      5 0x26
      5 0x30
      5 0x32
      5 0x38
      6 0x0C
      6 0x28
     12 0x12
     14 0x1E
     14 0x24
     17 0x2A
     18 0x18
     19 0x14
     22 0x3C
     25 0x3E
     29 0x04
     34 0x10
     37 0x02
     43 0x1C
     63 0x20
     92 0x08
    113 0x22
    556 0x00
So optimising 0x00 (and it's inverse) is a big win.
That's interesting. bits 0,6 and 7 are always zero.
Atom + YARRB + Noise Killer + HDMI adapter + Homebrew RPi-MMC AtoMMC V4
User avatar
hoglet
Posts: 10353
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by hoglet »

cjm wrote:
Fri May 21, 2021 4:28 pm
That's interesting. bits 0,6 and 7 are always zero.
Yes, in the original 6847 font, the character always occupies the same 5x7 pixel region of the 8x12 character cell.
User avatar
cjm
Posts: 96
Joined: Fri Sep 01, 2017 3:19 pm
Location: Woking, Surrey
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by cjm »

I need an address to use for testing 2/4MHz reads.

Does anyone know if there are any unused addresses in the YARRB address map outside of the range B000 to BFFF?

Chris
Atom + YARRB + Noise Killer + HDMI adapter + Homebrew RPi-MMC AtoMMC V4
User avatar
hoglet
Posts: 10353
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by hoglet »

cjm wrote:
Fri May 21, 2021 5:26 pm
Does anyone know if there are any unused addresses in the YARRB address map outside of the range B000 to BFFF?
Bit 1 of #BFFE controls the region at #0A00-#0AFF.

If this bit is 1, then that region is part of the 32K RAM.

If this bit is 0, then that region is mapped to the external bus (i.e. U4 would be enabled if fitted) to allow for an external FDC interface.

Dave
User avatar
roland
Posts: 4394
Joined: Thu Aug 29, 2013 9:29 pm
Location: Born (NL)
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by roland »

You're doing really great things with this board =D> I'll try to catch up this weekend with the latest firmware....
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:
Prime
Posts: 2946
Joined: Mon Jun 01, 2009 12:52 am
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by Prime »

Any chance of a look at the schematics?

I've got a couple of pi-pico boards and some LVC245s on order would be good to knock up a board....

Cheers.

Phill.
User avatar
cjm
Posts: 96
Joined: Fri Sep 01, 2017 3:19 pm
Location: Woking, Surrey
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by cjm »

Prime wrote:
Fri May 21, 2021 9:17 pm
Any chance of a look at the schematics?
Attached.
Attachments
output.pdf
(142.39 KiB) Downloaded 38 times
Atom + YARRB + Noise Killer + HDMI adapter + Homebrew RPi-MMC AtoMMC V4
Prime
Posts: 2946
Joined: Mon Jun 01, 2009 12:52 am
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by Prime »

cjm wrote:
Fri May 21, 2021 11:21 pm
Prime wrote:
Fri May 21, 2021 9:17 pm
Any chance of a look at the schematics?
Attached.
Thanks for that much appreciated :)

Cheers.

Phill.
User avatar
hoglet
Posts: 10353
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by hoglet »

Prime wrote:
Sat May 22, 2021 4:33 pm
Thanks for that much appreciated :)
Phill, if you are going to make your own boards, do take note of the modification that allows data to be read back from the Pico, decribed a few posts up. That's not reflected in the schematics.

Dave
Prime
Posts: 2946
Joined: Mon Jun 01, 2009 12:52 am
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by Prime »

hoglet wrote:
Sat May 22, 2021 4:52 pm
Prime wrote:
Sat May 22, 2021 4:33 pm
Thanks for that much appreciated :)
Phill, if you are going to make your own boards, do take note of the modification that allows data to be read back from the Pico, decribed a few posts up. That's not reflected in the schematics.
Thanks, yed I noticed that I've routed it to NRDS. Though I have the exact board laid out in Eagle, I may try using an XC9536 to buffer the address and control signals as that would bring the chip count down to 2 plus the pi.

Cheers.

Phill.
Prime
Posts: 2946
Joined: Mon Jun 01, 2009 12:52 am
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by Prime »

Well that was easier than I thought.....

Having followed a set of instructions for getting vstudio going with ubuntu running on WSL2 and installed all the needed bits, I managed to clone the source and compile.....

Of course as I'm not attached to an Atom, and am using the Pimoni Pico demo board which has more bits / colour I'm only getting the signon message and in very dark blue.....but it appears to be working :)

Cheers.

Phill.
User avatar
cjm
Posts: 96
Joined: Fri Sep 01, 2017 3:19 pm
Location: Woking, Surrey
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by cjm »

Prime wrote:
Sun May 23, 2021 9:30 pm
Well that was easier than I thought.....

Having followed a set of instructions for getting vstudio going with ubuntu running on WSL2 and installed all the needed bits, I managed to clone the source and compile.....

Of course as I'm not attached to an Atom, and am using the Pimoni Pico demo board which has more bits / colour I'm only getting the signon message and in very dark blue.....but it appears to be working :)
Cool, useful to know that the devkit works on WSL2 - and you're half-way to running an Atom emulator on a pico demo board! :lol:

The atom-pico-vga firmware only drives 6 out 16 of the DAC pins. So 64 shades of blue is all you can get without changing the firmware.

If you haven't done it already it's worth setting up SWD access to the pico.
Atom + YARRB + Noise Killer + HDMI adapter + Homebrew RPi-MMC AtoMMC V4
Prime
Posts: 2946
Joined: Mon Jun 01, 2009 12:52 am
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by Prime »

Right,

I'd like to make this code semi-portable between different machines. There are several things such as the location for the 80 Col stuff that would need to be moved to different addresses (for The Dragon and CoCo). So I'd like to define these as constants that could be changed on a machine by machine basis.

Also the video buffer base is set as a constant currently, for the Dragon this is going to need to be a variable (as it's framebuffer can be moved), this can of course on the Atom be initialized to the constant that it is currently. Would this be expected to cause a performance hit?

Another thing I wondered about is a 'ready' output for the pi, this needs to be connected to some external circuitry to hold the host CPU in reset until the pi is ready, that way you have no problems with the pi not catching the initial writes of the host.

Cheers.

Phill.
User avatar
cjm
Posts: 96
Joined: Fri Sep 01, 2017 3:19 pm
Location: Woking, Surrey
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by cjm »

Prime wrote:
Mon May 24, 2021 11:00 pm
I'd like to make this code semi-portable between different machines. There are several things such as the location for the 80 Col stuff that would need to be moved to different addresses (for The Dragon and CoCo). So I'd like to define these as constants that could be changed on a machine by machine basis.
Agreed.
Prime wrote:
Mon May 24, 2021 11:00 pm
Also the video buffer base is set as a constant currently, for the Dragon this is going to need to be a variable (as it's framebuffer can be moved), this can of course on the Atom be initialized to the constant that it is currently. Would this be expected to cause a performance hit?
That should be possible. The firmware generates the video one line at a time. If we can assume that the video buffer base is constant for the current line then the performance hit would be minimal.
Prime wrote:
Mon May 24, 2021 11:00 pm
Another thing I wondered about is a 'ready' output for the pi, this needs to be connected to some external circuitry to hold the host CPU in reset until the pi is ready, that way you have no problems with the pi not catching the initial writes of the host.
It's not a big problem on the Atom - the pico starts virtually instantly and you can hit break if you want to see the "ACORN ATOM" message but it's not necessary. Does the dragon have a reset key?

Chris
Atom + YARRB + Noise Killer + HDMI adapter + Homebrew RPi-MMC AtoMMC V4
User avatar
cjm
Posts: 96
Joined: Fri Sep 01, 2017 3:19 pm
Location: Woking, Surrey
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by cjm »

More Speed...

The https://github.com/hoglet67/pico_atomvg ... pio-timing branch contains an update to enable reads at 2MHz - reliably. It captures the read address earlier in the 6502 clock cycle - but timing issues mean it only works for R65C02 at present.

I think operation at 4MHz might be tricky to achieve with the current mechanism. The PIO takes about 100ns from the start of the 6502 clock cycle to acquire the address and 20ns to write the response. Which (at 4MHz) leaves at most 130ns for the ARM core to process the data (26 instruction cycles). If you subtract the processing time for FIFO transfers then it doesn't leave much time for the application code to do its thing.

However, for the VGA80 emulation we only need to provide read access to a limited address range. Maybe we could use the PIO to stretch the 6502 read cycle when an address is in that range by controlling the 6502 RDY signal?
Atom + YARRB + Noise Killer + HDMI adapter + Homebrew RPi-MMC AtoMMC V4
User avatar
roland
Posts: 4394
Joined: Thu Aug 29, 2013 9:29 pm
Location: Born (NL)
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by roland »

cjm wrote:
Wed May 26, 2021 10:01 am
I think operation at 4MHz might be tricky to achieve with the current mechanism. The PIO takes about 100ns from the start of the 6502 clock cycle to acquire the address and 20ns to write the response. Which (at 4MHz) leaves at most 130ns for the ARM core to process the data (26 instruction cycles). If you subtract the processing time for FIFO transfers then it doesn't leave much time for the application code to do its thing.
Although I fully understand the reason why .... it sounds hilarious that a 4MHz Atom is almost too fast for a 250MHz ARM CPU :lol:
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:
Prime
Posts: 2946
Joined: Mon Jun 01, 2009 12:52 am
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by Prime »

Right Atom version working correctly :) Even with the updates to make this compilable for the Dragon.

I'm having a problem getting my head round how some of the pio stuff works. I need to define another clock pin for the 6809's Q clock. I've connected this to GPIO20 on my board. On the 6809 it has a quadrature clock system, Q leads E (which is roughly equivilent to phi2 on the 6502) The 6809 sets up addresses at the leading rising edge of Q, and latches data out on the trailing edge of Q. Reads however are latched in on the falling edge of E.

I've added a definition for the Q pin to the .pio file,

Code: Select all

.define public PIN_Q 20
However when I change the statements waiting for the falling edge of E to the falling edge of Q, the Ahigh and alow ousputs start having glitches.

Code: Select all

  wait 1 GPIO PIN_Q
The other thing that I can't seem to get, is a load of the pins are used without apparently being defined anywhere.
e.g.

Code: Select all

    jmp PIN handle_read                                 ; wait for next clock cycle if not a write
How do I know which pin it's testing?

As for Reset, yeah the Dragon has a reset button, however unlike the Atom, it does a soft reset (technically it checks the contents of location $71, if they are $55, then it jumps to the address stored in $72-$73, otherwise it does a cold reset).

Cheers.

Phill.
User avatar
hoglet
Posts: 10353
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by hoglet »

Prime wrote:
Thu May 27, 2021 1:50 am
I'm having a problem getting my head round how some of the pio stuff works.
Phill, if you haven't already, you need to read the chapter on the PIO in the RP2040 datasheet:
https://datasheets.raspberrypi.org/rp20 ... f#page-331

Then read it again!

It took a while for me for it to sink in how inputs are "bound" to state machines.

Take JMP PIN, LABEL as an example.

Each state machine has a register that defines *the* GPIO pin to be used in all JMP PIN instructions. So all the JMP PIN conditional branches in a state machine operate on the same signal. See section 3.5.6.

(The same limit does not apply to the WAIT/IRQ instructions, which have a 5-bit indec field that specify the GPIO directly.)

There are a few tricks that can help. Post your complete program, with a few comments, and we can try to help.

Dave
Prime
Posts: 2946
Joined: Mon Jun 01, 2009 12:52 am
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by Prime »

hoglet wrote:
Thu May 27, 2021 7:22 am
Prime wrote:
Thu May 27, 2021 1:50 am
I'm having a problem getting my head round how some of the pio stuff works.
Phill, if you haven't already, you need to read the chapter on the PIO in the RP2040 datasheet:
https://datasheets.raspberrypi.org/rp20 ... f#page-331

Then read it again!

It took a while for me for it to sink in how inputs are "bound" to state machines.
Yep I went back and had another read after posting this last night, and along with the source, I twigged that the ascociation is done in the C function at the bottom of the .pio file. It made much more sense then :)

One thing did jump out at me from the datasheet tho.....under section 3.6.6 Instructions it says : "<side_set_value> Is a value (see Section 3.3.2) to apply to the side_set pins at the start of the instruction"

Won't that cause problems with the in instructions such as :

Code: Select all

    in PINS 8               side ADDRESS_LOW            ; read data
As the select pins will be change befor the in completes, leading to possibly corrupt values? This may not be an issue on the Atom board as it's using 3 74LVC245 chips, however the (current) version of the Dragon board has an xc9536xl, that is doing the address bus buffering / conversion
along with the clocks and generating the direction for the data buffer. I suspect that may be responding quicker than the 245 and corrupting the data :(

Cheers.

Phill.
User avatar
cjm
Posts: 96
Joined: Fri Sep 01, 2017 3:19 pm
Location: Woking, Surrey
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by cjm »

Prime wrote:
Thu May 27, 2021 8:14 am

One thing did jump out at me from the datasheet tho.....under section 3.6.6 Instructions it says : "<side_set_value> Is a value (see Section 3.3.2) to apply to the side_set pins at the start of the instruction"

Won't that cause problems with the in instructions such as :

Code: Select all

    in PINS 8               side ADDRESS_LOW            ; read data
As the select pins will be change befor the in completes, leading to possibly corrupt values? This may not be an issue on the Atom board as it's using 3 74LVC245 chips, however the (current) version of the Dragon board has an xc9536xl, that is doing the address bus buffering / conversion
along with the clocks and generating the direction for the data buffer. I suspect that may be responding quicker than the 245 and corrupting the data :(
Yes, it is possible that the xc9536xl is fast enough for this to be a problem. The 74LVC245s take ~40ns for the select to take effect.

In theory overlapping the read and select minimises the time taken to read the address. However, it makes the PIO code harder to understand and only saves one clock cycle so I don't think it has any real world benefit.

Chris
Atom + YARRB + Noise Killer + HDMI adapter + Homebrew RPi-MMC AtoMMC V4
Prime
Posts: 2946
Joined: Mon Jun 01, 2009 12:52 am
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by Prime »

LOL that'll teach me.

Turns out it was working pretty much all along, it's just that the Dragon and Atom map their ASCII->VDG sets in different orders. Dragon has green 64 green on black chars, 64 black on green and then 128 SG4 semigraphics. The Atom has the characters and the SG6 interleaved :)

But now working on making things work properly.....including SG8, SG12 and SG24 modes.

Will have to think of how I perhaps want to implement the commands, as Dragon basic doesn't have a convenient way of writing a string like Atom basic does.

Now might be a good time to talk about merging my changes, what would be the best way to do that?

Cheers.

Phill.
User avatar
hoglet
Posts: 10353
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by hoglet »

Prime wrote:
Thu May 27, 2021 10:14 pm
Now might be a good time to talk about merging my changes, what would be the best way to do that?
Are you at all familiar with submitting pull requests via github?

If so, that's probably, that's the best way.

If not, the easiest way is to zip up the updated sources and attach them here, then Chris or myself can merge them in.

Either way, it would be very helpful if your changes are to the latest version of the code.

I noticed Chris made lots of changes to the PIO code a couple of days ago:
https://github.com/hoglet67/pico_atomvg ... f002c7?w=1

If you started work before that, then it's going to be more of a pain to merge.

Dave
Prime
Posts: 2946
Joined: Mon Jun 01, 2009 12:52 am
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by Prime »

hoglet wrote:
Sat May 29, 2021 9:37 am
Prime wrote:
Thu May 27, 2021 10:14 pm
Now might be a good time to talk about merging my changes, what would be the best way to do that?
Are you at all familiar with submitting pull requests via github?

If so, that's probably, that's the best way.
Well I git cloned the repo locally and have added the one new file I created with git add, but don't want to commit anything incase I screw anything up...
If you can let me know how to do the pull request will be happy to.
Either way, it would be very helpful if your changes are to the latest version of the code.
Yeah I re cloned this evening (2021-05-29) and patched that with my changes, so should be pretty recent. Have of course checked that the changes work with the Dragon. Will fire up the Atom tomorrow and check that I don't seem to have broken anything.....

What I have done is setup a PLATFORM define that can currently be PLATFORM_ATOM or PLATFORM_DRAGON What would be cool is if we could have seperate targets for those....not sure how to modify the cmake files to achieve that tho.....

Cheers.

Phill.
User avatar
hoglet
Posts: 10353
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by hoglet »

Prime wrote:
Sun May 30, 2021 12:28 am
Well I git cloned the repo locally and have added the one new file I created with git add, but don't want to commit anything incase I screw anything up...
If you can let me know how to do the pull request will be happy to.
In this case, it's probably just easiest to upload a ZIP file and Chris or myself will merge the changes in.

For future reference, the github "pull request" workflow is:
- create a github account
- install your ssh keys into whatever git client you are using
- on github.com fork the pico_atomvga repository (so you have your own copy to work on)
- git clone git@github.com:phillhs/pico_atomvga.git (replace phillhs with your actual git username)
- cd pico_atomvga
- <edit files>
- git add -u (this adds all existing modified files)
- git commit -m "Add Dragon support"
- git push origin HEAD

(Most of the above is one-time setup, or per repository setup)

At this point your fork (on github.com) has been updated and is one commit ahead of "upstream". You then can goto github.com with a browser and create a pull request.

But because you are not currently working on a fork, you can't directly follow the above workflow, so just upload a ZIP file. Once that's merged, I would suggest going through the above, so that next time it's more straight forward.
Prime wrote:
Sun May 30, 2021 12:28 am
What I have done is setup a PLATFORM define that can currently be PLATFORM_ATOM or PLATFORM_DRAGON What would be cool is if we could have seperate targets for those....not sure how to modify the cmake files to achieve that tho.....
I can add some additional targets to the CMake build system to do this.

Dave
User avatar
cjm
Posts: 96
Joined: Fri Sep 01, 2017 3:19 pm
Location: Woking, Surrey
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by cjm »

I've just cloned and built and tested the latest release - it all seems ok. Good work!

Chris
Atom + YARRB + Noise Killer + HDMI adapter + Homebrew RPi-MMC AtoMMC V4
Prime
Posts: 2946
Joined: Mon Jun 01, 2009 12:52 am
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by Prime »

Now this is weird....

I've tested this on both targets both on my Dragon board and Chris' Atom board.

With the latest firmware in 32x16 text mode, if you fill the screen with a single character say 0, which is the inverse @ you get blue/black bars starting about 1/3 of the way down the screen. This doesn't seem to be dependent on the CPU, as I tried it in both boards also disconnected from their respective machines. Yes I guess the level shifters would still be powered up, but the PIO state machines should not be doing anything as there will be no E/Phi2 clock to trigger them.

To verify the problem I commented out the signon message, and changed the fill with space loop to fill with zero.

So this leads me to wonder if we have some subtle problem with the character mode rendering code?

Here's a demo of the problem.
P1000835.JPG
Cheers.

Phill.
User avatar
cjm
Posts: 96
Joined: Fri Sep 01, 2017 3:19 pm
Location: Woking, Surrey
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by cjm »

The blue/black bars indicate that the software isn't generating the video signal quickly enough.
Are you running a "debug" build? Try a release build instead.

Chris
Atom + YARRB + Noise Killer + HDMI adapter + Homebrew RPi-MMC AtoMMC V4
Prime
Posts: 2946
Joined: Mon Jun 01, 2009 12:52 am
Contact:

Re: Interfacing an Atom to a Raspberry Pi Pico

Post by Prime »

Not sure it's a debug build......but further tinkering with the rendering function (seems to have) fixed it.....expect a pull request soon :)

Looks like there was a section of code that was running for both semigraphics and text rendering, that only need to apply to semigraphics. Shifting the code areound so it's only executed when rendering semigraphics seems to have worked....and also not broken semi graphics :)

Cheers.

Phill.
Post Reply

Return to “acorn atom and acorn system series”