7800basic beta, the release thread

[CPUWIZ]

 

Pardon me if this sounds like a weird question, but when you say this, does that mean that, when you're working with ROMs that bankswitch, there's always two graphics blocks available -- the bank you're currently on, and the "last bank"?

 

Precisely.

[+frankodragon]

It is possible to have graphics in banks for graphics as long as you have the incgraphic and the plotsprite command in the same bank. A suggestion is using bank 1 to store and call up the title graphics. However, for banks that have a lot of code, like what I'm working on, it can eat up a lot of space (16k each), so it's a good idea to have most of your incgraphics in the last bank. I like to think the last bank as a "vault" to store the graphics so any plotsprite command you have in any bank before the last bank can be called up.

[RevEng]

Everybody's answers about banks and graphics are spot on.

 

Your question also involved "graphics blocks", which is distinct from banks. Just to be sure we're on the same page... MARIA expects the graphics to be located in particular locations in ROM, which is the main reason we have these graphics blocks. A 32k or 48k ROM can have multiple graphics blocks in it, despite not having any banks. And a 16k bank in a bankswitched ROM may have 0, 1 or more graphics blocks in it.

 

There can only be one active "graphics block" so far as character/tile graphics go. (the one you called "characterset" on last.) But sprites can be displayed from any one of the graphics blocks, so long as the graphics aren't in a bank that's been switched out. (hence CPUWIZ and frankodragon's replies)

 

Hopefully our responses help, or at least lead to other questions.

[NIKON]

I have a question... does the 7800Basic allow for vertical scrolling? I have a game in mind for the 7800 but it involves vertical scrolling of the characters on a static background. If I am having to use ASM, then can I get away with a scrolling routine for the scroll part and Basic for the rest.

[MAC-42]

does the 7800Basic allow for vertical scrolling?

I believe RevEng has scrolling in mind in a future release down the road. Not available just yet. I'd go ahead and use ASM if you can.

[RevEng]

The lastest 7800basic release, beta 0.3 20150106, is now in the first post.

 

Here's the changelog excerpt...

• fixed memset bug that occurred when exactly 256 bytes were written
• added pokey support to playsfx command
• added "set plotvalueonscreen on" statement
• added NTSC/PAL console detection
• rearranged drawscreen code, so a drawscreen call now exits at the top of the frame
• added splitmodedemo to samples
• updated documentation with pokeydetected and paldetected special variables
• added "set screenheight", which allows vertical resolution choice of 192, 208, and 224.

Here's a copy of the splitmode demo for the curious. it's just a demonstration of a 160A screen with 320A text on top.

 

splitmode.bas.a78

[+Random Terrain]

Looks like I caught all of the new changes and I added more jump links (anchor links), including ones I missed last time.

 

randomterrain.com/7800basic.html

 

If anyone finds any mistakes, please let me know.

[MAC-42]

Thanks again to both of you for your efforts!

[Synthpopalooza]

224 scanlines. Now I gotta check this out.

[Mord]

Going to try to start fiddling with this next month as the capabilities look promising.

 

I figure if I can -almost- get a DL Builder running properly in assembly, I should be able to get something done with this so long as I can get it to work for me. I'll try tinkering with the demos first though - hopefully I'll have lots of questions in the coming months, as that means I'm actually working on something!

 

If things go well, I might need to start looking for a ram cart by the summer.

[RevEng]

Feel free to let loose with those questions, once you're underway.

 

An observation for all... I've noticed an uptick in the 7800basic downloads. So far there have been 120 downloads in the 2 weeks since the last update. I think we may have some secret 7800 projects in the works!

[Mord]

I had some spare time to test the program itself to make sure it's working on my comp, but where my ancient rig doesn't have setx for the installer I have to set the path manually as per the readme.txt ie:

set basic7800dir=c:\7800basic
set PATH=%PATH%;c:\7800basic

Setting those (I do have it unzipped to the same directory) lets me use 7800bas from the sample directories, but compiles fail due to it not being able to open up the various files from the includes directory for reading. (default.inc for instance).

 

I can bypass that in a clunky, messy way by just copying the contents of the includes directory to whatever directory has the .bas program, but as I said that's kinda messy... is there some other instruction that needs to be done that isn't explicitly mentioned in the readme?

[RevEng]

The problem is this...

 

set basic7800dir=c:\7800basic

...should actually be this...

 

set bas7800dir=c:\7800basic

Once you fix that up and launch another CMD window, you should be good.

[Mord]

Once you fix that up and launch another CMD window, you should be good.

 

Yep, that fixed it.

 

Now to spend the rest of the week/month fiddling with the sample programs.

[Mord]

I was doing some tinkering by modifying the samples to see how they respond.

 

One thing I attempted was seeing how imported graphics intended for 160A would react if you tried to force them into 320B. Both have the same pixels/byte and color depth.

 

I was expecting to see the same image, just not stretched out.

 

The only changes I made to the program were to explicitly set the display mode, and to specify what display mode incgraphic should be using.

 

ie:

 rem *** a simple program to move a happy face around with the joystick
 displaymode 320B
 
 set zoneheight 8

 dim playerx=a
 dim playery=b

 incgraphic face1.png 320B

 rem *** set the colors of palette 0, which we'll use to draw the happy face
  P0C1=$82
  P0C2=$48
  P0C3=$fb

main
 clearscreen
 if joy0left  then playerx=playerx-1
 if joy0right then playerx=playerx+1
 if joy0down  then playery=playery+1
 if joy0up    then playery=playery-1
 plotsprite face1 0 playerx playery
 drawscreen
 goto main

Instead, the 320B mode appears to have the top line cut off from the smiley face.

 

 

Is there something I'm missing, or something not working as intended? ^^

[RevEng]

Looks like I accidentally introduced a bug into the 320B import with the last update. Thanks for the report!

 

I've updated the version in the first post, and incorporated the fix.

 

Here are the main updates...

• fixed bug in NTSC/PAL console detection
• added dummy _color# constants for images that don't fully use all colors
• added joy0any and joy1any checks to if...then
• fixed bug in 320B import

[+Random Terrain]

Online version updated:

 

randomterrain.com/7800basic.html

 

If anyone finds any mistakes, please let me know.

[Mord]

I did some more testing with 320B today by converting some of the 160A modes over to it just to see how they'd respond.

 

simple.bas works as expected now - has the full sprite.

 

When I tried adventurer.bas however, the palettes are wrong. After a bit more poking around it seems palette is being ignored entirely and everything ends up using palette 0.

 

All I modified in the original adventurer.bas was to set the displaymode to 320B, and add 320B to all the incgraphic commands. (changing the 160A to 320B as appropriate, and adding 320B to those that weren't explicitly set.)

 

The only time I'd see color changes show up in the program is where I'd alter the settings for palette 0.

[RevEng]

[edit] hang on. still investigating.

[RevEng]

Here's a copy that sort of works. Some of the graphics just needed "320B" specifiers.

 

adventurer.bas

 

I say "sort of works" because 320B is a bit weird. If a single black pixel is next to another color, then it shows up black. If there are 2 black pixels next to each other, they show up as transparent.

 

The 7800 Software Guide has more details on 320B and other 320 modes. They all have a few quirks.

[Mord]

I say "sort of works" because 320B is a bit weird. If a single black pixel is next to another color, then it shows up black. If there are 2 black pixels next to each other, they show up as transparent.

 

 

That would be with the pixel-pair things, where the background color gets displayed instead of not drawn at all... but does that mean the background color eats up the pixel that was suppose to be displayed? I'll keep fiddling with it over the weekend to see what I can learn from it. Expected storm weather should keep me in the house with plenty of time.

[Mord]

Ok, I figured out the whole issue I was having with 320B. I'm going to have to re-read the programmers guide to make sure I brush up on those limitations again. ^^

[Rhomaios]

I didn't want to create a whole new thread, but I'm curious, can something like Amidar be ported to the 7800 using 7800basic, or should that properly be done in assembly?

[RevEng]

I don't see why it couldn't be done in 7800basic. The main limitation with 7800basic compared to assembly right now is scrolling.

 

That said, I don't think it's a project that would be great for someone new to programming in general. Limiting the sprites to the grids and recognizing when a shape has been closed off is a little bit tricky compared to a game that's more free roaming.

[Rhomaios]

I don't see why it couldn't be done in 7800basic. The main limitation with 7800basic compared to assembly right now is scrolling.

 

That said, I don't think it's a project that would be great for someone new to programming in general. Limiting the sprites to the grids and recognizing when a shape has been closed off is a little bit tricky compared to a game that's more free roaming.

 

How much programming knowledge would I need to know for this game? I did Windows (mostly C, some C++) programming for a few years, and I still remember some of the Java class I took way back in college. I've never touched Basic, though.