Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

ggn

Members
 View Profile  See their activity

  • Content Count

    1,684

  • Joined

  • Last visited

Posts posted by ggn

  1. Posted

    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)

    • Like 6
    • Thanks 13
    • Haha 3

  6. Posted

    1 hour ago, ilmenit said:

    Thanks! Share also your gaming experience and feel free to ask any questions about the levels or mechanics. Some rules are different than in Baba Is You, but should be easy to spot and understand the differences.

    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!

    • Like 1

  7. Posted

    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):

     

    image.thumb.png.72a8bc75e7a01cb10181df7fc4e3034f.png

     

    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 :D.

     

    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)!

    • Like 1
    • Thanks 1

  8. Posted

    14 hours ago, Stephen said:

    Thanks so much!  The wife has had a terrible week at work.  I'll see if we can fire this up on the big screen later :)

    And you think this is going to improve her mood? :D

     

    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!

     

    • Like 3
    • Haha 1

  12. Posted · Edited by ggn

    1 hour ago, hlabrand said:

    Thank you!

    I tried just the first line in GFA Basic and it didn't work - I mean, maybe it executed something, but the program ended immediately.

    (Maybe you want more information on the program: when I click on JZIP.TTP from TOS, it asks for a parameter, which is 'tristam.z3', then it starts a terminal and loads the game file. Do I need to tell the script to open a terminal?)

    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!

    Quote

     

    Also, another slight problem with the code: the colors of the OS are all wrong after I execute it... Probably because of the line ~XBIOS(6,L:VARPTR(palette$) in the original script. Any way to restore the palette to its default value (or to whatever the user had before) after displaying that image?

    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....

    Quote

    If it's easier to post my .st file here, tell me... Thank you for your help :)

    If my suggestions don't work out then sure. And no worries :).

  13. Posted · Edited by ggn

    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

  17. Posted · Edited by ggn

    1 hour ago, Cyprian_K said:

    What about .org statement?

    Sure, let's talk .org. (spoiler contains some boring history, skip if not interested)

     

    Spoiler

    Back in ye olde days of MadMac, the assembler was made so it supported two formats: TOS prg and object files. Both of these formats are relocatable and don't allow placing code in absolute positions. If such a think was needed, it was a job for the linker.

     

    Then 6502 support was hacked in, where .org was introduced. But only for the 6502 mode.

     

    (I'll omit the modifications done to MadMac by Brainstorm as we don't have access to those)

     

    Then the source was released to the public by Mr Dyer. SubQMod picked up the source and added Jaguar support. He followed the Brainstorm model of primarily outputting 68k object code with Tom/Jerry code inlined. The 68k code was still handed over to the linker for generating the appropriate output format (coff/abs/plain binary assembled at fixed address, etc).

     

    Then that source was picked up by Shamus (and later myself) and DSP56001 mode was added, which allows for multiple .org statements. We still didn't touch the 68k output, .org was still illegal.

     

    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.

    • Like 2

  18. Posted

    On 10/28/2020 at 7:24 PM, Cyprian_K said:

    Ok, in attached GPUINT.tst.zip in file gpu_list.s I added test macros: 

        Macro_Test    UpdateList, 32     ;<--    Works ok
    Macro_Test    jagbits, 32        ;<--    Doesn't work
    Macro_Test    width, 32          ;<--    Doesn't work

     

     

    how do you generate COF then? rmac with -fb flag gives me only .O file.

    yes, in makefile jaguar.bin is defined as jagbits.

    ok, now I use ".incbin" for jaguar.bin, and "include" for other .S files, and problem with external variables has gone.

     

    but I faced another problem with ".org" in JagTST.zip

    currently all variables point to the same address $4000 

    	lea	v_bmp_lowl,A0
	lea	a_hde,A0
	lea	main_obj_list,A0

    When I comment ".org    $4000" from row 62, then those variables point to the same address $0

    When additionally I comment ".org    objList" from row 41, they point to correct unique address (based on definition from makefile), but my ".objproc" points to address in the rom. which isn't ok.

     

     

     

     

     

     

    GPUINT.tst.zip 17.39 kB · 2 downloads JagTST.zip 18.3 kB · 3 downloads

    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'!

    • Like 3

  21. Posted

    10 hours ago, Cyprian_K said:

    regarding b) when I try to pass jagbits to my macro I see following error message 

    gpu_list.s 238: Error: undefined expression
gpu_list.s 226: Error: undefined expression
gpu_list.s 226: Error: undefined expression
gpu_list.s 260: Error: undefined expression
gpu_list.s 260: Error: undefined expression
makefile:16: recipe for target 'gpu_list.o' failed

     

    if it's needed I can post a source code (it is actually a bit modified Atari's workshop)

     

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

  22. Posted

    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!)

  24. Posted

    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....

  25. Posted · Edited by ggn
    Extra thoughts

    10 hours ago, cubanismo said:

    So how do you build against an ancient libc without maintaining crusty build machines?  Containers (or their predecessor, chroots) of course 🙂

     

    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 :D

     

    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)

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...