Jump to content
IGNORED

My Atari Lynx Programming Journal


OldAtAtari

Recommended Posts

Ok, I figured out my "can't reset at Game Over" problem, more or less.

 

In my Game Over routine, I put the command "lynx_snd_pause()", and later "lnyx_snd_stop()" to prevent the program from playing any last sound effects after printing "Game Over" on the screen. When I removed that statement, the reset worked just fine. So I just put some other conditional code in there to only play sounds if the "Game Over" flag hasn't been set. It's working better now.

 

Probably, I just don't know what lynx_snd_pause and lynx_snd_stop do. I'll learn.

 

 

Link to comment
Share on other sites

Really nice that you got something put together that fast. :thumbsup:

Yeah, Mikey can and does sound a lot like Atari 2600 and Pokey, and in my eyes, well in my ears anyway, Pokey is only matched by SID when it comes to the classic sound chips. Mikey is not quite up to par with Pokey but still sounds by far the best of the classic handheld trio Gameboy/Game Gear/Lynx in my opinion :D (matter of taste too of course).

 

  • Like 1
Link to comment
Share on other sites

22 hours ago, OldAtAtari said:

Hmmm, the "return 1" was there, and now I've moved it around and tried it in different ways. I'm betting that the problem is more of what you said in your other post, which is a stack corruption. That will take some extra work to debug. I'll work on that later.

The point is, the function should return something. Not just be left, because then the return value can be arbitrary. If the return value is not needed, you should make it a good function and return without parameter when you want to leave early. 

  • Thanks 1
Link to comment
Share on other sites

1 minute ago, 42bs said:

The point is, the function should return something. Not just be left, because then the return value can be arbitrary. If the return value is not needed, you should make it a good function and return without parameter when you want to leave early. 

Currently, I have this in the code. Is this better? So regardless of what number the lives variable represents, it will still return something.
 

    if (lives == 0)
        {
        tgi_outtextxy(40, 51, "GAME OVER");
        return(1);
        }
    else
        {
        return(0);
        }
    }

 

Link to comment
Share on other sites

  • 4 weeks later...

Just poking my head into say I appreciate you documenting your Lynx coding journey here and everyone who has been so kind (or not lol) in helping you get to where you are now, compiling something that works! This has been in the back of my mind and it looks like you've done a huge part of the legwork in having something setup that's understandable for a newbie like myself. Hopefully I can use your trial and errors to sit down some weekend when I'm not exhausted and attempt to set everything up in creating something, anything, for the Lynx like you have in the sense of at very least compiling something and making it work, then going from there.

 

My environment is completely Windows these days, have an old Ubuntu box out in the garage that I haven't really touched in about 5 years and really, I'd just prefer to keep it that way at this point. With all of that noise being said, how are you currently getting on with anything new now that it has been a few weeks since your last post?

 

Since 256 color backgrounds are somewhat of a requirement for what I would like to do (not animated mind you, just static backgrounds) why is it required to be done in Assembly over C? Also, do you know the size limitations with using your current environment/setup in regards to game size? I'm guessing you'll beat me to it but I'm also curious to see the pathway into eventually burning your own chips and making your own carts, as I've already learned to do with the Jag.

 

Thanks, look forward to seeing more!

  • Like 2
Link to comment
Share on other sites

8 minutes ago, Clint Thompson said:

Just poking my head into say I appreciate you documenting your Lynx coding journey here and everyone who has been so kind (or not lol) in helping you get to where you are now, compiling something that works! This has been in the back of my mind and it looks like you've done a huge part of the legwork in having something setup that's understandable for a newbie like myself. Hopefully I can use your trial and errors to sit down some weekend when I'm not exhausted and attempt to set everything up in creating something, anything, for the Lynx like you have in the sense of at very least compiling something and making it work, then going from there.

 

My environment is completely Windows these days, have an old Ubuntu box out in the garage that I haven't really touched in about 5 years and really, I'd just prefer to keep it that way at this point. With all of that noise being said, how are you currently getting on with anything new now that it has been a few weeks since your last post?

 

