English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 08 January 2020, 22:47   #1
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 107
CyberGraphx ASM-Only SingleFile CodeSample to OpenScreen

I have initially taken ChunkyStartup2 from Aminet, but it actually uses C to call the ASM methods, so it's of no use as I need my code base and build+deploy to be uncontaminated by the C compiler.



I'm currently doing this against WinUAE (Picasso IV Zorro III).

I have NDK 3.9, so it proved very problematic to get the ChunkyStartup2 ASM files to compile, as it depends on quarter-century old snapshot of libraries that I don't have, resulting in OS functionality not compiling somewhere 3 layers deep down the OS hierarchy.
And even if I had the snapshot of those include files, I don't think I'd be willing to spend another day or two attempting to fight it, so that particular path was closed off.


Surely, there is, somewhere, a code sample that can open the CyberGraphX screen (lock, draw single pixel, unlock), say, 320x256x8bit, in Assembler ? I just couldn't find it - all the tutorials use C.


Hell, even the CyberGraphX Dev kit only contains C samples. The only thing in assembler there is a single include file.


I found out DemoStartUp which, again, just like ChunkyStartup, needlessly (for me) does the full-blown AGA/CGX/DirectX12/Vulcan/XBOX check. It has 7 files (and I presume, as it's same age as first one, won't go well with NDK39), so it's a plan D, if plan B and C fail.


I have a lot of printing/debugging code for 68000 for Chunky mode (from different platform), but it's a catch 22 - can't use it, because I don't have the Chunky video mode running...


Plan C, which is going to be a very useless multi-day exercise, is to take the chunky AGA sample I have running, and try to understand the planar stuff, so I can create methods that draw debugging text for the Cybergraphx methods I would be trying to call on my own.


Which is why having a simple code sample that just opens the screen, would be great ! Thanks!
VladR is offline  
Old 09 January 2020, 05:05   #2
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 107
50 views & no bite ?

I gotta move fast so I guess I'll go produce some throwaway bitplane code that will print some text on screen, which will later allow me to debug the OS calls to CyberGraphX (BestCModeIDTagList, CModeRequestTagList, etc.).
VladR is offline  
Old 09 January 2020, 07:43   #3
amiwolf
Registered User

 
Join Date: Aug 2015
Location: Emerald City
Posts: 76
Would this be of any use for adaptation?

http://aminet.net/package/dev/misc/24BitChunky

It also requires this:

http://aminet.net/package/dev/asm/NewStartup39
amiwolf is offline  
Old 09 January 2020, 09:51   #4
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 107
Turns out it took only two hours to study the relevant section on Copper in Amiga HW Ref Manual and implement a 2-color, single plane screen drawing, which is completely sufficient for printing debugging info.

That was less time than it took me experimenting with adjusting the system libraries (in the first sample I mentioned above) that would refuse to get included (without compilation errors).

In another hour I got the 8/16/32 Hex Number print functionality working, so now I'm ready to print out debugging info from the OS functions (namely CyberGraphX library) and slowly get the CyberGraphX working.
VladR is offline  
Old 09 January 2020, 09:56   #5
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 107
Quote:
Originally Posted by amiwolf View Post
Would this be of any use for adaptation?

http://aminet.net/package/dev/misc/24BitChunky

It also requires this:

http://aminet.net/package/dev/asm/NewStartup39
Thanks. While I browsed through that lib last week, for some reason it wasn't saved in my local directory, so it's great you reminded me of it.


While on the surface it looks like it's less files, that's only because it depends on the NewStartup39, so I don't think I will even attempt compiling it. Especially not now that I got the basic printing functionality working an hour ago.





Between those three start-ups, there should be enough code for me to study how to work with OS libs from Asm.


I will most definitely have lots of ridiculously simple questions during next week, though
VladR is offline  
Old 09 January 2020, 10:55   #6
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 704
VladR: join the #apollo-team IRC on freenode. Flype1200 has everything you are asking for, e.g. simple chunky graphics code doing a plasma or fire effect.

Btw, the cybergraphx C examples not compiling sounds like a user error in your setup totally unrelated to "snapshots of old libraries" and the 3.9 NDK but I know it is of no use to you (I read your other threads) because I understand you just want to have your ASM running on this (new to you) 68k platform. If you are an experienced ASM coder, there really is no need to use any C on an Amiga.
grond is offline  
Old 09 January 2020, 22:44   #7
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 321
Quote:
Originally Posted by VladR View Post
I have initially taken ChunkyStartup2 from Aminet, but it actually uses C to call the ASM methods, so it's of no use as I need my code base and build+deploy to be uncontaminated by the C compiler.



