[bB 256k, 128k, 64k, 32k, 16k, Multikernel Frameworks]

22 hours ago, Karl G said:

Edit: I should probably tag @RevEng to verify the accuracy of my answer since this is his framework.

Yep, it all looks right to me!

[7800Basic "Bouncy" Backgrounds]

If you have too much dma going on, display interrupts and wsync hits can get deferred to later lines.

[7800 NTSC boot rom documented?]

1 hour ago, karri said:

Your github is private.

It's not, but I see what you mean. I'll open a ticket. Thanks for the heads up.

[7800 NTSC boot rom documented?]

I just uploaded a copy of the NTSC bios (updated with additional comments) to my github. (it's not open source, which is why I didn't add it to the 7800 devtools github)

 

The source could use more commenting, for sure, but I'm not seeing a jump to F000. The bios NMI lives at F000, so maybe that's what you're seeing? In any case, search for "26C2" and you'll find the start of the 2600 Init code.

[7800 NTSC boot rom documented?]

1 hour ago, karri said:

Was this a known problem?

[edit - trebor beat me to it]

 

According to Kevin Horton's 2600 Bankswitch guide, there was only one commercial game that used F4, Fatal Run. The best practice for 2600 bankswitched games is not to assume a particular start-up bank. I tried starting up Fatal Run in different banks using Stella's "-startbank" argument, and the game appears to follow best practice.

 

So it wasn't a problem during the commercial life of the 7800, and shouldn't be a problem for homebrew games that follow best practice.

[cc7800, a C compiler dedicated to the Atari 7800]

2 hours ago, bsteux said:

Does anyone know how the Atari 2600+ is detecting the presence of a YM2151 ? Does it probe some specific address on the bus or does it look into the dumped ROM code for some access to a specific address (like 0x460 as suggested by the http://7800.8bitdev.org/index.php/YM2151_Detection detection code by @RevEng ? By the way, same questions for the Pokey chip...

I have to be a bit careful here, as I'm not able to disclose closed technical details. I will just point out that it's been publicly reported that the 2600+ YM/Pokey emulation works with games that have code to drive these chips but don't physically have them on the PCB.

[New Game: Destroyer 7800]

Great work!

 

Minor suggestion: it would look good if you changed the background color to the sky color below the visible screen. That way the upper overscan area would be sky colored.

[Experimental 2600+ Firmware]

1 hour ago, KainXavier said:

The game boots but there's no audio or video.  Based on the FPS, the performance is also pretty bad. 

When a game doesn't load right, the FPS isn't a matter of emulator performance, but rather the 2600 rom not giving out proper sync signals. The target FPS and actual FPS values being displayed in the debug info match each other, so the emulator is actually keeping up just fine with the (broken) code.

 

Zippy is a 64k rom, and only 16k was dumped, so this is a problem with the current public dumper.

[A78 header changes]

6 hours ago, Aking said:

i can't seem to "unfix" embedded size and unsync v3+v4

I'm not really sure why you'd want to do that... the embedded size needs to be correct, and v3+v4 headers should be synced for maximum compatibility with emulators and flash devices. Older emulators will ignore any v4 headers present, if they don't support them.

 

That said, if you want to go back to what you had before, 7800header always creates a ".backup" version of your rom. (though if you made changes in two or more sessions, the backup will be overwritten)

[DMA Masking - an alternative to modifying CHARBASE when vertically scrolling]

Yep, that works. The wrinkle there is you need to run the visible DLL all the way to the bottom of the PAL overscan area (or have a specific PAL version that does that) so you wind up with a different amount of play area between regions. Even with the NTSC version, you need to go a lot deeper than usual, to look right with TVs that have more visible area.

[Stella 6.7.1 virus warnings?]

46 minutes ago, Thomas Jentzsch said:

And this might kill quite some projects.  

My tinfoil hat is showing, but that suits the corporate push for walled gardens and software licensing just fine.

[Stella 6.7.1 virus warnings?]

8 minutes ago, Thomas Jentzsch said:

I am afraid, eventually we will be forced to buy developer certificates for hefty money.

I think that's a correct prediction. There is no incentive for the AV vendors to correct heuristics that result in false-positives, because any cost to the false-positives is external to the AV vendor.

[Stella 6.7.1 virus warnings?]

Virus scanning was added to Chrome a year ago, but it seems a recent update has some very aggressive virus signatures and heuristics.. Apparently the 2600 Halo rom also has malware! 

 

There are instructions in that thread on how to disable the check globally, if you so wish. I really don't think stella has a virus, and there's not much to be done here. Unlike other AV vendors, Google doesn't have a process to appeal and white-list a falsely flagged executable.

 

The executables from my open source projects, which are cross compiled on Linux and never touch a windows box, are regularly flagged as containing viruses, though the vendors always disagree on what. They use heuristics like "small download" and "not signed by a developer certificate" ($$$), in addition to overly-small overly-generic signatures that get triggered by a Hello World test.

[Phoenix - POC]

On 3/12/2024 at 10:34 AM, Synthpopalooza said:

Pleiades next?

Phoenix first

[DMA Masking - an alternative to modifying CHARBASE when vertically scrolling]

2 hours ago, PacManPlus said:

 (If I'm doing something wrong, let me know).

Entirely right. The approach of what gets updated just depends on the game design.

 

2 hours ago, PacManPlus said:

That's actually an interesting idea... I like that

Thank you; I'm going to give that a shot.

[DMA Masking - an alternative to modifying CHARBASE when vertically scrolling]

No worries. I didn't realize you were modifying the DLL pointers to DLs, instead of the character object addresses.

 

You can add the 4 objects to all of the DLs, but then point past them with the DLL pointers for all zones except the last.

[DMA Masking - an alternative to modifying CHARBASE when vertically scrolling]

It works with characters, but as you observed, the last zone needs 4 objects inserted before the character objects. It's true whether you use sprites or characters for the background. You just need to handle the bottom zone as a special case.

 

The easiest way to do that is to just add 20 bytes of pre-padding to the last zone DL, but have your tables with DL locations skip over that 20 bytes of pre-padding. Then your special case for the last DL is just to point the DLL at the pre-padding, which can be done in your DLL build routine.

 

Of course, that assumes you aren't otherwise running out of DMA on the line, even without the 4 objects.

[320 mode colours question]

I wrote a proof of concept a while back. I need to get back to it and turn it into a real game, rather than just a display test, but all of the enemies use 320c.

phoenix.bas.a78

 

 

[Halo for the 2600 Released at CGE! Download the game here!]

1 hour ago, Albert said:

They really should be taken to task for this, especially as it appears they are just blanket labeling all such files as dangerous.  I'm sure there are other extensions they are targeting as well. 

AV is the scourge of open source projects, for the last decade or two. The cost of false positives is externalised to the open source devs, who are asked to  prove to several vendors that each and every new project release doesn't, in fact, contain a virus. Or you buy an expensive developer certificate, which lasts for a year, and still doesn't help with all AV engines.

 

I'm not happy to see the AV scourge spread to our retro platforms that cannot have viruses.

[Experimental 2600+ Firmware]

I wouldn't sandpaper, personally. Erasers are good for cleaning edge contacts - gum art ones first, and if they need it, the rougher pink ones. Brasso is a good one too. Follow any of these up with alcohol.

[Score, variables and mathematics question]

1 hour ago, alfredtdk said:

I'm looking for this section in Batari Basic to learn more about this, about numbers and shared sprites, I haven't found it yet.
Hypothetically speaking, if there was an optimization of the code and reduction of some animated effects, would this perhaps help so that there would be no flickering in the numbers presented?

What can be displayed is a function of the display kernel, though the 2600 has limits on how many players can arbitrarily be positioned on any one scanline. i.e. there are just 2 players, and their regularly spaced copies. There are some kernel tricks that can be employed, like in galaxian 2600, but it still doesn't allow "arbitrary" positioning of those player copies.

 

Have a look at using the bB multisprite or dpc+ kernels . Using those you can have more players on the screen, but you will still get flicker when you try to put more than 2 players on the same horizontal strip, because that's a 2600 fundamental limit.

 

If none of the alternate bB kernels are suitable, you'd need to learn assembly language and how to create your own display kernel. Even there you won't be able to get past the fundamental limits, but you can reuse objects as you see fit in different horizontal bands of the screen, which may or may not be helpful for your game design.

[Score, variables and mathematics question]

The standard kernel is full, in terms of cycles per scanline, but also in terms of display objects. To display other items, like your values, you'd need to flicker them, using one frame to display a game object, and another frame to display the math value.

[Experimental 2600+ Firmware]

13 minutes ago, John Stamos Mullet said:

Uh - can't you just enable integer scaling in retroarch? It's right there. It's an option? Is there a performance hit for it? I wouldn't think so.

If you want to lose 20% of the vertical resolution, I guess it's theoretically possible.

[Experimental 2600+ Firmware]

The shimmering when vertical scrolling is a known issue, and has been present since the original factory firmware. Like you mentioned, it's due to non-integer scaling. Not much to be done there.

[Score, variables and mathematics question]

You're welcome!

 

Unfortunately there's no way to crop the screen or have black bars covering up those non-playfield area.