ggn

Ok, since I replied to a private e-mail the other day and I've been getting some PMs, I might as well post here: Just do whatever you wish to do with the project. Fork it, rename it, rip out bits of it and use it elsewhere, redo from scratch - it's all good! It's not like I'll lose millions on it or something. Just use your common sense and it'll all be fine. And for people that like FAQs, here is the same thing in that format: Q: Can I....? (assuming using common sense) A: Yes! So, Merry Christmas to everyone and stay safe! (and have fun with this)

Not sure about the MADS format but I remembered of an effort that recreated all the original listings from scanned documents here:

Regarding Pascal, nowdays you can use Free Pascal (which as of recently has TOS support: https://www.freepascal.org). For a live demo check out https://tinyurl.com/y7cbmwdn

68000

The scene composition is great on its own. That it fits into 256 bytes makes it something special.

I'm only about 15 levels in (from a brief play in the afternoon) so it's probably early . In any case, for now I can't think of a way to describe the game without spoiling it for people. And therein lies the magic of it (and Baba is you of course): figuring stuff out on your own and being surprised at the game and yourself for figuring out a solution. (If the solution is not the intended one, even better!) Anyway, enjoying it for now!

Just got my collector's edition today. Here's a pic of the goodies before opening the shrinkwrapped box (the poster is not in this shot): Excellent quality of all the things, especially for the asking price! I assembled the lego robot and it's now on my desk, lots of manuals and reference cards (and lego assembly instruction booklet) printed in glossy paper. Oh, and the game is super good of course . Then again I'm a Baba is you fanboi so it's no surprise there . So: congratulations to @ilmenit, @Duddie, @michomis and everyone else who worked their butts off to make this happen. Atari 800 GOTY for me hands down, then physical release is just icing (but very well done all the same)!

And you think this is going to improve her mood? Seriously, the game requires a combination of luck and patience. One thing I do at the beginning just to get a few points is to hit the first bubble dead center. This creates a huge bubble at the top of the screen. However this is very easily breakable if you hit it from the left or right sides - hopefully there will be multiple bounces so it'll be easy. Another worth mentioning is what @Irgendwer kind of demonstrates on his video - if possible create some bubbles at the bottom left and right corners. These will create a sort of shield so you can start launching a lot of bubbles at the top and popping them. Lastly (and quite obviously) try to at least hit one bubble per turn, otherwise the screen might fill up quite quickly!

Also, if I'd add something, it'd be medium resolution support, i.e. run the interpreter from medium resolution so we can get 80x25 text mode. This will probably need yet a few more changes but it's not too bad...

Okay, here we go, now it displays the pic, saves/restores/sets palette, runs the interpreter etc etc! I also added a 5 second pause so people can appreciate the title pic :). I restrained myself to make a palette fade in/out routine, at least this works as intended!

Ok, information is coming back to my head bit by bit. Before you EXEC you need to tell TOS to free as much available memory as it can. So try adding this before EXEC: RESERVE 100 Then you might see something happening! Okay, you're setting the palette to your pic but you never restore it. So your set palette code is going to also read the old palette before doing anything. So, the following should work: dim oldpal&(16) for i&=0 to 15 oldpal&(i&)=xbios(7,i&,palette(i&)) next i& Then when exiting you can restore the old palette using void xbios(6,l:v:oldpal&(0) Of course this triggers yet another change, i.e. the way you read the palette into a string. Let's change that too, from BGET #1,VARPTR(palette$),32 to dim palette&(16) bget #1,varptr(palette&(0)) Hopefully you get the idea, if not just say so . Also, the code above is untested, so apologies if I got it wrong.... If my suggestions don't work out then sure. And no worries :).

1) Try: VOID EXEC(0,"JZIP.TTP"," TRISTAM.Z3","") So the parameter(s) you want to pass to the executable should be placed in the second argument of EXEC. You might have to add a leading space to the parameters - if you notice carefully what I typed above there is a space between the opening quote and TRISTAM.Z3. I'm not 100% sure it's needed - my memory is hazy but try it with and without a leading space and see what happens! 2) CLS should clear the screen 3) The underscore could be in many places depending on your TOS nationality. For the UK version at least you should be able to produce it by hitting shift+whatever key is next to zero on your keyboard

Alternatively you could use @vitoco's tool, get the multiple images and join them together with something like imagemagick: convert page1.bmp page2.bmp page3.bmp page4.bmp -append joined.png

At least @vitoco has a web service for that here: http://www.vitoco.cl/atari/atasciiprinter.html

By the way, if anyone tries this with H: emulation enabled in Altirra, the game appears to hang on the level select screen. Just disable it and it'll work fine. (I guess the game first tries H: for levels and gets stuck in an infinite loop? @pps can probably explain this better!)

