Overview Features Instructions Performance Forum Downloads Products OrderV4 Reseller Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
VISIT APOLLO IRC CHANNEL



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 

Vladimir Repcak

Posts 203
12 Jan 2020 02:27


Vladimir Repcak wrote:

  Yesterday I found a super-short (less than 50 lines) ASM example code that starts the bitplane screen and draws some lines.
 
  I have a script that compiles and deploys it to WinUAE and it's running there with the changes I make, so I finally have a baseline here.
 
  Just started transferring the chunky ASM code from that previous C/Asm sample. Hopefully, will have that today...
Well, I was being overly optimistic about getting the chunky ASM Sample from AmiNet to get working in one day. That was 5 days ago :)
There were multiple issues:
- the snapshot of OS libraries is ~2 decades old
- I am using recent NDK 3.9
- files are in different directories in 3.9 than the sample asks for
- there's certainly many other differences
- took few days to get at least majority of stuff to compile
- eventually, it gets stuck on one OS include that simply barfs 3 layers deep down the OS chain

So, those code sample are not useable other than for inspiration to see how it's supposed to work.

Initially I hoped to at least use the OS macros, but they're dependent on stuff I don't have, so can't even compile those.

I worked around that by using the OS calling code from the Amiga HW Reference manual - no macros - just straight calling and that works.

So, I realized if I want to troubleshoot chunky gfx mode, I need some way of printing out values, unless I want to have a debugging set-up (possible, but not desireable currently).

Thus, I spent 2 hours learning the Amiga's bitplane mode, and same evening had functionality to print 8/16/32 bit return values in hexa.

Which is how I got the base OS calls working:
- graphics.library
- intuition.library
- dos.library
- cybergraphics.library

The one thing that didn't work was opening a 320x200 gfx mode.
So, in documentation, I found a method IsCyberModeID () and I stuffed all possible values to it (full 32 bit range) but it didn't find any valid Mode ID.

Which leads to me these assumptions:
1. Order of opening OS libraries is wrong
2. I have issues with the WinUAE RTG board config
3. CGX Drivers on the Dev Hardfile - I can open CGX, so I believe I have the CGX drivers installed, but maybe something needs to be enabled in the OS itself ?

I got a different code sample from flype on IRC, but his code also can't open a valid mode, so it looks like option 1 has been ruled out.

Leaving me with driver troubleshooting (option 2 and 3). I'll be hanging out on IRC for couple hours before I go to sleep and hopefully somebody volunteers in telling me where to click in the Workbench to figure it out.

I'll be definitely randomly clicking left and right like in those funny cats GIFs :)

Also, I found that cyberver command is supposed to tell me the version, but when I execute it from command line, OS can't find it - so it's probably buried somewhere in the filesystem and I gotta find it manually...



Vladimir Repcak

Posts 203
12 Jan 2020 02:40


Never underestimate those funny cats GIFs :)

Especially the one with the caption : "I have no idea what I'm doing" :- ))))))))))

Randomly clicking on the Workbench produced an OpusDir app that appears to be file commander in the style of Norton Commander.

So, I can now browse the full filesystem of OS. Looking at libraries directory, I can see all kinds of .libraries but not the CGX lib.

So, even though I can successfully open the Cybergraphics.library via OS call, it doesn't appear to be fully installed.

I downloaded a German PDF on installing ZORRO card, and while my German isn't what it used to be, I should be able to at least make out installation directories :)


Vladimir Repcak

Posts 203
12 Jan 2020 05:43


Gunnar has helped me configure the UAE to actually use RTG, so now I have a higher resolution and now the library calls should be able to succeed, which is hard to debug as apparently that means losing the bitplane screen, so now I can't see the debug output I had (I would need another video out from UAE).
 
  So, up until now the CGX stuff could not have worked as my OS wasn't in RTG mode.
 
  Now every single code sample I have (including flype's) uses files like:
  graphics_lib.i
  intuition_lib.i
 
  which aren't in NDK 3.9.
 
  So, perhaps I can't really do anything using that SDK, unless I have the knowledge of previous ones, and thus would be able to track the changes and apply them.
 
  Example - I must call _LVOOpenScreenTagList but it's nowhere to be found in include files. Perhaps it was deprecated ?
 
 
  So, if I'm not using the latest one, I might as well use the OLDEST one.
 
  Anyone has a link for the OLDEST possible SDK ? Like, 1995 to be safe ? That's the age of those code samples so that's what I should be using.

The oldest I am finding is 2009 : EXTERNAL LINK 


Stefano Briccolani

Posts 404
12 Jan 2020 07:22


Maybe you're searching for this one
EXTERNAL LINK


Javier R. Santurde

Posts 16
12 Jan 2020 08:52


I remember that I had a problem with the 3.9 ndk disk. It didn't include the asm LVO file.

Look at here:

EXTERNAL LINK 


Kamelito Loveless

Posts 76
12 Jan 2020 08:54


if you have an error on the *_lib.i files download the one in the Aminet’archive below and copy them on your include directory EXTERNAL LINK  Include dir containing them should be libraries inside include_i

Kamelito


Vladimir Repcak

Posts 203
13 Jan 2020 07:56


Javier R. Santurde wrote:

I remember that I had a problem with the 3.9 ndk disk. It didn't include the asm LVO file.
 
  Look at here:
 
  EXTERNAL LINK 

YES ! This was it !!!

Now I could compile the necessary OS calls for opening the screen&window !

Thank you !!!

I still got bitten by the fact that I had the original bitplane Copper code at the start-up, but as soon as I properly removed all the bitplane code (that I originally used for debugging), I managed to successfully open the bloody window and can finally draw into the chunky buffer :)

