splendidnut

To the best of my knowledge most/all ARM based games run on the Standard Harmony so: Seems the most they could potentially use is 8k? ---- Addendum: The majority of RAM is probably used as graphics buffers for fast-fetch use in the display kernel... Example: Chaotic Grill uses 2kb chunk (not all is used... because data is page aligned) for this purpose. This is based on my knowledge (which may be lacking) from working with DPC+ bankswitching which only has access to 4kb RAM.

TIATracker (by @Kylearan) is excellent: Also there's a module created by @mksmith for using the results within batariBasic programs:

Hey All, I've added the source code to the first post. I added lots of comments for the code to the 8 Sprite Kernel. There was a LOT of trial and error to get that kernel working. I've cleaned up most of the mess. There is definitely room for improvement in that area (lots of NOPs). Currently it's quite rigid in that the graphics data is hard-coded, but this could easily be worked around by using the DPC+ bankswitching scheme. There's probably other ways the code can be arranged to make it more flexible; I only stopped because I accomplished what I wanted to do with it. Also, I removed the quick and dirty kernel hack I had to add to fix the PAL version right before posting the binaries. So... the posted binaries are slightly out-of-date and don't quite match the posted source code. I don't think it makes too much of a difference since you all have the source code and can build it yourselves. If need be, I can update the post to have the matching binaries. If anyone has any questions, comments, complaints, please let me know.

After seeing the latest release of Stella (version 6.2) with it's new custom palette option, I figured that it's a good time to release my Palette Demo that I've been sporadically working on. Basically, it displays the full 128 color palette of the Atari 2600 with "hue" and "brightness" labels. I've made ROMs for both NTSC and PAL50. I'll release the source code after I clean it up and add some more comments. Enjoy! paletteDemoNTSC.bin paletteDemoPAL.bin -------------------------------------- Source code (as of 6-9-2020): PaletteDemo.asm

Here's your problem: sta HMOVE sta HMCLR You're immediately clearing out any changes to the HMove registers before they get applied... I believe you need ~24 cycles between sta HMOVE and sta HMCLR. Stella is emulating this correctly.

CodeBlocks is a C/C++ Integrated Development Environment... not really designed for editing and building assembly language programs. If you'd be okay with installing Visual Studio Code, you should check out Atari Dev Studio.

