7800basic beta, the release thread

[RevEng]

Yup, you can use a split screen with topscreenroutine, and it works fine with double buffering. topscreenroutine now gets called from an interrupt at the top of the screen, so there's no stopping it.

 

It's a better situation all around. Even if you're not using double buffering, the topscreenroutine method avoids split-glitching if you take too long to prepare the frame and it gets drawn before you actually call drawscreen.

[PacManPlus]

 

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.

... At the risk of sounding stupid, con someone explain to me what double buffering means? Is it something that I've done in one of my games without knowing the term? I guess I don't quite understand how you keep a stable screen and speed while not working with the screen frame rate...

 

Also, how many 160A sprites are you able to get in a single zone there? It's a little difficult to count with them moving around so much It looks like quite a bit more than the 'norm'.

 

Thanks!

Bob

Edited April 19, 2017 by PacManPlus

[RevEng]

When it comes to the 7800, double buffering means you have 2 DLLs (that point to different sets of DLs). You point DPPH/DPPL at whichever DLL+DLs you're not actively modifying, and modify the other non-displayed set at your leisure. When you're done, flip DPPH/DPPL to the DLL+DLs that was recently updated, wait for the next non-visible to visible transition, and then you can start working on the other (newly non-displayed) set of DLL+DLs. Rinse and repeat.

 

Thats enough to keep the screen stable. If you want to ensure a steady framerate between buffer flips, you can enforce a minimum framerate. To do this, track the actual frames displayed between buffer flips with a variable that gets incremented via display interrupts, and just burn extra frames if required just prior to each DPPH/DPPL buffer flip. (The 7800basic implementation has this minimum framerate setting as an option)

 

The demo isn't defying Maria's DMA cycle limits, but it is close to a best case scenario. When I create the men in the demo, I spread them out vertically as evenly as possible, so any one zone doesn't get hit that hard.

 

I'm at work, so I don't have an exact count for how many guys start off in one zone. Even if I knew, I can't easily give a running maximum in each zone - when the guys bounce vertically they overlap more, and its hard to count.

[PacManPlus]

Ah... I understand now... thank you... that explains why you need more memory to pull this off...

 

I've never tried doing that... I think Defender might benefit from that...

[RevEng]

No problem. Glad to hear you may have use for it.

[Mord]

I've been fiddling around to add double buffering and the splitscreen routine into graze. Mainly works although there's still work to do. One thing I did notice however is that when I use plotvalue commands to show bonus points between waves, they were blinking. Looking at my code they should be plotted properly ever frame, so wondering if this means the command isn't looking at the second DL list when it should be?

[RevEng]

Thanks for the bug report - it seems I missed the double-buffer adjustment for plotval.

 

I'm possibly reworking the pokey detection for another release right now, so for now you can stick this assembly file into the 7800basic includes directory, and it should fix it.

 

I'll get an official release with this file out in a few days, but it will be the same fix here.

 

[edit - put into the official download]

[RevEng]

Ok, I updated the official 7800basic release, with the plotvalue double-buffering fix, and the pokey detection was updated to better handle pokey carts missing the pokey.

 

No difference between the latest official release and using the modified std_routines.asm with the previous release. (also, no updates to the docs, RT)

[Heaven/TQA]

Much information in the thread and guide for me as 7800 noob still fighting with bmp7800 to get pixels as wanted on screen.

 

I think the concept of Maria is too different to the consoles at the same time (nes,sms,c64/800) but get used to it

[ColecoGamer]

Is 7800basic more complicated than Batari Basic? I have a decent understanding of BB, and I have written a couple of simple games with it. I wasn't sure if what I've learned so far with BB could be carried over to 7800basic or not.

Edited June 4, 2017 by ColecoGamer

[Mord]

Best way to answer that is to take a look at it yourself. (I haven't done a lot with batari basic and don't remember anything about it really)

 

Just go download the zip and take a look at the programs in the samples folder. That'll probably give you an idea of what's possible and if it's close enough to what you're familiar with.

[+Random Terrain]

Is 7800basic more complicated than Batari Basic? I have a decent understanding of BB, and I have written a couple of simple games with it. I wasn't sure if what I've learned so far with BB could be carried over to 7800basic or not.

 

7800basic has more commands than regular batari Basic. There is no IDE for it like Visual batari Basic so far. Sprites are shockingly different on the Atari 7800.

