RevEng

🤷 It seems to be stated in the official MiSTer FPGA FAQ... When will MiSTer support cartridges? MiSTer will never use physical cartridges. The project aims to replace the need for having original hardware for the same experience. It is also physically impractical/impossible given the number of GPIO pins available from the FPGA.

Seems to be working for me, with a test program.

Derp, you're right. I glanced casually at the schematic and mistook r34/35 as belonging to the pin 5/9 paddle inputs. So really I should have said R38/39. (and given those are 1.4k series resistors that will divide the voltage with the pull-down, I guess 20k+ would be more prudent than my original suggestion of 10k+)

No, genesis controllers operate completely differently than CX78. Similar hacks can't be made for CX78, because the 2600 lacks the circuitry required to read CX78 buttons independently. (and a 7800 in 2600 mode has this circuitry inactive)

Am I wrong in thinking that adding some high value pull-downs, say 10k+, at R34 and R35, would likely stop the wandering and allow for regular 2-button and paddle operation?

There's a new v0.32 7800basic release at github. Changes include: fix: rare unpack bug in lzsa optimisation. fix: spaces in basic filename hangs compile, under Windows. (RT, there are no manual updates in this one.)

If you want to send me your project directory in PM, I can check out the 7800basic side of things. I pretty extensively tested out the 2-pass stuff, but the fact that you're running into this problem right after 2-pass probably isn't coincidental.

Heads-up that they're back in stock at AA.

Chris is the authority, but I think I can get most of the list right... dma cycle penalty updates, which fixes visual glitches (retail and homebrew titles) palette accuracy updates (retail and homebrew) opcode updates (homebrew) maria render fixes (homebrew) pokey accuracy additions (homebrew) additional mapper support added (homebrew) ym2151 support added (homebrew) [edit] threadpeat [edit x2] also relevant

You sir, are a beast 👏

I've worked with the JS7800 source a few times. My understanding is the translation of the core prosystem emulation to javascript was done by some automated process, and then fixed up and tied in to the UI after the fact. Most of the original prosystem code is there in the comments, so back-porting isn't impossible. The trick is knowing where the fixes are, which would need to be done by someone with detailed knowledge. Maybe @raz0red would be open to a gig consulting or back-porting the fixes? Performance. This device can't won't run the a7800 core at full speed.

(Must... not... post... about.. Dremel)

The built-in tracker uses MML for composition. MML is kind of a programmer's music composition language. There are examples in the samples directory, and the manual covers the MML syntax. The tracker shares same TIA priority code as sound effects, so the music can play together with sounds - up to you which instruments or sound effects have priority over others. In the Salvo theme, I intentionally used a busy drum track (loosely based on the Funky Drummer riff) The notes have priority, and the beats just fit in wherever they can.

You're totally welcome! Various aspects of the 6502 aren't supposed to be reliable on power-up, so Stella is probably emulating that. Best practise is to initialise the cpu, console ram, cart-based ram (if present), and allow for power-up with any bank active. (if using bankswitching) Sometimes people will skip one or more of those, observing that it works fine on their hardware, but if you do that and your game endures, it will eventually become a headache for someone.

You've left decimal mode switched on somewhere. A starts off as $50, and after subtracting one, A becomes $49. That's normal decimal mode behaviour.

There's a new v0.31 7800basic release at github. Changes include: feature: compression and decompression commands have been added. feature: two-pass compile phase. Banners and tallsprites no longer need to follow their corresponding inc* statement in your source code, to work as-expected. feature: "set pausesilence on" directive added, to pause and silence tracker music when pause is active. fix: the native tia music tracker generates spurious reads to $0000. fix: max shakescreen with screenheight=224 and zoneheight=8 would sometimes cause interrupts to be missed. fix: plotsprite4 wouldn't error-out when you plot a sprite 32 bytes wide. An error message has been added. For anybody using the lz4 compression assembly routine that's been kicking around, I'm pretty sure you'll find the new in-built lzsa has better compression (typical 10% smaller) and faster decompression. (typical 20% faster) and a slightly smaller footprint. All credit goes to the Emmanuel Marty of the LZSA project. (though I did use 7800heat to improve the 6502 decompressor speed by about 10%)

Yeah, Seagull 78 will work with any 7800 game, including Petscii Robots. It's not presently in stock, but my understanding is the Mega7800 adapter will be in stock soon - it will allow your Genesiis pad to work with 7800 games too, but has the added virtue of allowing upcoming homebrew games that are aware of it to use the extra buttons. (Millie+Molly, A.R.T.I., Bernie and the Tower of Doom, ...) and it will also allow Sega "Light Phaser" Lightguns to work without modification with 7800 Lightgun games. (CRT display required, of course) Unfortunately Mega7800 came out after Petscii Robots, otherwise we would have added it as a multi-button option for the game. (but it works just fine in it's default two-button Proline mode)

There are 8 banks in 128k. Like bB, 7800basic starts counting from bank 1, so bank 8 would be the last one. There's no real developer headaches if you want to start with 128k, but later decide you need to migrate to 256k, or 512k - literally you can just change the format and renumber your last bank. Correct, and that's a good way to start. But you may find that last bank is just too small to hold everything you want to stick in it. If that happens, you may need to start splitting out map-specific graphics into ephemeral banks - maybe you'll have Base Area specific sprites in bank 2, and Ice Area specific sprites in bank 3, and make copies of the main loop in each. I'm avoiding giving a solid design layout, because there isn't a one-size-fits-all layout. Start with your plan, but adjust the plan if you need to.

