OldAtAtari Posted August 24, 2020 Author Share Posted August 24, 2020 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. Quote Link to comment Share on other sites More sharing options...
Turbo Laser Lynx Posted August 24, 2020 Share Posted August 24, 2020 Really nice that you got something put together that fast. 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 (matter of taste too of course). 1 Quote Link to comment Share on other sites More sharing options...
42bs Posted August 24, 2020 Share Posted August 24, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
OldAtAtari Posted August 24, 2020 Author Share Posted August 24, 2020 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); } } Quote Link to comment Share on other sites More sharing options...
42bs Posted August 24, 2020 Share Posted August 24, 2020 (edited) Correct. But return is no function, so IMHO it is bad style to write return(0); instead of return 0; Edited August 24, 2020 by 42bs 1 Quote Link to comment Share on other sites More sharing options...
OldAtAtari Posted August 24, 2020 Author Share Posted August 24, 2020 11 minutes ago, 42bs said: Correct. But return is no function, so IMHO it is bad style to write return(0); instead of return 0; Thank you! That's an easy fix. I'll do that. I appreciate you keeping me honest on these things. I'm a better programmer already. Quote Link to comment Share on other sites More sharing options...
Clint Thompson Posted September 18, 2020 Share Posted September 18, 2020 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! 2 Quote Link to comment Share on other sites More sharing options...
OldAtAtari Posted September 18, 2020 Author Share Posted September 18, 2020 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! 1 Quote Link to comment Share on other sites More sharing options...
LX.NET Posted October 1, 2020 Share Posted October 1, 2020 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. 2 Quote Link to comment Share on other sites More sharing options...
OldAtAtari Posted October 1, 2020 Author Share Posted October 1, 2020 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! 1 Quote Link to comment Share on other sites More sharing options...
OldAtAtari Posted February 4, 2021 Author Share Posted February 4, 2021 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 Quote Link to comment Share on other sites More sharing options...
LX.NET Posted February 4, 2021 Share Posted February 4, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
hikachi Posted February 4, 2021 Share Posted February 4, 2021 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? 1 Quote Link to comment Share on other sites More sharing options...
OldAtAtari Posted February 4, 2021 Author Share Posted February 4, 2021 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! Quote Link to comment Share on other sites More sharing options...
OldAtAtari Posted February 4, 2021 Author Share Posted February 4, 2021 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: Quote Link to comment Share on other sites More sharing options...
OldAtAtari Posted December 2, 2022 Author Share Posted December 2, 2022 (edited) 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 December 2, 2022 by OldAtAtari Quote Link to comment Share on other sites More sharing options...
obschan Posted December 2, 2022 Share Posted December 2, 2022 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 Quote Link to comment Share on other sites More sharing options...
OldAtAtari Posted December 2, 2022 Author Share Posted December 2, 2022 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! Quote Link to comment Share on other sites More sharing options...
MichelS Posted December 2, 2022 Share Posted December 2, 2022 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/ Quote Link to comment Share on other sites More sharing options...
OldAtAtari Posted December 2, 2022 Author Share Posted December 2, 2022 (edited) 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 December 2, 2022 by OldAtAtari Quote Link to comment Share on other sites More sharing options...
obschan Posted December 2, 2022 Share Posted December 2, 2022 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 Quote Link to comment Share on other sites More sharing options...
OldAtAtari Posted December 2, 2022 Author Share Posted December 2, 2022 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. Quote Link to comment Share on other sites More sharing options...
OldAtAtari Posted December 2, 2022 Author Share Posted December 2, 2022 (edited) 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 December 2, 2022 by OldAtAtari 1 Quote Link to comment Share on other sites More sharing options...
Ecernosoft Posted December 4, 2022 Share Posted December 4, 2022 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 😃 1 Quote Link to comment Share on other sites More sharing options...
OldAtAtari Posted December 11, 2022 Author Share Posted December 11, 2022 (edited) 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 December 11, 2022 by OldAtAtari 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.