I've been working on and off for the past several weeks and I've made some progress; which can, at times, seem like a lot. Other times, this all still seems to very much be a daunting task. When I started writing this entry, I realized I should probably give a general overview/background of how this compiler works under the covers. Here is a basic outline of the process that the compiler follows: (1) Input files are run thru a handwritten Recursive Descent parser to generate an Abstract Syntax Tree (AST) composed of linked lists with each node in the linked list can be a token (enumerations), a single char, an identifier (string), a number, or another list. Using an AST allows multiple passes with less processing (walking the tree) and easier manipulation (potential optimizer step before code generation) The AST is essentially following "Greenspun's Tenth rule"... a crude, implementation-specific version of a LISP list. (see footnote) There is a semi-implemented, semi-separate tokenizer/lexer utilized by the parser that's implemented in an on-demand way... As parser attempts to fetch a token, the tokenizer checks the next input character and uses that to determine what to fetch. It skips comments and the newline characters (and keeps track of the current line number). It usually returns a string to the parser with a token type... that token type indicator also serves as an indicator of a double symbol (++, --, and the like). Beyond that, the parser is mainly responsible for doing token selection when building the tree. (2) Next the symbol table (list of variables and constants) is generated from the AST. The code walks the tree, finds the variable declaration statements and function definitions, and adds them to the table. It keeps track of 3 different symbol tables: Global, current Function Parameters, current Function Locals. The symbol tables for each function's params and locals are stored under that function's entry in the symbol table. After table is generated, variable allocations are done. (3) Finally, the code generation is done. The code generator is made up of two parts: the AST walker, and the Instruction Generator. The code generator walks the tree in similar fashion to how the parser builds it, walking each node list in order and processing all sub-list nodes first before handling the operation of the parent list. When handling the operations, the Instruction generator is called to output the code, in DASM-compatible assembly language. In a way, it feels like it's been way too long with still nothing to show. I've actually done a ton of work that's only partially visible on the surface of the compiler. I've done a lot refactoring of the underlying code: - I've switched the parser->AST to rely more on using enumerations for tokens instead of string comparisons for operation designation. Originally there were a LOT of string comparisons all over the place; more or less due to procrastinating this rework. I'd like to try and push this more into the "tokenizer" but that's not really necessary... more of a nice to have. - I've filled out most of the code generation code for handling all the operations... although most operations are still 8-bit only. That's mainly because features have only been added as I've run into the need for them. And there have been a few cases where I've put off adding a feature because I don't want to spend the time implementing it... I just want my example code to run. I know, lazy. - I've created a constant expression evaluator that I call at a few different points in the code generator. The most obvious case is when initializing a constant variable. - I've got a full blown inline assembly language processor working. Inline assembly code has access to the symbol tables; it can use variables and preform simple array and structure accesses. I'm currently deep in decoupling the assembly instruction generation portion of the code. I'm working on building an Instruction List module to encapsulate a block of instructions so that I can more easily determine code size for dealing with conditional branching and making sure to only use jumps when necessary. The Instruction List will also help with function inlineing and allow me to finally implement a module system. Currently, only variables are processed in any included files. ------------ Things I still need to do: - implement better variable allocation for local variables. Currently local vars are located immediately after the global vars... Nested function calls don't work well because, for every function, the local vars start at the exact same spot. I need to add a function call tree to finagle that around a bit... that and automatic function inlining... - work on the expression processing code. It's still not quite working for more complex expressions... I have some simple stack-based code generation stuff written that isn't quite working right. Also, there are some complications with conditional expressions that I need to handle. - improve the handling of function parameter passing. I've started with the approach of using just the registers with a hinting system in place. I first implemented this to handle the inline assembly version of the position sprite function. But that's about the only case where it works nicely. That and very simple functions... since the code generation for the functions themselves doesn't quite know about register preservation - pass line and position information into the AST to allow for use when generating errors beyond the parsing stage. Currently I'm only spitting out the AST chunk that contains the erroneous code, which is generally enough for me, but not very user-friendly. - clean up memory management. I'm very loose with memory management for the compiler code itself at the moment. So far I've been relying on the OS to clean up afterwards. I should trying compiling this using an old 16-bit compiler and see what kind of fallout there is on an older computer. ------------------ I'm thinking and hoping that with another month of work on this project, that it should be at a good point for a beta release. I still need to figure out a new name for the project. I've come up with a few so far: - Nimble - It's short, simple, and seems to capture the spirit of this project (easy mixing of C and Assembly) - Elemental -> ElementalC - denotes the origins of the language while also subtly signifying that it's a subset. - Jumble - A bit of humor, since mixing of two languages can end up jumbled together. I'm leaning towards Elemental... but I haven't quite decided yet. ---------------------------------------- (footnote - from wikipedia) * Greenspun's tenth rule of programming is an aphorism in computer programming and especially programming language circles that states: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

I'd be interested in a simple cart both for development purposes and for playing some of the classics. Seems most of the original 7800 games I'd like to use it for don't need RAM (Mean 18 Golf, Rampage, Ninja Golf, Scrapyard Dog).

Agreed... I was just doing a simple fact check/fact correction. Sorry for derailing the thread.

That's not completely true... Example: The PPU inside of the NES is of similar architecture to the TMS9918 and derivatives (separate RAM, data, address buses) and has no built-in hardware light gun support. Light gun processing is done mainly in software using different techniques. One method of detection involves flashing a white filled box in each individual sprite location on a black screen. Each sprite gets its own separate frame, so that the frame number in which light is detected corresponds to the sprite. If light is detected, then that sprite is hit. Works great on CRTs... but things like frame lag cause issues on LCDs.

