Jump to content

RevEng

+AtariAge Subscriber
  • Content Count

    6,541
  • Joined

  • Last visited

  • Days Won

    10

RevEng last won the day on September 5 2020

RevEng had the most liked content!

Community Reputation

5,889 Excellent

About RevEng

  • Rank
    ​​ 👾 Space Cowboy​ 👾 ​

Profile Information

  • Gender
    Male
  • Location
    ​ 🇨🇦 

Recent Profile Visitors

45,246 profile views
  1. RevEng

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

    bB wish list

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

    bB wish list

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

    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.
  5. PRGE 2022: "Say... what's going on behind those curtains at the AA booth?"
  6. 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.
  7. 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.
  8. Nope, the plan was ROM. It's an in-cart chip, and the idea was they could have customised it per-title.
  9. Honestly, reading through the specs made my heart ache more than a little, for what could have been.
  10. 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.
  11. 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.
  12. I think that's a great idea. He also needs to add control via the console switches!
  13. Yeah, the usage of those bits is unique to the 7800 running in 7800 mode, and also unique to leaving the INPTCTRL register unlocked. Until the INPTCTRL register is locked, any hits to TIA locations also hit INPTCTRL with the same values. Normally, 7800 games will lock INPTCTRL at boot, making this concern moot. But I sometimes use 7800basic to create utilities that interact with INPTCTRL (e.g. the 7800 utility cart keeps INPTCTRL unlocked at first, so it can peek at the BIOS and generate a CRC signature) so my VBLANK (and other TIA register) usage takes that into account where possible.
  14. I'm not seeing it in the bB standard kernel... am I missing it?
  15. Yeah, don't sweat it. It's some internal access in the emulator tripping them, which I need to track down at some point, but harmless from an emulation standpoint.
×
×
  • Create New...