Devpac 3 - Where to start?

[WireLord55]

Hi,

Me again, being a newbie. How do i understand Devpac commands?

Such as:

Code: Select all

move.l

and

Code: Select all

move.w

also the numbers on the ends

Code: Select all

#1

and the statements

Code: Select all

d0

I've read a lot on Devpac but i still don't understand what does what with the code.
And that frustrates me to no end!

Can anyone help please?

WireLord55

[FedePede04]

"Move" is a command that move a value from one place to an other
it can be a Datareg, addressreg or a value or from an memory locations.

move.l is move longword, its a 32bit data / address
move.w is move word its move a 16bit data / address
move.b is move byte its move a 8Bit data / address

D0 to D7 is the data registers
A0 to A7 is the Address Register where A7 is reserved to the Stack pointer ( SR ) sor if you write A7 or SP is the same.

the # before a number mean that its a value if there are no # means you take the value from that address.
example

Code: Select all


move.w   #10,d0    load d0 with 10 now d0 contain 10.
move.w   10,d0   take the value that is in address 10
one thing you have to be aware about, you can't read/write a word/long word to and odd address it is only move.b you can use here.



[wietze]

Where to start is a broad question; and I do not have a single answer for you there.

But please consider the following:
- To help understand the various m68k operation and their operands: http://frummel.org/~weedz/atari/docs/Summary%2068000%20Instruction%20Set.pdf
- To find a general tutorial as to how to put them into a running program:
https://nguillaumin.github.io/perihelion-m68k-tutorials/
- For further information regarding GEMDOS
http://frummel.org/~weedz/atari/docs/The_Atari_Compendium.pdf

[thomas3]

Evaluate the following function...

WireLord55 = MrPixel

??!

[FedePede04]

Evaluate the following function...

WireLord55 = MrPixel

??!

don't get it, why do you think that?

[thomas3]

These kinds of requests for help just ring a few bells for me... Of course, if I'm mistaken, I apologise to the OP .

(Although, in saying that, if this person is earnestly asking the questions above, then they're probably best to start with a high level language rather than ASM. No offence intended, of course).

[FedePede04]

the problem with MrPixel was he asked about a lot of different systems, what people here don't know much about, so if it is MrPixel, then he is a least now talk about the ST.

but i also have to give you, he have a very long way to go, if he don't know the answer to the about questions, but again we all have to start at one point.

and as long he ask questions about the ST and i can answer, then i can't see any problem helping him out...

[WireLord55]

Yeah...thomas3 your right. I don't know, well anything about ASM.

Thanks for your help everyone!

By the way, I just discovered GFA-BASIC (ahh, sigh or Huh), much easier to understand! Also if you can write in ASM i think you're god! lol (me not understanding may also have to do with my age, 17)

WireLord55

[WireLord55]

None taken thomas

[SteveBagley]

There's a series of articles in ST Format (issues 21 to around issue 28 iirc) on how to write ST games in 68000 machine code with Devpac. That's probably a good place to start (its where I did).

Steve

[Foxie]

Do you have any experience with C? Most things in C have a direct equivalent in assembly language. BASIC is also helpful to know to understand program flow, but it won't teach much about memory addresses.

[spiny]

Hi,

Me again, being a newbie. How do i understand Devpac commands?


Can anyone help please?

WireLord55

What you need to understand about assembler/devpac is that it's all about moving memory values around (to the hardcore coders, I know this is not quite true ) rather than a set of commands that do stuff to the display.

So there isn't a command to show a picture for example, you need to write that yourself

so your prg needs to have the pic INCLUDEd in it as data somewhere, then you read that data and move it to the memory space where the screen lives, then locate the colour palette, and move that to where the screen palette lives, and then you have a pic on screen. In theory at least.

I see you've found GFA, that will almost certainly be more useful to get to grips with, it'll be easier to knock something up that actually runs, without the leg work you need for assembler to initialise the system first and quit properly after and all the other setup that isn't obvious if you just want some text to show on screen.