Danish Amiga Assembly Programming Course

[prowler]

Thanks for a mighty effort, Herpes! That's a fantastic job!



I guess this really ought to be uploaded to the EAB File Server too!

[AlfaRomeo]

Originally Posted by Herpes

Hi guys!
I used google translation and I really got mad about the results.

Once I tried to translate a Danish course too but when finished the job find more meaning in the phrases found in a alphabet soup

Anyway, great job Herpes and thanks for your effort

[Jherek Carnelia]

Well done. That's an excellent bit of work!

[BippyM]

Nice work man

Thank you from the whole of EAB and those wanting to learn ASM

[Herpes]

Thanks guys!

[Photon]

Some selected babelfish quotes in the coding humor thread maybe hmm?

[Nostalgeek]

Wooooooow, just discovered this thread by chance, what a perfect timing!

Herpes, thank you so much for this awesome job. I'm diving into it right now!

Bippy, this should be linked on top of your ASM Resources thread I think! This is probably the best and most complete source I've seen so far. What do you think?

[Lonewolf10]

I just started and finished part 1. That small program (part 1, page 16) is very neat. I did fiddle around with it and have a rough idea of how it works, but I haven't looked up the register values which were set beforehand (I am assuming they just switched off unecessary stuff), though I know which registers they are for (INTENA and DMACON).

Anyone else doing this course and wish to share their experimentations? For example, for the program in part 1, page 16 change line 4 to any of the following:

move.b $DFF006,$DFF180
move.l $DFF006,$DFF180
move.w #DFF006,$DFF180


Regards,
Lonewolf10

[Nostalgeek]

Hey Lonewolf,

I had to quit the course for a while and was planning to get back to it this week but a pretty nasty virus kept me in bed for a full week...I will get back to it in the upcoming days for sure, maybe even today, and I'd be more than pleased to share thoughts and stuff with you

Cheers!

Nic

[Lonewolf10]

That's a pity. I'm having problems with the 2nd example (part 2,page 16). The copperlist looks fine (it's a bunch of wait's and color00 changes), but nothing is displayed other than a grey background. I tried changing the copperlist so that it used colours 0 to 4 (trying to find which one workbench used as grey), with no success.
It only uses the DMACON and COP1LCH registers. DMACON has all the DMA disabled, then COP1LCH is set with address of the copperlist, and then copper DMA is set using DMACON ($8080). Can anyone point out what I am missing?

*Just worked it out... forgot to disable FAST ram, so the copperlist (and program) weren't in chipmem. I'll add a seperate config purely for the course *

