7800basic beta, the release thread

[Revontuli]

10 hours ago, RevEng said:

It looks like 7800basic isn't setting the header to "hram@4000" instead of regular "ram@4000", like it should be. It's a pain, but either you can set that after a build with 7800header, or you can wait for the next release. Sorry about that.

No need to apologize!  I feel a little bad for jumping in and pushing certain limits from the get-go!  I'm very excited about a feature that more than doubles the graphics I can have access to (as well as free up more ROM space for code).  I also know this is a beta, and part of the development process.  I try to make sure any issues I find are not a result of my own ignorance, and I try to narrow down what a given problem might be first, but I appreciate your work and efforts!

[RevEng]

I dropped a new v0.23 7800basic release at github. Changes include...

• feature: allow bankset with cart-ram to hold dl (see manual for double-buffer limitations)
• bugfix: bankset and cartram generated incorrect a78 header
• bugfix: "too many endifs" (harmless) error output

Just a minor release to knock off some of the rough bankset edges, so people could keep experimenting. 

Note that I haven't yet addressed the snes2atari+savekey issue yet - it's not a difficult fix, but I haven't had the time to do the deeper real-hardware testing and fix validation required.

[+mksmith]

 

@RevEng Mike sorry to bother - with banksets + ram do it still initialize it using:

 set romsize 128kRAM

 

I'm getting the red/grey lines on A7800.

 

Source

 set pokeysupport $800
 set doublewide off
 set tallsprite on
 set tv ntsc
 set zoneheight 8
 set screenheight 192
 set romsize 128kRAM
 set dlmemory $4000 $5fff
 set mcpdevcart off
 set bankset on
 set pauseroutine off
 displaymode 160A
 
 bank 1

MainLoopBank1
 clearscreen
 drawscreen
 goto MainLoopBank1

 

[OldStyle]

10 minutes ago, mksmith said:

I'm getting the red/grey lines on A7800

Matt, I noticed the same thing... if I'm not mistaken the memory type in the header should be set to hram?

[+mksmith]

40 minutes ago, OldStyle said:

Matt, I noticed the same thing... if I'm not mistaken the memory type in the header should be set to hram?

Ah thanks! I should check that with the header tool when I get a chance.  

[RevEng]

Actually, it should work with just regular cart ram, but I think I need to add to the doc - the "set bankset on" needs to come before anything else. (critically, "set romsize" and "set dlmemory")

[+Random Terrain]

1 hour ago, RevEng said:

Actually, it should work with just regular cart ram, but I think I need to add to the doc - the "set bankset on" needs to come before anything else. (critically, "set romsize" and "set dlmemory")

 

I was going to check for changes and update the online version of the manual today, but maybe I'll wait.

[RevEng]

Up to you. It will probably be at least a week or two before I manage another release. I've given the info here, which is fine for now.

 

The main addition to the manual was a caution that using banksets+cart_ram+"set dlmemory" needs to be handled specially. It's a bit of a special case, so anybody needing that info can just pull it from the pdf if they need it.

[+Random Terrain]

51 minutes ago, RevEng said:

Up to you. It will probably be at least a week or two before I manage another release. I've given the info here, which is fine for now.

 

The main addition to the manual was a caution that using banksets+cart_ram+"set dlmemory" needs to be handled specially. It's a bit of a special case, so anybody needing that info can just pull it from the pdf if they need it.

 

Yeah, that's probably too long to wait. Page has been updated:

 

https://www.randomterrain.com/7800basic.html

[+Karl G]

Question about dmaholes. I understand why they get created when there is more than one graphic block, but it seems like a dmahole also gets defined every time when using a bankswitched ROM even when the graphics all fits within one bank. Why is this the case, and is there any way to avoid it?

 

Edit: The problem goes away when I moved the graphics to the last bank as I should have anyway, so I have the answer to the second part of my question, which makes the first part mere curiosity instead of an issue to be solved.

[RevEng]

The dma holes are a hardware feature, and they dictate the addresses where graphics blocks can go. i.e. between the holes. The hole locations for any given zone height, are set in stone.

 

