splendidnut

For one of my projects, I used the following (Note this does not use PF0... but does use color): mountainsColors: .byte $4E,$4E,$0F,$0F,$0F,$4E,$0F,$0E .byte $0C,$0E,$0E,$0C,$0E,$0F,$30,$42 .byte $34,$30,$42,$34,$42,$34,$46,$34 .byte $32,$42,$34,$42,$34,$46,$34,$32 mountainsPF1: .byte $00,$00,$00,$00,$00,$00,$00,$00 .byte $01,$01,$01,$01,$01,$03,$03,$03 .byte $03,$03,$07,$03,$07,$07,$07,$07 .byte $07,$0F,$07,$0f,$0f,$0f,$0f,$0f mountainsPF2: .byte $02,$02,$06,$06,$0F,$0F,$0F,$1F .byte $1F,$1F,$1F,$1F,$1F,$1F,$1F,$3F .byte $1F,$3F,$3F,$3F,$3F,$3F,$3F,$7F .byte $3F,$7F,$3F,$7F,$7F,$7F,$7F,$7F I laid out the graphics this way so that it's faster in code. I only had to increment the array index once per line instead of once per byte (which would be 3 times per line). Depending on how flexible your want your tool to be, you could pursue doing some sort of mapper which would let the user choose which array was which by the labels. As for other common formats... you might want to look at into adding support for Batari Basic input/output.

I just checked my old Atari power supply -> 9V 500ma. So I'm thinking there's possibly a noise issue with the Retro2600 one.

Just took a look at this today. Very nice! Suggestions: * Add line by line color (you already mentioned) * Add option to output code into separate playfield arrays. i.e. Values for PF0, then values for PF1... etc. Also, really enjoy Studio2600... It's great for finding sounds quickly

There's really no need for the standard C library as I plan to use this mainly to write games for the Atari 2600. While my experience with working on Chaotic Grill (my Atari 2600 port/remake of BurgerTime) in 6502 assembly has been a nice experience, I'd like to try and speed up that process by writing in a higher level language. After seeing how quickly @johnnywc and cohorts brought Galaga to fruition (which was partially attributed to the use of C on the ARM/Melody platform), I figure that my biggest issue with ChaoticGrill had been the lack of flexibility that assembly language provides... There were a few times in which I needed to rewrite large portions of the code to move forward. You may ask: So why not BatariBasic (Bb)? Well, while Bb provides a nice way for coders and non-coders alike to develop games for the Atari 2600... It relies on canned kernels... and it seems to be a little bit of a pain to include/use your own assembly display kernels. Granted this is all from what I gathered from reading thru posts, especially @Karl G's posts in which he does a great service to the Bb community by using his skills to help others in this aspect. Overall, developing this compiler has been surprisingly rewarding. It's been a great learning experience and a good way to help me improve my C coding skills... which have partially rusted since I spend most of my time (at work) in Java/Javascript land. I am hoping that the compiler will also serve the purpose of providing a base compiler for any other compiler related projects I'd want to do in the future. I've been pondering something like a C / Javascript hybrid compiler... which is partially how this compiler project started... hence the name/codename Mocha. TLDR; Yes, challenging and rewarding. Plan to use for game making. No need for standard C library. Trying to solve the problem of slow development time. It's already produced good results (see attachments)

I've been doing some experiments recently...

