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:
And here are the asm-functions
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 $dff01c
INTREQR EQU $dff01e
DMACON EQU $dff096
ADKCON EQU $dff09e
INTENA EQU $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(a6) ; 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
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.
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
should be called first in _startup.
Besides of this, your main method should look like that:
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
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
Try adding a wait for the vertical blank before restoring INTENA/DMA etc. in _bringdown.
another good place to ask stuff like this is: ada.untergrund.net coding forum
what if you restore all registers (a1, a6) in bringdown?
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. :)
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. :)
btw. why not write startup() and bringdown() directly in C?
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
vscode-amiga-debug by Abyss
...and now I think I need to ditch my VBCC setup entirely and switch to that instead! :D
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.
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! ;)
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! :)
Well, one click less for ppl in the future for the video, while your link has the download to the codechain! :)