Since 256 color backgrounds are somewhat of a requirement for what I would like to do (not animated mind you, just static backgrounds) why is it required to be done in Assembly over C? Also, do you know the size limitations with using your current environment/setup in regards to game size? I'm guessing you'll beat me to it but I'm also curious to see the pathway into eventually burning your own chips and making your own carts, as I've already learned to do with the Jag.

 

Thanks, look forward to seeing more!

 

Very cool! Thanks, Clint! Yes the people here are amazing. I couldn't have even gotten a program started without their assistance.

 

Yes, it has been a few weeks since my last post. I took some time to work on some sprites for my new game. Then I took a week away from screens (it was amazing, by the way), and I haven't found my way back to my programming yet. I think about it every day, though. Maybe I'll get it fired up this weekend. But it's such an addicting thing for me, I want to be careful to not overdo it. My family really missed me while I was putting that little test game together. ?


As for your color question and size limitations, I don't know. I'm still the new guy around here. I've heard that assembly just allows you to do more. You can really push the limitations of the machine, so maybe if you want to do more than 16 colors, the tricks involved might only be doable with assembly. And I haven't given up on learning assembly, either. But just to hit the ground running, C seems easier.

As for the setup, I've done great with my Windows/Linux hybrid environment, described here: 

 

 

I need to add something to that Windows/Linux environment topic: It turns out that if you hunt through many, many subdirectories in Windows, you can find where the Linux files are stored in that setup. But if you use the Windows editing tools to edit those files, things can get really weird. The proper technique is to create a Windows directory for your Linux game files. So I created a folder on my Windows desktop, and then in the Linux terminal window, I can cd to something like "/mnt/c/users/steven/desktop/linux_dir/Atari/Lynx/". That might not be exactly right. I need to document that properly. Either way, since my game files are stored there, I can access them from both Linux and from Windows. It's really nice.

 

Thanks for the support, and good luck with your programming!

 

 

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...
On 8/9/2020 at 9:30 PM, OldAtAtari said:

Yes, of course! That was actually the first tutorial I tried! "Diary of An Atari Lynx Developer". It's an amazing piece of work, but I had so much trouble when it came to the Hello World example, that I just quit. My environment was all messed up. The example was written for Visual Studio 2010 and older versions of the cc65 tools. I made the mistake of thinking newer was better, so I installed Visual Studio 2019 and the newest cc65. So the example was calling joystick functions that have been renamed in the new cc65 includes, and once I debugged that, Visual Studio 2019 wouldn't compile it, saying that the 2010 tools weren't available. It was a long night, and I never got it working. That's when I went off looking for newer tutorials. Truth is that there is probably a ton of useful information in that tutorial, and I should not have given up on it entirely. I should revisit it and learn what I can from it, which is probably a lot.

Thanks for the comments and the feedback. Do know that I am currently working on improving the dev setup. VS2019 works like a charm, but I am looking into an easy setup for Linux and MacOS as well. This comes down to Visual Studio Code, running on each of these with the CC65 toolchain. To be continued. 

  • Like 2
Link to comment
Share on other sites

3 hours ago, LX.NET said:

Thanks for the comments and the feedback. Do know that I am currently working on improving the dev setup. VS2019 works like a charm, but I am looking into an easy setup for Linux and MacOS as well. This comes down to Visual Studio Code, running on each of these with the CC65 toolchain. To be continued. 

Thank you, LX.NET. I walked away from your tutorial too quickly, frustrated at my inability to compile in VS2019. I should have stuck with your tutorial at least for the information your provide, if not for the examples. I'm constantly referring back to it to learn about sprites and most everything else related to Lynx programming. You've done a great job on it, and once you get it revamped with the VS2019 setup, it will be a tremendous benefit to newbies like me. Thanks again!

  • Thanks 1
Link to comment
Share on other sites

  • 4 months later...

I was having trouble with a 2-color sprite tonight. It was corrupt when displaying on the screen and it took me way too long to find the solution. So I'm posting this here in case I ever need it again. The sprite code needs to change based on the number of colors. My other sprites have had more colors and used BPP_4. This one needs BPP_1. Thank you, Karri!

 

BPP_1 = 2 colours

BPP_2 = 4 colours

BPP_3 = 8 colours

BPP_4 = 16 colours

 

 

Link to comment
Share on other sites

On 10/1/2020 at 3:37 PM, OldAtAtari said:

Thank you, LX.NET. I walked away from your tutorial too quickly, frustrated at my inability to compile in VS2019. I should have stuck with your tutorial at least for the information your provide, if not for the examples. I'm constantly referring back to it to learn about sprites and most everything else related to Lynx programming. You've done a great job on it, and once you get it revamped with the VS2019 setup, it will be a tremendous benefit to newbies like me. Thanks again!

I updated the Windows based setup to refer to VS2019. https://atarilynxdeveloper.wordpress.com/2012/04/07/programming-tutorial-part-2development-environment/

PLease let me know what you think of the new article and whether it is more helpful. Any questions, feel free to ask.

  • Like 1
Link to comment
Share on other sites

On 10/1/2020 at 12:25 PM, LX.NET said:

Thanks for the comments and the feedback. Do know that I am currently working on improving the dev setup. VS2019 works like a charm, but I am looking into an easy setup for Linux and MacOS as well. 

If I can suggest something - maybe providing Virtual Machine image with lightweight Linux distro and working setup would be good idea? 

  • Like 1
Link to comment
Share on other sites

8 hours ago, LX.NET said:

I updated the Windows based setup to refer to VS2019. https://atarilynxdeveloper.wordpress.com/2012/04/07/programming-tutorial-part-2development-environment/

Please let me know what you think of the new article and whether it is more helpful. Any questions, feel free to ask.

LX.NET, thank you so much for doing this. I think this will help a lot of people. I just skimmed the article, and it looks terrific. Later on, I hope to follow the instructions and see how it works. I will let you know once I've tried it. Thanks again!

Link to comment
Share on other sites

7 hours ago, hikachi said:

If I can suggest something - maybe providing Virtual Machine image with lightweight Linux distro and working setup would be good idea? 

hikachi, this might be what you're looking for. When I got frustrated last year, I created a hybrid Windows10/Linux environment. So I can use Windows tools, and I can also use Linux terminal windows for the Linux tools. Windows 10 has built-in Linux distributions these days, and it's a really easy setup. I've really enjoyed it. For my text editor, I use Notepad++ in Windows. For my graphics editor, I use Gimp in Windows. But for all the cc65 stuff and all the compiling, I use the Linux terminal window which is right there on my Windows desktop. Oh, and my emulator is Handy for Windows. I wrote up a tutorial explaining the setup:
 

 

Link to comment
Share on other sites

  • 1 year later...

I'm resurrecting this topic, now that I'm back in the hobby to create a Lynx Jam 2022 game in the next 10 days.

After a long break, I found that my setup was corrupted, so I had to recreate my environment. Everything seems right, but when I run a "make" on the Karri/nop90 template, the *.lynx file it creates is smaller than it used to be, and it won't load in Handy. Same with my other previously good directories.

Anyone have a guess as to why make would create a different output now versus a year ago? It's the same sample game template. What could I be doing wrong?

Thanks. 

 

