7800basic beta, the release thread

[+Karl G]

I have an enhancement request. I would love for there to be a way for me to define images in ASCII, in the source file, with each pixel being the appropriate palette color entry number. Among other advantages, I believe this would make it easier to port games from batari basic.

[RevEng]

This was my first idea for 7800basic graphics, actually. As you mention, it's a natural progression from bB. I dismissed the idea because it has strong limitations; outlines are pretty obvious, but you the internal colors quickly become a muddle.

 

Here are some graphics from Salvo, converted to something like the bB format. Bear in mind these are 160A graphics, and some other modes will be more complicated. The work of a really masterful pixel artist would also be more obfuscated...

 

 

Spoiler

 

FILENAME: gfx/player_sprite_d1.png
..111...
2221222.
2.2.2.2.
.21112..
...3....
.33133..
1331331.
1.313.1.
1.3.3.1.
..3.3...
.33.33..
........
........
........
........
........


FILENAME: gfx/player_santa_d1.png
..11111.
.11111.3
.11111..
.22222..
.23232..
.22122..
.333331.
11333111
11131111
11111111
31111113
21111112
.11..11.
.33..33.
111..111
111..111


FILENAME: gfx/gear3.png
..........1.............
.........331............
.........332....1.......
.........333....33......
.........333...233......
.........333321333......
....2...2333333333......
...231.23333333333......
...333233333333333......
...333333333333333......
...3333333333333332.....
...2333333333333333.....
....3333333333333332231.
....3333333333333333332.
...13333333223333333333.
...2333332....233333333.
...333333......33333332.
...333331......1333332..
22333333........333331..
33333332........233331..
3333333..........33331..
3333333..........33332..
3333333..........33332..
1233333..........33332..
..33333..........333331.
..23333..........3333332
..23333..........3333333
..23333..........3333333
..133332........23333333
..133333........33333332
..2333331......13333311.
.13333333......333333...
.333333332....2333332...
.33333333332233333331...
.3333333333333333333....
.2333333333333333333....
..2.13333333333333331...
.....3333333333333332...
.....1333333333333333...
......333333333333333...
......33333333332.332...
......3333333332...3....
.....1333233333.........
.....1332..1333.........
.....133....333.........
.......3....333.........
............233.........
............121.........

 

 

 

 

St.Nick actually has eyes and beard, and fur on his boots and sleeves. The gear has anti-aliasing.

 

I agree this functionality would help to make a quick bB conversion, but it also makes it very hard to grow past the 2600's capabilities into the 7800's capabilities. Not to mention it makes collaboration with graphic artists more difficult, and animation more tedious.

 

If you, or anyone else, is still interested in this kind of ascii graphic import, despite the cons, let me know. I'll add it to the list.

[+Karl G]

I may just be the weird exception that would find this useful; I'm sure most users would probably prefer to work with images. I'd love to have the option of doing it either way myself, depending on my specific needs. Don't put it on the list if I'm the only one who wants it, but I'm curious now if anyone else wishes they could define images this way.

[+mksmith]

I guess for 160b images you would convert the index to hex.  Interestingly my editor in Dev Studio actually stores its info in arrays pretty much this way...  I think the biggest stumbling block initially is saving images to the required format that's why I did Dev Studio before starting a game so I had something to do this for me!

[+SmittyB]

