7800basic beta, the release thread

[RevEng]

[...]I was trying to increase it slowly, but I noticed it was going up faster than desired in my debug code. After doublechecking the variables weren't referenced elsewhere, and weren't sharing the same ram with other variables, I checked the assembly code which confirms it's loading a larger value for addition. For instance, with the MaximumXS, it was adding 5 instead of 2. For the Ys it was adding 10 instead of 4.[...]

That's actually how it's supposed to work. Fixed Point numbers aren't represented as their BCD equivalents. Instead, a value of X in the fraction byte refers to X/256. It's nicer to implement this way with plain old 16-bit math, and is less wasteful of precision.

[Mord]

That's actually how it's supposed to work. Fixed Point numbers aren't represented as their BCD equivalents. Instead, a value of X in the fraction byte refers to X/256. It's nicer to implement this way with plain old 16-bit math, and is less wasteful of precision.

 

Yeah but if I'm adding 0.02, I'm expecting it to increment the fractional portion by $02 (I'm assuming this would be 2/256), not $05... so.. where is the 5 coming from in the generated assembly code?

[RevEng]

0.02 = 2/100 = 5/256 (approximately)

 

Your values are decimal numbers, but 7800basic converts them to a fraction of 256, scaling the numerator with the denominator. Otherwise adding 0.5 to a position would give a very different result than the expected half speed.

[Mord]

Oh, ok now it's clicking. So 0.2 would be adding 20% of 256. Obviously the first time I've made use of literal values in fixed point math in 7800basic.

[+frankodragon]

When displaying score0 or score1 as three digits instead of six, are the digits used as: ones, tens and hundreds -- or thousands, ten thousands and hundred thousands?

[RevEng]

It goes in memory order, so in the case of score digits it's from most significant to least significant. One side note - if you display an odd number of digits, the first nibble of the first byte is skipped.

 

If you want to display the hundreds, tens, and ones instead, just use DIM to reference the later bytes...

 

dim low1=score1+1

 

...and then use plotchars with "low1" instead of "score1"

[+frankodragon]

This might be a bit off topic, but could a game, like those with the machine language source code released, be able to be converted into 7800 basic?

[RevEng]

Unfortunately not, not automatically anyway. Assembly code can have structures that don't have a exact corresponding representation in BASIC. You can hand-write BASIC code that achieves the same end, but it won't generate the same assembly code you started with.

 

Even if you hand-translated all of the original assembly code, since the original assembly game has strict requirements for space, location, layout, cpu flag states, etc., it would be very labor intensive. It would be easier instead to write the game mostly from scratch, borrowing the art and translating only a few logic routines where necessary.

[+frankodragon]

With the TIA "playsfx" command, is it only for short sound effects or could it be used for longer tunes? Also what dimensional variable addresses should someone avoid when diving into the TIA?

[RevEng]

With the TIA "playsfx" command, is it only for short sound effects or could it be used for longer tunes?

Playsfx is mostly for short sound effects. It can play very simple short music - like the cavalry charge in the "soundtest" sample. It's also used for the Wizard of Wor music in Dungeon Stalker.

 

 

WAlso what dimensional variable addresses should someone avoid when diving into the TIA?

I'm not sure I've parsed your question 100%, but... the only RAM locations you should directly assign with DIM are locations $2200 through $27FF. Anything else is reserved.

[+frankodragon]

 

I'm not sure I've parsed your question 100%, but... the only RAM locations you should directly assign with DIM are locations $2200 through $27FF. Anything else is reserved.

I mean for just sound effects, music, etc. Are there DIM addresses using locations $2200 through $27FF reserved for the sound?

[RevEng]

Memory locations $2200 through $27FF are completely available to 7800basic programs. Guaranteed not to conflict.

[Mord]

Trying to figure out how bankswitching works with 7800Basic (ie: how to organize the code in the source file). In particular looking at the 128k model, which should give 8 banks of 16k.

 

First thing I've done was set up a very basic shell that basically followed the format of:

 

cartridge info (Set romsize, etc)

constant declarations

variable declarations

 

incgraphics

code

bank 2

incgraphics

code

bank 3

incgraphics

 

bank 4

bank 5

bank 6

bank7

 

Then went with the final one:

 

bank 8

incgraphics

 

 

did a compile and it worked, but I noticed it said Bank 8 had 0 bytes free in the main area, then repeated something about dmahole 0 of bank 0 had 4k.

 

If I try to add any code or commands at all to bank 8, the compile fails due to it having negative bytes.

 

Do we have any samples/examples/etc showing how to properly compile a 128kb rom?

 

If not, can we get one?

[RevEng]

Atarius Maximus posted the Adventure demo which was 256K. 256K is identical to 128K, except that it has more banks.

 

It sounds like you've filled bank 8 completely with images. Its not a problem, but if you want to stick code in bank 8, it will need to go in the DMA holes between the images.

 

 bank 8
 incgraphic foo.png
 incgraphic bar.png 
 rem any more incgraphic commands
 dmahole 0
 rem your code here
 if joy0up then gosub eatbananas : rem for example

[MobiusAqua]

It sounds like you've filled bank 8 completely with images. Its not a problem, but if you want to stick code in bank 8, it will need to go in the DMA holes between the images.

 

Do you need a few bytes of space available in bank 8, even to just add the dmahole 0 command? I'm curious, because last time I tried adding code into the DMA hole in bank 8 of BB (or even just dmahole 0 by itself), it refused to compile the entire ROM, just like what happened to Mord.

[RevEng]

That's a good point. I hadn't considered there are a few bytes required for the code to jump over the graphics area.

 

I'll look into a solution for a fully stuffed bank. Stay tuned.

[+frankodragon]

I wrote a blog about conquering bankswitching and I wrote an example here.

[Mord]

Atarius Maximus posted the Adventure demo which was 256K. 256K is identical to 128K, except that it has more banks.

 

It sounds like you've filled bank 8 completely with images. Its not a problem, but if you want to stick code in bank 8, it will need to go in the DMA holes between the images.

 

 bank 8
 incgraphic foo.png
 incgraphic bar.png 
 rem any more incgraphic commands
 dmahole 0
 rem your code here
 if joy0up then gosub eatbananas : rem for example

 

Ok so I'm trying to figure out exactly what the issue is and it's basically the case of adding too many sprites (actually was trying to deliberately separate sprites into both C000 and E000 with newblock) + the dmahole issue above.

 

Where I had sprites added such that it would go to 2 graphics banks (C000 and E000) it would eat all that space up but not have any bytes left over to do the dmahole 0 to allow access to the dmahole at D000.

 

So unless I want to avoid using C000 for extra "global" graphics, I should wait for a fix on the dmahole issue or give up on the 4k trapped inside. ^_^

 

I think I'll wait on the fix.

 

I should be able to work on some of the conversion for graze suit alpha in the meantime though.

[RevEng]

I updated the 7800basic zip at the wiki. For the dmahole command in your stuffed bank, you'll need to use the "noflow" keyword. i.e. "dmahole 0 noflow"

 

This disables the assembly code that allows your BASIC code to flow over the graphics and into the dmahole. (which won't be required here, if you're using "goto" or "gosub" to reach the code in the hole.)

[+Random Terrain]

For the dmahole command in your stuffed bank, you'll need to use the "noflow" keyword. i.e. "dmahole 0 noflow"

Added:

 

randomterrain.com/7800basic.html#dmahole_noflow

[Mord]

*delete*

 

I need new glasses.

 

(However I still suspect an issue here, I just don't know what it is yet.)

Edited February 13, 2016 by Mord

[Mord]

Ok, finally got around to trying to at least make it compile properly and here's an issue that pops up.

 

 

Keep an eye on Bank 4's info below. Here's the space remaining data for it when I have code in there, a couple graphics to force the creation of the graphics charset at A000. Lots of free space it says! All it contains in here is the midwave loop. (Which I really want to redo anyway...)

 

 

 

Now I add "dmahole 0" at the end of the code. I don't have anything put after it.

 

 

As a final test, I add a line of code after the dmahole (a = a + 1) and get:

 

 

In all 3 cases the rom appears to be successfully compiling - I am getting a 128kb rom, and it's writing the signature as shown in the screenshots. I can't verify it works properly however since all the routines are all over the place still - I tossed a lot of things into other banks trying to get that negative rom space down until I realized it wasn't an issue of overrunning the bank with code.

 

Note that the dmahole 0 noflow is working just fine in bank 8.

 

Also, I tried doing a dmahole 0 noflow but the noflow keyword didn't change the results from above.

[RevEng]

When you get a sec, would you mind PM'ing me the source?

 

It looks limited to the free space report at this point, but I'll let you know for sure when I've tracked it down and fixed it.

[Mord]

Sent.

[+xucaen]

Does 7800 basic compile into assembler or into a binary?