pouët.net

Go to bottom

Amiga OCS/ECS development with VBCC

category: code [glöplog]
 
This might be a long-shot, but here goes:

I'm trying to do some development, targeting OCS/ECS Amigas in C, using the VBCC compiler.
Most of the code is in C, but the bringup/bringdown of the AmigaOS stuff is done by calling asm-functions that I haven't written myself.
The problem is that sometimes adding code in the main C program will make the Amiga freeze when exiting the program. The problem is reproduceable, ie. once I have "bad" code, it will always lock up. But then I remove some lines again and things start working again. I've never found any logic in what code triggers the exit-problem.
Could there be some errors in the bringup/down code that I've found?


The main.c looks something like this:
Code: #include <stdlib.h> #include <hardware/custom.h> #include <hardware/cia.h> #include "asm_util.h" int main(char *cmdline) { startup(); // Cool stuff happens here bringdown(); exit(0); }


And here are the asm-functions
Code: xdef _startup xdef _bringdown DMACONR EQU $dff002 ADKCONR EQU $dff010 INTENAR EQU $dff01 c INTREQR EQU $dff01e DMACON EQU $dff096 ADKCON EQU $dff09e INTENA E QU $dff09a INTREQ EQU $dff09c _startup: movem.l d0-a6,-(sp) ; store hardware registers, store view- and copperaddresses, load blank view, wait 2x for top of frame, ; own blitter, wait for blitter AND finally forbid multitasking! ; all this just to be able to exit gracely ; store data in hardwareregisters ORed with $8000 (bit 15 is a write-set bit when ; values are written back into the system) move.w DMACONR,d0 or.w #$8000,d0 move.w d0,olddmareq move.w INTENAR,d0 or.w #$8000,d0 move.w d0,oldintena move.w INTREQR,d0 or.w #$8000,d0 move.w d0,oldintreq move.w ADKCONR,d0 or.w #$8000,d0 move.w d0,oldadkcon move.l $4,a6 move.l #gfxname,a1 moveq #0,d0 jsr -408(a 6) ; oldOpenLibrary offset=-408 ... would OpenLibrary be better? offset=-552 move.l d0,gfxbase move.l d0,a6 move.l 34(a6),oldview move.l 38(a6),oldcopper move.l #0,a1 jsr -222(a6) ; LoadView jsr -270(a6) ; WaitTOF jsr -270(a6) ; WaitTOF jsr -456(a6) ; OwnBlitter jsr -228(a6) ; WaitBlit move.l $4,a6 jsr -132(a6) ; Forbid ;jsr mt_init movem.l (sp)+,d0-a6 rts _bringdown: ; exit gracely - reverse everything done in init move.w #$7fff,DMACON move.w olddmareq,DMACON move.w #$7fff,INTENA move.w oldintena,INTENA move.w #$7fff,INTREQ move.w oldintreq,INTREQ move.w #$7fff,ADKCON move.w oldadkcon,ADKCON move.l oldcopper,$dff080 move.l gfxbase,a6 move.l oldview,a1 jsr -222(a6) ; LoadView jsr -270(a6) ; WaitTOF jsr -270(a6) ; WaitTOF jsr -228(a6) ; WaitBlit jsr -462(a6) ; DisownBlitter move.l $4,a6 jsr -138(a6) ; Permit ; end program rts ; ******************************************************************************* ; ******************************************************************************* ; DATA ; ******************************************************************************* ; ******************************************************************************* ; storage for 32-bit addresses and data CNOP 0,4 oldview: dc.l 0 oldcopper: dc.l 0 gfxbase: dc.l 0 ; storage for 16-bit data CNOP 0,4 olddmareq: dc.w 0 oldintreq: dc.w 0 oldintena: dc.w 0 oldadkcon: dc.w 0 ; storage for 8-bit data and text CNOP 0,4 gfxname: dc.b 'graphics.library',0
added on the 2019-09-11 23:24:46 by Sdw Sdw
I have no clue about Amiga stuff, but whenever I see a "random" issue like this popping up when mixing C and assembly code, it's usually me missing up the calling convention (i.e. not preserving registers & stack alignment properly). You might want to recheck that, but it could be something entirely different as well, ofc.
added on the 2019-09-11 23:40:16 by porocyon porocyon
Looks as if the "bad" code does something bad. Could you give an example plz.? How do the prototypes of startup() and bringdown() look like?

By the way

Code:move.l $4,a6 jsr -132(a6) ; Forbid


should be called first in _startup.

Besides of this, your main method should look like that:

Code:int main(int argc, char *argv[]) { startup(); // Cool stuff happens here bringdown(); return 0; }


Some transformations into canonical form are possible in asm part:

move.l $4,a6 -> move.l $4.w,a6
move.l #gfxname,a1 -> lea gfxname(pc),a1
added on the 2019-09-12 05:44:49 by dOc.K dOc.K
Try adding a wait for the vertical blank before restoring INTENA/DMA etc. in _bringdown.
added on the 2019-09-12 09:21:18 by StingRay StingRay
another good place to ask stuff like this is: ada.untergrund.net coding forum
added on the 2019-09-12 09:29:03 by spike spike
what if you restore all registers (a1, a6) in bringdown?
added on the 2019-09-12 13:21:06 by dodke dodke
Thank you all for your suggestions! I've implemented the suggested changes, and the problem appears to be solved!
By testing them one by one, it seems like it was the exit(0) -> return 0 that made the lockups disappear, but I'll keep the other changes as well just to make sure. :)
added on the 2019-09-12 13:43:37 by Sdw Sdw
btw. why not write startup() and bringdown() directly in C?
added on the 2019-09-12 15:20:52 by spike spike
By chance I found a video from Evoke presenting this:
vscode-amiga-debug by Abyss
...and now I think I need to ditch my VBCC setup entirely and switch to that instead! :D
added on the 2019-09-12 22:01:31 by Sdw Sdw
Quote:
By chance I found a video from Evoke presenting this:
vscode-amiga-debug by Abyss
...and now I think I need to ditch my VBCC setup entirely and switch to that instead! :D


We, the pt-1210 dev team, haven't dropped into that new setup yet but u til recently our build system supported both gcc and vbcc, we have now since dropped vbcc just because it makes life a little easier. We've also just added a python based iff parser making it super easy to replace graphics.

But yeah, from the experience of converting what was originally a 100% asm project into mostly c, I would also suggest doing your system save and restore in c. Any access to the system is a lot simpler.
added on the 2019-09-12 22:39:36 by djh0ffman djh0ffman
I guess the video you are talking of is this:
https://www.twitch.tv/evoke/video/468413972?filter=archives&sort=time

I just wanted to pinpoint you to this...but maybe this link helps others in the future then atleast! ;)
oops, should have clicked your link first and could have seen the first comment had a link to the same video, then! ;)
Well, one click less for ppl in the future for the video, while your link has the download to the codechain! :)

login

Go to top