7800basic beta, the release thread

[RevEng]

beta 0.1 20140331 is now in the first post, replacing the old version.

 

plotchars can now work directly with text strings, and the install_win.bat file should work with PATHs with spaces. There's a simple text "helloworld" program added to the samples.

 

Here's the change log...

• modified plotchars to directly work with strings of text, instead of forcing the user to define alphadata.
• added "ASCII" and "default" options to the alphachars command.
• fixed bug in preprocessor, where alphachars processing didn't end.
• added "set debug color" command, to assist with seeing how much of the visible screen time has been used.
• updated the Guide with information on above enhancements.
• updated the Guide with tip for fine-tuning color constants.

I'll try to dial in the png color conversion a bit more accurately for the next release.

[gambler172]

Hi RevEng

great work......especially the HELLO WORLD

greetings Walter

[donnerkuh]

Thank you for this great programming tool.

 

I tried out the simple.bas. Now i have a question about the DIM-command. in simple.bas you do the following:

 

dim playerx=a
dim playery=b

 

than, you use it:

 

if joy0left then playerx=playerx-1

 

I tried to change playerx into the variable "a" , playery in "b" and tried to remove the dim-commands. I´ve got a fatal assembly-error. My question: If i use a-z variables, will i have to use the DIM-command? If I have to, how?

[RevEng]

If you use only a-z and var0-var99 variables, you don't have to use the dim command. I don't know what happened during your test... perhaps there was a leftover reference to playerx or playery you missed.

[donnerkuh]

you are right . I´ve overseen the plotsprite command. OK, i will start to find the next 500 questions, but at least i will create a game, i swear

[Shannon]

Sort of. There's a short entry in the docs on setting the pokey registers with assembly. This is a bit different than the usual way of setting the registers, as 7800basic uses indirect addressing because the pokey location can vary.

 

Eventually I'll get dsound implemented and wrap up some of the trickier stuff in a bow, but for now you can do it the assembly way. (and optionally still use psound to change the 16-bit frequencies one at a time)

 

Thanks for the reference links!

Since there is auto pokey detection code and the pokey location can vary. How about some form of "variable" that references the pokey location so maybe people can use that variable as a reference when wanting to set the AUDCTL register?

[RevEng]

I'll chew on it a bit. I may add it as special poke/peek commands, so it can be a general solution that can be applied in the other infrequent times that indirect addressing is needed from basic.

 

Something like "ipoke pokeybase PAUDCTL 13".

[+Random Terrain]

. . . ipoke . . .

 

I poke, therefore I am.

 

Oh, I would poke anything for love. I would poke anything for love, but I won't poke that. No, I won't poke that.

 

I am the eye in the sky, poking at you, I can poke your mind. I am the maker of rules, dealing with fools, I can poke you blind. And I don't need to see any more to know that I can poke your mind (poking at you). I can poke your mind (poking at you) . . .

 

[PacManPlus]

[Jess Ragan]

Thanks to Synthapalooza for the tips. I've got one of my graphics converted, and the colors are fairly close... a little washed out, but good enough. My only problem is that when I import the palette, it just arranges the colors in a seemingly random way, rather than setting them in a more logical order. I wish I could fix this; so far, I've not been able to do that.

 

I'll mess around with this a little more later. The current goal is getting the graphic I've designed to appear onscreen in a 7800 emulator; after that, we'll see what happens.

[RevEng]

Good to hear you're getting on.

 

The 7800 color index order should match the PNG index order, and the palette entries should match that order as well. The initial order is in the graphical program's hands, but if you want to override the index order, you can do so with optional parameters to incgraphic.

[Jess Ragan]

Okay, this is some crap. The compiler will process sample.bas, but not the program I'd written. It crashes after the REM statement, claiming "ERROR, Unknown Keyword ***." Sure, whatever you say, pal. I know how to write a cotton pickin' REM statement! I used the exact same format as in the sample program! Ugh.

[RevEng]

It would help if you posted the .bas.

[Jess Ragan]

Wait, you have to put a space before every statement? Seriously? Ugh.

 

