Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Information about the Apollo CPU and FPU.

Writing 3D Engine for 68080 In ASMpage  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 

Vladimir Repcak

Posts 359
31 Dec 2019 01:10


Nixus Minimax wrote:

  AmigaOS is the operating system every Amiga came with. It comprises several libraries among which the most fundamental are exec.library, dos.library, intuition.library and graphics.library. They are always available from the Amiga ROM (the "kickstart"). The last version Commodore did was 3.1 which may be considered standard. Everything after it were basically variants of this version with various bugfixes and new bugs added. For what you are going to do even v2.0 would suffice.
   
    Disabling the OS is something like an Amiga tradition but it doesn't make too much sense here. Even with a 50 MHz 030 the OS idling in the background took only about 5% processor time. With an 080 that is 20 times faster the speedup gained by disabling the OS becomes totally negligible. And it's much cooler if multitasking is still working, network connections stay up and you can just put the game screen into the background.
 

  Thanks for the explanation. I agree that if the performance of running OS comes down to just few %, it's not worth disabling it (unless there are other issues that I am not aware of at this moment).
   
 
 
Nixus Minimax wrote:

    Now you will want chunky pixels. Since AmigaOS never supported chunky pixels, you will have to go through either cybergraphx or p96 among which I would recommend the first because P96 is compatible with the earlier cybergraphx. If you code for cybergraphx, your code will run on any Amiga system that has chunky pixels - the Vampires are the most powerful among these.
 

  - I spent last two days figuring out the quirks of AmigaShell, Workbench
  - I troubleshooted the shared local directory (to exchange builds)
  - I got WinUAE to start with full config that I don't have to manually touch anymore
  - I also got executables of vasm and vlink that run under the emulator, kinda as a last resort - as I hope to completely avoid the compilation on the target platform and code straight on PC
 
  Now, I am ready to start playing with some code. I got this code sample from Aminet on setting up the chunky screen:
  EXTERNAL LINK 
  However, this thing appears to be going through detection whether it's AGA, CGX, Intuition or CyberGraphx. Mentions also Picasso in the source file. Quite an unnecessary Overkill since the target platform is just one - Vampire.
 
  The provided executables do run in Workbench even in 1280x512 Interlaced (which does, indeed appear to be such high resolution at least based on few seconds of the bitmap scaling it shows).
 
 
  Now, is there any particular reason why Cybergraphx would be preferable on Vampire ? From my understanding, Vampire uses P96 by default, right ?
 
I'll go and see if I can find some code sample starting P96 chunky...
 


Nixus Minimax

Posts 416
31 Dec 2019 08:57


Vladimir Repcak wrote:

      Now, is there any particular reason why Cybergraphx would be preferable on Vampire ? From my understanding, Vampire uses P96 by default, right ?
   

   
    P96, like so many things Amiga, is in legal hell (Cybergraphx is a proprietary product, too). There is an abandonware archive of P96 freely available which may be used fine on Vampires but also new versions which are sold by the Dark Side. This makes P96 somewhat of a moving target. More importantly, AROS is going to be the OS of choice for Vampires in the near future, not AOS. AROS is an open-source implementation of the AmigaOS 3.x API. Since AROS runs on all sorts of hardware including standard PCs, it has to use chunky pixels and for this reason includes an (open-source) implementation of the cybergraphx API. Cybergraphx is the older of the two chunky APIs and P96 was designed to be downward compatible making cybergraphx the least common denominator.


Thellier Alain

Posts 141
31 Dec 2019 09:41


There is in this page some infos about 3D and a soft rendered Cow3D example that can serve as a base to test AMMX optimisations
The example show also how to set up screen the os-friendly way...

CLICK HERE


Vladimir Repcak

Posts 359
31 Dec 2019 15:57


Nixus Minimax wrote:

    P96, like so many things Amiga, is in legal hell (Cybergraphx is a proprietary product, too). There is an abandonware archive of P96 freely available which may be used fine on Vampires but also new versions which are sold by the Dark Side. This makes P96 somewhat of a moving target. More importantly, AROS is going to be the OS of choice for Vampires in the near future, not AOS. AROS is an open-source implementation of the AmigaOS 3.x API. Since AROS runs on all sorts of hardware including standard PCs, it has to use chunky pixels and for this reason includes an (open-source) implementation of the cybergraphx API. Cybergraphx is the older of the two chunky APIs and P96 was designed to be downward compatible making cybergraphx the least common denominator.
