Jump to content
RevEng

7800basic beta, the release thread

Recommended Posts

I may have a go at this thing in the next two days. Pac-Man-Red has designed some sprites for me to try out.

 

When you do get those peekchar and pokechar functions ready, if you could put in an example for platform games that would be super. Just something to determine if my rocketman is standing on a platform, or if he's not got anything under his feet and begins falling.

 

I have the game's entire physics laws mapped out in my head. No jumping or ladders, only a rocketpack. Flying into a structure from below makes him fall, and you basically don't get to do anything (controls won't work) until he lands safely again (if at all).

  • Like 1

Share this post


Link to post
Share on other sites

I have both peekchar and pokechar ready, along with a platform example. :)

 

It's also the first meaningful example with zone height = 8, so I also made it an example of how to do sprites taller than the zone height.

 

Because it's a minimal demo, there isn't jumping. He just falls from platform to platform.

 

Sadly, I've lost the ability to modify that first post. I've asked for it to be restored, but there's a technical glitch preventing that, so the request was raised up. Hopefully it won't be much longer.

 

In the meantime, here's a zip with the binaries and source for the example, so you can look it over.

 

ramcharmap.zip

  • Like 4

Share this post


Link to post
Share on other sites

Thanks to CPUWIZ and co. the beta 0.1 20140311 is now in the first post, replacing the old version.

 

This one has memcpy, peekchar, and pokechar.

 

Here's the change log...

  • fixed alphadata so the format of the generated assembly for large amounts of data wouldn't segfault dasm.
  • added memcpy command.
  • added peekchar and pokechar commands.
  • added "ramcharmap" sample.
  • fixed bug that slightly reduced efficiency of plotmap palette setup.
  • Like 5

Share this post


Link to post
Share on other sites

Ok, I modified the example code, now I had some questions:

 

First off, here's the modified physics: No jumping, instead the sprite flies to the top of the screen when you depress the fire1 button. Here are the rules for flying and falling:

 

* You can move left and right while flying

* When you release the trigger, you start falling

* When your character hits his head on a charmap, you start falling. If the character he hits is an unpainted block, it gets painted

* When you are falling, none of your controls (left, right, or flying) will work until you land again.

 

The reason for having this, is that I have the ultimate goals in mind for my game:

 

* Falls are never fatal unless you land on a dangerous object or fall off the bottom of the screen

* Therefore, flying into a block from below is always fatal when there is no safe landing spot below you (because none of your controls will work again until after you land safely)

 

First of all, I noticed that I have duplicated the character checking routine twice, is there any way to streamline this?

 

Secondly: I want my guy to hover at the top of the screen when he reaches the top, instead of flying off the top. How can I do this? (i.e. What is the value of heroy when he's on the top char line?)

 

Next: Sometimes when I fly onto a platform, he looks like he's buried in the platform, when I want him to stand atop it. This happens if I fly onto a platform at an angle and release too soon. Is there a way to automatically correct the heroy value to align correctly with the screenmap when he's not flying?

 

Similarly, I also want my herox variable to align correctly with the screenmap when he is falling. That is, when he starts falling, regardless of his x position, I want herox to align exactly with the location of the next x charmap coordinate coordinate ... this helps make it easier to fly onto platforms. This is of course entirely dependent on which direction he is facing when he starts falling.

 

This is excellent, it's like I can feel my old Atari 8-bit game coming back to life!

 

I've attached the modified bas file and resultant binaries below.

 

 

ramcharmap2.zip

Share this post


Link to post
Share on other sites

Nice to see hands getting dirty. :)

First of all, I noticed that I have duplicated the character checking routine twice, is there any way to streamline this?


No, but I planned ahead for peekchar/pokechar to be accessed a bunch of times, so they're pretty efficient. The first instance of peekchar/pokechar for any given map builds a small look-up table in ROM with a small bit of assembly to use the table. Any other instances of peekchar/pokechar just adds the assembly code.

