Mr SQL

Great thread, lots of interesting posts! Interesting that the 6502's direct page was designed to allow that memory to be used like registers; the 64 byte memory of the Fairchild VES was comprised entirely of registers. As pointed out CPU's like the 6809 can slide the direct page window over the entire 64k, but I don't think direct addressing and other advantages of the 6809 are what prevented Mega-Bug from being developed on the Nec TREK with it's Z-80; that system has a 6847 VDG like the CoCo but there is no SAM support chip - seems to me it would leave the CPU pretty much left to race the beam since there's no buffer on the VDG and every line of input must be synchronised and accounted for like on the 2600. Rybags, what do you think?

Trem, that's awesome, the CoCo is a fun machine! Some great carts are: Arkanoid (of course ) - this one's a "fat binary" from Radio Shack that actually has two different Arkanoid games depending upon if you've got a CoCo3 or an earlier model. Dino Wars - fun 3D Dinosaur fighting game. Mega-Bug - Great pac game with a sliding magnifying glass; I was just reading on the 6502 vs Z80 thread how this was impossible on the Nec TREK which used the same display hardware as the CoCo. The CoCo has many phat pixel semigraphics modes and the games that use these feel the most retro Lot of great arcade conversions too, most of the software was on tape and disk as previously mentioned but there are many cart titles as well. There are multicarts available similar to the Harmony or the UIEC for the C64 and simpler solutions for loading the tape images from a casette deck or as WAV files.

loon, I agree, who would want multiple flashcarts? Just one can hold an entire library of games But I think they are a direct medium for the software analougous to a disk drive or tape player in the 80's; you can purchase new homebrew games to add to your flashcart with ease and all the free homebrew games and demo's already offer a great incentive to buy one.

I think the multicarts offer a direct platform for homebrew development today by enabling the option for soft releases of the game binaries much the way disk and tape facilitated the soft releases of the 80's. IMO StoneAgeGamer already supports homebrew just by selling multicarts

Tjoppen you're right There are plenty of free cycles in the physical block of scanlines for each row of phat pixels to expand three bytes into six for the next row.

Tjoppen, upscaling in the kernel would have to entail processing 3 bytes (into 6) per scanline; don't think there is enough time. If I create a non flicker mode I would probably drop the upsizing engine and have the panning engine do that job as well - creating six tables wouldn't be an issue since then there would be no RAM buffer overwrite. I am working on adding phat pixel sprites next

LOL loon! Fine to use bB to build your game logic if you prefer, IMO bB is not too different beyond semantics. I sure wish DASM supported a concatenation character so I could code horizontally in asm too (linefeed almost works but it reverts to CR+LF after I save the file). A no flicker mode may happen sometime in the future, it would "DVD" the picture down to a strip to get the cycles though and I really like using the full screen

The C64 can use the same joysticks and paddles, however Atari paddles contain a potentiometer with twice the resistance of C64 paddles - range of motion will be limited accordingly. The capacitors that charge to read the paddles are contained within that wonderful subtractive analougue synthesiser know as the SID; the higher resistance in the Atari paddles are fine (just longer charging time/less motion) but don't risk damaging that fantastic chip with an unmodified genesis controller (shunts the cap).

Juan, I was thinking the same thing as Tom; check that the volts and amps are to spec on the power supplies and on the cartridge bus. If that fails consider some of the 30 year old components can attenuate, particularly in different storage climates (caps can leak dielectric faster, etc). One other thing to check is using an isolating transformer or testing via a DC Inverter; a cross current, groundloop or microwave signal bleeding into the power supply could all be causes of varying sensitivity like you've described, check and see.

