ggn

Well, that's exactly the kind of pass I was looking for to comment again in this thread. First of all: this is a good game. Like I've commented earlier in this thread, the game mechanics do their job well, building on top of solid ideas and giving the player a set of levels that are challenging. This really is not a game for casual gamers, you really have to think hard in some of the levels and consider all the things the worms can and can't do. Now, for some nitpicks: - The music is a bit too... for the lack of a better term I'll go with "busy". Sometimes it grabs my attention when I'm trying to think a few tens of moves ahead and breaks my concentration. Of course the fix for that is to turn the music down or even off. But still I'd have preferred something more relaxed like the Snakebird soundtrack for example. - Similarly, I'd have welcomed some sound fx, so I can have audio feedback when I move or pick up a fruit. Unless there's an option to turn sfx on and I missed it? - As for the graphics, I'd have loved to see some distinction between tiles that matter and static tiles. I.e. some sort of hinting of the fruit, as sometimes they're hard to tell apart plain background tiles. Maybe a subtle flash of those items would have helped (although I guess hardware limitations come into play here. Still, sometimes that doesn't put people off!) - I wish there was a better way to track progress. In some occasions I hit start instead of option to restart a level, and got booted off to the title screen. Then it seems that I have to replay all levels in a world to get to the stage where I was. Not very pleasant, I'll tell you that. Even a sort of password system would have helped, then I could just go back to where I was before the disruption. Hopefully I'm not sounding too negative here. Like I declared above, I like this game. This is just some constructive criticism that only aims to better the game. As for that other matter in this thread...... I've heard all sorts of remarks from people about toxic members of the community, deliberation, malfeasance, and so on and so forth. My reaction to that is: "What?" If someone wanted to harm people's machines or whatever (as I recall reading in this thread), would they go into all the trouble designing a game and adding bells and whistles to it? Really? I thought one would only need to create a binary that bricks people's machines and send it to a party, like some sad people from the Spectrum community did in the past. So please, don't overreact. Now I will say that not supporting U1MB could have been handled better by the game. For example if the game detects U1MB then display a message like "Sorry, this configuration is not supported" and stop executing, instead of plain freezing without any feedback to the user. I'm all up for supporting all configurations, or as many as possible. Heck, I've spent a sizeable chunk of my life fixing stuff so they run correctly across the Atari STs, STEs, TTs, Falcons etc. So I know first hand what a pain it can be. In addition, I've also released quite a few games and demoscene productions, all under the same philosophy. All this gives (in my humble opinion of course) some extra weight to my next point: It doesn't really matter. At home I have at least 5 Atari XL/XEs, either stock or modded. If some game or demo requires a different configuration, I just grab another, switch monitor and power cables and joysticks and I'm up and running in minutes. No problems. If push comes to shove I'll just take a look at the software under the hood and try to fix it myself. But this is a very rare phenomenon, because switching machines is much less effort really. I won't say that communicating this was stellar in this thread. There were a lot of accusations flying from both sides which could have been avoided if people were more calm. Also I'm willing to claim that a chunk of miscommunication can be attributed to the language barrier, so misunderstandings happened. So, to sum things up (and apologies for dragging on and on with this post): - The game is good, could be better, and I encourage people to try solving just a few levels to fully appreciate all the mechanics. Thanks to the authors for this! - Calm down people, it's not the end of the world. It's a 40 year old platform and people should be in it for the fun, not the drama! P.S. If people want to discuss my non game criticism points in the post I encourage them to PM me or hit me up on IRC or something. My intention for this post wasn't to pour more gasoline into the flames, just wanted to present my take on this (and provide some constructive feedback to the authors).

Sorry to hear that. Very weird that you don't have those command line tools available. In all my machines both tools are at c:\windows\system32. As a last ditch attempt you could look if you have xcopy.exe in there. If yes, you'll need to fix your PATH variable. Alternatively here's a fix for build.bat: open it in a text editor and go to line 299. There should be a xcopy command. Delete that line and replace it with the following: mkdir projects\%PROJECTNAME% mkdir projects\%PROJECTNAME%\build mkdir projects\%PROJECTNAME%\assets mkdir projects\%PROJECTNAME%\assets\fonts mkdir projects\%PROJECTNAME%\assets\gfx mkdir projects\%PROJECTNAME%\assets\maps mkdir projects\%PROJECTNAME%\assets\sfx copy include\template\*.* projects\%PROJECTNAME% copy include\template\assets\*.* projects\%PROJECTNAME%\assets copy include\template\assets\fonts\*.* projects\%PROJECTNAME%\assets\fonts This should take care of things.

This is weird, according to Wikipedia xcopy has been a part of Windows system files since Windows NT. In any case, I'd try the following if I were you: 1. Open an administrator command prompt and type "xcopy". If it is found then open a normal command prompt and again run "xcopy". This might indicate some weird permissions problem. 2. (Do this at your own risk! Something bad could happen!) Open an administrator command prompt and type "sfc /scannow". This will repair and hopefully restore missing files. Then try running xcopy and see if it's there. 3. If you don't want try step 2, try opening a command prompt and type "robocopy". If that tool exists I'll change build.bat for you to use that. 4. Failing that, creating a new project using "build.bat <projectname> new" is nothing magical. Just copy the folder "template" from the "include" folder into your "projects" folder. Then rename folder "projects\template" to "projects\yourprojectname" and then open "projects\yourprojectname" folder and rename "template.bas" to "yourprojectname.bas". "yourprojectname" can be replaced with pretty much whatever you like. Then if you open a command prompt and type "build projectname" it should go ahead and build/run the project. Hope this helps, let us know how you get on with this.

I agree with pretty much with what Mariusz said. While I was looking to take Maziacs apart to port it to the Atari ST (which I did) I did look around for z80 disassemblers. What I was looking for was one that would be interactive and have a GUI. I did stumble upon skoolit and after 5 minutes of reading about it I dismissed it - it fails miserably on both my criteria :). Actually the way you control the disassembly and recognise parts of the binary as code or data is one of the most un-intuitive things I've seen. So, to cut a long story short I would recommend that people try Ghidra out. For anyone that gets triggered with the tool being released by the NSA (tinfoil hats on etc etc) there is radare2 and one of its GUIs, cutter. Lastly, for people who want to spend a few bucks there's Binary Ninja, and for those who money is not an issue, IDA Pro. With so many superior choices for disassembly tools, the only reason one would ever use skoolkit is if someone actually disassembled a few z80 games with it (I haven't checked but I doubt that there are people lining up to use this :)). And even then you just get the source code and pipe it into Mariusz' tool and work from there.

That's..... a bit rigging the vote though? I mean, you're influencing people to vote for the more popular entries. This means that people might find some hidden gem among the titles outside the list.

All right, I had a super hard time picking only 10 titles (and even more difficult to rank those), so hard when there's so much quality stuff being released :D. Anyway, here's my pick: 1.Gravity Worms 2.Fruity Pete 3.Adventure Ponies 4.Mister Hoppe 5.Rescue Expedition, The 6.Great Green Adventure 2 Prologue 7.Wasteland 8.Berks Four 9.Last Disk +, The 10.Mini Bros And just for completeness here are the runner ups/honorary mentions/didn't make the cut/sorry I left you out (in no particular order): Space Fortress Omega Jaskiniowiec w czasach Inkwizycji Joyas Millionaire 601F Block on Legs: First Steps Lastly, I'd like to take this opportunity to thank all creators for releasing all those good stuff for us to enjoy. Hope that this year will also be an excellent one for Atari 800!

So far I've tried this on 3 different PCs and they all work, so I sorry but I can't reproduce. I can't think of anything apart from asking you to state your windows version and if it's 32/64 bit. Lastly, open a command prompt and type "set rbtools". If this exists it will point to a path on your hard disk. Verify that it is the exact folder you have your rb+ install. If not you will need to unset it. Grasping at straws here but I can't think of anything else, sorry.

That's @Zerosquare's code which (as he mentioned) is not tested. How about mine?

Sorry, I can't reproduce that here locally. To be clear: I downloaded a full archive from https://github.com/ggnkua/bcx-basic-Jaguar (pushed 'clone or download' button, chose 'download zip'). I unpacked the zip somewhere on the hard drive opened a command prompt at the root of the unpacked zip location I typed "build testproj new" I opened projects\testproj\testproj.bas I edited the file and pasted the sample code from reply #39 and saved I typed "build testproj" on the command prompt Everything built and virtualjaguar came up I really can't imagine what went wrong with you there, it seems like some library is missing or truncated (=corrupt). Try again using the steps I outlined above and let us know what happens.

Right, first of all let me just say that string handling in rb+ has always been a bit problematic (and broken, let's not mince words here). You see the extra space in your print statement because of number-to-string conversion. If you read the bcx help file for str$ it is mentioned that So that's what you see there. How to overcome this? Well, it's a bit complicated but doable of course. Before trying my suggestions you should download the latest rb+ from github as today I've pushed some fixes regarding all this. After the update you can try the following code: dim seconds as float seconds=0.01 dim st$ rlocate 30,30 do vsync st$=str$(seconds) print mid$(st$,2,2) seconds=seconds+0.01 if seconds>=1 then seconds=seconds-1 endif loop If all goes well you will see a 2 digit number counting to 99 and then going back to 00 again. It works by placing the two digits we want to the decimal places of a floating point number, converts that to string and takes the 3th and 4th digit from that (i.e. omit the "0." part of the string). There is also a protection of resetting the number going above 1, because if the number reaches 10, we would have to then take the 4th and 5th digit. Anyway, hope this helps!

Great stuff @xxl - looking forward to the final. Would even buy a physical copy if it happens!

That's a happy banana if I ever saw one!

From the GFA Basic manual: LPOKE XBIOS(14,1)+6,0 --> Sets the head and tail pointers to the keyboard buffer to the buffer start, effectively erasing the buffer. or alternately: REPEAT UNTIL INKEY$="" --> Deletes the keyboard buffer, character by character. Hope this helps!

Just get an OSSC or [url=https://www.retrotink.com]Retrotink[/url], both devices have proven to function very good with ST line of computers (Retrotink has lower latency than OSSC)

Short answer: yes. Long answer (skip if you're bored): At the bottom of sound.s there are a few labels that are at the same time exported as globals and equated (EQU). rmac's COFF file writer hadn't expected that possibility and simply exported the labels as absolute. The problem with that is that the linker isn't allowed to modify absolute labels, so it simply uses whatever value it's fed. BUT: the equates are in fact relocatable addresses! Oops! Of course the most important thing is: which is good! I will try to create your dev environment above but I'm glad we at least fixed this without breaking anything else :). Also, since you did so much work and want to share it with people perhaps you should make a new topic so it'll have more visibility?

Right, so I managed to pass through the maze of twisty little tunnels, all alike, and came out with parts of my sanity :). I have a fix for the situation but it's super tentative for now - I'll have to run this past Shamus and we'll need to check with our regression suite to see if nothing breaks (because yes, we do have such a thing nowdays!). Without further ado: Open object.c and go to line 175. There should be an "else" in that line, a closing brace directly above and an opening brace directly below. Change the "else" to "if (w1 & DEFINED)", recompile rmac and you should be good to go! (unless I screwed something up. Never underestimate this!)

First of all, no worries about the supposed wild goose chase - it's all good! As for which sound.o I used: well, I just unpacked the "Jaguar_linux_dev_setup_rv6.zip" and started looking for the filenames of the objects I wanted to link against. It might have been from the "old" folder or the "new" but I'm not sure. The thing is, all sound.o files in that archive (and there are 3 of them) are byte for byte identical between each other. I also did some byte comparisons between the files in the folders the 3 sound.o files are and the files in the .zip file I uploaded above. I still get byte match for all files. Next thing I tried was to assemble sound.s with rmac myself. The resulting .o file isn't byte match identical to the archive's .o files. So that's progress I guess! I'll see what happens from here, there were quite a few changes that happened for v2.0.0 of rmac so it's not impossible that something upset the jrisc parts. I'll have a look and will report back when I have something. Stay tuned.... [EDIT] Now that I think about it: do you happen to know what version of rmac you used to assemble the sound.o in the archives? Or have I got it wrong and it was assembled using mac?

Okay, many thanks for this, it really helped with my findings. So here's what I got: 1. The .o files you supplied that are assembled with rmac and mac are byte for byte identical. This proves that rmac is rock solid and (almost) a drop in replacement for mac - high five! 2. This also stands true for the .o sets of files I produced independently of yours. So we're two for two :). 3. Linking - geez, that proved a major source of pain. I really ought to add a patch to rln that validates search paths instead of blindly accepting them, someone has to get this right :/. As usual, it's no fun adding a path that you have a typo and then the tool proudly reporting that your requested file could not be found, leaving you scratch your head in order to understand if the relative path was wrong or there was a typo or whatever (ok, rant mode off now, sorry!) 3a. Once I sorted out all the files etc (in my usual style I just copy all .o and .a files into the build folder and let rln parse the files from there!) I created a linked .cof file that run on virtual jaguar without crashing - yay! 3b. Out of curiosity I then took your "mod_tracker_crash_rmac" and just pasted the object files and libraries that I used to link my build files and that also resulted in a working binary - double yay! I went ahead and attached the winning combo of .o and .a files. Which leads us to takeaways: 1. Yeah we probably need some more work when it comes to user experience for rmac and rln. Bear with us! 2. I'm not sure what happens with your setup. Some file you link against seems to have an issue. I'd suggest you try linking with my set of object files and see if that works for you. If yes (I sincerely hope so!) then you can take it from there and check your build environment for the bad file(s) that produce the bad .cof. 3. Sadly I couldn't repro a crashing binary after all the above. So if you find the offensive file(s) it'd be interesting if you share them with us for further analysis into what went wrong There we go, sorry for the wall of text but I hope this helps fixing your problem and hopefully we can put this unpleasant experience (for you at least) behind us! object_files_and_libs.zip

Oh damn, I should have been more explicit when I mentioned "object files". I meant the object files created when you built the two examples, not the compilers themselves (so the .o files created like modTkrCrsh.o, gfx/data/gfx_data.o, etc). Sorry I put you into all that trouble really. Although it's not in vain as I'd probably end up asking you for the library files as well (rmvlib.a, jlibc.a, libgcc.a). Yesterday I tried assembling the project's assembly files using rmac and mac. The resulting object files were byte for byte identical between assemblers. So it all points to linker problems (like @Welshworrier pointed out above). Jesus Christ no :). Never mind that my PC is an old fossil by now, I'm pretty much against running VMs for developing! As Mr xkcd put it eloquently: In comparison WSL is a much better compromise than the trainwreck that is called "spin a VM" - much less resources consumed, shared file system and the ability to run native linux binaries on Windows without spending tons of disk space and RAM :). I was in the process of bringing it up to the latest ubuntu yesterday, but thought to ask @lachoneus for the files to accelerate the process a bit. No harm done though, I'll take a look at rln like I said.