Secondly: I want my guy to hover at the top of the screen when he reaches the top, instead of flying off the top. How can I do this? (i.e. What is the value of heroy when he's on the top char line?)


In your case, heroy will be 8. For a simple sprite it would be zero, but in my demo we have 2 sprites joined together, and heroy positions his bottom half.

Next: Sometimes when I fly onto a platform, he looks like he's buried in the platform, when I want him to stand atop it. This happens if I fly onto a platform at an angle and release too soon. Is there a way to automatically correct the heroy value to align correctly with the screenmap when he's not flying?


Sure. Adjust heroy so it rounds down to the nearest multiple of 8. The easy+quick way to do that is to use a binary AND and mask off the bits responsible for values 0-7...

heroy = heroy & %11111000

Similarly, I also want my herox variable to align correctly with the screenmap when he is falling. That is, when he starts falling, regardless of his x position, I want herox to align exactly with the location of the next x charmap coordinate coordinate ... this helps make it easier to fly onto platforms. This is of course entirely dependent on which direction he is facing when he starts falling.


Our previous heroy solution puts him on top. The equivalent solution for herox would put him to the left of each character, so we need to modify that a bit to push him into the middle...

herox = (herox & %11111000) + 4

Edited by RevEng
  • Like 1

Share this post


Link to post
Share on other sites

One other question, sorry ... :)

 

I understand 160B allows 12 colors per character or sprite. If I were to use this mode, what would be the correct way to set up the color registers, to read a PNG downsized to 12 colors?

Share this post


Link to post
Share on other sites

The 12 colors use 4 of MARIA's palette sets. Assuming one of your images is called "myhero.png", you could set up the palettes as...

 

P0C1=myhero_color1

P0C2=myhero_color2

P0C3=myhero_color3

P1C1=myhero_color4

P1C2=myhero_color5

P1C3=myhero_color6

P2C1=myhero_color7

P2C2=myhero_color8

P2C3=myhero_color9

P3C1=myhero_color10

P3C2=myhero_color11

P3C3=myhero_color12

Share this post


Link to post
Share on other sites

One of the benefits of this system is that it can use a whole lot of sprites at once. Does 7800Basic take advantage of them? I have some ideas rolling around in my head and I'm not sure if I want to take them to the Intellivision or the Atari 7800. I prefer the Inty as a system, but the 7800 would probably be better suited to the kind of lightning fast shooting action I have in mind. It's got all those sprites and graphics more in line with my all-time favorite console, the NES.

Share this post


Link to post
Share on other sites

The current limitation is 20 objects - sprites or lines of characters - per zone. This is mainly due to memory constraints.

 

If the objects don't all bunch up in one zone, you could likely draw more. The main challenge with pushing a large number of sprites would be having enough time to plot them and manage AI and/or collision detection for each one in the limited time we're given per frame.

Share this post


Link to post
Share on other sites

Sprites can be up to 32 bytes wide. In the most common 160A mode, that translates to 128 pixels wide.

 

The height is actually capped at the zone height, so 8 or 16 pixels high. But you can stack them to make a taller sprite.

Share this post


Link to post
Share on other sites

The current limitation is 20 objects - sprites or lines of characters - per zone. This is mainly due to memory constraints.

 

If the objects don't all bunch up in one zone, you could likely draw more. The main challenge with pushing a large number of sprites would be having enough time to plot them and manage AI and/or collision detection for each one in the limited time we're given per frame.

 

I benchmarked this a bit more, since it's important for us to know what constraints we're up against when developing games with lots of sprites.

 

I was able to get 24 sprites displayed against a character background. The logic in this benchmark is pretty simple, so I'd take 24 as an upper bound and design your games a bit more conservatively.

 

pro-tip: Whenever a plot* command is issued, 7800basic waits until the visible screen has finished being drawn, to avoid display glitches. So to get the maximum number of sprites on the screen, you should write your program so the game logic happens first, and any plot* commands happen closer to the drawscreen command. This allows your game logic to run while the screen is being drawn, as much as possible anyway.

 

I'll include this with the samples the next time an update is released, but until then, here's the benchmark...

 

multisprite.bas.a78

multisprite.bas.bin

multisprite.zip

Edited by RevEng
  • Like 6

Share this post


Link to post
Share on other sites

That is one thing that always amazed me about 7800 ...

 

20+ sprites onscreen and no flicker at all. Let's see NES do that. :)

 

Another question I had, is about music playing in the background while the game goes. I think I have an idea how to do it ... a lookup table for the music data, plus a call to the music routine to play the current note of the music, this happens once each loop.

 

So, some future ideas for additions: Commands for POKEY music ... and it would be cool if we had a means of importing RMT files (raster Music Tracker) into the program.

Share this post


Link to post
Share on other sites
Another question I had, is about music playing in the background while the game goes. I think I have an idea how to do it ... a lookup table for the music data, plus a call to the music routine to play the current note of the music, this happens once each loop.

 

