build errors

Hi guys, just getting some build errors, probably just initial learning curve issues for me, but thought I'd try ping you here on them.

I tried pinging you on the IRC channel (EFNet #mega), but I had to go zzz, so perhaps I missed a response there (does IRC keep a backlog/history of past convos?).

Anyway, here was my Q copy/pasted from IRC:

------

[23:30] <gurce> I'm just getting my bearings with ISE Design Suite (Proj Navigator).
[23:32] <gurce> It sees two *.xise files: "c64accel.xise" and "mega65.xise". I'm guessing I need to open the latter?
[23:33] <gurce> when i do, it warns of missing "charrom.vhdl", "kickstart.vhdl" and "version.vhdl" files. I saw a git commit somewhere mentioning these were auto-generated?
[23:35] <gurce> So, I guess I need to do the build/synthesise step then. At a guess, I thought this was done via "Process >> Implement Top Module", but that gave me lots of vhdl errors inside "uart_monitor.vhdl". Anybody got any pointers on where I'm going wrong?

Just for reference in google searches, here's the sort of error output I was getting:

ERROR:HDLCompiler:104 - "C:\Documents and Settings\vets\My Documents\mega65\uart_monitor.vhdl" Line 25: Cannot find <version> in library <work>. Please ensure that the library was compiled, and that a library and a use clause are present in the VHDL file.
Parsing entity <uart_monitor>.
ERROR:HDLCompiler:854 - "C:\Documents and Settings\vets\My Documents\mega65\uart_monitor.vhdl" Line 27: Unit <uart_monitor> ignored due to previous errors.

Hmm, I had a further sniff around the source and maybe I've got an inkling of what went wrong.

I noticed that the project has a "Makefile". This observation, in addition to noticing that in Paul's logs, he mentions that he uses a Linux VM to build the bitstream, gives me the impression that the missing "*.vhdl" files will get generated if I run "make" on a linux system...

Hmm, since I already installed the ISE Design Suite on a windows system (and don't want to go through that ordeal again in Linux! :D), maybe I'd better look for alternatives that'll work in the windows world...

Perhaps Cygwin offers a version of 'make' that'll do the trick... I'll give it a go and see what happens...

Yep, Cygwin's make seems to do ok. It gets me to my next build error:

../Ophis/bin/ophis -4 etherload.a65
make: ../Ophis/bin/ophis: Command not found
make: *** [Makefile:57: etherload.prg] Error 127

I did some googling to learn more about this Ophis thingie. Aah, so it's the "Ophis Assembler":

https://michaelcmartin.github.io/Ophis/

I'm wondering if I need to download these kinda pre-reqs, or is there some Makefile or python magic that pulls them all for me?

Well, I'll keep digging, but if anyone can chip in some tips, I'd be happy to hear it

:: @Gurce added on 21 Jun ’16 · 07:17

Ah ok, the Ophis source used to be housed in the "Ophis-2.0-standalone/*" sub-folder, but it got deleted in a recent'ish commit: "Cleanup and making it work again" - 13/03/2016 07:44:16 - justburn

Not sure what's up there, perhaps the dependencies are being moved out of the repo with the intent to build them separately?

Ah well, but maybe it highlights another factor, I'm trying to build the latest code in the "origin/master" branch.

Perhaps I need to back-track to an older time, from the date of the last bit-stream release and see how I go building that... At least then Ophis will return and I can build it from there.

Okidoke, I checked my email from Andreas containing the bitstream, it was called "DDR20150928", so seems to equate to the date 28/09/2015.

I don't see any labels/tags in the git repo, so my guess is that it refers to the last commit on that date:

5993feb9994c558392d1085b97d8c62ddabedd29 - "try to fix capslock reading." - gardners - 28/09/2015 9:20:35 PM

I try building it from that point, but then get this error:

gcc -Wall -o ghdl-frame-gen ghdl-frame-gen.c
make: gcc: Command not found
make: *** [Makefile:105: ghdl-frame-gen] Error 127!

Aah, I'm going to need gcc too eh? Alrighty, hopefully Cygwin can give me "gcc" and I can tick that one off.

I'm starting to suspect that maybe a Linux VM might've been an easier environment to build it in?

Ah well, let's see how far I can go in Windows.

:: @Gurce added on 21 Jun ’16 · 15:16

Yep, Cygwin's "gcc" does the trick. But immediately after that line builds, I get another Ophis error:

../Ophis/bin/ophis -4 showthumbnail.a65
make: ../Ophis/bin/ophis: Command not found
make: *** [Makefile:44: thumbnail.prg] Error 127

Hmm, I noticed that "Ophis-2.0-standalone/ophis" within the git repo in this era is actually an executable python script... Interesting...

WORKAROUND:

So, I wonder if I could solve this problem by copying it to a location where the Makefile expects to find it? I'll do these steps inside the Cygwin Terminal:

- cd to the "mega65" path.
- cd ..
- mkdir Ophis
- cp -r mega65/Ophis-2.0-standalone/ Ophis/bin/
- cd mega65
- make

Ah awesome, the calls to Ophis now work! This makes me wonder if the latest source would now build too... I'll try that later...

With this older source, I thought I'd then try build it in ISE.

I noticed there was no "mega65.xise" project file from at that time, so I guessed I should open the "c64accel.xise" project file instead.

It seemed to complain about many more missing files. I tried doing a "Process >> Implement Top Module" action, and surprisingly, it seemed to chug away at it for a good 20 minutes before dying on some errors like this:

Checking expanded design ...
ERROR:NgdBuild:604 - logical block 'fpgamonitor0' with type 'FPGAMonitor' could
not be resolved. A pin name misspelling can cause this, a missing edif or ngc
file, case mismatch between the block name and the edif or ngc file name, or
the misspelling of a type name. Symbol 'FPGAMonitor' is not supported in
target 'artix7'.
ERROR:NgdBuild:604 - logical block 'machine0/viciv0/charrom1' with type
'charrom' could not be resolved. A pin name misspelling can cause this, a
missing edif or ngc file, case mismatch between the block name and the edif
or ngc file name, or the misspelling of a type name. Symbol 'charrom' is not
supported in target 'artix7'.

Well, that's as much as I can push on it today... Will try look into this another day...

Just as an aside from the fpga build errors, my mind wandered back to that makefile and noticed that many of the missing *.vhdl files ought to be created by a call to "make simulate"?

I gave that a try and ran into these errors:

../Ophis/bin/ophis -4 kickstart.a65 -l kickstart.list
/cygdrive/c/Documents and Settings/vets/My Documents/mega65/kickstart_dos.a65:1872: Internal error! Label Update Pass cannot understand node type PointerZ
/cygdrive/c/Documents and Settings/vets/My Documents/mega65/kickstart_dos.a65:1880: Internal error! Label Update Pass cannot understand node type PointerZ
kickstart.a65:1754: Internal error! Label Update Pass cannot understand node type PointerZ
kickstart.a65:1758: Internal error! Label Update Pass cannot understand node type PointerZ
4 errors

Looking at the "kickstart_dos.a65" source, it seemed to choke on lines like this:

sta (<dos_file_loadaddress),z

...geting upset with using z as a pointer. Not sure why as yet. I thought perhaps I could replace Ophis 2.0 with the latest Ophis 2.1 (from https://michaelcmartin.github.io/Ophis/ ), but even that reported the same error.

Will try look into that a bit more later. But as always, if anyone has any tips or pointers (no pun intended on PointerZ there ;)), please share

Tonight I wanted to focus on the Ophis errors. I think I got to the bottom of it. The backstory (as far as I can fathom it so far) is this.

- Paul is working on the new 4502 processor in this github project:

https://github.com/gardners/gs4502b

- In it, there is a newer (pre-release?) version of Ophis which seems to support the PointerZ mechanism of the processor.

So for now, as a workaround, I copied the version of Ophis out of this project and dropped it into the mega65 project.

This fixed up my Ophis error, but now "make simulate" results in this:

./makerom rom_template.vhdl kickstart65gs.bin kickstart
make: *** No rule to make target 'ghdl_ram8x32k.vhdl', needed by 'simulate'. Stop.

Hmm, I noticed ghdl was also a sub-module of the gs4502b github project too. It makes me wonder if the gs4502b and mega65 github projects need to be cloned onto your pc in a nested manner, in order for one project to make use of stuff from the other...

Maybe... Well, I'll leave that study for another day...

Hmm, I pondered the missing "ghdl_ram8x32k.vhdl" some more tonight... Couldn't really grasp whether it's a file that is genuinely missing from the repo, or if it is auto-generated in some way...

I did notice a similarly-named "ram8x32k.vhd" file, and wonder if that is related in any way to the missing file.

I suppose with the "ghdl_" prefix, it makes me recall that there was a "ghdl" sub-module inside the "gs4502b" github project, so I wonder if something in that project helps generate what's missing here...

At this stage, not all that sure though, so again, I'd be happy if anyone more cluey can fill me in on what I've missed

:: @Gurce added on 23 Jun ’16 · 13:57

Just a little mental note to self (and anyone else following along at home), Paul's log makes mention of his usage of the open-source GHDL simulation tool in this post:

https://c65gs.blogspot.com.au/…ion-of-c65gs-to-help.html

I'm hoping there might be some hints in this post that might help on my current issue of the missing "ghdl_ram8x32k.vhdl" file, but my eyes are getting really drowsy tonight, not sure if my brain can absorb much more today...

:: @Gurce added on 23 Jun ’16 · 23:21

Ok, with a bit of reading from logs and studying the following commit, I think I got my answer:

https://github.com/gardners/c6…32be4cfd988007b47cb811f42

Paul's comment was "use coregen generated 32KB colour RAM instead of my GHDL-compatible one to try to fix timing."

After studying the commit, I learnt that a "ghdl_ram8x32k.vhdl" file never actually existed, but that Paul had tweaked the internals of the "ghdl_ram8x64k.vhdl" file to act as 32k before (perhaps for quick testing purposes), and this was his commit that restored it back to normal.

This was also the commit where a "ram8x32k.vhd" file was added (the Xilinx coregen file he refers to in the commit comment), but no "ghdl_*.vhdl" equivalent was added.

So considering that, I saw three ways of me working around the problem:

===========================
[OPTION 1]:
- I'd say it's safe to remove the reference to "ghdl_ram8x32k.vhdl" in the SIMULATIONFILES list of the Makefile.
- This is because the "ghdl_ram8x32k.vhdl" never actually existed, and Paul opted for the coregen file over the ghdl file for 32k RAM
===========================
[OPTION 2]:
- It seems safe to change the SIMULATIONFILES reference from "ghdl_ram8x32k.vhdl" back to "ghdl_ram8x64k.vhdl"
- This is because that ghdl file still exists, and there was no reason to change it to a file that didn't exist
(I suspect that this didn't come up on Paul's radar at the time, as he had ditched GHDL simulations at this point, and so wasn't running "make simulate" to notice the prob)
===========================
[OPTION 3]:
- Save of copy of Paul's tweaked "ghdl_ram8x64k.vhdl" file as "ghdl_ram8x32k.vhdl"
- I did this by typing grabbing the commit version prior to tweaking it back, which is:

git show 0dc967bfbe73017db71d0a1f6399710fe0bed8e8:ghdl_ram8x64k.vhdl > ghdl_ram8x32k.vhdl

- For more accuracy, it'll probably be best to edit this new "ghdl_ram8x32k.vhdl" file and editing any text references within from saying "ram8x64k" to "ram8x32k".
(there's only 3 points in the code to change)
===========================

For now, I'll do option 3, but I'm guessing it doesn't matter a great deal which option you choose (particularly if you're not going to simulate with GHDL via "make simulate" anyway).

Edging closer towards getting "make simulate" to run properly. Here are a few other issues along the way that I've ticked off, I'll drop in here for easy google referencing in future.

==========================
[PROBLEM]
After the prior fix for the missing .vhdl file, "make simulate" progressed further, then bumped into this error:

gcc -g -Wall -o pngprepare pngprepare.c -lpng
pngprepare.c:17:17: fatal error: png.h: No such file or directory
compilation terminated.
make: *** [Makefile:141: pngprepare] Error 1

----------------------------------------

[SOLUTION]
I ran Cygwin's setup exe again and searched for "libpng-devel" and then clicked on the item in found within the "Libs" group, and installed it.

==========================

[PROBLEM]
make: *** No rule to make target '8x8font.png', needed by 'charrom.vhdl'. Stop.

Yup, this file was missing (as I'm trying to build the older-era of the source, equating to the currently released bit-stream).

This "8x8font.png" file was added by justburn's fairly recent commit of "Cleanup and making it work again" though.

----------------------------------------

[WORKAROUND]
I've retrieved it with:

git checkout ad7698ce8 -- 8x8font.png

==========================

Hmm, this experience, and seeing justburn's comment, it makes me wonder if I should revert back to using the latest revision in the master branch?

Hmm... It sounds like a good idea... But no worries, I'll stay put for now. Since even if I'm tripping over issues that have been fixed in the latest master branch, at least I'm still learning things about this project as I go, so it's not a loss.

Next prob with "make simulate" was ghdl-related:

make: ghdl: Command not found
make: *** [Makefile:86: simulate] Error 127

Paul had a sub-module reference to this in his gs4502b github repo, so I thought I'd try and configure+build that. Plenty of pain experienced there, trying to get it to build with Cygwin.

My first efforts to do "./configure" were met with:

Sorry, you need GNAT to build GHDL. See the README
(gnatmake executable is: gnatmake)

I tried getting libgnat from the cygwin setup, but it wasn't the libraries this thing is after, but the gnatmake binary.

I learnt more about how to get it properly from here:
- http://gnuada.sourceforge.net/pmwiki.php/Install/Cygwin

This gets me gnatmake:

gnatmake -o ghdl_mcode -aI./src -aI./src/vhdl -aI./src/psl -aI./src/vhdl/translate -aI./src/ghdldrv -aI./src/grt -aI./src/ortho -aI./src/ortho/mcode -gnaty3befhkmr -gnatwae -aO. -gnatf -gnat05 -g -gnata -gnatw.A ghdl_jit.adb -bargs -E -largs memsegs_c.o chkstk.o jumps.o times.o grt-cbinding.o grt-cvpi.o fstapi.o lz4.o fastlz.o

...which internally calls its own copy of gcc:

gcc -c -I./ -I./src -I./src/vhdl -I./src/psl -I./src/vhdl/translate -I./src/ghdldrv -I./src/grt -I./src/ortho -I./src/ortho/mcode -gnaty3befhkmr -gnatwae -gnatf -gnat05 -g -gnata -gnatw.A -I- /cygdrive/c/Documents and Settings/vets/My Documents/gs4502b/ghdl/src/ghdldrv/ghdl_jit.adb

...but presently, that is giving me this error:

gnat1: invalid switch: .

Can't figure that one out yet, so will ponder it next time...

Getting the code to build in windows+cygwin is proving hard slog. I'm starting to wonder if pushing too hard in this direction is worthwhile... After a while, it feels like my time gets expended with batting of cygwin-ish issues, when maybe things'll jus build nicer in linux and I can focus on the task at hand quicker.

Hmm, well, I won't give up on the windows world just yet... Will push on...

Ok, got some more insights. I fixed the "gnat1: invalid switch: ." by editing the "ghdl/Makefile" and replacing this string:

FROM: -gnatw.A
TO: -gnatwA

This dot seemed to be upsetting it. After doing so, the "ghdl_jit.adb" compiled successfully to "ghdl_jit.ali".

The "make" command then died on the next item:

gcc -c -I./ -I./src -I./src/vhdl -I./src/psl -I./src/vhdl/translate -I./src/ghdldrv -I./src/grt -I./src/ortho -I./src/ortho/mcode -gnaty3befhkmr -gnatwae -gnatf -gnat05 -g -gnata -gnatwA -I- /cygdrive/c/Documents and Settings/vets/My Documents/gs4502b/ghdl/src/ghdldrv/ghdllocal.adb
ghdllocal.adb:335:13: "Is_Executable_File" is undefined
ghdllocal.adb:1072:42: warning: pragma Unreferenced given for "Success"
End of compilation

The prob here is that the Is_Executable_File() function isn't available in the version of gnat for cygwin (v4.1.1). It's available in newer versions of gnat though.

I downloaded my version of gnat from online here:

- https://sourceforge.net/projects/gnuada/files/

Notice that the cygwin folders haven't been touched since 2006. So I'm guessing nobody has had the desire/need/appetite to build a newer version since then.

Well, since they were able to compile it back then, it offers some chance a newer version could be built for our needs here too.

Not sure if I've got the appetite for it tonight though... I've also got to weigh the benefits. If I do it, it will get gnat-->ghdl-->"make simulate" working in windows+cygwin.

Yeah, that's good, but perhaps simulate doesn't have to be my top-most goal presently. It sounds like a "nice to have" thing at this stage.

Getting the vhdl stuff to synthesise and getting a bitstream is probably a better goal to aim for at present, so I reckon it'll be time to focus on that tomorrow.

Found it hard to let go of using windows+cygwin a dev environment, so dug a bit more today.

I asked on the sourceforge forums if there was a newer version of gnat around that could work in cygwin. They pointed me to use TDM-GCC (and check the optional "ada" language in the install wizard).

Cool, that gives me a newer gnat, with a gnatmake located at "/cygdrive/c/TDM-GCC-32/bin/gnatmake.exe"

I then tried building the ghdl project inside cygwin with:

PATH=/cygdrive/c/TDM-GCC-32/bin/:$PATH make

This build seemed to be progressing well, but then failed on linkage with:

gnatlink ghdl_jit.ali -o ghdl_mcode.exe -g memsegs_c.o chkstk.o jumps.o times.o grt-cbinding.o grt-cvpi.o fstapi.o lz4.o fastlz.o
C:/TDM-GCC-32/bin/../lib/gcc/mingw32/5.1.0/../../../../mingw32/bin/ld.exe: cannot find -lz

Turns out the zlib library was missing, so that needed to be downloaded from here (both the dll & dev files) and extracted to the C:\TDM-GCC-32\ dir.

https://sourceforge.net/projec…ension/zlib/zlib-1.2.7-1/

After that, I tried building again, but got a lot of missing references during linkage.

gnatlink ghdl_jit.ali -o ghdl_mcode.exe -g memsegs_c.o chkstk.o jumps.o times.o grt-cbinding.o grt-cvpi.o fstapi.o lz4.o fastlz.o
jumps.o: In function `grt_signal_setup':
/cygdrive/c/Documents and Settings/vets/My Documents/gs4502b/ghdl/src/grt/config/jumps.c:172: undefined reference to `sigemptyset'
/cygdrive/c/Documents and Settings/vets/My Documents/gs4502b/ghdl/src/grt/config/jumps.c:182: undefined reference to `sigaction'
jumps.o: In function `grt_signal_restore':
/cygdrive/c/Documents and Settings/vets/My Documents/gs4502b/ghdl/src/grt/config/jumps.c:205: undefined reference to `sigaction'

I've run out of steam for today, but feel like I'm edging closer and closer to getting ghdl building in windows, and so hopefully getting "make simulate" working won't be too far off either... Fingers crossed...

Ok, I've come to terms with what those new errors mean.

My switch to TDM-GCC was both good and bad.

- THE GOOD: The mingw-gcc has a reasonably new version of gnat/ada (containing the Is_Executable_File() function), this means all the ada code in the GHDL project compile fine now.

- THE BAD: the GHDL source also has c-code, that makes use of functions within "signal.h" (such as sigemptyset()), which is specific to linux's glibc library. The mingw-gcc does not support glibc, as it uses microsoft's equivalent instead.

Hmm, so looks like the only path left to me is to try build a newer version of gnat so that it works with cygwin's gcc (which can make use of glibc).

Ah well, I'll try figure that out another day...

Thanks Paul,

Yeah, I was aiming for something like that, just as how Ralph's walkthrough document on setting up the hardware really helped get up to speed with that side of things, after I've finally paved out a path in windows that works, I'll create a document for it (screenshots and all, I've been gathering screenshots on the way) and was thinking of hosting such info on a wiki of some sort, so that info could be ordered/grouped/arranged in a (modestly) logical and aesthetically-pleasing way.

Just as a draft of this idea, I had prepared a mockup wiki temporarily here:

http://gurce.net/mega65

If you think it's a good approach, you're welcome to host that wiki elsewhere on a more suitable server. If you're not too keen on this approach, no worries, I can take it down, I won't take it to heart

Ah, ok, some better progress today. I realised that instead of trying to build ghdl from the source within cygwin (which was proving to be a nightmare!), a better way is to download a pre-built ghdl.exe binary from the project's sourceforge site online (they've done the hard work for me, cool!):

https://sourceforge.net/projec…s/files/Builds/ghdl-0.33/

I unzipped the "ghdl-0.33-win32.zip" into cygwin's "/opt/ghdl-0.33/" path.

I then made a symbolic link to it so that it could be run from anywhere:

ln -s /opt/ghdl-0.33/bin/ghdl /usr/bin/ghdl

...and now, finally, "make simulate" completes fine!

Whew! Well, apart from this, I haven't got much idea how to make use of whatever "make simulate" provides at this stage, but I'm glad to finally to get a point where I can now find out!

Cheers Paul, I'll give this a try when I get home.

Edging closer, but still some windows gotchyas to sort out.

Firstly, even though "make simulate" worked, I couldn't locate any resulting "cpu_test" binary outputted via it.

After reading the "ghdl.htm" docs that came with ghdl, they made a mention of why:

===================
***On GNU/Linux***, the result is an executable program called hello which can be run:

$ ghdl -r hello_world

or directly:

$ ./hello_world

-------------------------------

***On Windows***, no file is created. The simulation is launched using this command:

> ghdl -r hello_world
===================

Aah, so in our case, in windows, I need to run it as "ghdl -r cpu_test"

This gave me the following error:

C:\cygwin\opt\ghdl-0.33\bin\ghdl.exe:error: NULL access dereferenced
C:\cygwin\opt\ghdl-0.33\bin\ghdl.exe:error: error during elaboration

I noticed my winxp vbox was sluggish while ghdl was running and it was running out of RAM. So I closed it, bumped it up (from 1GB RAM to 2GB RAM), then restarted it.

Upon running "ghdl -r cpu_test" again, this time it resulted in the following error:

C:\cygwin\opt\ghdl-0.33\bin\ghdl.exe:error: overflow detected
C:\cygwin\opt\ghdl-0.33\bin\ghdl.exe:error: simulation failed

Hmm, not too sure about that one... I know the "ghdl -r hello_world" example from the html docs runs fine, so looks like the prob is unique to cpu_test in some way.

Ah well, I think I'm stumped for tonight, might have to look at this with a fresher brain tomorrow.

For the last-mentioned error (overflow detected), it sounds similar to this raised ticket:

https://sourceforge.net/p/ghdl-updates/tickets/9/

The person there said that when running ghdl in windows, the test-case exited without providing any information on which file+line-number it died on.

When running in gcc ghdl, the test-case exited with all this nice information.

Well, that was his issue raised in ghdl-0.31, the ticket was closed/fixed, and I'm using ghdl-0.33, so I'm not sure what's happened. Perhaps an old issue resurfaced.

I tried out the test cases he mentioned, it still fails in ghdl-0.33 for windows, so thought I'd better add a comment to that ticket mentioning this.

Ah gee, sorting out all these windows woes is exhausting By the time I'm done, I reckon I won't have any energy left to work on the mega65 project! Hehehe, ah well, hopefully it might mean that the next person that feels that drive/enthusiasm towards this project can overcome some of these hurdles a bit quicker and push on tackling the hurdles further ahead, making it easier for the next person, and so on...

Thought I'd press on with the cygwin-windows world, just a few more final pushes before I give up on it.

I finally realised that the cygwin setup offers you a "gcc-ada" package, and this seems to be the right thing to install (if you want tools like gnatbind and gnatmake, when building ghdl from the source).

Tristan from the ghdl ticket said he was believed the error I mentioned might've resurfaced ought to have been fixed in the latest development source.

So I tried building that, that got me a "ghdl_mcode.exe"... I tried to run "cpu_test" with it, but still no luck...

Maybe I'll brave one last try tomorrow, of trying to compile the gcc-version of ghdl, via cygwin... Maybe that might work better... Fingers crossed...