If you play it in Handy, you'll notice lots of flicker and the lines doing
odd things at certain angles.
I am wondering - is that line oddity all Handy's doings (I've seen it trying
to run Steel Talons - I know it has some maths problems somewhere), or is it a
bug in the C libraries?
If it is a bug in the C libraries, does the C line routine use the hardware
beyond the CPU? I ask because otherwise I can throw in a quick Brenesham
routine to replace the supplied draw line.
I don't know if .com files can be directly downloaded onto Lynx's without me
having to do anything else, but if they can and anyone here has the
facilities, any chance of trying it on a real Lynx and telling me if the
problems persist? Thanks in advance!
Thomas Harte <T.H...@btinternet.com> wrote in message
> > http://www.btinternet.com/~t.harte/EliteLynx.zip (case sensitive).
> Haha! I've already created a new version by adding reverse face removal.
> that it is being drawn with polygons, but it is being considered with the
> of polygons. However, just to underline the point - each line is drawn
> and once only, from a line table.
> Anyway, I'll stop posting here for a bit now, I'm just quite proud of my
> achievements. So, why not try the truly-Elite style
> http://www.btinternet.com/~t.harte/EliteLynx2.zip instead of the above,
> remember - the lines are drawn by the C libraries, not by me, and may well
> work correctly on a real Lynx for all I know.
> Sorry to continually bother.
I agree that the vectors look much nicer than the bitmaps.
Especially for a classic like Elite.
Would a mixture of bitmaps and polygons be a bad idea?
I'm not persuaded that polygon games on the Lynx were ever a good idea, but I
reckon bitmaps and vectors might work well. Something like vectors for all
important objects, and some sprite effects such as little explosions, possibly
the space dust / stars that shoot by (I'm not sure about speed concerns with
that one though) and so on.
What doesn't seem to work as well is the C compiler. Nor the Handy emulator.
For example, the C compiler seems to have difficulties when you try to give
two, entirely seperate variables the same name. E.g. local variables in
different sections of code, or struct members and regular variables. And the
emulator was never going to be very good for a system as complex as the Lynx.
So maybe I won't be able to get any great amount further without dipping into
some (yuck) 6502 assembly.
Anyone got a good information source for programming the Lynx? It seems to me
that there is very little available information about what is possible and
what is not, and how I'm meant to achieve this and that.
: I'm not persuaded that polygon games on the Lynx were ever a good idea, but I
: reckon bitmaps and vectors might work well. Something like vectors for all
: important objects, and some sprite effects such as little explosions, possibly
: the space dust / stars that shoot by (I'm not sure about speed concerns with
: that one though) and so on.
See Battlezone 200 for both a good vector game and a good polygon game
(the hidden game). Both also use sprites, too.
: What doesn't seem to work as well is the C compiler. Nor the Handy emulator.
: For example, the C compiler seems to have difficulties when you try to give
: two, entirely seperate variables the same name. E.g. local variables in
: different sections of code, or struct members and regular variables. And the
I believe Bastian fixed this in a later version of the C compiler.
: Anyone got a good information source for programming the Lynx? It seems to me
: that there is very little available information about what is possible and
: what is not, and how I'm meant to achieve this and that.
Bastian's web pages have all the Atari Lynx documentation online.
I can't actually see that - apart from me being not willing to download it (I
don't own it), apparently it doesn't work correctly in Handy anyway. Also, it
is quite expensive (£25 at Telegames UK - games start at £10)
> I believe Bastian fixed this in a later version of the C compiler.
Then he has messed up source distribution somewhere, I compiled the latest
thing I could download only a couple of days ago (newcc65src.zip on the
geocities page) and the bug remains. I know of a few other things that appear
to be bugs, but may just be related to that one.
> Bastian's web pages have all the Atari Lynx documentation online.
Oops! Sorry! I must be some sort of idiot.
Incidentally, is there anyway to make the C compiler divide a signed number
by an unsigned one? It would be nice to be able to double my z range, but
whatever combinations I try, I can't seem to make this work. Although it may
not be possible - the documentation isn't really very clear on that matter.
Is there a Lynx development mailing list or anything? I know it would be
quite under-subscribed, but it would mean people like me could get the
questions to the right people at least.
I got the serial cable today from Carl and downloaded your vector demo
to the real Lynx. There were no artifacts - except one.
When the craft is horizontal then it looks as the whole craft would
not fit on screen and there is one frame with a flattened craft.
The text has small flickering visible but the white craft has no flicker
On Tue, 5 Oct 1999, Thomas Harte wrote:
> remember - the lines are drawn by the C libraries, not by me, and may well
> work correctly on a real Lynx for all I know.
> Is there a Lynx development mailing list or anything? I know it would be
> quite under-subscribed, but it would mean people like me could get the
> questions to the right people at least.
In my opinion there should be such a mailing list, despite the projected
size. There is an Intellivision programming mailing list to which I am
subscribed, and it seems to be a valuable resource. Currently Intellivision
home development is at a relatively young stage; the only development tools are
a handful of 1600 assemblers and disassemblers. That will inevitably change
over time, and it appears that the set of existing Lynx development tools is a
bit larger. Such a mailing list would be perfect for source code discussions
such as this.
I have a question. Why is it that Lynx programmers are predominantly
working in C instead of 6502 assembly? Is the Lynx a complicated system or is
the 6502 just a pain to work with? Does the Lynx not suffer a great deal in
speed when working in C as opposed to plain assembly?
When using the serial cable is the program/game dumped into the Lynx running or
is it saved to a cart then run?
Rick "My Lynx II is no more, see my web page for details" LaFleur
Rick LaFleur's Page
2600/7800 -- Lynx -- Reboot -- PSX -- 3D Artist -- Colecovision
Because Teddy, the programmer I work with, just turned 11 last week.
I don't intend to start teaching programming in assembler as a first
Besides I haven't even botherd to learn the register structure of a 6502
yet. When the time comes for squeezing the code to smaller space or
writing some time-critical stuff then I can easily rewrite everything.
For the present demos C is good enough.
-- Been there, done that, got the T-shirt, lost the hat.
The S.I.M.I.S. cart has a download program on the main screen.
When I connect the cable to a serial port on my PC then the S.I.M.I.S.
background starts blinking while the code downloads into the Lynx ram.
After the download is complete it will automagically start executing
the vector demo. You can then also disconnect the cable. The game
stays in the Lynx as long as the power is on.
There is no access to the cart available. So this is good for testing
games that completely fit into the Lynx ram.
Personally I feel that S.I.M.I.S. and a cable is a very good
investment. It feels good to run something _you_ have created in
your Lynx. Much more fun than just playing pre-made games.
Ponx was coded almost entirely in C. There is certainly some overhead to C
code, but considering I write C/C++ code for a living, I pushed very
strongly a few years ago to get a decent C compiler on the Lynx. I can
write assembly if needed, of course.
It's just a much quicker development cycle to write a game in C instead of
cranking out 2-4X more assembly lines of code.
A combination of all those factors. Firstly, 6502 assembly language is
horrible. The 6502 works entirely upon only four workable registers - a byte
stack pointer, two memory index registers and an accumulator. Because, unlike
nice processors, this gives you only one useful register when actually trying
to calculate something. As you tend to try to do with microprocessors. So, to
make things a little easier, the designers added a multitude of interesting
and strange ways to access the memory pointed two by the pair of index
registers. And then, just to make programmers even happier, they made sure
that the memory addressing methods are different for each index register!
Of course the 6502 also contains a program counter and flags register, but
I'll take it you assumed that.
Now, in the Lynx we have a 16Mhz bus and two main chips (Mikey and Suzy), one
of which contains the 6502 on-board (the 6502 was made by a variety of
manufacturers, so Atari using the design within their own silicon is no
surprise) running at roughly 4Mhz. This isn't the easiest system in the world,
but neither is it the most complex. The Sega Saturn, for example, has 2 CPUs
and 5 other custom chips, which don't even run in sync. That really is
Unlike 6502 assembly, C development hides the hardware from you and allows
you to think far more sensibly in terms of having easy access to more than one
variable at once.
Actually, while I'm here, the 6502 wasn't even considered a good design 'in
its day' - its main competitor of the home computer period, the z80 (which is
a very nice chip!) also contains two memory index pointers and an accumulator,
but its stack pointer is a proper 16bits (quite useful when your memory
address range is 16bits), and it has another 6 8bit registers always
available, pairable to create 3 16bit registers (16bit arithmetic simply isn't
possible on the 6502, but Atari added some silicon for that use into the
Lynx), and has two sets of all its important registers - you can switch
between parts of the sets at will.
Also, that the z80 played host to CP/M, a greatly important operating system
in the early 80's even lead Commodore to add a z80 to the C64 (a 6502 machine)
when it became the C128, and buying a z80 second processor for your BBC Micro
was probably one of the most popular purchases. Even the first assembler for
the Apple 2 (another 6502) required a z80 board add-on to run! Thinking about
it, of the mainstream brands, its only the Atari machines that stuck almost
rigidly to the horrible 6502. I really don't know why, but it looks to me as
though 6502's were manufacturable freely, giving them a cost advantage - which
would explain what Atari were thinking anyway!
The normal 6502 doesn't even have any port access for external hardware . . .
To sum up : I, and everyone with sense, hates the 6502! Although its worth
noting that the z80 was designed to be a backwardly compatible upgrade of the
intel 8080, to which the 80x86 owes a lot of its base functionality, so
perhaps my opinions are tainted by what sort of thing I'm already comfortable
with. Looking at it another way though, no 6502 machine seems to have survived
any amount of time without some decent backup chips and logic. Whereas, here
in England, the ZX Spectrum lived around 11 years with more or less just a z80
and an area of memory mapped onto the screen!
Even of the 8bit handheld consoles, both the Gameboy and Game Gear are z80
based, so it is a shame that the Atari is stuck with what is, in my opinion, a
greatly inferior CPU.
But I'd better stop writing now, before I get carried away!
Especially when those pre-made games are Batman Returns or Super Squeek! How
much would one of these cables cost?
The cables cost $29.95 plus shipping at the Songbird web site.
So I have to order from America? Unfortunately my general paranoia prevents
that! I'd be fine getting SIMIS from Telegames UK, is there a schematic for
the lead available?
There is a GIF in Bastian's BLL-archive
Atari Lynx page:
Atari Jaguar page:
That's the point: You can reach your goal faster using C!
My MarbleMadnes clone was written entirely in C, but this year (i had a
of about two years) i was in need for some RAM-space and ported about 90
inline-assembly-code. Result i've got my free space, and the framerate
rose up from 15 fps
to 30 fps!
> I have a question. Why is it that Lynx programmers are
> working in C instead of 6502 assembly? Is the Lynx a complicated
system or is
> the 6502 just a pain to work with? Does the Lynx not suffer a great
> speed when working in C as opposed to plain assembly?
It suffers ! A skilled programer can do a project on the lynx in
assembler as quick as in C. Only the program runs twice as fast and eats
half of the memory.
The 65C02 is a simple processor and 60 opcodes are'nt too much.
The Lynx itself is also easy to program.
This note from the guy who helped to bring you the C-compiler :-)
PS:Wonder why 99% of the Lynx-games are 100% assembly ? :-)))
Sent via Deja.com http://www.deja.com/
Before you buy.
I assume you mean unfilled-polygones when talking of vectors.Then one
note: Using the library to draw lines uses a sprite (you will notice
that some lines at certain angles have gaps). Thus for a triangle you
have to setup the sprite-engine three times. For small triangles,
drawing a filled one is faster. Also, there are no gaps.
If the runtime.run does not help you with your division, try to write
your own routine or better, try to get rid of the division by using
tables or using a multiplication.
> What doesn't seem to work as well is the C compiler. Nor the
> For example, the C compiler seems to have difficulties when you try to
> two, entirely seperate variables the same name. E.g. local variables
> different sections of code, or struct members and regular variables.
Thought I fixed it. Could you prepare an example and post it ?
> emulator was never going to be very good for a system as complex as
Esp. because the sprite-engine is still buggy.
> So maybe I won't be able to get any great amount further without
> some (yuck) 6502 assembly.
Always the best solution !
> Anyone got a good information source for programming the Lynx?
It seems to me
> that there is very little available information about what is possible
> what is not, and how I'm meant to achieve this and that.
As Carl pointed out: My homepage (now) at
PS: Readly would like to play Elite on the Lynx !
> Even of the 8bit handheld consoles, both the Gameboy and Game
Gear are z80
> based, so it is a shame that the Atari is stuck with what is, in my
> greatly inferior CPU.
I earn my living writing programs (RTOS') in assembler, all I can say
(knowing at least 10 different) is that: No CPU is perfect, some have a
lack in registers (too few (6502) too much (ARM/850/PPC) ) some have
stupid mnemonics (mov postman,letter :-).
But anyway, 10mil (or more ??) C64 users/programmer prove (in my eyes)
the 6502 (or 6510) isn't such a bad machine.
Please note: _A_skilled_programmer_. An average programmer will spend
a lot of time fixing his own bugs because he did not have enough
experience in the peculiarities of the 6502 CPU.
It is the same thing as eating out in a Chinese restaurant. It is just
as fast to eat with sticks - if you are Chinese. For me I just spend
an extra 30 minutes trying to get the food into my mouth and end up
with half of my meal on my shirt and trousers.
It would take me months to end up with the same code quality and
speed that is found in the Lynx libraries. I really appreciate
that Bastian has made these libraries available. In this way most
of the code runs fast and using C slows things down only by a
factor 2 instead of a factor 20 as it used to be in the early
hehe, good analogy. I think I'll hold off on Lynx programming until there is a
6502 compiler for Fortran.
aka. dj E on FM 97.9 the Wire