Sure, let's talk .org. (spoiler contains some boring history, skip if not interested) During another projecta (also this) I decided it would be good to have absolute assembly directly from rmac itself. Thus the -fr switch was introduced, which requires .org. So, the only use case that .org in 68k makes sense is only if you wish to output an absolute addressed binary directly from rmac. This means you can't link object files, everything must be a single compilation unit (i.e. .include all files from one), and only one base address is allowed. Now, it's quite weird that your source (with multiple .org statements) assembles at all without complaining about multiple .org statements. I'll check it again, this might be a bug that should be fixed. In general, don't worry about .org statements in your code. You pass text/data/bss addresses during link time, and that should be all you need. Those segments are assumed by the linker to be contiguous and not have gaps in them. if you do have a special need for multiple starting addresses for your code, then we can talk.

Right, first of all: sorry for the late reply. I was occupied with random things and kept putting this off. Thanks for the included code, this gives me a good example to explain the limitation here. I'll include the relevant bits below: .extern jagbits [...] .macro Macro_Test Macro_Test_DATA, Macro_Test_DATA2 .Macro_Test_DATA_W1 = \Macro_Test_DATA2 | (\Macro_Test_DATA >> 32) .Macro_Test_DATA_W2 = \Macro_Test_DATA2 | (\Macro_Test_DATA & $FFFFFFFF) dc.l .Macro_Test_DATA_W1, .Macro_Test_DATA_W2 .endm [...] Macro_Test jagbits, 32 ;<-- Doesn't work So, let's break this down. First we're asking the assembler to trust us, there is a symbol called "jagbits" defined somewhere else so it's all cool. The assembler replies with "sure buddy, no problem of mine. The linker will have to solve this issue". Then we ask the assembler to do bit manipulation on the symbol and create data based on that. Anyone notice the issue here yet? If the assembler has absolutely no hint what value the symbol contains, how on earth is it supposed to perform maths on it? And sure, for the sake of argument let's say that we allow this during assembly time and defer this until the fixup pass (where any unresolved symbols had better resolve or else). Since the assembler still has no clue about the symbol, it can't evaluate anything. So that's an error. What would be required here is a way to pass all that stuff to the linker so it can do all the fun operations. As far as I know, that's not a thing for any format and certainly for COFF, unless ELF has some oddball mode that does this (please let this not be the case!). So, how to overcome this? Well, just use externals like they were supposed to, point to actual static addresses! One way to rewrite the above could be: .extern jagbits [...] move.l #jagbits,d0 lea our_lovely_addresses,a0 move.l d0,d1 lsr.l #32,d0 move.l d0,(a0)+ move.l d1,(a1)+ Just simply do all the manipulations you want to do during runtime. It'll cost you a very slight fraction of CPU time during init and that's it. Anyway, I hope this sheds some light on the cryptic error messages you stumbled upon. P.S. That macro is very suspicious BTW, why do you assume jagbits to be a 64bit value? While rmac uses 64 bits internally, I really doubt COFF symbols are more than 32 bits. I assume it's probably an example macro, just sayin'!

Not troll, but help vampire

Can we at least correct the topic? Ed Bogas wouldn't be amused :).

It might be interesting to post one of the error lines so we could see what the expression is.

I can suggest 2 things: a) Use .include so both files are assembled in one go. No .extern/.globl required then. And don't worry, rmac's assembly speed is quite fast, you won't notice anything if both files are assembled every time! b) Use jagbits instead of TALKIETALKIE. rmac's line parser explicitly prohibits EQUing an undefined symbol (and we probably don't want to venture down that avenue as it gets philosophical, or ever religious!)

Hi there, I was thinking of biting the bullet and getting myself a membership. I'd just like to ask if I do get access to the older issues and downloads to the software competition disks etc. I'm assuming "yes" but even so I'd appreciate a confirmation before proceeding

Just to save people some time: I've been using sphinx to render [url=http://rmac.is-slick.com/manual/rmac.html]rmac's documentation into html[/url] (originally written in restructuredtext), and this thread reminded me that it also supports text output. Sadly, I get the exact same results with tables using that tool - one super long line without wrap around. And no options in the tool to set line width. Seems like text output is not a huge priority to these people....

Or just take 5 minutes to install gcc and make and compile it yourself. If you're a dev, and you're already into the linux rabbit hole then installing dev tools shouldn't sound like a daunting task. So, man up and ditch containers I say Apologies for the thread derail btw 😕 (Final note: I just built a version of rmac with statically linked musl using alpine linux. So if that works, we might start distributing linux rmac/rln binaries)