Jump to content
IGNORED

Lynx coding contest


Lynxman

Recommended Posts

I'm serious. I don't think you can use a 27C080 chip on these things. Chip form factor has long been an issue for other systems such as the Sega Master System "Sega Cards" and PC Engine. That's why R-Type came on two cards for the PCE.

 

Sure you can. even two of them would fit in the slot. See for example the EOTB module.

For the original module, it is not really a chip what is inside the cartridge.

Aynway, there is no reason to use that big package/formfactor chip beside that it is common for home brew projects.

Link to comment
Share on other sites

I'm serious. I don't think you can use a 27C080 chip on these things. Chip form factor has long been an issue for other systems such as the Sega Master System "Sega Cards" and PC Engine. That's why R-Type came on two cards for the PCE.

Two 27C801s is actually exactly what I use on my test cards for 2MB of space. For actual manufacturing you can just use a 29F016 and a logic gate to combine the strobes and it will be just as flat as the original cards.

 

Sure you can. even two of them would fit in the slot. See for example the EOTB module.

For the original module, it is not really a chip what is inside the cartridge.

Aynway, there is no reason to use that big package/formfactor chip beside that it is common for home brew projects.

Yeah, all original Atari stuff is just epoxy blobs.

Really, modern components are so tiny. Making a new card the size of the Atari originals is only challenging from the standpoint of paying for a plastic mold. But this was already done nearly three years ago with Zaku.

  • Like 1
Link to comment
Share on other sites

Like promised the writing of the sprite tutorials is under way. You can check out the two new parts at http://atarilynxdeveloper.wordpress.com

 

All feedback is welcome. Please point out incorrect information. Let me know if it is helpful. Next two parts will cover flipping, tilting and positioning. Then it is on to collision detection.

 

Encourage me to get more faster. ;)

Link to comment
Share on other sites

With cc65, pre-increment in loops is supposed to create better assembly code. See http://www.cc65.org/doc/coding.html

 

Also, this is a personal thing: I don't like using the POKE macro. That's a BASIC thing, C does it differently.

 

POKE(0xFDA0 + index, palette[index] >> ;

 

should be something like:

 

#define _MIKEY_PAL ((unsigned char *) 0xFDA0)
_MIKEY_PAL[index] = palette[index] >> 8;
_MIKEY_PAL[index+16] = palette[index] & 0xFF;

 

Actually, if you're hitting Mikey and Suzy registers from C code, you probably want something like the Atari 8-bit and C-64 has already in cc65: hardware defines (I was supposed to provide something for Karri, but haven't got around to it yet.)

 

Something along the lines of this:

 

#ifndef __MIKEY_H
#define __MIKEY_H

/* timer structure */
typedef struct _mikey_timer {
unsigned char reload;
unsigned char control;
unsigned char count;
unsigned char control2;
} _mikey_timer;

typedef struct _mikey_all_timers {
struct _mikey_timer timer[8];
} _mikey_all_timers;

/* audio channel structure */
typedef struct _mikey_audio {
unsigned char volume;
unsigned char feedback;
unsigned char dac;
unsigned char shiftlo;
unsigned char reload;
unsigned char control;
unsigned char count;
unsigned char other;
} _mikey_audio;

/* Define a structure with the mikey register offsets */
struct __mikey {
struct _mikey_timer timer0;	 // 0xFD00
struct _mikey_timer timer1;	 // 0xFD04
struct _mikey_timer timer2;	 // 0xFD08
struct _mikey_timer timer3;	 // 0xFD0C
struct _mikey_timer timer4;	 // 0xFD10
struct _mikey_timer timer5;	 // 0xFD14
struct _mikey_timer timer6;	 // 0xFD18
struct _mikey_timer timer7;	 // 0xFD1C
struct _mikey_audio channel_a; // 0xFD20
struct _mikey_audio channel_b; // 0xFD28
struct _mikey_audio channel_c; // 0xFD30
struct _mikey_audio channel_d; // 0xFD38
unsigned char	 attena;		 // 0xFD40 ?? not yet allocated?
unsigned char	 attenb;		 // 0xFD41	 |
unsigned char	 attenc;		 // 0xFD42	 |
unsigned char	 attend;		 // 0xFD43	 |
unsigned char	 panning;	 // 0xFD44	 |
unsigned char	 unused0[11]; // 0xFD45 - 0xFD4F not used
unsigned char	 mstereo;	 // 0xFD50 stereo control bits
unsigned char	 unused1[47]; // 0xFD51 - 0xFD7F not used
unsigned char	 intrst;		 // 0xFD80 interrupt poll 0
unsigned char	 intset;		 // 0xFD81 interrupt poll 1
unsigned char	 unused2[2];	 // 0xFD82 - 0xFD83 not used
unsigned char	 magrdy0;	 // 0xFD84 mag tape channel0 ready bit
unsigned char	 magrdy1;	 // 0xFD85 mag tape channel1 ready bit
unsigned char	 audin;		 // 0xFD86 audio in
unsigned char	 sysctl1;	 // 0xFD87 control bits
unsigned char	 mikeyrev;	 // 0xFD88 mikey hardware rev
unsigned char	 mikeysrev;	 // 0xFD89 mikey software rev
unsigned char	 iodir;		 // 0xFD8A parallel i/o data dir
unsigned char	 iodat;		 // 0xFD8B parallel data
unsigned char	 serctl;		 // 0xFD8C serial control register
unsigned char	 serdat;		 // 0xFD8D serial data
unsigned char	 unused3[2];	 // 0xFD8E - 0xFD8F not used
unsigned char	 sdoneack;	 // 0xFD90 suzy done acknowledge
unsigned char	 cpusleep;	 // 0xFD91 cpu bus request disable
unsigned char	 dispctl;	 // 0xFD92 video bus request enable, viddma
unsigned char	 pkbkup;		 // 0xFD93 magic 'P' count
unsigned char	 *scrbase;	 // 0xFD94 start address of video display
unsigned char	 unused4[6];	 // 0xFD96 - 0xFD9B not used
unsigned char	 mtest0;		 // 0xFD9C
unsigned char	 mtest1;		 // 0xFD9D
unsigned char	 mtest2;		 // 0xFD9E
unsigned char	 unused5;	 // 0xFD9F not used
unsigned char	 palette[32]; // 0xFDA0 - 0xFDBF palette 32 bytes
 // 0xFDC0 - 0xFDFF not used
};

