6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Oct 06, 2024 2:42 am

All times are UTC




Post new topic Reply to topic  [ 56 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
 Post subject:
PostPosted: Mon Mar 12, 2007 6:31 pm 
Offline

Joined: Sun Mar 04, 2007 1:47 am
Posts: 19
Mats,
My mistake - i wrote that from memory and got it wrong. Here is the real code:
Code:
  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:
  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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Mar 12, 2007 9:01 pm 
Offline

Joined: Sun Aug 24, 2003 7:17 pm
Posts: 111
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!


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Mar 12, 2007 9:18 pm 
Offline

Joined: Sun Mar 04, 2007 1:47 am
Posts: 19
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:
processor 6502
include vcs.h
SEG.U variables
ORG $80


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Mar 12, 2007 10:01 pm 
Online
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8521
Location: Southern California
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.


Top
 Profile  
Reply with quote  
 Post subject: Oh no...
PostPosted: Mon Mar 12, 2007 11:31 pm 
Offline

Joined: Sun Mar 04, 2007 1:47 am
Posts: 19
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:
  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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Mar 13, 2007 6:47 am 
Offline

Joined: Sun Aug 24, 2003 7:17 pm
Posts: 111
Why do you say that the Kowalski simulator does not like your syntax? I just tested

Code:
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!


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Mar 13, 2007 6:58 am 
Offline

Joined: Sun Aug 24, 2003 7:17 pm
Posts: 111
..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!


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Mar 13, 2007 10:13 am 
Offline

Joined: Sun Aug 24, 2003 7:17 pm
Posts: 111
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:
;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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Mar 13, 2007 1:23 pm 
Offline

Joined: Sun Mar 04, 2007 1:47 am
Posts: 19
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Mar 13, 2007 4:14 pm 
Offline
User avatar

Joined: Tue Mar 02, 2004 8:55 am
Posts: 996
Location: Berkshire, UK
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:
 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

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs


Last edited by BitWise on Tue Mar 13, 2007 9:18 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Mar 13, 2007 4:44 pm 
Offline

Joined: Sun Aug 24, 2003 7:17 pm
Posts: 111
If you really want to run it on a real ATARI computer I can tell you that with:

Code:
*= $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:
 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".


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Mar 13, 2007 5:28 pm 
Offline

Joined: Sun Mar 04, 2007 1:47 am
Posts: 19
Mats wrote:
If you really want to run it on a real ATARI computer I can tell you that with:

Code:
*= $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:
 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:
*= $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:
; 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:
; 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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Mar 13, 2007 11:50 pm 
Offline

Joined: Sun Sep 15, 2002 10:42 pm
Posts: 214
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:
 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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Mar 13, 2007 11:54 pm 
Offline

Joined: Sun Sep 15, 2002 10:42 pm
Posts: 214
Mats wrote:
If you really want to run it on a real ATARI computer I can tell you that with:

Code:
*= $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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Mar 14, 2007 9:12 am 
Offline

Joined: Sun Aug 24, 2003 7:17 pm
Posts: 111
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?


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 56 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 21 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: