clipka <nomail@nomail> wrote:
> I guess the graphics card would be perfectly fine with it - even today's
> graphics card still include backwards compatibility with VGA, if only for
> booting and just in case someone decided to run some old DOS.

  If you are having problems running old DOS programs with a modern PC,
all you have to do is to use the DosBox emulator. It's a full PC/DOS emulator
(ie. it emulates the entire hardware) and it works very well. Most DOS programs
run flawlessly and without having to configure anything. The emulator is
available for many systems (including Windows and Linux).

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   Overall, BASIC programs were quite hard to read and understand. Most
> editors in the old days did not support such a basic technique as code
> indenting (iow. even if you tried to indent the code manually, the editor
> didn't support it and you couldn't). This means that every single line of
> code started from the same column, which made reading long nested blocks of
> code a bit difficult.

I am 75% sure that the C64 would *automatically* indent your code. As 
in, if you wrote a FOR-NEXT loop, the loop body would automatically 
appear indented, and there was nothing you could do about it.

But sure, the whole concept of using line numbers for editing, must less 
flow control, is fundamentally flawed...

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> The problem with all the low-level languages like C and C++ and such is that 
> they don't really come with the libraries you need to do modern stuff. 
> There's nothing built in for threading, graphics, sound, IPC, etc. That's 
> all left to libraries developed well after the language was standardized.

  The reason why languages like C++ don't come up with libraries which would
be handy (such as graphics and sound) is complicated.

  There is no one single unambiguous, clear way of drawing graphics easily
and as efficiently as possible in all systems (never mind the fact that C++
is designed to be portable and not all computers even *support* any kind of
graphics). For example, if you were in Windows, how should a graphics library
work? Should it be a full GUI library like Qt or WxWidgets? Or should it be
simply a library which draws on some drawing surface/frame buffer, but leaving
GUI elements up to the (non-standard) system libraries? Should the graphics
be drawn using the Windows API, DirectX or maybe OpenGL? These are mutually
incompatible techniques which have their advantages and disadvantages, and
it's very difficult to create a library which would be agnostic to the choice
(and still be fully useful). Also if you wanted to draw accelerated 3D
graphics, there is no one single unambiguous, clear way of doing that either.
You could try to replicate OpenGL or something like DirectX, but since hardware
is constantly developing, the standard library would get old really quick.
It would be basically useless for anything new.

  Also such library would be highly non-portable. For example, if the C++
standard dictated some kind of GUI library, how would you implement it eg.
for the iPhone? You just can't. This would mean that for such systems you
would have to use a crippled version of the language which may or may not
compile some existing code.

  A standard library to play sounds would run into similar problems, as well
as its own. The source of the sound would be a difficult question. Usually
you would want to play a sound from a file. Which sound file formats should
be supported by a standard library? Many of the most useful formats have
license restrictions, which is something you really don't want to be using
in a programming language standard. Usually international standards for a
portable programming language try to be neutral with respect to proprietary
licensed file formats and such, for a good reason. Thus a standard sound
library would necessarily be very limited and mostly useless. It would also
probably get old quickly, as new, better formats are being developed all the
time.

-- 
                                                          - Warp

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> I blamed those "access violations" that occasionally show up on Windows. So
> their really due to a "safety" feature in Intel's hardware. Is that why
> machines with
> AMD processor's (reportedly) crash and hangup less frequently?

No, not really: AMD processors use the very same features.

They do have a fierce and long-standing competition however, as to who can get
the most computing power out of a single chunk of silicon; naturally, this
involves pushing the CPUs quite close to their limits of stable operation; if
these limits are exceeded, once in a while a glitch may occur and just throw
the computer off-track; in such a case, anything might happen then, from a
computation error, to a messed up address pointer or misread programm command
that may have the CPU's / operating system's safety measures kick in as
response.

I guess it is worth noting here that not every such access violation message is
due to a glitch in the CPU; probably the vast majority of such messages in
everyday use is due to straightforward programming errors (often flawed pointer
handling in C/C++ code). Instead, true glitches are most frequently observed by
high-end gamers trying to push the system even closer to its limits than AMD or
Intel decided to, by operating them beyond the official operational parameters
(bus clock, clock multiplier, memory access timings, voltages and the like).