First of all thanks ever so much for deciding to stick with rmac. We'll get it fixed, don't worry! Unfortunately I don't have any Linux machines around as I've given up on Linux running smoothly on my machines at home. I'm trying to get WSL on Windows 10 updated to ubuntu 19.10 but it seems like it'll take some time. However I think that if you also upload the generated object files from all folders (rmac/mac/gcc) so I can have a "golden" reference I can then see the differences and when things go haywire. My gut feeling for now is that rln is at fault but I'd like to double check that the object files are also okay before going there. (Yes I suppose I can find a copy of mac/aln and run them on dosbox but I think it'd be better if I had your copy of the object files altogether!)

You really don't need to upgrade your linux distro just to have a m68k gcc. A few years ago I made a script that builds gccs 4.6.4 to even the most recent ones (9.x) regardless of your linux distro. Of course the script targets ELF binaries but it really doesn't matter since Jaguar binaries are built to be absolute position without any headers. That script has grown to be long and complex because we (me and DML) wanted to also build C++ support and libraries in order to be able to build TOS binaries. Most of that complexity will go away if you remove these goals (i.e. just gcc with C support and a bare bones libc). If anyone is interested I could attempt to chop the script down. On a modern PC running a linux vm and 4 simulated CPU cores the build time should be around 15 to 20 minutes so it's not that bad.

