Need help again, hehe, this time in asm

[GreatLor]

Ok, this is the problem, I've been digging alittle into the amiga with  asmOne during the last two days, now, the code runs fine when I assemble and run it, but when I write the object to disk and then run it from cli, the cli-window disappears leaving a blue screen, and the sound sound weird, I'm assuming that the copper-list is loaded into FAST-RAM, so what should I do ? I know I could insert some code to copy the copper-list into chip directly and start it, but I do believe there are other ways (including the OS), besides, it wouldnt be system-friendly (yes my code is supposed to exit nice and quiet), so whats the best way to solve this ?

Thank you very much in advance

[Piru]

Code: [Select]


        SECTION DATA_C,DATA_C
copper: dc.w ...
        dc.w $ffff,$fffe
        dc.w $ffff,$fffe

Or alternatively AllocMem MEMF_CHIP memory and build the copperlist into this memory.

[Cymric]

Without a single line of code to work with, my guess is as good as anybody else's. We don't know at all if the problem truly resides with a copper list being loaded into FastMem. To be more specific: I think that in fact it *is not* the source of the problem at all, as I can think of no particular reason why an assembler would wilfully assemble code into ChipMem if FastMem is available. Unless the assembler specifically asks for ChipMem to do so, but that would make it a lousy assembler in my book.

Under the assumption that FastMem is indeed the source of the problem, I don't even understand why manually reserving ChipMem and copying the copper lists into that area would be a Bad Thing. You would have to do some minor arithmetic in order to have the correct pointers inside the copper list---in other words, modify the copper list after it has been copied over---but that isn't so bad, is it?

Finally, you can insert some pseudo-opcodes into the assembly source to instruct the linker to emit some stuff so that later on the DOS loader automatically places that particular section of code or data into ChipMem. But that would still involve a bit of pointer arithmetic, and probably even more than before as you'd have to track down yourself where that segment ended up---not a fun thing to do.

Bottom line: without code, it all boils down to pure speculation.

[GreatLor]

I'll try to take the code with me tomorrow. (Do not think its anything fancy, its just the most primitive beginning of some (later) intro (? haha,  :pissed: ).

This kinking thing, what is it ? Does the assembler assemble my code and then put that together with a pre-assembled object file into one file or what ?

[Cymric]

Kinking? Oh, you mean linking! Err, what does a linker do... Well, what you say is not too far from the truth, although traditionally, assemblers are much less involved with linkers than higher languages such as C or C++. A linker's job is to glue together all kinds of separate source files or modules into a single executable file, often adding information in the process. Think of a list of symbols or names for debugging purposes, hints as to whether a section of that file contains data or code, and in what part of memory those sections should be stored. A very important task of the linker is to resolve all so-called cross references: references to variables and functions which are used, but not defined in a source code module. The assembler cannot compute the correct offset itself (it is defined in another file, after all), but the linker can. It keeps track of every location in each and every assembled file where such a reference is made, then computes all the correct offsets and addresses before writing them out to the final executable file.

You can do without a linker if you write all your code into a single file (although some extra information to make the assembled result into an executable would still have to be added) or if you use absolute addresses. The latter is useful in a few rare cases.

[GreatLor]

@Cymric, thanx for clarifiying, unfortunately I didnt have time to move the code to a pc-disk, however I'l give the vary base of the code.

I made an include file with the name "SaveLoadSys.i" (hey, dont laugh, I just used "Sys" because I didnt come up with anything better)

This is (I think) the source of "SaveLoadSys.i":

*CODE*

savesys:

move.l  4,a6
lea  dosname,a1
moveq  #0,d0
jsr  -552(a6)
move.l  d0,dosbase

move.l  dosbase,a0
move.l  -30(a0),oldcop  ;I think it was -30
move  $dff002,d0
bset  #9,d0
bset  #15,d0
move  d0,olddma

move.l  4,a6
move.l  dosbase,a1
jsr  -414(a6)
rts

loadsys:

move  olddma,$dff096
move.l  oldcop,$dff080
move.l  #1,$dff088
rts


oldcop:
dc.l  0

olddma:
dc.w  0

dosbase:
dc.l  0

dosname:
dc.b  'dos.library',0

I'm almost certain it misses some lines from the original code, anyway lets look at the main code (about 1/10 or so of the original):

bra  start
include "df0:asm/SaveLoadSys.i"

start:
bsr  savesys

move  #%0xxxxxxxxxxxxxxx,$dff096  ;I KNOW I set the RIGHT bits, but since I dont remember say, if blitter-dma was bit number 9 or 7 I just wrote "x" here !

move  #%1xxxxxxxxxxxxxxx,$dff096  ;same goes here !

move.l  #cop,$dff080
moveq  #1,$dff088

;also some code for noise, but I dont have energy to write'm down here now

waitmb:
btst  #10,$dff016
bne.s  waitmb

bsr  loadsys
rts

cop:
dc.w  .....,.....
dc.w  .....,.....
etc ...

*/CODE*

The point is that it full version works when assembled and ran run immediately but not as a separate object file, since everything works EXCEPT the copper (and sound) definition is executed (I can click the mouse button to exit the code and get back to cli) also when ran as a separate object file, I assume it's becouse the whole thing (including the copper) is loaded into fast-ram.

[Steady]

As far as I can see from your code, it does seem to be the problem you suspect.

You probably know, but to recap.

It's the classic problem:
Copper instructions need to be in CHIP RAM. If you have both CHIP and FAST ram in the the system and there is room in FAST RAM to load the program, it will be loaded there. Since you have not explicitly copied the copper list into CHIP RAM, it will not be able to be read by the copper. When you execute the program, the copper attempts to read instructions from a random area in CHIP, giving you garbage, sometimes even spectacular fireworks if you're lucky ;-)

As mentioned earlier, the other option is to flag the segment containing your COPPER list to be loaded into CHIP RAM. See your assembler/linker docs for details.

To prove if this is the problem, run NoFastMem and then see if the program works. If it does, that is your problem.

[GreatLor]

Yes, I will test the NoFastMem, thanx !

[Piru]

Some comments...

Code: [Select]


    move.l dosbase,a0
    move.l -30(a0),oldcop ;I think it was -30


That's wrong. DOSBase - 30 is ptr to jump to _LVOOpen routine, not old copper list. You only find JMP (abs).l instruction there on 2.x+ or 'moveq #x,d0 + bra.w' with 1.x.

This means the code is unable to restore system copper list at exit.

Code: [Select]


loadsys:

move olddma,$dff096


You need to disable all DMA before restoring:

Code: [Select]


loadsys:

move.w #$7fff,$dff096
move.w olddma,$dff096

Also, the code lacks disabling of interrupts (INTENA(R)) before peeking & poking DMACON(R).

In fact, you probably want to take a look at proper minimal startup code hwstartup.asm.

[GreatLor]

That's wrong. DOSBase - 30 is ptr to jump to _LVOOpen routine, not old copper list. You only find JMP (abs).l instruction there on 2.x+ or 'moveq #x,d0 + bra.w' with 1.x.

This means the code is unable to restore system copper list at exit.

Offcourse, for one little moment I forgot that negative offsets contain jump-instuctions to routines, it should offcourse be a positive number, whether its 30 or 3x I dont remember right now, but I have offcourse the correctr offset in the original code.

You need to disable all DMA before restoring:

Yes, yes, I said in a comment in that post that I'm sure I forgot some line(s), however, are you sure that the word #$7fff is correct ? when I used that value in a line in the "savesys" subroutine BEFORE setting new dma bits the system crashed when I ran the code, why did that happen ?

Also, the code lacks disabling of interrupts (INTENA(R)) before peeking & poking DMACON(R).

yes, but like I said, when I did disable them all the system crashed.
So this is the reason why the command-prompt/CLI out put the charachters of every key I pressed during the execution of the code, huh

By the way one thing I forgot in the code HERE, is the disabling of multitasking. (shouldnt the disabling of multi-tasking take care of the keyboard thing ?)

[GreatLor]

Ok, it worked when I disabled fast-ram with NoFastMem, I knew there were nothing wrong with my code itself, so now I have to write some lines to copy copper to chip ram, therefore I have another question: I know of two routines in exec.library namely, AllocMem and AllocAbs, however in the tutorial I have nowhere is mensioned if you use them (or another routine) to allocate CHIP ram, can I do that ? I KNOW I can use AllocAbs to allocate CHIP ram, but thats an absoulte address I request for and NOT a random one that the routine returns.

[Steady]

Use AllocMem with the MEMF_CHIP flag in the attributes like so:

        move.l   #CopListSize,d0
        move.l   #2,d1      ;$00000002 is MEMF_CHIP
        move.l   4,a6      ;A saved copy of ExecBase will be faster on 68020+, but this will do.
        jsr   -198(a6)        ;AllocMem()
        move.l   d0,MemPtr   ;Save the result from D0 locally.

Sorry if I have made a couple of 68k assembly errors above. I've not programmed it for quite a while, but it is the general gist of what you want...

Any corrections welcome.

[GreatLor]

move.l #2,d1 ;$00000002 is MEMF_CHIP

1. what are the other values ? 0 and 1 ? (for fast ram etc..)
2. what does the "F" in "MEMF_CHIP" stand for ? I know I ask too much, but I really need to know EVERYTHING that I do, thats the reason I like asm. (what I dislike is relatively advanced math in low level asm coding )

Thanx

[Noster]

Hi

> what does the "F" in "MEMF_CHIP" stand for ?

As usual at the Amiga, the "F" stands for "flag".
For several bitflags there are two defines, one with the number of the bit and a second with the bitvalue, e.g. in "dos.h" are the definitions for the fileattributes for example

#define FIBB_READ 3

This defines the bit number 3 as the one that has to be tested do determine is a file is readable. The according flag is:

#define FIBF_READ (1<

Unfortionally there are no MEMB_#? defines but nevertheless this follows this name-convention.

Noster

[GreatLor]

I didnt get anything of what you said now, but thanx I guess  :-D , I dont know, I just HATE macros, I prefere direct values/code, THEN I could make my own macros if I WANT.

Oh, hehe, it was really graphics.library and NOT dos.library I should have opened there  :lol: