• Please review our updated Terms and Rules here

Why does building something from Github have to be in a "secret" language and needlessly archaic with no real instructions?

Al, but I did try watching about 5 videos on becoming familiar with Github. Unfortunately all the ones I trudged through were about what GIT is and starting your own project. None were about understanding and navigating someone elses project, And it seems most were based around 100% software repositories not hardware. Trust me I was searching. I just didnt find any that explained it well.
I forgot the sarcasm emoji. Written documentation apparently now is an 'old person' thing. You are expected to sit though an hour-long video now of something
that could be explained in a couple of pages with a handful of pictures/diagrams

The problem isn't with the repository, it is the lack of information on dependencies or what the original build environment/toolchain was
I have a directory of maybe 100 projects I've cloned, and most won't build in my world.

Microcontroller build chains are the absolute worst. Look at the pain people go through trying to write bare metal code for Pi Picos as an example.
 
Inferring that its not a straightforward approach to use the repositories?
Well, I generally don't use compiled code as-is from github repositories. I'm more interested in how something is done--and then I write my own code, or adapt the source.

Anent Al's comment--what I've submitted for MCUs generally uses the gnu compilers. No IDEs or fancy mixtures of 4 languages--libraries used must also be open-source and readily available.
 
Well, I generally don't use compiled code as-is from github repositories. I'm more interested in how something is done--and then I write my own code, or adapt the source.
You also can't count on what is there to even be correct (i know you can't comment on this but I found it funny)
This code is wrong
None of the implementations out there were handling multiple sections of compression in a sector correctly
before this weekend or doing sector checksum verification. Apps like HxC don't do verification and can dump
uninitialized data to the sectors they output.
And apparently no one noticed.
 
Microcontroller build chains are the absolute worst. Look at the pain people go through trying to write bare metal code for Pi Picos as an example.

I personally spent several evenings in that Hell. All I wanted to do was to compile a simple test program (like "Blink") for the Pico from C++ source, *not* by uploading the pre-built TinyPython EF2 file and blinking an LED in Python.

Part of the Hell was my own making - I intentionally chose to use the machine in front of me, which was *not* a Debian variant. It was a lot of effort to get the right version of cmake, the right ARM cross-compiling environment, etc.

I've had zero toolchain problems in the past with AVR and Expressif MCUs (ESP8266, ESP32). The Pico toolchain experience was multiple levels of suck.
 
I'm a BSD and Linux person mostly with the odd Pi, Arduino and ESP thrown in as well, but I find that regardless of the platform or language, most source packages work well with a few tweeks here and there, as long as you don't what something a little different or the latest version and can still get access to all the required source.

Knowing the origional build environment helps, but achiving that exact same environment can be near impossible.
The use of OS containers in your favourite flavour does improve the odds of success.

I suppose those of us [un]fortunate enough to have being building from source for a while longer do find it easier, but that is usually by experiencing all the pain along the way.
With Linux it is usually library version hell, with BSD, "it only runs on Linux".


Sometimes I even try stuff just see if it is possible, like making a FreeBSD version of the Modoboa installer that is now 90% working and the last 10% manual changes.

So, don't expect it to be easy and the more you stick at it the more you learn for next time.
 
To be fair, I use stdint and stdbool as part of every gcc project I scribble. Not absolutely necessary, but they do make data types a bit more explicit. Also, it's good to #define a string for non-universal features, such as this:
Code:
#define PACKED __attribute__ ((__packed__)) 
...
typedef struct PACKED ...
Not every compiler follows the gcc conventions. For example, MS C uses either /Zp on the command line or a #pragma in the code.
When dealing with hardware interfaces or imported data, packed data structures are often necessary.

I've seen USB descriptors done as arrays of individual unsigned characters, with no symbolics in them at all. The web is great for propagating Horrible Examples.
 
Last edited:
Am I the only one who thinks you're asking a bit much?
Maybe not the only one but I really really cant understand how that is your viewpoint......

So because he offers no clear or concise instructions, I am therefore not up to the task and should outright buy it? Is that what you are implying? Thats nuts.




And Tindie has no instructions on the build.. Why would it? They are offering it up for sale.

