Chinese FPGAs

[hoglet]

I've tried "GOWIN Programmer V1.9.8.11 Education Edition (Linux)" but it only appears to contain the programmer and not the IDE.

I've also tried "Gowin Programmer V1.9.9 Beta-4 Education (Linux)". This contains both the programmer and the IDE. However, the IDE produces a lot of errors when I try to build AtomFpga. I'm not sure whether this is because it's a beta version, or whether I'm doing something wrong.

I've attached the log file in case it helps.

I was using 1.9.8.11 Education (on Linux), but as you say, it looks like that version is no longer available.

I also recall having problems with 1.9.9 Beta something.

Let me have another look tomorrow.

Do you want to be able to build this yourself? If not, I could just post the FPGA bitstream files.

Dave

[Grasshopper]

Do you want to be able to build this yourself? If not, I could just post the FPGA bitstream files.

Dave

Thanks. The latter would be fine for the time being.

[hoglet]

Do you want to be able to build this yourself? If not, I could just post the FPGA bitstream files.

Dave

Thanks. The latter would be fine for the time being.

I'll try to upload something tomorrow.

I've attached the log file in case it helps.

The warnings are expected; the error is not:

Code: Select all

ERROR  (PA2122) : Not support 'dpb_inst_0'(DPB) WRITE_MODE0 = 2'b10, please change write mode WRITE_MODE0 = 2'b00 or 2'b01.

Looks like for some reason they have dropped WRITE_MODE 2'b10 (Read before Write). You could try just changing the write mode back to 2'b00 in dpram_8k.vhd (in 8 places in this file) and see if you get any further.

Dave

[hoglet]

Looks like they have recently dropped some features from the BSRAM:
http://cdn.gowinsemi.com.cn/UG285E.pdf

Look at the last comment:

I think that explains why the latest software is giving an error.

The documentation of these write modes is pretty much non-existant. We were seeing some wierd issues with Asteroids, and switching to "Read before Write" fixed them. I have no idea why.

I'll download the latest software tomorrow and have a play.

Dave

[Grasshopper]

I'll download the latest software tomorrow and have a play.

Hi, I'm wondering whether you've managed to make any progress?

If anyone's interested, I've created a small script that will install the dependencies needed to build FPGAloader on Linux (see attached). It was designed for MX Linux 23 but it might work with other Debian based distributions.

[hoglet]

Hi, I'm wondering whether you've managed to make any progress?

Sorry, I've not had time to look at this yet.

Let me take a look now...

You could try just changing the write mode back to 2'b00 in dpram_8k.vhd (in 8 places in this file) and see if you get any further.

Did you try making this change? It should fix the errors.

Dave

[hoglet]

Let me take a look now...

OK, I've pushed a change that fixes the errors in dpram_8k when building with 1.9.9 Beta 4 Education Edition.

That builds and runs fine for me now.

Dave

[Grasshopper]

Let me take a look now...

OK, I've pushed a change that fixes the errors in dpram_8k when building with 1.9.9 Beta 4 Education Edition.

That builds and runs fine for me now.

Dave

Thanks for doing that. However, it looks like I might be able to use version 1.9.8.11 of the IDE after all.

I've just revisited the "Download GOWIN EDA" section of Gowin's website to see whether a new version of their software is available. It wasn't. But I then had a look at their "documentation database". It turns out that this database contains software as well as documentation.

More importantly, the documentation database contains another version of the Gowin_V1.9.8.11_Education_linux file, and this version of the file does contain the IDE software.

Direct links to the two files are as follows:

https://www.gowinsemi.com/upload/databa ... 50069c.zip
https://cdn.gowinsemi.com.cn/Gowin_V1.9 ... nux.tar.gz

The tar file is the one that contains the IDE executable.

I'll have another go this evening.

[Grasshopper]

I'm pleased to report some progress.

I've managed to build AtomFpga using version 1.9.8.11 of the IDE.

I've also successfully run the two openFPGALoader commands detailed in the wiki. They initially produced error messages. But that was fixed by running them as root.

I can now see an "ACORN ATOM + ATOMMC2" message on the screen when I boot the Tang Nano. Unfortunately, I can't proceed any further as I haven't yet bought the components to wire up a ps/2 keyboard. I might need some help doing that, but that's a job for another day.

Thanks for your help so far.

[hoglet]

Thanks for your help so far.

You're welcome!

[Grasshopper]

Hi Dave,

I've just come across a thread that suggests that some versions of AtomFpga support changing the palette in ways that were not possible on an original Atom. So for example, it's possible to play Chuckie Egg with a black background.

