Mr SQL

wood_jl, I was impressed by the 128 bit Emotion Engine when it came out and now; PS3 emulation of this (before it was pulled) always fell short and the PS3 owners I know who wanted to play GOW all had to go and buy a PS2. The PS4 will be even less capable of emulating the Emotion Engine or the cell processor for that matter but that doesn't matter because it's just a gaming PC. This raises questions about the PS4 PC model though; traditionally, the SONY way to creating a SONY brand PC has been to simply take ownership of your PC using a trick ROOT Kit. At the time all PC's were powerful enough to run the ROOT kit; now only tangerine and strawberry Alienware gaming PC's would be powerful enough to run and install SONY PS4 as a stealth rootkit but Moore's law is rapidly changing this...

Awesome Cybearg! Programming Assembly on the 2600 with the ASDK should feel more like that. This will be fun, I'll get that thread started soon!

loon, NESHLA looks really cool, the ASDK is more simplified but definitely along those lines That's a great idea! I was planning to start a tutorial on learning Assembly fast with the ASDK and will include examples of how to migrate bB Assembly output into the user code section of the ASDK as well as the similarites in how both frameworks abstract the hardware; Assembly can be nearly as RAD as bB with the abstract calls.

Here is the latest version of the Abstract Assembly Development Kit with source and inline demo's to illustrate using the new enhancements, and an updated manual: drawsprt2.asm drawsprt2.bin ASDK_Manual.pdf The first sprite demo example is flipping through different sprite animations, the second is more complex where as you scroll around and draw on the playfield scrolling the playfield through the large virtual world, you are also able to scroll it through the moving sprite and draw on it too. The sprite objects, the playfield and the large virtual world are all abstract objects that are x and y coordinate addressable and can be used for RAD development in Assembly in a very similar manner to bB. Sprite definitions are stored in intuitive WYSIWYG format like the large virtual worlds. In the back of the manual there are also some ideas on directly integrating a flicker free version of the scrolling engines into the bB DPC+ kernel at higher resolutions.

Tom, perhaps the programmer needed to pad cycles? Those opcodes are less frequently used but I would expect the Activision programmers to to be familiar.

That's awesome Tjoppen, the colour depth really enhances the 18x75 image!

Joe, what genre most interests you, do you want a simple pac-man type theme like the Alien movie game? Or a complex theme with a manual like ET?

loon, In the 80's there wasn't much difference; developers wrote games because it was fun You made a very relevant comment on the other thread about the classic hits being fun to play and inspiring you in terms of game design ideas; IMO you've got the right mindset. First ask him if he likes gaming, ask him if he likes building the games - if the answer is yes you may be in for an interesting discussion; if the answer is no your backup plan sounds perfect

Cybearg, read this thread and have a look at the scrolldraw Assembly example in the opening post: http://www.atariage....evelopment-kit/ There's nothing required for setting timers, counting cycles, drawing an asymetric playfield or loading the playfield registers backwards! Instead, the focus is on using Assembly at a very basic level to drive the game logic and loops while using familiar high level calls for setting pixels (like the pfpixel commands in bB) and for panning the camera to scroll the large play area (10x the size of the visible playfield) which is also defined similar to bB in simple WYSIWYG format. IMO only once you've mastered Assembly should you attempt to use it to harness the unique and bizarre hardware of the VCS; it's a lot harder to do that all at once, kind of like trying to learn SQL by starting with correlated subqueries

Cool selections RT, I think it's a tough call between Enduro and Defeder II/Stargate. You're article on Pitfall really cracked me up; I can see you're not a big fan of the game having returned the sequel I assume you got it for the 2600 or was it another system? I still have Pitfall II on disk for the CoCo II; in order to hear the cool sound track you needed to buy a special cart with a sound chip, and because it was on disk and the disk controller was using the cartridge port, you also needed to get a multipack interface - I never bought all of that extra hardware and just played it without the sound but it was like playing without the sound Would you have returned the disk or bought the extra computer peripherals? It was a fun game but in retro retrospect it seems like the 2600 verison was a much better deal; that's a lot of expanding just to hear sound.

Great perspective Schizophretard, you've asked the right question. I can read a book for hours but reading on a kindle or a nook won't even last 20 minutes; no analougue feel; the UI can't match a real book. I like listening to SID's but prefer to listen to them on my C64 with an early revision 6581; the SID is a subtractive analougue synth and simulation isn't emulation. The 2600 has many analougue parts; Stella is an awesome emulator and tremendous fun, but gaming on a real 2600 is a richer experience and even more fun so it's going to last longer. You're other observations are right on too; forget customising settings, I prefer not to even boot windows and launch apps or navigate pop-up ads in order to read a book or play a game.

