7800basic beta, the release thread

[+Atarius Maximus]

RevEng, it's all your fault that I'm now (at least for the time being) going to be abandoning 2600 bB as I'm much more interested in this now. I also own a Cuttle Cart 2 from many years ago so I can test and play games on real 7800 hardware.

[RevEng]

RevEng, I'd strongly suggest a more detailed tutorial in the manual about how to create images that are compatible. I wound up using Gimp and will have to spend a little time learning it, but it was much easier than trying to figure it out in Photoshop. If you lack experience using an advanced image editor that's going to be a major stumbling block to developing a game, IMO.

 

Edit: I'd consider including Trebor/Synthpopalooza's palette files in the distribution as well, if they are ok with it.

I'll let the guys chime in if they're OK with redistribution, but it sounds like a good idea to me.

 

The graphic tutorial idea is good too. I'll fit it in somewhere in the ever-growing list of things to do.

 

 

RevEng, it's all your fault that I'm now (at least for the time being) going to be abandoning 2600 bB as I'm much more interested in this now. I also own a Cuttle Cart 2 from many years ago so I can test and play games on real 7800 hardware.

Its funny you should say that, I actually did spend a minute worrying that I might wind up poaching from the limited bB developer pool with this thing, but I figured that anybody wanting to change would already have wandering eyes.

 

Anyway, we need to do new things with our retro hobby, or else it gets boring and we move on and stop visiting the forums. The nice thing here is you can spend time with 7800basic and keep your general bB syntax sharp, jumping back when something cool like bus-stuffing happens on that side of the fence.

[+Atarius Maximus]

Its funny you should say that, I actually did spend a minute worrying that I might wind up poaching from the limited bB developer pool with this thing, but I figured that anybody wanting to change would already have wandering eyes.

 

Anyway, we need to do new things with our retro hobby, or else it gets boring and we move on and stop visiting the forums. The nice thing here is you can spend time with 7800basic and keep your general bB syntax sharp, jumping back when something cool like bus-stuffing happens on that side of the fence.

 

Time to join the dark side? I go for months without checking the forums, not because I'm not interested anymore but because life gets in the way. It'll always be fun for me, 2600 or 7800.

 

I read through the manual several times but need to more fully understand collision detection, it wasn't clear... although I haven't really tried experimenting yet. I want to start simple and maybe make a clone of my most recent 2600 project 'Touchdown Challenge'. It's a simple concept, just have one sprite move up the screen and get to the top without touching any others. I may have more questions once I have more time to dive in (and will probably start another topic rather than hijack this one) but any more info/examples on collision detection would be helpful.

[Trebor]

I'll let the guys chime in if they're OK with redistribution, but it sounds like a good idea to me.

 

It would be an honor. Although thorough, the sheer number of palettes in the aforementioned linked post may be a bit overwhelming for some.

 

I created a smaller set below utilizing one of the brighter and more saturated lines ("x6") to better simulate colors from a CRT while just giving 3 different phase shifts simulations for each region:

 

25.7 degrees - Perfectly calibrated not accounting for any additional phase shifting during consistent console runtime.

26.7 degrees - A more ideal presentation of palette colors accommodating both automatic higher phase shifting after calibration is performed and Atari's own documented description of color order.

27.7 degrees - Possible final resulting palette with a longer consistent console runtime.

 

It includes *.pal and *.act files along with respective color reference charts.

 

Under NTSC, my advice is to avoid Ex and Fx like the plague.

 

Instead of any greens from Ex go with Dx instead.

Instead of any browns from Fx go with 1x instead, or a 2x value if you like a "warmer" system's Fx color value.

 

PALETTESx6.zip

 

NTSC [25.7 --> 26.7 --> 27.7]

 

PAL [25.7 --> 26.7 --> 27.7]

[RevEng]

@Trebor: I knew you'd be glad to share, but one has to ask. Thanks!

 

@Atarius Maximus...

 

Did you see the "boxcollision" program in the sample directory? It pretty much distills collision detection using the boxcollision function down to basics.

 

Since the MARIA chip in the 7800 lacks hardware collision detection, we need to check if sprites collided using a bunch of math and if...thens, or with the "boxcollision" function that does a bunch of math and if..thens for you.

 

