Jump to content

Search the Community

Showing results for 'pokey explorer'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Atari Systems
    • Atari General
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Atari VCS
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Classic Consoles
  • Classic Computing
  • Modern Consoles
  • Gaming General
  • Marketplace
  • Community
  • Community
  • Game Programming
  • Site
  • PC Gaming
  • The Club of Clubs's Discussion
  • I Hate Sauron's Topics
  • 1088 XEL/XLD Owners and Builders's Topics
  • Atari BBS Gurus's Community Chat
  • Atari BBS Gurus's BBS Callers
  • Atari BBS Gurus's BBS SysOps
  • Atari BBS Gurus's Resources
  • Atari Lynx Programmer Club's CC65
  • Atari Lynx Programmer Club's ASM
  • Atari Lynx Programmer Club's Lynx Programming
  • Atari Lynx Programmer Club's Music/Sound
  • Atari Lynx Programmer Club's Graphics
  • The Official AtariAge Shitpost Club's Shitty meme repository
  • The Official AtariAge Shitpost Club's Read this before you enter too deep
  • Arcade Gaming's Discussion
  • Tesla's Vehicles
  • Tesla's Solar
  • Tesla's PowerWall
  • Tesla's General
  • Harmony/Melody's CDFJ
  • Harmony/Melody's DPC+
  • Harmony/Melody's BUS
  • Harmony/Melody's CDFJ+
  • Harmony/Melody's General
  • ZeroPage Homebrew's Discussion
  • Furry Club's Chat/RP
  • PSPMinis.com's General PSP Minis Discussion and Questions
  • PSPMinis.com's Reviews
  • Atari Lynx 30th Birthday's 30th Birthday Programming Competition Games
  • 3D Printing Club's Chat
  • Drivers' Club's Members' Vehicles
  • Drivers' Club's Drives & Events
  • Drivers' Club's Wrenching
  • Drivers' Club's Found in the Wild
  • Drivers' Club's General Discussion
  • Dirtarians's General Discussion
  • Dirtarians's Members' Rigs
  • Dirtarians's Trail Runs & Reports
  • Dirtarians's Wrenching
  • The Green Herb's Discussions
  • Robin Gravel's new blog's My blog
  • Robin Gravel's new blog's Games released
  • Robin Gravel's new blog's The Flintstones Comic Strip
  • Atari Video Club's Harmony Games
  • Atari Video Club's The Atari Gamer
  • Atari Video Club's Video Game Summit
  • Atari Video Club's Discsuuions
  • Star Wars - The Original Trilogy's Star Wars Talk
  • PlusCart User's Bug reports
  • PlusCart User's Discussion
  • DMGD Club's Incoming!
  • DASM's General
  • AtariVox's Topics
  • Gran Turismo's Gran Turismo
  • Gran Turismo's Misc.
  • Gran Turismo's Announcements
  • The Food Club's Food
  • The Food Club's Drinks
  • The Food Club's Read me first!
  • The (Not So) Official Arcade Archives Club's Rules (READ FIRST)
  • The (Not So) Official Arcade Archives Club's Feedback
  • The (Not So) Official Arcade Archives Club's Rumor Mill
  • The (Not So) Official Arcade Archives Club's Coming Soon
  • The (Not So) Official Arcade Archives Club's General Talk
  • The (Not So) Official Arcade Archives Club's High Score Arena
  • Adelaide South Australia Atari Chat's General Chat & Welcome
  • Adelaide South Australia Atari Chat's Meets
  • Adelaide South Australia Atari Chat's Trades & Swaps
  • KC-ACE Reboot's KC-ACE Reboot Forum
  • The Official Lost Gaming Club's Lost Gaming
  • The Official Lost Gaming Club's Undumped Games
  • The Official Lost Gaming Club's Tip Of My Tounge
  • The Official Lost Gaming Club's Lost Gaming Vault
  • The Official Lost Gaming Club's Club Info
  • GIMP Users's Discussion
  • The Homebrew Discussion's Topics
  • Hair Club for Men's Bald? BEGONE!


There are no results to display.

There are no results to display.


  • AtariAge Calendar
  • The Club of Clubs's Events
  • Atari BBS Gurus's Calendar

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start










Custom Status



Currently Playing

Playing Next

