CBM Projects 2009?
Harry Potter
computers right now. I am creating Temp-C and want to know what I can
do with it to make its cc65 support more useful.
-------------------
Joseph Rose, a.k.a. Harry Potter
Creating magic in the computer community...or at least striving to! :(
xlar54
What is Temp-C?
Dmackey828
I 2nd that, What is it?
DanSolo
> What is Temp-C?
He states quite clearly
> I am creating Temp-C
so it isn't anything yet. I've no idea what's wrong with regular old C
and CC65 though.
commodorejohn
> so it isn't anything yet. I've no idea what's wrong with regular old C
> and CC65 though.
create it. There's a whole other thread* about this that he's been
busily spamming on any site even vaguely related to retrocomputing,
trying to cajole people into using it; he wants to write something
that he'll be lauded for, and never stops to consider whether his
programs are actually all that useful for real programming.
5k3105
> *http://groups.google.com/group/comp.sys.cbm/browse_thread/thread/3ebc...
or, going back ten years and under a different name:
DanSolo
> trying to cajole people into using it; he wants to write something
> that he'll be lauded for, and never stops to consider whether his
> programs are actually all that useful for real programming.
Well in that case I know at least one person who would laud him for
1: Making an FPGA that emulates the 264 series CPU and TED
2: Making a version of Head Over Heels with all new screens
3: Speeding up the line drawing routines on Elite so those Speccites
will shut up about the framerate
4: Fixing the C64 version of Jet Set Willy so it has an ending. Or at
least find me the bloody line of code that detects touching a bloody
conveyor belt and I'll do the rest...
commodorejohn
> 3: Speeding up the line drawing routines on Elite so those Speccites
> will shut up about the framerate
Han Lin's "Extremely Fast Line Algorithm," which is fast and easy to
implement. I haven't done a 6502 implementation, but his fixed-point
version is very suitable for 8-bit CPUs. It's all detailed here:
http://www.edepot.com/algorithm.html
Lars Haugseth
I think that one will have to be modified quite a bit to be really fast
on the C64. For one, it sets individual pixels, which is a big waste of
cycles if there are many pixels to be set within the same screen address.
Dividing the line into smaller segments with a limited range of possible
slope values, with speedcode to draw each possible segment, would be
something to strive for. Provided you have the memory to spare for the
speedcode.
(Speedcode being simple LDA/ORA/STA statements with no calculation or
branching of any kind.)
--
Lars Haugseth
DanSolo
I was under the possibly erroneous impression there was something
about the way the C64 stores bitmap data that makes it difficult (i.e.
slow) to calculate the bit in memory that corresponds with a x,y point.
commodorejohn
> I was under the possibly erroneous impression there was something
> about the way the C64 stores bitmap data that makes it difficult (i.e.
> slow) to calculate the bit in memory that corresponds with a x,y point.
doing; it basically stores the bitmap in 8x8 cells, just like the
character set for a text-mode screen. Lars is right in that the
algorithm would have to be modified in order to be efficient on the
C64, but it's definitely doable; however, without more information on
how Elite does its line drawing, it's difficult to say how much more
efficient this would be. I worked out most of the details for a C64
implementation once; I'll have to see if I can dig up those notes...
5k3105
> line drawing
I thought steve judd did the definitive c64 line-drawing algorithm 15
years ago?
Kelli Halliburton
Nothing really. Creates a bunch of blank editor documents; the names of
those documents to be determined by the type of program you intend to
write. There may also be some generic function prototyping.
For example, you write a word processor, and it creates a series of
documents named main.c, editor.c, file.c, menu.c, and so on. There may
be some stubs in each of those files for common functions found in that
type of program, like blockmove() or findreplace(). You will have to
provide the actual code yourself.
It's supposed to be a programmer's aid. I don't know to what extent it
will actually help anyone do anything.
It's a bit like the various code modules that Visual Whatever generates
for you when you draw a control in the Forms editor and then assign
events to it. You get a function stub that says something like
Button1_Click and then whatever languages block control keywords, and
your cursor is automatically placed inside the function's code block to
start adding your code. Except there's no form and no event model.
5k3105
wrote:
> Except there's no form and no event model.
... and no IDE.
sampsa
> Joseph Rose, a.k.a. Harry Potter
> Creating magic in the computer community...or at least striving to! :(
Failing in an epic way I would say.
Groepaz
> On Jul 8, 4:00 pm, DanSolo <daniel.oto...@ucd.ie> wrote:
>> 3: Speeding up the line drawing routines on Elite so those Speccites
>> will shut up about the framerate
> Any idea what Elite uses for line-drawing? I've messed around with Po-
most of the elite code is a direct translation from z80 to 6502 code, thats
why its terribly inefficient and slow. its not the algorithms it uses :)
> Han Lin's "Extremely Fast Line Algorithm," which is fast and easy to
> implement. I haven't done a 6502 implementation, but his fixed-point
> version is very suitable for 8-bit CPUs. It's all detailed here:
> http://www.edepot.com/algorithm.html
on c64, this one is too complex to be efficient. plain good old bresenenham
(with midpoint mirroring) is pretty much the fastest you can do (if we
exclude those methods that use enormous amount of tables and/or speedcode
and thus are only useful for demos)
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
I love my country... but I fear my government!
commodorejohn
> most of the elite code is a direct translation from z80 to 6502 code, thats
> why its terribly inefficient and slow. its not the algorithms it uses :)
be faster, then, I assume. How simple a task would it be to replace
the line-drawing algorithm?
lyricalnanoha
On Mon, 13 Jul 2009, Groepaz wrote:
> commodorejohn wrote:
>
>> On Jul 8, 4:00 pm, DanSolo <daniel.oto...@ucd.ie> wrote:
>>> 3: Speeding up the line drawing routines on Elite so those Speccites
>>> will shut up about the framerate
>> Any idea what Elite uses for line-drawing? I've messed around with Po-
>
> most of the elite code is a direct translation from z80 to 6502 code, thats
> why its terribly inefficient and slow. its not the algorithms it uses :)
Odd. Wasn't it originally written for the (6502) BBC?
-uso.
Hg
Yes, it was written for the 6502 in the BBC. When the programmers tried to
do a direct port of the 3d code over to the C64 they must have found it
was way too slow, so they had to 'optimize' the 3d routines for the 64 and
even then the screen update still wasn't as fast as the BBC. Years ago while
browsing I found a webpage that had a copy of the optimization algorithm the
programmers came up with. Can't find the webpage now.
Funny thing is one of the main complaints about C64 Elite was the flickery
slow 3D. Imagine how many complaints they would have got if they had used the
BBC code.