I think the difference is quite simple.
Languages like C have a standard defined runtime that provides file I/O,
standard input and output, etc. That runtime is the specific part for the
OS it is running on, and the OS deals with the specific hardware using
drivers. So the program code just has to say it wants to print some text
or read some input, and the rest is already dealt with by other layers.
BASIC does that too. If you just want to print hello world, that will work
on pretty much any BASIC ever made, but if you want to access things that
are specific to the machine you are on you are going outside the standard
part of basic. Of course the 8 bit machines were also too small to have a
large runtime to abstract everything, so you tended to have to peek and
poke directly to the hardware instead since BASIC only provided a bit of
what you needed. Some systems of course had more advanced features in
BASIC (I think some Apple IIs had graphics commands available to simplify
access to the display).
So since BASIC doesn't have a universal standard for what features to
provide, each system has its own set of commands and often requires you to
directly mess with the hardware. The is no OS helping out and keeping
control (in the case of the 8 bit machines. Once you get to PCs or Amigas
and such, basic runs on top of the OS and no longer does direct hardware
access).
On Tue, 19 Mar 2019 at 10:07, Chris Cunnington <brasspen@xxxxxxxxx> wrote:
OK, I have an idea for a topic. I’m happy to present on it on Thursday.
But there’s a catch. It’s more of a question than a presentation.
That is to say, I have a question I’d like to get an answer to. The answer
would be in the audience.
I’d lead the discussion for 15-20 minutes to kind of pull out answers.
I’m curious about how different languages accessed the memory and chip
differently.
BASIC in the C64 and others was an exact fit to the metal. Languages on
the PC would soon evolve to add layers between specific chips and memory
chips.
C, for example, could be ported to any computer. That was it’s selling
point.
So what layers were added to make that portability possible.
The same question could be asked for every language that was ported to run
on the C64.
Maybe the question is easiest asked by asking what problems would somebody
face porting a given language to the C64.
I think that question might illustrate the relationship between the
memory, chip, bus, etc. in an interesting way.
As you can see, I’m not sure what I’m talking about, but I think asking
the question in this way could be interesting.
FWIW,
Chris
On Mar 19, 2019, at 9:54 AM, Leif Bloomquist <leif@xxxxxxxxxxxxxxxx>wrote:
happen!
Hi all,
As discussed at the TPUG AGM, we are looking for more membership
involvement in running the monthly "chapter" meetings.
This means suggestions for meeting topics, volunteers to give
presentations or demos, arrange guest speakers, or other suggestions.
We don't have to stick with the usual meeting format either! Really
anything Commodore (8 or 16 bit, or modern) or retrocomputing in
general is fair game.
What would *you* like to see and do at the monthly meetings? What
would *you* like to share with the group?
The Commodore scene and retrocomputing in general are more vibrant
than ever, so there's lots to explore. I'm happy to help coordinate.
Let's hear your ideas, suggestions, and some volunteers to make them
Thanks,
-Leif