viewtopic.php?t=18370

If this feature built into the Tang Nano version of AtomFpga?

[hoglet]

If this feature built into the Tang Nano version of AtomFpga?

Sorry, that feature is only available in the build of AtomFpga for Roland's Atom2K18

The palette code was added by Roland, and exists in the top level module that is build-specific.

Do you have a keyboard working yet?

Dave

[Grasshopper]

Do you have a keyboard working yet?

Unfortunately not. I've ordered the parts, but they haven't arrived yet.

[Grasshopper]

I finally found a bit of time to solder on the header pins and connect the keyboard. To my surprise it worked first time.

For my own future reference, I connected the level shifter board as follows:

Code: Select all

Pin Label	Connects to:

HV1		CLK pin on PS/2 socket
HV2		DATA pin on PS/2 socket
HV		+5V pin on Tang Nano, +5V pin on PS/2 socket
GND		GND pin on PS/2 socket
HV3		n/a
HV4		n/a
LV1		pin 25 on Tang Nano
LV2		pin 26 on Tang Nano
LV		3V3 pin on Tang Nano
GND		GND pin on Tang Nano
LV3		n/a
LV4		n/a

[Grasshopper]

My next step (once I’ve bought the components) will be to connect a speaker.

Can someone clarify how the two resistors and capacitor should be wired up? I’m guessing that the capacitor should be connected in parallel with the speaker, and the two resisters in series, but this is not clear from the documentation.

Also, is there a way to get the audio to output through the HDMI connector?

Thanks

[hoglet]

My next step (once I’ve bought the components) will be to connect a speaker.

You need to be using a powered speaker with a line level input.

Can someone clarify how the two resistors and capacitor should be wired up? I’m guessing that the capacitor should be connected in parallel with the speaker, and the two resisters in series, but this is not clear from the documentation.

Sorry, there was a typo in the wiki page - the capacitor should be 4.7nF, not 4.7uF.

It will work without the capacitor, but the sound might be a bit harsh.

Connections are like this:

Code: Select all

IOB13A      +-----------+
Pin 29 -----+    3K3    +--------+-------------------> Line level
            +-----------+        |                     audio signal
                                 |
IOB13B      +-----------+        |
Pin 30 -----+    3K3    +--------+
            +-----------+        |
                              =======   4n7
                              =======  Capacitor
                                 |
                                 +-------------------> Line level
                                 |                     audio ground
                               --+--
                                ---
                                 -

Also, is there a way to get the audio to output through the HDMI connector?

There is HDMI Audio with BeebFpga, but not currently with AtomFpga.

Dave

[Grasshopper]

Connections are like this:

Code: Select all

IOB13A      +-----------+
Pin 29 -----+    3K3    +--------+-------------------> Line level
            +-----------+        |                     audio signal
                                 |
IOB13B      +-----------+        |
Pin 30 -----+    3K3    +--------+
            +-----------+        |
                              =======   4n7
                              =======  Capacitor
                                 |
                                 +-------------------> Line level
                                 |                     audio ground
                               --+--
                                ---
                                 -

Thanks. I wouldn't have guessed it was wired up that way.

There is HDMI Audio with BeebFpga, but not currently with AtomFpga.

That's a shame. Is that feature likely to be added any time soon?

If the answer is no then it occurs to me that, as an alternative, I could wire up the optional VGA socket, and then use a cheap converter to combine the VGA and audio signals into a single HDMI signal.

For example, one of these might do the trick.

https://www.amazon.co.uk/Multibao-Conve ... L1SS&psc=1

Unfortunately, the wiki makes no mention of how to wire up the VGA connector. Has this feature actually been implemented and tested?

Thanks

[hoglet]

That's a shame. Is that feature likely to be added any time soon?

Well, it's on my radar screen now and I've logged an issue so I don't forget.

Unfortunately, the wiki makes no mention of how to wire up the VGA connector. Has this feature actually been implemented and tested?

VGA is implemented - you can see the VGA pin assignment in the .cst file:
https://github.com/hoglet67/AtomFpga/bl ... 9K.cst#L25

The R/G/B signals need connecting via 120R resistors (so the level is reduced from 1.8V to 0.7V).

The HS/VS signals can be connected directly.

Dave

[Grasshopper]

Hi Dave,

I've just been creating a list of the parts that I'll need to (hopefully) finally complete this project. However, I've realised that I still have a few additional questions:

• In your previous reply, you said that the HS & VS VGA signals could be connected directly. Are you saying that they should definitely be connected directly, or are you saying that ideally they should be connected using 120R resistors but that you can get away with connecting them directly?
• The Acorn Atom (and BBC Micro) only has mono audio output. But I've just realised that all of the speakers that I'm likely to connect this board to are in stereo. So can you advise me how I can connect a mono signal to stereo speakers so that the mono signal is output to both speakers simultaneously, with no loss of volume or quality?
• For the sake of completeness, I'd also like to wire up the ps/2 mouse connector. But I'm not sure how to test it. Is there any Atom software that actually supports a mouse?
• Is this project now essentially finished, at least from a hardware perspective? The reason I ask, is because at some point, I'd like to transfer the design to vero board. But I won't do that just yet if there are likely to be further changes or enhancements.
• Once the Atom core is fully working, I'd like to flash the BBC Micro core to my second Tang Nano 9K. Should the ps/2 keyboard etc. be wired up in exactly the same way for that core?

Thanks for your help.

[hoglet]

[*]In your previous reply, you said that the HS & VS VGA signals could be connected directly. Are you saying that they should definitely be connected directly, or are you saying that ideally they should be connected using 120R resistors but that you can get away with connecting them directly?

I'm currently connecting them directly.

HOWEVER...

The pins I'm using for the dedicated VGA interface have 1.8V levels, which is far from ideal. They really should be level shifted up to proper TTL levels.

Adding a 120R resistor given a small amout of additional protection to the FPGA, but will potentially reduce the levels even further.

You really need to test this with the monitor you are intending to use.

Or better still, use HDMI. And as a bonus you'll get more colours.

On the Atom Core (but not currently on the Beeb Core) the VGA signals are duplicated to a second set of outputs called the gpio bus, and these outputs are 3.3V levels. But these outputs are multipurpose. So if you ever wanted to use the 6502 bus tracing feature (e.g. for debugging a machine code program) you would loose this copy of the VGA signals.

Sorry it's a bit complicated, that really just reflects this being more of an experimental project!

[*]The Acorn Atom (and BBC Micro) only has mono audio output. But I've just realised that all of the speakers that I'm likely to connect this board to are in stereo. So can you advise me how I can connect a mono signal to stereo speakers so that the mono signal is output to both speakers simultaneously, with no loss of volume or quality?

You can just connect the mono output signal to both the left and right line level inputs at the same time. There shouldn't be much of an impact on volume or quality, as the input impedence of a line level input should be quite high.

[*]For the sake of completeness, I'd also like to wire up the ps/2 mouse connector. But I'm not sure how to test it. Is there any Atom software that actually supports a mouse?

Kees has written a ROM called Atomic Windows that uses the mouse. I think there are some demos written for Atomic Windows.

If you just want a quick test, this should print the mouse X/Y coordinates:

Code: Select all

DO P.?#BDE8,?#BDE9$13;U.0

I haven't tested this myself, but if it doesn't work I can investigate.

[*]Is this project now essentially finished, at least from a hardware perspective? The reason I ask, is because at some point, I'd like to transfer the design to vero board. But I won't do that just yet if there are likely to be further changes or enhancements.

This is a hard question to answer. I'm not actively working on it, but if anyone reports an issue than I'll try to fix it. I'm not planning any changes to the pin assignment.

[*]Once the Atom core is fully working, I'd like to flash the BBC Micro core to my second Tang Nano 9K. Should the ps/2 keyboard etc. be wired up in exactly the same way for that core?

Yes, the idea was to make the two cores compatible, so they use identical .cst files.

I have a single breadboard that I'm using for both systems. Eventually I'll get around to designing a PCB, if someone else doesn't do that first.

Dave

[Grasshopper]

I'm currently connecting them directly.

HOWEVER...

The pins I'm using for the dedicated VGA interface have 1.8V levels, which is far from ideal. They really should be level shifted up to proper TTL levels.

Adding a 120R resistor given a small amout of additional protection to the FPGA, but will potentially reduce the levels even further.

You really need to test this with the monitor you are intending to use.

Or better still, use HDMI. And as a bonus you'll get more colours.

On the Atom Core (but not currently on the Beeb Core) the VGA signals are duplicated to a second set of outputs called the gpio bus, and these outputs are 3.3V levels. But these outputs are multipurpose. So if you ever wanted to use the 6502 bus tracing feature (e.g. for debugging a machine code program) you would loose this copy of the VGA signals.

Sorry it's a bit complicated, that really just reflects this being more of an experimental project!

Thanks for the advice.