Okay, next problem. The bit depth doesn't match the requested display mode, which is weird because no display mode is mentioned in the sample program and I went through all the business of changing the bit depth of the graphic in the GIMP. So I'm still annoyed, just less so than before I figured out I needed a space before each statement.

[Jess Ragan]

All right, let me dink with this for a while before I post it.

[Synthpopalooza]

Post up the .bas and I can have a look, I had similar issues when writing mine. One thing to look for, is when you issue the incgraphic, make sure the mode you select matches the graphics file ... for instance, if your picture is 13 colors (12+BG), you want to make sure the picture's mode is set to 160B in the incgraphic command. Also make sure you are exporting as .png and not .jpg ... this may seem fairly basic, but JPG can introduce artifacts that will throw off your result.

[RevEng]

Wait, you have to put a space before every statement? Seriously? Ugh.

Just like bB. To be fair, this is covered in the guide.

 

The benefit is you get to use labels for goto/gosub destinations like a modern language, instead of having to enter old fashioned line numbers for every single line.

[CPUWIZ]

That could easily be solved by parsing a colon.

 

R.T. is gonna have fun with that.

[Jess Ragan]

Okay, here's the program and associated file.

 

Jumping back into GIMP and re-indexing the graphic finally made it compatible with the compiler (I'm absolutely sure I already did this once!). However, when I ran the program, I just got a black screen. I hoped to have a single sprite appear near the center of the screen, followed by an infinite loop that would freeze the program in place. There's probably two or three things I did wrong, which tends to happen when I'm learning a new BASIC dialect.

 

(A command list would really be nice... I find it really comes in handy for other flavors of BASIC)

 

(My apologies for getting cranky earlier; programming tends to be fun and frustrating for me in equal measure)

byron.bas

[+Random Terrain]

If you don't have drawscreen in your main loop, you'll get a blank screen.

[RevEng]

You need to set those palette colors first, or your bear won't show up.

 

e.g.

 

P0C1=bear_color1

P0C2=bear_color2

P0C3=bear_color3

[Jess Ragan]

That's a must even though the colors are already defined in the graphic itself? Hmm.

 

Would that code snippet work in my program, or am I going to have to enter hex codes in place of "bear_color1," etc.? How would I know which colors to select? Is it just a trial and error thing or are the colors defined in a specific order?

[RevEng]

That could easily be solved by parsing a colon.

The colon is already reserved as a special separator, but I honestly don't think whitespace is a problem to be solved here.

 

There are plenty of languages that use whitespace in a similar fashion, including 6502 assembly. It's just one of those syntactical differences you need to learn before coding in any new language.

 

Additional whitespace isn't required, but using it sure does help visually organize your code. Consider the requirement of a single whitespace a step down that road to good habits.

Edited April 6, 2014 by RevEng

[RevEng]

Would that code snippet work in my program, or am I going to have to enter hex codes in place of "bear_color1," etc.? How would I know which colors to select? Is it just a trial and error thing or are the colors defined in a specific order?

You could use hex codes if you prefer, but what I wrote will work in your program as-is. Just be sure to add in the leading whitespace the forum ate.

 

The numbers are in sequence, and match the indexes in your picture.

 

Yes, setting your palettes is a must. You can import hundreds of pictures, but the 7800 only has 8 palette sets. Its up to you to manage them.

 

From the Guide...

 

When importing a graphic, incgraphic also creates color constants that you can use to set the palette entries for the sprite. Here's an example for setting palette 0 for the graphic foobar3.png.

 

P0C1 = foobar3_color1

P0C2 = foobar3_color2

P0C3 = foobar3_color3

 

Since 7800basic only learns of these values during the incgraphic command, you may only use these constants in your source code lines after the incgraphic command for the sprite you wish to set the color for.

 

If you wish to fine-tune the color that 7800basic has provided, you may add or subtract a constant value from it.

 

P0C2 = foobar3_color2 + $10

Edited April 6, 2014 by RevEng

[Jess Ragan]

Booyah! Success.

 

Still not sure how to make that blue part transparent, and the white seems a little... drab. I'll have to experiment to see if I can fix it. Still, this is a really good start. I do appreciate the help!

 

Also, don't mind the bear. He's been a mascot of mine for the last twenty years; I've grown rather attached to him.