flat assembler
Message board for the users of flat assembler.

Index > Main > Amiga -> Windows

Author
Thread Post new topic Reply to topic
M68kael



Joined: 15 Jul 2015
Posts: 5
M68kael
Finally, my Amiga has gone to meet it's maker and i have bought a PC.

Can someone please help me get starting with Asm (demo coding)
by answering some questions

1. How do I sync animations with the rasterbeam or something else?
(Amiga = IRQ #nn)

2. Amiga:
move 4,a6
jsr -nnn(a6)

Windows:
int $nn

But that is too old or?

4. I have dualboot Win7 & Linux, is it possible wrte code that is
independant of the underlying Operating.
Afterall it's the same CPU.

5. Programs that converts gfx to raw-data?

5. Suggested reading.


/Mike
Gone but not forgotten - Amiga Cool

_________________
/Mike
Post 15 Jul 2015, 09:03
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
M68kael

1. Forget about IRQ's. Forget about hardware related things. What you'd need to synchronize with are window messages. WM_PAINT for graphical output.

2. int $2e still works in Win7, but it's an undocumented interface that you don't wanna deal with. The correct documented alternative are Win32 API calls to functions inside of system dlls.

3. It's impossible to make all the code OS independent. But it's always possible to create an OS abstraction layer, and the rest would be OS independent. There's significant effort in that respect, but I'd better restrain from recommending anything: you'd better start without this idea and then make your own reasonable decision as soon as your knowledge of both systems is advanced enough for that.

4. No idea what you're talking about.

5. This. But it's for masm, so your reading should be tightly interleaved with reading this and this. So I acutally think, this little problem is a good opportunity to gain some deeper understanding while translating the gained knowledge into fasm.

Additionally it's important to learn to use a debugger in parallel. There's an excellent tutorial, but it's in Spanish, and I haven't seen an adequate English translation (though there's a good one in Russian).

_________________
Faith is a superposition of knowledge and fallacy
Post 15 Jul 2015, 17:21
View user's profile Send private message Reply with quote
M68kael



Joined: 15 Jul 2015
Posts: 5
M68kael
l_inc wrote:
M68kael

4. No idea what you're talking about.


Thank you very much, just what i needed.

About #4 i mean this:

Code:
section .data
txt:     db 'Works on Linux Only!',10 
txtLen:  equ $-txt  

section .text
        global _start
_start:
        mov eax,4            
        mov ebx,1            
        mov ecx,txt        
        mov edx,txtLen                       
        int 80h              
        mov eax,1            
        mov ebx,0            
        int 80h
    

_________________
/Mike
Post 15 Jul 2015, 22:44
View user's profile Send private message Reply with quote
PeExecutable



Joined: 26 Jun 2015
Posts: 181
PeExecutable
On the Amiga you were probably a lot into pixel manipulation. On a modern PC, pixel manipulation is a lot "blockier" to make it work. You either have to use the stencil buffer to make that work or write a shader. Things have become a lot "blockier" than it used to be in the older days. You can also use point sprites.

I think Amiga demo programming was all about showing the world what you could do, graphics-wise (What was never possible before). The world already knows what we can do graphically, so I don't think demo programming has a place in the world anymore. You should focus on creating useful graphics, a game or a program, not so much demo anymore.

If you could rotate a rectangle on the Amiga, the world was amazed at that, 30 years ago. But today, there is no such thing anymore, a rectangle is nothing anymore. If you're lucky, people will be amazed by the most graphics intensive 3d game out there.

You could do some amazing things in GDI or GDI+ with direct pixel manipulation, it's not actually slow, it's quite fast if you use dib sections, it works for fast pixel manipulation, but it doesn't work for synchronizing and getting smooth frames because it works on the CPU and the CPU is busy at an interval you can't predict, so you get uneven frame rates, which is unacceptable for anything but pixel manipulation.
Post 15 Jul 2015, 23:47
View user's profile Send private message Reply with quote
M68kael



Joined: 15 Jul 2015
Posts: 5
M68kael
You'r right about the demo part, my intensions now days is the nitty gritty of things not the speed.
tempus fugit Wink

Thank you for the info.
Post 16 Jul 2015, 03:46
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.