Cafeman

Thanks. Any comments on this version VS the 5200 one, since I know you've played them both?

Actually, this is what I was wondering when I asked you how you'd translate it to POKEY. I don't know if there is a MIDI utility to translate it to pokey chips. There are A8 sound packages that you can devote a chunk or ROM for in your program, and use the util to compose a tune with various FX, but I've never used those either.

This thread is what you need to map the notes to POKEY values. But you still need a sound routine for loading notes, duration, and decay if you use it.

The only way I know is tedious. I was just playing that tune on guitar today, there are tabs for it on the Ultimate Guitar Tabs App. It is either in Db or Ab in the sheet music. What key did you record yours in?

How are you going to translate that into pokey music?

wow, very nice picture coming from that 5200. He also draws nice foxes!

87,450. LOL ...

Updated 10/12/20 with the results, see bottom. I'm running out of ROM memory with the new code I'm adding for the 2-player mode of the game. Koffi: Yellow Kopter was programmed in 32k back in 2002. It seemed like a huge amount of ROM at the time, so I didn't try much to keep things small. There ended up being huge graphics tables and repetitive code routines, just because that was easiest to do. Also, before I finished Koffi, I used up as much remaining memory as I could. Over summer 2020, I went back and rewrote several routines, and I've ditched the original game's credits / names text and freed up 1k or 2k. I thought this would be enough to add some fun new stuff, but I'm once again running low on ROM space, so I am now rewriting the routines/data tables which are the biggest ROM wastes: those that create the image of the Trees. Stage 1 Mountain Valley's Tree / leaves graphics take up 1,000 bytes originally. But most of the bytes are the value of $55. I am now trying to store a big rectangular block of $55's (no need to code these into the ROM now) programmatically, and then just have left-edge and right-edge tables to provide the more rounded tree details. To illustrate, an original code section: ;************ Draw Leaves Layer2 ****************** ; RWL 2001 lda #<leaves2 sta Ptr1 lda #>leaves2 sta Ptr1+1 lda #$32 ;row 4 starts at $3208 sta $81 lda #$08 sta $80 jsr CommonMVTreeDrawLoop ; rewritten as common routine RWL 072520, saved hundreds of bytes Using data tables like this one: leaves2 .byte $15,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55 ;line 7 .byte $55,$55,$55,$55,$55,$55,$55,$55,$55,$50 ; ; .byte $55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55 ;line 8 .byte $55,$55,$55,$55,$55,$55,$55,$55,$55,$50 ; ; .byte $55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55 ;line 9 .byte $55,$55,$55,$55,$55,$55,$55,$54,$55,$50 ; ; .byte $55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55 ;line 10 .byte $55,$55,$55,$55,$55,$55,$55,$51,$15,$54 ; ; .byte $55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55 ;line 11 .byte $55,$55,$55,$55,$55,$55,$55,$55,$55,$54 ; ; .byte $55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55,$55 ;line 12 .byte $55,$55,$55,$55,$55,$55,$55,$55,$55,$54 ; ; See all those $55 values? A compression routine would also reduce ROM needs, I could compress these tables and expand them into screen RAM directly. But I'm not wanting to add a compress/decompress routine to this game this late in the game, which would take up some ROM itself anyway. So, I'm reducing these tables with my own custom draw routines. 10/12/2020 Monday night. Results: Success! I got the same basic tree image but at a cost of about 640 bytes less! prior Blog entries: https://atariage.com/forums/blogs/entry/16854-koffi-redux-2020-part-2/ https://atariage.com/forums/blogs/entry/16763-koffi-2020/

65,700. I did a little better. Playing using the arrow keys is tough though.

55,700.

Regardless of how fast that suit is shut down, that kid and his mom are getting something sweet courtesy of Nintendo's lawyers.

That does it. I'm playing Pitfall again. Well written entertaining article.

Are you (or anyone else) working on Tron style music clips? Also, curious, what graphics mode?

Very interesting. I have never attempted to take apart a console and change something like thermal paste, which I have no idea where and what that is. But my Xbox 360 fan has been very loud for years to the point I don't want to play it sometimes oh, you could probably use the same remedy.

ROBOTWAR 2600 is a good name. Was the name change preemptive, or demanded?

Defender introduced me to the term Smart Bomb. Or maybe Tempest. Here's a link I found: https://www.giantbomb.com/smart-bomb/3015-144/

