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

mksmith

+AtariAge Subscriber
 View Profile  See their activity

  • Content Count

    1,152

  • Joined

  • Last visited

  • Days Won

    1

Posts posted by mksmith

  3. Posted

    13 hours ago, Andrew Davie said:

    I think at this stage I've pretty much learned all that I wanted to know about CDFJ and its capabilities.  A fantastic bankswitching scheme that offers some significant assists to programming - in no particular order, I found that ability to have a "flat memory model" for all of my graphics most useful. I didn't need to care at all about banks, and could just have all the graphics (sprites, playfield) in standard C structures. I loved the data streams that let the 6507 access streams of data with simple lda/sta instructions. Very easy to use, and it made the sprites effectively like those on the 400/800 machines (that is, an 8-bit wide sprite that is the whole-screen deep). I just needed to copy sprite shapes into a 200 byte block of memory, that represetned the 200 scanlines I reserved of screen. I liked that I could effectively "idle" the 6507 during vertical blank, and use that time to do some impressive ARM processing. The full-screen draw every frame wouldn't be possible without it. Actually it's still not possible WITH it, because I'm going way overtime - I'm doing the full-screen draw AND the full board scan/processing.  But that's a fix for another day - the proof of concept was fine for me, even if it only runs on Stella. This engine won't run on hardware and would need a rewrite to do so.  I've taken this demo to the point where I'm not interested in working on new features - sound, title/selection screens, etc. Just not going to happen, and as noted this was always just a test/demo/exploration of capability. To some degree I regret choosing BD as the game on which I based the experiment, but what's done is done. I loved being able to do the vast majority of my coding for the machine in C. It made things so much easier and faster to implement; firstly the ease of programming with the C-language, but also the flat memory model, as noted. It's a game-changer. I really really loved thinking about some idea (for example the overview screen) and being able to program it quickly. In this case, the very first workable-ish version took half an hour. That's astounding. CDFJ is also an eye-opener as to what the actual machine is capable of .

    I'm thinking of taking the lessons learned - for example, the overview screen seems well received and works very well IMHO, and the super smooth-scrolling, and the gajillion animation frames that you can have, and of course ChronoColour(TM) and moving on to a game which would be suited to these capabilities.  That is, "character graphics", a "board" of 40 x n tiles, 8-colour ChronoColour(TM) display. Perhaps a hexboard; I have been thinking this would be possible and work OK. One thing I haven't played with yet, but will obviously be possible, is digitised sound/effects. The only limitation I can see there is ROM space. But CDFJ+... mmh.

    Maybe I'll move on to one of the games suggested in the show, or perhaps one suggested in this thread. I'll have to look at what's around and who owns the IP. But for now, I'm pretty much done with this engine and showing demos and I'll archive it for posterity. I'll start another thread if/when I choose a game to actually write with what I now know.

    Sometimes the best part of coding is doing something different or using some new technology that you haven't before.  If this leads to another awesome project down the track then that's great news too!

     

    Theoretically, I'd be interested in your thoughts around your chess engine and what type of speed benefit something like CDFJ might make to that? 

     

     

  4. Posted

    6 minutes ago, sramirez2008 said:

    Lol Matt.  I’m expecting an Arkanoid t-shirt when the game comes out. The back of the shirt can list the City of Austin Tx. (aka AA headquarters) along with the games official release date and all of the available controller options, in rock concert format.😉

    Lets hope so mate! One day!!

    • Like 1

  7. Posted

    @newtmonkey Hi thank you so much for your kind words.  Of course most of the credit goes to our illustrious devs such as Mike, Fred, Stephen and others for coding and maintaining all the tools ADS pulls together.  I, like you are very happy to be able to just install the extension, type some stuff and push some buttons and know I can see my efforts straight away and now we also have carts such as Dragonfly, Concerto and Harmony to see it on the real thing.

     

    I love the community here for it's openness to share experiences and tools to help each other and ADS is my little contribution to that.

     

    Happy coding!!

    • Like 3

  8. Posted

    Thanks for the update mate 👍  The .h file is clearly tricky due to the association - would it eventually be best to have that restored to the 'C' file association for editing purposes?  I think allowing the VS Code to keep it's base file associations for languages might be best and then have the ability to override/set the compiler quickly might work nicely. I'm thinking of adding a sidebar tab to manage the basics for ADS so you don't have to access the settings to select the compiler.

     

    I'm surprised it's not finding the root/parent makefile as that's what I intended but nice job getting that working.

     

     

  9. Posted

    On 4/7/2021 at 1:35 PM, Andrew Davie said:

    Files are in the project root directory. Their association is to either "dasm" or "C". When I hotkey-build on ".asm" or "Makefile" all works. When I hotkey-build on C or ".h" nothing happens, regardless if the ".h" is a "dasm" file or a "C" file. What I'd like to happen, actually, is the build to happen on hotkey *regardless* of the file type/association in the window.  But, failing that, ".h" associated to "dasm" should behave the same as ".asm" associated to "dasm".

     

    Hi Andrew,

     

    Been doing some checking on this. The base dasm association contains the .h reference, so by default if you select the 'Make' compiler for dasm then it will search for the appropriate make file (at least I does for me on Windows).  It may be that VS Code is not always associating .h with dasm (or that VS Code on macOS is slightly different than Windows in some manner - my virtual environment is not up and running currently) as you are finding with mixing c/dasm.  The first part of the compile validation is using the file association to determine which 'language' to use then in the case of dasm validating whether to use the default, custom or makefile so the message does seem a little odd in that regard.

     

    The whole file association thing is great in theory but is really not working for how I have configured/hack-in the makefile process. I have again been considering the 'project' process we had previously discussed so that it doesn't use the file association when you use the ADV build/rum hotkeys. I'm going to take a bit of a look over the next few weeks but am thinking of having a settings option to select the following:

     

    * use a 'project' file (containing the base config)

    * use the makefile/shell/bat process

    * use file association (existing)

     

    The first two options should/will allow the user to 'take over' the editor and select a compiler/build process to use for any file currently open.  

     

  10. Posted

    5 hours ago, Propane13 said:

    Random question.  How accurate is the a7800 emulator?  Specifically, if a game has too many DL's in its graphics that real hardware wouldn't be able to display them all, would the emulator follow suit, or would it display those extra graphics?  Just checking expectations since I haven't played with newer emulator versions in a while.  I figure I should read up a bit. :)

     

     

    Mike can probably answer more scientifically!! than me but whilst developing I've found that side of it very accurate showing even partial images as it would. It's definitely very helpful when you get very close to the DL limits.

    • Like 2
    • Thanks 1

  11. Posted

    7 hours ago, Muddyfunster said:

     

    @mksmithThis is what I went with (analogue IO board, 128MB ram, USB board and some top/bottom plates + a more beefy PSU). Overkill for 7800 but I plan to do more in the future.

     

    No photo description available.

    Must admit I'd love one !

    • Like 2

  12. Posted

    14 hours ago, Karl G said:

    I was researching how I could comment multiple lines of code with semicolons, and I discovered that the language definition files for batari Basic and 7800Basic don't define a line comment like the DASM language definition does. I think it would be good to add these, either with a semicolon or REM:

      

        "comments": {
        // symbol used for single line comment. Remove this entry if your language does not support line comments
        "lineComment": ";",
        "blockComment": ["/*", "*/"]
    },

     

    Thanks Karl - I'll check that out!

  15. Posted

    11 minutes ago, Muddyfunster said:

    Ran the core today for the first time - superb! E.X.O. ran nicely no issues at all.

     

    I did notice that the colours seem really bright compared to my PAL console and emulation. I probably need to tinker with the settings some.

    Awesome mate 😊

  20. Posted

    On 4/4/2021 at 2:15 PM, Andrew Davie said:

    Probable bug:

    When I do a build via my hotkey (Opt+Command+B), if I'm focussed on a ".asm" window, all works.

    But if I'm focussed on a ".h" window, it gives me the following error...

     

    110755871_ScreenShot2021-04-04at2_14_48pm.thumb.png.36d86e4dc16c03889fc05078ab2d885a.png

     

    Hi Andrew - apologies for the late reply. 

     

    I'll take a look at what's going on there - it may be that it's not using the correct folder/path when searching for the makefile.  One question - any of those files are in the root folder or sub-folders?

     

  23. Posted

    On 3/24/2021 at 2:50 PM, kisrael said:

    I tried to do my part with https://alienbill.com/2600/bbkickstart/ and https://alienbill.com/2600/101/ 

    --I should probably update the second one so it talks about Atari Dev Studio...

     

    Hey @kisrael - would you be ok if I put some links in Atari Dev Studio off to your editors? I'm thinking about adding a new tools feature which will link off to stuff. I may be able to open them in a tab otherwise will open the browser - need to check.

    • Like 2

  24. Posted

    2 minutes ago, quohog said:

    Thanks, @mksmith! I got it working this time by messing with my assembler path settings. It seems like something wiped out the path I was using. Since the path field was empty, it seems like the built-in compiler should have kicked in instead. Not sure why it didn't. Or why my settings cleared. (Would an update do that? )

     

    I was frustrated that I wasn't getting any feedback when I pressed the button--just a dead button. But then I wondered if maybe some output was being generated and I wasn't looking in the right output window. Where would a message about "there's a problem with your compiler," go? 

     

    Thanks again!

    Where are you setting your assembler path setting (is that choosing a custom compiler..)? Generally none of the build VS Code setting will be changed by an update (accessible via the preferences).

     

    As said to work out what compiler is required the required file window generally must be active otherwise I can't work out which language is required.  I might take a look at how that is determined - for example if the output window is active the F5 button won't know what to process.

     

    The output window will show something if it can determine what compiler to use.  The Developer tools log will show something if the F5 is pressed as it outputs stuff from the backend to track (as highlighted in the pic above).

     

    • Thanks 1

  25. Posted

    1 hour ago, quohog said:

    Hi! Thank you for Atari Dev Studio! I use it every day! Not sure if this is the place for tech support, but I'm not sure where else to ask:

     

    One of my most common problems is that the F5 button "breaks." More specifically--pressing the compile, or compile and run, buttons do nothing. Pressing the short cut key, the on-screen buttons, or calling directly from the command palette--none of it works. Sometimes I fix this by just randomly changing things--updating if there is one, restarting, variations on jiggling the handle. But I wish I knew what specific thing I could do to clear this error. Right now it's happening to me and nothing seems to fix it. :(  Any info, or things to try, greatly appreciated! 

    Thanks! :)

    Hi quohog!

     

    Thanks for using Atari Dev Studio.  There may be one specific reason using the F5 Key - make sure the source code tab is active before you press the button.  The way VSCode works it really requires a code window to be selected/focussed to determine which file/language is required.

     

    The other issue my be related to VS Code and/or the extension.  Open the Developer Tools via the help menu and check out the log on the right - sometime it will show an error within the system.

     vsc-developermode.thumb.png.34356bbe15b464ae695dc54721c20fc5.png

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...