Mr SQL

Great thread! The 8 year olds in my test groups here had top two favorite games being Ms Pacman, and KC Monster Maze; they did not care for Junior Pacman because it was much too hard. I agree and don't think you are stereotyping; in Israel we teach specially gifted children to protect from an early age and it's important the shooting games and simulators should be carefully designed from a gender neutral perspective.

Yes it can; we just need to think outside the box a bit which we are already doing with the design. The ARM can run an emulated TIA and RIOT if we include an HDMI video out on the cart like the Retron77 has - I'm part of the development team for this console and it would be interesting to see both combined into a streamlined dream machine or just heavy concept material, you know what I mean. This will allow the best of both worlds on the console and even regular games would be "improved" with reduced flicker via 6 player sprites and missle sprites instead of 2 if we set the more powerful TIA to merge 3 frames. If the player wants to play a classic Atari game like ESB or one of the newer games that doesn't work well with merging TIA frames, they can just unplug the cart with the enhanced TIA and use the default TIA. And programmers can use it for contest where the souped up TIA isn't allowed; the default TIA doesn't merge any frames but we can do some really cool tricks with it

X2! Awesome - and definitely the most fun. It's good to see programmers taking different paths and approaches for emulation instead of reusing the same codebases. You miss out on a lot otherwise particularly on solving the puzzles with a different approach

Sure I agree don't implement take-back but the player should still be able to cancel the move if they change their mind before they finish the move because this is pretty standard in Video Chess and ChessMaster, everyone is used to playing computer chess that way and can play a better game with that feature kept on. Increase the challenge by hiding the board between moves instead - some trippy Lava Lamp demo's between moves would be really cool if you want to one-up the Video Chess mood ring effect!

All excellent points about the kernels and trade-off options present in bB and what can be done custom in Assembly - Also a great point that bB loses fine grain control of the scanlines, accessing the full width of the playfield or the drilldown to the individual scanlines that comprise the frame that you get with custom asm. There is a third option with the Atari 400/800 where BASIC and Assembly programmers can use the ANTIC chip to marshall sections of the screen with display lists, which are lower level than the whole frame, but higher level than the individual scanline and give the BASIC or the assembly programmer a lot of extra functionality for making the cool A8 and 5200 games we have seen - the ANTIC chip is indeed much like an ARM from back in the day in this respect. SuperCharger BASIC gives you the option to use Display lists like the ANTIC because the soft blitter chip has similar functionality, here's a simple BASIC example where the playfield is splitup into three different sized zones, each with it's own playfield CAM and display list calls, you can control the ship a bit with the joystick and it's influenced by the physics in the different zones in this demo: http://javatari.org/?ROM=http://relationalframework.com/Flashback_BASIC_DLI_Demo.bin&SCREEN_FULLSCREEN_MODE=1 It's pretty cool because it gives BASIC and assembly programmers a way to go lower level and program variable sized sections of the frame still racing the beam necessarily because all sections are within one frame, but at a more abstract level marshalling variable sized blocks of scanlines at a time for bit blasting. And it's alot simpler and friendlier to the BASIC programmer than working with the more powerful display lists on the A8. This is also an example where the SuperCharger BASIC program was cross compiled as CBS RAM+ format for the Atari Flashback Portable, with no changes to the BASIC program, I'm working on an A8 version of the cross compiler as someone pointed out CTIA/GTIA is similar enough and should be able to accomodate my soft antic to run "Atari 2600 games" on the A8 with no changes to the BASIC code - what will we call them, SuperCharger games, CBS RAM+ games, soft antic games? Interesting stuff...

To get 100% of the playfield give SuperCharger BASIC a try for performance greater than regular asm due to the soft blitter and somewhat closer to the ARM, or the BoulderDash construction kit if you know asm. The ZeroPage show will need to turn off merge frames and phosphor on their emu to properly display some SuperCharger games though - this setting gives the ARM games an unfair boost. In Gdansk, they used an authentic CRT for their show which can tilt the playing field in favor of legacy reto techniques like artifacting and low pass filters.