PS4 Dirt 4 -- 6 hours.

I never tried it, but I imagine you would have to use an emulator like Altirra.

Agreed. At first the A8/5200 port seems impressive, but its not a lot of fun to play. The coin-op version is so much better programmed and fun. I played it for a long time at the last Replay FX show.

Excellent question! The app that I used to use for Adventure II can be found in the link below, programmed by @calamari. I think you have to run it in DOS box on Windows 10. Is calamari still around? It would be great to have a version that you could run in Windows 10. Also these were recommended recently. I haven't tried them yet. > Graph2font: > http://g2f.atari8.info/ > Atari graphics studio: > http://madteam.atari8.info/index.php?prod=uzytki > For char based gfx you can use my fontmaker: > http://matosimi.websupport.sk/atari/2020/01/atari-fontmaker-1-5/

The very last programming change I made to Adventure II XE brought me great happiness, because it was a bug fix that, although infrequent and minor, had eluded me. Giving up on it over the past years of this project, I concluded that it must be a weird timing issue with the Atari Hardware and VBI timing. Something was perhaps changing registers behind the scenes? Because my code was surely 100% rock solid and correct. This was a bug which plagued me for years of this project. I'm not sure if it exists in the 5200 version (probably), but I don't recall it occurring back then. I spent hours trying to determine why this somewhat infrequent bug would occur. Then I'd forget about it. But with lots of testing of the game over summer 2020, I started to see it again and too frequently. I said to myself, "Self, you should be able to figure this out and fix it". Description of the bug: Sometimes when you stab a dragon and kill it, the "Dragon Killed" success music would fire, but the Dragon didn't die. Literally, it seemed that the DragonState variable didn't get changed to a value of 0. The code decrements the dragon's hit points (health) for every frame that the sword is touching the dragon. But somehow the dragon would get down to 0 hitpoints left, but its DragonState would not be 0. This isn't tricky programming. It all looked fine. I kept blaming "weird Atari hardware timing". So with the game done otherwise, and nothing else to do, I decided to attack the problem systematically. You know, like a real programmer would. I tested using the excellent Altirra emulator, setting WatchBytes on-screen so I could track exactly what was happening as I fought the dragon. I killed the dragon over and over, then hit the Revive key (which revives the dragons too) and fought/killed the dragon again and again. I was able to get the glitch to happen but not consistently. All the memory locations that I tracked were exactly as I'd expected - correct. What's going on??? Then I started to review the code in detail. Some of the labels for subroutines in the code were stupid, the code didn't do what I originally had intended back in 2004. So I changed a few labels to make more sense, to help the analysis. And then I saw it. The code Check_If_Killed_Dragon was executing 100% correctly. As I always assumed. But after it, in the same frame, it was immediately falling into the next routine Check_If_Bit_By_Dragon, which checks if the Dragon bit you, and changes the Dragon's DragonState variable to a "2" - which means to chase the player. So ... if you killed a dragon and the dragon's pixels were touching your player at the same time, it was inadvertently changing the DragonState from 0 (dead) back to 2 (chase player) ! It wasn't "weird Atari VBI timing" at all . It was BAD PROGRAMMMING. Mine! And, I fixed it. Now, after Check_If_Killed_Dragon, it jumps out of that logic. It can check if you were bitten the next frame. This simple addition of a Jump fixed the years-old glitch! And I felt ... quite pleased and happy. The game was 100% finished at that moment. Sorry I blamed you Atari 8-bit computer line! You were just doing what I told you to do.

Added a few more details to original blog for posterity, now that the game is done.

