Gemintronic

My initial games will be small, derpy abominations. Most likely simulating text/character graphic games of old. So, not so concerned with extra ROM space. But, price and save game support are important.

You could probably play around with: set kernel_options pfcolors no_blank_lines background I'm thinking that'd give you a colorful background with single color playfield blocks. Although you'd lose a missile. But, the original question wanted 2 players and what I suggested only has 2 sprites. In my scrolling game and in Princess Rescue the players sprite and enemy/item sprite take up all the available, er, sprites.

I know gosubs have overhead.. what about functions?

Enthusiasts have updated the Notepad++ language syntax file for the Jaguar BASIC/C/asm suite JagStudio. It would be jaw droppingly awesome to code almost every Atari platform with one extension Maybe the XML data in there would be useful for at least JagStudio code editing in Atari Dev Studio?

I appreciate the thoughts. It was actually many years ago. That event - thankfully buffered by James Pond 2 - prepared me for further situations down the road. So, came out stronger. James Pond 2 is kind of little a recognized sleeper hit that exists on tons of platforms. PC, GBA, GB, C64, PSX, Playstation 2 and more! The particular soundtrack mentioned was from the Amiga version. My go to version is on the genesis though the SNES arguably is better. The Playstation 2 version is growing on me.

Figured he'd be leary if I told him I helped go through the examples before publishing for Óscar. But, the jig is up! You'll find it's easy to get into the Intellivision. AtariAge makes paying tribute to our favorite systems eminently possible with its community.

You've probably already gone through the YouTube videos that showcase Intellivision titles. Also, played through the back catalogue via emulation. So, really the only thing that got me farther is reading this book and typing in the programs. https://www.lulu.com/en/en/shop/oscar-toledo-gutierrez/programming-games-for-intellivision/paperback/product-1p7mvg87.html?page=1&pageSize=4

Be happy to make a more appropriate scene. What are the resolution / color requirements?

Tried to make a convertible image based on random searches for the requirements of color stack mode. But, I know %100 that I did not make a truly educated guess. nano.bmp

Yeah. I was searching for more information on the color stack mode and failed to switch tabs. I apologize to the original poster (and DZ-Jay). Don't think I can delete posts either.

Only choice is to scrap this and make a web IDE for your port of ZX Basic to the Sega Master System ~_^

Unsure of the requirements for a good convertible picture. Would this do? nano.bmp

I think any system relying on a "walled garden" storefront other than the big 3 is doomed to a meager existence. I hope someone picks back up the FPGA Jaguar core so we no longer need to scrounge for r4r3 old stock for development and gaming. https://misterfpga.org/viewtopic.php?t=342

The designs philosophy of both systems were different beasts. It seems to me the Inty was the first to cater to the game developer with its built in functions in firmware. The Atari 2600 depended on how deeply the programmer understood the hardware. Things like a text display required a huge amount of personal skill (mostly self taught) and certainly not shared knowledge between companies. Most 2600 games that look good do so because they focused on a specific graphical tricks and molded the game around that. The Inty made game design first more of a normal thing - that led to overall amazing graphics and gameplay like Treasure of Tarmin in my opinion. I guess what I'm saying is, if I could trade the raw flexibility of 2600 for the built in functions on the Inty it's a no-brainer.

One of us BASIC or C users could probably write ourselves a LUA interpreter and include it in our projects. Store the tokenized LUA code in eeprom / save memory. Thought of something similar for Atari 2600 projects using a SaveKey (or Genesis with battery backed RAM). Why cause real programmers headaches with GOTO usage when you can make unreadable self modifying code as well?

Imported the updated language file and opened an example .BAS project without error. Used the PortableApps version of Notepad++ and put that in the JagStudio folder. It deserves its own copy https://portableapps.com/apps/development/notepadpp_portable

Been inspecting and modifying examples provided in JagStudio with just a simple text editor. The guide recommends (as far as my rotted brain understands) to use the built in BASIC syntax in Notepad++. But, I remember omf made a rB+ syntax highlighting file awhile back.. ..is that no longer compatible? Seems understandable given the changes to the newer Raptor API.

I just compiled a 32k version of your multi sprite example and it works in Stella. Haven't tried the real console yet because impatience But, very promising! Big thanks to Karl G and Gauauu!!

I've tried copy-and-pasting several projects including my very first a.k.a. "Drunken Pooper" and had no success. https://atariage.com/forums/topic/165286-conversion-of-drunken-pooper/ Does your web based solution support all the different canned kernels or just the bare bones one used when you don't specify "kernel_options"?

Thank you for the example! Really excited for the multi sprite kernel version. I know there isn't much CPU time in that.. but, all my QuadTari game designs revolve around it

