From: BLuRry on 24 May 2006 10:24
> It depends on what you do. If you do lot's of graphics and sound stuff,
> Java is definitely a bad choice.
Are we talking about Java 1.2 or are we talking about the modern
1.4/1.5 java runtimes with JIT compiler support. Surely you must have
looked at the advances in java technology before making such a blanket
And as for pushing heavy graphics and sound through an apple computer,
the apple game server works very well in java, thank you very much! :-P
From: Michael J. Mahon on 24 May 2006 11:09
Cameron Kaiser wrote:
> "Michael J. Mahon" <mjmahon(a)aol.com> writes:
>>>The C64 mainly needed it for its text mode. Unlike the Apple, the
>>>character shapes reside within the Video chip's AND the CPUs normal
>>>memory map, are read over the normal address bus, and can be redefined
>>>by pointing a register to RAM instead of ROM.
>>It was a conscious choice to make the Apple character set fixed.
>>(And it's nice to have a character set fully defined at power-up.)
> This is a marginal diversion, but I'm not sure what you mean by "fully
> defined" since the C64's is, of course, also fully defined in the sense
> that it's there. :)
I meant that there was no SRAM to initialize to provide a character
set--but perhaps I misunderstood the explanation of character generation
in the C=64.
Parallel computing for 8-bit Apple II's!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it is seriously underused."
From: John Selck on 24 May 2006 12:17
>> It depends on what you do. If you do lot's of graphics and sound stuff,
>> Java is definitely a bad choice.
> Ha. You think so? I have friends in the mobile handset game market that
> would disagree with you. In fact even on the PC it's not "definitely a
> bad choice". Have you had a look at Java Quake?
Lol, yeah Java on mobile is an especially cool example of "Java power"
where Giana Sisters runs jerky as hell on a ~300 MHz CPU, while a lame
old 1 MHz 8 bit computer could do it smooth in 50 fps.
> JIT compiles at runtime for YOUR processor. Not the lowest common
I have yet to see an example of pure rendering where a JIT comes even
close to lame C++ programming.
From: John Selck on 24 May 2006 12:47
Michael J. Mahon wrote:
> This works only when the behavior of all versions are known, and they
> can be differentiated by software tests.
> Since it is difficult to predict which undocumented behavior(s) would
> be present in a future chip, it cannot, in general, allow for future
> chips, except in the special case where the "test" encompasses *exactly*
> the behavior that the exploiting code uses (no more, no less).
SHX/SHY have been replaced with STZ on later CPUs, so there is no
problem with future chips since either these chip's expand the old
instruction set which has STZ already, or it is incompatible anyway
since it does not implement all the former legal opcodes.
> Modern programming practice does allow for code (and even algorithms)
> tailored to specific processor levels, but only when there is a method
> for differentiating implementations that is architectural, and therefore
> sanctioned by the manufacturer(s). Of course, most compilers don't
> offer support for this, except in some embedded environments.
Ok, next time I will ask MOS if the use of illegal opcodes is sanctioned
by them... Oh wait, MOS doesn't exist anymore for almost 20 years now :D
From: Paul Schlyter on 24 May 2006 15:13
In article <1148480676.109301.184350(a)y43g2000cwc.googlegroups.com>,
BLuRry <brendan.robert(a)gmail.com> wrote:
> > It depends on what you do. If you do lot's of graphics and sound stuff,
> > Java is definitely a bad choice.
> Are we talking about Java 1.2 or are we talking about the modern
> 1.4/1.5 java runtimes with JIT compiler support.
Let's talk about Java 2 !!! :-)
> Surely you must have looked at the advances in java technology before
> making such a blanket statement!
> And as for pushing heavy graphics and sound through an apple computer,
> the apple game server works very well in java, thank you very much! :-P
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stockholm dot bostream dot se