splendidnut

Yes... because they rely on different palettes. Stella has multiple palettes to choose from. So far I haven't see any emulator palettes that exactly capture what I've seen on my TVs. Stella has come close to matching my LCD TV, but not my CRT TV (understandable as CRTs have that nice glow that no one has captured yet). (This is all based on my experiences with NTSC consoles) The Atari 2600 color generation is a bit loose, users are able to tune their consoles for colors to their liking. $1x is almost always yellow, but relies mainly upon a TVs tint control setting. $Fx is dependent on what the user has set the color delay control (in the console itself) to, which usually ranges from a greenish yellow to a brownish-orange color. Brightnesses can vary a bit also, but not as much. Looking at the palette in the link you posted, it looks wrong to me... I've never seen $4x as a nice red with having $Fx as brown. Usually $4x being red involves $Fx being green, and if $Fx is brown, then $4x is more of a magenta color. Usually I end up using $3x for my reds. If you are a perfectionist in colors, take a deep breath, you're in for a ride

Also looks like you have timing issues (or something more elusive) going on with the numbers in the upper left.

Well, you do know that the colors will vary from console to console and from TV to TV right? NTSC = Never The Same Color

For NTSC, the "hue begin point" could almost be considered static but can be changed via a user's TV Tint setting. I've also noticed that this can vary slightly between the different 2600 versions. i.e. Same tint setting with two different consoles can have a slightly different hue for $1x: golden rod vs. a slightly lime yellow. Console warm-up doesn't seem to have that much effect on the starting point... but it can greatly affect the end point. The $Fx hue on my 4-switch Vader starts as a green and finally settles into it's final brownish/orange color after a few minutes. Awesome that you are looking into this! This is something I've been thinking about playing around with for a while.

As long as you maintain a consistant scanline count and are doing VSYNC properly, you should be okay.

I fiddled around with the enemy swarm... You can make the enemy bee swarm a bit bigger if you replace beesAsMissile with the following: beesAsMissile: .byte $00, .byte $00,$22,$D2,$32 .byte $00,$E2,$32,$D2 .byte $00,$22,$D2,$32 .byte $00,$E2,$32,$D2 .byte $00,$00

Have you tried using Stella?

Just realized that since I'm not going to allow assignments in expressions (in other words, I'm only allowing assignment statements), that probably helps alleviate some of the use cases that would otherwise require semicolons.

Alright... I spent quite a bit of time and merged the two codebases together (my killerbees9.asm with killerbees10.asm). I had to fudge around with things for quite a while, but I managed to get a rock-solid 262 scanline count. I fiddled around with the RIOT timers and made sure EVERYTHING was wrapped: vsync+vblank, overscan period AND the display kernel. I removed all the old overscan tweaking code (OverscanValue) and the old display kernel counter (ScreenDrawing). I moved the "wait for overscan" into the beginning of the VerticalSync routine so that code can be executed in the overscan region. I also wrapped the display kernel in a timer just to be safe. I kept the bigger side boxes with the technique to "hide" the HMOVE bars and I also changed the top one to match better. Also did some code cleanup (rearranged somethings). Let me know if you have any questions. Enjoy! killerbees10_pb.asm killerbees10_pb.bin

Yes, zp is placeholder name for a variable that needs to be in the zeropage (Atari 2600 memory is in the zeropage). You need to add it in your variable table... and you should probably rename it something like enemyRoutinePtr to clarify it's purpose.

By the way, here's a different take on the side boxes... using a slightly different display kernel that has a few more cycles available. And I think that gives enough cycles to add in the other missile (or ball) if you have a use for it. Slight bug though, the Arena is slightly bigger and I didn't change bounds checking for the beebot/bees, so they don't quite hit the full arena. killerbees9.asm

Sadly not.... Missile 0 uses/shares the color of Player 0... and Missile 1 uses/shares the color of Player 1.

Yup, currently semicolons are optional. I set it that way when I was debugging some parser issue and then just never removed the conditional check for them. Seems to work good for now. Although there are probably a few potential issues that will have to be dealt with from not enforcing them. I'm still in the early stages of adding error reporting in the parser and am leaning towards a "one and done" since any syntax error can throw parsing completely off. While enforcing semicolons would allow multiple syntax errors to be reported... I grew up with Turbo Pascal so I am very used to the "one and done" error reporting I'm not sure how helpful it would be to have multiple syntax errors thrown. My experience with various C/C++ compilers was that it wasn't really helpful since anything beyond the first error could be a false positive due to the first error. Currently I'm using a hand-written recursive descent parser with no look-ahead. I've thought about adding look-ahead, but I haven't run into the need for it yet... and that might just be because I'm only doing a subset of C. Or that might more due to that being a "grammer to parser" parser generator issue... I'm really not sure.

Welp, got both techniques working... It's a little sloppy, but it works. The display kernel could probably be cleaned up/reworked to hide the HMOVE bars on the left. The bees could probably be tweaked to be a bit more consistent also. Let me know if you need help with that. killerbees5_with2setsOfBees.asm