I'm currently doing this against WinUAE (Picasso IV Zorro III). Which is why having a simple code sample that just opens the screen, would be great ! Thanks!
The best (and only) way to open a screen in an RTG graphics mode is to use the intuition function OpenScreenTagList() (really!). Hardware-banging with RTG-graphics is a pretty bad idea. Once that is done, to draw *directly* on an RTG screen, without using the Os, you *need* to lock the bitmap of the rastport of the screen. As for P96, the right function to call is p96LockBitMap() in the Picasso96API.library. On the CGfx side, it is LockBitMapTags() of the cgfx.library So, I'm not quite sure where to start. Do you know how to open libraries, open intuition, call intuition functions? No, there is no way around these steps with RTG graphics.
Thomas Richter is offline  
Old 10 January 2020, 10:12   #8
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,667
The problem with RTG is that it doesn't have the flexibility of original hardware. You can not just open your screen, grab the bitplanes address (that is permanently valid) and then do whatever you want with it.
Or if you can, I too want to see the code.
F.e. calling OpenScreenTagList is easy, finding exact parameters to give it is another story.
meynaf is offline  
Old 10 January 2020, 12:59   #9
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 107
Quote:
Originally Posted by grond View Post
VladR: join the #apollo-team IRC on freenode. Flype1200 has everything you are asking for, e.g. simple chunky graphics code doing a plasma or fire effect.
Weekend is coming up, so I should go and install some IRC client (the web interface on Apollo forum is crashing on me, but that's most likely because of my web browser).



Quote:
Originally Posted by grond View Post
Btw, the cybergraphx C examples not compiling sounds like a user error in your setup totally unrelated to "snapshots of old libraries" and the 3.9 NDK
Those CyberGraphX C examples I didn't even attempt to compile (I tried the ChunkyStartup.asm which barfed on me, somewhere 3 layers down deep the OS include chain), because it's C. And from my ~decade of experience with C compiler under Jaguar, I would rather suffer now, at the beginning for a week or two, than get bitten down the road. Which, using C alongside the ASM, is 100% guaranteed.


I spent a really long time checking ASM output of C functions. That time, was effectively, just burnt, which after about 6 months of such suffering, led to an Heureka moment - I really, totally, absolutely, without any hesitation, MUST commit to 100% Assembler. Which I did.









Quote:
Originally Posted by grond View Post
but I know it is of no use to you (I read your other threads) because I understand you just want to have your ASM running on this (new to you) 68k platform. If you are an experienced ASM coder, there really is no need to use any C on an Amiga.
Correct. I've got around 100,000 lines of 68000 ASM code from my experimenting on Jaguar which covers all kinds of 3D experiments at various stages of completion at various resolutions (mostly HiRes 640x240 at 65536 colors):
- Road Rash
- Outrun
- 4 KB Voxel terrain demo
- Radiosity lighting for FPS games - this should run really well with AMMX at 24-bit colors


Only about 15% of that is RISC code (DSP, GPU), the rest is 68000. Since 68080 is effectively a RISC from performance standpoint (almost ~all ops execute in 1 cycle), I can basically easily interpolate the performance of RISC-based rasterizer onto 080.




And, of course,there's the StunRunner-style game with RPG elements which I want to port to Vampire.
VladR is offline  
Old 10 January 2020, 13:10   #10
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 107
Quote:
Originally Posted by Thomas Richter View Post
The best (and only) way to open a screen in an RTG graphics mode is to use the intuition function OpenScreenTagList() (really!). Hardware-banging with RTG-graphics is a pretty bad idea.
Initially, I intend to support only two SKUs - Vampire V2 and V4, with art assets made explicitly for them.


If, and only if, they do well, I can go and start implementing renderers that would work on lower configs - like 060.
But, those will invariably require a completely different set of art assets, as the performance gap between V4 and a modest 060 at 50 MHz is quite severe.



Quote:
Originally Posted by Thomas Richter View Post
The best (and only) way to open a screen in an RTG graphics mode is to use the intuition function OpenScreenTagList() (really!). Hardware-banging with RTG-graphics is a pretty bad idea. Once that is done, to draw *directly* on an RTG screen, without using the Os, you *need* to lock the bitmap of the rastport of the screen. As for P96, the right function to call is p96LockBitMap() in the Picasso96API.library. On the CGfx side, it is LockBitMapTags() of the cgfx.library So, I'm not quite sure where to start. Do you know how to open libraries, open intuition, call intuition functions? No, there is no way around these steps with RTG graphics.
Well, about 10 minutes ago, I finally managed to write a code (without any macros that go 3 levels deep (like in all those samples I mentioned above) and refuse to compile on vasm) that opens:
dos.library
intuition.library
graphics.library
cybergraphics.library


Using the hex printing methods (for the single bitplane screen mode I got now) I wrote yesterday, I confirmed they return a working pointer (and stored it) to each library.


So, now I can go and see if I can actually make a working parameter list (screen dimensions, bit depth, etc.) for CyberGraphx (or Intuition - still confused why do I need Intuition if I'm using CyberGraphx - perhaps CyberGraphX still needs to go one layer down in the OS - which would be Inutition ?).
VladR is offline  
Old 10 January 2020, 13:13   #11
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 107
Quote:
Originally Posted by meynaf View Post
You can not just open your screen, grab the bitplanes address (that is permanently valid) and then do whatever you want with it.
Yeah, I think I read in one of the samples that the FrameBuffer pointer returned by OS is only valid for the duration of frame ? Seriously ?


Why would OS reshuffle it every frame ? Surely nobody runs 3 games in parallel at the same time and expect them to run at 120 fps each?


Quote:
Originally Posted by meynaf View Post
The problem with RTG is that it doesn't have the flexibility of original hardware.
That's not a problem for 3D gfx coding - Everything is SW-based. I really only need that stupid pointer for FrameBuffer from the OS (as, apparently, I can't just allocate it by myself otherwise it's allegedly OS-incompatible or something and I would have to kill OS, which I don't think I want users to have to reset the box after playing the game).
That's not to say, that original HW won't be used - for example, I use a 2D background for the skybox - so I presume, on Amiga, I would use the so-called Playfield technique of Copper - having two playfields - one for background (static) and the other for 3D scene (erased and redrawn each frame).

I am presuming here, that on a HW level, Copper would only take the FrameBuffer pointer that CyberGraphX gives me, so there would be no slow-down involved - but I'll confirm that with Apollo team (issue here is that the original HW, obviously, must run at original performance levels for compatibility).

Last edited by VladR; 10 January 2020 at 13:20. Reason: typos
VladR is offline  
Old 10 January 2020, 13:42   #12
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,667
Quote:
Originally Posted by VladR View Post
Yeah, I think I read in one of the samples that the FrameBuffer pointer returned by OS is only valid for the duration of frame ? Seriously ?

Why would OS reshuffle it every frame ? Surely nobody runs 3 games in parallel at the same time and expect them to run at 120 fps each?
RTG is made to handle cheap PC hardware put into a miggy. So it works like PC stuff (= in a stupid way).


Quote:
Originally Posted by VladR View Post
That's not a problem for 3D gfx coding - Everything is SW-based. I really only need that stupid pointer for FrameBuffer from the OS (as, apparently, I can't just allocate it by myself otherwise it's allegedly OS-incompatible or something and I would have to kill OS, which I don't think I want users to have to reset the box after playing the game).
That's not to say, that original HW won't be used - for example, I use a 2D background for the skybox - so I presume, on Amiga, I would use the so-called Playfield technique of Copper - having two playfields - one for background (static) and the other for 3D scene (erased and redrawn each frame).

