RevEng

If you'v specified an address with your pokeysupport statement, then the autodetection is turned off and pokey is hard-coded to that address. If you're just using "set pokeysupport on", the old autodetection code runs, and this code hasn't been changed.

I'm late to the party, but WOW! Super work @playsoft and @TIX!!!

I had a look, and it looks like it doesn't run through priority checks in mono mode. I'll update that when I get a chance.

If you have a pokey in it, try removing it temporarily. Be careful not to bend the pins.

DLs don't allow for negative Y, so for the bottom half of the sprite you need to call "SetObjectImage" with an offset to the image. If you change the "IMAGE" example in the underthehood.bas demo from "SetObjectImage smallball" to "SetObjectImage (ball-8*256)" you'll see what I mean. Using the macros, you'll want to change your offset to "(image-16*256)" so it points past the top of the image, and then adjust the Y. Even more efficient would be to write your own assembly routine based on the underthehood ones that just adjusts the DL object hi pointer by itself, leaving the Y at 0.

Yeah, both are stupid generalisations. Unfortunately these generalisations get propagated by clueless people who wouldn't know good or bad 6502 code, or the difficulties in optimally interfacing the ARM to the 6502. Also a different group, but still as clueless, are the ones who think recent ARM enhanced titles would have saved Atari back in the day. I don't think there's much to be done here, beyond factual corrections when you see bad assertions. I think it's fine to point out sub-optimal 6502 code in a technical review sense. Singling one game out for a bit of "bad code" shaming just seems overly harsh to the author, given the game runs as intended, and was written decades ago in a commercial setting. Could entirely be just my own personal hangup, though.

Great work, Steve! One update on this. The Argon guys reached out for my OK to port my POKEY updates back to MAME. (they didn't actually need my permission, but I did appreciate being looped in.) The updates were accepted, so MAME 0.247 and up will be able to handle your weird POKEY stuff too. My understanding is it also fixed the MAME accuracy of some A8 music.

[!!!sarcasm detected!!!] Seems a bit of a cheap shot. A working programmer sometimes does something sub-optimally with an idea to return to it later, but later never comes because everything works and the product has to ship. Maybe Surratt had code that originally stomped one of those locations. Or maybe he did forget, because he had enough zp memory available anyway. I don't think that takes away from the fact that the 6502 in general, and the 2600 in specific, has a pretty high baseline of efficiency you need to adhere to to get things done.

The Bentley Bear source was created for DASM, so you're set. DASM can work with multiple files too, you just use the "include" directive in your main assembly file to bring in any other files.

All three are working fine for me too.

A7800 doesn't need to deal with this, because it doesn't accurately emulate how the cart is switched away (by hiding A12+A14+A15) so it's not worth studying in this regard. Honestly, the bios threw batari and I a curve ball on the $800 access, and we haven't had a lot of time to look at it, due to other pressing hobby stuff. At this point it looks like batari will just require a bank switch or whatnot to enable pokey at $800. That way it will be invisible until the cart activates it. When that's settle upon, I'll implement the same in a7800. 100% this. The $4xx scheme is the domain of devices with precise decoding logic. The $8xx (and up) should be the loose-decoding area, so to speak. When I get around to it, a7800 will get double-pokeys at the expected $4xx addresses, and at the same time, I'll loosen up the decoding for the $8xx pokey. The BIOS hits the internal $18xx RAM addresses during the console testing phase, while the BIOS is switched in. Because the BIOS switched in, the A12 line appears low to the cart-port device, so the $18xx accss looks like $8xx. If the cart device responds to $8xx, we have bus conflict.

Makes sense to me!

It's not just a matter of having enough gates to add an ARM chip. The disparate parts require relative timing correctness. A low-level emulation of an ARM chip feeding the 6502 by bit-banging the bus requires that both parts are cycle accurate. A small slip in the timing and it all blows up. Further complicating things is the fact that "rom" is provided by sdram here, since Mister doesn't have an actual cartridge connector. A 486 may be similar to a 2600+arm in terms of complexity or fpga gates (no idea if that's the case actually) but the same sort of cycle-accurate dance isn't needed for a core capable of playing 486 games. The correspondence of mister components to actual 486 components is also much closer. (sdram provides the 486 sdram, An image on block storage provides the 486 block storage)

Goalposts are being moved. Your claim was "You'll need to switch to asm to show real dedicated love". If you don't wish to broaden your mind to the fact that your hobby rules don't apply to others, then I guess we have nothing more to say here.

It's not a cult, and there's not just one true way to "show real dedicated love". Try to broaden your mind a bit.

I'm wondering if I'm making things worse with another suggestion, but here goes... I found techpowerup's all-in-one collection of visual c++ runtime packages pretty handy. Download the zip, extract it somewhere, and double-click the batch file inside. All of the visual c++ runtimes stretching back before human prehistory will be installed. Never again will you need to figure out which vc runtime version delivers the DLL you need.

I believe that should work. When the cart device sees $FFFC/D access, you're guaranteed that the BIOS is banked out - that will happen only when the encryption check is running out of ram, which is after the ram testing I referenced above which runs out of the bios ROM.

Yeah, for pokey@800 boot you need some special handing, and ignore reads until the bios has handed off. Here's what I wrote to @batari back in April...

It's a miracle that hotcakes sold like the NES. You can only play a few games with hotcakes, hotcakes have zero replay value, and hotcakes start to smell bad after the first few days of purchase.

The benefit to your suggestion is we don't need to allocate another bit, which is good because we're presently out of bits. The drawback to your suggestion is we're taking clarity - a bit specifically meaning pokey@440 - and taking it away, while adding a bit more complexity to the header parser. The header format should document existing hardware, so this suggestion also has the side-effect of implying that second pokey@4xxx is a valid thing. I'd rather see us get that benefit by moving to the v4 header spec, where we'll have bits'a'plenty.

Here's the way I see the address space going forward... The $8xx address range is specifically for non-pass-thru devices with limited decoding logic available. (like concerto) The $4xx address range is devices capable of fine address decoding, pass-thru or otherwise. (like DF, XM, etc) Along those lines, our current bitfield mix and match approach is best left to the $4xx range. I think $8xx will need to be more mapperish. e.g. "dual chip" hokey solutions at 800 will likely use internal chip registers to switch between the two virtual devices, rather than unique addresses for each.

I worked with TwentySixHundred on the side, and this appears to be an issue with a7800 and the 256k+ram mapper. Anybody impacted can revert to the older a7800 release in the meantime, or wait for a fixed release.

There weren't any changes to cart-ram specifically. I can't seem to recreate the issue - it sounds like a 7800basic issue, so maybe hit me up in that thread or PM, and share the source.

That would be ideal. Unfortunately the de10-nano doesn't have enough GPIOs free to pull off cart slots. So like an emulator, it has to provide both the console hardware and the cart hardware. If modern homebrew cart hardware makes that feat impossible with the de10-nano (or at least more difficult than mister devs would like) then it just is what it is.

Hey Lewis, it would indeed help. The pokey@450 in concerto is write-only, so the 7800basic auto-detect routine can only fail. Setting the pokey address explicitly skips the auto-detect routine and enables the pokey, without actually trying to read from it.