Steven@StevensLaptop:~/Atari/template$ make -B
"make" -C game;
make[1]: Entering directory '/home/sreed/Atari/template/game'
cc65 -t lynx -I /usr/local/lib/cc65/include -I . --add-source -O -Or -Cl -Os --code-name GAME_CODE --rodata-name GAME_RODATA --data-name GAME_DATA --bss-name GAME_BSS -o  game.s game.c
ca65 -t lynx -I /usr/local/lib/cc65/asminc -o game.o  game.s
rm -f game.s
sp65 -r tree.pcx -c lynx-sprite,mode=packed,ax=94,ay=168 -w tree.c,ident=tree,bytesperline=8
cc65 -t lynx -I /usr/local/lib/cc65/include -I . --add-source -O -Or -Cl -Os --code-name GAME_CODE --rodata-name GAME_RODATA --data-name GAME_DATA --bss-name GAME_BSS -o  tree.s tree.c
ca65 -t lynx -I /usr/local/lib/cc65/asminc -o tree.o  tree.s
rm -f tree.s
rm -f objlist
for obj in game.o tree.o; do echo ../game/$obj >> objlist; done
make[1]: Leaving directory '/home/sreed/Atari/template/game'
"make" -C intro;
make[1]: Entering directory '/home/sreed/Atari/template/intro'
cc65 -t lynx -I /usr/local/lib/cc65/include -I . --add-source -O -Or -Cl -Os --code-name INTRO_CODE --rodata-name INTRO_RODATA --data-name INTRO_DATA --bss-name INTRO_BSS -o  intro.s intro.c
ca65 -t lynx -I /usr/local/lib/cc65/asminc -o intro.o  intro.s
rm -f intro.s
sp65 -r bg.pcx -c lynx-sprite,mode=packed -w bg.c,ident=bg,bytesperline=8
cc65 -t lynx -I /usr/local/lib/cc65/include -I . --add-source -O -Or -Cl -Os --code-name INTRO_CODE --rodata-name INTRO_RODATA --data-name INTRO_DATA --bss-name INTRO_BSS -o  bg.s bg.c
ca65 -t lynx -I /usr/local/lib/cc65/asminc -o bg.o  bg.s
rm -f bg.s
rm -f objlist
for obj in intro.o bg.o; do echo ../intro/$obj >> objlist; done
rm bg.c
make[1]: Leaving directory '/home/sreed/Atari/template/intro'
"make" -C resident;
make[1]: Entering directory '/home/sreed/Atari/template/resident'
ca65 -t lynx -I /usr/local/lib/cc65/asminc -o fadein.o  fadein.s
ca65 -t lynx -I /usr/local/lib/cc65/asminc -o fadeout.o  fadeout.s
cc65 -t lynx -I /usr/local/lib/cc65/include -I . --add-source -O -Or -Cl -Os --code-name CODE --rodata-name RODATA --data-name DATA --bss-name BSS -o  LynxSD.s LynxSD.c
ca65 -t lynx -I /usr/local/lib/cc65/asminc -o LynxSD.o  LynxSD.s
rm -f LynxSD.s
ca65 -t lynx -I /usr/local/lib/cc65/asminc -o lynxeeprom.o  lynxeeprom.s
ca65 -t lynx -I /usr/local/lib/cc65/asminc -o lynx-snd.o  lynx-snd.s
cc65 -t lynx -I /usr/local/lib/cc65/include -I . --add-source -O -Or -Cl -Os --code-name CODE --rodata-name RODATA --data-name DATA --bss-name BSS -o  resident.s resident.c
ca65 -t lynx -I /usr/local/lib/cc65/asminc -o resident.o  resident.s
rm -f resident.s
rm -f objlist
for obj in fadein.o fadeout.o LynxSD.o lynxeeprom.o lynx-snd.o resident.o; do echo ../resident/$obj >> objlist; done
make[1]: Leaving directory '/home/sreed/Atari/template/resident'
"make" -C tunes;
make[1]: Entering directory '/home/sreed/Atari/template/tunes'
ca65 -t lynx -I /usr/local/lib/cc65/asminc -o track2.o  track2.s
rm -f objlist
for obj in track2.o; do echo ../tunes/$obj >> objlist; done
make[1]: Leaving directory '/home/sreed/Atari/template/tunes'
"make" -C cart;
make[1]: Entering directory '/home/sreed/Atari/template/cart'
ca65 -t lynx -I /usr/local/lib/cc65/asminc -o lnxhdr.o  lnxhdr.s
ca65 -t lynx -I /usr/local/lib/cc65/asminc -o directory.o  directory.s
cl65 -t lynx -o game.lnx -m lynx.map -C lynx.cfg lnxhdr.o directory.o @../resident/objlist @../intro/objlist @../game/objlist @../tunes/objlist lynx.lib
make[1]: Leaving directory '/home/sreed/Atari/template/cart'
Steven@StevensLaptop:~/Atari/template$

 

Edited by OldAtAtari
Link to comment
Share on other sites

Just a guess, the structure of the directory has changed. Check your entry macro. it should be something like that now:

.macro entry old_off, old_len, new_off, new_block, new_len, new_size, new_addr
new_off=old_off+old_len
new_block=new_off/__BLOCKSIZE__
new_len=new_size
	.word	new_block
	.word	(new_off & (__BLOCKSIZE__ - 1))
	.word	new_addr
	.word	new_len
.endmacro

 

Link to comment
Share on other sites

Quote
3 hours ago, obschan said:

