sage Posted October 11, 2012 Share Posted October 11, 2012 Does the slim form factor of Lynx carts constrain game size? Haha ha hahahaha ROTFL Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted October 11, 2012 Share Posted October 11, 2012 (edited) 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 October 11, 2012 by theloon Quote Link to comment Share on other sites More sharing options...
disjaukifa Posted October 11, 2012 Share Posted October 11, 2012 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. Quote Link to comment Share on other sites More sharing options...
sage Posted October 11, 2012 Share Posted October 11, 2012 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. Quote Link to comment Share on other sites More sharing options...
TailChao Posted October 11, 2012 Share Posted October 11, 2012 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. 1 Quote Link to comment Share on other sites More sharing options...
obschan Posted October 12, 2012 Share Posted October 12, 2012 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. Quote Link to comment Share on other sites More sharing options...
LX.NET Posted October 14, 2012 Share Posted October 14, 2012 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. Quote Link to comment Share on other sites More sharing options...
108 Stars Posted October 14, 2012 Share Posted October 14, 2012 This is great, LX.NET. And overall I love to see that this competition might be a success after all! Quote Link to comment Share on other sites More sharing options...
Shawn Jefferson Posted October 14, 2012 Share Posted October 14, 2012 (edited) 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 October 14, 2012 by Shawn Jefferson Quote Link to comment Share on other sites More sharing options...
LX.NET Posted October 15, 2012 Share Posted October 15, 2012 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. Quote Link to comment Share on other sites More sharing options...
LX.NET Posted October 15, 2012 Share Posted October 15, 2012 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? Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted October 15, 2012 Share Posted October 15, 2012 Normally its the size of the binary for the game. Quote Link to comment Share on other sites More sharing options...
DracIsBack Posted October 15, 2012 Share Posted October 15, 2012 Haha ha hahahaha ROTFL Snotty much? 1 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted October 15, 2012 Share Posted October 15, 2012 (edited) Snotty much? Well, at least he actually explained himself. Not defending the unwanted attitude. Just saying I was OK with his post Edited October 15, 2012 by theloon Quote Link to comment Share on other sites More sharing options...
+karri Posted October 16, 2012 Share Posted October 16, 2012 (edited) 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 October 16, 2012 by karri Quote Link to comment Share on other sites More sharing options...
sage Posted October 16, 2012 Share Posted October 16, 2012 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 :-) Quote Link to comment Share on other sites More sharing options...
Shawn Jefferson Posted October 16, 2012 Share Posted October 16, 2012 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. Quote Link to comment Share on other sites More sharing options...
+karri Posted October 16, 2012 Share Posted October 16, 2012 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 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted October 16, 2012 Share Posted October 16, 2012 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. Quote Link to comment Share on other sites More sharing options...
+karri Posted October 16, 2012 Share Posted October 16, 2012 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 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted October 16, 2012 Share Posted October 16, 2012 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. Quote Link to comment Share on other sites More sharing options...
+karri Posted October 16, 2012 Share Posted October 16, 2012 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 2 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted October 16, 2012 Share Posted October 16, 2012 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. Quote Link to comment Share on other sites More sharing options...
LX.NET Posted October 16, 2012 Share Posted October 16, 2012 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. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted October 16, 2012 Share Posted October 16, 2012 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.