Something I've been thinking about that I'd love as an addition (though it wouldn't be useful to me any time soon) would be the ability to import graphics to areas of ROM outside of the usual graphics banks.

The reason is a couple of the projects I have in mind for the future would benefit from setting CHARBASE to a location in RAM and loading in / modifying tiles on the fly and as part of that the tile data in ROM would just be copied around like any other data freeing up the usual graphics banks for sprites which would benefit from holey DMA unlike tiles.

At the moment I would probably do it by importing graphics into a dummy program and then copying the data from the output assembly file.

[RevEng]

Unfortunately your request isn't as trivial as I'd like, due to the weird one-page-per-line graphics format of the 7800, dasm's insistence on receiving all information in-order, and the dance 7800basic has to do to translate between the two.

 

Similar to your described workaround, for the Serpentine port I exported the original A8 graphics to a png file, and imported assembled graphics via a throwaway 7800basic program. It's not the most elegant solution, but it works.

[+SmittyB]

Ah, I see.

Well there's no harm in a little copying and pasting to achieve the same thing. Thanks.

[Ryan Frazier]

With the Atari 7800 being somewhat more advanced than that 2600 system,  could games be made for it that match the quality in terms of graphics, sound, and game play that of the Nintendo NES such as Super Mario Brothers 2 and 3, Castelvania, or even Fantasy Zone on the Sega Master System?

[+SmittyB]

That depends, the first Super Mario Bros was built with the mindset of it being the very best the Famicom / NES could do, and it does hit a few of the NES's limits doing it. Nearly all of the games people remember fondly use 'mapper' hardware on the cartridge to go beyond what the NES can normally do. Rikki & Vikki is a good example of doing something similar on the 7800 to push it beyond what a stock 7800 is capable of.

 

The 7800 has an entirely different set of strengths and weaknesses though so while it could probably easily pull off something with gameplay like Fantasy Zone, Castlevania, Legend of Zelda or Metroid, it would be tough to get anything like Super Mario Bros 3 or the later Megaman games because of how much they rely on the extra hardware.

 

It's really a case of playing to the 7800's strengths rather than trying to copy something which hits all of its weaknesses.

[RevEng]

Heads-up that the new v0.7 release of 7800basic has been made public, and it's now being distributed at github under the GPLv2 license. See the first post for details.

 

This release brings in the ability to swap out some alternate controllers - for now it's just driving controllers and keypads, in addition to the usual joysticks, but I have plans for other others. I haven't picked up these controllers yet, so I've presently only tested against emulation. If anybody can test them (there are sample programs) then please do!

 

If you've implemented other controllers in your basic code already, the new code should play nice; if you don't try to change controllers with the new "changecontrol" command, 7800basic will default to the same 2-button joystick code used by previous versions.

 

Additionally, banner widths can be as wide as you like now; no need to break them into 32-byte wide chunks.

[+Random Terrain]

Online version updated:

 

randomterrain.com/7800basic.html

 

After unzipping, I renamed the folder from 7800basic to 7800basic_2020y_02m_15d_0714t so I'll be able to tell the difference between versions since I have to compare PDFs.

 

The differences between the latest PDF and the one before it were checked using WinMerge and the page was updated with the latest changes, including the table of contents and index. If you think I missed something or screwed something up, please let me know.

 

Thanks.

[RevEng]

Looks great, RT! ?

[RevEng]

I've updated the spacephysics sample to demonstrate how to import sprite sheets, and also to incorporate sub-pixel movement for the X coordinate. X coordinate motion now happens on a 320 grid, instead of a 160 grid, by using pre-shifted sprite data. The result is that slower movements appear less clunky now.

 

The update is only in github right now, so I've attached a zip of this sample, and the resulting roms.

 

 

spacephysics.bas.a78 spacephysics.bas.bin spacephysics_new.zip

[+mksmith]

Will get this into Atari Dev Studio some time today. Thanks Mike for your ongoing contributions???

[RevEng]

Same back at you.

[+mksmith]

Atari Dev Studio has been updated to use the bB 1.4 and 7800basic 0.7 releases.  

[+SmittyB]

I've just tried compiling SotA with the new release and I think I've found an issue with dmaholes compare to the 20190613 release I've been using.

 

It's giving me a label mismatch for dmahole_0_0 and poking around at the assembly I can see that it's jumping over dmaholes by labelling the hole with 'dmahole_bank#_hole#' and then reversing it for the label to jump to. The problem is where this is now creating a label for the start of the hole with the label 'dmahole_hole#_bank#', obviously this will always fail for bank 0 hole 0, but if I then set bank 0 to use hole 1 that then conflicts with the labels for hole 0 in bank 1 and I'd presume with other combinations of bank and dmahole.

[RevEng]

Can you send me the generated list file, in a PM? I don't think this is a general problem with dmahole, because I've been testing with code that uses dmahole extensively. But maybe it's a combination of features issue, or perhaps it's limited to the 144k rom format.

[RevEng]

Ok, SmittyB and I worked it out. It seems there was a bug introduced between bankswitching and dmahole.

 

I've resolved the bug, and I've created a new pre-release version at github. If anybody encounters other problems, let me know. If a week or so passes in silence, I'll promote the pre-release to a full release.

[+Karl G]

More enhancement requests (none of them urgent):

• It would be handy if incgraphic could do a simple rotation or flip on an image, so the same source file could be used for multiple sprites (easier to maintain changes in the source)
• I would like to have a way to tell the sound driver to "reset" and stop playing whatever sounds it is playing
• It would also be handy to be able to query to see if if the sound driver is in the midst of playing a particular sound. This would be handy to avoid playing multiple copies of a continuous sound, like a thrust sound when the joystick is moved

 

[Mord]

With regards to the first point, it would probably be best done by allowing the programmer to specify the sprite name for the extra copies (or any sprite image) instead of taking the name of the filename directly - if the name/alias isn't specified by the programmer then have it take the filename as it does now.

 

Not sure if it would be easier/better to try to add to the current incgraphic command or create a separate command for it.

 

Another useful function this would allow is to load up multiple copies of the same image but rearranging the sprite colors.

[RevEng]

1 hour ago, Karl G said:

More enhancement requests (none of them urgent):

• It would be handy if incgraphic could do a simple rotation or flip on an image, so the same source file could be used for multiple sprites (easier to maintain changes in the source)
• I would like to have a way to tell the sound driver to "reset" and stop playing whatever sounds it is playing
• It would also be handy to be able to query to see if if the sound driver is in the midst of playing a particular sound. This would be handy to avoid playing multiple copies of a continuous sound, like a thrust sound when the joystick is moved

• The flip or rotation could be done. incgraphic is a bit overloaded in terms of arguments, so I'd need to sit down and figure out the UI, but I think this is a great suggestion. Rotation would only be allowed if the image height=width, I think.
• Try the "mutesfx" command. Looks like I have another doc update to do.
• Yeah, the technical challenge here is we don't know which audio channel the sound is playing on, and the pointer has likely changed since the "playsfx" command (it advances as each chunk of the sound is played) so we can't even use that to check. As a work-around, you can count on the sound taking the expected number of frames to play, and just play it again at the end - I updated the spacephysics demo that I previously posted with a continuous thrust sound using that technique.

Thanks for the input, Karl!

[+Karl G]

Maybe something like "clonegraphic <oldname>  <newname> <operation1> ..."?

[RevEng]

Seems like a definite maybe. I think that would have to be followed by the typical incgraphic arguments too, so (as Mord suggested) you could shuffle indexes around, or assign the tile to another default palette.

 

At the moment I have my hands extra-full with the XM and alternate controller updates, but I'll look at this after that dust has settled.

[RALPH!]

IF-Blocks would be very helpful.  IF [THEN], ELSE, ELSEIF, ENDIF included with Basic, Pascal, C, and other programming language made from 30 year ago. It greatly simplifies programming complex game logic. Programming 7800 Basic is similar to programming in Atari or Commodore computer basic.