Page 3 of 4

Posted: Mon Mar 12, 2007 6:31 pm
by wstjohn
Mats,
My mistake - i wrote that from memory and got it wrong. Here is the real code:

Code: Select all

  ldy   #7
.drawLine
  lda   (PF1_pointer),Y
  sta   PF1
  sta   WSYNC
  dey
  bne   .drawLine  
PF1_pointer points to an 8 byte rom table containing a checkerboard pattern.
However what gets drawn to the screen is a single line of alternating color, not a checkerboard.
If I do it like this:

Code: Select all

  ldy  #7
  lda  (PF1_pointer),Y
  sta  PF1
  sta  WSYNC
  ldy  #6
  lda  (PF1_pointer),Y
  sta  PF1
  sta  WSYNC
  ldy  #5
  ;etc  
then the checkerboard pattern is drawn correctly.

Posted: Mon Mar 12, 2007 9:01 pm
by Mats
Then your simulator must be bullshit! Try the one of Kowalski! Your "short" code is absolutely correct and must give exactly the same result as the "long" version!

Posted: Mon Mar 12, 2007 9:18 pm
by wstjohn
Mats wrote:
Then your simulator must be bullshit! Try the one of Kowalski! Your "short" code is absolutely correct and must give exactly the same result as the "long" version!
OK, so Im not crazy after all. good.

I tried to assembly it with kowalski, but it didnt like the syntax for these lines, and probably a lot of others. I am writing a program for the atari vcs which runs on a 6507 processor. Is this possible? If so, I need to figure out how to change the code to make it recognize these lines and the header files...

Code: Select all

processor 6502
include vcs.h
SEG.U variables
ORG $80

Posted: Mon Mar 12, 2007 10:01 pm
by GARTHWILSON
Please do a favor for other Z26 and Stella simulator users and tell the suppliers they have a serious bug that should be easily fixable.

Oh no...

Posted: Mon Mar 12, 2007 11:31 pm
by wstjohn
OK, I am really confused now.
I wrote another test program using the same indirect addressing mode, and it WORKS on Stella and Z26! The original example only works on PCAE.
Also - I could have sworn that the code:

Code: Select all

  ldy   #7
.drawLine
  lda   (PF1_pointer),Y
  sta   PF1
  sta   WSYNC
  dey
  bne   .drawLine
