Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Gemintronic

+AtariAge Subscriber
 View Profile  See their activity

  • Content Count

    9,937

  • Joined

  • Last visited

  • Days Won

    35

Posts posted by Gemintronic

  1. Posted

    I appreciate the time and labor put into the PlusCarts.

     

    I've made a small run of 2600 games using 3D printing before.  It's never quite a perfected science.  You could be into the 12th print and half-way through there's a tray full of plastic spaghetti moving around :)

  2. Posted

    10 hours ago, Karl G said:

    Huh. Does this just happen with that modified kernel, or does it happen with the base multisprite kernel as well? If the latter, do you have an example of this that includes the basic source so I can try to see what's going on?

    It happens in the modified multi sprite kernel used in Flappy Bird. Thought it would be easier to point to the Flappy Bird source than present awful, work-in-progress code.

     

    I guess I was glomming on too many fever dreamed concepts.  In a perfect world I'd wish that multi colored playfields be integrated into the multi sprite kernel.  Also, the glitchy effects when virtual sprites pass vertically through said playfield.  It is not a bug in bB.  Just an unintended effect in the modded multi sprite kernel Flappy Bird uses.

     

     

     

     

    playfieldbleedproj.zip

  3. Posted

    38 minutes ago, Andrew Davie said:

     

    Of course as we know, every piece of paper had "@Gemintronic" on it.

    When do I get my cut?

     

     

     

    Good news is that I have yet another reason to make a new 2600 game incorporating the PlusCart..

     

    ..bad news is my methodology of choice is: "Dark Agile" so your royalties may take years with the productivity it delivers :)

  4. Posted

    29 minutes ago, Andrew Davie said:

    We have a winner!

    Congratulations to @Gemintronic, whose name was literally pulled out of a hat by Tanya on the ZeroPage Homebrew show today!

     

     

    Holy HMOVE bars Batman!  Thank you!  I'll be sure to put this to good use!!  Email sent :)

    • Like 2

  6. Posted

    11 hours ago, bogax said:

    And speaking of cycle counting, wouldn't it be nice if the language could report byte count or tote up cycles for you

    (but that's not something I'd expect to see in bB. on the other hand it might be worth while if the purpose of bB is to ease you into assembly)

     

    I think the Jaguar BASIC used to use BCX to take BASIC and turn it into C.

    http://bcx-basic.sourceforge.net/

     

    I could swear some people are working with CDFJ and C.  Maybe something could be jury rigged from that combination..

    https://atariage.com/forums/topic/297759-part-1-cdfj-overview/

  8. Posted

    30 minutes ago, Andrew Davie said:

    You don't need the Nextcloud thing. It's just convenient for getting your own ROMs onto the PlusCart.

    The PlusCart provides pretty much every available ROM already, via the PlusStore.

     

    The dream is to keep things as local as possible.  Including figuring out how to send and receive level data.

     

    I'm stubborn and slow.  So, it should take awhile.  :)

  9. Posted

    My PlusCart arrived a few days ago.  Thank you, Al_Nafuur!

     

    Now I have to figure out how to set up that Cloud thing and hunt down some example code.

     

    Er, and set up my new wireless router.  Procrastination leads to layers of things to-do before you can do the thing you want to do 😛

    • Like 1
    • Haha 1

  13. Posted

    Perhaps something like SARA RAM where part of the variable means something.

     

    Like: var37b12 would indicate which variable (var 37) in which RAM bank (bank 12) should be read or written to.  Have the 6502 kernel and ARM code do the heavy lifting of retrieving said value from the ARM resources.

     

    I guess an alternative to wait state flags would be to have a function for reading/writing ARM RAM.  Said function would return 255 if still waiting.

     

    In other words, I'd trade the complexity of waiting for extra variable reads/writes over dealing with low level stuff like push pop foo lang dang whatchahooty.

  15. Posted

    12 minutes ago, Karl G said:

     

    I can tell you that unfortunately this one isn't possible. DPC+ memory can be accessed by the ARM processor, and there's no way for the 6507 to read and write to them directly. The stack gives a way to do this indirectly. Effectively it lets you save your existing variables, and restore them when you need them, but there's no way to bypass the need to use the stack or something similar to access ARM memory, unfortunately.

     

    Things like expanded memory management and extended memory management existed in the 286/386 days.  Perhaps with a little more code running on the ARM side something can be done to mitigate the complexity for BASIC coders.

     

    Maybe something that allows you to request to store ARM variables and retrieve ARM variables.  With a special flag raised when said reads or writes have executed.  So, it doesn't have to complete right away.

     

    I wonder if a routine that pretends to be an internal SaveKey could be made.  That's another half coherent idea.

  16. Posted

    I may have been thinking too VisualbB centric.  That IDE has a field for an alternative batch file to be used during the compile process.  It's the only way to successfully use VisualbB under Linux/WINE.  Anyway, inject your preprocessor into there.

     

    My bB laundry list revolves around the plain, old multi sprite kernel.  None are actually requests.  Just selfish dreaming :)

     

    Multi Sprite Kernel

    * Seamless/integrated support for virtual sprites in the built in collision function

    * Seamless/integrated support for playfield collision in built in collision function

    * Ability to assign sprite data to more than one sprite.

    *  It seems like off screen sprites still effect flickering on on-screen sprites at times.  I wonder if designating Y location 255 could tell the graphic kernel to stop processing a sprite and optimize itself accordingly.

    * Find the CPU time for variable height ball/missiles.  I'd gladly sacrifice playfield and sprite resolution for this.

    * Slipstream playfield background/foreground color support into the standard kernel.

    * Prevent visual horizontal rebound of sprites when they cross the screen boundaries.  I.E. make them seamlessly transition from the screen and loop to the farthest relative position at the other edge.

    * Special title screen mode with asymmetrical playfield and disabled sprites.  Maybe triggered by pfheight=0

    * Integrated nybble variable support.  Multi sprite games are thirsty for variables!  'Specially in a QuadTari game.

    * Fix the color bleeding when sprites move vertically through a multi color background.  I know this is currently only a feature in an unofficial extension.

    * Managed sprite mode where player0 is swapped with whatever other sprite is going to cause flicker.  So, at least one pair of sprites will not flicker.  More RAM and CPU time but less flickery fickering bB games :)

     

     

  17. Posted

    Could a lateral solution work?  Some combination of an assembly include file with new routines and a code pre-processor that converts certain new commands into inline assembly?

     

    Yeah, this is a badly explained idea that I hardly understand myself :)

     

    Just trying to think of solutions that don't require extra attention/effort on batari or RevEng.

  19. Posted

    11 minutes ago, kevtris said:

    do you have a ROM or something I can test out?  also, it could be the YM3438 busy behavior checkbox might change things.  If not I will look into it.  This is the first I heard of this problem.

     

    That's because I complained before doing the logical thing and ask for help :)  Sent you the offending Genesis homebrew.  Thanks again!

  22. Posted

    So, I figured out how to test JagStudio compiled games on the MiSTer FPGA.  It has a pretty much abandoned, incomplete core.. but, that may change.

     

    First, this YouTube video has a link to be compiled core: https://www.youtube.com/watch?v=OCKsYtjAySU

     

    Plop that Jaguar .rbf file into your \\mister\fat\_Console directory.  Put your JagStudio compiled ROM files into the \\mister\fat\games\Jaguar directory.

     

    I found that the MiSTer core doesn't quite understand .abs files so make a ROM file instead:

     

    C:\Dev\jagstudio>build print ROM

     

    It's not a great solution.  But, it is yet another option!

     

     

  23. Posted

    I think this topic was a product of its time.  What I remember was a glut of people asking for free development services without any clear specifications.  Also, declaring that game development was worth nothing because: easy.

     

    I tried to engage them with gentle push back:  show me your game design.  Give me gameplay rules.  Give me mock up screenshots.  That usually caused them to stop responding.

     

    A few years go by and now I just see novices willing to at least consider doing it themselves with community support.  Elitism and newbie entitlement both seem to be at a low point.  I think hashing it out here helped.  Also, the general respect AtariAge members have for each other.

     

    UPDATE:  I just realized I may come off as contradicting what batari just said.  Nope.  Nope nope.  Just adding my own experiences.

    • Like 2

  24. Posted

    18 hours ago, Steven Pendleton said:

    Did you try the YM3438 busy behaviour option?

     

    Didn't see an option like that.  But, I'll check again.  Thank you!

     

    Problem is: all the people who bought my genesis homebrew who just want to stick in the game and go.  They'll just assume my work is awful.  I mean,  it IS but I'd rather they put in the time to find out themselves :) 

  25. Posted

    The Mega SG runs my sega genesis homebrew like your typical genesis clone: with super sped up music.  This doesn't happen on original hardware or hardware clones like the JVC X'Eye.

     

    The MiSTer just updated their core so my games play like original hardware.  So, for now: MiSTer 1  Mega SG 0

     

    The neat thing is both systems are FPGA so it's just a matter of who gets updates and enhancements more often.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...