Just a guess, the structure of the directory has changed. Check your entry macro. it should be something like that now:

.macro entry old_off, old_len, new_off, new_block, new_len, new_size, new_addr
new_off=old_off+old_len
new_block=new_off/__BLOCKSIZE__
new_len=new_size
	.word	new_block
	.word	(new_off & (__BLOCKSIZE__ - 1))
	.word	new_addr
	.word	new_len
.endmacro

 

Wow. Thank you so much! I haven't encountered macros before. I don't even know where to look to investigate this. I'll do some research and try to figure it out. Thanks again!

Link to comment
Share on other sites

3 hours ago, MichelS said:

Karri changed the rom directory structure of his CC65 in May - see:

https://forums.atariage.com/topic/336279-my-cc65-version-of-the-compiler-directory-structure-has-changed/

 

Thank you! That is most definitely my problem! And maybe related to what obschan said.

 

Now I just have to figure out how to adjust or recreate my setup to work with the new structure.

 

Thanks again!

Edited by OldAtAtari
Link to comment
Share on other sites

26 minutes ago, OldAtAtari said:

Wow. Thank you so much! I haven't encountered macros before. I don't even know where to look to investigate this. I'll do some research and try to figure it out. Thanks again!

there :

ca65 -t lynx -I /usr/local/lib/cc65/asminc -o directory.o  directory.s
Link to comment
Share on other sites

2 hours ago, obschan said:

there :

ca65 -t lynx -I /usr/local/lib/cc65/asminc -o directory.o  directory.s

Thank you! I'm not sure what to do with that command. By itself, it definitely recompiles the directory.o file. But I assume it needs to be somehow rolled into the Makefile somehow in order to fix the ultimate problem. I have plenty of experience as a Linux user, but when it comes to these behind-the-scene things, I'm still pretty dumb.

Since this seems specifically related to Karri's ROM directory structure change, I went ahead and asked in that topic for some dumbed-down instructions. Maybe it will help me as well as the next person if it's in that topic instead of this one.

Link to comment
Share on other sites

1 hour ago, OldAtAtari said:

Thank you! I'm not sure what to do with that command. By itself, it definitely recompiles the directory.o file. But I assume it needs to be somehow rolled into the Makefile somehow in order to fix the ultimate problem. I have plenty of experience as a Linux user, but when it comes to these behind-the-scene things, I'm still pretty dumb.

Since this seems specifically related to Karri's ROM directory structure change, I went ahead and asked in that topic for some dumbed-down instructions. Maybe it will help me as well as the next person if it's in that topic instead of this one.

Argh! Disregard!

 

I see what you were saying now! You were pointing me to look in the directory.s file for the entry macro! It's in that file, and I fixed it! I just made my entry macro match what you posted earlier. Everything compiles now.

 

Thank you, @obschan!

And thank you, @MichelS!

Edited by OldAtAtari
  • Like 1
Link to comment
Share on other sites

On 8/6/2020 at 10:47 AM, Songbird said:

Very cool, thanks for sharing all these steps and links! Lynx programming is fun, and I have done both -- actually wrote a couple of Lynx games in C ~20 years ago, but this year I am working on two pure assembly games. :)

 

I agree! Lynx programming is fun, and it’s very versatile. Too bad the vertical resolution is only 102…. Hey, it’s better than the game boy 😃 

  • Like 1
Link to comment
Share on other sites

It took me a while to figure out how to access the Option1 and Option2 buttons. So I'm posting here for others (and myself) to read later on. 

 

if(SUZY.joystick == BUTTON_OPTION1) // Do the following thing if Opt1 is pressed
    {
     stuff;
     and more stuff;
    }


//The following is from the file suzy.h
/* Joypad $FCB0 */
#define JOYPAD_RIGHT    0x10
#define JOYPAD_LEFT     0x20
#define JOYPAD_DOWN     0x40
#define JOYPAD_UP       0x80
#define BUTTON_OPTION1  0x08
#define BUTTON_OPTION2  0x04
#define BUTTON_INNER    0x02
#define BUTTON_OUTER    0x01

/* Switches $FCB1 */
#define BUTTON_PAUSE    0x01

 

 

 

Edited by OldAtAtari
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...