I would generally be leery of publishing your code for an assessment prior to that assessment. In practice, it's pretty unlikely that anyone will notice, but teachers can and do Google sections of students' work if they have suspicions. Obviously it's your own work, but it could make your life unnecessarily more difficult.
Your code looks alright, from a quick skim. Indeed, given the sort of heaving monstrosity that I've seen people produce, it's pretty good.
I would strongly recommend against adding 'passing parameters' as some sort of postprocessing step, though. Whilst breaking things up in this way could be viewed (is) as
refactoring, there's no reason not to do so as you write the code. Apart from anything else, this is easier - you don't end up accidentally coupling or repeating things which absolutely don't need it. As always, you have to strike a balance between creating some beautifully architected abstraction and actually Getting **** Done, of course.
I can't remember if you're taught functions (as opposed to procedures) at Higher, or UDTs - but they should really be used here; e.g. I would have UserChoice return an integer representing the option chosen and have cmdRun_Click() handle the actual calling of the relevant handler. (Actually, I would prefer cmdRun_Click() to call a separate, usefully-named procedure) UDTs will also let you have a type representing all the aspects of a graphics card, rather than maintaining a collection of independent arrays. (Your current approach is roughly 'structure of arrays' style, which does have its place, but I think the UDT is much nicer here.)
It's worth saying that both of the above are overkill for Higher, but worth bearing in mind.
Rename option1, option2, etc. to something more useful!
I would usually want to stick 'Option Explicit' at the start to ensure you have to declare things before you use them. Apart from anything else, typos will hurt you in longer programs (people write longer programs in Visual Basic?
) otherwise.
Gencode shouldn't call Randomize - this should be called once at the start of the program (e.g. in Form_Load or whatever it's called) and never again. This doesn't really affect you here, but it's a good practice - firstly, if you're reseeding the generator then you are Doing It Wrong, conceptually, since it will work fine having been seeded exactly once. Secondly, in other common situations, if you end up calling Randomize in a tight (or even not-so-tight) loop you'll find that your 'random numbers' are distinctly non-random since Randomize uses a timer value as a seed, and the frequency of your loop will be much higher than that of the timer, so you'll get the same value over and over again.
But this is mostly nitpicking. Good job.