[This older blog entry was updated on 2/14/2020 and 9/30/2020]. 2001-2002 -- Alan and I begin the game and design 75% of what it will be like. Raccoon joins as the artist. 2002-2004 -- Raccoon Lad & I discuss 5200 limits, we design and create screens, and program the game. 2004 -- Infogrames "Atari" attack! Game renamed (temporarily to Quest for the Golden Chalice. Knocked the wind out of me for a while. https://atariage.com/forums/topic/59600-quest-for-the-golden-chalice/#comments 2005-2006 -- mostly me finishing and debugging the program and trying to accomplish my own vision within dwindling memory space. Jan - March 2007 -- Since I have to wait for the game to be manufactured, I do add a few things like the Dragon Trap, then test some more. May 2007 -- 5200 version of Adventure II is published by AtariAge! ... XE Port begins ... Sept and Oct 2010 - Perry Thuente (Tep392 on AA) ported the code to 8bit format, including both XEGS and Atarimax Bank-switching formats, and other mods involving OS, keyboard code. Added Bryan's AA splash screen. I now have a lot more memory to work with overall, but need to shift things around some more. 2011 - overhaul of Random Item hiding logic, creature behavior, and overhauled hiding of the 3 Bat Eggs/Dots. Distribute code and data to different banks to leverage out available total memory. Use one bank for a character set to get prettier text on title screen. 2012 - address bugs with collision and troll sprite 'remnants'. Changes to map paths, create new EXITS on hedge screens so Hedge Maze is the hub between Ice and Dark kingdoms, not the Green Castle itself like in 5200 version. Oct 2012 - first PRGE demo. 2013 - experiment with new sounds; add more wood plank bridge building (you can build bridges on both islands screens now, not just 1); Added end-game statistics. Implement one-button control scheme. (5200 version used 2 buttons). More gameplay tweaks and bug fixes. Timing seems different running on A8? New box artwork is done by David but we do not reveal it. Release first demo in AA Homebrew forum, with resulting feedback. PJT fixes PORTB problem. My homebrewing desktop computer has a problem at end of year, lost some data and felt burned out. Quit for a while. 2014 - project on hiatus. Too much real-world stuff going on such as home repair. 2015 - I got a new Lenovo i7 laptop, so I restored and reorganized my Adventure II folders and files, and started working on it again. Added content and tweaks, fixed new bugs that got introduced, continued to get frustrating trying to add new content into the original hard-coded engine! At least the Yuengling beer was satisfying. 2016 - project on hiatus again. I just can't get to it. I can't really remember why! Too busy living life I guess. There is an up-to-date PRGE demo in October. Jan and Feb 2017 - with a real "Git'R Dun" determination, I completed engine optimizations. I had too much going on in Vertical Blank , which was causing strange behavior when several large sprites were all on screen. These optimizations corrected DLI screen color errors that had been plaguing me. I programmed the Alternate Icons with distinct special abilities. Added all-new rankings and overhauled rankings determination logic. Opened up Sword collision so it will harm a dragon even if you are not carrying it (I know that is how 2600 Adventure worked, but if you play 5200 Adventure II, a dragon will glide THROUGH an uncarried sword unharmed. Not any more!) Sept and Oct 2017 - Fixed some rankings bugs. Revised Title screen so that options are selectable via joystick. Continued to add content here and there, and worked on years-old list of items. Purchased Atarimax USB programmer, to test on real hardware. Another PRGE demo October 2019, showing new Title Screen and options like Dark Mode. New artwork is revealed in a banner at PRGE show. 2018 - not much accomplished. I lose interest in things. 2019 and 2020 work: 1. After experimenting with different sounds and tunes, I decided to keep most of the original 5200 sounds, which now to me are iconic of the game. Even the dragon barks. I reduced the repetition of the main tune, and added a couple new sound cues. To save ROM space, the 5200 version sounds/music were hardcoded into small static tables which used an index to find the right piece, and compressed/decompressed into RAM to boot. Thus it was difficult to really do much modification of those. It was easier to make new sounds than to change the old ones. I moved all sound logic and sound/music data tables to their own 4k bank which I didn't even fill up! I really feel the game's overall silence is important so I didn't want to put a repetitive and looping pokey tune in there playing all the time. 2. Play testing, using Altirra and its nice debug, but also using the Atarimax USB programmer and 8 mbit cart with my XEGS and Atari 800XL consoles. I have not seen any differences of game behavior between Altirra and real hardware, other the colors / brightness of a laptop screen vs Plasma HDTV. With one exception: my Plasma would roll at the Game Win screen, I eventually fixed that by tweak to when I turned off Antic between game screen and Game Win Rankings Screen. Another thing as I opened up the Start, Select, and Option console buttons to server as Start/Quit, Revive, and Game Pause functions, respectively. This allows use of the Atari XEGS without a keyboard. My son proved helpful with QA testing. He really tries to break the game. Because of his testing, I noticed one glitch that was reported before - when square is changing screens, if you kept spamming the rotate-carried-item button, it can mess up the X coordinate and the item will be far away from you but still 'carried'. I thought this bug was an unavoidable VBI timing issue, but it is "user-caused" ! I fixed it. This was a too-common pattern of mine, blaming the Atari hardware for my own glitches! Because , you know, I'm such a good programmer n'at, how could it be happening due to MY code? 3. A new DEMO was released on 2/5/2020 to the Homebrew / Adventure II XE demo and testing thread. So far it looks like 70-80 downloads of the various different formats. Feedback comments were: (1) comments about Key colors. Green and Gold keys aren't always distinguishable; (2) and a comment showing a collision bug, Knight Helmet gets stuck. I did find a bug and fixed it to prevent getting stuck on plants, etc. when you are the Knight Helmet. This brings up a good subject - NTSC colors. I spent quite a few hours trying to prevent 'NTSC greenish hue' syndrome on my yellow/tans, and also quite a few hours experimenting with different key colors so that it was always easy to distinguish which key you were looking at. Depending on which color of background graphics a key sits, it can be near impossible to tell the Gold and Green keys apart, or sometimes even the red and blue keys have a similar purple/white hue on some screens. Making the keys darker helps to distinguish them, but then the keys are sometimes lost in the background graphics which isn't acceptable either. So, my first solution was to cycle / pulsate the key colors. But I still got negative feedback about the keys, even after adding the cycling. And then .... an epiphany around March 2020 ... ... I was so surprised that I didn't think of the obvious solution before -- have unique bitmaps for each of the 4 keys. I started by making the Gold Key have a square handle. It looked great - problem fixed. AA member TIX drew some additional Key designs, and I picked 2 for the Red and Blue keys. Of course I had to rework the code which had previously assume all keys had the same bitmap. 4. In summary, my 2020 tweaks included the new unique key images, that collision fix, a screen garbage fix at Game Win, several minor gameplay tuning tweaks, and ... one more bug fix that was rare but plagued me for the past few years: sometimes you would stab a dragon, but the dragon would not die on screen even though the kill music played. This baffled me over the years, then I would forget about it, but then in testing I would see it again. I thought surely there was a strange and unknowable Atari Hardware VBI timing bug doing something weird. However, since I had some free time waiting for AtariAge to manufacture the game, I decided that I should be able to figure this out and fix it. And, using the Altirra emulator, I did indeed finally spot the problem, which was not strange timing but was 100% bad programming by me! But the details are a story for another blog entry. This was the last coding change, in September. Fixed! In summary, I had also added new uses for 4 items for the XE version. (a) Sword now interacts with Dragons even if not being carried; (b) Chalice now grants you SPEED as long as you hold it. I think this makes the end-game less tedious and more fun, and adds the game play mechanism of keeping the found Chalice close by to re-grant yourself SPEED as you explore. Yes, you can find the Chalice before you find the sword or the Yellow/Golden Key for the Seashore castle. This was not true in the 5200 version. The Chalice will also trigger a sound cue if you carry it onto a screen hiding a Bat Egg; (c) Blue / Ice Key now interacts with the Minotaur in a certain way. (d) Red Key also has a hidden function, other than opening up its Castle gate. It isn't a necessary or even helpful function but you'll know it when you go to the right place with this key. 4. AA Store and Publishing ... Its looking like October 2020. David Exton created nice art and layouts for the manual and box designs. The manual is very distinct from the 5200 Adventure II manual with a lot more art (and in a different style). Albert had to figure out a solution to getting more A8 cart shells in 2020 - in August he shared a pic of one, a charcoal color. The picture is in the Adventure II XE demo and testing thread. This may be my last blog entry for Adventure II. I've been involved with the game since 2001! 19 years duration, although not actually 19 years-worth spent. FIN

I just checked the display list in Altirra. 5200 Wizard of Wor gameplay uses Antic D. This is a bitmap mode (not a character/redefined mode like Antic 4) with 4 colors. It is half the vertical resolution that Antic E is (see 5200 Joust to compare against). Antic D - 160 cols x 80 rows / or 160 x 86 . It uses 2 scanlines per mode line. Antic E - 160 cols x 160 rows / or 160 x 192. It uses 1 scanline per mode line. Thus needs double the memory compared to Antic D. It would be trickier to convert existing game code to use 5-color Antic 4 mode (character/tiles mode) but not impossible of course.