Awesome fun, my grandmother was also from Poland! That's a bit dramatic, I think you like hyperbole; there are fans on another thread kicking Tod Frye but I don't see that happening here. AW127 is not insulting anyone nor is the SillyVenture party insulting the ARM programmers or Nolan's any platform goes Atari games group either; they want the code to run on the actual hardware and not on a chip from the future, they have the same point. Here's something folks may find interesting about consumer perception when there was a big market bitd - I really did write a fake "ARM game" for the color computer just for pure marketing reasons (no satire this time): I made this fake "ARM game" in 1986 that supposedly ran on the next generation superchip in the CoCo III, not technically an ARM, but it could move and push memory in 8K chunks to overwrite any section from 512K of RAM in a manner a whole lot like bus stuffing and less like bank switching - you could do a lot more incredible things that were a lot harder or could not be done without this special chip. I couldn't use the chip very well since I had just got my hands on it but I knew marketing so I scraped a hi-res standard 256x192 CoCo screen I had done with artifact colors and transposed it as a 320x200 16 color screen without artifacts using the new chips graphics output but completely unnecessary. I added digitized sound to the demo and a Max Headroom effect using a CoCo kit I had for homebrew developers to add digitized sound clips to BASIC - none of the software I sold required the "ARM" including the digitized sound kit, only the demo and it was a fake because I could have used the standard screen with the artifact colors and it would have looked the same or better, I went for the characteristic graphics look of the new chip for marketing only; the demo was free, no way would it have required the CoCo III "ARM" if I sold it. Of course if I could have put the ARM in the cart and it wasn't bundled with the CoCo III then that would have been a different story, but the only CoCo III software I sold was deliberately CoCo I/II compatible too and would trick out extra features, but never exclude 90% of the market share - that was the marketing rule. It should not matter what is in the cart from a marketing perspective, except for niche markets where more authenticity is desired. This can be any collector or any contest.

The SillyVenture party in Gdansk doesn't allow modern technology in the Atari competition along similar lines - Gdansk is an awesome town and I loved the salt mines when I visited, memories of the swirling underground rivers a mile below ground flowing with sparkling pastel colors influenced my Breakout2002 entry and possibly, whomever wrote Zork. Take a look at the party - these guys are uber nerds having tremendous fun! I wouldn't mind if they allowed the ARM to compete but I understand the authenticity being a reason to disqualify it from competition for not being a contemporary Atari technology even though it fits in the cartridge port: There is also an international BASIC 10 liner competition that bB cannot enter because of the form factor, SuperCharger BASIC has an old-school mode for folks that like to write classic BASIC just like in the 80's that is compatible with the contest. I think these perspectives are both just as valid as Nolan Bushnell's latest take that any system can be used to create an Atari game.

X3, agree the ZeroPage crew should not be calling anyone trolls - now I'm not going to release my new ARM game until they apologize; ok they did just as I was typing this good I'll be releasing this one in France on schedule then as Berzerk Friendly Fire - I thought it was a cool pun for game to bear ARMS; there are actually twin processors in the special cart but it's not a double ender. One processor handles the sound like the DPC chip in Pitfall II, and the other faster processor runs the gameloop in ARM assembly so there is enough time to render game through the TIA: Can you spot the fake? I added a tape loading intro to this to pretend it was done with 6K SuperCharger graphics, but a lot of people are able to clearly spot it as game all about ARMS...

Good point ... It just means he doesn't consider them Atari games; the opinion is just as valid as yours and doesn't deserve the rude/ignorant insults or the curses that followed it from the other posters. So I'll ask what do you think of all those "so-called Atari games" we wrote on other systems in the early 80's? The hardware was all commensurate for the timeframe and didn't include a modern processor to run the gameloop on, although some of those systems had a more powerful contemporary CPU and more RAM. And what about Nolan's "so-called Atari games". Those include ARM games and also games on any platform under the sun provided the game is easy to play and difficult to master? I agree with that and don't consider ET an Atari game by that definition, and my definition is even more liberal since I think Double Dutch on the playground is an Atari game...

I think it has "blatantly similar features" like KC but extends the genre, also like KC.

Very cool, 4 pixels is just enough for a blocky Archon/Chess set. Your Chess code has characters 5 pixels wide and looks like more with the shading, could do a better Archon. Looking forward to seeing someone build Archon with either of these engines! Didn't you write the NES port bitd?

Interesting perspective, on perspective lost over time. If we take the Delorean back to the early 80's our perspective increases commensurately: We all wrote Atari games to the extent the system had the color and sound to support them. And, some of the games written on the Atari weren't Atari games.

