" I compiled two of the programs and ran them using DOSBox. The first, RANDOM.BAS, was used to create disks of random numbers to be used as a one time pad" It’s not a one-time pad if it’s generated by a basic program! If you’re going to the bother of shipping a one-time pad, it had better be based on a true hardware random number generator! Otherwise you might as well just send the (probably 32 bit) seed for the PRNG used by the basic program. This was well known even back in the 80’s. In fact something similar was discussed in our first-year CS class in '77. (Mind you at least two of our lecturers had worked at Bletchley Park.)
Technically correct! Let’s call it a pseudo-one-time-pad, as we’re using pseudo-random numbers. You and I know that the seed and the algorithm are sufficient to reconstruct the output, from the beginning. Reconstructing it from the middle is just a little harder.
I think I’ve never done it - surely I’d remember - but we probably have the compute and the brains these days to try to reverse a simple pseudo-one-time-pad, given a page of output. I think it would still be quite a challenge! And I suspect the 1980s secret police - our adversary - would find it easier to use their techniques of raids, intimidation, infiltration, and worse, than to do the mathematics and the programming.
Still, it could be an interesting programming challenge. Just for fun, here are some random bytes from a very short Basic program: 246 253 73 68 7 48 185 139 6 244 20 173. That should be enough!
It is: just not a very good one, especially if it’s implemented badly. Hardware random number generators were effectively unobtainable for pre-2000 PCs. And the Vula code doesn’t just spit out RND() output. The routine (which starts here: jgc-vula-september-2024/RANDOM.BAS at 09ed3da13a2d69bb61118a7c972ba254b3e54d70 · jgrahamc/jgc-vula-september-2024 · GitHub) makes multiple rounds over the data blocks, hopping (pseudo-)randomly between different (simple) algorithms.
Since there’s no evidence that the Vula transmissions were ever intercepted and decoded by the apartheid regime, it might have been good enough. Not that anyone’s ever going to let on that they broke an encryption method …
You could get pretty high quality random numbers from looking at the timing of random events such as keystrokes. I posted https://ftp.funet.fi/index/crypt/archive/idea.sec.dsi.unimi.it/code/386bsdkeystroke-rangen.c in 1993. Which is definitely pre-2000 
Yes, it was slow, but I would leave it running all the time and soon enough it would accumulate enough data to be useful. The main thing about an OTP is that you had to physically transport it securely to the other user in advance of it being needed. If it got there without interference, you could use it. If it was intercepted en route, you abandoned it and waited for another one. That’s the main reason they weren’t used much and the reason so many naive amateur cryptologists would use pseudo-rngs where both ends of the conversation would create matching pseudo-OTPs from some seed with insufficient entropy… frequently something that once the obfuscation was removed, ultimately boiled down to being a 32-bit integer … making all possible sequences enumerable, if you knew the algorithm and had the resources.
Which, as detailed in related articles, they had a pretty good physical pipeline for getting the OTPs through to South Africa: passenger aircrew sympathetic to the cause.
Vula may have not run for very long (mid 1988 to mid 1990, at best), may have been a little late to provide world-changing intelligence to ANC leaders, and may even have been the cause of later in-fighting between ANC factions. We know that it doesn’t provide what we’d class as an acceptable level of security today. But for a while, it did what it was designed to do. Is that about all we can hope for from our software?