7800basic beta, the release thread

[+Random Terrain]

The differences between the latest PDF and the one before it were checked using WinMerge, then I updated the High Score Support section, added the Music Tracker section and the Feature Modules section. The table of contents and index were also updated. If you think I missed something or screwed something up, please let me know.

 

Thanks.

[+frankodragon]

Could paddle code be implemented into 7800Basic?

[RevEng]

Could paddle code be implemented into 7800Basic?

Eventually, but not soon.

 

The most straightforward implementation would resemble a 2600 kernel, and waste a ton of cycles during the visible screen. I'd like to avoid that, as then I'd just get requests for paddle support that works with more than a handful of sprites.

 

I have some ideas on how to improve that, but it would need an overhaul of how interrupts are handled.

[briwayjones]

I've dabbled with programming in various flavors of basic over the years but wouldn't call myself a programmer. So please bear with me.

 

I'm not understanding why there is all of the different color phasing color palettes for the 7800 as opposed to just one color palette like there is for the 2600 for example. And also I don't understand how to implement using all of these palettes.

[RevEng]

The 2600 has different hardware color registers for the various objects it can display. These color registers are more or less a sort of dedicated palette.

 

The 7800 doesn't have a fixed number of objects it can display, so it wouldn't make sense to dedicate color registers to any one object. Instead there are groups of color registers (palettes) that you get to pick from when you tell Maria to draw any given object. The bonus here is, your yellow-and-green wood-elf sprite can become an ice-elf sprite just by picking another palette, and they can walk around on the same screen.

 

The alternative to using palettes would be for the 7800 to have a single 16-color palette and exclusively use 16-color graphics. This would be expensive in terms of ROM space and Maria cycles, so the games would have to be a lot simpler.

[briwayjones]

What I mean is on the color picker charts. There is a 25.7, 26.7 and others. With very little difference between them. What is the purpose of that? Do you just pick one to use?

[RevEng]

What I mean is on the color picker charts. There is a 25.7, 26.7 and others. With very little difference between them. What is the purpose of that? Do you just pick one to use?

There's not a purpose - those charts represent a bug rather than a feature - the color phase change due to drift in the colorburst generation circuit. See the dev wiki for more info.

 

You don't pick any one of those, per se. You just have to be aware that as a console warms up, the colors closer to 255/$FF will tend to drift in quality. So if you need, for example, a yellow that won't change color, it's better to use $18 instead of $F8.

[briwayjones]

There's not a purpose - those charts represent a bug rather than a feature - the color phase change due to drift in the colorburst generation circuit. See the dev wiki for more info.

 

You don't pick any one of those, per se. You just have to be aware that as a console warms up, the colors closer to 255/$FF will tend to drift in quality. So if you need, for example, a yellow that won't change color, it's better to use $18 instead of $F8.

 

 

Ah, okay, that makes more sense now. With all of those phase shifted color charts being thrown around my head was starting to spin. Thanks Rev.

[briwayjones]

This may be a dumb question, and knowing me I'm missing something completely obvious, but is the 7800 x/y screen axis opposite of the normal y being vertical and x being horizontal? I have a problem where when moving my character the y variables are moving the character horizontally. I have the y variables setup on the joy0down command, but when I press down in the emulator it moves it horizontal. I've tried two different emulators and they are button mapped correctly.

[RevEng]

x is horizontal, y is vertical, same as everywhere. Check out the included adventure demo for an example.

 

Maybe you don't have the plotsprite arguments right?

[briwayjones]

Check out the included adventure demo for an example.

 

Maybe you don't have the plotsprite arguments right?

 

Yup, been using the adventurer example. It definitely helps. As far as I can tell the plotsprite is correct. If I switch the p0y to p0x then it moves down like it's supposed to. Of course that's the y axis not the x. This is what I have.

 set tv ntsc

 dim p0y=a
 dim p0x=b
 
 p0y=40
 p0x=40

 incgraphic gfx/ostrich_down.png
 incgraphic gfx/ostrich_up.png
 incgraphic gfx/ostrich_left.png
 incgraphic gfx/ostrich_right.png

 P0C1=$03
 P0C2=$f3
 P0C3=$f8

 BACKGRND=$00

 plotsprite ostrich_right 0 40 40

gameloop

 if joy0down then p0y=p0y+1:goto doneostrichmove

 goto gameloop

doneostrichmove
 clearscreen
 plotsprite ostrich_right 0 p0y p0x

 restorescreen

 goto gameloop

