7800basic beta, the release thread

[7800basic beta, the release thread]

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.

[MiSTer FPGA - 7800 Core]

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 beta, the release thread]

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.

 

[MiSTer FPGA - 7800 Core]

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.

[MiSTer FPGA - 7800 Core]

1 minute ago, Gemintronic said:

THANK YOU very much for your work.  I'd very much like to use my MiSTer with 7800bas.  My PC and MiSTer are literally a matter of feet from each other!

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.

[MiSTer FPGA - 7800 Core]

 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...

 

 

[Troubles Using DASM]

See this issue

 

 

 

^{[nevermind me here, with the answer]}

[7800basic beta, the release thread]

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

[bB wish list]

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.

[Joystick multiplexer help]

1 hour ago, ChildOfCv said:

I'm surprised that using a CX40 on a 7800 game doesn't burn them out since it shorts 6 to ground when you push the fire button, but maybe the resistors to each transistor do adequate current limiting.

[...]

If you want to use Quadtari in 7800 mode with one button, then turn off the Q6/Q7 transistors at RIOT port B, and use the 2600's fire button bit.

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.

 

[Joystick multiplexer help]

1 hour ago, Karl G said:

I'm glad to hear that A) it works, and B) it wasn't me doing something stupid. Though I could have lived with B. 

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

[Joystick multiplexer help]

9 minutes ago, johnnywc said:

That's great news, thanks so much for confirming!   

You may inspire me to get into 7800 programming now...   It would be nice to add some 7800 games to the Champ Games list someday.  

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

 

[Joystick multiplexer help]

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.

 

[Joystick multiplexer help]

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.

[bB wish list]

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.

[bB wish list]

8 minutes ago, splendidnut said:

So this DPC+ thing would be "somewhat" reasonable then? 

 

You could require the user to prefix the DPC+ variable access with "DPC->" or something similar.

 

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.

 

[bB wish list]

20 minutes ago, splendidnut said:

Always a good question to ask.  The language is called Basic.  All depends on how "basic" you want to make the language for the users. 

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.

 

[bB wish list]

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.

 

[What type of game would you come up with, that uses a controller that is not supported on the 7800?]

1 hour ago, Shawn said:

Ass stick.

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

[The 7800 Minnie In-Cart Sound Chip]

48 minutes ago, Pat Brady said:

That happens when I read almost anything about Atari after they ran Bushnell off. Just a massive squandering of potential.

 

I'll quibble with this. Contemporary sound chips were SID (on the market in 1982), 2A03 (1983), and YM2151 (1984), all of which did envelopes in hardware. 2A03 envelopes were limited but better than nothing.

Fair point. Wiki updated.

 

48 minutes ago, Pat Brady said:

 It strikes me as a clever design with at least a dash of wishful thinking: the second document contains a jarring statement about needing to outsource design of the analog section, and I believe the per-game ROM customization was not feasible at all. But even if they had chosen 2 useful waveforms to be shared by all games, this would have been a very nice option for 7800 games. For that matter, even if it only provided the 3 "free" waveforms it would have been a vast upgrade from TIA alone.

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.

 

[The 7800 Minnie In-Cart Sound Chip]

13 hours ago, batari said:

That said, this looks like a job for HOKEY! hehe.

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.

 

[The 7800 Minnie In-Cart Sound Chip]

2 hours ago, ZylonBane said:

Err, did you mean on-chip RAM here?

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

[The 7800 Minnie In-Cart Sound Chip]

8 minutes ago, Trebor said:

Such a shame it never saw the light of day back in the 7800's heyday. 

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

[The 7800 Minnie In-Cart Sound Chip]

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.
 

[Concerto firmware thread]

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.