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...

Code snippets on the internet indicate otherwise. Next try... :)

(Hint: It wasn't the Amstrad CPC either; I don't know of any home computer that
had an auto-indent feature.)

Post a reply to this message

Darren New <dne### [at] sanrrcom> 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. 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.

Typically, yes. After all, in those days of Windows 3.1 (and earlier), windows
were just solid-filled rectangles with a border around, and buttons likewise.

Having a dedicated blitter chip made the approach much more worthwile. And I
guess the Amiga only had it because it was designed for GUI operation right
from the start.

Post a reply to this message

Neeum Zawan <m.n### [at] ieeeorg> wrote:
>  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.

Why, yes, of course!

That was a freakin' awesome piece of software in any respect.

Post a reply to this message

Invisible <voi### [at] devnull> 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.

http://en.wikipedia.org/wiki/Amiga_models_and_variants

allegedly 256K on the A1000.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> My rant was more along the lines of higher-level stuff. Take, for example,
> an HTTP client library. You would think it's straightforward, but how do you
> allocate memory such that it's easy to free? (C++ solved this problem,
> obviously, which is one of the big wins for C++ libraries over C libraries.)

Um... what's wrong with malloc() and free()??

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Invisible wrote:
> > Which model? I don't recall seeing one with less than 1MB RAM.
>
> Amiga 1000. From wikipedia
> "Machines began shipping in September with a base configuration of 256 KB of
> RAM at the retail price of 1295 USD."
>
> Which fits my memory. I think the 500 had 128K? It wasn't a whole lot, but
> the Amiga made efficient use of it.

It actually had more than the original A1000 (512K), and was released later; but
by that time, memory prices must have dropped enough that they could offer it
for a significantly lower price - hence the lower type designation as it seems.

Post a reply to this message

clipka wrote:
> Um... what's wrong with malloc() and free()??

It exposes the internals of the memory allocations to the caller. And it's 
difficult to manage if you don't have at least destructors. And it can be 
inefficient if you do it a lot. And sometimes you need certain kinds of 
memory (like DMA-accessible memory) so you wind up with multiple kinds of 
malloc and free.

But mostly because it exposes the internals of the memory allocations to the 
caller, which is usually less of a problem until you combine it with the 
other problems, like threading.

Say you're generating some audio by reading hardware-compressed samples off 
a microphone, then shipping it out over a connection that's packetized and 
interleaved with other data (RTP, for example).  You don't know how big the 
data you're reading is, and you don't know how big the data you're writing 
is. One thread is reading from the microphone and filling buffers. One is 
coordinating. One is writing the buffers to the socket. Who is responsible 
for allocating buffers? Who is responsible for freeing them? Especially 
given that the buffers you're writing might not be the right size for the 
buffers you're reading.

Sure, you can use malloc and free. But I've seen maybe 5% of the programs 
I've worked with *not* layer other memory management stuff on top, and each 
"on top" is incompatible with the other "on top"s. You can't read a buffer 
from John's DVD reader, feed it into a Python data structure, then take that 
and stuff it out to a MPEG decoder hardware interface without copying it 
three times. Heck, Qt is written in C++ and it doesn't make use of any of 
the STL *or* C strings. You know how you print out the URL stored in a 
"QURL" object?  myQurl.toAscii().constData() gives you an actual char* (or 
something like that). Because Qt didn't like STL for some reason.

Everyone builds up big abstractions to help. If you have to do it yourself, 
you're going to build abstractions suited to the program you're writing. If 
you don't have to do it yourself, you have to haul around the whole library 
from someone else and keep up with *their* changes.  I think this is a big 
part of what the .NET stuff is trying to solve with all the "component" part 
of the framework.

-- 
   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 28-7-2009 2:00, clipka 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"
> 
> (Identified from memory... man, it's been ages since I've last heard that song.)

"The earth is a libra"

quoting from memory. No points for identifying the source.

Post a reply to this message

On 28-7-2009 3:51, David H. Burns wrote:
> Jim Henderson wrote:
> 
>>> I ought to apologize for my typos and irregular lines. The keyboard on
>>> this Timex Sinclair
>>> is rather small and my tail keeps getting in the way.
>>
>> Ah, the ZX-81?  Had to use a rubber band to hold the 16 K expansion 
>> pack on mine. ;-)
>>
>> Jim
> 
> You go farther back than me. I wasn't lucky enough to get one of those. 
> The Timex-Sinclair
> is a latter version.

I had (in fact have) a ZX-80, am I now more or less lucky?

Post a reply to this message

Neeum Zawan wrote:

>     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.
> 
> 
Another *really* impressive piece of software. It won't run on an XP 
machine, of course.

David

Post a reply to this message