If you are doing a simple collision check, like between a single-pixel bullet and a larger sprite, you may wish to roll your own. In that case just check that the x coordinate of the bullet is greater than the x coordinate of the left-side of the sprite AND less than the x coordinate of the right-side of the sprite. Then repeat the same check with y coordinate of the bullet and sprite y top and bottom coordinates. The guide has an example of this.

 

The math and if...thens get more complicated if you begin to check for collision between two sprites with height and width, since you have more points to check. Hence the boxcollision function, which does the math and if...thens for you, and in a 6502 optimized way. To check if two sprites are overlapping, just pass boxcollision their coordinates, widths, and heights, and it does the heavy lifting for you, returning TRUE if the objects overlap or FALSE if they don't overlap.

 

Let me know if that explanation and the sample program clears things up.

[+Atarius Maximus]

@Trebor: I knew you'd be glad to share, but one has to ask. Thanks!

 

@Atarius Maximus...

 

Did you see the "boxcollision" program in the sample directory? It pretty much distills collision detection using the boxcollision function down to basics.

 

Since the MARIA chip in the 7800 lacks hardware collision detection, we need to check if sprites collided using a bunch of math and if...thens, or with the "boxcollision" function that does a bunch of math and if..thens for you.

 

If you are doing a simple collision check, like between a single-pixel bullet and a larger sprite, you may wish to roll your own. In that case just check that the x coordinate of the bullet is greater than the x coordinate of the left-side of the sprite AND less than the x coordinate of the right-side of the sprite. Then repeat the same check with y coordinate of the bullet and sprite y top and bottom coordinates. The guide has an example of this.

 

The math and if...thens get more complicated if you begin to check for collision between two sprites with height and width, since you have more points to check. Hence the boxcollision function, which does the math and if...thens for you, and in a 6502 optimized way. To check if two sprites are overlapping, just pass boxcollision their coordinates, widths, and heights, and it does the heavy lifting for you, returning TRUE if the objects overlap or FALSE if they don't overlap.

 

Let me know if that explanation and the sample program clears things up.

 

Thanks RevEng, I had limited time today and was pretty much only looking at your adventurer and multisprite samples. My bad. Thanks for the explanation and I'll look at your boxcolllision sample tomorrow. I'm sure you're going to get sick of people missing the obvious and pointing them back to the manual and samples you've already created.

[RevEng]

No worries. Someone needs to answer the easy questions, direct people to resources, etc., until enough helpful people are bootstrapped.

[iesposta]

"Instead of any browns from Fx go with 1x instead, or a 2x value if you like a "warmer" system's Fx color value."

 

For what it's worth, I say this about 2600 as well.

Some systems I have show my brown ape as green when I use Fx for brown.

Always use dark orange for consistent brown in 7800 or 2600.

[+Atarius Maximus]

 

It would be an honor. Although thorough, the sheer number of palettes in the aforementioned linked post may be a bit overwhelming for some.

 

I created a smaller set below utilizing one of the brighter and more saturated lines ("x6") to better simulate colors from a CRT while just giving 3 different phase shifts simulations for each region:

 

25.7 degrees - Perfectly calibrated not accounting for any additional phase shifting during consistent console runtime.

26.7 degrees - A more ideal presentation of palette colors accommodating both automatic higher phase shifting after calibration is performed and Atari's own documented description of color order.

27.7 degrees - Possible final resulting palette with a longer consistent console runtime.

 

It includes *.pal and *.act files along with respective color reference charts.

 

Under NTSC, my advice is to avoid Ex and Fx like the plague.

 

Instead of any greens from Ex go with Dx instead.

Instead of any browns from Fx go with 1x instead, or a 2x value if you like a "warmer" system's Fx color value.

 

PALETTESx6.zip

 

NTSC [25.7 --> 26.7 --> 27.7]

NTSC_25-7.PNGNTSC_26-7.PNGNTSC_27-7.PNG

 

PAL [25.7 --> 26.7 --> 27.7]

PAL_25-7.PNGPAL_26-7.PNGPAL_27-7.PNG

 

