patjomki

But this is only 2.07? Shouldn't it be 2.11 instead?

Thanks a lot. I even already found that version but was confused due to the reason that the files extension of the source file changed from .pas to .dpr. Anyway, I could compile it and the bug with the missing Source: statement in the .lst file is gone. One thing is a little bit confusing. Athough the version no. should be 2.11 according to the .zip file the printed version no in the .lst file is still mads 2.0.8?

But where exactly? I don't see any binaries or sources there...

Where did you get that version? I could only get 2.07 from http://mads.atari8.info/

Yes. That was the reason. In order to avoid that I had to change the .sh script a little bit. So here is the version of freetz' script that allows source level debugging: #/!bin/bash fullpath="${1//\"}" lstfile=${fullpath%.xex}.lst WineExec=/Applications/Wine.app/Contents/Resources/bin/wine AltirraExec=/Applications/Altirra.app/Contents/Resources/wineprefix/drive_c/winebottler/Altirra.exe sed "/mads /a\\ Source: $lstfile " $lstfile > $lstfile.temp sed "s/lst/asm/" $lstfile.temp > $lstfile rm $listfile.temp cd "$(dirname "$fullpath")" $WineExec $AltirraExec /singleinstance /run $(basename "$fullpath") & Enjoy!

Compared to my .lst file within windows I found out that there is a difference: mac version: mads 2.0.7 Source: /Users/patjomki/Documents/workspace/Example/example.lst windows version: mads 1.9.9 Source: C:\jac\wudsn\Workspace\Example\example.asm So shouldn't the altirra.sh script generate the Source: line with .asm at the end instead of .lst?

Perhaps I should have copied the content of the .lst file from the filesystem instead of the Eclipse editor (where it is generated before altirra.sh is executed). So here is the new content generated with the latest version of mads I could get for Mac os x and this time from inside the file system. mads 2.0.7 Source: /Users/patjomki/Documents/workspace/Example/example.lst 1 org $4000 2 3 start 4 FFFF> 4000-4007> A9 34 lda #52 5 4002 8D C8 02 sta 712 6 7 4005 endless 8 4005 4C 05 40 jmp endless 9 10 ; run start The problem remains though. Breakpoints are not executed.

I am also using my Mac for developing but couldn't find enough tools to create everything natively under Mac OS X. So I am using Eclipse/WUDSN/mads natively under Mac OS X. Everything else is used with wine (3.03 stable). Character (font) editor: CharPad - http://www.subchristsoftware.com/CharPad1_83.zip(couldn't get the latest version 2.0 beta to run with wine) Sprite (P/M editor): SpritePad - http://www.subchristsoftware.com/SpritePad1_81.zip(same as with charpad, latest version doesn't run) converted to ATARI format with: Graph2Font - http://g2f.atari8.info/graph2font_v4.0.2.3_full.7z graphics: ATARI graphics studio - http://madteam.atari8.info/uzytki/ags.7z ATR-generator: makeATR - http://serious-dial.atari.pl/makeATR/pliki/makeATR_v0.06.zip Sound: Raster Music Tracker - http://raster.infos.cz/atari/rmt/rmt128.zip

Is this version (source code) already published? I could only find 2.07 on http://mads.atari8.info/ and want to compile the latest version for mac os x.

Update: I just installed the latest mads 2.07 (compiled it with freepascal from the sources provided at: http://mads.atari8.info/) but the problem still remains. Altirra starts within wine but no breakpoints are recognized.

Today I tried to finally setup WUDSN ide on my mac. I can compile any .asm file with mads and automatically start it in Altirra 3.1 and wine with the above shellscript provided by freetz (thanks for that). The only thing that is not working is debugging within Altirra. Wudsn creates the files example.asm, example.atdbg, example.lab, example.lst and example.xex and executes example.xex but although I set some breakpoints Altirra doesn't stop execution in order to debug. Edit: Perhaps someone can help? I am using mads 1.9.9 (that's the latest version I could find for mac os). When I manually (F8) break the program Altirra seems confused because when I step (F11) into it shows the wrong sourcecode line in the .lst window breakpoint is at line 8 in my source code but in the .lst window Altirra always jumps to line no. 6. Here is the sourcecode (Breakpoints at line 4 and 8 ): 1 org $4000 2 3 start 4 lda #52 5 sta 712 6 7 endless 8 jmp endless 9 10 run start This is the .atdbg file: .sourcemode on .echo .echo "Loading executable..." .echo bc * .onexerun .echo "Launching executable..." bp `/Users/patjomki/Documents/workspace/Wudsn-Test/example.asm:4` bp `/Users/patjomki/Documents/workspace/Wudsn-Test/example.asm:8` And that is the .lst file: mads 1.9.9 1 org $4000 2 3 start 4 FFFF> 4000-4007> A9 34 lda #52 5 4002 8D C8 02 sta 712 6 7 4005 endless 8 4005 4C 05 40 jmp endless 9 10 02E0-02E1> 00 40 run start