So even with a single graphics block, you always have a dmahole right after it. (and right before it too, but we don't need to do anything special to use the space before the graphics block)

 

For example, if you put one graphics block into bank 1, with a zone height of 16, the graphics go from $A000-$AFFF, with a dma hole at $B000-$BFFF. If you switched to a zone height of 8, the same scenario would place graphics from $B000-$B7FF, with a dma hole at $B800-$BFFF.

 

[edit reply to your edit - the 7800basic reserved area sits in a dma hole at the end of the rom, in the last bank, so you don't get to access that dma hole. Not because it's not there, but just because it's already being used]

[+mksmith]

8 hours ago, RevEng said:

Actually, it should work with just regular cart ram, but I think I need to add to the doc - the "set bankset on" needs to come before anything else. (critically, "set romsize" and "set dlmemory")

Great thanks mate - working fine now.  I need to expose the guide somewhere in the extension (as it's quite valuable when you read it) but I will put a note in the hover tooltip about the ordering.

[Revontuli]

I'm porting over my scrolling system, and seem to be most of the way there, but I'm having trouble with A7800 emulating the POKEY sound on my ROM when turn banksets on.  I have POKEY@450 set in the source code.  I'm not sure if it's a case of the headers needing to be set a certain way (setting Pokey@450 on its own using 7800Header doesn't seem to work), but my current setup is a 128kROM16kRAM(x2 for banksets).  Everything else, graphically, seems to be working ok at this point.

 

 

Edited February 14, 2023 by Revontuli

[RevEng]

7 hours ago, Revontuli said:

I'm porting over my scrolling system, and seem to be most of the way there, but I'm having trouble with A7800 emulating the POKEY sound on my ROM when turn banksets on.  I have POKEY@450 set in the source code.  I'm not sure if it's a case of the headers needing to be set a certain way (setting Pokey@450 on its own using 7800Header doesn't seem to work), but my current setup is a 128kROM16kRAM(x2 for banksets).  Everything else, graphically, seems to be working ok at this point.

You need to use pokey@800 by using the statement "set pokeysupport $800". You could set this in the header after-the-fact to pokey@800, and it would work in a7800, but It's now best practise to hard-code pokey at the particular location your hardware is expecting it.

[Revontuli]

11 hours ago, RevEng said:

You need to use pokey@800 by using the statement "set pokeysupport $800". You could set this in the header after-the-fact to pokey@800, and it would work in a7800, but It's now best practise to hard-code pokey at the particular location your hardware is expecting it.

Thank you!  That did it - when all else fails I suppose I should re-read the documentation!   
 

With the DMA holes, it seems like you'll get 8k of graphics per bank (unless you're sticking with zone-locked graphics and some custom ASM code) correct?  The scrolling code I use assumes zone-aligned tiles, but the characters and objects can be anywhere on the screen.  8k per bank in a 128k ROM is a nice amount, although I can imagine using the RAM to store more level tiles, etc. as previous posts have suggested.  

 

Regardless, this frees up a ton of space and simplifies a lot of my bookkeeping (graphics *here*, code *there*).  I usually try to learn something new with each game, and I'm looking at banksets (and data compression) for the platformer I'm working on. 

 

Thanks again for the help!  

 

[RevEng]

3 hours ago, Revontuli said:

With the DMA holes, it seems like you'll get 8k of graphics per bank (unless you're sticking with zone-locked graphics and some custom ASM code) correct?  The scrolling code I use assumes zone-aligned tiles, but the characters and objects can be anywhere on the screen.  8k per bank in a 128k ROM is a nice amount, although I can imagine using the RAM to store more level tiles, etc. as previous posts have suggested.  

Yep, 8k of graphics out of each 16k bank, due to the dma holes. For sure copying graphics to RAM is a nice way to increase that.

[RevEng]

A heads-up... after implementing "set dlmemory" for banksets with cart ram, I've just now come to realise it's going to be a problem with banksets cart hardware. (there's a requirement that the first DMA fetches come from console ram, rather than bankset rom or ram). So I'l need to turn "set dlmemory" off when banksets is chosen, in the next release.

 

If you need additional memory for the DL for more objects, it's recommend to instead use "set extradlmemory on" and use the cart ram for anything you would have stuck in $2200+.

 

Note this is only a problem for the DL memory, You're still able to store graphics, character buffers, etc. in the cart ram without issue.

 

Sorry for any rework this caused!

[+Gemintronic]

"26 bytes is more memory than anyone will ever need." - Bill Gates

[+Random Terrain]

I got an e-mail today:

 

Quote

I tried to post on github, but the submit, or it tells me that I don't have permission at this time.
With "extradlmemory" on. Is there a way to control which memory locations can be added? Lets say a program needs about 512 bytes for variables, and arrays that need to track what is going on in a game. Maybe have the extra display list memory use $2400 to $27FF, for some extra onscreen sprites per line.

 

Can somebody answer that and I'll send the reply?

[+Gemintronic]

29 minutes ago, Random Terrain said:

I got an e-mail today:

 

 

Can somebody answer that and I'll send the reply?

 

There are some banned members that try to bypass normal support routes.  One of them made multiple Facebook accounts to spy on AtariAge activity including mine.  Sounds a little fishy.

[RevEng]

peteym and his sockpuppet accounts are banned at AtariAge and the 7800basic github, which is why he's having trouble getting help there. 

 

7800basic is a product of the AtariAge forums, and peteym regularly bad-mouths AA in other venues. Sorry, but I don't want to help him out. 🤷

[+Random Terrain]

1 hour ago, RevEng said:

peteym and his sockpuppet accounts are banned at AtariAge and the 7800basic github, which is why he's having trouble getting help there. 

 

7800basic is a product of the AtariAge forums, and peteym regularly bad-mouths AA in other venues. Sorry, but I don't want to help him out. 🤷

 

I don't know anything about peteym, but the name on the e-mail is "Peter J. Meyer" and after doing some searching, I guess that is the same person.

[RevEng]

Yes, same person.

[+frankodragon]

4 hours ago, Random Terrain said:

I got an e-mail today:

 

 

Can somebody answer that and I'll send the reply?

Possibly the best answer for this is an animated GIF. 

 

[+Random Terrain]

5 hours ago, RevEng said:

peteym and his sockpuppet accounts are banned at AtariAge and the 7800basic github, which is why he's having trouble getting help there. 

 

7800basic is a product of the AtariAge forums, and peteym regularly bad-mouths AA in other venues. Sorry, but I don't want to help him out. 🤷

 

In case you want to know, I got a reply back:

 

Quote

I could have created a "sock puppet" on Github, to post the question, and probably got an answer without any problems. But I chose not to do it this time. This is what happens when I try to move forward being myself, polite, and honest. The response provided me other with information.

 

I have no idea what that last sentence means.

 

youtu.be/40K6rApRnhQ?t=31