Jump to content
Lynxman

Lynx coding contest

Recommended Posts

Haha ha hahahaha ROTFL

 

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.

Edited by theloon

Share this post


Link to post
Share on other sites

I'm serious. I don't think you can use a 27C080 chip on these things. Or, can you?

 

I think standard slim cartridges use a different type of chip, though I have no idea what it is. I'm curious to this as well.

Share this post


Link to post
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.

 

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.

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

I could contribute with a small Makefile that links in all the needed stuff mentioned above plus a simple Hello World-application with sound and timekeeper.

I am looking forward to it, I am interested in the cc65 sound sample.

Share this post


Link to post
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. ;)

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post
Share on other sites

Snotty much?

 

Well, at least he actually explained himself. Not defending the unwanted attitude. Just saying I was OK with his post :)

Edited by theloon

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

 

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.

 

 

Mybe I stop posting 1k game source codes then :-)

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

Good point. What about a fools day's contest. Deadline 1st of April 2013? Anything goes as long as it runs on the Lynx.

 

--

Karri

  • Like 2

Share this post


Link to post
Share on other sites

Good point. What about a fools day's contest. Deadline 1st of April 2013? Anything goes as long as it runs on the Lynx.

 

Sounds good! The next step would be to decide on a few tile set themes and persuade some pixel artists to help out.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

If there is a size limit I'd rather it be the limit of the available RAM in the machine. With my other projects on the go I wouldn't be able to enter with a January deadline.

Share this post


Link to post
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.

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...