I see. So, Cybergraphx will work for game purposes then.

What's the largest amount of RAM any Amiga OS consumes right now ? While browsing the AMIGA_HowToCode7.pdf I noticed the section on dynamic RAM allocation.

Obviously, on Jaguar, without any OS, everything is always placed at fixed address (you got 2 MB and that's it). Hell, I spent 2 weeks recently merely refactoring the system and now almost everything uses a fixed constant for each pointer.

To rewrite the whole game and engine using the OS allocation, that would take easily 6-8 weeks across all engine and game components. Obviously, that's out of the question for the first game on Vampire.

Is there any OS that takes more than, say, 16 MB RAM ? I'll gladly sacrifice first X MB of RAM for that.



Vladimir Repcak

Posts 359
31 Dec 2019 16:11


thellier alain wrote:

There is in this page some infos about 3D and a soft rendered Cow3D example that can serve as a base to test AMMX optimisations
  The example show also how to set up screen the os-friendly way...
 
  CLICK HERE 

If you mean the file you linked to in your post on same page, then that file doesn't exist anymore - throws error 404.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
31 Dec 2019 16:20


Vladimir Repcak wrote:

Is there any OS that takes more than, say, 16 MB RAM ? I'll gladly sacrifice first X MB of RAM for that.

Not sure I understand your question reason?

Lets say on V4 of the 512 MB you might have 506 MB free.
Lets say your game is 100 MB
The will load is "somewhere" and correct all relocation for you.
You have nothing to worry about.


Vladimir Repcak

Posts 359
31 Dec 2019 16:50


Gunnar von Boehn wrote:

Vladimir Repcak wrote:

  Is there any OS that takes more than, say, 16 MB RAM ? I'll gladly sacrifice first X MB of RAM for that.
 

 
  Not sure I understand your question reason?
 
  Lets say on V4 of the 512 MB you might have 506 MB free.
  Lets say your game is 100 MB
  The will load is "somewhere" and correct all relocation for you.
  You have nothing to worry about.

Well, unlike Jaguar, this is a computer with an OS where many processes run at the same time - so it's understandable that the application should just ask to allocate all RAM it needs.
There appears to be a system method AllocAbs (addr, length) that returns the pointer to a requested block of RAM.

Unfortunately, there's ~100,000 lines of code that relies strictly on absolute addresses - there's only few things like FrameBuffers and couple arrays that are handled in a relocatable way.

Everything else has a fixed address, e.g. $13F800, right in the source code, via .EQU constants - because every single Jaguar out there has only 2 MB of RAM and all audio and video registers are at identical addresses (unlike Amiga).

So, I reckon, most of OS shouldn't really take up more than 16 MB, right ? So, I'll sacrifice first 16 MB (just to be safe) and place executable starting at 16 MB.
Should the OS complain and try to crash, I can certainly write one block allocation upon startup and ask for a single block of, say, 512-16 = 492 MB RAM - and this way the game will have all RAM it needs.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
31 Dec 2019 17:11


Vladimir Repcak wrote:

Unfortunately, there's ~100,000 lines of code that relies strictly on absolute addresses - there's only few things like FrameBuffers and couple arrays that are handled in a relocatable way.
 
  Everything else has a fixed address, e.g. $13F800, right in the source code, via .EQU constants - because every single Jaguar out there has only 2 MB of RAM and all audio and video registers are at identical addresses (unlike Amiga).

AMIGA GFX/AUDIO registers are also the same on all AMIGAs.

Vladimir Repcak wrote:

So, I reckon, most of OS shouldn't really take up more than 16 MB, right ? So, I'll sacrifice first 16 MB (just to be safe) and place executable starting at 16 MB.

Well ...
This sounds pretty dirty.

I understand that you fixed GFX register addresses.
But I fail to understand why the program itself needs be put on fixed address.

Can you not just use labels?

BSR 3dmath
BSR clip
BSR render

like this?


Wawa T

Posts 695
31 Dec 2019 17:19


do i understand you correctly, that you code an application that needs to be a loaded to a particular memory absolute address and allocate a hard coded memory range?? wow!


Vladimir Repcak

Posts 359
31 Dec 2019 17:32


Gunnar von Boehn wrote:

  AMIGA GFX/AUDIO registers are also the same on all AMIGAs.
 
 
Vladimir Repcak wrote:

  So, I reckon, most of OS shouldn't really take up more than 16 MB, right ? So, I'll sacrifice first 16 MB (just to be safe) and place executable starting at 16 MB.
 

  Well ...
  This sounds pretty dirty.
 
  I understand that you fixed GFX register addresses.
  But I fail to understand why the program itself needs be put on fixed address.
 
  Can you not just use labels?
 
  BSR 3dmath
  BSR clip
  BSR render
 
  like this?

Labels for code are there, of course. But code starts at a specific .ORG $400

But the variables that touch HW (Blitter, ObjectProcessor) are mostly done like this:

VAR1 .equ $1F3800
VAR2 .equ $1F3840
VAR3 .equ $1F3880
VAR4 .equ $1F3900
VAR5 .equ $1F3A00

Given the issues in the Jaguar's assembler and linker - especially the broken alignment (not always - just sometimes - which is just enough to drive one crazy), this was the fastest way to debug and ensure your code will actually work every single time you add a line of code somewhere else.

Variables that don't interact with HW can be placed via dc.w, dc.l as their alignment doesn't matter.



Vladimir Repcak

Posts 359
31 Dec 2019 17:38


wawa t wrote:

do i understand you correctly, that you code an application that needs to be a loaded to a particular memory absolute address and allocate a hard coded memory range?? wow!

Of course, Jaguar is not a computer like Amiga with hundred configs and OSs and expansion cards.

Your code can start as early as $400. That's where the .ORG directive starts.

Every single Jaguar has 2 MB of RAM and that's it. There's no OS to ask for available RAM block.

Why on Earth would you introduce additional and completely useless memory abstraction layer there? Each game handles the dynamic memory allocation as it needs.

I have my own dynamic memory allocator that uses a portion of RAM for dynamic allocations.


Vladimir Repcak

Posts 359
31 Dec 2019 17:54


Is there perhaps some kind of virtual paging (MMU perhaps?) system on Amiga where you only link your code to a certain 64KB page and then it can be simply loaded at any address (as long as it's on that 64KB boundary)?

Because the linker has to compute absolute addresses of all jumps and data segment/variables during link time.

That, however, would probably kill one address register and introduce performance penalties, as any complex address computation is a multi-cycle op. If that had to be done for every single variable access...



Samuel Crow

Posts 424
31 Dec 2019 18:23


AllocMem in AROS supports alignment constraints and the 68080 supplies 16 address registers.  Just dynamically allocate the space before you take over the system.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
31 Dec 2019 20:46


Vladimir Repcak wrote:

Because the linker has to compute absolute addresses of all jumps and data segment/variables during link time.

This is normal.
The linker will make list of all those addresses and put behind executable. This is called relocation table.
The OS does parse this onloading your EXE, and will adjust your binary.

Et Voila, Your binary can run on any address.


Vladimir Repcak

Posts 359
01 Jan 2020 17:43


Gunnar von Boehn wrote:

Vladimir Repcak wrote:

  Because the linker has to compute absolute addresses of all jumps and data segment/variables during link time.
 

 
  This is normal.
  The linker will make list of all those addresses and put behind executable. This is called relocation table.
  The OS does parse this onloading your EXE, and will adjust your binary.
 
  Et Voila, Your binary can run on any address.

Interesting.

So, I just downloaded Abacus Advanced System Programmers Guide For the Amiga and found the section on DOS Library, which contains (among others) these functions:

File IO:  Open/Close, Read/Write, Lock/Unlock, Input/Output
Programs: Execute, LoadSeg, UnloadSeg
Process:  CreateProc, DeviceProc, Exit, Delay, WaitForChar

And some functions of Exec Library:
Allocate / Deallocate, AllocMem, AllocAbs, FreeMem, AvailMem,

So, I suspect those are the OS library functions people are referring to ?

Meaning, every single OS for Amiga has to support them ?

I haven't found any notes on the relocation table there, though.



Vladimir Repcak

Posts 359
01 Jan 2020 17:49


Samuel Crow wrote:

AllocMem in AROS supports alignment constraints and the 68080 supplies 16 address registers.  Just dynamically allocate the space before you take over the system.

Having just read on the Exec library, is the following understanding of mine correct ?

Option 1: Absolute address of executable via .ORG $1000000
Exec.AllocAbs (ProgramLength, $1000000)

Option 2: Relocatable executable
Exec.AllocMem (ProgramLength, Requirements)



Gunnar von Boehn
(Apollo Team Member)
Posts 6207
01 Jan 2020 20:06


I'm not sure what you try to solve.

Lets say your code looks like this
 
  ADD.L DATA1,D0
  move.l D0,RESULT1
  rts

DATA1: DC.l 5
result1 dc.l 0

You can just compile this.
The ASM will create a file with included all data to run this, at ANY address.
And when you start the program on AMIGA OS then the OS will take care. The program will just work.




Nixus Minimax

Posts 416
02 Jan 2020 09:55


Vladimir Repcak wrote:

  Having just read on the Exec library, is the following understanding of mine correct ?
 
  Option 1: Absolute address of executable via .ORG $1000000
  Exec.AllocAbs (ProgramLength, $1000000)
 
  Option 2: Relocatable executable
  Exec.AllocMem (ProgramLength, Requirements)
 

AllocAbs() requests memory at a specified location. If that memory is already taken, the call will fail and your program will either crash (bad) or abort silently because it can't have what it needs (semi-bad).

AllocMem() gives you a chunk of memory of the requested type at just any location where the OS sees an empty spot in its memory lists. The function returns a pointer to that chunk of memory or, if there isn't enough memory of the requested type available, returns -1. If your program doesn't check for this return code and there is not enough memory available, => crash.

AllocMem(), btw, is deprecated anyway, better use AllocVec(). You may also consider the "Pool" functions (AllocPooled() and friends).

Generally you will not use fixed addresses. As you already noticed, the Amiga is a computer with an operating system. More precisely it is a multitasking computer without memory protection which is why programs need to behave nicely to get along. In 1985 coders came to the Amiga from the C=64 and just didn't get this new stuff about not using fixed addresses. They killed the OS (that doesn't even protect itself) and just coded the way they always did on the C=64. It took some years until they finally understood that not all Amigas were created equal and that in fact the OS and hardware changed over time which caused their programs to fail badly.

Don't treat the Amiga as a games console. You will have to adapt your code to variable addresses. If you are really desperate, you could probably use self-modifying code to just overwrite all the fixed addresses you are using now with the addresses of what the OS gives you on your AllocVec() requests and write these addresses right into your fixed-address code. Personally I think this would be rather dirty and probably more work than learning the clean way and rewriting your code to use variable addressing. Furthermore, if you do some tricks like calculating hardcoded addresses (e.g. something like MOVE.l a0,d0; BSET #10,d0; MOVE.l d0,a0 to switch screenbuffer or whatever), this will never work well on an Amiga.

Just have a look at a few coding examples, it's quite simple and you have done infinitely more complicated stuff than this.



Gunnar von Boehn
(Apollo Team Member)
Posts 6207
02 Jan 2020 10:03


Nixus Minimax wrote:

If you are really desperate, you could probably use self-modifying code to just overwrite all the fixed addresses you are using now with the addresses of what the OS gives you on your AllocVec() requests and write these addresses right into your fixed-address code.

Arrg no! please not do this.

There is really no need to ORG a program to a fixed address.
Just let the Assembler create you binary.
The assembler can happily used absolute addressing - this is fine.
The AMIGA OS will do this "rewrite" of your executable when its first loaded into memory.
This means you can happily code using absolute addresses and they will be the correct addresses to the memory where the OS loaded you.

Really its easy this way.


Kyle Blake
(Needs Verification)
Posts 108/ 1
02 Jan 2020 12:33


Sounds like most of these questions can be summed up as: "i only program for fixed hardware specifications, on bare metal. please explain the concept of an operating system to me".

posts 429page  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22