Found 150 results

  1. The thing is, because there's so much unexplored, POKEY's true potential has never been fully realized ... I've still got a few more jungles to explore yet.
  2. A.R.T.I. (Archaeological Rescue Team International) A.R.T.I. is my take on a port of the classic 2600/C64/A8 game H.E.R.O. by Jon Van Ryzin. H.E.R.O. along side Keystone Kapers was another of my favourite 2600 titles. This adaptation for the 7800 is based on the 2600, 5200 and C64 versions and closely follows the level layout of all three, with the plan being to add extra levels beyond the originals. Objective You are Arty's new apprentice. A bunch of explorers and adventurers have got themselves lost in South America and you need to go and rescue them. There are additional on-ROM instructions accessible from the title page. Controls Left & Right - run / fly left and right. Up - enter activate the Gyrocopter backpack Fire 1- Laser Fire 2- Dynamite Scoring Rescuing a lost explorer or adventurer will earn you 1,000 points. Destroying a wall is worth 75 points Killing any critters or beasties is worth 50 points Bonus points are awarded for each stick of dynamite remaining and for remaining power, when making a rescue. An extra life is awarded at 20,000 points Demo A demo will be available soon! Plans All original version screens 50 or so Additional screens (extra levels) Themed rescue zones. SaveKey + AtariVox support for hiscore saving. POKEY musical score. Credits & Thanks @sramirez2008 @-^CrossBow^- @Trebor for their testing and feedback - fantastic as always! @RevEng for help with compression and answering my never ending stream of questions! @ZeroPage Homebrew for showing the demo on the stream Media https://www.twitch.tv/videos/1477067248 .
  3. There is a lot of misnomer but you are mostly correct, it's either squarewave or (periodic) noise. There is an actual "sawtooth" waveform that can be generated from the POKEY using the filter and 2 generators at 1.79mhz, however The Atari bass sound? that would be... a periodic noise. I know some people call it sawtooth but that's not what this looks like under an oscilloscope. Ohhh good idea, that would help for explaining, thanks for the suggestion! By far the easiest way to test sounds is by using POKEY Explorer by ivop, a really nice tool which has helped me a lot during my tests. Thank you! That's a pulse wave! this synth technique is usually called Pulse Wave Modulation, or PWM for short. This waveform is also the most characteristic sound used on the SID chip, but the POKEY has its own twist for generating it using the "high pass filter"
  4. I'm not advocating using this (i.e. stream frames from an IDE device, or a large cartridge like The!Cart), just pointing out it is a possibility that could work. But xxl is all about real hardware, and sizecoding, and so am I. Pokey Explorer works on a 16kb machine. 16kB for the win! Edit: just wait for xxl to release his code, and then listen to the complaints that it doesn't work on their CMOS CPU's because of "illegal" instructions
  5. There's no banking. Just loading from storage for each frame. Like Phaeron's IDE video player. That's the beauty of it. ANTIC (yes ANTIC) loads the video RAM directly from the IDE device (or SD card with an IDE API emulated). The CPU just selects a different block out of 16GB every frame, and there's a new frame on your display! Yeah, I recognize the ambivalence. I accept stereo Pokey somewhat, but I am more impressed by single Pokey songs. Extra storage, okay, but where's the limit? 16GB is a Whole Lotta Bytees Co-processor on a cart was well known in the MSX, (S)NES and Sega world, but not so much in our 8-bit time just before that. Only Pokey in some 7800 carts. Wrathchild demonstrated a very cool MODE 7 implementation for the Uno Cart. Yes, I like it. I thought it was about the engine fitting in 16kB, but now I read it should run on a 16kB machine, too That's cool. I really appreciate the effort. Similarly, I made sure that Pokey Explorer runs on a 16kB machine
  6. Latest Public Demo is RELEASE CANDIDATE A (December 2021) find it HERE E.X.O. Elite Xeno Operations. Your objective is to rescue your 4 team mates who are all inconveniently being held in different places. You also need to foil an alien plot to destroy the Earth and wipe out Humanity. How rude. E.X.O. - Inspiration E.X.O is heavily inspired by games like Cybernoid, Starquake, Exile and even Adventure. Flick screen shooter/adventure/explore type games. E.X.O draws on these archetypes, it has shooting but it's not trying to be a 'schmup', it has exploration, it has some puzzles (with more planned), it has a lot of "figuring out" that the player needs to do, to solve each screen and each level. It originally started as a "port" of Cybernoid, but I wanted to go in a slightly different direction so after some initial work, everything changed. Controls E.X.O needs a two button controller. (added emphasis!) A good controller is important! (no really, a beat up old controller that barely works will lead to a very frustrating experience!) Button 1 is mapped to lasers (useful for softer targets, mines, probes). Button 2 is mapped to rockets. (default is a "down" rocket, rockets can be flicked upwards by using up + button 2. Up activates thrust / engines. left and right to move left and right. Select = Bail out - only works on screen 1 of any world (used if you select the wrong level to try by mistake). See the in-game "how to play" for more details. Gameplay & Objective Each level has a generator and a security code. To rescue the team member and leave the level, you need both. Each level also has a hidden Key Stone. Switches are used to unlock the rooms containing the Key Stones. When the final Key Stone is unlocked the screen will screen shake, notifying you something has changed in the level. You will not be able to get to the security code until you have disabled the generator and weakened the security systems that block the way. (TLDR : Generator -> Security Code -> Exit -> Boss). Rockets are limited, use them sparingly! replenishments can be found, usually 1 crate on each world. Life & Death If you lose your ship, you will restart at either the beginning of the level or the most recently activated restart point. Restart points look like TV's, fly into them to activate them, when they are active, they are green. Features & notes as of Release Candidate A (December 2021) 5 full worlds for the player to explore and defeat, each with unique a graphical theme and enviroment, from industrial factories to ruined ancient temples. 5 end of level bosses to defeat. 4 hidden Key Stones to unlock. Pokey Tunes for your audio enjoyment. More than 100 screens in total. HSC, Atarivox and Savekey support for saving progress and unlocks. AtariVox speech supported for boss fights. Cinematic Viewer so that you can revisit past glories. Comprehensive "how to play" tutorial in game. Unlockable Easter Eggs such as the POKEY music player. Fully PAL compatible (palette, speed and yes, spellings..) 32kb of music and sound effects, over 80kb of graphics. Issues Nearly all of EXO's tunes do not sound right under older emulators. This is due to the maturity of POKEY emulation in software emulators. If the music sounds odd - it's the emulation. Recommended Emulator for EXO is A7800 V5 - POKEY sounds good. Link to V5 Road Map for EXO Release! Special Thanks : @mksmith @RevEng @SmittyB for answering my never ending stream of questions and providing great advice. @mksmith @RevEng for supporting the homebrew community with fantastic tools and drivers like 7800 Basic, ADS etc. @[email protected]^CrossBow^- @Trebor @ZeroPage Homebrew for comprehensive testing and feedback. You guys rock! @Synthpopalooza for making some absolutely bangin' tunes! Media: RC-A Screenshots. World 1 map
  7. Hi all. I currently have a Simple Stereo board in my 130XE with a 2nd pokey fitted. BUT I'd like to explore the possibility of moving the 2nd one out and into my Concerto cart for my 7800. So although the PokeyOne does not work as a replacement for the first pokey in an A8 machine will it work as a replacement for the 2nd pokey in the Simple Stereo board? Any experience anyone has with this configuration will be most helpful. Craig
  8. Thanks for the heads-up. I added the 2x to the text that was missing it... Right now I've just been throwing things into that entry as they occur, but I need to go over it for consistency. I prefer the 2x notation because it emphasises the nature of the rom. I'm told that 6502 coders can multiply by 2 easily. IMO the hi score cart not meaningfully existing in real hardware puts it into second-class status. Curt did a release of these, but due to a design flaw they don't actually retain the hi-scores for any length of time. A non-HSC compatible rom isn't a bad trade off for 52k contiguous rom. (though I agree with Pat that the 2x128K variants are where the action is at) Yes, for sure I was generalising the meaning of the EXRAM/X2 bit, since implementation header parsers need to work in a particular context anyway. I think we've pretty much lost the battle for the current implementation of cart-type referring to a particular implementation of a feature, and the parser needs to be context-aware anyway. But if people don't agree, I will gladly grab another bit in cart-type for halt-banked ram. With your size logic, we don't need a SUPER bit either, and can detect SUPER based on size. But the bit adds simplicity to the header parser. IMO it does much the same for header parsers for banksets. Not as much simplicity as the proposed mapper approach would, of course. Originally to @TailChao, but since banksets uses this I feel compelled to reply. To figure out if a destination is somewhere in the range of $4000-$7FFF you only need to monitor+act on 2 address lines. (+1 for the write line, in this scenario) To do the same for 400-4FF (I don't particularly care for sharing address space with the 480-4FF with RIOT ram, but ignoring that for now) and avoid bus conflict with other devices, you're involving at least 5 address lines. (more if you wish to avoid future XMish devices that may be listening at 4xx locations. Of course, said future devices may be incompatible with [email protected] carts anyway, if they always listen to 450, without XMish control registers.) IMO I'd rather use those logic elements on other features, or minimise the cart design cost. The RNG in POKEY isn't a particularly compelling feature to gain. Auto-detection and failback to TIA audio is nice, but I'm not seeing a whole lot of that going on. With the rise of POKEY replacement solutions, I see it becoming even less common. On your later reply, the main problem is any lower address is going to require similar amounts of decoding. Sticking a POKEY at HSC addresses would be more frugal for gates, but problematic for obvious reasons. Upper addresses might be up for game (e.g. write to $C000-$FFFF for pokey) but won't be universal either. e.g. Banksets uses that range so Sally can write to Maria's RAM. I don't think there is a universal mix-and-match solution here for Pokey outside of 4000 that doesn't have design cost or other trade-offs similar to [email protected] (though would love to hear @batari's thoughts) The limitation with this proposal is you would need to bank them all together, so all of the animations would be limited to the same rate, frame-count, and repeating requirements. Also, there are sharp rocks ahead - don't rely on graphics immediately at $8000 for sprites. The Maria DMA memory holes don't extend to below $8000, so non-zone aligned vertical offsets for sprite objects will reveal whatever below $8000, which is either floating bus or something else you don't want displayed. So I'd recommend sticking characters/tiles in this area, if any graphics are going there. Souper or Banksets have this design. (Souper allows for different banks to be active for Sally & Maria) In the case of Banksets, yes, the image seen by Sally goes first, then the image seen by Maria. If Banksets is something you want to explore, I'd recommend holding off for at least a couple weeks. Presently the only emulation support is via pre-release a7800. I'm in the process of getting test roms finished for the emulation/cart devs (nearly there) and formalising an a7800 release. (still some work to do) Loving the innovation
  9. @VinsCool Thanks for sharing. Great you are pushing this tool and adding so much functionality! Really enjoyed what you have illustrated there in this latest video. Some amazing tracks you are creating and/or playing with here! Aside the Battle squadron fav, (sounding great as ever), the starting track is great, (ideal for a medievil adventure game (point and click or platformer maybe). Also love the track from 15mins in: https://youtu.be/rIXwWdlcGX0?t=895 with the fade out at the end. The track 32.50 in https://youtu.be/rIXwWdlcGX0?t=1958 with the leading synth tone running up and down the scale quickly is amazing - love to see this in a game! See you got the excellent Flob game track in there too (56.10 in - love that track). https://youtu.be/rIXwWdlcGX0?t=3370 and the on-the-fly changing of that tune's key and also tempo is cool. Definitely hearing pokey sounds I've not heard of before. My main interest is seeing music and Pokey SFx being utilized in A8 games for atmosphere going forward, as IMHO it's a totally underused element of the A8's hardware. Music and sound effects in games is a hugely important aspect to games. Case in point the sound FX in the A8s Prince of Persia and music track in Flob. (Flob's soundtrack, aside it's signature tune, changes too in the game) Having graphic adventure or action/exploration platform games with "timed" atmospheric/ambient background pokey sounds which come in at key moments and also can fade in and out would greatly enhance a game. Tracks changing to suit a particular element in a platformer or a vertical/horizontal shooter. (Ie a boss encounter, or coming up again an enemy camp). Battle Squadron on the Amiga did this very well. It could be used to an amazing degree in the new 3D raycasting engine based FPS games emerging on the A8. (Just imagine enytering a room in a 3D raycasting based FPS where there is a low level music ambience and or sound fx generated by Pokey and perhaps the occasional sample - (CPU cycles and memory permitting of course). And this changes to add an element of danger, or indicate an encounter with an enemy, etc. Case in point if you have ever played that seminal classic Outcast (1999) on the PC the use of music scores to change the mood and accentuate say a battle, danger or a discovery/reveal is absolutely key. Check it out. Listen to the chilled ambient background music for a few moments at the start of the video then hear it suddenly change to a more sinister track at 14.57 in before the protagonist, (the fatastically named Cutter Slade), engages with the enemy: .........this switch in music make a huge difference to the game's atmosphere. I highly recommend Outcast from 1999. There is also a modern remake with the same gameplay and score but with enhanced graphics available on Steam on the PC. Defo recommend ya'll check it out. (Although I have a soft spot for the original Voxel engine - which incidentally never utilized the graphics card accelleration of cards at the time - it was purely CPU driven). Here is a video comparing the two side by side: Anyways - going off on a tangent here but all this work you are doing is great for pushing the Pokey chip tunes as well as the future of in game music and ambient sound fx IHMO. So glad you are working on this. Tracks and new sounds the like of which you have created clearly proove the A8/Pokey is capable of so much more than bleeps and very rudamentry wobbly sounding chip tunes. (Sorry - I don't know what else to call the traditional wobbly Pokey sound that so many 90's games had). I'd love to hear more synth sounding tracks, (and would still love to see Blade Runner blues tackled..... (can you imagine fading that one in with a long maintained haunting synth sound as close to the original as possible?)) Finally I'll leave you with 2 x Stereo PDM Fujiconvert conversions (For SIDE3's player ) of two of the most amazing tracks from the Outcast game. Crank up the volume: Outcast - 12 - World Of Temples audio alter 3D gain 4 DC offset minus7 16 2 0 5_7 4_6 pdm2 stereo 22135Hz ide pal.pdsOutcast Oriental Spirit_AudioAlter3D gain4 DC offset minus7 16 2 0 5_7 4_6 pdm2 stereo 22135Hz ide pal.pds Full Youtube soundtrack here:hhttps://youtu.be/tkhv-sMTeI0?t=3103 More info about the Outcast Orchestral sound track (by Lennie Moore) here:https://www.greatestgamemusic.com/soundtracks/outcast-soundtrack/
  10. Version 4.00 of my emulator Altirra is out at the usual place: https://www.virtualdub.org/altirra.html As usual, thanks to everyone who tried the releases or just chimed in on just about anything during the 4.00-test series. Never thought I'd been working on it this long, but here's the highlights (it's been about a year since 3.90): Tape: New turbo support, tape editor, and support for loading raw tapes directly from .flac files. Disk: Atari 815 emulation, 8" disk geometry support, Disk Explorer can now access files in Indus CP/M images, many full disk drive emulation fixes. Display: Palette solver, monochrome mode, HDR display support, ANTIC fixes. Sound: Improved audio filtering, automatic output switching when using WASAPI output, POKEY fixes. Input: Preset template generator for making input maps, low-latency paddle option, retuned trackball speeds, 5200 fixes. Devices: Percom AT88-SPD, SIDE 3, 1090 80-column board, Bit 3, virtual FAT16/FAT32/SDFS hard disk; modem, XEP80 and Rapidus fixes. UI: Improved dark mode theme support. Debugger: Memory window upgraded with variable width, type, and graphics decoding support; improved speed, more banked cartridge debugging support, improved 65C816 native mode support, more timestamped logging options, and more verifier options. As usual, 4.00 final is essentially the same as 4.00-test43, except for version number changes and using the release check-update channel. (Previous thread for 3.90/4.00-test) Note that starting with 4.00, Altirra requires at least Windows 7. For Windows XP and Vista users, there is also a 3.91 maintenance release at the above link, which contains backported changes from 4.00 of critical bug fixes and the latest version of AltirraOS. And, per tradition, starting off the 4.10-test series: https://www.virtualdub.org/beta/Altirra-4.10-test1.zip https://www.virtualdub.org/beta/Altirra-4.10-test1-src.7z The device tree now better preserves selection when adding or removing devices. AltirraOS updated to 3.32 with fixes for a couple of compatibility issues with the math pack, so B-Graph and House of Usher now work. Fixes to the docking UI to reduce glitching when switching layouts or toggling full screen mode, due to panes becoming visible too soon and drawing in weird places before being moved to their final location. Fixed a few timing bugs in the standard disk emulator. 810s now produce the head bump sound, the timeout was too short for Record Not Found (RNF) errors, and with long retries the idle timeout was sometimes kicking in too soon. Happy 810 and 1050 now have retuned receive rates. The standard disk emulator now attempts to emulate track buffering for the Happy 810, 1050, and Speedy 1050 profiles, where the drive will burst transmit sectors from memory after reading in new tracks. This makes timing closer to the default modes for those drives. The Happy 1050 commands for toggling track buffering are now also support.
  11. Hey there, it's been a while since I last posted in this thread. So tonight while I was playing in some of my experimental stuff involving a MIDI controller and Raster Music Tracker, I accidentally discovered what appears to be a POKEY emulation bug involving the 16-bit timing using the AUDCTL Join Channel bits, while also outputting volume on the LSB 16-bit channel (something lovingly nicknamed Reverse-16 Output). How could I describe it and still make sense? Well to make a short description, modulating the 16-bit frequencies, while outputting the sound in the LSB channel outputs a unique kind of tone, and it does have a lot of nice musical application with enough dedication, notably, creating a harmonic tone in a pulse/distortion motion, that would also be exactly 1 octave higher than the actual 16-bit tone underneath, so this is a somewhat predictable effect, making use of the 2 pair of 16-bit channels. Well, here's when things took me by surprise: I noticed the sound output from the ch1+2 and ch3+4 pairs is very different to each others! Specifically, only the ch1+2 pair does seem to sound correct, the other would seem to output the exact same pitch that would be in the MSB 16-bit channel output, and it would also crackle a lot whenever a single POKEY register would receive new data, for some reason. I spent a bit more time earlier tonight to see if this was a normal occurrence, or if I was responsible for the bug in question, and to my surprise, this appears to be a bug present in Altirra for a really long time! I tested versions from the most recent test build, all the way back to 2.80, and as far as I could tell, the behaviour in question (that is, the ch1+2 and ch3+4 pairs having a big disparity in sound output) seems to have been introduced in version 2.90. Version 2.81, 2.80, and most likely further down, did not actually feature this difference, both pairs of channels will sound identical, but unfortunately the emulation accuracy of the Reverse-16 sound is also lower. Also, I did test the exact same setup on real hardware, using both my PAL and NTSC Atari 800xl, and they do not suffer from the disparity-- each pairs of Reverse-16 channels will always sound identical. Same for the Atari800 emulator, it sounds pretty much exactly the same as hardware, in this specific setup. TL;DR: The Reverse-16 output is most likely incorrectly emulated between channels, where CH1+2 is the only one sounding proper, while the other pair is very off. What is expected to happen is that regardless of the 16-bit pairs, the sound should be identical, as far as hardware comparisons went to confirm this was not something I caused myself earlier. --- Anyway, how to reproduce the effect in question? Written below is a simple way to hear what is going on, and this was also how I tested for the disparity going on for every version/platform I tested it, including RMT (where I initially noticed it): - Using POKEY Explorer is the fastest and easiest way to showcase the bug, so first, simply load the .xex in Altirra/hardware/etc - Next, set the 4 AUDF channels to the following frequencies, in this order: $FF, $01, $FF, $01 - Now, press the J and K keys, this will activate the Join Channels 16-bit mode to both pairs, still running in 64Khz mode Once these initial steps are complete, do the following, and you will immediately notice what I am talking about: - Firstly, increment the volume level in channel 1 using the 2 key to a audible level - Next, start decrementing the channel 1's AUDF value using the Q key - What will then happen is the Reverse-16 sound in action, and this should sound exactly as expected The pitch will go higher, while also the pulse wave will change its shape to modulate a different timbre as the frequency is being shifted. - Once you are satisfied of what was heard, lower the ch1 volume back to 0 using the W key, in order to test the ch3 for the same setup - Now, increment the ch3's volume level the same as before, using the 6 key - And just like before, lower the ch3's AUDF using the T key, and listen carefully the sound that will be output From this point onward, 2 things may happen: - The sound produced is exactly the same in either ch1+2 or ch3+4 pairs --EXPECTED Or - The sound produced in the ch3+4 pair is very garbled each time a tiny change is applied, and appears to be identical to the underneath 16-bit tone if it was output the intended way --INCORRECT The second one is exactly what happens in Every Altirra versions I tested, all the way down to the version 2.81, at this point, the 2 channels pairs will sound the same, but with lesser accuracy to what it should sound like on hardware. --- And that's about it, if reading this much text sounds a bit boring, here's the RMT capture I made when I first noticed the behaviour: simplescreenrecorder-2022-05-28_22.04.18-CUT.mp4 While it is not truly the Altirra emulator, I can say for sure this is 100% identical to what the stand alone emulator also did, before I went ahead and gave a more indepth testrun. Also, for further precision, the Altirra emulation core running through the plugins used in this recording came from the version 4.00. So yeah, like I said above, what is expected, and should happen, is that the ch1+2 and ch3+4 output must be identical, fact backed up with hardware tests a few minutes later. Thanks for reading a bit of rambling, I hope this may help tracking down why this is happening.
  12. E.X.O. is complete. (woohoo) Release Candidate Demo A The demo is limited to the first two worlds and the first two bosses and saving functionality is disabled. Other than that you have the full experience, nothing is cut from the levels or bosses EXO is a 512KB binary with 16KB RAM + POKEY - It is NTSC and PAL compatible out of the box and works on Dragonfly with POKEY/POKEYMAX on real hardware, and on MiSTer PAL and NTSC Cores. It does not work on Concerto currently due to the ROM size. Emulation : Testing and working fine under BUP, A7800, JS7800 & Argon - Please note the Music comments below. The release candidate has had a few tweaks and changes since the demo from July and I'm very pleased to be able to provide a demo for folks to test. The only real changes I plan to make from here are fixing any bugs that pop up between now and release and removing the temporary demo title page etc. We might also have to tweak the music depending on how HOKEY testing goes. Updates for Release Candidate A - December 2021 ⦁ Significant amount of balance tweaks made across the whole game. ⦁ Palette tweaks to avoid colours that do not play well on LCD displays. ⦁ Extra POKEY tunes (now 15 up from 13) ⦁ World 5 is complete and implemented. ⦁ 5 boss fights now implemented. ⦁ AtariVox speech on boss fights. A note on POKEY music : Please note that quite a few of EXO's tunes do not sound right under emulation. This is just the maturity of POKEY emulation in the currently available emulators. If the music sounds odd - it's the emulation. Elite Xeno Operations - Full feature list : ⦁ 5 full worlds for the player to explore and defeat, each with unique a graphical theme and environment, from industrial factories to ruined ancient temples. ⦁ 5 end of level bosses to defeat. ⦁ 4 hidden Key Stones to unlock. ⦁ 15 Pokey Tunes for your audio enjoyment. ⦁ More than 100 screens in total. ⦁ HSC, AtariVox and Savekey support for saving progress and unlocks (3 save slots). ⦁ AtariVox speech supported for boss fights. ⦁ Cinematic Viewer so that you can revisit past glories. ⦁ Comprehensive "how to play" tutorial in game. ⦁ Unlockable Easter Eggs such as the POKEY music player. ⦁ Fully PAL compatible and adjusted. ⦁ 32kb of music and sound effects, over 80kb of graphics. Enjoy EXO_Release_Cand_Demo_A.a78
  13. Welcome to Atari Dev Studio for designing homebrew games for the Atari 8-bit systems (Atari 2600 and 7800). Atari Dev Studio is a one-stop-shop for any programmer and includes a number of built-in features to allow you to design, develop and test games for your favourite system. Get started with batari Basic (2600) or 7800basic (7800) using easy to learn BASIC-like languages or go hard-core with assembly using dasm. During development test your creation using the Stella (2600) or A7800 (7800) emulators right from within Atari Dev Studio. Requirements Atari Dev Studio is an extension for Microsoft's cross-platform IDE Visual Studio Code and will run on the Windows, Linux and macOS platforms. The latest releases of batari Basic, 7800basic, dasm, Stella and A7800 are included so you can begin coding straight after installing the extension. Features Atari Dev Studio includes the following features: Develop your game on Windows, Linux or macOS Compile source code for your Atari 2600 or 7800 using batari Basic, 7800basic or dasm Use scripting (makefile, batch or shell script files) to build your dasm projects [preview] Optionally launch and test your game using the Stella (2600) or A7800 (7800) emulators Document outline support (batari basic, 7800basic, dasm) Peek/Go to Definition and Reference support (batari basic, 7800basic, dasm) Built-in Sprite Editor (also suitable for tiles and other objects) [preview] Manage your project using the File Explorer or version-control your source code directly with GitHub (and others) using the built-in features of the Visual Studio Code platform. Provide references to your own specific releases of each language or emulator rather than use the includes ones via the Settings. Additional features are planned for the future. At this time the focus is on the core functionality and ensuring full cross-platform support. Installing Atari Dev Studio What is Visual Studio Code? Visual Studio Code (VS Code) is a streamlined code editor with support for development operations like debugging, task running, and version control. It aims to provide just the tools a developer needs for a quick code-build-debug cycle and leaves more complex workflows to fuller featured IDEs, such as Visual Studio. Which OSs are supported? VS Code is a cross-platform application which runs on Windows, Linux and macOS. See requirements for the supported versions. Note: Linux users on 64-bit systems will be required to install the 32-bit compatibility libraries on your system to ensure everything will run as expected. Note: macOS users will require a 64-bit operating system to fully utilise all features of Atari Dev Studio and will be required to install the SDL libraries on your system to ensure the A7800 emulator will run as expected. Note: M1 based Mac users will need to install the INTEL CHIP version of VS Code before installing Atari Dev Studio. The current dev stack is incompatible with the M1 chip for the time being. See here for further discussion around the potential issues you will encounter. Installing the extension Once you have installed VS Code (available here), open the VS Code program and complete the following: From the Activity Bar, click the Extensions button to display the Extensions window. From the Extensions window, type Atari into the Search box and press Enter to display the list of available extensions. From the list of available extensions, locate Atari Dev Studio and click the green Install button. Updating the extension Updates will be regularly provided and you will be notified via VS Code when one has been made available. Once an update has been installed you will generally be prompted to restart VS Code. Using Atari Dev Studio Compiling your program To display the available extension features press CTRL+SHIFT+P to display the Command Palette. From the command palette prompt type adv to short-list the available options: ads: Open the Welcome page ads: Compile source code (Shift+F5) ads: Compile source code and run in emulator (F5) ads: Kill build process ads: Open the Sprite Editor Language Selection When you load a file the initial language will be chosen based on the file extension. For example: batari Basic (.bas, .bb) [Default for .bas files] 7800basic (.bas, .78b) dasm (.dasm, .asm, .a, .h) To change a language you can click on the Status Bar Language selector and a list will be shown allowing you to choose another language. Optionally in the Settings you will be able to either let the extension choose based on the active language or set a specific language to always compile against. Build scripts [preview] Prefer using scripts to build your dasm games? If you have chosen to override the dasm compiler (select Make via the Settings) , Atari Dev Studio will scan and detect for makefile, batch (makefile.bat) or shell scripts (makefile.sh) files which are located in your root workspace folder to build your game. Note: You are totally responsible to ensure your environment is properly configured to allow you to utilise the tools and applications you will be interacting with. No support will be provided for this feature. Status Bar Apart from using the Command Palette to select compilation, there are a number of short-cut buttons on the Status Bar allowing you to: Display the extension version (might be useful at times) Open the Welcome page Open the Sprite Editor Compile source code (Shift+F5) Compile source code and run (F5) Note: The short-cut buttons on the Status Bar can be turned off via the Settings. Sprite Editor [preview] Atari Dev Studio includes a simple and easy to use Sprite Editor allowing you to create sprites, tiles and other objects for use in your projects. It has the following features: New Project wizard allowing you to select the console (2600 or 7800), size, region (NTSC or PAL palette) and total colors of your sprites Load and Save projects allowing you to save and come back to on-going work Editing features such and palette selector, zoom, pen, eraser, fill and move modes Ability to manage your sprites in a sortable list with options to copy, paste, duplicate, resize and delete Export sprites to batari Basic or assembly source code (2600) Export sprites to .png files (7800) - either selected or all (compatible with 7800basic 3+1 and 12+1 image requirements) Load and save palettes The Sprite Editor is based on Spritemate by Ingo Hinterding (GitHub) and was suggested by RandomTerrain for inclusion in Atari Dev Studio. I have customised the source to provide the required features necessary for editing sprites, tiles and objects for the Atari platforms. This work is currently in preview and will be on-going until all required features have been added. Settings There are a number of compiler, emulator and editor configuration options available in Atari Dev Studio which can be changed via the Settings (Preferences -> Settings -> Extensions -> Atari Dev Studio). Debugging the extension During the development phase of the extension I've added some developer output to assist with any issues that may appear. To view this output, open the VS Code Developer Tools by selecting Help -> Toggle Developer Tools from the menu, and in the debugger window ensure the Console tab is activated. This information may help identify the area where the extension is failing to process as expected. Known Issues There are currently no known feature issues. If you find a problem please raise an issue on GitHub or contact mksmith at the AtariAge community. Acknowledgements This extension is only available due to the great people of the AtariAge community who have created these tools to help developers build their vision. Special thanks to the following for either allowing the inclusion of their tools or for their ongoing help and encouragement: 7800basic - Mike Saarna (RevEng) batari Basic - Fred 'batari' Quimby and Mike Saarna (RevEng) dasm - the many contibutors Stella emulator - Stephen Anthony (stephena) A7800 emulator - Mike Saarna (RevEng) and Robert Tuccitto (Trebor). The AtariAge community including Albert, CPUWiz, Random Terrain, Trebor, Synthpopalooza, sramirez2008, Defender_2600, Gemintronic, Karl G, ZeroPage Homebrew, Muddyfunster, TwentySixHundred, Lillapojkenpåön, Andrew Davie, splendidnut, andyjp, sexyUnderwriter, MikeBrownEmplas, Generation2Games, cwieland, slacker Mats Engstrom (SmallRoomLabs) Languages Atari Dev Studio includes the following programming languages: batari Basic (release 1.7 - 20220703) batari Basic created by Fred 'batari' Quimby is a BASIC-like language used in the creation of Atari 2600 games. batari Basic is compiled to generate a binary file that can by used on actual Atari 2600 VCS hardware via cartridge (such as a Harmony or UNO cart) or by using an Atari 2600 VCS emulator such as Stella. batari Basic is an external project is kindly currently maintained by Mike Saarna (RevEng) and can be downloaded separately from here. Further information is about this release is available here at AtariAge. 7800basic (release 0.19 - 20211231) 7800basic is a BASIC-like language for creating Atari 7800 games. It is a compiled language that runs on a computer, and it creates a binary file that can be run with an Atari 7800 emulator, or the binary file may be used to make a cartridge that will operate on a real Atari 7800. 7800basic is derived from batari basic, a BASIC-like language for creating Atari 2600 games. Special thanks to the bB creator, Fred Quimby, and all of the bB contributors! 7800basic is included as part of this extension with many thanks to Mike Saarna (RevEng). 7800basic is an external project and can be downloaded separately here. Further information about this release is available here at AtariAge. dasm (release - 20201109) dasm is a versatile macro assembler with support for several 8-bit microprocessors including MOS 6502 & 6507, Motorola 6803, 68705 & 68HC11, Hitachi HD6303 (extended Motorola 6801), and Fairchild F8. Matthew Dillon started dasm in 1987-1988. Olaf 'Rhialto' Seibert extended dasm in 1995. dasm has also been maintained by Andrew Davie (2003-2008) and Peter Froehlich (2008-2015). The DASM team has taken over maintaining and updating dasm since 2019. dasm is an external project and can be downloaded separately here. Emulation Atari Dev Studio includes the following emulators for testing purposes: Stella (release 6.7.0 - 20220613) Stella is a multi-platform Atari 2600 VCS emulator released under the GNU General Public License (GPL). Stella was originally developed for Linux by Bradford W. Mott, and is currently maintained by Stephen Anthony. Since its original release several people have joined the development team to port Stella to other operating systems such as AcornOS, AmigaOS, DOS, FreeBSD, IRIX, Linux, OS/2, MacOS, Unix, and Windows. The development team is working hard to perfect the emulator and we hope you enjoy our effort. Stella is included as part of this extension with many thanks to Stephen Anthony. Stella is an external project and can be downloaded separately here. If you enjoy using Stella place consider donating to ensure it's continued development. A7800 (release 5.2 - 20220626) A7800 is a fork of the MAME Atari 7800 driver, with several enhancements added: Support for emulation of Proline Joysticks, VCS Joysticks, Lightguns, Paddles, Driving Controllers, Keypads, Trak-Balls, Amiga Mice, and ST Mice. Support for emulation of Proline Joysticks, VCS Joysticks, Lightguns, Paddles, Driving Controllers, Keypads, Trak-Balls, Amiga Mice, and ST Mice. Maria DMA timing has been improved further, with the addition of accurate DMA hole penalties. Selectable and improved palettes with enhanced screen options. Streamlined UI including menu options to have an Atari 7800 system focus. A bug in the existing RIOT emulation has been fixed. POKEY sound emulation improvements. SALLY (CPU) and MARIA (Graphics chip) performance adjustments. Audio indication of no ROM loaded silenced. BIOS files no longer required and made optional. Implementation of XM control registers updated. Graphical register updates made mid-scanline are now displayed mid-scanline. Bankset bankswitching support added. [email protected] added for non-banked, supergame, and bankset formats. Machine targets a7800dev and a7800pdev added, which display DMA usage per-scanline. MAME compatibility and syntax has been maintained, to allow for the reuse of MAME configuration files and front-ends. A7800 is included as part of this extension with many thanks to Mike Saarna (RevEng). A7800 is an external project and can be downloaded separately here. Further information about this release is available here at AtariAge. Releases 20220702 - Build v0.7.8 20220628 - Build v0.7.7 20220627 - Build v0.7.6 20220614 - Build v0.7.5 20220504 - Build v0.7.4 20220401 - Build v0.7.3 20220101 - Build v0.7.2 20210422 - Build v0.7.1 20210315 - Build v0.7.0 20210305 - Build v0.6.9 / 20210216 - Build v0.6.8 / 20210210 - Build v0.6.7 / 20201124 - Build v0.6.5 / 20201008 - Build v0.6.4 / 20200917 - Build v0.6.3 / 20200915 - Build v0.6.2 / 20200912 - Build v0.6.1 / 20200901 - Build v0.6.0 20200829 - Build v0.5.9 / 20200624 - Build v0.5.8 / 20200622 - Build v0.5.7 / 20200616 - Build v0.5.5 / Build v0.5.6 / 20200608 - Build v0.5.4 / 20200518 - Build v0.5.3 / 20200508 - Build v0.5.2 / 20200429 - Build v0.5.1 / 20200427 - Build v0.5.0 20200415 - Build v0.4.9 / 20200415 - Build v0.4.8 / 20200414 - Build v0.4.7 / 20200409 - Build v0.4.6 / 20200407 - Build v0.4.5 / 20200323 - Build v0.4.4 / 20200321 - Build v0.4.3 / 20200317 - Build v0.4.2 / 20200316 - Build v0.4.1 / 20200314 - Build v0.4.0 20200314 - Build v0.3.9 / 20200312 - Build v0.3.8 / 20200307 - Build v0.3.6/v0.3.7 / 20200305 - Build v0.3.5 / 20200217 - Build v0.3.4 / 20200129 - Build v0.3.3 / 20200128 - Build v0.3.2 / 20200108 - Build v0.3.1 / 20191022 - Build v0.3.0 20190807 - Build v0.2.8 / 20190711 - Build v0.2.7 / 20190614 - Build v0.2.5 / 20190611 - Build v0.2.4 / 20190604 - Build v0.2.3 / 20190528 - Build v0.2.2 / 20190522 - Build v0.2.1 / 20190521 - Build v0.2.0 20190513 - Build v0.1.9 / 20190510 - Build v0.1.8 / 20190506 - Build v0.1.7 / 20190428 - Build v0.1.6 / 20190425 - Build v0.1.5 / 20190421 - Build v0.1.2 & v0.1.3 / 20190420 - Build v0.1.1 20190419 - Build v0.1.0 - Initial release Manual download
  14. Hello, since I got back into Atari and discovered the excellent Mad Pascal compiler, I fell into programming again .. so here’s my first Atari program since Atari BASIC programs in the late eighties, also my first pascal program again after .. decades? My target is Ultima V: I was envious in the late 80ies when I saw it at my C64 owning friends - I was impressed by that open world RPG approach!; where I sat at home with my 800 XL without much access to software, fiddling around with some BASIC.. So now - decades later – I can find remedy with the power of Mad Pascal, by writing my own Ultima V port Of course port is a much too big word! It almost certainly will never reach the state of a full game. What you can do is to explore the Lands – an Seas - of Britannia; visit it’s famous towns, mighty castles & picturesque villages! Some basic interaction with the world is possible – rearrange your room, go eat out at one of the many taverns or maybe you care to play 'Stones' on the harpsichord? (See splash screen for the available commands) As I’m in PAL land, I never had the possibility of mode F artifacting on real HW, like it was done in Ultima IV. Also I think that a more colourful approach would be nice: so the idea to use ANTIC mode E for the map viewport, with a 13x10 grid - widescreen! (The original is11 x 11). A tile consist of 12x16 pixel. I converted them from the original assets – available on the net – from 16x16x4c down; and did some basic manual retouching. I’m not good at graphics, so I guess there’s great potential left in the tile design if a real pixel artist would put his hands on that. What I tried though is to make use of “PAL blending” to create a fifth color – grey - and used that for walls, rocks, mountain, .. Another future possibility is to do some PM “augmentation” to the tiles, similar like it is now done for the Avatar tile. Adding red for torches, fires and the like would be an ideal candidate, since it would even look like by design should it flicker The text and info ‘console’ is layout below the map (instead as on the right side like in the original), using mode 2. I extended the displaylist from the standard 192 to 216 scanlines to make more room.. I could only test NTSC with Altirra, where it seems usable still. The attached ATR is a 180K DD mydos disk using xBootDOS. I did not include the original .DAT files that are needed by the program, since I guess that they are still under EA copyright: You would have to copy them by yourself on the disk; I used the files from MSDOS version that GOG offers. The files currently needed are: BRIT.DAT CASTLE.DAT DWELLING.DAT KEEP.DAT TOWNE.DAT (the program will created index files at the first run and tell you if it misses a certain file) I’ll be glad to share the sources and assets if there is interest! (Just needs some clean up first as it grew in all direction while writing and learning) Big thanks to @tebe, @jac!, @gury & @xxl for their development tools that I’m using, and the whole Atariage 8-bit forum for the tons of information I’m getting from here! Thank you! So, what do you think of the idea of doing an Ultima V engine in such a layout? PS: I was looking for pokey conversions of Ultima songs, but could not find any.. maybe someone knows more about that? Music would be a great addition! ULTIMAV_WorldExplorer_v0.01.atr.7z
  15. Version 3.90 of my emulator Altirra is out: http://www.virtualdub.org/altirra.html Thanks for everyone's continuing support, whether it be bug reports, feature requests, discussion, trying out the helper programs on real hardware, etc. 3.90 final is essentially the same as 3.90-test34, except for release changes. Although previous versions tended to be about six months apart, it's almost been a year since 3.20, so I figured I'd better hurry up. Highlights of the 3.90 release: Accuracy: 800 System Reset timing fixed, undocumented RMW and WSYNC timing fixes, several fixes to 65C816 direct page wrapping and Veronica, many fixes to FDC/RIOT/6809 for full disk drive emulation, improved POKEY two-tone mode emulation, more accurate power-up hardware state. Debugger: Improved disassembly window with automatic block separation and inline call target preview, more disassembly options, better loop detection in the history window, Alt+Shift+click to jump to history for a pixel. Disk drives: 810 Turbo, Amdek, and Percom AT-88 full emulation; easier file import/export in the Disk Explorer. Display: Improved PAL artifacting and color defaults, gamma-corrected frame blending, color setting import/export, PERITEL and monochrome monitor emulation, fixes to color correction logic (esp. with VBXE). Firmware: Updated AltirraOS 3.26 for improved compatibility with hardware addons and software, improved autodetection for custom OS ROMs. Tape: Faster emulation especially in warp mode, audio filter compensation for better turbo decoding, and enhanced debugging for tape issues. Video recording: Aspect ratio correction, scaling, and direct H.264/WMV compression support through Media Foundation. UI: Dark theme, improved audio monitor/scope, improved timing for slightly reduced latency. With 3.90 done, it's now time to start the 4.00 test series: http://www.virtualdub.org/beta/Altirra-4.00-test1.zip http://www.virtualdub.org/beta/Altirra-4.00-test1-src.zip First, there are a couple of breaking changes in 4.00: End of support for Windows XP SP3 and Vista. The new minimum operating system requirement is Windows 7 SP1. End of support for DirectDraw, which has not been native since Vista, and OpenGL, of which only old versions were used anyway (and was not enabled by default). New features and fixes: Palette solver: Matching color palettes in Altirra has been a long-standing issue, since it is unable to take .pal/.act files due to needing the generation parameters for the palette rather than the final colors for various features, and matching colors from real hardware is a difficult task. Pretty much everyone has their opinion on what "true colors" should be. Well, in 4.00-test1 there is now a solver to guess the parameters for you: You can either give it a PAL/ACT file, or you can give it a picture -- and although the picture needs to be a good one, it doesn't have to be perfectly straight as you can align it to compensate for projection by dragging the corner dots. It's compatible with any show-palette tool for the Atari that does 16 lumas across and 16 hues down. Click Match, and it'll start grinding on the parameters to try to get as close as possible, and tell you how good the match is. Or, you can have it overlay the current palette as dots over the picture to check the palette while manually tuning it. Debugger: On-screen watches now update continuously while stepping and the 'wx' command has options for hex formatting, bank-sensitive debugging is now supported for SpartaDOS X cartridges, improved handling of subdirectories when looking for source files, and the console output window is faster when flooded with output. Oh, and the Memory window has been improved with scrolling and more display options: Display: Added pure white monochrome mode, and fixed a bug in the high artifacting engine where chroma artifacts moved in the wrong direction for ascending hues. XEP-80: Fixed an emulation bug in the way that scrolling occurs, and added a couple of new toys to the Additions disk: an XEPVHOLD.COM tool to reprogram the XEP80's timing chain for a shorter display that's less likely to roll on modern displays, and a new ultra-speed ALTXEP8U.SYS driver that runs at symmetric 31.5Kbaud instead of 15.7K or 31.5K send / 15.7K receive. Tape: Added support for KSO Turbo 2000. Disks: Added emulation for the Percom AT88-SPD, and added 1791/1795 FDC selection for the AT-88. Fixed support for virtual SpartaDOS disks with directories and files whose names start with periods. Added a polling workaround option for virtual disks for environments where file change notifications don't work (some Wine environments). Audio: More accurate emulation of uneven volume bits, and rewrote cycle-level filtering emulation for improved high frequency aliasing rejection during downsampling. UI: Dark mode now has reskinned buttons. Added support for auto-hiding the menu bar. Fixed mouse wheel scrolling when the OS page-at-a-time option is on. H: device: Lifted 16MB limit for binary (untranslated) access, and fixed errors not being returned properly during burst I/O accesses. AltirraOS 3.27: Fixes to the printer handler for EOL handling, particularly for the Atari 1025, and improved compatibility of variable usage to work with Monkey Wrench II. Custom Devices: More scripting language constructs like break, while/do-while loops, and forward declaration of functions, better threading support, and more scripting methods for manipulating memory. Custom devices can now raise Parallel Bus Interface IRQs. Custom video outputs can now be created with either text or graphical output, and even support text select/copy like the emulator's built in ANTIC and XEP-80 video outputs. New sample custom devices: Bit-3 80 column, 1090 80-column, and a PBI-based metronome.
  16. Both NTSC and PAL tuning tables Pokey Explorer uses, are calculated by https://github.com/ivop/pokey-explorer/blob/master/util/genfreqtab.c I believe my tables are correct. How does your COMPUTE! table compare to https://github.com/ivop/pokey-explorer/blob/master/tuning-16bit-ntsc.s ?
  17. So ... I took some of the generated notes, and compared them to the tuning note in Pokey Explorer, and I noticed that on the lower registers, some of them are just a step out of phase. I wonder if the note table I am using is tuned properly. I copied the original 16-bit $Ax table from an old COMPUTE! article, but it may need to be rechecked for accuracy. If the $Ax 16-bit note table is indeed accurate (as I think it is) there may be a slight frequency error on the lower frequencies. On $0101, when you get up to about C3 it's pretty much spot on
  18. I have a new build ready to share. This version includes the addition of a death explosion animation for our space man and a few sound effects for firing your gun and during the explosion. I also made some performance related changes. As I was testing the previous build and making some changes, I noticed our first performance related issue pop up, and I had to do a little troubleshooting. I was noticing a little bit of graphic artifacting at the bottom of the screen, and after I added the animation for the death of the space man the normal graphic on-screen for the space man was no longer displaying correctly. Knowing that I was already pushing the limit of sprites on screen, first I removed the first aid sprite from the screen. It didn't completely resolve the problem, but since I hadn't implemented it yet I decided to leave it out altogether. The graphic import and plotsprite commands for sprite_firstaid1.png as well as the variable assignments for it were removed from the code. I remembered from past experience that how graphics blocks are organized is important. I know for a fact that animated sprite images must all be in the same graphics block. As a test, I used the "newblock" command to divide up the sprites into three separate graphics blocks - one for title screen graphics, one for the junk sprites, and one for the spaceman and explosion images. Once I added the newblock command in, the display issues for the spaceman disappeared. That took care of the problem. Below is how our images are now laid out in the graphics blocks. INFO, GFX Block #0 starts @ $8000, has 448 bytes left (28 x 16 bytes) scoredigits_8_wide tileset_stars1 tileset_planet1 spacejunk_title00 spacejunk_title01 spacejunk_title02 INFO, GFX Block #1 starts @ $A000, has 1856 bytes left (116 x 16 bytes) spacejunk_title03 spacejunk_title04 spacejunk_title05 sprite_7800basic200 sprite_7800basic201 sprite_firetobegin INFO, GFX Block #2 starts @ $C000, has 3440 bytes left (215 x 16 bytes) sprite_satellite1 sprite_satellite2 sprite_invader1 sprite_alien sprite_chip1 sprite_rocket1 sprite_rocks1 sprite_rocks2 sprite_rocks3 sprite_rocks4 sprite_debris1 sprite_debris2 sprite_debris3 sprite_debris4 sprite_debris5 sprite_debris6 sprite_debris7 sprite_debris8 sprite_debris9 sprite_bullet INFO, GFX Block #3 starts @ $E000, has 3456 bytes left (216 x 16 bytes) sprite_spaceman_left sprite_spaceman_right sprite_explode1 sprite_explode2 sprite_explode3 sprite_explode4 sprite_explode5 sprite_explode6 sprite_explode7 sprite_explode8 Unfortunately, the display glitch was still evident in the game. I wasn't sure of the cause, so I ran the issue by RevEng. He reminded me that for performance issues, the best practice you can use to avoid performance issues is to place all of your general game logic right after the drawscreen, which is the start of the visible screen. This means game logic runs during the visible screen, which represents a large percentage of the CPU time. With that in mind, I relocated all of the any plot* commands until right before the drawscreen command (at the end of the code). If the screen is being drawn, a plot* command wastes time until the screen isn't being drawn. You need try and minimize any other game logic once you have started with the plot* commands. Once I relocated all of the plot* commands to the end of the code the graphical glitch on the screen went away. Problem solved! As a side note, especially if the above tip doesn't resolve your problem, you can alternatively explore the use of double-buffering, which frees you from locking the game to the framerate, but if you have a lot of game objects it pretty much requires on-cart or XM RAM. I'm not planning on using double-buffering unless it becomes a necessity, but you can review how it's used in the doublebuffer sample that RevEng includes in the samples directory of the official 7800basic distribution. Now, on to the code changes I made in this revision. Variable Assignments Because my goal was to add a death animation to the space man, I knew I'd have to assign a variable that would be used to count the frames in the explosion. I assigned "exploldeanimframe" to var90 for this purpose. dim explodeaniframe =var90 :rem frame counter for explosion animation Image Imports Several changes were made in the "Import" section of the code. I explained earlier that I added two newblock statements to manually divide the graphics blocks how I wanted them. In addition, I imported 8 new image files that are used for the explosion animation for the spaceman, sprite_explode1 - sprite_explode8. Obviously, it's an 8 frame animation. It's important to note that the animation will run in the order that you import the sprites. import ; Here we import all of the indexed image files ; Banner images require that you specify the display mode and index colors incgraphic scoredigits_8_wide.png incgraphic tileset_stars1.png incgraphic tileset_planet1.png incbanner spacejunk_title.png 160A 0 1 2 3 incbanner sprite_7800basic2.png 160A 0 1 1 1 incgraphic sprite_firetobegin.png newblock incgraphic sprite_satellite1.png incgraphic sprite_satellite2.png incgraphic sprite_invader1.png incgraphic sprite_alien.png incgraphic sprite_chip1.png incgraphic sprite_rocket1.png incgraphic sprite_rocks1.png incgraphic sprite_rocks2.png incgraphic sprite_rocks3.png incgraphic sprite_rocks4.png incgraphic sprite_debris1.png incgraphic sprite_debris2.png incgraphic sprite_debris3.png incgraphic sprite_debris4.png incgraphic sprite_debris5.png incgraphic sprite_debris6.png incgraphic sprite_debris7.png incgraphic sprite_debris8.png incgraphic sprite_debris9.png incgraphic sprite_bullet.png newblock incgraphic sprite_spaceman_left.png incgraphic sprite_spaceman_right.png incgraphic sprite_explode1.png incgraphic sprite_explode2.png incgraphic sprite_explode3.png incgraphic sprite_explode4.png incgraphic sprite_explode5.png incgraphic sprite_explode6.png incgraphic sprite_explode7.png incgraphic sprite_explode8.png incmapfile spacejunk.tmx characterset tileset_stars1 Main Loop Changes While I didn't change a whole lot in the gameplay, there were numerous changes to the code in the main loop, some of which were repetitive changes where I'd change one simple thing in many different places. With that in mind, I'll describe the change with one line of code rather than pasting in everything. Collision Detection In the collision detection block of code, I removed the "goto losealife" that was at the end of each line. I changed that subroutine completely, as the prior code was more intended to pause the game and show how a collision was registered and I don't want that in the actual finished game. That subroutine now simply resets variables. Lives are now decremented in a single line of code when the death animation is triggered later on. ; Detect collision between spaceman and alien if boxcollision(spaceman_xpos,spaceman_ypos,13,13, alien_xpos,alien_ypos, 15,15) then alien_xpos=200 :alien_ypos=200:lives=lives-1:goto losealife <removed> ; This section of code detects collisions between the spaceman and all of the space junk sprites if boxcollision(debris1_xpos,debris1_ypos, 6,14, spaceman_xpos,spaceman_ypos, 13,13) then debris1_xpos=200 :debris1_ypos=200 :debris1_flag=1:lives=lives-1:goto losealife <removed> Plotsprite location The main difference in the plotsprite section is that it's been moved. I cut and paste the entire block of code with all of the plot* commands and pasted it in at the very end of the main loop, immediately before the drawscreen. Changes related to explosion animation I made a few other changes near the end of the code, all related to accommodating the inclusion of the new death animation, starting at line 571. First, I added a line to skip over the code that controls the spaceman movement, the joystick direction detection, and bullet firing while the death animation is active. We don't want the player to be able to move around the screen and fire when the sprite is in the middle of exploding. In the same first line, I also reset the location of the bullet off the screen, it otherwise would remain at the home location and be visible behind the explosion animation. Here’s an image of what all 8 of the death animation frames look like: Next you'll see I added some sound effects to the code that fires your gun. This is accomplished with the "playsfx" command, followed by the name of the subroutine that contains the audio data. I also added a random number to the end of the sound effect to vary the pitch when it's played. I'll get to more detail on sound effects a little later. ; If the explosion animation is running for the space man, we don't want him to be able to move around or fire. ; We also temporarily reset the location of the bullet, or we'll see it behind the explosion animation. if spaceman_flag=1 then bullet_fire_xpos=200:bullet_fire_ypos=200:goto skip_spaceman_move ; This block of code checks to see if you've changed joystick directions. If so, the bullet is stopped and reset. ; First Line: If Joystick is being pushed up, and the last push was not up, then reset the bullet to the home location. if joy0up && joyposup=0 then bullet_fire_xpos=spaceman_xpos-1:bullet_fire_ypos=spaceman_ypos+8 if joy0down && joyposdown=0 then bullet_fire_xpos=spaceman_xpos-1:bullet_fire_ypos=spaceman_ypos+8 if joy0left && joyposleft=0 then bullet_fire_xpos=spaceman_xpos-1:bullet_fire_ypos=spaceman_ypos+8 if joy0right && joyposright=0 then bullet_fire_xpos=spaceman_xpos-1:bullet_fire_ypos=spaceman_ypos+8 ; This block of code moves your Space Man, and sets a flag for the currently pressed joystick direction ; The direction flag is used to determine the direction the bullet is fired later on if joy0up1 then spaceman_ypos=spaceman_ypos-1:joyposup=1:joyposdown=0:joyposleft=0:joyposright=0 if joy0down1 then spaceman_ypos=spaceman_ypos+1:joyposup=0:joyposdown=1:joyposleft=0:joyposright=0 if joy0left1 then spaceman_xpos=spaceman_xpos-1:joyposup=0:joyposdown=0:joyposleft=1:joyposright=0 if joy0right1 then spaceman_xpos=spaceman_xpos+1:joyposup=0:joyposdown=0:joyposleft=0:joyposright=1 ; Here we set a temporary variable to fluctuate the pitch of the gun firing sound. temp7=rand&3 : rem set temp7 to a random number from 0-3 ; Based on the most recent direction the joystick was pushed, fire the bullet in that direction if joy0fire && joyposup=1 then bullet_fire_ypos=bullet_fire_ypos-4:playsfx sfx_gunfire temp7 if joy0fire && joyposdown=1 then bullet_fire_ypos=bullet_fire_ypos+4:playsfx sfx_gunfire temp7 if joy0fire && joyposleft=1 then bullet_fire_xpos=bullet_fire_xpos-4:playsfx sfx_gunfire temp7 if joy0fire && joyposright=1 then bullet_fire_xpos=bullet_fire_xpos+4:playsfx sfx_gunfire temp7 if !joy0fire then bullet_fire_xpos=spaceman_xpos-1:bullet_fire_ypos=spaceman_ypos+8 skip_spaceman_move ; Limit the Space Man's movement to keep him on the visible screen if spaceman_xpos>146 then spaceman_xpos=spaceman_xpos-1 ; Don't move off the right side of the screen if spaceman_xpos<1 then spaceman_xpos=spaceman_xpos+1 ; Don't move off the left side of the screen if spaceman_ypos>176 then spaceman_ypos=spaceman_ypos-1 ; Don't move off the bottom of the screen if spaceman_ypos<11 then spaceman_ypos=spaceman_ypos+1 ; Don't move off the top of the screen ; Don't let bullet fire off of the visible screen if bullet_fire_xpos>158 then bullet_fire_xpos=spaceman_xpos-1:bullet_fire_ypos=spaceman_ypos+8 ; Stop bullet at right edge of screen if bullet_fire_xpos<2 then bullet_fire_xpos=spaceman_xpos-1:bullet_fire_ypos=spaceman_ypos+8 ; Stop bullet at left edge of screen if bullet_fire_ypos>188 then bullet_fire_xpos=spaceman_xpos-1:bullet_fire_ypos=spaceman_ypos+8 ; Stop bullet at bottom edge of screen if bullet_fire_ypos<11 then bullet_fire_xpos=spaceman_xpos-1:bullet_fire_ypos=spaceman_ypos+8 ; Stop bullet at top edge of screen Explosion Animation Code Here's the code that actually makes the explosion animation work. Turning on the animation itself is trivial, as all you need to do is plot the sprite and add a frame counter variable to the end. This code by itself is what actually puts it on the screen: plotsprite sprite_explode1 5 spaceman_xpos spaceman_ypos explodeaniframe There's a little more to it than that, though, as we need to control the speed of the animation, set flags for the sprite that's exploding so we can trigger other changes in the code, and we need to set a flag to know when the explosion animation is completed so we can move on. The first thing I did was to add a few frame counters. I could have used just the one new counter "explodeaniframe" and counted from 1-8, but doing that alone causes the entire animation to run extremely fast - so fast that you can't really see it on the screen. We need a way to run an additional counter that increments the animation counter a little more slowly. To accomplish that, I used one of the "junk_Slowdown" frame counters that I'd already assigned at the very beginning but hadn't used yet. It will increment by 1 each frame, and when it gets to 8 it then resets itself and increments the explosion animation frame variable by 1. This effectively makes our animation run every 8th frame, slowing it down to an acceptable level. You'll also notice that all of the if...then statements are precluded by "if spaceman_flag=1", which is because we want to verify that the spaceman has just been killed before we run the code for the explosion. Finally, notice that we also trigger the explosion sound effect in this section of code. ; This section starts two frame counters to control the animation speed of the space man's explosion ; The junk_slowdown3 frame counter is used to slow down the animation frame counter. ; When the animation is complete, the animation frame variable (explodeaniframe) is set to 0 if spaceman_flag=1 && explodeaniframe=1 then playsfx sfx_death if spaceman_flag=1 then junk_slowdown3=junk_slowdown3+1 if spaceman_flag=1 && junk_slowdown3=8 then junk_slowdown3=0 if spaceman_flag=1 && junk_slowdown3=2 then explodeaniframe=explodeaniframe+1 if spaceman_flag=1 && explodeaniframe>9 then explodeaniframe=200 I mentioned earlier that I changed the "losealife" subroutine code. The next few lines perform a few of the functions that were formally in that subroutine. The first line checks to see if the death flag is set for the space man (spaceman_flag), the explosion animation is complete, and you have at least one life left, reset but stay in the game if spaceman_flag=1 && explodeaniframe=200 && lives>0 then spaceman_xpos=80:spaceman_ypos=80:spaceman_flag=0:explodeaniframe=0:gosub losealife:goto main This line checks to see if the death flag is set for the space man, the explosion animation is complete, and you have no lives left, reset to the title screen. The Game is over. Note that the score is not reset prior to the titlescreen, so the score you see when you jump back is the score you just achieved in the game. It resets to zero when the main loop is called from the titlescreen at the beginning of a new game. if spaceman_flag=1 && explodeaniframe=200 && lives<1 then explodeaniframe=0:spaceman_flag=0:goto plot Next is the area for all of the plot values, at the end of the code but prior to the drawscreen. The first few lines are all-new, they will plot either the spaceman sprite or the explosion depending on the value of the spaceman_flag variable. That flag is set when a collision is detected, and then reset with the lines of code just above that take you back to the main loop or the titlescreen if the game is over. ; If the death flag is off, plot the normal space man sprite. If the death flag is on, plot the explosion animation sequence. if spaceman_flag=0 then plotsprite sprite_spaceman_left 5 spaceman_xpos spaceman_ypos if spaceman_flag=1 then plotsprite sprite_explode1 5 spaceman_xpos spaceman_ypos explodeaniframe The remaining plotsprite commands are the same as before, just moved to a new location. ; Plot score values ; Image File Palette Score Variable # Digits X Pos Y Pos ; ------------------- ------- --------------- -------- ------ ------- plotvalue scoredigits_8_wide 2 score0 6 26 0 plotvalue scoredigits_8_wide 2 score1 1 153 0 ; Here we plot all of the sprites on the screen, using the variables we defined for the X and Y locations. ; Spaces were added for readability, only one space is required between each option ; Name of the Sprite Palette X Position Y Position ; ------------------- ------- --------------- ------------- plotsprite sprite_invader1 5 invader1_xpos invader1_ypos plotsprite sprite_alien 6 alien_xpos alien_ypos plotsprite sprite_chip1 5 chip1_xpos chip1_ypos plotsprite sprite_debris1 1 debris1_xpos debris1_ypos plotsprite sprite_debris2 1 debris2_xpos debris2_ypos plotsprite sprite_debris3 0 debris3_xpos debris3_ypos plotsprite sprite_debris4 1 debris4_xpos debris4_ypos plotsprite sprite_debris5 1 debris5_xpos debris5_ypos plotsprite sprite_debris6 1 debris6_xpos debris6_ypos plotsprite sprite_debris7 1 debris7_xpos debris7_ypos plotsprite sprite_debris8 1 debris8_xpos debris8_ypos plotsprite sprite_debris9 0 debris9_xpos debris9_ypos plotsprite sprite_rocket1 5 rocket1_xpos rocket1_ypos plotsprite sprite_rocks1 3 rocks1_xpos rocks1_ypos plotsprite sprite_rocks2 2 rocks2_xpos rocks2_ypos plotsprite sprite_rocks3 3 rocks3_xpos rocks3_ypos plotsprite sprite_rocks4 4 rocks4_xpos rocks4_ypos plotsprite sprite_satellite1 4 satellite1_xpos satellite1_ypos plotsprite sprite_satellite2 3 satellite2_xpos satellite2_ypos plotsprite sprite_bullet 5 bullet_fire_xpos bullet_fire_ypos drawscreen ; Display the plotted images on the screen goto mainloop ; Jump back to the beginning of the main game loop The losealife subroutine This subroutine was changed to simply reset variables and decrement the lives counter. losealife lives=lives-1 ; Here we reset some variable values before returning to the game ; We reset the location of the junk to the default if they're still active if debris1_flag <>1 then debris1_xpos = 52 : debris1_ypos = 5 if debris2_flag <>1 then debris2_xpos = 4 : debris2_ypos = 20 if debris3_flag <>1 then debris3_xpos = 72 : debris3_ypos = 12 if debris4_flag <>1 then debris4_xpos = 4 : debris4_ypos = 60 if debris5_flag <>1 then debris5_xpos = 92 : debris5_ypos = 18 if debris6_flag <>1 then debris6_xpos = 122 : debris6_ypos = 23 if debris7_flag <>1 then debris7_xpos = 4 : debris7_ypos = 120 if debris8_flag <>1 then debris8_xpos = 4 : debris8_ypos = 140 if debris9_flag <>1 then debris9_xpos = 38 : debris9_ypos = 12 if rocks1_flag <>1 then rocks1_xpos = 18 : rocks1_ypos = 20 if rocks2_flag <>1 then rocks2_xpos = 140 : rocks2_ypos = 48 if rocks3_flag <>1 then rocks3_xpos = 18 : rocks3_ypos = 60 if rocks4_flag <>1 then rocks4_xpos = 140 : rocks4_ypos = 88 if satellite1_flag <>1 then satellite1_xpos = 18 : satellite1_ypos = 100 if satellite2_flag <>1 then satellite2_xpos = 18 : satellite2_ypos = 120 if invader1_flag <>1 then invader1_xpos = 140 : invader1_ypos = 126 if chip1_flag <>1 then chip1_xpos = 152 : chip1_ypos = 90 if rocket1_flag <>1 then rocket1_xpos = 152 : rocket1_ypos = 130 fire_debounce = 0 : gameover_flag = 0 : junk_slowdown4 = 0 alien_aniframe = 0 : spaceman_aniframe = 0 : spaceman_dir = 0 bullet_fire_xpos= 0 : bullet_fire_ypos = 0 : joyposleft = 1 joyposright = 0 : joyposup = 0 : joyposdown = 0 ; Reset location of alien to offscreen alien_xpos = 200 : alien_ypos = 200 : alien_flag = 0 return Sound Effects Data I'm only going to use TIA sound effects in this game, I won't be exploring the use of POKEY. Sound effects are craeted by playing TIA data with the playsfx command, or by manipulating the TIA registers directly. I'm going to foucs on the playsfx command, as it greatly simplifies adding TIA sound effects in the game. Sound effect are created by adding the following line in the main game loop: playsfx soundata [offset] The optional offset parameter allows you to raise or lower the pitch of the played sound. If you have a sound which is often repeated, it's recommended that you vary its pitch a bit randomly. I decided to use the optional parameter in Space Junk for the gun firing sound, as I noted earlier. When you play a sound, the sound driver will automatically choose between the two available sound channels based on which channels are already being used by the driver, and if both channels are being used it will interrupt one of the playing sounds based on a priority system. Before playing a sound with playsfx, you'll need to define the sound effect data in the expected format. The data format 7800basic works with is composed of three parts, a header, the sound data itself, and an end-of-sound marker. The header consists of 3 bytes: 1. The format version. Use "16" here for TIA ("32" for POKEY, but we're not using POKEY) 2. The sound priority. The suggested usage here is to enter the number of chunks of data. This will have the effect that longer sounds will be less likely to be interrupted early on compared to short sounds. If you have a background sound that should only be played if a channel is free, use a 0 here. 3. The number of frames each chunk of data represents, less one. The sound data then consists of 3 byte chunks, each of which represents the Sound Frequency, Control/Waveform, and Volume to play. The sound driver will continue to play the sound data until it reaches an end of sound marker, which consists of 3 zero bytes. I'm no expert on sound effects, and when I've created them in the past it's generally involved a lot of trial and error testing by changing bytes in the data and seeing what happens. The sound data included in Space Junk was pulled directly from RevEng's soundfx sample program, although I did modify them a bit to make them shorter in length. data sfx_gunfire $10,$10,$01 ; version, priority, frames per chunk $16,$04,$04 ; first chunk of freq,channel,volume $16,$04,$07 $16,$04,$0f $16,$04,$0e $04,$0c,$07 $0d,$04,$07 $03,$0c,$04 $03,$0c,$04 $04,$0c,$02 $05,$0c,$04 $12,$04,$04 $12,$04,$02 $05,$0c,$04 $05,$0c,$02 $05,$0c,$02 $10,$04,$02 $00,$06,$01 $00,$00,$00 end data sfx_death $10,$10,$02 ; version, priority, frames per chunk $1F,$03,$0F ; first chunk of freq,channel,volume data $1F,$08,$0E $1F,$03,$0D $1F,$08,$0C $1F,$03,$0B $1F,$08,$0A $1F,$03,$09 $1F,$08,$08 $1F,$03,$07 $1F,$08,$06 $1F,$03,$05 $1F,$08,$04 $1F,$03,$03 $1F,$08,$02 $1F,$03,$01 $00,$00,$00 End That’s it for this revision. I’m not sure what’s coming next, I’ll have to give it some thought. There’s plenty of ROM space left (about 6k, and I haven't optimized anything) so I may add some optional features like the high score table. Here’s the latest version of code with the updated graphics files and all compiled files: SpaceJunk_092617_1a.zip
  19. If I wanted to have it in tune , I'd check for a remix at RKO. If you put the "better" sounding of all created sounds aside, as SID is simply better in playing deep notes, you realize the "out of tune" on the SID-Synth also. Just the 8580 plays it better... Could be even more interesting to have a similar sound playing routine as with "Fanta in Space" , as it seems C64/SID is also not able to play "fitting" synth sweeps to the sampled part. POKEY offers much more variations there... Could also be interesting to have a modulation feature, using two channels for digis. Or to have GTIA playing a digi channel and POKEY uses all 4 channels for waveshaping.... Could also be interesting to see what happens if the audio channels of POKEY and GTIA had been timed together, using additive or substractive waves, manipulating the analog circuitry.... a.s.o. Actually , there is much more to explore than already has been explored. Perhaps only 99% of what A SID could do in a stock C64 has been explored, not 100% .... but music on the Atari is at 30%-50% of what's possible, if you compare the "eventuallities"
  20. I appreciate everything that enhances the Atari. But this "enhancement" has a sour side effect. POKEY isn't really explored yet , so how can such an enhancement help to put the thing to the real limit?
  21. You have plenty of time, but you must monitor the SIO line frequently to measure the transitions with enough precision. And the more advanced the encoding method the more the precision you need. And unfortunately there are no interrupts for SIO transitions, so the decoding code might need to be interleaved with peeks to the Pokey register. But may be you are right, and may be this is feasible. I honestly never attempted any SIO stuff bypassing Pokey. It is certainly a very interesting idea and might be worth exploring. There is another interesting issue related to this concept. You don’t really need a faster bit-rate to decrease the actual load time. Bypassing Pokey and using any self-clocking method, you avoid the need of start and stop bits. This by itself is a significant gain. Another possibility is just to increase the word size. Use, say, 10, 12 or 16 bit words. You don’t really need IRGs, they can be removed altogether when using a custom loader. I still think that the most important gain is obtained by the compression. So may be the best idea is to find the best possible compression (which can obviously done on a fast modern computer) that can still be decompressed fast enough on the A8.
  22. Perhaps in the beginning, but Ray Kassar demanded that Atari get into the computer business once he heard about Apple's first computer. I don't think people at Atari thought the system was going to be a game console for long. -Bry Based on my interviews with Joe Decuir, initially the 400 was meant to be the next gen game console, with a keyboard built in to allow direct programming of games on the console by developers. (this was of course the same concept intended when they moved to do Amiga). The 800 was inteded to be the actual high end "computer". The graphics and sound chips were also initially to be designed to be used in coin-op as well, but the graphics chip use was soon scrapped because of the differences in display technology in coin-op monitor vs. television. Only the Pokey made it over. The coin-op releases of the time period support that crossdivision idea with the use of the 6502 as well as Pokey - Missile Command, Centipede, Warlords and the vector games Lunar Lander, Asteroids, and BattleZone. The decision to get in to computers (and this game console and high end computer in general) actually started under Nolan's watch, not Ray's. (While it's been popularly reported that Nolan passed on the original Apple 1 in 1976, this later fact has been woefully under reported). The idea was (as someone else mentioned) the 2600 was to be only temporary, a bridge between the dedicated and programmable systems with a "higher end" game console to be released a few years later. What changed it was when Ray took over and had no desire to abandon the 2600 nor create competition for it. Keeping the two in development and then seeing Apple's success, he held a meeting with management and engineering where he pushed development towards "computers as appliances". Some of the views in the speech actually wound up offending some of the women at Atari (without going in to much detail). But in general, his view was much like Steve Jobs' view with the iMac some 20 years later. So the 400 was pushed as more of a low end introductory computer mainly for novice computer users (hopefully eventually leading people to upgrade to a full blown 800). The 800 was seen as the serious computer and business machine and considered high end. This is also what lead to the initial "closed system" view he had (much to the protests of engineering), where he viewed third party software development across the board (consoles and computers) in a negative manner. With the "computers as appliances" view, he felt all parts (including software) should come from the manufacturer (what else would you expect from a former towel man). Of course Ray was forced to change not long in to the computer market, as ultimately he had no control over it when talented hackers like John Harris started to explore and doccument the hardware. Likewise the success of Apple's support of third party development kinda kept hitting him over the head.
  23. i can't remember where i heard or read about it but i clearly remember seeing/reading or hearing that Atari were planning to do an 'all in one' antic/g/ctia graphics chip (therefore replacing the 'two chip' design) Was i just imagining it or is/was there an element of truth in this Additionally, i remember from the disk version of the hardware reference manual (Bob DuHamel) that it was possible to have Atari's working with 'multiple' Antic/gtia and pokey chips, apparently you could theoretically better Atari's graphics/sound capabilities by doing this, i.e higher rez., more colours, more pmg's/sprites, stereo sound and multiple sound channels etc Would it be possible these day's to use the concept of a 'multiple' Antic/gtia and pokey chips in a one chip design for each... i.e 5-6 antic chips on one chip, 5-6 gtia chips on one chip etc, etc...again with added hardware capability like more colours, more sprites, own ram (64-512 K) totally reprogrammable Antic chip, programmable gfx resolutions (like the later MSX gfx chips), more sound channels, stereo sound/voice synth/adsr and all that Also, going back to the other thread, the NUMEN demo, it made mention of a 'bug' in the GTIA chip which allowed for interlacing and more colours, in regards to these 'new gfx modes', what would be the highest possible resolution, 600/400, 480/320 or PC stylee rez (1280/1024) and what of the colour range, would that be limited to 512/4096 (ST/e/Amiga stylee) or PC stylee 16/32bit colour range...would it be capable of putting up more then 4 hardware PMG's (i remember a gfx type in demo published in Atari User that claimed to display 80 hardware sprites)...Also Page 6 published a couple of gfx type in demo's called doing the impossible, one of the techniques explored was 'Vertical screen splits' which the STe hasd built into in shifter chip, but this was a A8 type in graphics demo, could these other capabilities be possible on the 'undocumented' gfx modes Additionally, i wonder whatever happend to the 'Apac' graphics mode (I believe it was capable of generating 4096 colours and all that) Lastly, in regards to the GTIA, i recall hearing or reading that Atari didn't officially support the GTIA modes 9, 10 and 11, if this was so, what was the point of the GTIA chip in the first place (esp. if your not going to support it's additional capabilities)
  24. Super Mario Bros., Excite Bike, Duck Hunt, Hogan's Alley, and even the original version of Punch Out! were all Nintendo arcade ports. When I was playing the emulator on my friend's Wii, I couldn't believe how bad Rampage and Double Dragon were on the 7800. I don't remember them being that bad back in the day but the sound was atrocious [due to the lack of the Pokey chip] and I can't imagine the graphics were better than the NES versions [although in fairness, there was no 2 player mode on the NES for DD]. Even Xenophobe was a rather bad port too [i don't remember the Lynx version being bad]. If I recall, Xenophobe was published by Atari but DD and Rampage were published by Activision. 7800 splash screen (I forgot what the XEGS looks like at boot) and/or is that a Commodore 1702 monitor? Too bad Atari didn't have their own composite monitors. Or monitors that supported both RGB and composite. Surprised they didn't! BTW: they sure do have that XEGS parked unnaturally close to the monitors. Where are the cables?? My money says a different Atari system is responsible for that display. lol You mean XEGS carts didn't have the same splash screen as the 7800 titles? If that's the case, I'm rather surprised the Tramiels didn't "recycle" it. Wasn't there an Atari [Corp.] branded composite monitor in Europe? That's actually something that surprised me about Atari Inc. during the 400/800/XL days...why they were so content to have Atari 8-bit owners buy composite monitors from Commodore and Philips which were both competitors [Commodore computers and Magnavox Odyssey, etc.]. To think Atari Corp. later discussed marketing Atari branded television sets around the time they started selling Atari branded calculators. As for the 2600 vs. 7800 argument, I think it would be fitting to suggest that Atari should've continued selling the 2600 as long as they could but not allocate precious development dollars on titles for it at the expense of the 7800. As for 7800 vs. XEGS development dollars, unless I am mistaken, there wasn't much development dollars necessary to take already existing Atari 8-bit disk based games and "convert" them to cartridge versions. In fact, that might be one of the reasons why Atari was gung-ho about the XEGS; they got to recycle and repackage content whereas converting those very same titles to the 7800 would have been another expense. Furthermore, this is probably why the Tramiels opted to cancel the 7800's expansion port...they probably concluded that if a consumer wanted a computer keyboard they should just buy the XEGS. That seems like a sure fit considering their hyped - at the time - logic of color coding anything with the 8-bit computer line in red and products related to the Atari ST line were to be colored blue. They actually thought this would differentiate products successfully in mass market outlets and they actually bragged about this in Atari Explorer magazine [although I think Antic/STart ridiculed it] that such retailers wouldn't need to have knowledgeable sales staff because of it. Regarding left over 8-bit parts as the reason for the XEGS, perhaps Atari had leftover custom and RAM chips that had been allocated for the 65XE that wasn't selling so well at the time and they opted to repackage that with the redesigned mobo for the XEGS. The other reason for the XEGS was to shore up the Atari 8-bit line to increase the user base since software publishers were looking for any excuse to dump the Atari 8-bit line because of the alleged rampant piracy on the platform [even if there were far more C64 owners who were software pirates]...
  25. Lynxpro

    5200 SIO

    Well, changing out the BIOS for an EPROM is trivial since it's socketed. I wasn't counting the Ultimate SD Cart because it's external and there's no cartridge pass thru for actual cartridges. I'm more for easy "authentic" expansion. Adding a MIPS isn't exactly authentic to the era vs 32/64/128K expansion, SIO, Dual POKEY, or a 65816 which were all possible. The more I think about it, the more I'm surprised Atari Inc didn't go ahead with adding the SIO simply to offer an option to saving game score to a cassette using something like the 1010. That would've certainly been easier than going the route of the 7800 High Score Adapter. Then again, the 5200 cartridge is definitely big enough to support battery backup saves; too bad that wasn't explored. I really think using the 2600 cart design for the later 7800 was a big mistake. They should've stuck with the 5200 cart size but used a cart adapter to use in conjunction with the 2600 internals. But that's a different discussion.
  • Create New...