Huh, when counting from 0, I end up at cycle 48 for doing the update to PF2 (reflected playfield). How are you counting your cycles to end up at 47? Actually... nevermind... it's the whole inclusive bit. You must be a mathematician.

@Nathan Strum That's really cool! It's nice to see the clean versions of those movie scenes.

Or while? Maybe Gotta watch the movie first.

Very nice! Keep fleshing out the game design and maybe a developer will pick up this project.

I've avoiding ARM programming, partially because I just wanted to program in 6502 assembly language. I also wanted to explore within the constraints of the theoretical DPC+ bankswitching scheme. This project originally started without any inkling of what bankswitching scheme it was going to use. Then I moved to playing around with DPC, and almost ending up sticking with that. But at some point, mainly when trying to figure out how to do the burgers, I was attracted to the "Fast Fetch' feature of DPC+. I never moved into the ARM programming aspect as (A) the documented toolchain required the setup and use of Linux and (B) I didn't really see any project using DPC+ as originally thought up. It seemed that once the idea of being able to call custom ARM code was realized, that became the defacto way of using DPC+. So really, I'm trying to explore some weird kind of middle ground of unexplored territory

Yes, Mattel did do the original 2600 port. Yes, this uses DPC+ bankswitching, so does require the Harmony/Melody hardware. However, unlike other DPC+ games, this one DOES NOT use any custom ARM code, only the DPC+ driver. So, it could easily run on other hardware if that hardware provides a DPC+ driver. By avoiding custom ARM code, I'm also somewhat limited in what can be accomplished. That's why the number of enemies is currently limited (both a memory constraint and a timing constraint).

Gameplay is pretty much finished... according to how the arcade works. The only big difference with my game is the bonus item is on a timer instead of being based on burger building progress. I have some ideas for adding my own little twists which I'll allow to be turned on/off and adding some more level layouts. That's part of the drive behind implementing a menu system. While there already is a title screen implemented, NostAlgae37 provided some extra graphics which I'm incorporating into a new title screen. You can enjoy the game right now using Stella... The download links for the latest work-in-progress release are in the first post.

Soon maybe... I basically took an unannounced break from it. And then ended up working on other projects... The game is currently stuck in the "almost complete" state. It really just needs a few things (better title screen, menu, etc.). There's also some under-the-covers work that I want to get done (tweaks here and there). I do have a new title screen in progress that I've worked on occasionally. Finishing this project has been in the back of mind a lot recently. Being as a few other people have also made references/proddings to this project recently... It might be time to try to finish it up.

That's what 160 scanlines of playfield looks like (174 scanlines if you count all the way to the bottom of the score)... Is that what you want or did you want a taller playfield? You can push that upto 192/200 scanlines (would include the score area too) and still fit reasonable well on most TVs. So screenheight = ~92. (would be 184 scanlines)

I believe Albert is currently working on setting up the Downloads section (currently not visible to the public) to allow for ROM purchases/downloads. In the meantime, you should check out this post earlier in the thread:

I take it that Ambidextrous is Robotron 2084?

This feature right here is such a nice thing to have.... I've been using it a lot lately. Thanks!

That's mostly how color works with the Atari 2600 NTSC signal... It produces color by delaying the color sub-carrier a certain amount to generate each different "hue". So the different colors will not align vertically since they will be positioned slightly different horizontally. Have you tried turning down the "Saturation" or "Color" (usually newer TVs) control on your TV? Certain colors tend to bleed quite a bit when the saturation is set too high. Some 2600s have this issue more than others. This is all part of the "charm" of the Atari 2600.

Is this when we start demanding a cart then? Fists pounding, loud chanting?

Just tried it real quick on my 4-switcher and the beast animation is running good now.