Very impressive, Trebor, I am humbled by your knowledge and appreciate your reply to my earlier post. With that said and no disrespect meant to you at all, your post is mostly over my head. I ended up following Synthpopalooza's info to get an image to properly export and work in Gimp based on one of his earlier posts. I'd love a dumbed down version if you think it's feasible or even relevant to this discussion. I'm most accustomed to creating single color sprites for the 2600. That's of course why I mentioned to RevEng explaining the creation of 7800 images in more detail, of course. I just don't understand it well and I'm probably not the only one.

[Trebor]

"Instead of any browns from Fx go with 1x instead, or a 2x value if you like a "warmer" system's Fx color value."

 

For what it's worth, I say this about 2600 as well.

Some systems I have show my brown ape as green when I use Fx for brown.

Always use dark orange for consistent brown in 7800 or 2600.

Same may happen with a 5200. The three consoles behave very similarly.

 

The console could be calibrated for less than 25.7 degrees or when "cooler" will fall under 25.7 degrees regardless.

Here's what just a 1 degree difference makes with a 2600 console at 24.7 degrees.

Notice that bottom Fx row looking pretty green

[Trebor]

With that said and no disrespect meant to you at all, your post is mostly over my head. I ended up following Synthpopalooza's info to get an image to properly export and work in Gimp based on one of his earlier posts. I'd love a dumbed down version if you think it's feasible or even relevant to this discussion.

 

Not a problem at all.

 

Short and Sweet:

Essentially the 7800 palette = 5200 palette regarding the number of colors available as well as their hue order.

 

The NTSC 2600 palette = NTSC 5200/7800 palette, but with half of the brilliance ramp. Notice along the top of the color chart screen captures posted the listing of: "0, 1, 2 ,3...C, D, E, F" running from left to right. For the 2600, you eliminate every other column, which cuts the 7800/5200 palette of 256 colors down to the 2600 color palette of 128 colors. The Hue order though is the same running from top to bottom.

 

If you are happy with a color selection for the 2600, as it appears on real hardware, in a nut shell, there are more dark/light shades of that color available under the 7800.

 

Here's the NTSC 7800 and NTSC 2600 side-by-side (Both at 25.7 degrees):

 

A Little More Depth:

The 'factory ideal' and outcome of following the instructions per the 7800 Diagnostic Cart, would be fine tuning the color pot so that Hue 1x = F/15x. At that setting, the phase shift value equals ~25.7 (or more precisely 25.714) degrees. There is a cart for the 2600 with the same intent.

 

So, if nothing else were to happen, and a 7800 console was factory tuned, ideally, that would be the palette setting: ~25.7 degrees phase shift, where 1x = Fx.

 

The reason there is a series of additional phase shifts (26.2, 26.7, 27.2, 27.7) having higher degrees set is that despite color pot adjusting a system to factory default of ~25.7 degrees, over time, as the console (and its components) 'warm up', the degrees of phase shift increases gradually. The rate and total amount at which it increases may vary across consoles.

 

Additionally, Atari tech documents provide details where instead of Fx = 1x, Fx falls between 1x and 2x in its description: 1x = Gold, 2x = Orange, F/15x = Light Orange. The phase shift of 26.7 degrees (also 26.2 degrees as an alternative) accounts for both the system 'warm up' and the hue descriptions provided by technical documentation.

 

The reality though is many systems go even higher in their phase shifting (I.E. 27.2, 27.7 degrees) as they 'warm up'. Once reaching 27.7 degrees, the end result is E/14x = 1x and F/15x = 2x, along with the other hues being adjusted considerably too. However, phase shifting's impact visually diminishes the higher you go towards the 'top', as can be seen in the previously posted color charts.

 

Hue 1x (NTSC = "Gold" range) is never affected by phase shifting as that is controlled by the tint/hue setting of the display. Hue 3x and especially Hue 2x changes by the naked eye would be very hard if not impossible to distinguish among the phase shifts noted. Hue 15/Fx and Hue 14/Ex are the most affected, hence the advice to avoid them completely as there are better (consistent) alternatives.

 

A more extensive breakdown of all the above is here.

 

Side Note:

The sample pattern Synthpopalooza linked to appears similar to the one from the Prosystem emulator default with a few improvements. The ProSystem emulator's default/internal palette is a hand-picked one that kind of combines PAL and NTSC results, as well as incorporating a very high degree of phase shifting (Greater than 28 degrees).

 