Of the dozen+ HW platforms I coded for, displaying my first chunky pixel (I don't count the bitplane code I had running 3 days ago) on Amiga has somehow managed to take more effort (~10 days) than on the current top place occupied by Sega Saturn, which involved compiling its special version of gcc under completely silently internally-crashing msys32 (discovering that "feature" of msys was quite fun!) with special SH-2 compilers, which took 3 days each to configure to correctly compile under msys (in total 7-9 days).

Now I can start porting my codebase from Jaguar.  Finally :)


Gerardo González-Trejo

Posts 36
13 Jan 2020 08:27


Congratulations! I think your posts are much more interesting now once focused :)
 
  Regarding dev tools you are right... Installing and configuring an Amiga development environment, working and compiling correctly, is not as easy as expected.
 
  I hope, now that AROS is the official OS for Vampire, things will be better soon with dev tools too.


Michael Borrmann

Posts 124
13 Jan 2020 09:38


May I ask why you go the complicated and unusual route of doing this so super OS friendly, with windows etc?
 
  On the Amiga, you usually just shut off the system, set a few bitplane pointers and modulos in a copperlist and are ready to just write stuff into those bitplane buffers (either by CPU or Blitter).
 
  Edit: okay, I have now read the discussion about this over the last few pages. :D
  You can shut off some system stuff by disabling interrupts with INTENA and do a "forbid()". There are some routines you can find online, that take less than 15 lines of code.
 
  And you will still be able to use Dos.Library and return to the CLI/Shell after finishing the game.
 
edit2: I'd also go the "Vampire" only route, and target the V2s, since you will have the largest base of people there.
 


Vladimir Repcak

Posts 203
13 Jan 2020 10:22


Gerardo González-Trejo wrote:

Congratulations! I think your posts are much more interesting now once focused :)
 
  Regarding dev tools you are right... Installing and configuring an Amiga development environment, working and compiling correctly, is not as easy as expected.
 
  I hope, now that AROS is the official OS for Vampire, things will be better soon with dev tools too.

Thanks :)

To be fair, the stuff would probably compile directly inside the emulator (or on actual Amiga). My main problem was:
- doing the cross compilation on Windows (finding latest Windows build of vasm took 2 days of random reading forums and accidentally stumbling upon one such thread at EAB, though later somebody posted a link here too)
- NOT using C, but insisting on Asm, as even the CGX dev code samples are in C - literally 98% of all code I found was in C

As I am going to introduce my own High-level language compiler into the mix (the Higgs), compiling straight on Windows is necessary.

What really shocked me, however, is the amount of C language and samples. WTF !

I really expected the ratio to be the other way around - e.g. 2% C and 98% ASM, given the ~7 MHz core speed of A500. Nope, that's not what it turned out to be :)


Vladimir Repcak

Posts 203
13 Jan 2020 10:35


Michael Borrmann wrote:

May I ask why you go the complicated and unusual route of doing this so super OS friendly, with windows etc?
   
    On the Amiga, you usually just shut off the system, set a few bitplane pointers and modulos in a copperlist and are ready to just write stuff into those bitplane buffers (either by CPU or Blitter).
   
  Edit: okay, I have now read the discussion about this over the last few pages. :D
  You can shut off some system stuff by disabling interrupts with INTENA and do a "forbid()". There are some routines you can find online, that take less than 15 lines of code.
 
  And you will still be able to use Dos.Library and return to the CLI/Shell after finishing the game.
 
  edit2: I'd also go the "Vampire" only route, and target the V2s, since you will have the largest base of people there.
 

Well, because I am starting from scratch, I'm trying to approach it the way that will ensure largest possible user base, given the plethora of various OS.