Tjoppen, yes this is an excellent idea (and I like your code comments!) but it would require either modifications of the rendering engines or more RAM to play with. Via Modication of the Engines: The engine that pulls a 20x10 pixel screen from the panoramic 96x20 pixel WYSIWG bitmap (which is fully malleable and stored in 240 bytes of CBS RAM) deposits it in the bottom 30 bytes of the 60 bytes of the Atari's RAM reserved as a screen buffer. The upsizer engine then expands that bottom 30 bytes into the full 60 bytes creating phatter pixels (and flipping it so it is no longer WYSIWIG but ready for rendering). If I remove the latter engine I could have the first one perform both functions and so render it as six tables, reading with the same Y value via the optimised code you have shown, I may do something like this so I don't have to use an entire frame for the engines but I like having both of them because the latter engine can also be used independently depending upon the game design (scrolling or non-scrolling). Via more RAM: Without modifying the engines I would need an additional 30 bytes of RAM and I'm already only leaving 78 for the stack and variables; here's why: I usually sketch something on paper to explore an idea; as you can see from the illustrations, transposing the bottom half of the screen buffer (30 of 60 bytes) to six tables in 60 bytes breaks the same memory space (I haven't illustrated that the images on the right are not WYSIWYG) while contiguous transposition does not.

Gateway, no Macro's are actually used, I just included the reference in case anyone wants to use them (you could actually comment it out or remove the reference just in case there is something wrong with your macro.h file). You mentioned you had to turn on phosphor before with alt-p or the screen was blank; that is interesting, I'm curious what version of Stella you are using? Also, installing the open GL drivers for windows improves the look making it considerably closer to the real hardware with smoother scrolling (no pixels breaking rank).

save2600, sorry just saw your post! Maybe sometime in the future but right now I am working on SCROLLOUT and SCROLLANOID, a scrolling sequel

Spice, this game rocks! I was just playing the most recent build on my 2600 (it freezes in Stella) and checking out your C source code for the ARM; very cool, reminds me of the Compumate the way the ARM can take over the 2600

Fantastic Gateway! I'm looking forward to hearing about your experience

loon, excellent question! You could wrap them with an aa_drawscreen function that calls them both in order, agree that would be even more abstract. But I've left them as two seperate functions because one of the engines could potentially be used independantly, depending upon the kind of game you are building: pushabstractextendedplayfield pans a 20x10 pixel playfield out of your 92x20 pixel virtual world and maps it to 30 of the 60 bytes of the 2600's RAM set aside for screen memory, still storing it in WYSIWYG format. AbstractPlayfieldBuilder takes no arguments and simply upsizes the 30 bytes to 60 bytes, doubling the size of the pixels and also flipping them to and fro to suit the 2600's unique playfield architecture; for building games that don't scroll it is possible to load the bottom 30 bytes of reserved screen memory with a WYSIWYG 20x10 bitmap (from any 3 byte wide x 10 row table) and just call this routine to upsize and flip the bits around.

Omegamatrix, Excellent point, Machine Language for Beginners is an excellent path to learning Assembly - it is the book I recommend using with my Abstract Assembly Development Kit for faster assimilation. Nukey had some very good points about some of the concepts it misses, but in doing so the book makes it easy for developers to make the transition and IMO trying to master the 2600's unique chipset at the same time as learning Assembly is even more extreme - kind of like learning BASIC or C by starting with three dimensional Array's. HatefulGravey, you might like the ASDK for learning Assembly, I just uploaded the manual and the dev kit to my thread of the same name

Here is the ASDK Manual and the full Framework source code with the inline example ScrollDraw ASDKManual.pdfScrollDraw.asm

You're welcome Gateway, great screenshots! The scrolldraw.asm example, or any Assembly program you build with the AADK (nice acronym) just gets dropped right into the Framework file (it's all one Assembly file) right between: ; --------------------------------------------------------- ; ------ Your Assembly code goes here: ;---------------------------------------------------------- and ; ---- Resume Framework... I'm writing the manual right now and will post it soon and the AADK source with the ScrollDraw.asm example inline. btw, I think you just imagined an interesting possiblity I hadn't thought of: You could probably use bB to write your game loop and game logic - and then paste the resultant assembly code it generates (just for your loops and logic, no part of the bB framework code would work) into the AADK; the AADK even offers the variables a-j which you could use directly in your program with no changes (Pretty cool idea, I will add it to the manual!). You would still have to edit your bB Assembly output to hook up the abstract calls for the phantom hardware but the api's are very straight forward/high level and editing the large virtual world bitmaps is very similar to the playfield screens in bB - all WYSIWYG, same for the musical score table.