I am presuming here, that on a HW level, Copper would only take the FrameBuffer pointer that CyberGraphX gives me, so there would be no slow-down involved - but I'll confirm that with Apollo team (issue here is that the original HW, obviously, must run at original performance levels for compatibility).
You can't use the Copper on a CGX screen.
Remember, all these boards which use RTG don't have a Copper.
meynaf is offline  
Old 10 January 2020, 14:14   #13
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 107
Quote:
Originally Posted by meynaf View Post
RTG is made to handle cheap PC hardware put into a miggy. So it works like PC stuff (= in a stupid way).



You can't use the Copper on a CGX screen.
Remember, all these boards which use RTG don't have a Copper.
Well, that sucks. I presumed there's no way to disable the legacy HW present in every Amiga?


Wait, so now the 2D background will have to be copied every single frame ? We can't have Copper show one bitmap and CGX another ? Awesome...

Guess I won't need to do ClearScreen then :- ))))))))



EDIT:

As an aside note, on Jaguar, the background bitmap was only handled internally, by the HW - by ObjectProcessor (kinda like Copper's playfields) - my OP List had 2+ bitmap pointers:
- Background (2D)
- Framebuffer (3D engine)

The bandwidth, required to process the background bitmap, was fully 64-bit, and required zero CPU time (no copying was involved).

Then the Gap between Jaguar and Apollo just got smaller. At 640x256x16bpp, that's a lot of CPU bandwidth (640*256*2*60 = ~19 MB/s) that just - poof - evaporated. And the CPU will be locked during all that time, leaving even less CPU time for the rendering...

Wait, I just realize that it's actually double the bandwidth then. It's a copy - so I gotta read those ~19 MB/s and then write same 19 MB/s. Not a good idea then, to have a full-screen background...

Last edited by VladR; 10 January 2020 at 14:22.
VladR is offline  
Old 10 January 2020, 14:27   #14
sparhawk
Registered User

sparhawk's Avatar
 
Join Date: Sep 2019
Location: Essen/Germany
Age: 51
Posts: 248
Quote:
Originally Posted by VladR View Post
Why would OS reshuffle it every frame ? Surely nobody runs 3 games in parallel at the same time and expect them to run at 120 fps each?

Wasn't the idea of RTG to allow graphiccard replacements, just like on the PC? In that case it would make sense, as new cards may have different requirements, and thus should be used through a stable interface.
sparhawk is offline  
Old 10 January 2020, 14:27   #15
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 107
Quote:
Originally Posted by meynaf View Post
calling OpenScreenTagList is easy, finding exact parameters to give it is another story.
Correct
I'm getting 0 back from the lib when asking for 320x240x8 (Min).


But, looking at the library docs, it appears there's a function IsCyberModeID, so I'm gonna shuffle it all values from 0-65535 and see if it returns some valid IDs that I could then stuff into another fn.


For all I know, my WinUAE Zorro IV config could be wrong...
VladR is offline  
Old 10 January 2020, 14:32   #16
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 107
Quote:
Originally Posted by sparhawk View Post
Wasn't the idea of RTG to allow graphiccard replacements, just like on the PC? In that case it would make sense, as new cards may have different requirements, and thus should be used through a stable interface.
But you can't replace the gfx card for another while the PC is running. Can you swap 3DFX for another card on Amiga at run-time without powering the whole Amiga down ? Like, a hot swap (say, like on a server) ?


Meaning, the moment the OS gives you pointer, I don't understand why it's valid only for the duration of frame.


That is not a PC behavior at all. I worked with SW rasterizing during transition to OpenGL and DirectX long time ago and this is the first time I hear of a framebuffer pointer valid only for the duration of frame.


Perhaps there was some obscure gfx HW on PC that behaved the same way ?
VladR is offline  
Old 10 January 2020, 14:47   #17
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,667
Quote:
Originally Posted by VladR View Post
That is not a PC behavior at all. I worked with SW rasterizing during transition to OpenGL and DirectX long time ago and this is the first time I hear of a framebuffer pointer valid only for the duration of frame.
This is because the PC never actually gives you access to the real front buffer.
meynaf is offline  
Old 10 January 2020, 14:48   #18
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 107
So, just made a loop ($FFFFFFFF times) calling IsCyberModeID () and not a single ID found was good.

That would imply that even though the library itself opened fine, there's some other issue - perhaps some additional dependency ? Highly likely my Zorro IV config in WinUAE...


I'll see if I can rustle up some CyberGraphX tool that would show, from the commandline, list of all valid modes.
VladR is offline  
Old 10 January 2020, 15:52   #19
VladR
Registered User

 
Join Date: Dec 2019
Location: North Dakota
Posts: 107
I figured I would manually reinstall the drivers (to confirm/rule out the dev HD File I got does indeed have them), but can only find the updates requiring CyberGraphX V4 CD and first two pages on google didn't produce a viable download.

Anyone got a working link ?
VladR is offline  
Old 10 January 2020, 16:03   #20
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 704
Quote:
Originally Posted by VladR View Post
Meaning, the moment the OS gives you pointer, I don't understand why it's valid only for the duration of frame.
You keep forgetting that the Amiga is not a games console but a personal computer, more specifically a multitasking computer. This means that you may want to run many productivity programs at the same time. All of these will have some graphics output. Now PC graphics cards have some framebuffer and are a totally different concept to the original Amiga hardware that could just DMA from anywhere in the computer RAM (let's forget about chipmem vs. fastmem for a moment). This means that cybergraphx and P96 had to invent some additional layer of memory management. You may write directly into your screen (when it's in the graphic card's local memory) but must not assume that your screen will be in the graphic card's local memory when it is not being displayed (e.g. when iconified, not visible etc.) because then your screen data may have been shuffled out of the graphic card's memory again. You would then write into somebody else's screen that happens to be visible at that time.

Now with the Vampire all memory is graphics memory and you are not tied to that limitation. You buffer will be in the same physical location regardless of whether it will be displayed or not.
grond is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
CyberGraphX V4 B2k_ad support.Apps 2 01 October 2018 21:57
Prevent intuition/OpenScreen from clearing custom bitmap? dalton Coders. System 8 12 September 2015 23:59
Tool to convert asm to gnu asm (gas) Asman Coders. Asm / Hardware 6 12 October 2013 13:45
Looking for CybergraphX 4.2 Smiley support.Apps 1 25 June 2006 23:44
CybergraphX dido support.Hardware 9 10 January 2006 11:22

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 00:42.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.14409 seconds with 13 queries