I just recently got a Rapidus installed into my 800XL (pal) and gave it a try. As already mentioned in this thread the emulator needs seperate CPU and ANTIC banking so I had to change the Extended RAM settings for my U1MB to "576KB Compyshop". With this setting it worked good with spy vs. spy. Speed is fine. I had to use the keyboard instead of a joystick. So the question is: Does the emulator have joystick support?

Because we have things like this: Of course the number of developers is much higher and it is easier to programm for C64. So it no surprise that there are more programs for the C64 than for A8 but considering that the ATARI is a machine from the 70's we shouldn't complain. There are still a lot of outstanding productions each year.

Great to read that the project is not dead because I think it can be achieved even with the limitations of the p/m-graphics (compared to C64-sprites). I mean, most of the times there is only a single ghost in each scanline. But one question remains: Did wanax continue to code on platman a8 or has the project been on hold for the last two years.

Is this project still alive?

Five days later... wow... I don't want to know how you behave when you're "in a hurry".

Actually I don't see a huge difference between mentioning the AMIGA enhancements and the enhancements of the ATARI 8 bit version. To me this looks like a personal vendetta of the wiki user Tanonero against ATARI software.

I recommend playing Superfly XL (lite) on a real (pal) atari. I achieved more than 3000 points on real hardware while on emulators I could only get a little bit more than 1400 points.

We would like to thank all our voters. Congratulations to the winner but also to all the others that participated. Great selection of different genres this year. Attached find the abbuc version of Superfly XL (lite). It is pal only and runs best on real hardware. I hope I can find some time to make a ntsc version and to fix some minor things... Enjoy! superfly_boot.atr

Thanks for your feedback. First there was only one level (level 2) but several of my betatesters complained that level 2 was too hard (while for me level 2 was too easy). So as I already had to implement different difficulties I decided to do three difficulty levels. One disadvantage of level 3 is that it is nearly unplayable on any emulator I found (including Altirra, ATARI++, ATARI800, ATARI800Win Plus and ATARI800MacX). Seems that there is a small input delay for the trigger button on each emulator. Warning siren is a great idea, btw. Apart from that Superfly XL can be further improved in different other ways as well. Let's see, what the future brings (NTSC anyone?) but don't hesitate to suggest more improvements!

Hi popmilo, of course competition is part of the fun but I think no matter which game wins the contest we all won. - Those are winners who submitted an entry because they got something finished. Yes, the final 10% are hard work. But 90% are pure fun. Not only coding was fun but cooperation was fun as well. I talked to several people during development and these contacts were the ones that kept me motivated. Not only they provided superb graphics or fantastic sound, helped with code snippets or helped with setting up the development engine. I just got the impression that there are persons out there who have the same hobby, like to be productive etc. and simply like being an 8-Bit-ATARIan. - Those are winners who still get new releases for a platform that is nearly 40 years old. These games might be good or bad this year (who can tell from some screenshots or videos?) but we still get new games we can talk about, share our opinions about them, love or hate them. - Those are winners that perhaps got their motivation back to work on their own games so that these games are ready next year even if they did not participate this year. Finally, I enjoy what we got. I think there is a nice variety of games, we got six entries, one of them even revived a genre that was already dead (text adventures). I'm eagerly awaiting the abbuc disks.

Thanks for your fast reply, guys! So I have to find a different solution then.

Hi, is there by any way a chance to change the priority of player five (when you combine all four missiles to have a different color than from the player the missile belongs to)? Whatever I write to gprior the fifth players always stays on top of the playfield, but I want it to be behind the playfield. gprior (623/$026F) is set to 52/$34 04/$04 = priority PF0-PF1-PF2-PF3 P0-P1-P2-P3 BAK 16/$10 = Four Missiles add up to be 5th player 32/$20 = Overlapping Players have 3rd color When I do not combine the four missiles to a fifth player priority is fine but then I am missing the additional color.

Well, actually it is a combination of several things. First it was a problem of internal character code/ATASCII. Now that I corrected the code it is running fine with both Altirra/Original hardware. Unfortunately when I use the above corrected code snippet in my complete program it doesn't work on original hardware but on Altirra. So there still IS a bug in my complete programm. When I change my complete programm that I jmp to the subroutine it works on both Altirra/original hardware but not when I jmp to the subroutine at the intended moment (well, when there is a new highscore saved). Have to investigate that later when the rest of the program is finished.

Thanks for your reply. As with altirra and wudsn I am able to have source level debugging so I can check the Y register immediately. I am also going to try your other suggestions. I am using MyDos and as an .atr in Altirra with read/write operations enabled. In the meantime I found out that when I write a different TXTBUF for example "abcdefghi" everything is running fine. Strange.