#define MIKEY (*(struct __mikey *)0xFD00)

#endif

 

Then you can do it this way:

 

MIKEY.palette[index] = palette[index] >> 8;
MIKEY.palette[index+16] = palette[index] & 0xFF;

Edited by Shawn Jefferson
Link to comment
Share on other sites

Hi Shawn,

 

Wow, I can see the change in code from that. These sound like great additions to the CC65 Lynx library. It would be awesome to get that support in for real. I would revisit the tutorials and update them. Should you find time to send it to Karri, please let me know.

Link to comment
Share on other sites

A quick noob question on 1k competitions: is the limit on the memory or on the binary for the game? In other words: can you do smart things like calculate sprite structures that might take more than 1k in memory?

 

The 1k is the size of the binary. You can use stuff found in the boot rom (there is nothing of value in there).

 

The 1k is really very difficult. For the Lynx a good minigame would be 2048 bytes. This is exactly how much you can fit in the boot block of a cart with all address lines in use.

 

Part of the 2048 bytes would be eaten by encrypted bootloader (52 bytes). But it would not need a directory, no title sprite. So the rest of the game could take 1996 bytes.

 

Is anyone up to the challange of a single boot-block game competition?

 

For this I suggest BLL. I can also post the tools needed for making an encrypted bootloader. In this way you have full control of every step on the way.

 

A good end-of competition time could be end of January 2013.

 

You need to deliver the game binary in lnx-format (size exactly 2112 bytes - there is a 64 byte lnx header). And a youtube video of a game session (length 2 minutes, preferably commented by the author of the game).

 

The jury could be the Lynx High-Score forum. One vote per player and you can vote for yourself. For an objective result I suggest a point system:

10 points how fun was it to play

10 points how smooth and playable was it

10 bonus points for wow effects, graphics and sounds

 

The points are then summed together and divided by 30 to get a score.

 

The worst and best scores of every game is dropped and from the rest we calculate an average to get the final score.

 

Hmm. That was complicated. Perhaps my 2048 byte entry will be the scoring system for calculating the winner ;)

 

And then we need a nice prize. I am open on this one still...

--

Karri

Edited by karri
Link to comment
Share on other sites

Like promised the writing of the sprite tutorials is under way. You can check out the two new parts at http://atarilynxdeve...r.wordpress.com

 

All feedback is welcome. Please point out incorrect information. Let me know if it is helpful. Next two parts will cover flipping, tilting and positioning. Then it is on to collision detection.

 

Encourage me to get more faster. ;)

 

Working my way through some of the examples, and I noticed a minor error on this page:

http://atarilynxdeveloper.wordpress.com/2012/04/07/programming-tutorial-part-3analyzing-hello-world/

 

The "CLI()" macro is actually defined in 6502.h (probably the only reason you included it) and not lynx.h like the article explains.

Link to comment
Share on other sites

Hi Shawn,

 

Wow, I can see the change in code from that. These sound like great additions to the CC65 Lynx library. It would be awesome to get that support in for real. I would revisit the tutorials and update them. Should you find time to send it to Karri, please let me know.

 

I just got the these additions from Shawn and they are in the cc65 repository now. I hope that the code banging registers directly from C is much more readable after this.

 

--

Karri

Link to comment
Share on other sites

For a single platform contest I don't think you'll get many entries if you limit the size.

 

Perhaps, but the small size will also limit the amount of work you put into it. A minigame is typically something you write in 4 evenings or so. Not a loooong project taking months.

 

If no one is interested then there is no point in doing it. But even a small competition with 3 entries would be nice. I don't expect to have 10 developers entering it.

--

Karri

Link to comment
Share on other sites

Perhaps, but the small size will also limit the amount of work you put into it. A minigame is typically something you write in 4 evenings or so. Not a loooong project taking months.

 

True! It also means that you'll be limited to using assembler to make an interesting game. To attract the most developers you need to make the contest very easy to enter. To me that means a selection of ready made sprites to choose from and also allowing "C" and assembler games with a 4 to 6 month deadline.

Link to comment
Share on other sites

Aah, choices, choices. There are some pros and cons to fixing things in this competition. The size restrictions means an emphasis on smart programming, not graphics and sounds. It will encourage the programmer to leverage the hardware as much as possible. The downside is that you are restricted from using fancy graphics and sound or large logic. Or be smart in that respect. More freedom will make the comparison more difficult. Will we have a theme or are all entries allowed?

 

Anyway, I'm up for the challenge. Put me down as a contestant.

 

If i get to say anything this would be my list of conditions:

- 2 kb limit. Lnx header doesn't count for limit.

- Free graphics, but a set to use would be awesome.

- Deadline of end January seems ok

- bll or c entries are permitted

- Source code release optional.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...