Mocha/BCA Announcement Usually, the biggest hassle with getting things done for me has always been a lack of enough big chunks of free time to do stuff. Due to the current pandemic, that is no longer the case. Since I'm pretty much home-bound waiting for the weather get warmer, I have a lot more free time to work on personal projects. I've been wanting to announce and talk about my current projects for a while. I'm in the process of developing a C-like compiler focused on generating optimized 8-bit code for the 6502 to use for developing projects for the Atari 2600. There have been a few people that have announced projects like this a few years ago, all of which seem to have stalled out. That's why I'm a bit hesitant to annouce this. I wanted to wait until I was further along, so that I could actually feel confident enough to release a beta-version of the compiler. Currently the compiler does work to a point... As long as the code remains relatively simple, the compiler produces decent assmebler code which can then be fed thru DASM to get a working program. Anything the compiler can't handle, it either yells loudly about (usually syntax errors that can't make it thru the parser), or let's you know there was an error and still produces an assembly file containing all the code it could compile. In parallel with the compiler, I'm working on a game that I started long before ChaoticGrill. I've been able to get a somewhat simpler version of the original display kernel programmed and running in C code. Which shows that, Yes, you can write a display kernel in C for the 6502. The only thing in the demo that has strickly been written in 6502 code, is the Sprite Positioning routine. Working on the two in parallel, while a bit slower... seems to keep the motiviation going as I flip back and forth between the two. While working on the game/demo when I hit a need for something to be implemented in the compiler, I can switch over and implement it. And when I get tired of working on the compiler, I can always switch back. ---- This all came about because I was playing around with a lot of different things the past several months... * Progress on Chaotic Grill has been slow because I'm now at the point where I need to fill in the framework surrounding the game: the titlescreen, menu system, extra features... like SaveKey support. On top of debating whether I want to add anything to the gameplay. * I've been thinking about writing a compiler for a while now. It's something I've always wanted to do, but just haven't had the time or motivation. I've spent some of my free time playing around with some old Turbo Pascal projects, experimenting with old C/C++ compilers, and digging more in depth into Javascript. And that has all led me back around to thinking of developing my own compiler... which led to the root of this project. * I did some experimenting with CC65 and trying to get something compiled and running for the Atari 2600. I was able to get a very simple display kernel working... but only after I started hacking away at the CC65 code base, adding my own code optimizers into CC65's vast optimizer code base. There was some success... but it was a bit of a painful process. Ultimately I came to the conclusion that, while you could do a project in it (other's have... Robo Ninja Climb / https://atariage.com/forums/topic/280856-robo-ninja-climb-atari-2600/ ), you kind of had to jump thru hoops to do it. * I attempted to experiment with the C02 Compiler (https://atariage.com/forums/topic/267074-c02-compiler/), but it appears there's a very constraining identifier length limit (6 chars!!!!)... which the codebase itself adheres to also. After trying my previous efforts hacking away at CC65, I was not about to do that again.... There were also some other reasons, but I don't remember what they were. This was the final push into developing my own compiler. ---- For the most part, the compiler I've written trys to following somewhat closely with the C89 (Ansi) spec. My main reference has been "The C Programming Language: Second Edition" by Brian W. Kernighan and Dennis M. Ritchie. I'm probably not going to implement Preprocessor stuff... I currently have one, it only processes the #include stuff (in a very hacky/not quite implemented fully way), but I'm debating just pushing that into the parser itself. I will not be one to enable "macro abusers" Constants are currently implemented and working, and I'll be adding either a manual or automatic function inliner. Both of which are usually what macros are used for. I've greatly simplified the variable declaration stuff. Only handling 8/16 bit values, pointers and arrays. The most complicated thing you can create is an array of pointers: char *gfxPtrs[5]; So far, I've found this to be sufficient. I've yet to implement one of the features I'd really like to see: Inline assembly. It hasn't been done yet, mainly because I'll need to write a parse/code generator for that. i.e. Lazy... I've got my position sprite routine... what more do I need? Uhh... a score kernel... So far, the compiler mainly deals in byte-based operations... there are a few things that can work with integers (mainly for the current pointer support), but for the most part, the 16-bit support is missing. For comparisons, signed/unsigned-ness has generally been ignored, mainly because I haven't used it that much. ----- Overall, despite that half-implementation of most things... I've been slowly adding features to make the compiler ready for general consumption. Or at least tolerable. Since I currently don't know when I can throw anything out there, I decided to make this a blog post instead of a general announcement. Oh... and here's two binaries. One of the original game project in ASM (pre-ChaoticGrill), and one of the C reimplementation using the aforementioned compiler. And might as well throw some C source code out there too. Feel free to ask questions or comment. --Philip bca-asmEng.bin bca-mocha.bin bca.c

Short answer: Programming tricks. If you want a more elaborate answer than that, please provide a screenshot/example of what you're talking asking about. (be more specific)

Of note, ChaoticGrill currently uses DPC+ without any custom ARM code... but it does not use all of the features available (mainly, the music/sound features).

For DPC and DPC+, a good resource is the Stella source code. DPC was (to my knowledge) only used for Pitfall II. The patents are probably the only "official" documentation of that scheme; though, I believe there is a mapper doucment out there somewhere that goes over the registers used. Asking @SpiceWare is probably your best resource for DPC+ information. Note: almost all of the DPC+ games require some kind of ARM CPU emulation also.

The Atari 2600 Cartridge slot has access to ALL the address lines of the CPU. So it can see what is written to any address in the 6507 address space. As can be seen in the schematic: https://atariage.com/2600/archives/schematics/Schematic_2600_Low.html

Short answer, no. Even/odd fields are controlled via mid-scanline change in the VSYNC signal, not VBLANK, which just turns enables/disables the display. But, there is also quite a bit of setup to do a "proper" NTSC 480i signal.

I tried to take a picture of my NTSC CRT for you, but it appears it doesn't run on a Harmony Cart.

Yes.

In Barnstorming, take note of the black strip along the left side of the screen. For Barnstorming, the HMOVE register is strobed on every single line during the display kernel which causes that black strip to appear. Something along the lines of (quick example of a two scanline kernel): STA WSYNC STA HMOVE ;-- code to run during scanline STA WSYNC STA HMOVE ;-- code to run on next scanline

Indeed it is... but that doesn't fix the issues of "Compile" and "Compile and Run" buttons (and the keyboard shortcuts) doing the same thing. It's these simple things that are the difference between good and great.

I thought a developer was always responsible for configuring their environment? Yup, that worked, thanks! I'm a bit surprised you went with "makefile" instead of "build" as you specified earlier. But I take it this was just a test run of the feature and it will be developed further? And I'm guessing that until you implement some sort of project file system, it's a no-go on having Stella automatically launch when using the "launch" button. Which is OK, since Stella is generally just an ALT-tab away.

Don't get me wrong, I like it (Visual Studio Code)... just wish it did more out of the box. (project management -> allow me to select what files are in a project, and which is the main file for assembling/building/compiling/etc...) Ultimately, I don't know much about Visual Studio Code as I only downloaded it to be able to try out the Atari Dev Studio extension. I've been poking around trying to learn more, but right now, it is still easier for me to leave a command prompt open to run my build with. I've only put in my request for supporting build scripts directly in Atari Dev Studio after seeing how quickly @Andrew Davie's request for make support was implemented. Outside of those issues, I have no complaints. @mksmith This is a nice little extension. I look forward to future development of it.

Happy to hear you're enjoying. Maybe someday I'll finish it.

For executing script files, I'd think it'd be better just to have a setting/preference instead of the app auto-magically scanning for a "build" script. This would give the user complete control over. Visual Studio Code appears to track settings separately by user, workspace and directory. With directory given the highest priority. Though it is a shame that there is no project support in Visual Studio Code... that really makes me question the purpose of it, as that makes it just another multi-file text editor with syntax highlighting, something we already have plenty of. We need more "project-management" based editors! Maybe it's just me... asking too much of the software I use Anyways, thanks for looking into the matter.

Any chance you can add the ability to set and call a custom build script (Windows batch file or Linux/Mac shell script) as opposed to the makefile? I already have build scripts written, and I really don't want to have to go thru the process of migrating over to make. OR... give the user the ability to set which file is the main file in a workspace for running thru DASM? I dislike having to find and switch back to my main assembly file (multi-file project) every time I want to build and run. Thanks.

I just tried the test program out on my NTSC standard CRT TV (circa 1997) and it doesn't roll there. But of course that doesn't mean much as TVs are generally designed to be as tolerant as possible. The only thing I can think of is the Overscan timer is expiring too close to the end of a line. Sometimes it hits before and sometimes it hits after causing an occasional extra scanline. So you may have found an edge case in which Stella (maybe the RIOT emulation) might be slightly off from real hardware.

Says the man that wrote PHP code that almost looks like exactly like C

Using AverageSoftware's code, it appears you only need to change the one method: unsigned char string_to_byte(std::string value) { unsigned char byte = 0; std::for_each(value.crbegin(), value.crend(), [&byte] (char c) { byte <<= 1; if (c == 'X') { byte |= 1; } }); return byte; } And that should solve the huge number problem.

Any reason why you can't just ask @Sprybug?