In light of the issues you've highlighted, I think I'll park the idea of adding a VGA port for the time being (although I'll still buy the components).

My main motivation for adding a VGA port was so that, with the aid of a suitable VGA to HDMI adapter, the Atom's audio signal could be output through the HDMI port. However, as you've indicated that HDMI audio will eventually be added to the AtomFpga core, I might just live with a separate audio connector for the time being.

That being said, I do own quite a few old CRT monitors, and it would be quite nice to be able to connect the board to one of those monitors through VGA, for the sake of authenticity.

One thing I've noticed when running AtomFpga on one of my more modern HDMI monitors, is that the text looks far too wide. This is presumably because the Atom was designed to be used with a 4:3 aspect ratio monitor, whereas most modern monitors have a widescreen 16:9 aspect ratio. I presume that BeebFpga exhibits the same behaviour?

Is this something that could possibly be addressed in the future? It occurs to me that the AtomFpga core could be amended so that it optionally outputs a wide VGA (FWVGA) resolution of 854*480 instead of the standard 640*480. You could then add 107 pixels to the left and right margins, and the usable display area in the centre of the screen would display with a correct 4:3 aspect ratio on a 16:9 monitor. Does this sound feasible?

[hoglet]

One thing I've noticed when running AtomFpga on one of my more modern HDMI monitors, is that the text looks far too wide. This is presumably because the Atom was designed to be used with a 4:3 aspect ratio monitor, whereas most modern monitors have a widescreen 16:9 aspect ratio.

The Atom core outputs standard 640x480 60Hz DVI signal (hence the lack of audio). I would hope that a modern HDMI monitor would handle this, and provide an option for displaying it at the correct aspect ratio. What make/model monitor are you using?

I presume that BeebFpga exhibits the same behaviour?

Actually, the Beeb core is different. It outputs a 720x576 50Hz HDMI wih audio and aspect ratio signalling.

Is this something that could possibly be addressed in the future? It occurs to me that the AtomFpga core could be amended so that it optionally outputs a wide VGA (FWVGA) resolution of 854*480 instead of the standard 640*480. You could then add 107 pixels to the left and right margins, and the usable display area in the centre of the screen would display with a correct 4:3 aspect ratio on a 16:9 monitor. Does this sound feasible?

Adding alternative video mode is quite a lot of work. You are the first person to have asked for this. I'm probably not going to do this, as I think it would only benefit a minority of situations (16:9 monitors that don't allow the aspect ratio to be controlled). It's probably less work to switch from DVI to HDMI.

Dave

[Grasshopper]

Adding alternative video mode is quite a lot of work. You are the first person to have asked for this. I'm probably not going to do this, as I think it would only benefit a minority of situations (16:9 monitors that don't allow the aspect ratio to be controlled). It's probably less work to switch from DVI to HDMI.

OK. Fair enough. I was hoping it might be an easy feature to add. But if not, it's a minor problem I can live with.

I had a quick play with the Atom software archive last night. I only had a 64GB SD card available, but to my surprise it worked.

[hoglet]

OK. Fair enough. I was hoping it might be an easy feature to add. But if not, it's a minor problem I can live with.

What make/model monitor are you using?

Grasshopper, do you mind answering this question from earlier in the thread? It's always helpful to know what monitors are problematic.

Dave

[Grasshopper]

What make/model monitor are you using?

Grasshopper, do you mind answering this question from earlier in the thread? It's always helpful to know what monitors are problematic.

Dave

Well the monitor I'm currently using does actually support setting a 4:3 aspect ratio. But that's not really the main issue.

There are essentially two reasons why I think it's preferable for the aspect ratio to be controlled by the connected device itself rather than through the monitor settings.

The first is that I have a habit of using a single monitor connected (via different inputs) to several devices simultaneously. I do this because I haven't had muck luck with KVMs. Unfortunately, in my experience, monitors have a tendency to behave unpredictably when you switch from one input to another, when each of the input devices is supposed to have a different set of settings. So, unless all the settings are the same, I end up having to manually change the monitor settings each time I switch inputs. This is not the end of the world of course. But it is still slightly annoying.

The other reason is purely aesthetic. When you set a 4:3 aspect ratio using the monitor's settings, you end up with black bars on the left and right hand sides of the display. This doesn't matter when emulating a BBC Micro, because the BBC Micro only supports black borders. But most of the Acorn Atom's screen modes have green borders. So, you end up with black outer borders and green inner borders which looks a bit weird to me. I think it would look more correct for the green borders to extend to the far left and far right of the display. This is essentially how the Atom's display would have looked on an old TV where the borders extended into the overscan area. But like I said, it's a minor issue that I can live with.