I definitely wouldn't call it "super OS-friendly", not yet for sure. Maybe I'll get there, if I can recover from OS launching another game and my game surviving losing the FrameBuffer pointer.

But, just to give you an idea what was going on, this is summary of OS calls to start the chunky mode:
Initialization:
Open graphics.library
Open CyberGraphX.library
Open Intuition.library
Open Dos.library
CyberGraphX._LVOCModeRequestTagList (requesterTags)
Intuition._LVOOpenScreenTagList (screenTags)
Intuition._LVOOpenWindowTagList (windowTags)

rendering:
CyberGraphX._LVOWritePixelArray (ptrFrameBuffer)

exiting:
Intuition._LVOCloseWindow ()
Intuition._LVOCloseScreen ()

Of course, just having NDK 3.9 was not enough - either missing files or after some rearranging it barfed 3 layers deep down in OS includes.

I should clean my code up and upload it somewhere so that in future this doesn't prevent people from trying to play with Amiga's code.


Gunnar von Boehn
(Apollo Team Member)
Posts 4450
13 Jan 2020 10:46


Vladimir Repcak wrote:

    CyberGraphX._LVOWritePixelArray (ptrFrameBuffer)
 

 
Yes, this can be done.
And is OK as start and also for test.
For a fast FPS game there are better options.
 
With WritePixelArray you will copy the whole screen each frame this way. This will cost you many FPS.  Much faster is setting the Pointer instead copy the content.  We can discuss this on IRC. :-)


Kyle Blake
(Needs Verification)
Posts 108/ 1
13 Jan 2020 11:38


Vladimir Repcak wrote:

 
    - NOT using C, but insisting on Asm, as even the CGX dev code samples are in C - literally 98% of all code I found was in C
   
    What really shocked me, however, is the amount of C language and samples. WTF !
   
    I really expected the ratio to be the other way around - e.g. 2% C and 98% ASM, given the ~7 MHz core speed of A500. Nope, that's not what it turned out to be :)
 

 
  Nobody is using cybergraphics on an A500.
 
  Insistance on C on amiga in general is because the Amiga is a real computer platform, with a real OS. That the cheapest model has 7Mhz isn't interesting because the next ones are 16, 25, 40Mhz, have different memory layouts, different hardware capabilities etc. C fits the real computer mindset better. ASM code practices does not scale or adapt.