Make sure to follow R.T. Getting Started section. R.T.s site is where I find %99.9 of my answers and cheat sheets for commands. https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#gettingstarted But, since VisualbB hasn't been updated in awhile you may wanna just use Visual Studio Code and the Atari Dev Studio extension. https://atariage.com/forums/topic/290365-atari-dev-studio-for-homebrew-development-release/ To go the VisualbB route I follow R.T. getting started section to find the latest links for batari basic and VisualbB and dump the contents into a bB folder. Just run VisualbB.exe from there. Mine is just unzipped into C:\bB. Visual Studio Code link: https://code.visualstudio.com/download 7-zip if you don't already have something for compressed .ZIP files: https://www.7-zip.org/ UPDATE: I forgot one other thing of note. There's this super crusty hacked together "Tinkernut" installer that creates folders like you described. If you used that the first time around uninstall it and start from R.T. getting started guide.

Recently I up (ha!) dated Upp to Upp Plus Plus. Old version here: New game ROM is here: https://theloon.itch.io/upp Thought it might be useful to highlight some of the changes. My code isn't the best solution: just the best that works for me. Hopefully others can find my experience of some use crafting their own improved technique - or, at least avoid my bad habits I want to make it very clear I am not pointing out flaws in batari BASIC, Stella or mini kernel developers. The faults presented here are in my abuse, unintended usage of features and misunderstanding of coding in general. I expanded the ROM from 4k to 32k to fit in more levels. This revealed a booboo in my placement of "include div_mul.asm". While this works in 4k: set kernel_options player1colors pfcolors pfheights set romsize 4k include div_mul.asm Only putting div_mul.asm at the very, very very top works for 32k: include div_mul.asm set kernel_options pfcolors pfheights set romsize 32k Also, any inline asm seems to work best in the actual bank you use it in. So, since I use SeaGtGruffs pfhscroll in the main game loop in bank one I made sure it was the last thing before bank 2. inline pfhscroll.asm bank 2 For the extra hand-crafted levels I made sure to keep the individual level labels very short to avoid problems compiling very long lines of code. Also, keep the number of level labels to 32 just in case there are issues with on .. goto or on .. gosub labels over 40. loadlevelstatic tempvar = rand&31 on tempvar goto l1 l2 l3 l4 l5 l6 l7 l8 l9 l10 l11 l12 l13 l14 l15 l16 l17 l18 l19 l20 l21 l22 l23 l24 l25 l26 l27 l28 l29 l30 l31 l32 In order to avoid triggering paddle auto-detection in Stella I redacted any seemingly paddle related code in std_kernel.asm. Also, renamed any labels in paddlemini.asm to something other than “paddle” (although this shouldn’t actually be a factor.) Not including the modified binaries as I probably scwewed something up unintentionally with my oblivious modifications. Adding Genesis controller support was far easier than I thought thanks to RevEng. Used up a variable for genesispad dim genesispad = z I added this code just after my constants section: genesisdetect rem Detect if a genesis pad is plugged in... rem We only run this once, at the start of the program. genesispad=genesispad & $fe if INPT1{7} then genesispad=genesispad | 1 In the input section of code I put the button C code in. Also, its substitute for normal joysticks: if joy0down then if player1y < 78 then player1y = player1y + 1 : goto after_down if genesispad{0} && !INPT1{7} then if player1y < 78 then player1y = player1y + 1 after_down Only other update to techniques used was to use my constants for colors. If I ever wanted to go PAL60 it’s as easy as swapping out the NTSC constants for PAL ones. rem //** NTSC Colors **// const _orange = $3A const _aqua = $B8 const _black = $00 const _blue = $86 const _dkgray = $F2 const _fuchsia = $58 const _gray = $08 const _green = $D8 const _dkgreen = $D6 const _lime = $DE const _ltgray = $0A const _maroon = $52 const _navy = $A4 const _olive = $E8 const _purple = $6C const _dkpurple = $64 const _red = $44 const _silver = $0C const _teal = $AA const _white = $0E const _yellow = $1E const _brown = $F4 const _dkblue = $70 const _pink = $5E const _skyblue = $AE Hope some part of this was of use. Thanks for slogging through my self inflicted trials and tribulations!

Ah! I see the confusion then. The Arkanoid like ship in Upp is your enemy - you don't actually control it with a paddle or otherwise. Not a paddle controller game though it does look like it.

Thank you for the suggestion to add Genesis controller support! Although, I'm still wondering what feature you wanted the Genesis buttons to do. I suspect is was just to have it use the Genesis controller in any way?

So, after gathering all the feedback over the years I decided to come out with another iteration of Upp. It's been an incredible journey that would be entirely impossible without AtariAge and especially batari, Albert, RevEng and Thomas Jentzsch. Plus, all of you brave souls willing to try new, weird homebrew! Changes from previous versions of Upp include: * 32 additional hand crafted levels/boards * Optional Genesis controller C button support * New stacking ship mechanic: your hit box is taller with more lives. * Eliminated some cheap shots from laser salvo and stasis ball. * Removed lines of code that may have triggered paddle auto-detect in Stella (Thanks RevEng and Thomas Jentzsch) * Added more bonus capsule types that effect the playfield. * Eliminated half-tone flicker effect on blocks due to YouTube mangling the video output in reviews. The digital download and more info here: https://theloon.itch.io/upp As always feedback is super awesome good or bad!)