I disagree, we were all writing Atari games in the early 80's regardless of which system we wrote them for - these seven pacman posted earlier, were all Atari pacman: KC Munchkin was also Atari pacman despite running on another system and taking the genre to the next level; it was indeed even more of an Atari game than Atari's Atari pacman. My favorite ports of Pacman are KC and the Grabber port above, and both are Atari 2600 games. There are games like ET and Raiders of the lost ark that are not "easy to play and difficult to master" - these are not Atari games according to Nolan Bushnell, yet his definition is very liberal and Atari most recently specified "any system" in their last contest. This also makes Double Dutch on the playground an Atari game; the concept is very broad and yet ET cannot prepare to quality like Pitstop and Enduro. Back then there was a demand for Atari games as Nolan defined them and most enjoyed pacman and Yars but returned ET; we knew whenever we had succeeded in writing an Atari game, because it sold really well - it didn't matter what system we wrote for beyond the userbase market size. Some companies got smart and wrote their Atari games for all the systems, maximizing the market size.

Those are the characteristic reactions of an artist, when someone doesn't like their art. With millions of fans, not everyone will be pleased. An angry Pacman fan confronts Tod Frye a retro gaming expo.... I created a very liberal port of KC Munchkin for Atari a few years ago that most players loved, but there were some fans that were equally outraged at the variations from the original: Of course I continued to make the port different with the computer taking over control of "Pacman" if you let go of the stick, and a larger maze with screen scrolling like Jr Pacman; I don't like Ms Pacmen that scroll so I understand the resistance to the idea for some players, but a fun variation can be a lot like Green eggs and Ham; you have to try it and you may like it even though it's different. With this example the original author, KC's Dad Ed Averett loved the new variations and seeing it on the Atari 2600, and his encouragement was really awesome, because I'm one of his biggest fans Along those lines I wonder what the author of the original version of Pacman, thought of Atari Pacman. It shouldn't be too hard to find his commentary from bitd and I bet it was favorable!

Interesting observation - I have created efficient BASIC cross-compilers for the Atari 2600 SuperCharger and CBS RAM+ and I am working on creating a cross compiler for the Atari 800. If I get them running on the A8 and 5200 these will still be Atari games across Atari platforms unless I can write one for the C64... "Atari games across all platforms" is what you are describing which was Nolan's vision for the 2012 Pong Challenge - any technology could be used to create the Atari game. The other way around was allowed - the Atari 2600 could be used too. The other entries were all modern platforms creating an Atari 2600 look and ambiance for the game. What do you think of the first Flashback that offered players Nintendo Atari games? The idea was similar - to have the games dictate the technology using the "more powerful" Nintendo on a chip technology as the expressive medium to create a better looking Atari 2600 experience updated for players today. I think the Pong Challenge worked better with your concept for having a large user base from the phone games with indirect cultural influence from Atari, as compared to the market segment that wanted an Atari Flashback and didn't get the memories they had expected/remembered with the games.

Atari considered Frye a 100M commodity and did not want to lose him!

All good points but when Atari treated young programmers like rockstars they took more pride in their work and were more liberal with their artistic vision.

Atari was losing control over the market and losing some of their best programmers was part of that so they were treating them better and much more respectfully as artist rockstars; Tod got a millions dollar check for being an artist vision as much as his programming prowess. I like his artistic vision for the port but I can understand some people wanting a more exact arcade port and less abstraction who may not like artistic variance. Eye of the beholder applies as well; not everyone likes the same painting or style...

X2! I get the most power in the soft blitter games that halve the Hz and steal an entire extra frame for calculations. The alternate method is to blit sections of the screen from BASIC with display list calls made from either vertical blank to get enough time, and it uses up most of it leaving very litttle time per frame for the gameloop. There's so much potential here with the ARM pushing 60 FPS dynamically coupled with complementary techniques like BD queue illustrates to dynamically split tasks across frames using the TIA/6507 side if we want to keep the gameloop there. Gameloops on the ARM are interesting too of course - it opens up c as a high level language for Atari games which is another cool factor as we don't have as much overhead on the 6507 and can realistically only use Assembly or compiled BASIC for the smaller footprint memory sizes to get the most power. That's another interesting point - some programmers prefer to write Atari games in c; I love BASIC, but a lot of modern programmers grew up on c and java syntax and it's great that the ARM makes more development choices possible; no doubt there are or will be fun Atari games where it was a matter of preference more than performance for the author to write the gameloop in c on the ARM vs BASIC or asm on the 6507.