The Abstract Assembly Development kit Is an Assembly Language Programming Framework for the Atari2600 that provides the equivelent of Hardware based horizontal scrolling and a screen buffer! It also abstracts and/or eliminates Racing The Beam (scanlines) and timing/cycle counting and flipping the portions of the screen backwards and forwards (large WYSIWYG bitmaps are supported) so the developer can focus just on the logic for their Assembly games and leverage high level calls to the phantom hardware. This framework is an excellent resource for advanced bB developers to rapidly gain a working knowledge of Assembly language programming; you just have to start writing code to learn Assembly but it's daunting and near impossible to learn the chipset and concepts such as programming without a screen buffer let alone horizontal scrolling without hardware support (when I learned Assembly in the 80's I had these things all available in hardware, the 2600 is quite a unique beast!) Anyone may use the kit however they wish (no strings attached), please enjoy! Examples to try: ScrollOut: Scrollout2.bin This has a demo and an unfinished breakout style game; the demo scrolls horizontally and diagonally a few times and then starts breaking out, pressing the fire button will scroll a "Eady Player One!" banner and then start the game; the camera initially follows the paddle but once you launch the ball it follows the ball, making it very difficult to hit the ball with the paddle when it scrolls diagonally/vertically and you have to find it - this game will be changed so that it only scrolls horizontally (no vertical/diagonal scrolling), so that it will be fun ScrollDraw: Scrolldraw.bin This is the traditional "draw on the screen" demo only it scrolls and the camera follows the cursor, source code to show how simple this assembly program is follows! Sample Code from ScrollDraw: Here is a short simple Assembly example from ScrollDraw.bin, drawing on a large scrolling virtual world; try the demo's and take a look at the code and let's discuss it! I'll be posting the source for the framework shortly, it already works with the version of DASM that comes with bB so you have everything you need: ; --------------------------------------------------------- ; ------ Your Assembly code goes here: ;---------------------------------------------------------- ;-----SCROLL Draw: ;-----Simple Demo for the Abstract Assembly Development Kit ; Hold the Button Down to Draw or Erase ;------------------------------------------------------- ; bity, bitx - x and y vars for the large virtual world ; BITindex, x value for horizontaly scrolling anywhere in the large virtual world ; BYTErowoffset, calculated from YIndex for vertical scrolling (hardware support already exists) ; moved joystick? Then Move the Draw Cursor lda #$10 ; #16 or %00001111 bit SWCHA ; like AND but we drop the result in the bit bucket behind the CPU bne skipup lda bity beq skipup ; don't decrement bitx further if it is at zero dec bity skipup lda #$20 ; 26 or 00011010 bit SWCHA bne skipdown lda bity cmp #19 beq skipdown ; don't increment it past 19 inc bity skipdown bit SWCHA BVS skipleft lda bitx beq skipleft ; don't decrement the x position value past zero dec bitx skipleft bit SWCHA BMI skipright lda bitx cmp #96 beq skipright ; virtual world is 96 pixels wide inc bitx skipright ; ---------------End Drawing Routine ;----------------------------------- ;Follow the Cursor with the Camera: ; Camera X Axis: ----------- lda bitx cmp #10 bcs followXaxis ; >=10 lda #0 sta BITIndex ; (X position for camera is 0 - nothing to scroll to yet) jmp donefollowXaxis followXaxis sec ; set carry for subtracts, clear it for additions sbc #10 cmp #72 bcc dontadjustxaxis ; <72 lda #72 ; adjust x axis so code to the right of the virtual world is not shown on screen dontadjustxaxis sta BITIndex donefollowXaxis ; Camera Y Axis: ----------- lda bity cmp #6 bcs followYaxis ; if >=6 lda #0 ; keep Y pos for virtual world at the top for the top 6 pixels sta YIndex ; superfluous jmp offsetdone followYaxis lda bity sec ;set carry for subtracts, clear for additions sbc #6 sta YIndex donefollowYaxis cmp #10 bcc dontadjust ; <10 lda #10 sta YIndex ; don't show the code below the virtual world; this sets the bottom border dontadjust ; Now turn Y Index into a Row Offset for the bitmap (it's 12 bytes across) lda #0 ldy YIndex offsetcalc sec ; set carry before additions clc adc #12 dey beq offsetdone jmp offsetcalc offsetdone sta BYTErowoffset ;----------------------------------------------------- ;----- Done Following the draw cursor with the camera ;--- Turn on the target bit in the virtual world: lda #1 ; argument to turn pixel on always jsr getbitstatus ; call subroutine, passing argument ;---- Done Turning on the target bit ;---------Erase the target bit under the cursor? ;--- if button is pressed, erase it: bit INPT4 bmi skiperase lda #0 ; argument to invert bit, since it was just set it will be turned off jsr getbitstatus ; call subroutine, passing argument skiperase ; note: The getbitstatus subroutine can get, set, invert or clear a bit ;----------------- ;-- Now Call the Twin Engines that emulate hardware level ;-- Horizontal Scrolling and Scaling ;----------------------------------------slide view window along bitmapped panorama currently loaded into CBS RAM: jsr pushabstractextendedplayfield ;--------- expand and flip 30 bytes of system RAM buffer into 60 Bytes for display: jsr AbstractPlayfieldBuilder ;------------------------------------------- ;----------End Scrolling Draw Demo ; ---- Resume Framework...

