RevEng

Nice find. 👍 So not a pull-up like I initially thought, but instead in-line between U12-3 and the RAM WE. (and U12-4)

Thanks guys! I sent a mail to Steve. Fingers crossed that he has something to share, and is willing to feed the nerds.

For rom load errors, the first thing to try would be just cleaning the slot. 7800 mode is higher frequency than 2600 mode, and involves the higher address pins.

Not a dumb question. I'm not sure if it works with console on, but I remove the cart from the console entirely. It will receive power over usb.

I am so so sorry for your loss, Oscar. Hoping for peace and comfort for your family.

@Trebor documented a perfect Choplifter! run...

Jackpot. Steve put the presentation notes online. Within the notes is an interesting overview of the plans for the full-blown Gumby... So we have confirmation here that the full Gumby was supposed to have 8x voices. (per channel? or do they mean a 4+4 voice mix for stereo) If the design relied on clock division, like TIA and Pokey, using 50KHz would give the upper range fairly coarse frequency resolution. (a bit worse than pokey running with a 64KHz base) This doc seems to be a loose overview, so "at least" may just mean the minimum acceptable lower bound, and they would have targeted a higher rate. Or perhaps Gumby wasn't a clock division design. There's also no mention of how the sound timbre might be changed. There's also a very clear version of the slide I captured before... ...looks like I was wrong about 4x voices (also clear from the previous note). Other than that, the block diagram doesn't illuminate anything for me. (The "accum" "add" notes make me think that maybe the chip wasn't using clock division, but instead using addition+overflow to evenly divide up the frequency range, but that's a lot of inference from two words in a block diagram.) Is this all old news to you guys? I think I'd like to reach out to Steve to see if he has any other info he'd be willing to share with the community on Gumby or Minnie, but I don't want to bother him if I'm just retreading old ground that I personally just missed running across before.

I could, if I had a scope. Since I only dabble in hardware, I've been getting by with just a cheap logic analyser. I'm mostly uncertain about the specific target of the fix, rather than the general result. For that I think I'd have to give disabling it go, and see what it does, but the issue it protects against is likely some obscure edge case.

My 7800 has the RAM resistor too. It appears to be pulling WE up. I'm not sure if that's to delay the leading edge of a write, or to make it end quicker. WE for both of the ram chips is common, so the resistor would affect both chips. It's also common to U12-4, where it's used to derive the clock for the INPTCTRL U11 flip-flop. Not sure which is the intended target for the fix... the ram chips, the flip-flop clock, or all of the above.

Wow. I was a bit surprised when Steve mentioned me above, and figured it was mostly a thoughtful kindness, not wanting to leave me out. Now more mentions... My heart grew two sizes this day! I'll make the observation on James' behalf that I don't really fit the show's spotlight mold; I have just a handful of homebrew titles, due to spending a good chunk of my hobby time on tools for devs. Though I certainly do feel a bit of pride every time I watch the show and see a bB game using the title screen kernel, or one of the many kick-ass 7800basic games. Lots of good spotlight suggestions so far. Bob DeCrescenzo could fill out a couple shows. 👍

Awesome news! Flash carts in general seem to be more sensitive to cart pin resistance than regular rom carts, so cleaning is always a good place to start. The utility cart software doesn't know how to look for a write-only [email protected] (technically it can't be detected, it just needs to be written to blindly by the software) so yeah, your lack of pokey detection in the utility cart is normal. I don't know how common it is to have a cap there on pokey, but it appears to just be a power decoupling or conditioning cap. (it's connecting v and gnd) I wouldn't sweat adding it back on, but we'll see what batari says about it.

This was a very good presentation, with lots of interesting tidbits. Thanks for passing it on! Steve talked about the cart-based "mini gumby" in the chat and put up this block diagram... While it's mostly blurry to the point of being illegible, it's clear to see the blocks around the border are pinouts (e.g. "VDD") though what exactly the internal blocks represent is a bit tougher to discern. Guessing what seems to be 3 additional layers under some of the internal blocks is meant to represent that the block is duplicated for 4 voices. I took a look, but I didn't see this diagram or anything else relevant over at the Museum. Does anybody have a better quality version of the diagram, or is there any other info on "minnie"? The dev community has been looking at inexpensive options for quality sound, and I think a micro-based functional equivalent to "minnie" might be an interesting choice. I've seen speculation that suggested that gumby may have been little more than multi-pokey, but I don't think that's right. That's not GCC's style, and Steve's talk seemed to suggest that it was a new ground-up design.

If someone has "unknown bios found" without actually having installed an alternate bios, I'd totally be interested in hearing that. But for Concerto troubleshooting purposes the Console Info screen can be skipped, I think. A mention of the console region is always useful, of course.

Yeah, looks like a rom load error. If you shutdown the console and launch the same rom from Concerto, do you get the same result in the exact same place, or does the bad rom location move? It might be good to give the console slot an alcohol cleaning, just in case. It would be good if everybody reporting an issue could try out the "internal ram test" menu item in the same 7800 utilitycart rom, and advise if it was clean or not with your report.

You're welcome!

That one is part of the initial AtariVox+ run (as opposed to the original AtariVox) that were assembled by Glenn Saunders (mos6507) and sold by thegoldenax. This was prior to Al taking over the AtariVox+ sales. The AA AtariVox+ version has a redesigned label, and different packaging. By definition, all of the AtariVox units are homebrew, since they came out after the commercial life of the console.