The default setting for the Retron 77 community build actually break some Atari games including some of the bundled Retron 77 games that I've developed on the real hardware without Stella as batari described earlier, we've worked on bugs that can only be found this way as well. If you try Fluid City on the Retron 77 after disabling merge frames and phosphor which also merges frames, it will almost work like the real hardware but it flushes a remaining Judder bug that can be seen intermittently; I don't see this on my PC with Stella or Z26 so it's likely close to the hardware limits on this hotspot. And if you use the option menu to tag the game as a PAL60 game it turns from Fluid City into Judder City - that code branch needs more attention. SillyVenture used real hardware where the game and the demo effects work by default however Atari Pacman has flickery ghosts by default; Stella solves the flickering ghosts issue by default but lowers the effective frame rate possible by whatever factor you merge frames by.

LOL, I love that awesome mix! 😎 What kind of music will inspire your Heroes?

How close does the generic BD engine come to handling enough unique characters to render Chess or Archon? Can it be added to the engine and/or could the new code be used as a similar kit engine?

There have been some discussions on creating compatible routines, it would be really cool if you could abstract the Chess engine to support both flashcarts.

Awesome perspective! "If real programmers today wanted to be authentic..." Fluid City and KC Monster Maze were created using a 1981 Arcadia SuperCharger and real hardware as you described. KC was indeed an underground success and Fluid City took 1st place at SillyVenture 2019. "You'd program on an Apple II or A8 or other system available back then..." I think you will find this very interesting - I was an advanced programmer in the 80's who didn't just write video games, I also wrote tools for the homebrew community that wrote games in BASIC just like today, but the BASIC games were slow and did not compare to Atari games (we called all video games Atari games until around 1984, the VIC-20 and CoCo were initially marketed as Atari's you could program as well as play Carts on). I expanded the graphics and sound capabilities of Microsoft BASIC so that homebrew programmers could use ASCII art designers to draw the sprites like bB, and use sound designers to embed digitized audio clips and manipulate the sound Fx in BASIC; I had a column in the mags to teach these concepts and I demo'd them at Expo's to pack the booth and turbocharge sales of my software while giving away the free dev kit. With the knowledge I have Today, I could use an Apple II, A8 or Color Computer to port the SuperCharger BASIC compiler and I bet you could do the same with batari BASIC. We grow nerdier over time - 10,20,30,40 years later and we find ourselves writing things we only dreamed of in the 80's. "It's important to note that for *any* current, complete ARM scheme, such as DPC+, CDFJ, take any screenshot of any frame of any game screen, whether it's Stay Frosty, Galagon, Mappy or whatever, and you could program this static screen to display this single static frame without using an ARM chip at all. Probably even in 4k. Without the ARM, the difference is that the 2600 is not powerful enough, computationally, to produce these screens dynamically, i.e. 60 frames a second." It is powerful enough - I wrote a soft blitter chip that can ouput display lists to control sections of the screen like the A8. Reviewers have confused the games with ARM games. Try the demo's listed here in Fluid City and see what you think; I haven't seen any ARM games blit 60 FPS dynamically yet but it certainly has the potential to exceed a soft blitter written in 6507 asm. Emerging Blitter Technology BoulderDash blitters wonderfully using just the standard technology by using a great deal of memory with an ingenious array of kernels. Sokobon and the new Chess display are great examples where homebrewers can start to use these technologies in a development kit. The ARM appears to be used as a bit-blitter in some ARM games though not always general purpose - with the gameloop running on it I percieve this as driving the TIA and the 6507; with DPC+ bB I would consider the ARM to assist as a co-processor because the gameloop still runs on the 6507. The BD kit has a 10x10 pixel Camera with a large virtual world, tile mapping and definable character graphics that can draw recognizable objects using the playfield, while SuperCharger BASIC has a 20x10 CAM and lower res playfield character graphics. It would be cool to see an ARM based blitter throw out a 40x40 pixel CAM with the virtual world, tile mapping and higher res character graphics - Maybe Batari BASIC with just the blitter running on the ARM? This could be an extension like DPC+ bB since with a blitter only the blitter need run on the ARM and not the whole gameloop. Perhaps the 30x30 bB playfield that fits in the 128 bytes of Superchip RAM could be blitted by the ARM with very little changes to bB...