Utilizing either the ProSystem emulator's default, or the slightly improved one linked to earlier as reference, may provide less than desirable results, since the brilliance ramp is skewed and there are inaccuracies and inconsistencies in many areas, including the hand-picked manipulated interpretation of phase shift and resulting colors. The seemingly 'hybrid' nature of the palette is also incorrect, despite the regions being similar in appearance, there are differences between NTSC and PAL 7800 colors (Mostly a one row shift).

 

Region Conversion for 7800 Colors:

NTSC 1x		PAL 2x
NTSC 2x		PAL 3x
NTSC 3x		PAL 4x
NTSC 4x		PAL 5x
NTSC 5x		PAL 6x
NTSC 6x		PAL 7x
NTSC 7x		PAL 8x
NTSC 8x		PAL 9x
NTSC 9x		PAL 10/Ax
NTSC 10/Ax	PAL 11/Bx
NTSC 11/Bx	PAL 12/Cx
NTSC 12/Cx	PAL 13/Dx
NTSC 13/Dx	PAL 14/Ex
NTSC 14/Ex	PAL 15/Fx [May be also PAL 1x when phase shift equals ~25.7 degrees]
NTSC 15/Fx	N/A [Except being PAL 2x when phase shift equals ~25.7 degrees]

 

Visual representation of the above with a 26.7 degree phase shift (In harmony with the tech documented values and accounting for some system 'warm-up'):

Additional Notes:

-Avoid NTSC Ex and Fx during color selections for more consistent results across systems.

-NTSC Hue 1x tends to have a green(er) default range on modern flat panel displays with the real hardware as opposed to the golden range stated in the tech docs and witnessed on CRTs. Its demonstrated for the 7800 here, and 2600 here. Further, the aforementioned not fully understood at the time, Yurkie's (No longer available) console mod was mistakenly thought to have color issues, but it was simply the default 'greener'/'less red' lean effect or default tint/hue setting of a modern flat panel display that needed to be adjusted.

 

Keeping the above points in mind, referencing the following (excluding 'rows' not listed) ensures more consistent color results across different phase shifts, display types, and regions:

NTSC 2x		PAL 3x
NTSC 3x		PAL 4x
NTSC 4x		PAL 5x
NTSC 5x		PAL 6x
NTSC 6x		PAL 7x
NTSC 7x		PAL 8x
NTSC 8x		PAL 9x
NTSC 9x		PAL 10/Ax
NTSC 10/Ax	PAL 11/Bx
NTSC 11/Bx	PAL 12/Cx
NTSC 12/Cx	PAL 13/Dx
NTSC 13/Dx	PAL 14/Ex

To visualize the above, here are the two regions crossed referenced with (the tech documented values and accounting for some system 'warm-up' setting of) 26.7 degrees:

[BioForceApe]

Turns out that the blank line of tiles was an intended black bar. Btw, it was so easy to spot the line of code I needed to change for so long! I seemed to overlook it. :l I can't perfect the guy by changing heroy into decimals such as heroy/16.7 but 17 is close. The game now reads 16 zoneheight tiles really fine!

 

Sorry if I overreacted, I haven't done BASIC language in a long time, and things are just starting to come back.

Edited June 6, 2014 by BioForceApe

[RevEng]

No worries. Glad you worked out the issue!

[RevEng]

beta 0.2 20140608 is now in the first post, replacing the old version.

 

This version adds a new TIA sound effect engine and the "playsfx" command. 7800basic will automatically select the TIA audio channel to play the sound with, based on which channel isn't in use. If both channels are in use and it needs to interrupt an existing sound to play the new one, it will do so based on the dynamic priority system.

 

Attached here is the "soundtest" program, which allows you to play sounds from a collection of original and classic sound effects. soundtest is also included in the 7800basic samples directory.

soundtest.bas

soundtest.bas.a78

soundtest.bas.bin

[+Atarius Maximus]

beta 0.2 20140608 is now in the first post, replacing the old version.

 

This version adds a new TIA sound effect engine and the "playsfx" command. 7800basic will automatically select the TIA audio channel to play the sound with, based on which channel isn't in use. If both channels are in use and it needs to interrupt an existing sound to play the new one, it will do so based on the dynamic priority system.

 