I should really write something up on this in the wiki Atari's 7800 supergame bankswitching gives you 16k of rom that changes whenever you bankswitch (ephemeral banks), and another 16k of perma-rom. (the permanent, last bank in rom) First rule - you need to keep anything that 7800basic needs for the current frame in either: the last bank, the active ephemeral bank. or ram. That goes for goes for graphics, level data, text strings, music data, etc. If you start using the interrupts (topscreenroutine, bottomscreenroutine, userinterrupt) they *need* to go in this last bank, or else bad things will happen when you bankswitch. So you want to stick anything that's very shared in that last bank, be it data, code, or graphics. If there's something shared that can't fit in the last bank (data, code, graphics) you can stick copies of the same stuff into the ephemeral banks that that you plan to be switching between - even though that seems wasteful, this sort of duplication is normal. For things that don't need to be shared, I like to break my banks down by game function. e.g. my title screen code and graphics go in one bank. I guess one way to judge this is if the code uses a different main loop than your game engine, it might be a good candidate for another bank. I also dedicate banks to large data structures that will be copied to ram (e.g. RMT music, level data) along with the routines that do the copying.

Only that wasn't the entirely of your claim... I made the statement that 320 mode on the 7800 isn't difficult on the 7800. You just need to take the time and learn the rules, and that's no different than any other system of the era. That doesn't merit a summarising of "320 mode is easy on the 7800" without my qualifications. It's a stupid statement without qualifications, because it's not easy for children or animals. Using 320 modes would not be difficult for a professional game programmer in the 80s, because they're already need to work within rules for systems they know, and it's the same situation here. Then you add the "unlike other systems" claim, which is the complete opposite of what I've been saying all along. I'm moving on from this meta discussion, because now you're not only dropping salient points from my posts, you're now dropping assertions that you yourself made as you try to defend statements. Life is too short for these kinds of games.

If it helps, you can conceptualize Maria's operations in a couple of ways. Both are accurate, but depending on your understanding of other systems, one may resonate with you better than the other... First, you can think of Maria as a soft-sprite accelerator on steroids. You hand it a list of sprite (and character) parameters (graphic data location, x, width, palette, mode) and it runs through the list and composites all of the sprite and character bitmaps for you. There's another level of detail to this explanation, due to the fact that Maria only has two on-chip scanline buffers. (one buffer is used for displaying the current scanline to the TV, the other used for generating the next scanline coming) Maria's bitmap compositing happens on a scanline by scanline basis, so you need to give it multiple parameter lists (aka Display Lists) covering different horizontal strips of the screen. Second, you can think of Maria as a blitter chip, only unlike other blitter chips it doesn't run in parallel with the cpu. Instead it halts the 6502 when it needs the bus, and copies over graphics data at 4x the normal 6502 clock. (with no time wasted fetching opcodes or processing loop logic, like the 6502 would need) The extra level of detail I mentioned earlier, about Maria having a scanline-buffer, applies here too - the blitter operation is repeatedly triggered for each scanline prior to it being displayed by the TV, rather than the singe blit to a full-screen ram destination you might see in other blitter implementations. It's worth pointing out here that one of the explicit GCC design goals was for the console to run Robotron well, and the Robotron arcade game has a blitter chip for compositing graphics. (as does Joust and Sinistar)

Defender_2600 commenting about cycles being something that had to be checked for Xevious in 160B mode literally didn't have anything to do with 320 mode at all. And before you infer some grand weakness, 320 mode doesn't use more cycles than 160 mode - 320 trades color for resolution, not cycles. The fact that you're paraphrased what I've said as "even 320 mode is easy on 7800" and "no advanced programming required unlike other systems" is either delusional or a bad faith strawman. Since you decided to mischaracterise what I said, rather than cite, I guess I'll need to do it myself... Show us on the doll where the 7800 console touched you.

To rule out a problem with whichever console port you have them plugged into, try the snes2atari in the other port. (with 7800 Petscii Robots, of course) The game will autodetect the control and use either port. A multimeter test isn't going to be very instructive. The SNES controllers talk to the console through a serial protocol, unlike controllers from Atari. Are these SNES gampads from Nintendo, or some third party manufacurer? We tested the game with a pretty wide variety of SNES controllers, both first and third party, but obviously not every third-party controller that ever existed.

Who told you that the 7800 doesn't have resource limits you need to not be careful of exceeding?!? Citation, please. NES didn't manage an arcade-perfect Xevious port either - it looks worse than the 7800 port from my perspective - despite your pet theory about it being easier to get amazing results from the NES without difficulty. It's almost as if dedicated arcade hardware from 1982 could push console tech from 1984 to the limit. So strange.

You only need to "check cycles" (or test a design on real hardware or emulator, which is what most devs do instead) when you're pushing the game display so hard that you're in danger of bumping up against the system limits - it's not a factor in most games. When you're pushing the limits of other consoles, you also need to be sure you're not exhausting the resources involved. Even the NES! 😱 But by all means, confirm your bias again!