kisrael Posted January 10, 2018 Share Posted January 10, 2018 (edited) Hey there. I've been involved in Atari 2600 development for a long time, but with long gaps. In 2003-4 I made JoustPong/FlapPing in assembly, and I made the "2600 101" tutorial. A few years later I helped make some of the early Batari BASIC pages, and was the first moderator around here. Then - nothing. (Somehow even back in '04 I got the feeling Albert understands that people come, people go in this field (and so do URLs sadly) - though there are some people, and some sites, who seem to be eternal stalwarts) But in 2015 I did a Batari game for the Global Game Jam Loaded4Bear - you can see a page on its development (over a weekend!) here: http://kirkdev.blogspot.com/2015/02/programming-atari-2600-part-ii.html ANYWAY. I've kind of lost the narrative of what's going on in Atari homebrew. In my absence, Facebook has arisen, and I'm part of a few groups here and there, and sometimes I see some truly astounding homebrews every once in a while. Sometimes I get a hint that really amazing stuff is being done largely in bB - or at least sections? Maybe as a prototype or something, but with a custom kernal? (Admittedly sometimes it's tough for a game to break out of a "this was clearly made in bB" feeling..) The AtariAge forums are frustrating sometimes, because some of the stuff is so old, and it's side by side with more recent activity - and also you have some threads that are like over a decade old, but every couple years someone picks up on, and that's where some of the most recent posts are. So... what's going on? Are people floundering? Making great strides? What's the size of the code-in-Assembly vs code-in-batari-BASIC vs code-in-some-hybrid communities? If nothing else I hope to update the "start here" pages and links, especially now that bataribasic.com is no more. Edited January 10, 2018 by kisrael 2 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted January 10, 2018 Share Posted January 10, 2018 Back in 2014 I did Collect, a tutorial that documents the creation of a 2K game using assembly. On more advanced fronts cd-w and I created BUS, a new driver for the Harmony/Melody that acts like a coprocessor (think Pitfall 2's DPC) and implements bus stuffing. We did a number of neat things with it, but due to it failing on a number of systems we haven't pursued it further. Multicolor Tile based display using BUS We took what we learned from that and applied it to DPC+ (the coprocessor, not bB's DPC+ kernels) to create a new coprocessor called CDF. Most features of CDF are covered in this blog entry while Fast Jump, a late addition, is covered in this one. So far CDF's been used in released games Draconian and Super Cobra Arcade, as well as the forthcoming Mappy. And to tie that back to Beginner Programmer, I'm planning to create Spice C, a framework like batari BASIC that uses C instead of BASIC for the game logic. Like bB it'll have prewritten kernels, though they'll all be using the new CDF coprocessor. I plan to start in on this framework in the next few weeks, just have a couple things to take care of first like porting Stay Frosty 2's music driver from DPC+ to CDF for use in Mappy. 7 Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted January 10, 2018 Share Posted January 10, 2018 I've been working on a new driver for the Harmony/Melody hardware that makes it possible to offload some of the processing in between servicing the 6507 bus. This extra processing power makes it possible to compensate for the systems that were not compatible with the BUS driver. It's still in the early phase of development, but eventually should make it easy to program the Atari in C/C++. The entire game including the display kernels can be written in C/C++. Currently I have a working prototype of the dev environment which enables source level debugging via visual studio. Then when it's working you simply build it for the Harmony hardware and copy it to an SD card for testing on real hardware. Once it's stable enough I'll be releasing the entire suite of dev tools including all the source code. I recently posted a working example of it using bus stuffing to scroll a PF and another example where JSR is misused to display 10 colored sprites while also playing an audio sample. 3 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted January 10, 2018 Share Posted January 10, 2018 (edited) I am not closely following the Basic developments, but there seem to be quite a lot. Nevertheless Assembler is still quite strong and ARM based games and hardware tricks (CDF) have extended the possibilities massively. Besides the "ordinary" hacks, people have created a lot of hacks for compatibility (e.g SuperCharger) and more PAL-60 conversions. And then Omegamatrix and I created a lot of new "real" Trackball hacks. Edited January 10, 2018 by Thomas Jentzsch 2 Quote Link to comment Share on other sites More sharing options...
kisrael Posted January 10, 2018 Author Share Posted January 10, 2018 Fascinating stuff! What are the physical cart manufacturing implications? Can Al etc churn this stuff out as easy as anything else, or does it complicate things? Does the line ever grow fuzzy, in terms of what feels "like a 2600 but goosed a bit" (like the Pitfall 2 sound chip) and what would feel like "we're using a 2600 as a klutzy I/O device, but all the work is elsewhere"? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted January 10, 2018 Share Posted January 10, 2018 There have been discussion about this. I think most customers don't care, but developers have differing opinions. 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted January 10, 2018 Share Posted January 10, 2018 What are the physical cart manufacturing implications? Can Al etc churn this stuff out as easy as anything else, or does it complicate things? Cartridges using BUS, CDF, and DPC+ are actually easier for Al to build, he just plugs the Melody board into a programmer and flashes the game ROM. He can even do that with completely assembled cartridges - flash the game then slap on a label and it's ready to go. Does the line ever grow fuzzy, in terms of what feels "like a 2600 but goosed a bit" (like the Pitfall 2 sound chip) and what would feel like "we're using a 2600 as a klutzy I/O device, but all the work is elsewhere"? I see it as a continuation of what has always been happening with Atari games - I've written a blog entry about the extra hardware they've been putting in Atari cartridges ever since they needed to break the 4K barrier. I don't mind that others may disagree, they're free to not play the games we've been creating. What I do mind is the implication that it's "easier" as writing code to get the 2 processors (6507 and ARM) to work together is anything but. Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 10, 2018 Share Posted January 10, 2018 Doing a diff between what you've reported in the bB read me first post and what I'm aware of... The bB DPC+ kernel is a kernel that uses the Harmony/Melody ARM chip as a coprocessor of sorts. The titlescreen kernel allows coders to create custom bitmap titlescreens for bB games. The multikernel frameworks allow for multiple kernel binaries to be loosely combined, overcoming "everything must go in the kernel bank" limitations. The bB starfield effect is a port of the Cosmic Ark starfield effect to bB. (standard and DPC+ kernels) Some of these and a few more are listed at RT's. 3 Quote Link to comment Share on other sites More sharing options...
kisrael Posted January 10, 2018 Author Share Posted January 10, 2018 That's a cool article. Yeah, I'm a little torn. I *hate* sounding like a snob, and your article points to the precedent for it - and I have little problem counting SNES Star Fox or 2600 Pitfall 2 as legit games for those systems. (And I've never been into Atari programming for the sheer masochism or flaunting my coding prowess ) It would be interesting to see what a full-on "screw it, we're gonna build a little kernal that does nothing but read memory from the coprocessor and blit it to screen" and then have the coprocessor be like an Xbox. I've heard this talk about the flashback stuff too - and how some games like Frogger are just clearly more like the 500-in-1 NES-clones than anything that came near a Stella chip. (I'm trying to wrap my head around whatever Flashback BASIC is doing with that ) 1 Quote Link to comment Share on other sites More sharing options...
+stephena Posted January 10, 2018 Share Posted January 10, 2018 To help beginning programmers (as well as more experienced ones), Stella emulation has greatly improved over the past few years, thanks to Thomas J. and DirtyHairy. Many parts of the TIA emulation are now cycle-exact, and Stella now runs some ROMs that don't run on any other emulator. The debugger has been greatly extended too, to help with development. And finally, DirtyHairy has created a web-based emulator (Stellerator), and ported its TIA emulation to Stella. Emulation-wise for developers, the past year or so has seen more activity than the previous 5 years combined. 4 Quote Link to comment Share on other sites More sharing options...
Keatah Posted January 10, 2018 Share Posted January 10, 2018 Does the line ever grow fuzzy, in terms of what feels "like a 2600 but goosed a bit" (like the Pitfall 2 sound chip) and what would feel like "we're using a 2600 as a klutzy I/O device, but all the work is elsewhere"? A good portion of the essence of the VCS experience is in the quality and characteristics of the sound/video output. A certain look of graphics, x-amount of speed in movement, a certain timbre or resonance in the sound. It's quite different from and Apple II, as the Apple II is quite different from an Amiga, and so on. And unless those are radically changed, then it's still going to be a VCS game. Pitfall II, IMHO, goes a little too far with changing how the sound sounds. It sounds like a campy console RPG game from the NES-era. It's looping, sounds like it's sampled, and applies only to the music. Doesn't feel integrated into the game. As a child we were always fascinated by what was in cartridges and how they worked. When I busted some open I said look!! There's more room in here!! And I thought they were ripping us off, charging so much for a box of air and the tiny chip. Once I learned some electronics I began theorizing (as much as a 3rd grader could) about something called AROM. Active ROM. Me and my buddies drew up "plans" to make one. This new kind of ROM would be able look at its own program, all by itself, and make changes to its output. A ROM running its own program. This output would then be fed into the VCS like a regular Game Program. 1 Quote Link to comment Share on other sites More sharing options...
kisrael Posted January 10, 2018 Author Share Posted January 10, 2018 To help beginning programmers (as well as more experienced ones), Stella emulation has greatly improved over the past few years, thanks to Thomas J. and DirtyHairy. Many parts of the TIA emulation are now cycle-exact, and Stella now runs some ROMs that don't run on any other emulator. The debugger has been greatly extended too, to help with development. And finally, DirtyHairy has created a web-based emulator (Stellerator), and ported its TIA emulation to Stella. Emulation-wise for developers, the past year or so has seen more activity than the previous 5 years combined. Oh, DirtyHairy! Just put 2+2 together and realize he's contacted me on regular email, he likes FlapPing as a test subject for his brilliant emulator work, and of course I'm delighted to oblige. 1 Quote Link to comment Share on other sites More sharing options...
Mr SQL Posted January 10, 2018 Share Posted January 10, 2018 It would be interesting to see what a full-on "screw it, we're gonna build a little kernal that does nothing but read memory from the coprocessor and blit it to screen" and then have the coprocessor be like an Xbox. I've heard this talk about the flashback stuff too - and how some games like Frogger are just clearly more like the 500-in-1 NES-clones than anything that came near a Stella chip. (I'm trying to wrap my head around whatever Flashback BASIC is doing with that ) The Flashback BASIC kernel was built with that idea in mind! It's based on a soft blitter chip (not the ARM) that uses display lists like the A8 to blit variable sections of the screen. Flashback BASIC has two gameloops, one for each vertical blank, DLI's can be called from both and there is also another method to steal an entire frame to do the bit-blitting. Flashback BASIC games can also be cross compiled to run on the SuperCharger. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted January 10, 2018 Share Posted January 10, 2018 That's a cool article. Thanks! Yeah, I'm a little torn. I *hate* sounding like a snob, and your article points to the precedent for it - and I have little problem counting SNES Star Fox or 2600 Pitfall 2 as legit games for those systems. (And I've never been into Atari programming for the sheer masochism or flaunting my coding prowess ) I talked with Joe Decuir quite a bit at PRGE, he seemed very impressed with how we've been pushing 2600 development - his jaw about dropped upon seeing the 32 character text display (he took a bunch of photos of that). He also really liked the cool quad-joystick project. At another point John Champeau was showing David Crane his takes on Scramble and Super Cobra, as I walked up David started asking questions about DPC+ which John handed over to me. So if people that involved with the foundations of the 2600 have no issues... It would be interesting to see what a full-on "screw it, we're gonna build a little kernal that does nothing but read memory from the coprocessor and blit it to screen" and then have the coprocessor be like an Xbox. You're still limited by how TIA works, such as having to reposition objects midscreen to reuse them. The kernels with DPC+ and CDF are basically a bunch of LDA #/STA ZP instructions, so 5 cycles for most updates to TIA (for 48 pixels and such you still need to get X and Y registers involved). BUS gets that down to 3 by using just STY ZP. Draconian has 56 kernels for the gameplay area - 11 reposition kernels for each of the 5 objects, plus one more for when nothing's being repositioned. There's two more kernels, one for the score/radar/lives/formation display and another used for the menu & splash screen. I've heard this talk about the flashback stuff too - and how some games like Frogger are just clearly more like the 500-in-1 NES-clones than anything that came near a Stella chip. (I'm trying to wrap my head around whatever Flashback BASIC is doing with that ) I've not kept up with the Flashback, but images as seen in Frogger aren't possible with Atari so they're obviously using a different video chip. The sound effects don't sound like TIA either, but then again I never thought TIA could sound like this. Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted January 10, 2018 Share Posted January 10, 2018 Oh, DirtyHairy! Just put 2+2 together and realize he's contacted me on regular email, he likes FlapPing as a test subject for his brilliant emulator work, and of course I'm delighted to oblige. Now I'm blushing Thanks again for letting me use FlapPing in 6502.ts (although I must admit that I suck at playing it). I should also mention that your thin red line was the first piece of VCS code that was ever displayed by 6502.ts Quote Link to comment Share on other sites More sharing options...
vidak Posted January 13, 2018 Share Posted January 13, 2018 I've kind of stalled on finishing this, but I have completed most of a new dig of the Stella Mailing List from back in the 90s and 00s. It's here at http://bootlicker.party/commo-dig Personally, I think it is too difficult for new non-programmer fans to start developing games in ASM. There is not a unified location on Atariage for people to logically develop every known skill for 2600 development. I have mastered as much as a beginner can through sheer force of will and determination. I think most people should not have to try this hard. Kirk Israel's 101 guide is amazing, though. It is everything a complete rookie needs. We need a hundred more guides like that. I am willing to give say 8 hours a week contributing towards a more comprehensive guide for beginners. Some things on only became clear to me after looking at 8bitworkshop.com. I am not against using something like that to do a codeacademy.com for Atari games. I am so, so grateful for Stella, Collect, StayFrosty and so on. 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.