Okay, many thanks for sticking with this - there's nothing more annoying than setting up the toolchain and build system and THEN having to fight with buggy tools :). Think of the current rmac workarounds as temporary. Me and Shamus will try to get to the bottom of this and fix these issues in the official source tree so nobody has to undergo the ordeal you did! I'll give your script a go soon though, thanks for sharing. The rmac authors hope that people use it in their toolchain to create useful software and move away from moldy old software that require VMs to use :). P.S. any other issue you encounter with rmac, let us know!

Sorry you couldn't get this to work. From your log I see that display.s gets compiled correctly now but sound.s isn't. I just went and double checked, no issues here. I can only assume that for some reason it's using the unmodded rmac version. Can you double check that your Makefile.config points to the freshly modded/compiled rmac? (MADMAC line at the top of the file). Also, this is not a C compiler program as the errors seem to lie on rmac, so for now you should focus there.

Ok, so first things first: rmac and rln do have an official distro here: http://virtualjaguar.kicks-ass.net/builds/ or if you need to build from source: "git clone http://shamusworld.gotdns.org/git/rmac" and "git clone http://shamusworld.gotdns.org/git/rln". The first link holds the windows and mac builds, so there's no need to upload versions anywhere. Also I noticed that the version @swapd0 uploaded is an older one, so it's also another reason :). For obvious reasons we don't host any linux binaries so people are encouraged to build from source in that o/s. With that out of the way, I had a go at building the removers' libraries, which meant I had to fiddle with makefiles (yuck!). I'll get back to the topic in a bit, I'll just skip forward a bit to mention the rmac assembly issues: a) There is a small issue with rmac not handling * as program count on expressions. I didn't fix that inside rmac itself but I bypassed it by altering the offending code. If you open display\display.s you'll find a line that says "padding_nop (G_RAM+$10-*)" and another "padding_nop (G_RAM+$40-*)" which both give out some cryptic errors. These can be overcome by equating * to a symbol in the previous lines. I.e. go to the first padding_nop line and add a line directly above that says "pc1=*", then modify the offending line to ""padding_nop (G_RAM+$10-pc1)". Likewise, go to the second line and add a "pc2=*" immediately above and modify line to "padding_nop (G_RAM+$40-pc2)". That should take care of that. b) But there's another issue inside rmac that can't be fixed that easily unfortunately. For this you need to modify the code and recompile rmac for now. Namely, open file expr.c and go to line 421. The line there should read "*a_attr = cursect | DEFINED;". Change that to "*a_attr = DEFINED;" and recompile rmac. If you do these two steps correctly and you've set up your paths to point to the correct tools you should be able to compile the code all the way through. At least on my setup with gcc 9.2.0-m68k it seems to create the library no problems. I just skipped the doxygen doc generation as I don't want to install that. Getting back to the main topic now. The whole a.out requirement is a bit weird to me. a.out is for creating binaries that are relocatable so the operating system can load them, relocate them where they're loaded and then execute them. Jaguar binaries are by default absolute, i.e. you have to tell your linker to hardcode them into specific addresses (for example $802000 for ROMs or $4000 for a typical bjl binary). This can be done without generating a.out binaries at all, just tell the linker to grab the libraries in whatever format they are and the object files, jam them together and hardcode all addresses, then write the binary to disk. It's true that a.out is also a format for object files and libraries as well. I encountered this problem a few years ago when trying to build a cross gcc compiler for Atari ST binaries. I mistakenly thought that the a.out format was dropped back then and only elf was available (that was true to some extent). So I managed to use the elf format for gcc and covert the elf binaries to tos executables. (sorry for babbling, we're getting to the point!) The side effect is that we had to add elf support to rmac, so it's there by default now. What this all means is that you can now use the elf format for gcc and rmac, and produce object files that are compatible with each other. I'm pretty sure that the gcc linker (ld) then can generate absolute binaries. Anyway, that's as far as I got to this evening. If you'd like to try my fixes above and see if at least this fixes the rmac issues we could figure out the rest. Ideally a small test project that uses the library and builds a small binary would be a great help at this point, since I'm not familiar with the library at all! Hope this helps a bit! (also I hope Seb will read this and comment!)

FWIW I'm taking a look on why Seb's code won't assemble under rmac, so far it seems that a macro is making the assembler mis-behave. (I guess worst case the macro can be rewritten to comply but I'll take a crack at fixing the issue first. Since it's working with madmac and all...)