SpiceWare, very cool! I had a very parallel experience as a freshman in Comp class with the seniors using the Commodore PET's; got along great with the students, not so well with the teacher Agree about the unique 2600 hardware posing the learning curve and not Assembly language - HatefullGravy's comments about scanlines and the other esoterics being daunting are right on, particularly so if the programmer has never used Assembly before! I think what makes the Tiny BASIC implementation (bB) so fantastic is that it abstracts the hardware in addition to allowing the higher level coding. I'm planning to release an abstract Assembly dev kit based on my virtual world scrolling engines to provide hardware abstraction and let the programmer focus on Assembly programming instead; excellent developers like the Loon, RT and disjaukifa (to name a few) who haven't picked up Assembly yet will find this kit a great tool for quickly learning Assembly without having to learn the chipset at the same time - the chipset should be the next step, I don't think I would have been comfortable learning them both at once. bB is a great learning tool in this regard and will only make it easier for developers to learn Assembly but it will not help you with the chipset for having abstracted it so nicely Developer can make awesome games with bB or Assembly and should use whatever environment they find the most comfortable; whichever implementation is chosen the resources here and on RT's site are fantastic. Your site is also a great resource, I looked at a paddle demo you had up for hints on discharging the cap

Blacklight, as an experimental musician you owe it to yourself to get a real C64 or an Electron SID Station; the phat sound of the subtractive analougoue synth cannot yet be duplicated via digital approximation; here's one example of many that cannot be reproduced well via emulation: http://www.youtube.com/watch?v=6ZsX3D_vUuY

atari2600land, I agree with Prime_Suspect, it's the unique hardware that is the learning curve, not 6502 Assembly, and Andrew's overview is excellent

Another awesome video! You Rock Metal Jesus!!! This is what the collective comments here are saying about the VCS: The 2600 has more retro coolness than any other system; so much so that it's still alive and thriving. Even Atari keeps flashing back with new releases of the hardware, both real and in emulation. Updates to old favourites like the aforementioned Voice Enhanced Beserk and new releases of Arcade Classics never seen before on the 2600 keep this system going and going and going like an Energizer bunny. The unique hardware is so flexible that developers today can push it beyond the outer limits of yesteryear, the fun literally never ends! What other system do you race the electron beam across the screen and program it in real time? Without a screen buffer games must be fast and responsive by design. Metal Jesus, you are the man to cover the story of the enternal VCS, the perpetual 2600, that iconoclastic console so thoroughly embedded in the culture and history of gaming.

loon, that's awesome you are doing this project on both platforms. Big difference in resources! I've been meaning to check out BEX; I remember seeing another Basic compiler for the Genesis too but not sure what it is called. Why does BEX need asm, is it missing functionality? bB feels like a cross between Tiny BASIC and asm (things wrap around and fall through, etc); from our discussions on your bit project I don't think you'd have any trouble switching to asm

stephena, I understand your perspective and I'm on your side like Dr Walter Gibbs User requests are what computers are for! Unfortunately as you've pointed out, Microsoft is a bit like Dillinger in this regard: DOING OUR BUSINESS is what computers are for! And no one installs OpenGL on their own except for a handful of power users and a few wishfull Engineers hoping everyone's a power user. Simply because they've made it very hard; I want the environment 99% of the users have on that platform (most probably your largest distribution platform). That is the default - no OpenGL, no double buffering: Clu, we don't have much time to find that file. I'm not being silly, that is a good reason for me not to install OpenGL. Based on Tom's comments I imagine he hasn't installed OpenGL for that same reason; we need to see what the users will see: If the Users can no longer help us, we're lost. I'm looking forward to the next release because the defaults change and everyone on that version will have it. The problem will still persist for some time though because most users will be on the last version: On the other side of the screen, it all looks so easy. It's tough getting people to upgrade when stella already works so well; even a year after the new release all we can do is encourage: This is the key to a new order. This code disk means freedom.