Newbie developer

[tdp]

Hi all,

 

I'm looking at having a go at coding for the Lynx. I have a couple of general questions (sorry if these questions seem to be weak technically - I'm gathering information):-

 

1) Has any developers used the 480 x 102 resolution that the lynx is capable of?

 

2) It seems like the Lynx' 64K of ram is a disadvantage for creating games. I find this a little confusing considering the ram available to the Neo Geo:-

 

Neo Geo AES

CPU: 16-bit Motorolla 68000 (12MHz) and 8-bit Zilog Z80 (4MHz)

RAM: 64KB (68000) + 2KB (Z80), Video RAM: 68KB

Colours: 64K (4K on screen)

Sprites: 380

Game Media: Cartridge

Resolution: 320x224

Sound: 3 PSG, 4-FM synthesis, 7-digital, 1 noise channel

 

Atari Lynx

CPU: 8-bit MOS 65C02 (3.6MHz)

RAM: 64KB

Colours: 4K (16 on screen)

Sprites: Unlimited

Game Media: Cartridge

Resolution: 240 * 102 and 480 * 102 (apparently)

Sound: 4 8-bit DAC

 

Does the Neo Geo use it cartridges, not just as storage for the game data, but it also becomes additional memory for system? I mean does the NG have some form of dma to data stored on it's cartridges? Is it possible to do something like this for the lynx?

 

If I have made any mistakes, sorry.

 

Cheers - TDP

[tdp]

Hi again,

 

I have managed to get the NG CDZ specs:-

 

Neo Geo CD/Z

CPU: 16-bit Motorolla 68000 (12MHz) and 8-bit Zilog Z80 (4MHz)

RAM: 7MB, Video RAM: 512KB

Colors: 64K (4K on screen)

Sprites: 380

Game Media: CD

Resolution: 320x224

CD Speed: CD 1X, CDZ 2X

Sound: 13 channels, Yamaha 2610

 

Cheers

 

TDP

[Shawn Jefferson]

1) Has any developers used the 480 x 102 resolution that the lynx is capable of?

 

I don't believe the Lynx has a 480x102 mode. The screen is 160x102 IIRC. No other modes are available as far as I know.

 

2) It seems like the Lynx' 64K of ram is a disadvantage for creating games. I find this a little confusing considering the ram available to the Neo Geo:-

 

The issue is that the 6502 only has 16 address lines, so only 64k of memory is addressable without some bank switching. The cartridge access on the Lynx is also a little strange, since you cannot access any byte on the cartridge at any time. There is a small amount of address lines to the cartridge plus a counter that increments at each memory read. So you access the cartridge memory in "blocks".

 

You should read the Lynx development docs on Bastian Schick's webpage:

 

http://www.geocities.com/SiliconValley/Byte/4242/lynx/

[Matthias]

Hello!

 

1) Has any developers used the 480 x 102 resolution that the lynx is capable of?

 

I don't believe the Lynx has a 480x102 mode. The screen is 160x102 IIRC. No other modes are available as far as I know.

 

Each pixel on the Lynxes display consists of 3 physical subpixels, one for red, one for green and one for blue. So you could speak of a horizontal resolution of 160*3 = 480 pixels.

I think the below mentioned Epyx-docu states somewhere that it was at one time considered to release a monochrome-display version of the Lynx using that "higher" 480*102 screen-resolution.

 

I think Bastian Schick had released a text-printing demo which uses a "monochrome" font, that's the only program i know of which utilizes the "480*102" resolution. Of course the letters look quite funky on the colour-display

 

2) It seems like the Lynx' 64K of ram is a disadvantage for creating games. I find this a little confusing considering the ram available to the Neo Geo:-

 

The issue is that the 6502 only has 16 address lines, so only 64k of memory is addressable without some bank switching. The cartridge access on the Lynx is also a little strange, since you cannot access any byte on the cartridge at any time. There is a small amount of address lines to the cartridge plus a counter that increments at each memory read. So you access the cartridge memory in "blocks".

 

You should read the Lynx development docs on Bastian Schick's webpage:

http://www.geocities.com/SiliconValley/Byte/4242/lynx/

 

The main problem is, that the screen doesn't have it's own memory, so with double-buffering you have only 64KB - 2* 8KB = 48 KB for the program itself.

 

Regards

Matthias

[Shawn Jefferson]

The main problem is, that the screen doesn't have it's own memory, so with double-buffering you have only 64KB - 2* 8KB = 48 KB for the program itself.

 

You would still be left with the problem of writing to this memory via CPU, which would involve bank switching somehow, since the CPU can only access 64k. I guess you could only use Suzy to write to screen ram, but that would be more restrictive than the system the lynx uses.

[eric_ruck]

Yeah, the Neo Geo has a 68K with a 32 bit address line...you do have the cartridge space to use in the Lynx, which amount to megabytes, but the only thing you can do with it is move the data to RAM, where it can actually be used.

 

Eric

[tdp]

- HELP!!!!

 

Hello all,

 

Thanx for the replies. Still a little confused.

 

I have been doing some reading on this (again apologises if I make any mistakes). The Apple IIc Plus runs a 4Mhz 65c02 and has 128 Kb. As Shawn rightly states, the 65c02 is only capable of handling a maximum of 64kb. However, the Apple is able to access the "high" 64kb by memory paging.

 

Also, the NES (running a 6502) was able to access more data due to using memory mappers.

 

Is it possible to implement a memory mapper onto a lynx cartridge (forget about cost for the time being)? Could this be a way forward? Also from what I understand the Audio_in line is used for read/write operations to the EEPROM. Is possible to use the Audio_in to control a memory mapper? I figure it should be possible to use the Audio_in line for any purpose. I suspect this would require a custom cart.

 

What do you think? Again I apologise if this seems to be the rantings of a mad man!!

 

 

Cheers - TDP.

[Shawn Jefferson]

Is it possible to implement a memory mapper onto a lynx cartridge (forget about cost for the time being)? Could this be a way forward? Also from what I understand the Audio_in line is used for read/write operations to the EEPROM. Is possible to use the Audio_in to control a memory mapper? I figure it should be possible to use the Audio_in line for any purpose. I suspect this would require a custom cart.

 

Yes, that is what is essentially done to get bigger cartridge sizes. I think (???) there is also a way to trade off a larger block size (512, 1024, 2048 bytes) to get a larger cartridge. I believe the Alpine Games cartridge uses a large block size plus another line (maybe Audio_in?) to do bank switching to access an even larger cartridge. IIRC, the Alpine Games cartridge is 4Mbit (512KB).

 

I'm sure others will have more details about which pins, etc..

 

This is from the Atari Lynx FAQ:

 

The Lynx contains 64K (half a megabit) of 120ns DRAM.  Game cards

  currently hold 128K (1 megabit) or 256K (2 megabits) of ROM, but there

  is a maximum capacity of up to 2 megabytes (16 megabits) on one game card.

  In theory, this limit can be exceeded, either with bank-switching

  hardware in the card, or by using a ROM power on/off line as an extra

  address line (up to 4 megabytes).  Most Lynx game cards are 256K ROMs.

  Three games are on 512K ROMs: NINJA GAIDEN 3, PIT FIGHTER, and JIMMY

  CONNORS TENNIS, along with the never-released EYE OF THE BEHOLDER.

[+karri]

The largest block size is 2048 bytes and Lynx has 8 block select pins.

That makes the largest cart 512k.

 

There is also Audio I/O pin that 42Bastian used to extend the address range in his early driving school program. You don't need to add any chips to use the Audio I/O pin. Just make a wire directly to an address line. Then you need to set it to 1 or 0 before you do the block read. So now we are up to a 1M cart.

 

Then Harry told me that the Vcc pin can also be used for selecting which chip to access. I am not aware of anyone who has experimented on this but I am sure that Harry has some idea of how this could be done. This extends the maximum cart size to 2M bytes with no extra hardware.

 