Yeah ascii sneaks up on you. Even a single 40x24 screen of characters is most of 1k, let alone wrapping up strings with plotchars. Maybe some day I'll have a go at some kind of Huffword encoding, though even that's not going to be magical (~50% compression, depending on the number of words used) and then one would need to unpack the strings into memory before using them. That means a lot to me, especially since I most often get feedback when someone hits a bug or is having a tough go with some functionality... there were some lean years during which the 7800basic developer landscape was a lot more barren, with just a few brave early adopters. It's very gratifying to now see all of the different 7800basic WIP and completed projects, yours included. 👍

Pretty much every feature and decision has a real resource cost, and since the 7800 is limited in resources, it's my role to try and spend them wisely in 7800basic. One of those resources is my limited dev time. Even though we're talking about a small amount of rom and cpu, this is a feature that won't be available on real hardware. More importantly, there are things I could be doing with that dev time that would seem to pay better dividends at this time, or at the very least, that are dearer to my heart. That said, all of the YM support in 7800basic is there via DMF2ASM and it's bundled XMYM assembly tracker. All of the code is open and freely available. If some other dev wants to add YM panning to their basic or assembly project, they're certainly welcome to do so!

No, it encodes with default center-pan. The XM (and no doubt dragonfly) only have access to the mono on-cart audio line.

You're relying on the fact that whatever code that ran previous to your score subtraction just happened to set the carry flag. If you know that the previous code will always set carry, then that's fine. If the previous code will sometimes will clear carry and sometimes set carry, then you'll have an issue; your subtraction code will sometimes remove 2 from the score instead of 1.

It's not a bad idea, with the benefit that one could use it in an if...then, but there might have some issues with dasm syntax within the preparser. (an asm+end clause overrides the usual basic preparser) I'll have a look next time I'm in the source, to see how cleanly it might work.

You're welcome. It sounds like using the drawwait command during your main loop is what you're after. It should be noted that on many TVs you will be able to see background color changes in overscan, depending on your screenheight. If you needed to avoid that, you'd need to do something with userinterrupt instead, since that runs right as vblank starts up.

Everything I'm about to talk about is with reference to regular 7800basic operation vs double-buffering. With double buffering enabled your game code and screen updates happen whenever they happen, without regard to the timing within the TV frame. After a "drawscreen", your code begins to run right near the top of the visible frame. I say "near" because there's a few things that happen first - some interrupt handling, including any "topscreenroutine". Your game logic will continue to run throughout the reset of the visible frame, until you either: run out of visible screen time, at which point it will begin to execute out of overscan. execute your first plot* statement, at which point 7800basic will wait until overscan, to avoid glitches that could happen if you update the display while it's being drawn. call another drawscreen, which will cause the CPU to wait until the top of the next frame. The above stuff is why my performance recommendations say to do all of your game logic right after drawscreen, and leave any plot* commands to happen right before the drawscreen. Since plot* commands run during overscan cpu time, which is more limited than visible cpu time, it's best to reduce any game logic around your plot* commands. If you wanted to know if some of your code was running during the visible frame, you could change the background color before and after the code in question. The height of the painted rectangle tells you how much of the visible frame the code is taking up. If you see the painted rectangle running off the screen and overlapping itself at the top, your routine is using more than a frame. If your game logic runs too long and the next visible screen happens before your "drawscreen", generally you just see a repeat of the last frame. In theory, because you may not have finished plotting some objects, those objects may be glitched or missing. In practise, an occasional dropped frame doesn't usually result in visible glitching, due to the previous frame likely being very similar to the past one. If this overage is more than occasional, than the chance of object glitching goes up, but even here it just depends on how often things move in your game and where the plot* statements actually happen. If your game does a frame count via the main loop, then indeed your count would be off with regard to TV frames, though accurate with regard to game-logic "frames". If your game does a frame count via interrupt, then your count would be accurate with regard to TV frames, and off with regard to game-logic "frames". Which accuracy you value more is up to you. There shouldn't be any other effects of an extra frame, other than your game moving slower if they happen regularly. Music, sound effects, and other time critical stuff happen via interrupt. I probably value 60hz updates more than most people, so I worked pretty hard at getting Salvo to run within budget in most circumstances. Part of that was painting the routines with the background color, and ensuring everything fit within the frame. Certain game logic routines are spread across different frames, or run only on certain frames, to accomplish that. When game objects need to move quickly, true 60hz update makes the game motion appear smooth, silky, and alive, in a way that you usually only experience on the 2600.

[edit] nevermind; I re-posted Karl's original response, but now I'm not so sure you can handle it, so I've removed it. ( ͡ᵔ ͜ʖ ͡ᵔ ) The ratio of width to height of 160 mode pixels is 1.714. So vertical movement of 1 pixels/time-unit would cover the same visual distance as 0.58 pixels/time-unit in the horizontal. The same math actually holds true for 320 modes too, since horizontal movement for those modes is still on a 160 pixel grid. For sfx, have a look at the bundled soundtest sample. Or have a look at the thread with the same utility, which has a link for playing the sounds online via JS7800. It's pretty easy to take the existing sounds and tweak them. The sfx format is pretty easy. For TIA music, I use the 7800basic integrated tracker. It's MML based, so a natural fit for coders. See the guide and the bundled trackertest sample if you're interested in that route.

Super impressive!