RevEng

Late night work, and it looks like I forgot to actually attach the binaries to the release. Just as well, as I was able to fix a small bug, which caused an issue when you didn't use interrupts. @Random Terrain the binaries at the github release page now are in place, and have the pdf in them. There was one small update to the user-interrupt section.

Thanks for all of the kind words, all. Honestly it's been a treat working with the MiSTer devs, who deserve the lion's share of credit here. Speaking of credit... the devs were looking for expertise on implementing 7800 colors/palettes, so of course our color guru @Trebor got pulled into the discussions. Trebor has provided the devs palette files they could use directly, general info on the subject, and guidance on which palette choice is going to look best overall as a default. So a big thanks to him from me, for that.

7800basic v0.18 is now available at the github releases page. Whats new, compared to v0.17: User interrupts and DMA enable were made a little kinder and gentler. Interrupts now won't trigger until you've completed a drawscreen or page flip. New options added to the 7800header menu. The main purpose of this release is to make it impossible to create boot-time race-conditions between your main code and the interrupt. If you don't know what that means and you use interrupts, you should probably update.

The 7800 core is 2600 mode capable, but the devs are literally in the process of hooking that up right now, so it's too early to say.

Nice, and you're welcome! I'm thrilled to have helped Kitrinix and alanswx with this work. Hopefully you'll get a chance to run the new core soon.

A heads-up that I've been working with some of the MiSTer FPGA devs (Kitrinix and alanswx) on the 7800 core. Mainly I've been the 7800 programming answer-man, creator of various 7800 test programs, co-analyser of problem roms, and guy responsible for updates to the a78 header. I take no credit for any of the VHDL, nor the painstaking hardware analysis being done (but they are using 7800 logic diagrams directly provided to them by no other than Curt Vendel... that guy is still making an impact!) and frankly I'm awed by the level of skill and determination being displayed. It's my pleasure to say the in-progress 7800 core is now freakishly accurate, despite all of the torture tests I've thrown at it. This is not surprising in retrospect, given the attention to detail being thrown into this project. I know real 7800 consoles are getting expensive, especially in certain parts of the world where the 7800 didn't see wide release. A simple de10-nano and 32m memory card may be a good alternative very soon, and if you're interested in any of the other systems, it can be a cost-effective one. (the MiSTer wiki has a good overview, and details on what those other systems are) In case MiSTer FPGA somehow hasn't been on your radar, RMC has a decent intro video...

See this issue [nevermind me here, with the answer]

The boxcollision sample uses pretty much the same dimensions, without issues. Was one of the objects positioned partially off-screen?

bB won't be able to do accurate cycle counts. It doesn't "know" a particular location is zp or otherwise while it's generating assembly code for dasm. Like orange808 suggests, stella would be better. Or dasm, but that's less useful than stella since it's a static analysis.

A CX-40 button press does cause a short when the console is in two-button mode. A two-button game is supposed to monitor INPT4/5, and immediately switch back to one button mode if they go down. 7800basic does include this protection when in two-button driver, so it should be safe. As safe as the original commercial run of games, anyway. The same protection will kick in if a game designer is using QuadTari with Prolines and accidentally enables two-button mode.

Understood. It's much better when my (B) moments happen in private, because it keeps the illusion of competence going.

You're totally welcome. The 7800 folks, myself included, would be thrilled to see what you could do with the old gal.