(I did read the part about most of the examples not working, due to fast RAM being present, but that was yesterday. I didn't try example 2 until today, by which time I had forgotten about the fast RAM thing, doh!!)

Also, after exiting the code all workbench graphical operations run at about 1/5 normal speed (perhaps slower). Is that intentional, or due to my setup?

Setup: WinUAE as A600 (2MB chip RAM, kickstart 37.350, workbench ver. 37.71)


Regards,
Lonewolf10

[BippyM]

Just force the code into chipram within the program!

[Leffmann]

Originally Posted by Lonewolf10

Also, after exiting the code all workbench graphical operations run at about 1/5 normal speed (perhaps slower). Is that intentional, or due to my setup?

Definitely not intentional. Can you post your code?

Also, make sure you locate your code and related data in public memory when it's final and you release your stuff. It's the best place for it and enables it to run faster if you have fastmem. The only data that must reside in chipmem is data that is to be directly accessed by the hardware, such as sprites and bitplanes, copper programs, blitter data etc.

[Lonewolf10]

Originally Posted by Leffmann

Definitely not intentional. Can you post your code?

Also, make sure you locate your code and related data in public memory when it's final and you release your stuff. It's the best place for it and enables it to run faster if you have fastmem. The only data that must reside in chipmem is data that is to be directly accessed by the hardware, such as sprites and bitplanes, copper programs, blitter data etc.

I know about chip and fast memory, but public memory always confuses me.

This is the code from the course (Part 2, page 16). I added the saving of the register values, but that doesn't make any difference. I tried compiling with them commented out (asterisks at start of both movem.l lines) and with them included.

;
; Danish Assembler Course: Example 2 (part 2, page 16)
; Saving/restoring register values added by ADB
; Always compile WITHOUT fast RAM, so copperlist is in chip memory.
;

    movem.l        a1/a6,-(sp)

    move.w        #$01A0,$DFF096    ;DMACON (all DMA off)
    lea.l        copperlist(pc),a1
    move.l        a1,$DFF080    ;COP1LCH

    move.w        #$8080,$DFF096    ;DMACON (was $8080)
wait:
    btst        #6,$BFE001    ;wait for LMB
    bne        wait

    move.w        $0080,$DFF096    ;DMACON
    move.l        $04,a6
    move.l        156(a6),a1
    move.l        38(a1),$DFF080    ;COP1LCH
    move.w        #$81A0,$DFF096    ;DMACON

    movem.l        (sp)+,a1/a6
    rts

copperlist:                ;Translation
    dc.w        $9001,$FFFE    ;wait for line $90 (144)
    dc.w        $0180,$0F00    ;Colour 0 to $F00 (red)
    dc.w        $A001,$FFFE    ;wait for line $A0 (160)
    dc.w        $0180,$0FFF    ;Colour 0 to $FFF (white)
    dc.w        $A401,$FFFE    ;wait for line $A4 (164)
    dc.w        $0180,$000F    ;Colour 0 to $00F (blue)
    dc.w        $AA01,$FFFE    ;wait for line $AA (170)
    dc.w        $0180,$0FFF    ;Colour 0 to $FFF (white)
    dc.w        $AE01,$FFFE    ;wait for line $AE (174)
    dc.w        $0180,$0F00    ;Colour 0 to $F00 (red)
    dc.w        $BE01,$FFFE    ;wait for line $BE (190)
    dc.w        $0180,$0000    ;Colour 0 to $000 (black)
    dc.w        $FFFF,$FFFE    ;wait forever (until next VBL)

Perhaps it's glitchy as it is designed to be used with K-Seka?


Regards,
Lonewolf10

[StingRay]

The code is quite bad because it doesn't restore the DMACON settings properly. Correct way to do it is like this:
- store current DMACON settings (read register DMACONR, $dff002) so you can
- write this value back to DMACON ($dff096) upon exit (don't forget to set BIT #15 (SET/CLR) before)

I don't give any code example because it is a good exercise for you to do it yourself.

[Retroplay]

Originally Posted by fryguy

I can understand danish when reading. But spoken danish is just strange :P

I know what you mean, it's the exact same thing for me and swedish.

[Lonewolf10]

Originally Posted by StingRay

The code is quite bad because it doesn't restore the DMACON settings properly. Correct way to do it is like this:
- store current DMACON settings (read register DMACONR, $dff002) so you can
- write this value back to DMACON ($dff096) upon exit (don't forget to set BIT #15 (SET/CLR) before)

I don't give any code example because it is a good exercise for you to do it yourself.

Thanks. It took a while but I got it working properly now

(I commented out the line "move.w #$81A0,$DFF096", added a dc.l to store the DMACONR value and a few other lines to store/retrieve it to/from there)


Regards,
Lonewolf10

[Lonewolf10]

I am continuing on with the course (currently on part 4), but something is starting to bug me. Some of the examples use...

blk.l 1,0

...to reserve space and their pre-set value when compiled. Devpac 2 doesn't like this saying "instruction not recognised". I can replace it with "dc.w" which isn't too much hassle, but I was wondering why it doesn't like the above. Is it K-Seka specific?


Regards,
Lonewolf10

[StingRay]

Originally Posted by Lonewolf10

Thanks. It took a while but I got it working properly now

Nice one.

Originally Posted by Lonewolf10

(I commented out the line "move.w #$81A0,$DFF096", added a dc.l to store the DMACONR value and a few other lines to store/retrieve it to/from there)

DMACON is a word sized register, so a dc.w is enough. dc.l will work too of course but you waste 2 bytes.

Originally Posted by Lonewolf10

I am continuing on with the course (currently on part 4), but something is starting to bug me. Some of the examples use...

blk.l 1,0

...to reserve space and their pre-set value when compiled. Devpac 2 doesn't like this saying "instruction not recognised". I can replace it with "dc.w" which isn't too much hassle, but I was wondering why it doesn't like the above. Is it K-Seka specific?

blk is SEKA specific, yes. Devpac and most other Assemblers use ds (d.efine s.torage) which is the same as blk. And watch out, dc.w 0 is not the same blk.l 1,0. (word vs. long).

[Lonewolf10]

Originally Posted by StingRay

DMACON is a word sized register, so a dc.w is enough. dc.l will work too of course but you waste 2 bytes.

Yes, oops. I was more concerned with getting it to work properly and overlooked that.

Originally Posted by StingRay

blk is SEKA specific, yes. Devpac and most other Assemblers use ds (d.efine s.torage) which is the same as blk. And watch out, dc.w 0 is not the same blk.l 1,0. (word vs. long).

Thanks for that. I just reached example 6 (part 4, page 9) that uses "blk.l 10240,$80" to define one bitplane and pre-sets the bitplane value for a quick display of how a bitplane works.
Of course, I'll have to add some move.l's and a dbra loop to do the same thing, as ds (define storage) doesn't seem to support the pre-set values (2nd part of blk.l)


Regards,
Lonewolf10

[StingRay]

Originally Posted by Lonewolf10

Thanks for that. I just reached example 6 (part 4, page 9) that uses "blk.l 10240,$80" to define one bitplane and pre-sets the bitplane value for a quick display of how a bitplane works.
Of course, I'll have to add some move.l's and a dbra loop to do the same thing, as ds (define storage) doesn't seem to support the pre-set values (2nd part of blk.l)

Just use dcb.l 10240,$80 instead of blk. (d.efine c.onstant b.lock)