Edit. And I cant believe I need to say this but of course I am grateful to the whole open source community and people who put projects up for everyone to share in. My problem is not with them but the seemingly systemic lack of documention, instructions, and communication. Thats what I am getting at.
 
Last edited:
I was able to clone it without problem:
Code:
git clone git@github.com:V2RetroComputing/analog.git
cd analog
git submodule update --init

The project this is based on seems to have very thorough instructions for the components:
https://github.com/markadev/AppleII-VGA/blob/main/pico/README.md

Maybe you should ask for your money back?
thank you for the link and I will try to commands. Cloning it wasn't my issue I could download the files as Chuckg mentioned. And I don't like admitting the seat that's why I started the thread I was looking at more information to understand how to build the files with the make shell scripts Etc
 
Maybe you should ask for your money back?

The ultimate definition of "free" software
You are free to waste your time figuring out what I did, because I don't care enough to make it
so you can easily replicate my work.

The equivalent in the old days was selling a "kit" that was nothing but a bare pcb and a schematic.
The world has grown past all of that nonsense, hasn't it?
Except now, the information may be out there, in someone's project fork that you probably won't be
able to find with today's biased web searches.
 
Can someone who speaks the super secret language and has a happy little decoder ring tell me honestly HOW to build the software?

I mean I need a JED file to load the gal.. I know that much ... But where are the instructions?
I think the basic mechanics of getting the source (using git or download) is not the problem here, nor is loading up the design files in kicad and plotting gerbers (although this repo has gerbers). The build is a bit complicated. Just to give it a try, I cloned the repo, and the clone of the repo and submodules was as described, but downloading a .ZIP for each submodule would work as well.

I can see why this would be tough without any instructions, and not too bad with good instructions.

Most hobbyists will have some awareness of Make. This project uses Cmake, so you'd have to know to install cmake on your machine and make sure it's in your path. For Linux or Mac it's easy (apt install cmake / port install cmake). For windows it's there's an MSI you can download form cmake.org, but you'd have to know where to find it, and for any platform you'd need to know that you need it in the first place.

I did what anyone familiar with cmake would normally do for a cmake build: I created a 'build' directory, switched to it, and tried 'cmake ..' However, that crashed because an environment variable was not set to point to the PICO toolkit. I had to clone that (the github link was in the error message), and inspecting the CMakeLists.txt file, I realized that cmake looks at the build directory name to determine what features are enabled in a build. Luckily there is a build.sh script that creates directories for all the configurations, but it won't do so if there's already a 'build' directory, so I had to delete the 'build' directory first, then run the script, which then crashed because the ARM compiler could not be found. After figuring out what compiler I needed, and discovering the macports name for the package, I had to download and install the arm compiler (port install arm-none-eabi-gcc). Macports elected to compile the entire compiler toolchain, which took a while on my 2009 Mac Pro, and afterwards, I deleted the 'build' tree once more and ran the 'build.sh' script, and it build everything.

It would also be very easy for the developer to set up a github-actions build and generate all the binaries automatically to make them available for download so people don't need to go through all those steps unless they are modifying the code.

The instructions for the firmware build would be:

0) If you are running Windows or MacOS, you might want to consider adding a package system. This is not strictly necessary, but will make things much, much easier.
1) You probably want git, and you will need a shell like sh or bash:
  • Linux:
    • sudo apt install git
  • Mac: Both are natively installed, but you probably want the latest git:
    • sudo port install git
  • Windows:
    • Download Git for Windows from https://gitforwindows.org/
    • Also, to get Make and other utilities, Download the Git for Windows SDK from the bottom of the page at https://gitforwindows.org/
    • OR, you can use chocolatey to install git. I believe this installs bash, but not sure if make & friends get installed, so you may still need to download the SDK as above.
      • choco install git -y
2) Download or clone the firmware repository from github
  • git clone git@github.com:V2RetroComputing/analog.git

3) Download the pico sdk from https://github.com/raspberrypi/pico-sdk, or clone it: git clone git@github.com:raspberrypi/pico-sdk.git