QuadTari on 7800 in one-button mode appears fine. I may need to adjust the 7800basic abstraction for two-button vs one-button fire-button sticks as part of the QuadTari support (likely where Karl's test got hung up) but INPT4/INPT5 is registering as expected. Here's a 7800 test program. It sets one-button mode, but shows 2 button controls because it's adapted from another program. Just look at the INPT4 and INPT5 registers, rather than the graphical button state. Left difficulty switch controls vblank cap grounding/charging. (i.e. whether INPT4 reads are for QT ports 1 or 3, and whether INPT5 reads are for QT 2 or 4) quadtaritest.bas.a78 quadtaritest.bas.bin I'll do a proper 7800basic integration soonish, but this should hopefully give anybody keen to support QuadTari enough info to do it.

Yeah, we came to that conclusion a while back, before QuadTari was completed. As part of the design it uses the paddle lines, and so do the proline sticks, so two-button mode has always been known to be unsupported. QuadTari *should* work with 7800 in single-button mode with regular cx-40 sticks. It *might* work with prolines in single-button mode, but that needs testing. I've been swamped IRL, so I just haven't gotten to that yet.

Yes, they want it to act exactly as local memory. Of course they do. They just won't be happy when their game runs out of cycles and rom partway through the design, at which point they'll be posting in the forums asking why they've run out of rom and cycles. Then we'll be telling them that they shouldn't access DPC memory like regular memory.

Sure, but you're doing that to tell the user that they should avoid using it except whenever absolutely necessary, at which point it's lost utility over the stack functions. In that case the abstraction only serves to fool the coder into thinking accessing DPC->variables is the exact same as regular variables.

As basic as it can be, without hobbling the game. It's the same reason that bB lacks print statements, lacks character strings, uses one byte for regular variable types, uses fixed point vs floating point, etc. If an abstraction would be too costly in the context of the 6507, then out it goes.

So it's possible in theory to do that in bB, but it would take major overhaul to most of it. Each time a variable is accessed, used as a parameter, etc., bB will have to fetch and store to arm as needed In my mind the question is, should we really abstract away all of those extra cycles and rom? A statement like "mem=mem+3" normally generates something like... lda mem clc adc #3 sta mem While with ARM memory becomes something like... LDX #memIndex STX DF0LOW LDA DF0DATA clc adc #3 LDX #memIndex STX DF0LOW STA DFOWRITE Which is about twice the rom and cycles. A huge chunk of the game code deals with variables, so unfettered usage of the ARM variables with this interface will eat your game's lunch. The only way to mitigate this cost is to adopt a "load memory" and "save memory" ethos prior to certain sections of your code, at which point the whole thing starts to look the current ARM stack functionality anyway.

PRGE 2022: "Say... what's going on behind those curtains at the AA booth?"

Fair point. Wiki updated. Steve reported the design was complete, and that they had prototype chips manufactured and working. I think the analog section outsource mention in that doc was old news. They found the expertise somewhere. When I read about the rom-based waveforms, I was also thinking that it missed out on economies of scale. Thing is, I think GCC would have been aware of that at the time, having just finished Maria2, so I personally trust that they would know if it was a feasible concept or not. Either way I do think they would have likely had a common Minnie config (or two) and only customised it per-game when the game actually demanded it, and was expected to sell in large numbers.

This was also part of my motive for getting the Minnie information from Steve. It would be a good alternative to pokey, and something unique to the 7800 scene. There's certainly enough information in the docs to do a sound-alike clone. Probably worth it to deviate from the original design and do the samples in updateable RAM though, since 64 bytes of RAM per sample won't affect our cost, like it would have with the original chip.

Nope, the plan was ROM. It's an in-cart chip, and the idea was they could have customised it per-title.

Honestly, reading through the specs made my heart ache more than a little, for what could have been.

As most of you are likely aware, TIA wasn't the first choice for 7800 audio. Originally the 7800 Maria chip was supposed to include advanced audio within it, but that was removed when die-space was needed for other functionality. At that time GCC pivoted to in-cart audio, coupled with TIA audio. Over the years there's been some speculation as to what GCC's proposed in-cart sound chip solution would have been like, and how cost-effective it may or may-not have been to have an in-cart chip. To help nail this speculation down, I reached out to Steve Golson. (GCC chip-designer extraordinaire, and friend of the community) Steve kindly searched through his archives for all of the docs he could find, and shared them with me. (and now you) When I received these docs, I was astonished to read about Minnie. This thing was no pokey-redux. Here we have a chip capable of basic WaveTable synthesis while still keeping things lean and cost-effective. I've written a 7800 Minnie Sound Chip article over at the 7800.8bitdev.org wiki, which also contains the original GCC docs. Steve is still seeing if there's anything else he can put his hands on, so the article may be updated as time goes on. If it is, I'll post an update here. Enjoy, and feel free to ask questions here, or discuss what may have been.

It's normal. The utility cart tries to initialise and read information from the pokey to detect it. Concerto doesn't support reading from pokey at the homebrew-typical $450 location, only writing.