[RevEng]

Not a whole lot more to add here, other than the syntax of 7800basic is pretty much identical to bB. (since bB birthed it) So dimming variables, math operations, if...then, etc., will all be familiar.

 

Also, there's a lot more available memory on the 7800.

[RevEng]

Heads up that there's a new release of 7800basic can be downloaded from 7800.8bitdev.org.

 

Changes:

• added 16k, 144k, 272k, and 528k ROM formats.
• added "set extradlmemory" which uses up the memory at $2200 to increase the number of display objects.

Enjoy!

[+frankodragon]

I've been using the Dungeon Stalker code as reference of what dim variables to use for the Draker Quest 2 game. So I've renamed all the variables after the "var[#]" starting with with $268C. But can I use anything before that? I must have at least 500+ variables.

 

Reason being is I've been getting crashes from testing my game. If I enter one bank, go into another one, then exit that bank, then go back to the bank I've started at, the games freezes up. I changed all the variables and still the same result. And it's just not between two banks, it's pretty much the entire build.

 

I'm using the current build of 7800Basic that was just released.

 

 

[RevEng]

The memory at $2200-$27ff is available. Since you've started with someone else's code, just be sure they haven't already dimned the memory you try to use. And also make sure you didn't go higher than $2700.

[CPUWIZ]

 

dimned

[+frankodragon]

Nope, still glitched even with the dimmed variables changed. It works fine the first time but if I repeat the process, for example from bank 2 to bank 14, then back to 2, and then back to 14, it glitches up. I even tried return otherbank and return thisbank.

 

 

EDIT- Got it to work. Turns out I should of used goto instead of gosub in the 2nd bank and gosub remained in bank14.

 

Here's what happens:

[+Random Terrain]

Heads up that there's a new release of 7800basic can be downloaded from 7800.8bitdev.org.

 

Changes:

• added 16k, 144k, 272k, and 528k ROM formats.
• added "set extradlmemory" which uses up the memory at $2200 to increase the number of display objects.

Enjoy!

 

 

Avast refused to let me download the latest version. It didn't happen when downloading previous versions.

 

[+frankodragon]

I used to have ClamWin for antivirus software and that also detected 7800Basic as a trojan/virus. I just ignored it and uninstalled ClamWin.

[RevEng]

Avast refused to let me download the latest version. It didn't happen when downloading previous versions.

 

7800virus.png

It happens every few releases. The AV manufacturers err on the side of making false positives, because it doesn't really bother them when their AV falsely accuses your code of being malicious.

 

I'll shuffle a few bytes around and let you know.

[RevEng]

I'll shuffle a few bytes around and let you know.

Try now. I checked at virustotal, and all of the accusers are now happy with the zip.

[+Random Terrain]

Try now. I checked at virustotal, and all of the accusers are now happy with the zip.

Thanks. Avast had no complaints.

[+Random Terrain]

The differences between the latest PDF and the one before it were checked using WinMerge, then I updated the set romsize section and added the set extradlmemory on 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.

[Synthpopalooza]

When it comes to the 7800, double buffering means you have 2 DLLs (that point to different sets of DLs). You point DPPH/DPPL at whichever DLL+DLs you're not actively modifying, and modify the other non-displayed set at your leisure. When you're done, flip DPPH/DPPL to the DLL+DLs that was recently updated, wait for the next non-visible to visible transition, and then you can start working on the other (newly non-displayed) set of DLL+DLs. Rinse and repeat.

 

Thats enough to keep the screen stable. If you want to ensure a steady framerate between buffer flips, you can enforce a minimum framerate. To do this, track the actual frames displayed between buffer flips with a variable that gets incremented via display interrupts, and just burn extra frames if required just prior to each DPPH/DPPL buffer flip. (The 7800basic implementation has this minimum framerate setting as an option)

 

The demo isn't defying Maria's DMA cycle limits, but it is close to a best case scenario. When I create the men in the demo, I spread them out vertically as evenly as possible, so any one zone doesn't get hit that hard.

 

I'm at work, so I don't have an exact count for how many guys start off in one zone. Even if I knew, I can't easily give a running maximum in each zone - when the guys bounce vertically they overlap more, and its hard to count.

 

Question: Can the double-buffering be done at 60 fps?

 

Had an idea for a demo which could increase the number of colors onscreen at once by swapping out charactermaps and/or palettes at 60 fps.