SmittyB

Nice...

Just to put this into perspective for everyone, I was curious as to price of the 2600+ versus the price of the 2600Jr in 1992 and when taking into account inflation the Jr would be about £75 today compared to £100 for the 2600+. Seems pretty reasonable considering it's a 7800 on top of that.

The gist of it is that Atari Inc split into Atari Corp and Atari Games Inc with Jack Tramiel getting Atari Corp and Warner getting Atari Games Inc. Atari Corp merged with JTS, JTS sold all the Atari Corp properties and name to Hasbro Interactive who sold everything to Infogrames, then Infogrames through various business stuff and layers of subsidiaries became Atari Inc with Atari SA as the parent company. The Atari Games Inc branch eventually folded back into Warner.

The rad ones do.

The pain of picking a mode, drawing loads of graphics in it but deciding to try other modes 'just in case' only to circle back to what you already had after hours of wasted effort... ...yeah I don't know what you're trying to say 🤐

For the good of humanity ProSystem should be scrubbed from the internet. It's not at all accurate and relies on several bodge fixes to specific games. There are some newer emulators derived from ProSystem that fix a lot of the problems, but ProSystem itself is obsolete and should be avoided.

@KrunchyTC this thread might be interesting to you, and here's a link to a small bitmap demo I did. Press Select to switch between 320A and 160A modes. https://raz0red.github.io/js7800/?cart=https://atariage.com/forums/applications/core/interface/file/attachment.php?id=910920

I'd go so far as to say 7800basic is a great tool for learning 6502 assembly. It's trivial to look at the compiled output that's sent to the assembler and learn how the higher level commands break down into simpler instructions. You can then take that code and make small optimisations based on assumptions the compiler can't make until you're confident to just do certain things in assembly. I write most of my code in assembly just because I'm comfortable with it, but I leave all the tedious work like converting graphics data, playing sounds, managing the screen and more to 7800basic. If there's some complicated logic I can always write it in 7800basic and move on whereas otherwise it might have scuppered the whole project.

I don't know why I assumed you were talking about the X position but I did and that's where the 160 figure comes from. The visible Y is from 0 to either 191, 207, or 223 depending on your screenheight setting. The same rules about 192 / 208 / 224 to 255 being offscreen still count and things will wrap around.

Looks like the compiler isn't sure how to interpret it. In 8 bit maths, -1 is the same as 255 where the value of the byte underflows from its minimum to maximum values. If you just want to stick a negative number in you can do so by subtracting from 256. For example -32 would be 256-32=224. The visible part of the screen is from 0 to 159 so that gives you 96 pixels that are offscreen to work with.

It's in production currently unlike Dragonfly, and supports more ROM formats than Concerto currently does. Then on top of that it's the only one to support the custom chips that power Rikki & Vikki for those who missed the cartridge release, mod-less RGB-out is a big deal for some people including me, it allows for save states and cheats which I don't believe any other 7800 cart has, and as an added bonus it supports 2600 games. There are some games that make use of the Yamaha with the best examples I can think of being Pac-Man Collection Anniversary Edition, and 1942. I'm not sure if anything uses dual pokeys yet apart from music demos, but as support for it becomes common it's more likely we'll get games that use it.

Don't worry, Team 17's Body Blows and Body Blows Galactic exist for all your 1-button Street-Fighter-clone needs

I guess it's possible it's registering to the left on the next line but that would be quite a lot of a delay. Either way the calibration will probably sort it out.

I don't want to derail the thread too much, but it's coming along very well thanks. I rewrote the original version from scratch to take advantage of some ideas I had and it's all the better for it. I'm pretty much where I was with the old version plus some new extras like quadtari support. I'm not sure how practical 4 lightguns will be with the screen flashing away all the time but the option is now there for whoever wants to play it that way.

But yes I am working on a duck-themed lightgun project called Ducks Away. It is not Duck Hunt because frankly DH is dull as dishwater and I can do better. For the lightgun I use a target selection method like DH which flashes individual targets on screen and it means the gun only needs to tell me if it saw something that frame. I tried the screen-flash method but while I could reliably get the Y position, the X position requires precision timing to be anything close to accurate and I just couldn't make it work. If the response times are affected by those components aging as @DrVenkman mentioned then that will throw off the accuracy by quite a lot. I know the 8-bits read the gun as an analogue device but I don't know the specifics, but on the 2600 /7800 the screen-flash method means polling the gun in a tight loop. I believe Crossbow only manages to poll it about 16 times per line giving an accuracy of down to the nearest 20 pixels give or take. If the gun responds late it could miss being polled and be out by nearly 40 pixels.