Spice, thanks! Interesting stuff; looks like the DPC+ allows for 4K of graphics data RAM and from the bB listings I've seen the DPC+ kernel supports up to 40x192 pixel playfields, so it looks like up to four playfields this size could be stored simultaneously in RAM. I have a 4-way scrolling engine in my ASDK that has a lot of overhead that takes an extra frame; do you think code running on the ARM could enable this kind of scrolling engine with virtually no overhead?

Does the DPC+ kernel actually copy all playfields to RAM or just one specified playfield at a time like the 1.0 kernel? I remember with superchip memory enabled for the expanded 32x32 playfield in 1.0 that worked out to 4 bytes x 32 rows, the entire 128 bytes in the SC. Being in RAM, the playfield could then be modified with pfpixel commands, etc. If the DPC+ kernel works the same but with a bigger chunk of RAM rather than loading all the defined playfields into RAM simultaneously it should still be possible to write a scroll routine to scroll the playfields but a malleable large playfield area larger than the screen would still be out of reach - you could scroll all around a large maze but the composite tapestry images are read from ROM with only the currently displayed sections in RAM.

Those both look Awesome! Fantastic you are emulating the analougue filters; the TinySID emulation I'm using with RockBox has no support for that and you can really hear the difference. The TIA support looks really cool too; would be nice to be able to browse a folder of 2600 demo binaries and play them - there was a 2600 emulator the developers almost got working in RockBox that would have been great for that. You're doing 2600 emulation projects too so I imagine you could add the rest of the core to the player for this?

kevtris, the chiptunes player looks really cool! Any chance you'll add SID support? I have the Rockbox firmware on my audio player which plays SID's but I would love a chip tune walkman with a real SID chip.

Tom, wow that's pretty cool! Atari R&D must have been pretty cutting edge to have had a Macro Assembler in 1987!! Obviously the 1987 kit is retro but the high level Macro scripting language you are leveraging is a product of the 90's, closer to Visual BASIC than Tiny BASIC All kidding aside, you've raised a very interesting point and I'm not sure it's about the dialect; what if a game developer wrote a 100% Machine Language game but entirely within the bB framework? Would you try it then? Green eggs and ham thing? You can even write 100% .asm but still have it run entirely within the bB framework leveraging all of the abstract objects for faster development for a RAD .asm approach; my ASDK framework I've shared also takes this approach. Would you play such a 100% Assembly game or is it really the frameworks you object to? This is intriguing, I suspect the latter

Tom, you have some very good points but we didn't have lightweight macro scripting languages in the 80's and you wrote some awesome games in pure Assembly without them I like RAD tools too but I don't fancy using macro's when I code in Assembly; they aren't retro I think a master coder like yourself can learn from programs written in any language just by looking at the screen or the outputs - that you don't even need to see the codebase to figure out what's going on That would be awesome! Tiny BASIC is refreshingly retro and Fred's implementation for the VCS has a lot of charm for that reason, I bet you would be tempted to use it if you put the BD kernel in it Fair assessment; developers like different things. Spice writes C code that runs on the ARM for his games, you like macro scripting. When I play Atariage I like to keep it retro

loon, those are all great games! My point was I don't see how bB is so different from the Macro scripting language Tom favours for generating blocks of Assembly code. Back on topic I agree there is something inherrently cool about loading games from tape, and it is a more interesting (and durable) medium for a retro release than an mp3 player. I wonder if the Compumate could load the 2K games as well, anyone try this?

It's just another way to write Macro's isn't it though?

Loon that shouldn't matter, it's only if you use the entire 4k; looks like the hotspot is 8 bytes away from the end of memory so make sure you have at least 8 bytes free. I think it would be cool to see more 2600 games released on tape

Awesome work yerzmyey these tracks are fantastic! You can really push the chip in the ST and your work with Pokey (Mountain in the Sky, etc) is equally awesome. Ditto for your ZX/Spectrum compositions - are those done with the stock hardware too?

This is pretty awesome Loon, I just tried the latest version Feels like a two player Defender type game, very colourful!!

Al, I agree the AJAX has gotten much better! IMO you don't need to bother with the backups at all anymore with that nice RAID That isn't the suggested protocol but more than adequate with MySQL.

Al, the backup window gave it away but I think MySQL is OK - you were getting pretty good performance from the database side before the AJAX upgrade to the software; that upgrade was pretty buggy at first, the AJAX created client side bubbles that could crash a workstation if the page was left up over night and probably bogged the server with too many unnecessary database hits. I would think AtariAge is awesome even if you ran it on an 80's BBS ... wait a minute, what am I saying? I think AtariAge would be even more awesome if you ran it on an 80's BBS

Hey Al what database are you using? Just curious, feels like you are running MySQL if I had to guess