cc65/libsrc/atari/initcwd.s

;
; Stefan Haubenthal, 2008-04-29
;

        .export         initcwd
        .import         findfreeiocb
        .import         __cwd
        .include        "atari.inc"

.proc   initcwd

        lda     #0
        sta     __cwd
        jsr     findfreeiocb
        bne     oserr
        lda     #GETCWD
        sta     ICCOM,x
        lda     #<__cwd
        sta     ICBLL,x
        lda     #>__cwd
        sta     ICBLH,x
        jsr     CIOV
        bmi     oserr
        ldx     #$FF            ; ATEOL -> \0
:       inx
        lda     __cwd,x
        cmp     #ATEOL
        bne     :-
        lda     #0
        sta     __cwd,x
oserr:  rts

.endproc
syschdir by Stefan Haubenthal git-svn-id: svn://svn.cc65.org/cc65/trunk@4658 b7a2c559-68d2-44c3-8de9-860c34a00d81 2010-05-01 22:33:25 +00:00			`;`
			`; Stefan Haubenthal, 2008-04-29`
			`;`

Removed (pretty inconsistently used) tab chars from source code base. 2013-05-09 11:56:54 +00:00			`.export initcwd`
			`.import findfreeiocb`
			`.import __cwd`
			`.include "atari.inc"`
syschdir by Stefan Haubenthal git-svn-id: svn://svn.cc65.org/cc65/trunk@4658 b7a2c559-68d2-44c3-8de9-860c34a00d81 2010-05-01 22:33:25 +00:00
Removed (pretty inconsistently used) tab chars from source code base. 2013-05-09 11:56:54 +00:00			`.proc initcwd`
syschdir by Stefan Haubenthal git-svn-id: svn://svn.cc65.org/cc65/trunk@4658 b7a2c559-68d2-44c3-8de9-860c34a00d81 2010-05-01 22:33:25 +00:00
Changed run location of INIT segment. So far the INIT segment was run from the later heap+stack. Now the INIT segment is run from the later BSS. The background is that so far the INIT segment was pretty small (from $80 to $180 bytes). But upcoming changes will increase the INIT segment in certain scenarios up to ~ $1000 bytes. So programs with very limited heap+stack might just not been able to move the INIT segment to its run location. But moving the INIT segment to the later BSS allows it to occupy the later BSS+heap+stack. In order to allow that the constructors are _NOT_ allowed anymore to access the BSS. Rather they must use the DATA segment or the new INITBSS segment. The latter isn't cleared at any point so the constructors may use it to expose values to the main program. However they must make sure to always write the values as they are not pre-initialized. 2015-10-14 20:52:09 +00:00			`lda #0`
			`sta __cwd`
Removed (pretty inconsistently used) tab chars from source code base. 2013-05-09 11:56:54 +00:00			`jsr findfreeiocb`
			`bne oserr`
Use symbolic names for all CIO commands. 2013-06-07 22:35:07 +00:00			`lda #GETCWD`
Removed (pretty inconsistently used) tab chars from source code base. 2013-05-09 11:56:54 +00:00			`sta ICCOM,x`
			`lda #<__cwd`
			`sta ICBLL,x`
			`lda #>__cwd`
			`sta ICBLH,x`
			`jsr CIOV`
			`bmi oserr`
Adjusted current working directory initialization on Apple and Atari. Moving __cwd from BSS into INITBSS does of course ;-) not only impact the CBM targets but all targets with disk I/O support. Note: Code using `__cwd-1` may trigger an ld65 range error because __cwd may end up at the very begining of a segment. As far as I see this is an ld65 bug which I'm not try to fix - at least here. 2015-10-14 22:15:38 +00:00			`ldx #$FF ; ATEOL -> \0`
			`: inx`
			`lda __cwd,x`
Removed (pretty inconsistently used) tab chars from source code base. 2013-05-09 11:56:54 +00:00			`cmp #ATEOL`
			`bne :-`
			`lda #0`
Adjusted current working directory initialization on Apple and Atari. Moving __cwd from BSS into INITBSS does of course ;-) not only impact the CBM targets but all targets with disk I/O support. Note: Code using `__cwd-1` may trigger an ld65 range error because __cwd may end up at the very begining of a segment. As far as I see this is an ld65 bug which I'm not try to fix - at least here. 2015-10-14 22:15:38 +00:00			`sta __cwd,x`
Removed (pretty inconsistently used) tab chars from source code base. 2013-05-09 11:56:54 +00:00			`oserr: rts`
syschdir by Stefan Haubenthal git-svn-id: svn://svn.cc65.org/cc65/trunk@4658 b7a2c559-68d2-44c3-8de9-860c34a00d81 2010-05-01 22:33:25 +00:00
			`.endproc`