Grzegorz Wójcik (pisklak
(Apollo Team Member)
Posts 76
13 Jan 2020 12:15


Intuition._LVOOpenWindowTagList (windowTags)
     
      Well.... I suggest you to work on screen not window. This way you can simply direct draw on screen just by writing data in FB addr, so I guess in the same way you do this on Jaguar.
  You can find addr of your opened screen FB by reading data from screen struct which returns OpenScreen function.
  direct_FB_addr=scr.rastport.bitmap.planes  which in ASM will look like
move.l sc_RastPort+rp_BitMap+bm_Planes(A1),fbaddr (when in A1 you have addr returned by OpenScreen).
 
  But pls have in mind that I am myself begginer Amiga coder which not coding for too long so I might be wrong. In this case I am sure someone will correct this "help".


Nixus Minimax

Posts 405
13 Jan 2020 13:59


Grzegorz Wójcik (pisklak wrote:

Intuition._LVOOpenWindowTagList (windowTags)
     
      Well.... I suggest you to work on screen not window.

Pisklak, the standard way to get user input is by openening a borderless window on your screen and reading its message port. For a game lowlevel.library provides an alternative, though, where you don't need a window to get input. And, of course, there has always been the old direct-hardware approach, no need to bring that one up again. My point is that opening a window is one valid approach.



Vladimir Repcak

Posts 203
13 Jan 2020 19:50


Gunnar von Boehn wrote:

Vladimir Repcak wrote:

    CyberGraphX._LVOWritePixelArray (ptrFrameBuffer)
   

   
  Yes, this can be done.
  And is OK as start and also for test.
  For a fast FPS game there are better options.
 
  With WritePixelArray you will copy the whole screen each frame this way. This will cost you many FPS.  Much faster is setting the Pointer instead copy the content.  We can discuss this on IRC. :-)

Yes, it's going to cost some bandwidth - 320x240x2 = 150 KB per each frame, which at 60 fps makes ~9 MB/s.
More importantly, it's probably going to be a significant chunk of available frame time at 60 fps. Especially compared to Jaguar where I was always doing clearing in parallel via Blitter (and never had to copy the framebuffer, as there is no OS).

But, this is just first working prototype and a great learning experience.

Looking at the code from flype (his fire demo) and from a very quick look it seems he is also doing CALLCGX  LockBitMapTagList / UnLockBitMap and obtaining the pointer that way (not sure about other dependencies as yet), so that's what I shall try next.

There's also about 4 other OS calls for Audio, Keyboard, Timer, LowLevel library - which highly likely aren't related at all.


Vladimir Repcak

Posts 203
13 Jan 2020 20:02


Kyle Blake wrote:

   
    Nobody is using cybergraphics on an A500.
   
    Insistance on C on amiga in general is because the Amiga is a real computer platform, with a real OS. That the cheapest model has 7Mhz isn't interesting because the next ones are 16, 25, 40Mhz, have different memory layouts, different hardware capabilities etc. C fits the real computer mindset better. ASM code practices does not scale or adapt.
I don't know if 40 MHz really matters in C compared to 7. It's probably only about a factor of 10x (A500 vs 040).

From my experience on Jaguar, the resulting code is atrocious at best. I spent a lot of time comparing ASM output after every compilation.
Now, it is possible, once you understand how each command gets translated, to write a "relatively" fast code, avoiding constructs that translate to 2 screens of instructions.

Perhaps gcc is better in this regard ? Never tried gcc on jag.

That being said, C is great for:
- apps / utilities
- adventures, turn-based strategies, board games, logical games, ISO-metric RPGs, top-down 2D RPGs, all screen-based games

Even 2D action platformers can be done well (assuming HW register usage and doing all sprite heavy lifting via Amiga's chips).

But, high-performance racing/shooter genre is not a good match.

Besides, I've already done the grunt work on Jaguar - so for me, it now scales really well - but I understand the idea of writing and debugging 100,000+ lines of ASM code is indeed daunting (in year 2020). You just gotta be the right kind of crazy : )))))



Vladimir Repcak

Posts 203
13 Jan 2020 20:09


Grzegorz Wójcik (pisklak wrote:

Intuition._LVOOpenWindowTagList (windowTags)
     
      Well.... I suggest you to work on screen not window. This way you can simply direct draw on screen just by writing data in FB addr, so I guess in the same way you do this on Jaguar.
  You can find addr of your opened screen FB by reading data from screen struct which returns OpenScreen function.
  direct_FB_addr=scr.rastport.bitmap.planes  which in ASM will look like
  move.l sc_RastPort+rp_BitMap+bm_Planes(A1),fbaddr (when in A1 you have addr returned by OpenScreen).
I just checked and this looks basically indentical to what flype is doing in his Fire demo.

Grzegorz Wójcik (pisklak wrote:
 
  But pls have in mind that I am myself begginer Amiga coder which not coding for too long so I might be wrong. In this case I am sure someone will correct this "help".
Please, you have no idea how I appreciate these technical discussions - not having to figure out the path through the OS minefield just by myself. Even if I don't respond to every single post, I truly appreciate everybody taking their time and sharing their experience.



Vladimir Repcak

Posts 203
13 Jan 2020 20:10


Nixus Minimax wrote:

Grzegorz Wójcik (pisklak wrote:

  Intuition._LVOOpenWindowTagList (windowTags)
       
        Well.... I suggest you to work on screen not window.
 

 
  Pisklak, the standard way to get user input is by openening a borderless window on your screen and reading its message port. For a game lowlevel.library provides an alternative, though, where you don't need a window to get input. And, of course, there has always been the old direct-hardware approach, no need to bring that one up again. My point is that opening a window is one valid approach.
 

Very interesting - so many ways to do the same thing. I was already starting wondering about the input, so I guess I can check the OS docs on input from the window.


Gunnar von Boehn
(Apollo Team Member)
Posts 4450
14 Jan 2020 10:40


Vladimir Repcak wrote:

Yes, it's going to cost some bandwidth - 320x240x2 = 150 KB per each frame, which at 60 fps makes ~9 MB/s.

 
9MB read + 9 MB write = 18MB time
Also on higher res 640x360 = this becomes 55 MB/sec
This is a lot time for nothing.
 
The bigger problem of the copy is = it looks like shit.
As you copy to the screen - which is displayed!
This means you see the copy/redraw.
This looks bad.
 
A much cleaner solution is having 2 buffers
and rendering the 2nd while the 1st is displayed and then swapping the PTR. This PTR swap is free and looks a lot better.
You only need to sync the SWAP time.

The very best solution is having 3 Buffers.
1st is Displayed, 2nd is rendered, and 3rd is also rendered.
Using 3 Buffers you can unsync
the render loop from the display time.
This means if your render routine does not need to wait for the display.

For the final product I can highly recommend you to use Tripple Buffer and to only do PTR update.
 
On Vampire/SAGA the PTR SWAP is auto-synced with screen display.
This means all you need to do is 1 MOVE.L and the HW does the rest for you.


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