Attached here is the "soundtest" program, which allows you to play sounds from a collection of original and classic sound effects. soundtest is also included in the 7800basic samples directory.

 

Cool. Look forward to trying out the new playsfx command and checking out the soundtest sample program.

[+Atarius Maximus]

Its funny you should say that, I actually did spend a minute worrying that I might wind up poaching from the limited bB developer pool with this thing, but I figured that anybody wanting to change would already have wandering eyes.

 

Anyway, we need to do new things with our retro hobby, or else it gets boring and we move on and stop visiting the forums. The nice thing here is you can spend time with 7800basic and keep your general bB syntax sharp, jumping back when something cool like bus-stuffing happens on that side of the fence.

 

I meant to respond to this earlier. I agree, having a new creative outlet is refreshing and needed to keep this hobby interesting. Once bB developers discover this I think they'll want to use both. I attempted to start on a sequel to CaveIn with bB and DPC+, but was frustrated by the limitations on the size of the graphics bank. With the high resolution graphics I wanted I could have made only 16 unique screens and I had around 40-50 in the original. At the moment I'd like to remake every game I've made in bB in 7800basic. The 7800 Adventure demo I posted has the map layout I created last year for Cave In II (which at this point will never happen). I'm going to have to re-do the map some point for the new game of course. So much to do, so little time.

[+Gemintronic]

I'm pretty sure I'll still use bB for future projects. Anything that needs more than two sprites is going straight to 7800BAS, though! There are just enough differences and quirks in the multi-sprite kernel that I get easily confused and discouraged.

[+Atarius Maximus]

I'm pretty sure I'll still use bB for future projects. Anything that needs more than two sprites is going straight to 7800BAS, though! There are just enough differences and quirks in the multi-sprite kernel that I get easily confused and discouraged.

It is your destiny, join me and together we can rule the galaxy.

[RevEng]

Just watch out for his force-lightning, theloon.

 

beta 0.2 20140612 is now in the first post.

 

This one is a small update, with just a single fix for a bug I found in memcpy.

[Shannon]

Just watch out for his force-lightning, theloon.

 

beta 0.2 20140612 is now in the first post.

 

This one is a small update, with just a single fix for a bug I found in memcpy.

 

Let me guess... it works fine except when copying to overlapping memory areas...

 

Sorry... bad Atari Basic Rev A joke....

[RevEng]

beta 0.2 20140620 is now in the first post.

 

Here's the changelog excerpt...

• added the "incmapfile" command, to import Tiled TMX files so they can be used as character map data.
• enhanced playsfx. if a sound is given 0 initial priority it won't interrupt any playing sounds.
• added the 7800basic logo to the samples directory and in the Developers Guide.
• fixed a bug in plotmap that caused a compile error when ":" followed the command.
• fixed a bug in plotchars. The optional extrawide parameter wasn't working.
• fixed a bug that would under certain circumstances cause a compile error when complex math was used.
• fixed a bug that would cause a compile error when the sread command was used.

[+Random Terrain]

I haven't looked at the logo yet. So it's officially 7800basic, not 7800BASIC or 7800Basic?

[RevEng]

I prefer "7800basic" when typing, mainly for ease.

 

The logo deviates by using all caps, but this was done to evoke the ATARI logo used on a number of their machines.

[+Random Terrain]

I prefer "7800basic" when typing, mainly for ease.

 

The logo deviates by using all caps, but this was done to evoke the ATARI logo used on a number of their machines.

OK, thanks.

[+Atarius Maximus]

It's time to create a 7800basic page on your site, RT! I haven't used all of the commands or features yet, but I'd be willing to help.

 

What I'm loving about 7800basic is the lack of restrictions that exist compared to bB, there are so many compromises that need to be made in bB with the different kernel options. So far it seems like I could do anything the original developers could do with 7800basic, I wish I had more time to work on all my ideas. 20 multicolor sprites on screen with no flicker or slowdown, unlimited text graphics on screen, 8 color palettes with 3 colors each (+transparent) for sprites and the background, two six digit scores, up to 512k ROMs with bankswitching (48k without), tiled bitmapped graphics, tons of CPU cycles compared to the 2600... it's like an 8bit programmer's dream come true.

 

While I am wrapped up in this adventure game thing, my biggest feature request would be scrolling. I'd love to attempt a racing game.