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

Bill Pragnell wrote:
> "clipka" <nomail@nomail> 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... :)
> 
I don't think you meant to imply that other PC BASIC's didn't have Peek 
and Poke functions.
The BASIC in PET and TRS-80 certainly did and I think that Basica and 
GWBasic did, but I'm
not altogether certain about them.

David

Post a reply to this message

Bill Pragnell wrote:
> "clipka" <nomail@nomail> wrote:
>> "David H. Burns" <dhb### [at] cherokeetelnet> wrote:
>>> A convenient excuse anyway. "Everybody needs someone to look down on. If you
>>> ain't got nobody else, well help yo'self to me!" -Kris Kristofferson
>>> (quoted from
>>> memory) :)
>> "Jesus was a capricorn"
> 
> "Capricorn, eh? What are they like?"
> "He is the son of God, our Messiah! King of the Jews!"
> "And that's capricorn, is it?"
> 
> 
Well, I agree with the middle quote of the three. Of course whether He is a
Capricorn in astrological terms depends on the date of His birth, which is
disputed. Of course I doubt if that was what was meant. :)

David

Post a reply to this message

Warp wrote:
> you could do a "GOTO xyz" where xyz was a variable.

What, ON GOTO and ON GOSUB weren't good enough for you? :-)

> which made reading long nested blocks of code a bit difficult.

Nested blocks??  We used to *DREAM* of nested blocks!

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

On 07/28/09 00:58, Chambers wrote:
> Jim Henderson wrote:
>> Oh, there have been much longer threads in here.... :-)
>
> So... is religion good or bad? :)

	Good if it's Emacs.

-- 
ASCII and ye shall receive.

Post a reply to this message

clipka wrote:
> Back then, in order to be able to display multiple overlapping application
> windows at once, the solution was that whenever the position of a window would
> change, all windows previously hidden below it but now visible would have to be
> (partially) re-drawn by their respective applications.

That's one solution, but not really because of the memory. The Amiga had 
only 128K or 256K, and it handled clipping windows and saving the clipped 
parts elsewhere just fine. I suspect it was more a question of (a) amount of 
effort put into the graphics layer and (b) the fact that there was no 
hardware accel for Windows boxes so redrawing from scratch was probably 
close to as fast as blitting the saved window anyway.

> I'm not sure if I get all these details right, but stuff along these lines added
> up to make the Windows graphics interface somewhat complicated to use, 

Note that X Windows has all these same problems, except the user has to deal 
with it all. In typical UNIX fashion, X will tell you what the screen looks 
like and expect you to do all the work of making sure you're passing pixels 
in the right format, rather than taking a device-independent drawing command 
and adjusting it to the proper display.

> Yes, nowadays everyone is using 24-bit RGB graphics, and typically at 1:1 pixel
> aspect ratio, but that's something PC-users could only dream of in the early
> days of Windows.

Or even on sophisticated hardware. 1994 or so I needed to do compression 
testing (i.e., figure out whether JPEG works), so I wound up buying a $3000 
graphics board for the Sun workstation so I could see 24-bit color.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

On 07/27/09 18:56, clipka wrote:
> Warp<war### [at] tagpovrayorg>  wrote:
>>    Immediately when you started having different users with different
>> hardware setups, the whole graphics programming stumbled on a huge problem.
>
> Yup. DOS times were even worse than nowadays, as there was no accepted standard
> interface to graphics cards at all (except for standard CGA/EGA/VGA modes,
> which later graphics cards tried their best to remain hardware compatible
> with); so essentially each program came with its own proprietary set of
> graphics drivers, which fully supported only a selection of SuperVGA graphics
> cards available - and new graphics cards in turn would come with disks
> providing graphics drivers for only the most popular graphics-hungry
> applications.

	Ever used Fractint on DOS? _That_ program probably supported more video 
cards than any other. The amount of collaboration for that piece of 
software was truly impressive.


-- 
ASCII and ye shall receive.

Post a reply to this message

Darren New wrote:

> That's one solution, but not really because of the memory. The Amiga had 
> only 128K or 256K, and it handled clipping windows and saving the 
> clipped parts elsewhere just fine.

Which model? I don't recall seeing one with less than 1MB RAM.

Post a reply to this message