Unless 7800BASIC has totally changed from normal batari Basic for the Atari 2600, I was hoping we could still use the Music and Sound Editor to make TIA music and sound effects similar to this kind of thing:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#sound_example_no_bank

  • Like 2

Share this post


Link to post
Share on other sites

Or, how about expanding this editor to include POKEY support, in both 8-bit and 16-bit mode.

 

There are 4 usable waveforms for POKEY to make music. I did a note table here which basically covers about 10 octaves, maybe this might be of some help:

 

http://atariage.com/forums/topic/216807-complete-pokey-note-table-for-all-distortion-settings/

Share this post


Link to post
Share on other sites

Another question I had, is about music playing in the background while the game goes. I think I have an idea how to do it ... a lookup table for the music data, plus a call to the music routine to play the current note of the music, this happens once each loop.

Yep, that will work. Your main loop will have a drawscreen call in it, which will synchronize the loop with the frame rate.

 

Depending on how much note data you throw at it, you'll either need to break up the data into multiple data statements, or use sdata.

 

The vbb music program RT references should work too, since none of the 7800basic data access commands needed to be changed from the original bB code.

 

Jeff Wierer maintains that tools. I don't know if he has plans for Pokey. (or greater plans for 7800basic)

 

 

So, some future ideas for additions: Commands for POKEY music ... and it would be cool if we had a means of importing RMT files (raster Music Tracker) into the program.

I'm not opposed to doing something like that. It might even be a good use for DMA holes between graphic areas.

 

I'll look at the possibility eventually, but my TODO list is still pretty big so it will likely be a bit down the road.

Edited by RevEng
  • Like 1

Share this post


Link to post
Share on other sites

great to see another basic compiler for Atari.

I was planning on doing another laserman game for the 7800 as soon as I get some of bugs worked out on the 2600 and improve it.

only bad thing I don't have a working 7800 so might have to use an emulator for it.

how are people testing the games here? Emu or actual 7800.

Share this post


Link to post
Share on other sites

great to see another basic compiler for Atari.

I was planning on doing another laserman game for the 7800 as soon as I get some of bugs worked out on the 2600 and improve it.

only bad thing I don't have a working 7800 so might have to use an emulator for it.

how are people testing the games here? Emu or actual 7800.

I'm using both both hopefully soon I will just be using an actual 7800 only.

 

http://atariage.com/forums/topic/223330-revealed-mystery-hardware-any-guesses/

 

Allan

Share this post


Link to post
Share on other sites

RevEng,

 

Is there way to have the .a78 file output to a different folder than the rest or is that hard-coded into 7800basic? Maybe this is more of a Dasm thing but I'm not sure.

 

Allan

Share this post


Link to post
Share on other sites

beta 0.1 20140320 is now in the first post, replacing the older version.

 

This one has initial pokey support. It will autodetect pokey in the standard cart memory location, and it should do the same for XBoard and XM hardware. (I'm unable to confirm)

 

There's a "pokey.bas" program in the samples that plays "daisy do". It's not meant to be a stellar example of a music engine, nor is it a particularly exciting tune. Its just a quick and dirty demo.

 

Here's the change log...

  • added pokey detection code, and "set pokeysupport on" command.
  • added psound command.
  • fixed bug that didn't allow alternate mode (160B, 320C, 320D) character support.
  • modified the DL interrupts. previously 1x non-visible scanline was counted as visible.
  • removed "wait for screen end" code from clearscreen, as it isn't strictly needed.
Special thanks to Synthpopalooza, who's pokey waveform descriptions were a starting point for the descriptions in the psound part of the docs.

 

For those that don't want to download the whole thing, but are very, very bored and curious about the new sample...

 

pokey.bas.bin

pokey.bas.a78

  • Like 4

Share this post


Link to post
Share on other sites

Is there way to have the .a78 file output to a different folder than the rest or is that hard-coded into 7800basic? Maybe this is more of a Dasm thing but I'm not sure.

 

Allan

Sure. The default is to make the .a78 in the current working directory, but all the pieces of 7800basic are tied together by the 7800basic.sh shell script (OS X, Linux) or by the 7800bas.bat batch file. (Windows)

 

So you can just add a line to the end of the script that copies or moves the file where you want.

 

Since I know you're an OS X guy, here's the line to add to 7800basic.sh, right before the last "exit 0" line...

 

cp "$1.a78" /path/where/I/want/the/a78
  • Like 1

Share this post


Link to post
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...