But there is actually 2 cart ports. The cart0 port is used for reading data from the cart while cart1 is used for write access to developer carts. Both ports can be read or written to. So you could use cart1 for a second read strobe givin you an extra pin and a 4M cart. But then you lose the ability to write anything to the cart so it has not been done.

 

I was seriously planning to do a 16M cart with a microcontroller controlling the extra address lines. But then I got lazy and fell for DIP-switches instead. So I could write a 16M bytes game that instructs the user. "Please set the dip switch to 11100110 and press A to continue"

 

But there is also new compiler at www.cc65.org that lets your program use any bytes on the cart almost as if it were in RAM all the time. This means that you can easily write code where you keep only those routines in memory that you need just now. Once you have used them you can throw away the data and load some other routine on top of it in the same memory space. This makes loading very fast - you only load those bits you really need when you need them.

 

Of course you cannot code like people do for Windows (I need some buffer space, lets allocate a few megabytes just for fun in case we need it. And link it with all libraries we can find).

 

I tried to fill up a cart by linking in every piece of code I have ever written for the Lynx. But I am still only up to 128k. The beautiful graphics in Alpine Games is probably the only reason why Duranik wanted to go up to 512k.

 

--

Regards,

 

Karri

[sage]

But there is actually 2 cart ports. The cart0 port is used for reading data from the cart while cart1 is used for write access to developer carts. Both ports can be read or written to. So you could use cart1 for a second read strobe givin you an extra pin and a 4M cart. But then you lose the ability to write anything to the cart so it has not been done.

 

hmmm... if I remeber correctly, i was told that reading on the write port/writing on the read port gives "strange" results...

But I never checked that myself.

 

I tried to fill up a cart by linking in every piece of code I have ever written for the Lynx. But I am still only up to 128k. The beautiful graphics in Alpine Games is probably the only reason why Duranik wanted to go up to 512k.

 

Plus the music. The MOD files are eating a lot of space. From my experience: One MODfile is eating up around 10-20k ROM (already packed). The game consists several MODs.

[Nubian]

Hey All,

You technical wizards amaze me sometimes. All that know-how! It must take alot to make a game. I don't have the slightest idea about any of this stuff but it's still interesting to see guys making games for the good old Lynx. I am one Lynxer who really appreciates the work some people do to get a game up and going.

 

Nubian.

[tdp]

Hello all,

 

Karri has hit the nail on the head!!! This is what I was asking about.

 

But there is also new compiler at www.cc65.org that lets your program use any bytes on the cart almost as if it were in RAM all the time. This means that you can easily write code where you keep only those routines in memory that you need just now. Once you have used them you can throw away the data and load some other routine on top of it in the same memory space. This makes loading very fast - you only load those bits you really need when you need them.

 

Thanx. I had a look at that site. Based on my currently limited knowledge, what you have described above is possible with pointers (or to a lesser degree Peek and Poke). Is that right? So I could use a pointer to point to the location on ROM to pull the code/data needed. Is this right?

 

How would you keep the code/data where you want it in RAM? Linkers produce relocatable code. Is this when you need the assembler directive .org? I'm not up on assembler - studied x86 assembler years ago - and that was to control bead counters - WOW!!!

 

Again, humble apologises for my (dodgey) questions.

 

Cheers - TDP

[Shawn Jefferson]

Thanx. I had a look at that site. Based on my currently limited knowledge, what you have described above is possible with pointers (or to a lesser degree Peek and Poke). Is that right? So I could use a pointer to point to the location on ROM to pull the code/data needed. Is this right?

 

I'd be suprised if that were the case. The lynx cartridge is usually organized as a "file system" complete with a directory which makes it easier to find the information you want off the cartridge. I suppose you could forgo the file system setup and just load data from the cartridge at a specific block + offset.

 

Anyway, I don't think there is any provision to create a pointer into the cartridge space. You probably have to use the cartridge reading functions?

 

Karri, I just took a quick look at the latest snapshot of cc65 that I downloaded from cc65.org. The lynx.h file sure was shortened! How do you access the cartridge now? I didn't even see any of the cartridge functions there...

 

What about graphics, do you have to use the TGI driver? Didn't the _suzy.h and _mikey.h make it past Ullrich? I didn't see them.

 