Edited January 12, 2017 by briwayjones

[RevEng]

Your plotsprite command has the x and y variables swapped.

[briwayjones]

Your plotsprite commany has the x and y variables swapped.

Oh wow, thanks Rev. I didn't look at it close enough, obviously.

[digress]

Not working for me so far. The install fails. So I manually set the path. the 7800basic.exe then runs but seems to hang. it started to make the .asm & .cfg for simple.bas but never finishes.

 

windows 7. any ideas.

[+frankodragon]

Where are you installing the 7800Basic program? I have the files in a folder on the Local Disk C: drive (i.e. C: 7800Basic) the same area where the Windows folder is located. Also are you installing as administrator?

[RevEng]

Make sure you're running 7800bas.bat instead of 7800basic.exe, per the manual. The exe isn't designed to be called directly.

[digress]

ok got a little further: Now not quite there yet. I was running 7800basic.exe directly now using the bat file.

 

I got it to compile once now dumping the entire includes directory into the project folder. So I'll have another look at my path.

 

[Mord]

I was working with some large graphics in a test program and found I couldn't fit all of the graphics inside a single bank. That alone isn't too big a deal so I went back to the graphic I was cutting up to fit.

 

While I was freeing up space, the overflow wasn't falling into the proper bank as quickly as I expected it to. I did some extra testing and found for some reason the last 8 bytes (32 pixels) of the bank refused to accept graphics despite the next graphic to be added was smaller than 8 bytes. (I had to keep chopping up a larger graphic til it fit.)

 

I tried making a quick test prog, attached below, to see if it would always leave 8 open. But it didn't. The test program simply tries to add (with mode 320B) 256 4-pixel graphics. That should completely fill the bottom bank. However, while it won't leave 8 free like it was doing with my graphics tests, it left 1 open. (I added a 257th sprite as well which should always carry over, which it does - but it should be the only graphic that does that.)

 

Not sure if this is an Issue, or if I'm just misunderstanding something.

 

The program itself does nothing - it's just a list of graphics includes for the most part.

bug.zip

[RevEng]

Good catch - definitely a bug. I've uploaded a fixed version to 7800.8bitdev.org

[Mord]

Thanks. I'm not sure if the bug is completely eliminated but it's certainly in a better state than it was!

 

I also noticed the latest version redefined how DL start locations for the zones are caculated - where I hook into them directly it made for some interesting side effects. I like the change though - it looks like it'll make it easier to edit savescreened data in the long run, as well as changing resolutions during the development cycle. (I primarily just edit the wall locations in graze suit alpha currently as an example.)

[RevEng]

Yeah, the variable DL memory locations make it a bit easier when you're working under the hood. They're also the first step in 7800basic allowing DL memory to be relocated to cart or xm ram, for larger DLs.

[RevEng]

Ok, I found the real source of the incgraphic bug, and fixed it correctly. It seems I had a mistake in the 320B and 320C byte width calculation used to see if the dl has enough remaining room for the new graphic.

 

I've also introduced optional double-buffering. Behold! 40 moving sprites...

 

doublebuffer.bas.a78 doublebuffer.bas.bin

 

...such a large number of sprites requires external/on-cart memory, to hold a larger display list. The "set dlmemory" command was added to support this.

 

double-buffering unhooks your game code from the TV display frame-rate, so it's also handy for games that need extra time to build up a complex display.

 

Some architectural changes occurred in this release. I had to change the mode-splitting technique to account for this - see the splitmodedemo in the samples directory, or the manual information on "topscreenroutine".

 

The new 0.6 release can be downloaded from 7800.8bitdev.org, as usual.

[Trebor]

...Behold! 40 moving sprites...

 

They look stationary to me.

 

Now these guys are moving...

 

https://www.youtube.com/watch?v=d1nWjIx1QeA

 

 

40 non-flickering moving sprites!

 

That's really impressive, RevEng.

[+Random Terrain]

The differences between the latest PDF and the one before it were checked using WinMerge. Based on that, I added the set dlmemory section, the doublebuffer section and the topscreenroutine subroutine section. The Table of Contents and Index were also updated. If you think I missed something or screwed something up, please let me know.

 

Thanks.

[Mord]

I can probably guess the answer but just to save me some time from tinkering with the samples, is it possible to do a splitscreen with the topscreenroutine with double buffering active? Or would it cause glitchy things if the double buffering went more than a frame before switching?