Jump to content
Posted Fri Jun 27, 2003 8:34 AM
Posted Fri Jun 27, 2003 9:44 AM
Posted Fri Jun 27, 2003 9:56 AM
Posted Fri Jun 27, 2003 10:05 AM
Thanks I was just about to ask that one
The graphic certainly lives up to its namesake. It truly is an "Incredibly Good Timing Diagram."
The only thing I'd add to the diagram is an annotation or a footnote stating that a write to the WSYNC register halts the microprocessor until the TIA gets to time zero, the start of the Horizontal Blanking period. I was confused over this "obvious" fact for the longest time, thinking the microprocessor resumed execution immediately AFTER the 68 color clocks of Horizontal Blanking.
Posted Fri Jun 27, 2003 2:04 PM
Posted Fri Jun 27, 2003 4:22 PM
Why not eventually show how to move sprites, how to implement simple routines (enemies moving towards the player, collision checks) or more simply... show how to make a simple game and explain everything.Step by step
Posted Fri Jun 27, 2003 10:59 PM
Posted Sat Jun 28, 2003 9:44 AM
Posted Tue Jul 1, 2003 7:17 AM
Posted Tue Jul 1, 2003 9:07 AM
Posted Tue Jul 1, 2003 2:02 PM
Posted Tue Jul 1, 2003 5:59 PM
Posted Tue Jul 1, 2003 6:03 PM
Posted Tue Jul 1, 2003 9:00 PM
Posted Tue Jul 1, 2003 9:06 PM
As our knowledge of playfield manipulation increases, so does the desire to create more complex backgrounds. What are the best tools to design playfields? I think someone mentioned not so long ago the use of an Excel spreadsheet as a huge grid map. If there is any experienced homebrewer out there reading this: what have worked best for you?
Posted Wed Jul 2, 2003 1:40 PM
Dang it -- I just re-read Eckards post... the TIA appears to be latching a single pixel, not the entire value of PFx, right? That actually makes more sense when I look at it
Posted Thu Jul 3, 2003 10:00 AM
This is correct. If you change a playfield register while the third playfield pixel is currently being displayed, then the first three playfield pixels will be taken from the old value in the playfield register, and the last five playfield pixels will be taken from the new value.
Posted Thu Jul 3, 2003 1:36 PM
sta WSYNC nop nop nop nop nop nop nop nop nop nop sta COLUBKthen the background colour would change after the first TIA pixel has already been drawn, because the STA COLUBK would finisch it's write cycle at CPU cycle 23 (which is TIA cycle 69, which is one TIA cycle after the horizontal blank period).
Posted Sat Jul 5, 2003 9:42 AM
Thanks, that was the info I was looking for.
then the background colour would change after the first TIA pixel has already been drawn, because the STA COLUBK would finisch it's write cycle at CPU cycle 23 (which is TIA cycle 69, which is one TIA cycle after the horizontal blank period).
Posted Mon Jul 7, 2003 11:59 AM
Posted Mon Jul 7, 2003 1:38 PM
1) Is it possible to create the data tables in a separate text file and have it inserted into out program as an 'include "mypfdata.h"'?
2) I used PF data tables to draw my assymetrical playfields. The data is for every scanline in the visible kernel. The drawings I did have empty spaces at the top and bottom. This translates into a lot of zero byte entries, that takes valuable ROM space. I could shave off those data lines and adjust the kernel code accordingly. Is there is another way?
lda #10 nextblank: sta WSYNC dex bpl nextblank
ldy GraphicsData ;Get number of blank lines at top nextblankline1: sta WSYNC dey bne nextblankline1 ldx #0;Index of graphics data ldy GraphicsData+1 nextdrawline: sta WSYNC lda GraphicsData1,x sta PF0 lda GraphicsData2,x sta PF1 lda GraphicsData3,x sta PF2 nop ;Some NOPs in here, I'm not going to cycle count nop lda GraphicsData4,x sta PF0 lda GraphicsData5,x sta PF1 lda GraphicsData6,x sta PF2 inx dey bne nextdrawline ldy GraphicsData+2 ;Get number of blank lines at bottom nextblankline2: sta WSYNC dey bne nextblankline2 GraphicsData: .byte 20;10 blank lines at top .byte 150;150 lines of graphics .byte 22;22 blank lines at bottom GraphicsData1: .byte ;150 bytes of data for left PF0 GraphicsData2: .byte ;150 bytes of data for left PF1 GraphicsData3: .byte ;150 bytes of data for left PF2 GraphicsData4: .byte ;150 bytes of data for right PF0 GraphicsData5: .byte ;150 bytes of data for right PF1 GraphicsData6: .byte ;150 bytes of data for right PF2
Posted Mon Jul 7, 2003 10:15 PM
9 references to unknown symbols.
7 events requiring another assembler pass.
- Expression in mnemonic not resolved.
- Obscure reason - to be documented :)
--- Unresolved Symbol List
NO_ILLEGAL_OPCODES 0000 ???? (R )
PFData0A 10000 ???? (R )
PFData0B 100a7 ???? (R )
PFData1A 10037 ???? (R )
PFData1B 100df ???? (R )
PFData2A 1006f ???? (R )
PFData2B 10117 ???? (R )
--- 7 Unresolved Symbols
Posted Mon Jul 7, 2003 11:30 PM
When I place the include command (for PF data) at the beginning of the asm file, right after the macro.h and vcs.h includes, dasm gives me errors.
include File1 include File2 include File3
include File3 include File2 include File1
lda #$10 sta $80Is completely different from:
sta $80 lda #$10
TMP EQU $80 LDA TEMPis really just:
LDA $80because the label TEMP gets replaced by the $80. So too your INCLUDE statement gets replaced, right there, with the contents of the included file.
Posted Tue Jul 8, 2003 12:06 AM
Posted Tue Jul 8, 2003 1:35 AM
Very interesting. I was thinking about it in C terms, where the includes are always declared at the start of your code, but this is obviously not the case. Thanks for the help!
0 members, 0 guests, 0 anonymous users