only drew one line, and I had to code each line manually for it to show up, but now this is working on all 3 emulators. I dont know what to believe now. Was it my fault all along? (I reeeaallly can't see what it could have been) Is it a bug in stella and z26 that some other minor, seemingly unrelated change that made it work/not work?
I am just starting and am really wondering if this is even worth it. Then again I don't really have a choice.
I really appreciate everyone's help. I would be totally clueless without it.

Posted: Tue Mar 13, 2007 6:47 am
by Mats
Why do you say that the Kowalski simulator does not like your syntax? I just tested

Code: Select all

PF1_pointer=$00
PF1=$02
WSYNC=$03
  *=$0300
;
;SET THE POINTER
;
      LDA #<TitleScreen_PF0
      STA PF1_pointer
      LDA #>TitleScreen_PF0
      STA PF1_pointer+1
;
;your code, start
;
  ldy   #7 
.drawLine 
  lda   (PF1_pointer),Y 
  sta   PF1 
  sta   WSYNC 
  dey 
  bne   .drawLine  
;
;your code, end
;
      BRK
TitleScreen_PF0   .BYTE  $10
                  .BYTE  $11
                  .BYTE  $12
                  .BYTE  $13
                  .BYTE  $14
                  .BYTE  $15
                  .BYTE  $16
                  .BYTE  $17

and there is absolutely no problem. Obviously you have to define the symbols

PF1_pointer=$00
PF1=$02
WSYNC=$03

and also the label "TitleScreen_PF0" must be present!

Posted: Tue Mar 13, 2007 6:58 am
by Mats
..but with your code the first item of the table will never be loaded. You could for example code

bpl .drawLine

instead of

bne .drawLine

to have the loop executed also with "0" in the Y-register!

Posted: Tue Mar 13, 2007 10:13 am
by Mats
I looked into your full code that you submitted in the beginning to see if the syntax could easily be made compatible with Kowalski(and other) assemblers.
First of all, only labels start in column 1. Then you have many special "directives" etc in your code that obviously cannot be understood (=>syntax errors). But in addition to this there is at least one logical error, the symbol/label "PF1" is used but nowhere defined! This is detected by the assembler

Your code with the obvious syntax errors corrected (but not logical errors):

Code: Select all

;Code: 
;------------------------------------------------ 
; Addressing Test 
;------------------------------------------------ 
;processor 6502 
;include vcs.h 
;include macro.h 
;------------------------------------------------ 
; Constants and Variables 
;------------------------------------------------ 
;SEG.U variables 
;ORG $80 replaced by:
 *=$80 
;PF1_pointer .word  no word specified here, you just want
;                   to reserve space (in ZP)
PF1_pointer *=*+2
ScreenFake = $AA 
Screen_PF1 = $01AA 

;------------------------------------------------ 
; START OF ROM 
;------------------------------------------------ 
;SEG Bank0  SEG?
;ORG $F000 ; 4k ROM start point 
 *=$F000 ; 4k ROM start point 
;------------------------------------------------------------------------- 
; Game 
;------------------------------------------------ 
Start 
CLEAN_START ; Clear RAM and Registers 

;lda #%10001000   ;only labels start in first column
 lda #$88
;sta Screen_PF1   ;only labels start in first column
 sta Screen_PF1 
;lda #%11111111   ;only labels start in first column 
 lda #$FF 
;sta ScreenFake   ;only labels start in first column 
 sta ScreenFake 

;SET_POINTER PF1_pointer, Screen_PF1 SET????
 ldy #0 ;only labels start in first column
 lda (PF1_pointer),Y ;only labels start in first column
 sta PF1 ;only labels start in first column

 lda #$94 
 sta COLUPF 

.mainLoop 
 jsr VERTICAL_BLANK 
 jsr DRAW 
 jsr WAIT_V_BLANK 
 jsr OVERSCAN 
 jmp .mainLoop 

;------------------------------------------------------------------------- 
; SUBROUTINES 
;------------------------------------------------ 
;***** VERTICAL_BLANK ***** 
VERTICAL_BLANK 
 lda #0 
 sta VBLANK 
VERTICAL_SYNC 
 lda #41 ;41 64-cycle ticks 
 sta TIM64T 
 RTS 

;***** WAIT_V_BLANK ***** 
WAIT_V_BLANK 
.waitForVBlank 
 lda INTIM 
 bne .waitForVBlank 
 RTS 

;***** DRAW ***** 
DRAW 
 ldx #220 
.drawLine 
 sta WSYNC 
 dex 
 bne .drawLine 
 RTS 

;***** OVERSCAN ***** 
OVERSCAN 
;lda #%01000010 
 lda #$42 
 sta VBLANK 
 lda #35 
 sta TIM64T 
.waitForOverscan 
 lda INTIM 
 bne .waitForOverscan 
 RTS 

;------------------------------------------------ 
; Interrupt Vectors 
;------------------------------------------------ 
;echo [*-$F000]d, " ROM bytes used"  ?????
;ORG $FFFA
 *= $FFFA
 .word Start ; NMI 
 .word Start ; RESET 
 .word Start ; IRQ 
END

Posted: Tue Mar 13, 2007 1:23 pm
by wstjohn
Thanks for catching that error in the loop. I'll use bpl instead.
The thing is, I'm writing an atari game, so I need to have those directives, as far as I know. The PF1 is a register defined in vcs.h. Well, I guess I could just pull the info from that header file and dump it in with the rest of the code.

I guess I'm just not experienced enough with assembly to know what is kosher or not with each assembler.
Thanks for your help though.

Posted: Tue Mar 13, 2007 4:14 pm
by BitWise
At the risk of complicating the discussion, if all you are trying to do is move blocks of data from a ROM area to video RAM for a splash screen then some absolute indexed loads and stores might be quicker and simpler.

For example if your splash screen is 1K of data, then ..

Code: Select all

 LDX #0
.Splash
 LDA SPLASH+$000,X
 STA SCREEN+$000,X
 LDA SPLASH+$100,X
 STA SCREEN+$100,X
 LDA SPLASH+$200,X
 STA SCREEN+$200,X
 LDA SPLASH+$300,X
 STA SCREEN+$300,X
 DEX
 BNE .Splash
.. would copy it from a SPLASH to SCREEN.

Edit: Having read a technical description of the VCS I can see the foolishness of my posting. 1K of RAM, in my dreams

Posted: Tue Mar 13, 2007 4:44 pm
by Mats
If you really want to run it on a real ATARI computer I can tell you that with:

Code: Select all

*= $FFFA 
 .word Start ; NMI 
 .word Start ; RESET 
 .word Start ; IRQ 
nothing will work, the ATARI will be completly dead!

The reset vector in $FFFC,$FFFD has to point to an adequate boot sequence and also the IRQ vector in $FFFE,$FFFF is certainly needed for hardware interrupts and has to point to completly different code then what you have following label "Start"!. If it at all should possible for a "user" to write his own programs for an ATARI computer there must be some "Application Program Interfaces" foreseen in the ATARI operating system. Otherwise you have to write the complete operating system yourself including management of screen, keyboard etc.

The

Code: Select all

 include vcs.h 
 include macro.h 
must contain a lot of stuff as your code (without this) is full of undefined labels/symbols. From where does this "include code" come and from where the idea that ATARI application programs can be written with this approach overwriting the original operating system resident in ROM? At least the top of the ROM is part of the operating system! Application programs have to reside in RAM/ROM not used by the operating system and control to the application program has to be given from the operating system in the way foreseen by the system designer!

For a Commodore this is done with BASIC command "SYS".

Posted: Tue Mar 13, 2007 5:28 pm
by wstjohn
Mats wrote:
If you really want to run it on a real ATARI computer I can tell you that with:

Code: Select all

*= $FFFA 
 .word Start ; NMI 
 .word Start ; RESET 
 .word Start ; IRQ 
nothing will work, the ATARI will be completly dead!

The reset vector in $FFFC,$FFFD has to point to an adequate boot sequence and also the IRQ vector in $FFFE,$FFFF is certainly needed for hardware interrupts and has to point to completly different code then what you have following label "Start"!. If it at all should possible for a "user" to write his own programs for an ATARI computer there must be some "Application Program Interfaces" foreseen in the ATARI operating system. Otherwise you have to write the complete operating system yourself including management of screen, keyboard etc.

The

Code: Select all

 include vcs.h 
 include macro.h 
must contain a lot of stuff as your code (without this) is full of undefined labels/symbols. From where does this "include code" come and from where the idea that ATARI application programs can be written with this approach overwriting the original operating system resident in ROM? At least the top of the ROM is part of the operating system! Application programs have to reside in RAM/ROM not used by the operating system and control to the application program has to be given from the operating system in the way foreseen by the system designer!

For a Commodore this is done with BASIC command "SYS".
OK, I don't understand enough to know what you're talking about. The code

Code: Select all

*= $FFFA 
 .word Start ; NMI 
 .word Start ; RESET 
 .word Start ; IRQ 
is in all the examples I have been working with, and it works on the assembler and the atari emulators. Here is the code from the include files:

Code: Select all

; VCS.H
; Version 1.05, 13/November/2003

VERSION_VCS         = 105

; THIS IS A PRELIMINARY RELEASE OF *THE* "STANDARD" VCS.H
; THIS FILE IS EXPLICITLY SUPPORTED AS A DASM-PREFERRED COMPANION FILE
; PLEASE DO *NOT* REDISTRIBUTE THIS FILE!
;
; This file defines hardware registers and memory mapping for the
; Atari 2600. It is distributed as a companion machine-specific support package
; for the DASM compiler. Updates to this file, DASM, and associated tools are
; available at at http://www.atari2600.org/dasm
;
; Many thanks to the original author(s) of this file, and to everyone who has
; contributed to understanding the Atari 2600.  If you take issue with the
; contents, or naming of registers, please write to me (atari2600@taswegian.com)
; with your views.  Please contribute, if you think you can improve this
; file!
;
; Latest Revisions...
; 1.05  13/NOV/2003      - Correction to 1.04 - now functions as requested by MR.
;                        - Added VERSION_VCS equate (which will reflect 100x version #)
;                          This will allow conditional code to verify VCS.H being
;                          used for code assembly.
; 1.04  12/NOV/2003     Added TIA_BASE_WRITE_ADDRESS and TIA_BASE_READ_ADDRESS for
;                       convenient disassembly/reassembly compatibility for hardware
;                       mirrored reading/writing differences.  This is more a 
;                       readability issue, and binary compatibility with disassembled
;                       and reassembled sources.  Per Manuel Rotschkar's suggestion.
; 1.03  12/MAY/2003     Added SEG segment at end of file to fix old-code compatibility
;                       which was broken by the use of segments in this file, as
;                       reported by Manuel Polik on [stella] 11/MAY/2003
; 1.02  22/MAR/2003     Added TIMINT($285)
; 1.01	        		Constant offset added to allow use for 3F-style bankswitching
;						 - define TIA_BASE_ADDRESS as $40 for Tigervision carts, otherwise
;						   it is safe to leave it undefined, and the base address will
;						   be set to 0.  Thanks to Eckhard Stolberg for the suggestion.
;                          Note, may use -DLABEL=EXPRESSION to define TIA_BASE_ADDRESS
;                        - register definitions are now generated through assignment
;                          in uninitialised segments.  This allows a changeable base
;                          address architecture.
; 1.0	22/MAR/2003		Initial release


;-------------------------------------------------------------------------------

; TIA_BASE_ADDRESS
; The TIA_BASE_ADDRESS defines the base address of access to TIA registers.
; Normally 0, the base address should (externally, before including this file)
; be set to $40 when creating 3F-bankswitched (and other?) cartridges.
; The reason is that this bankswitching scheme treats any access to locations
; < $40 as a bankswitch.

			IFNCONST TIA_BASE_ADDRESS
TIA_BASE_ADDRESS	= 0
			ENDIF

; Note: The address may be defined on the command-line using the -D switch, eg:
; dasm.exe code.asm -DTIA_BASE_ADDRESS=$40 -f3 -v5 -ocode.bin
; *OR* by declaring the label before including this file, eg:
; TIA_BASE_ADDRESS = $40
;   include "vcs.h"

; Alternate read/write address capability - allows for some disassembly compatibility
; usage ; to allow reassembly to binary perfect copies).  This is essentially catering
; for the mirrored ROM hardware registers.

; Usage: As per above, define the TIA_BASE_READ_ADDRESS and/or TIA_BASE_WRITE_ADDRESS
; using the -D command-line switch, as required.  If the addresses are not defined, 
; they defaut to the TIA_BASE_ADDRESS.

     IFNCONST TIA_BASE_READ_ADDRESS
TIA_BASE_READ_ADDRESS = TIA_BASE_ADDRESS
     ENDIF

     IFNCONST TIA_BASE_WRITE_ADDRESS
TIA_BASE_WRITE_ADDRESS = TIA_BASE_ADDRESS
     ENDIF

;-------------------------------------------------------------------------------

			SEG.U TIA_REGISTERS_WRITE
			ORG TIA_BASE_WRITE_ADDRESS

	; DO NOT CHANGE THE RELATIVE ORDERING OF REGISTERS!
    
VSYNC       ds 1    ; $00   0000 00x0   Vertical Sync Set-Clear
VBLANK		ds 1	; $01   xx00 00x0   Vertical Blank Set-Clear
WSYNC		ds 1	; $02   ---- ----   Wait for Horizontal Blank
RSYNC		ds 1	; $03   ---- ----   Reset Horizontal Sync Counter
NUSIZ0		ds 1	; $04   00xx 0xxx   Number-Size player/missle 0
NUSIZ1		ds 1	; $05   00xx 0xxx   Number-Size player/missle 1
COLUP0		ds 1	; $06   xxxx xxx0   Color-Luminance Player 0
COLUP1      ds 1    ; $07   xxxx xxx0   Color-Luminance Player 1
COLUPF      ds 1    ; $08   xxxx xxx0   Color-Luminance Playfield
COLUBK      ds 1    ; $09   xxxx xxx0   Color-Luminance Background
CTRLPF      ds 1    ; $0A   00xx 0xxx   Control Playfield, Ball, Collisions
REFP0       ds 1    ; $0B   0000 x000   Reflection Player 0
REFP1       ds 1    ; $0C   0000 x000   Reflection Player 1
PF0         ds 1    ; $0D   xxxx 0000   Playfield Register Byte 0
PF1         ds 1    ; $0E   xxxx xxxx   Playfield Register Byte 1
PF2         ds 1    ; $0F   xxxx xxxx   Playfield Register Byte 2
RESP0       ds 1    ; $10   ---- ----   Reset Player 0
RESP1       ds 1    ; $11   ---- ----   Reset Player 1
RESM0       ds 1    ; $12   ---- ----   Reset Missle 0
RESM1       ds 1    ; $13   ---- ----   Reset Missle 1
RESBL       ds 1    ; $14   ---- ----   Reset Ball
AUDC0       ds 1    ; $15   0000 xxxx   Audio Control 0
AUDC1       ds 1    ; $16   0000 xxxx   Audio Control 1
AUDF0       ds 1    ; $17   000x xxxx   Audio Frequency 0
AUDF1       ds 1    ; $18   000x xxxx   Audio Frequency 1
AUDV0       ds 1    ; $19   0000 xxxx   Audio Volume 0
AUDV1       ds 1    ; $1A   0000 xxxx   Audio Volume 1
GRP0        ds 1    ; $1B   xxxx xxxx   Graphics Register Player 0
GRP1        ds 1    ; $1C   xxxx xxxx   Graphics Register Player 1
ENAM0       ds 1    ; $1D   0000 00x0   Graphics Enable Missle 0
ENAM1       ds 1    ; $1E   0000 00x0   Graphics Enable Missle 1
ENABL       ds 1    ; $1F   0000 00x0   Graphics Enable Ball
HMP0        ds 1    ; $20   xxxx 0000   Horizontal Motion Player 0
HMP1        ds 1    ; $21   xxxx 0000   Horizontal Motion Player 1
HMM0        ds 1    ; $22   xxxx 0000   Horizontal Motion Missle 0
HMM1        ds 1    ; $23   xxxx 0000   Horizontal Motion Missle 1
HMBL        ds 1    ; $24   xxxx 0000   Horizontal Motion Ball
VDELP0      ds 1    ; $25   0000 000x   Vertical Delay Player 0
VDELP1      ds 1    ; $26   0000 000x   Vertical Delay Player 1
VDELBL      ds 1    ; $27   0000 000x   Vertical Delay Ball
RESMP0      ds 1    ; $28   0000 00x0   Reset Missle 0 to Player 0
RESMP1      ds 1    ; $29   0000 00x0   Reset Missle 1 to Player 1
HMOVE       ds 1    ; $2A   ---- ----   Apply Horizontal Motion
HMCLR       ds 1    ; $2B   ---- ----   Clear Horizontal Move Registers
CXCLR       ds 1    ; $2C   ---- ----   Clear Collision Latches
 
;-------------------------------------------------------------------------------

			SEG.U TIA_REGISTERS_READ
			ORG TIA_BASE_READ_ADDRESS

                    ;											bit 7   bit 6
CXM0P       ds 1    ; $00       xx00 0000       Read Collision  M0-P1   M0-P0
CXM1P       ds 1    ; $01       xx00 0000                       M1-P0   M1-P1
CXP0FB      ds 1    ; $02       xx00 0000                       P0-PF   P0-BL
CXP1FB      ds 1    ; $03       xx00 0000                       P1-PF   P1-BL
CXM0FB      ds 1    ; $04       xx00 0000                       M0-PF   M0-BL
CXM1FB      ds 1    ; $05       xx00 0000                       M1-PF   M1-BL
CXBLPF      ds 1    ; $06       x000 0000                       BL-PF   -----
CXPPMM      ds 1    ; $07       xx00 0000                       P0-P1   M0-M1
INPT0       ds 1    ; $08       x000 0000       Read Pot Port 0
INPT1       ds 1    ; $09       x000 0000       Read Pot Port 1
INPT2       ds 1    ; $0A       x000 0000       Read Pot Port 2
INPT3       ds 1    ; $0B       x000 0000       Read Pot Port 3
INPT4       ds 1    ; $0C		x000 0000       Read Input (Trigger) 0
INPT5       ds 1	; $0D		x000 0000       Read Input (Trigger) 1

;-------------------------------------------------------------------------------

			SEG.U RIOT
			ORG $280
 
	; RIOT MEMORY MAP

SWCHA       ds 1    ; $280      Port A data register for joysticks:
					;			Bits 4-7 for player 1.  Bits 0-3 for player 2.

SWACNT      ds 1    ; $281      Port A data direction register (DDR)
SWCHB       ds 1    ; $282		Port B data (console switches)
SWBCNT      ds 1    ; $283      Port B DDR
INTIM       ds 1    ; $284		Timer output

TIMINT  	ds 1	; $285

		; Unused/undefined registers ($285-$294)

			ds 1	; $286
			ds 1	; $287
			ds 1	; $288
			ds 1	; $289
			ds 1	; $28A
			ds 1	; $28B
			ds 1	; $28C
			ds 1	; $28D
			ds 1	; $28E
			ds 1	; $28F
			ds 1	; $290
			ds 1	; $291
			ds 1	; $292
			ds 1	; $293

TIM1T       ds 1    ; $294		set 1 clock interval
TIM8T       ds 1    ; $295      set 8 clock interval
TIM64T      ds 1    ; $296      set 64 clock interval
T1024T      ds 1    ; $297      set 1024 clock interval

;-------------------------------------------------------------------------------
; The following required for back-compatibility with code which does not use
; segments.

            SEG

; EOF
and

Code: Select all

; MACRO.H
; Version 1.06, 3/SEPTEMBER/2004

VERSION_MACRO         = 106

;
; THIS FILE IS EXPLICITLY SUPPORTED AS A DASM-PREFERRED COMPANION FILE
; PLEASE DO *NOT* REDISTRIBUTE MODIFIED VERSIONS OF THIS FILE!
;
; This file defines DASM macros useful for development for the Atari 2600.
; It is distributed as a companion machine-specific support package
; for the DASM compiler. Updates to this file, DASM, and associated tools are
; available at at http://www.atari2600.org/dasm
;
; Many thanks to the people who have contributed.  If you take issue with the
; contents, or would like to add something, please write to me
; (atari2600@taswegian.com) with your contribution.
;
; Latest Revisions...
;
; 1.06  03/SEP/2004     - nice revision of VERTICAL_BLANK (Edwin Blink)
; 1.05  14/NOV/2003     - Added VERSION_MACRO equate (which will reflect 100x version #)
;                         This will allow conditional code to verify MACRO.H being
;                         used for code assembly.
; 1.04  13/NOV/2003     - SET_POINTER macro added (16-bit address load)
;
; 1.03  23/JUN/2003     - CLEAN_START macro added - clears TIA, RAM, registers
;
; 1.02  14/JUN/2003     - VERTICAL_SYNC macro added
;                         (standardised macro for vertical synch code)
; 1.01  22/MAR/2003     - SLEEP macro added. 
;                       - NO_ILLEGAL_OPCODES switch implemented
; 1.0	22/MAR/2003		Initial release

; Note: These macros use illegal opcodes.  To disable illegal opcode usage, 
;   define the symbol NO_ILLEGAL_OPCODES (-DNO_ILLEGAL_OPCODES=1 on command-line).
;   If you do not allow illegal opcode usage, you must include this file 
;   *after* including VCS.H (as the non-illegal opcodes access hardware
;   registers and require them to be defined first).

; Available macros...
;   SLEEP n             - sleep for n cycles
;   VERTICAL_SYNC       - correct 3 scanline vertical synch code
;   CLEAN_START         - set machine to known state on startup
;   SET_POINTER         - load a 16-bit absolute to a 16-bit variable

;-------------------------------------------------------------------------------
; SLEEP duration
; Original author: Thomas Jentzsch
; Inserts code which takes the specified number of cycles to execute.  This is
; useful for code where precise timing is required.
; ILLEGAL-OPCODE VERSION DOES NOT AFFECT FLAGS OR REGISTERS.
; LEGAL OPCODE VERSION MAY AFFECT FLAGS
; Uses illegal opcode (DASM 2.20.01 onwards).

            MAC SLEEP            ;usage: SLEEP n (n>1)
.CYCLES     SET {1}

                IF .CYCLES < 2
                    ECHO "MACRO ERROR: 'SLEEP': Duration must be > 1"
                    ERR
                ENDIF

                IF .CYCLES & 1
                    IFNCONST NO_ILLEGAL_OPCODES
                        nop 0
                    ELSE
                        bit VSYNC
                    ENDIF
.CYCLES             SET .CYCLES - 3
                ENDIF
            
                REPEAT .CYCLES / 2
                    nop
                REPEND
            ENDM

;-------------------------------------------------------------------------------
; VERTICAL_SYNC
; revised version by Edwin Blink -- saves bytes!
; Inserts the code required for a proper 3 scanline vertical sync sequence
; Note: Alters the accumulator

; OUT: A = 0

             MAC VERTICAL_SYNC
                lda #%1110          ; each '1' bits generate a VSYNC ON line (bits 1..3)
.VSLP1          sta WSYNC           ; 1st '0' bit resets Vsync, 2nd '0' bit exit loop
                sta VSYNC
                lsr
                bne .VSLP1          ; branch until VYSNC has been reset
             ENDM

;-------------------------------------------------------------------------------
; CLEAN_START
; Original author: Andrew Davie
; Standardised start-up code, clears stack, all TIA registers and RAM to 0
; Sets stack pointer to $FF, and all registers to 0
; Sets decimal mode off, sets interrupt flag (kind of un-necessary)
; Use as very first section of code on boot (ie: at reset)
; Code written to minimise total ROM usage - uses weird 6502 knowledge :)

            MAC CLEAN_START
                sei
                cld
            
                ldx #0
                txa
                tay
.CLEAR_STACK    dex
                txs
                pha
                bne .CLEAR_STACK     ; SP=$FF, X = A = Y = 0

            ENDM

;-------------------------------------------------------
; SET_POINTER
; Original author: Manuel Rotschkar
;
; Sets a 2 byte RAM pointer to an absolute address.
;
; Usage: SET_POINTER pointer, address
; Example: SET_POINTER SpritePTR, SpriteData
;
; Note: Alters the accumulator, NZ flags
; IN 1: 2 byte RAM location reserved for pointer
; IN 2: absolute address

            MAC SET_POINTER
.POINTER    SET {1}
.ADDRESS    SET {2}

                LDA #<.ADDRESS  ; Get Lowbyte of Address
                STA .POINTER    ; Store in pointer
                LDA #>.ADDRESS  ; Get Hibyte of Address
                STA .POINTER+1  ; Store in pointer+1

            ENDM

;-------------------------------------------------------
; BOUNDARY byte#
; Original author: Denis Debro (borrowed from Bob Smith / Thomas)
;
; Push data to a certain position inside a page and keep count of how
; many free bytes the programmer will have.
;
; eg: BOUNDARY 5    ; position at byte #5 in page

__DASM__TOTAL_FREE_MEMORY	SET 0
.FREE_BYTES SET 0   
   MAC BOUNDARY
      REPEAT 256
         IF <. % {1} = 0
            MEXIT
         ELSE
.FREE_BYTES SET .FREE_BYTES + 1
            .byte $00
         ENDIF
      REPEND
__DASM__TOTAL_FREE_MEMORY SET __DASM__TOTAL_FREE_MEMORY + .FREE_BYTES
   ENDM


; EOF

Posted: Tue Mar 13, 2007 11:50 pm
by TMorita
BitWise wrote:
At the risk of complicating the discussion, if all you are trying to do is move blocks of data from a ROM area to video RAM for a splash screen then some absolute indexed loads and stores might be quicker and simpler.

For example if your splash screen is 1K of data, then ..

Code: Select all

 LDX #0
.Splash
 LDA SPLASH+$000,X
 STA SCREEN+$000,X
 LDA SPLASH+$100,X
 STA SCREEN+$100,X
 LDA SPLASH+$200,X
 STA SCREEN+$200,X
 LDA SPLASH+$300,X
 STA SCREEN+$300,X
 DEX
 BNE .Splash
.. would copy it from a SPLASH to SCREEN.

Edit: Having read a technical description of the VCS I can see the foolishness of my posting. 1K of RAM, in my dreams
The Atari VCS doesn't have video memory. It uses the CPU to generate the display.

Toshi

Posted: Tue Mar 13, 2007 11:54 pm
by TMorita
Mats wrote:
If you really want to run it on a real ATARI computer I can tell you that with:

Code: Select all

*= $FFFA 
 .word Start ; NMI 
 .word Start ; RESET 
 .word Start ; IRQ 
nothing will work, the ATARI will be completly dead!

The reset vector in $FFFC,$FFFD has to point to an adequate boot sequence and also the IRQ vector in $FFFE,$FFFF is certainly needed for hardware interrupts and has to point to completly different code then what you have following label "Start"!. If it at all should possible for a "user" to write his own programs for an ATARI computer there must be some "Application Program Interfaces" foreseen in the ATARI operating system. Otherwise you have to write the complete operating system yourself including management of screen, keyboard etc.
...
must contain a lot of stuff as your code (without this) is full of undefined labels/symbols. From where does this "include code" come and from where the idea that ATARI application programs can be written with this approach overwriting the original operating system resident in ROM? At least the top of the ROM is part of the operating system! Application programs have to reside in RAM/ROM not used by the operating system and control to the application program has to be given from the operating system in the way foreseen by the system designer!

For a Commodore this is done with BASIC command "SYS".
Umm. look at the header file. He's including "vcs.h" It's an Atari 2600, not a computer.

If it helps any, here's a picture of the Atari VCS and some info:

http://en.wikipedia.org/wiki/Atari_2600

It has no operating system resident in ROM. In fact, it has no built-in ROM. It doesn't have an API either, and no keyboard.

And yes, you do need to write a little OS for yourself, which isn't that difficult.

Toshi

Posted: Wed Mar 14, 2007 9:12 am
by Mats
TMorita writes:
Quote:
It has no operating system resident in ROM. In fact, it has no built-in ROM. It doesn't have an API either, and no keyboard.
OK, I do not know anything about ATARI, what I know something about are the 65** series chips and the Commodore/PET.

But as the ATARI has a 65** CPU (6507) it must also start the execution at the memory position it reads from address $FFFC,$FFFD. What kind of memory/circuitry is mapped to this address if it is not ROM? And as a minimum the start up sequence after power up must set the stack pointer (subroutines will be called) and set (program) the 6532 chip, for example setting the state of the bidirectional I/O ports!

I there no setup to be done for the video interface chip (replacing the screen of a normal computer)?

Is it really easier to interface "joy-sticks" with the 6532 chipt then to interface a keyboard? Is there for example no clock driven interrupts to sample the state of the joy-sticks?