4) Download and install the ARM GCC compiler:
5) set the environment variable PICO_SDK_PATH to point to the downloade/cloned pico sdk, and run the build script:
  • PICO_SCK_PATH="$HOME/my_path_to_pico_sdk" bash build.sh
 
Sort of the hacker's version of "If you lived in Boston, you would know where that is." Or, in rural parlance, "Just go past where the McCoy farm used to be before it burned down and then turn right just before the big sycamore that blew down 10 years ago."
 
I mean I need a JED file to load the gal.. I know that much ... But where are the instructions?

I’m not sure it’s a terribly unreasonable expectation to assume that someone who has the wherewithal to flash a GAL should have a nodding familiarity with the standard tools associated with them. I guess I’d feel differently if this was something explicitly aimed at beginners, but the vibe I get from this repo is this is mainly here as an obligation because the guy who’s manufacturing these for sale based it on an open source project which, as is noted above, did have better documentation. (Presumably because he was actively trying to recruit collaboration help and *not* churn out things for sale.)

Anyway, with the repo with the GAL source being nothing but a .pld (which is the GAL source) and a .bat file this is where ”read the source”, the inevitable cost of free software, comes in. A quick peek at the batch file reveals you need WinCUPL to compile the .pld to a .Jed; how that gets burned into the GAL is beyond the scope because that of course will rely entirely on the software your particular programmer uses.
 
I understand the frustration with using some of these tools, but the project noted here is a pretty complicated one with 3 target systems to program (apple II, raspberry pi, and GAL). It is not for beginners. Expecting the developer to document how to use the 3 tool chains is a bit much, especially since there are multiple build platforms someone could use. Then the developer gets to spend all of their time updating documentation for somebody else's sdk whenever it changes, instead of working on their own project. Or, they script the entire toolchain build and it is soon outdated and users complain about it installing old versions of the software. People complain either way, so I can see the temptation to just not do the extra work.

Even so, the original developer included the Pico SDK build script:
https://github.com/markadev/AppleII-VGA/blob/main/pico/cmake/pico_sdk_import.cmake

I suspect the new developer did not include this so they would not have to support it, or so you would just give up and buy the card from them.
 
I understand the frustration with using some of these tools, but the project noted here is a pretty complicated one with 3 target systems to program (apple II, raspberry pi, and GAL). It is not for beginners. Expecting the developer to document how to use the 3 tool chains is a bit much, especially since there are multiple build platforms someone could use. Then the developer gets to spend all of their time updating documentation for somebody else's sdk whenever it changes, instead of working on their own project. Or, they script the entire toolchain build and it is soon outdated and users complain about it installing old versions of the software. People complain either way, so I can see the temptation to just not do the extra work.

Even so, the original developer included the Pico SDK build script:
https://github.com/markadev/AppleII-VGA/blob/main/pico/cmake/pico_sdk_import.cmake

I suspect the new developer did not include this so they would not have to support it, or so you would just give up and buy the card from them.
Loading up a gal or a pi pico is not complicated. Understanding where to find the files to do so just so happens to be complicated.... Apparently... for some unknown reason.

Your last statement might just be true... I cannot say.
 
Maybe not the only one but I really really cant understand how that is your viewpoint......

So because he offers no clear or concise instructions, I am therefore not up to the task and should outright buy it? Is that what you are implying? Thats nuts.




And Tindie has no instructions on the build.. Why would it? They are offering it up for sale.

Edit. And I cant believe I need to say this but of course I am grateful to the whole open source community and people who put projects up for everyone to share in. My problem is not with them but the seemingly systemic lack of documention, instructions, and communication. Thats what I am getting at.
Well, he offers something for free on GitHub. A lot of work has probably already gone into this project. You get something for free and complain it's not enough (Which might be true for you, I agree, but: Bad luck, no free beer today).
 
Well, he offers something for free on GitHub. A lot of work has probably already gone into this project. You get something for free and complain it's not enough (Which might be true for you, I agree, but: Bad luck, no free beer today).
"you get something for free" I have? What have I gotten?

"complain its not enough" Huh...



Dont put words in my mouth. I am saying there is no real documentation. Others confirmed this. And the title of the the thread is about github as a whole. Im not singling out the creator of the project I am trying to build.
 
Last edited:
Back
Top