How would you keep the code/data where you want it in RAM? Linkers produce relocatable code. Is this when you need the assembler directive .org? I'm not up on assembler - studied x86 assembler years ago - and that was to control bead counters - WOW!!!

 

The cc65 linker doesn't create relocatable code (the assembler/compile does though), it (the linker) then uses a linker configuration file to decide where to put the code (much like the .org directive you reference.)

[+karri]

Thanx. I had a look at that site. Based on my currently limited knowledge, what you have described above is possible with pointers (or to a lesser degree Peek and Poke). Is that right? So I could use a pointer to point to the location on ROM to pull the code/data needed. Is this right?

 

I'd be suprised if that were the case. The lynx cartridge is usually organized as a "file system"...

 

True. But the interesting thing is that the Linker can link the code and data for a whole application so that the code can be overloaded in a clever way.

 

Example of old way to do things:

0400: startup code

0500: initialize hardware

0600: intro



Level 1



0400: startup

0500: level 1 code

etc...

 

New way:

0400: loader that loads the startup code somewhere

1000: initialize hardware

1000: intro

1000: resident portion of game

1200: level routines for level1

1200: level routines for level2

 

So the same addresses get reused all the time. The "files" on the cart are now extremely small containing only the portion of the code you really need. And the linker calculates the addresses on the cart and in the memory. So I link the entire cart in one go instead of trying to link separate programs and put them on a cart.

 

In the loader part I have to keep track of which parts are needed in RAM. So I have code like:

switch (next_module) {

case FLYING_IN_SPACE:

 if (!Stardreamer_core_loaded)

   load(Startdreamer_core);

 if (!Stardreamer_3D_space_loaded)

   load(Stardreamer_3D_space);

 load(Stardreamer_flying); // This loads fly() from the cart

 next_module = fly();

 break;

case DOCKED:

 if (!Stardreamer_core_loaded)

   load(Startdreamer_core);

 Stardreamer_3D_space_loaded = false;

 load(Stardreamer_docked);

 next_module = docked(); // This loads docked() from the cart

 break;

...

 

But the interesting thing is that I can call any routine anywhere on the cart just like it was in RAM. It is my responsibility to actually load the code to RAM before I do the call.

 

Karri, I just took a quick look at the latest snapshot of cc65 that I downloaded from cc65.org.  The lynx.h file sure was shortened!  How do you access the cartridge now?  I didn't even see any of the cartridge functions there...  

 

What about graphics, do you have to use the TGI driver?  Didn't the _suzy.h and _mikey.h make it past Ullrich? I didn't see them.

 

I am using several routines "outside" the official distribution. They did not make it past Ullrich

 

But I could actually make a cart-building template with some simple code to let other people use this wonderful linker for putting the cart together.

 

All code is always linked at absolute addresses. And you can easily work in assembler or C or both. But the C produces much better code than any assembler I could produce. Ullrich is an amazing coder.

 

--

Regards,

 

Karri[/code]

[Shawn Jefferson]

But the interesting thing is that I can call any routine anywhere on the cart just like it was in RAM. It is my responsibility to actually load the code to RAM before I do the call.

 

Ahh, so you are using the loadable modules capability of cc65 then? Or some routines that you created yourself?

 

I am using several routines "outside" the official distribution. They did not make it past Ullrich

 

Not a big deal really.. just another library I guess. Do you have your own version of the linker too? (Sorry if you told us about this already... can't remember.)

 

But I could actually make a cart-building template with some simple code to let other people use this wonderful linker for putting the cart together.

 

I'd be interested in that. I'd like to eventually write something substantial for the lynx, but I have this 8-bit project in mind next...

 

All code is always linked at absolute addresses. And you can easily work in assembler or C or both. But the C produces much better code than any assembler I could produce. Ullrich is an amazing coder.

 

He certainly knows what he is doing, but I think there will still be room for improvement, either size or speed, when you get into hand-tuning the code. Like you say though, if it's good as it is, why bother? Concentrate on those parts of your code that really need optimization.