The allegations about processor stability tend to change over time, too: A few
years ago, it was Intel CPUs that were considered more stable.


So to wrap it up, those "access violations" are actually the applications' fault
- even though they seem to be a rather Windows-typical phenomenon, but I
attribute this to some good degree to the fact that Windows just happens to be
the most popular target for unexperienced or lazy program authors.

Post a reply to this message

"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> In my particular example, of course, none of that applied. Being able to write
> directly to memory from BASIC on the Acorns meant you could store large amounts
> of data more efficiently without having to resort to assembler. And, since the
> screen memory was in main RAM, you could write to the screen by storing your
> pixel values directly to that block... :)

No need to tell me that - I had an Amstrad CPC, which featured 16K of display
RAM so there was plenty of poking you could do :)

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> > The first computer *I* used, the Amstrad CPC, *did* - hehe :P
>
>   Of course even in editors which did have a renum command, it would mess
> up any numbering scheme you might have been using. For example, if you
> started every subroutine using line numbers starting from multiples of 1000
> (so that you could easily remember that "this subroutine started at line
> 3000, and that one at line 5000" etc) the renumbering would mess up all
> that and you lost the semi-logical numbering.

Actually, the Amstrad CPC's BASIC was remarkably sophisticated about that,
allowing you to renumber only a subset of lines, to start from a specified new
number and at specified intervals.

IIRC, really the *only* problematic statements were GOTOs to non-existent lines,
which would by default go to the next higher existing line number; these could
indeed be broken.

Truly computed GOTOs, as far as I can remember, weren't supported by the Amstrad
CPC's BASIC (except with some obscure RSX tools) - only a "ON ... GOTO
line1,line2,line3,..." to pick one of a predefined set of jump targets.


>   Overall, BASIC programs were quite hard to read and understand. Most
> editors in the old days did not support such a basic technique as code
> indenting (iow. even if you tried to indent the code manually, the editor
> didn't support it and you couldn't). This means that every single line of
> code started from the same column, which made reading long nested blocks of
> code a bit difficult.

Still, with some discipline it was possible to write well-maintainable code.

(Though I agree that there are languages that make it far easier.)

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I am 75% sure that the C64 would *automatically* indent your code. As
> in, if you wrote a FOR-NEXT loop, the loop body would automatically
> appear indented, and there was nothing you could do about it.

I'm 99% sure it did *un-indent* the code no matter how hard you tried... (just
googled for a few C64 BASIC code snippets, and found them all not indented)

Post a reply to this message

clipka <nomail@nomail> wrote:
> Instead, true glitches are most frequently observed by
> high-end gamers trying to push the system even closer to its limits than AMD or
> Intel decided to, by operating them beyond the official operational parameters
> (bus clock, clock multiplier, memory access timings, voltages and the like).

  Many games do indeed stress the CPU and the GPU to their limits, even
without any overclocking. For regular non-overclocked systems it then
becomes a question of ventilation: If the CPU or the GPU gets too hot,
it might start glitching, in which case the game usually hangs, gives a
"this application performed an illegal operation" message or outright
reboots the computer.

  Of course in practice this is probably less common than one would think,
and by far the most common reason for games crashing is simply that the game
(or in some cases a driver, eg. the display driver) is buggy. Some games are
really stable and basically never crash, while other games seem to be
constantly crashing. This would seem to be indicative of a software bug
rather than a hardware problem (although it wouldn't be completely implausible
that the crashing game is stressing some part of the hardware that the
non-crashing one isn't).

-- 
                                                          - Warp

Post a reply to this message

clipka wrote:
> Invisible <voi### [at] devnull> wrote:
>> I am 75% sure that the C64 would *automatically* indent your code. As
>> in, if you wrote a FOR-NEXT loop, the loop body would automatically
>> appear indented, and there was nothing you could do about it.
> 
> I'm 99% sure it did *un-indent* the code no matter how hard you tried... (just
> googled for a few C64 BASIC code snippets, and found them all not indented)

Hmm. Perhaps it was the Sinclare Spectrum then...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Hmm. Perhaps it was the Sinclare Spectrum then...

  No such computer has existed. In the *Sinclair* Spectrum there was no
indentation.

-- 
                                                          - Warp

Post a reply to this message