|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> On Mon, 27 Jul 2009 17:56:03 -0500, David H. Burns wrote:
>
>> The Commodore PET was one of those desk tops with a built in monitor. It
>> had, I guess, a 16K ROM and 16K of RAM. (That's K) and
>> programs we stored on a cassette tape.
>
> The earliest PET computers had 2K of RAM in them, not sure what the ROM
> size was, but it wasn't big.
Wow! I actually took those numbers from my TRS 80 Model III. They did a
lot with a little
memory in those days. The PET I had had a full-sized normal keyboard,
IIRC (If I
remember correctly).
>
> Those older models also had the "chicklet" keyboard - good for elementary
> students (which I was at the time), not so good for people with "grown
> up" hands.
>
> Jim
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> > I wouldn't be too surprised if people found a way to provide a BGI driver that
> > could open a window of a particular size and use it as a canvas. Heck, I even
> > personally wrote a driver for the SuperVGA modes of my own Trident TVGA 8900
> > card (except for the blitting operations which I found I didn't need) =B)
>
> I have several graphics "packages" which use the "Mode 13h" but programs
> compiled
> with them, even pre-compiled examples don't work with XP (and I suspect
> the graphics
> card I have is also incompatible).
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.
XP (for good reason) doesn't allow you to access the graphics card directly
(just guess what happened if every application you have running on your
computer - say, browser, calculator, Windows Explorer and your own home-brewn
program - would try to poke around at the graphics hardware, maybe even trying
to run in different modes... perfect chaos.
But a suitable driver might provide a frame buffer of, say, 640x480 pixels for
you to use freely, and do the interfacing to Windows (including event handling)
for you, instead of directly accessing real hardware.
> The graphics routines in John Beales wonderful
> heightfield programs don't work, though the rest of the program does.
The name doesn't ring a bell.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> (just guess what happened if every application you have running on your
> computer - say, browser, calculator, Windows Explorer and your own home-brewn
> program - would try to poke around at the graphics hardware, maybe even trying
> to run in different modes...
They call that SunView / OpenWindows. That's what SunOS used before X was
around. Linux still allows this stuff, too, as in the Linux FrameBuffer.
--
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 Mon, 27 Jul 2009 19:54:32 -0500, David H. Burns wrote:
> Wow! I actually took those numbers from my TRS 80 Model III. They did a
> lot with a little
> memory in those days. The PET I had had a full-sized normal keyboard,
> IIRC
Yeah, the later models of PET used a full-sized keyboard - the 8K model I
remember certainly did, as did some variants of the 4K model IIRC.
That really takes me back, though....
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 27 Jul 2009 20:00:10 -0400, clipka wrote:
> "Jesus was a capricorn"
Jesus was Jewish! -- Avenue Q Soundtrack
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 27 Jul 2009 19:47:14 -0500, David H. Burns wrote:
> Jim Henderson wrote:
>> On Mon, 27 Jul 2009 18:27:19 -0400, Warp wrote:
>>
>>> That kind of mocking attitude isn't really helpful.
>>
>> Nor is it particularly helpful to mock the abilities of someone you've
>> only just met.
>>
>> This thread needs a whole lot of "lighten up, folks!". Seriously.
>>
>> Jim
> I *thought* my monkey comment was light. Maybe we have just harped on
> this same,
> rather tangled, thread to long. :)
Oh, there have been much longer threads in here.... :-)
> 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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> XP (for good reason) doesn't allow you to access the graphics card directly
> (just guess what happened if every application you have running on your
> computer - say, browser, calculator, Windows Explorer and your own home-brewn
> program - would try to poke around at the graphics hardware, maybe even trying
> to run in different modes... perfect chaos.
>
> But a suitable driver might provide a frame buffer of, say, 640x480 pixels for
> you to use freely, and do the interfacing to Windows (including event handling)
> for you, instead of directly accessing real hardware.
>
I can appreciate that it might be wise to restrict access to the video
card. But it is possible to
display images somehow. Pov-Ray does it and in a whole host of
resolutions. Maybe displaying
graphics is very hard but it can't be impossible!!
> The graphics routines in John Beales wonderful
>> heightfield programs don't work, though the rest of the program does.
>
> The name doesn't ring a bell.
>
You took me aback! I had to call up Pov-Ray links to make sure had had
the name right.
Have you every played with heightfields? I can't imagine anyone who has
not being familiar
with John Beale's "Gforge".
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Immediately when you started having different users with different
> hardware setups, the whole graphics programming stumbled on a huge problem.
I don't think it's really even just graphics, altho graphics are the main
source of problems.
I think having libraries (or, more particularly, "components") is a
difficult thing to do efficiently. I've been looking at bunches of code for
high-efficiency programming lately, and I've started remembering what I hate
about C and C++ and the ilk.
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.
With C it isn't too bad, but C doesn't support things at a high-enough level
that I can take (say) an MPEG decoder library or a media streaming library
and just use it. Most of the time the author either invents a whole bunch of
routines to handle logging, strings, async I/O, header parsing, etc. Nobody
really writes a sophisticated library relying on a minimum of outside
non-standard libraries any more. *Most* systems have their own names for
integers, strings, whole complex hierarchies of header files, etc. There's
nothing even coming close to UNIX pipes or something where you plug things
together without having to fix a bunch of stuff inside. For example,
everyone has different logging libraries, instead of just writing to stderr
like the libraries were originally designed to handle. If you want to use an
XML parser, an HTTP client, a multimedia stream receiver, and a graphics
framebuffer library, you're going to wind up with four different logging
mechanisms probably more than one resource manager.
C++ is a lot better, in that at least people seem to avoid rewriting
malloc() and such, and Boost (if you use it) has a bunch of handy libraries
handling stuff everyone needs but everyone reinvents. Which is great if all
the projects use the same version, and all your code is in C++. But just try
to (say) use Qt from a language other than C++, and watch the pain-fest
begin. If you can do everything from scratch in C++, you're in good shape,
but if you're putting together a bunch of third-party stuff, you're pretty
well screwed unless you can cut it into separate processes.
High-level languages designed to solve this problem (like C#, say) have the
problem that they solve it by giving you huge libraries, so if not all your
code is .NET, you're basically screwed again. At least you can go out and
buy the components you want. The problem here seems to be that building such
a framework properly requires a whole bunch of design on a huge library and
runtime system, but people don't want to pay for that. Plus, if it doesn't
come from someone that's essentially already a monopoly, getting everyone to
use it is problematic. It doesn't matter how complete .NET's libraries are
if you can't find the piece of code you're looking for except in some
baroque conglomeration of twisty C++ classes. And it doesn't matter how
complete .NET's libraries are if you can't use them on the machine you
happen to be programming.
Sadly, I don't really see this getting better. Either your language is
sufficiently low-level that it works everywhere you need it, or it is
powerful enough that it has bunches of good code already developed for it
(either as standard libraries or built into the language) that you can just
plug in and use.
I don't think we're quite there yet, but I think the fact that languages
evolve much more slowly than hardware does might make this less of a problem
in the future.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David H. Burns wrote:
> You took me aback! I had to call up Pov-Ray links to make sure had had
> the name right.
> Have you every played with heightfields? I can't imagine anyone who has
> not being familiar
> with John Beale's "Gforge".
(Warning! Thread is becoming dangerously on-topic! :) ).
I'm aware of it, but I never used it. I prefer making my height fields
with POV-Ray instead :)
--
Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|