Jump to content

FifthPlayer

Members
  • Content Count

    461
  • Joined

  • Last visited

Community Reputation

320 Excellent

About FifthPlayer

  • Rank
    Moonsweeper

Recent Profile Visitors

5,563 profile views
  1. I like the monochrome punch. Good work!
  2. He said he didn't want to do that. I was trying to brainstorm an alternative. Hmmm... I see what you're getting at. If FastBasic manages the display list on behalf of the programmer (a change from the current behavior), it would be able to implement my idea with a two-step approach. First, a display list with a single DLI at the top of the screen. Then in that DLI add the other DLIs to the display list (this could be done by swapping lists) and start the DLI chain. All that said, I think a VBI is a better idea for what you are trying to do. FastBasic could provide its own hook vector to allow a developer to provide a chunk of code that gets run from within the FastBasic VBI. Not as transparent as you might like, but it would still allow game developers to provide some assembly (or maybe even some basic code?) that gets run with the VBI. This is fun stuff to think about.... Stuff like display list interrrupts have heretofore been impossible to do solely in Basic, so this is an exciting development.
  3. Yes, I have an idea. Go with the second option (update the DLI vector at the conclusion of every DLI). To synchronize, FastBasic inserts a DLI at the very top of the display list that it manages and is for its own use. That DLI is used to start the chain of user-defined DLIs. To deal with dynamic updates to the DLI chain, you could add a mutex flag so that the DLI chain is temporarily disabled while the main program updates the DLI chain. This idea has some problems. 1) It isn't totally transparent to the developer 2) it might cause compatibility problems for programmers who provide their own bespoke display lists. With the mutex method I proposed, the system won't crash into hyperspace due to a partially updated DLI vector but 3) there could be temporary instances where DLIs don't fire because the interrrupt list is being updated. Edit: now that I think about it, a mutex wouldn't be necessary as long as any updates to the chain of DLIs occur before the first user DLI is invoked. So perhaps the FastBasic DLI synchronizer interrupt could also do any necessary work to update the DLI chain, after it has set the vector to the first DLI.
  4. This looks really nice. It's a nice happy medium between the two scenarios I proposed. Most of the time a DLI just stuffs hardware registers anyway. I guess with this code you have to provide your own bespoke display list. I don't see any syntax for specifying at what scanline the DLI should be triggered. As far as supporting multiple DLIs, is your problem with syntax or is it having FastBasic do the work of managing the display list? Because if you require the programmer supply the display list up front, the syntax problem seems solvable. If you give each DLI its own number/ID, and perhaps require the programmer to declare the number of DLIs up front, you can then allow devs to update DLIs dynamically.
  5. The DLI support sounds interesting. Does FastBasic offer a way for a programmer to provide an assembly-language DLI handler(s)? Or does FastBasic include its own built-in DLI handler that provides a specific set of services (like changing color registers, or player-missile position registers)?
  6. The limitation is in the Atari's hardware sprites (player-missile graphics). An Atari sprite is 8 pixels wide and a single color. To make multicolored Popeye, the game overlays two sprites to provide 3 colors plus background. The Popeye "punch" graphic is wider than 8 pixels, so to fit the larger graphic the second sprite is placed next to the first, rather than overlaid. So in that configuration only a single color is available. The second sprite has to be repurposed because the other hardware sprites are already in use (mainly for Brutus).
  7. I have to say the game lineup for this machine is pretty underwhelming. Most of the built-in games are console games and I already have a lot of them from prior Flashback units. Some big titles like Zaxxon exist as console ports, but not arcade versions. And for arcade games, there's only four licensees. Personally, I have an aversion to monthly fees, and I have no intentions to hack the hardware, so the built-in game library was always the draw for me. And for me it's not worth the asking price. So I'm going to pass.
  8. https://www.atgames.us/ is working for me right now.
  9. Some speculation as to how the streaming will work.... AtGames will likely give you access to a virtual PC desktop hosted in their cloud. You access it via a web browser, then sign in to Steam, GoG, whatever on it. Then AtGames streams from that cloud PC to the arcade console. So nothing actually runs on the PC you have at home. I could see this being useful if the cabinet is located somewhere outside the home, for instance a cabinet set up in a public area at a workplace. All that said, I think the per-hour fee is pretty offputting and something like a flat monthly fee might be better accepted by consumers. But AtGames has presumably thought about this and they feel this is the best approach.
  10. I think the answer is more prosaic - they simply didn't have much development time, and so they reached for the most straightforward way to implement line numbers. The history of Atari Basic is documented by Bill Wilkinson and others; Atari gave them a VERY tight schedule along with monetary bonuses for finishing ahead of time. And they did.
  11. You might get better response if you repost in the main Atari 8-bit forum, or ask one of the mods to move this thread for you. This is the programming sub-forum and so fewer people are likely to see it.
  12. I'm willing to bet it's Linux based, since AtGames would be able to avoid paying a licensing fee to Microsoft for each unit shipped. Given all the other licensing fees they are paying out for the 350 included games, they would likely want to economize wherever they can.
  13. Teensy-weensy bug report: there's a typo in the first line of the first screenshot (the one with the backstory). "Peacful" should be "peaceful". I like the old-timey 80-column green terminal font.
  14. Hmm, I spent a long time trying to get Apple Jack to jump onto the platform in the first level but just discovered a different way to do it. Previously I was stuck. I'll hold back my criticism on the control layout until I play some more.
  15. That works for Altirra.....I also have a 130XE.
×
×
  • Create New...