I tried throwing it in there, but with the current display kernel design, it will take a lot of work. BUT I was able to get your current setup working. I modified and added to your bee graphics and added a random offset. Code attached. killerbees5x.asm

Here's a way to do a swarm of bees using a missile (labeled as mist here): mist: .byte $00, .byte $00,$12,$E2,$22 .byte $00,$F2,$22,$E2 .byte $00,$12,$E2,$22 .byte $00,$F2,$22,$E2 .byte $00,$00 ;-- setup index into mist pattern setupMist: LDA mainTimer LSR LSR STA mistCnt LDA #16 STA lineCnt SBC mistCnt STA mistCnt ;--- loop to draw mist mistLoop: STA WSYNC STA HMOVE NOP NOP NOP NOP NOP LDY mistCnt LDA mist,Y ;-- load mist pattern STA ENAM1 STA HMM1 DEC mistCnt DEC lineCnt BNE mistLoop ;-- clear mist LDA #0 STA ENAM1 STA HMM1 mainTimer is a variable that counts to 10 before resetting to 0. It increments once per frame. NOPs are there to provide separation between HMOVE and HMM1 to make sure HMOVE is not interrupted. This is the same technique I use in ChaoticGrill to create the pepper spray.

Fair enough @RevEng. In my bit of research, adding kernels to BatariBasic was not obvious to me... that is a pain So I looked around a bit, and came upon your title screen examples and it seems "easy" enough. Maybe it's just me, but it doesn't seem "Basic" enough. (quotes are for laughs) To be fair, I'm not going to magically solve that problem here either. Display kernels, for the most part, will always have to be written in assembly. Until someone proves that wrong... (Note that I'm not including my own sloppy example above). My goal is to reach the middle ground between Batari Basic and Assmebly. By it's very nature, a C-like (or any Algol derivative) language falls nicely in that area. Over the weekend I've added code to my compiler to handle inline assembly (in a better way than CC65... similar to KickC), which I personally think makes it easier/more flexible to add/include display kernels than in BBasic.

If you add these two lines after CLEAN_START: lda #88 sta Rand It will fix the randomizer not working issue by providing the initial seed. (any number other than zero will work)

Where do you seed the random number generator?

No. The Atari 2600 TIA chip only keeps track of a single horizontal line. It relies completely on the programmer to keep track of the vertical signal and to initiate the Vertical SYNC (VSYNC) signal at the appropriate time to have a steady television frame. In this particular case, he is not, because the CPU is spending ALL of its time thinking about chess moves. While the computer is thinking, the video will roll on an old CRT TV. To implement a simple thing as a blinking cursor would require a ton of work. Andrew would have to utilize the RIOT timers AND insert a ton of code to check them. Ton of effort for little reward. I think his solution here is perfect as is. Deal with it.

Yes I have. The KickC developer and I appear to have similar ideas (like how inline assembly blocks should work). The big difference is KickC requires Java (it's written in Java) and mine (written in C) does not. And semicolons are optional in mine

Yeah, it doesn't really interfere with the current parsing... but it did seem to interfere when I started playing around with simplifying the parser to take care of the whitespace issue. I kind of dropped playing around with the DASM source code because of this. I feared I wouldn't use a light hand and would have ended up with my own separate fork or my own personal version. I figured that I was used to working around the whitespace issue so in the end it's really not a big deal. Always interesting to dig into the history of projects like this. I'm wondering if he (Olaf) had a specific use for it, like maybe interfacing to some external piece of software. I'm also wondering if he'll point to this as more of a reason to have merged the code bases in his suggested way: https://github.com/dasm-assembler/dasm/issues/20 Thanks for looking into this. It'll be interesting to see if/when/how Olaf responds.

I found that syntax a while ago too... when I was looking at the DASM source code to see what it would take to: * Fix the issue that labels can't have whitespace at the start of the line * Fix the issue that cpu instructions and psuedo ops REQUIRE space at the beginning of the line (not that much of an issue) If there is no need/historical use for the '^' trick, my personal opinion is that it should be removed. I think it would help alleviate some of the weirdness of the line parser.

I don't really have much experience with Batari Basic either. So I'll let someone else speak up if they want that.

I was thinking there can be controls on the side of the import box with drop down selections. When the user pastes into the import box, the labels are detected and the user has to select the mappings. Something like: Map to PF0 ( dropdown with labels ) <-- list of labels includes (none) Map to PF1 ( dropdown with labels ) ... The labels can be detected either as a line with just an identifier string (alphanumeric, '_') with a potential '.' as a prefix (DASM local var indicator) and a ':' as an optional suffix (I think the colon is optional in DASM label). For output, it gets a bit tricky... you might need a different control panel to handle the situation of new/first playfield (no mappings set) which has text input fields instead of the dropdowns.