Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Sdw

Members
 View Profile  See their activity

  • Content Count

    86

  • Joined

  • Last visited

Posts posted by Sdw

  4. Posted

    Well, the dlist switching code I posted works, so I guess I have the OS disabled. I always start my program with a SEI, so I guess this OS stuff you are talking about is set up as an interrupt. I want none of that, all CPU cycles for my code please! :)

     

    But back on topic - if going wihtout the $41 instruction, how do I tell the display list it is "done", so that it doesn't continue trying to run crap code that is in memory after my last display lines?

    Also, when can I do the $d402/$d403 update? Is it safe as soon as VCOUNT hits 0 to update it, and it will not take effect until next frame?

  5. Posted

    Anyone have some good "best practice" on how to handle double buffering of display lists?

    It's easy to set up a system that switches between display lists:

     

    dlist1:
.byte $70,$70,$70
lineptrs:
...(stuff that I change dynamically goes here)
.byte $41,<dlist2,>dlist2


dlist2:
.byte $70,$70,$70
lineptrs:
...(stuff that I change dynamically goes here)
.byte $41,<dlist1,>dlist1

     

    This will switch between dlist1 and dlist2 every frame.

    However, how do I sync my main code so that I'm updating the code that is NOT currently being displayed?

     

    lda #0
!wait:
cmp VCOUNT
bne !wait-
..Here i need to figure out if dlist1 or dlist2 is in use, so I can start updating the other!

     

    Or can I somehow avoid using the $41 "jump" instruction in the display list, and control it manually from my main code instead? Which is the best solution?

  6. Posted · Edited by Sdw

    Interesting take on the kefrens bar Heaven, mine look a bit more "traditional". Hopefully people appreciate the classics as well! :)

    I will refrain from looking at the source code, to avoid any accusations of code-stealing! ;)

     

    Regarding my own kefrens, think I got it sorted out now, looks OK to my eye both in Altirra and on my 130XE.

    Looking at the Altirra Hardware Reference Manual, Iif I read it correctly, the first graphics fetch happens on cycle 20, and with my new code, I have all updating done by cycle 16, so all should be good.

     

    -edit-

    oh, quick additional question:

     

    How many lines of screen data is it possible to display?

    At the moment I have 208 lines, dlist looks like this:

     

    $70

    208 lines of $4e,<scr,>scr

    $41

     

    I guess 216 should be possible as well, but it seems like I can only get extra lines "upwards", is it possible to have more screen estate "downwards"?

  7. Posted

    OK, thanks all, it seems that it is a bit more complex than I first thought.

    I have been testing in Atari800win and thought it looked good when pausing and inspecting the graphics, and it looks OK to the eye on my Atari 130XE, but of course there is movement in the effect, so there could be bugs that I'm not noticing.

     

    Hmm.. Kefren bars effect maybe? :)

     

    Yes, that's correct. Good deduction! :)

  8. Posted · Edited by Sdw

    Say I want to update the graphics for a line currently being displayed, for example like this:

     

    I have a standard 160x192 bitmap mode.

    My DLIST repeats the same address on all lines, so I keep displaying the same 40 bytes over and over.

    I then have code that looks a little something like this

    1) Wait for the first line

    2) STA WSYNC

    3) Update some of the 40 bytes

    4) Repeat 1-3 192 times

    (yeah, I know I could probably do this with DLI stuff, but I chose the simple, buisy-wait-loop approach for now)

     

    How does the graphics fetching work? Will all the 40 bytes for the line have been fetched before I start modifying it, ie. my modify is safe, or will t continuously fetch data, meaning that some of my modifications will be shown mid-scanline?

  9. Posted

    Thank you all, great info!

     

    Xuel's little example was just enough to get me going (once I figured out what the strange assembler-specific macros were doing! :D)

    I also managed to get some different text modes up and running, without problem. Now I have a nice little dither-plasma going! ;)

     

    Regarding Xuel's example though - what is the reason to put the screen at $3010, and not an even address (like $3000 or so)?

     

    Also, the list Synthpopalooza contained many graphics modes, however, I'm sure I've heard of additional modes like 80x192 with 16 lumas of the same color for example, any info on how to set those up?

  10. Posted

    Coming from primarily from Commodore systems (c64 for example) the Atari 8 bit way of dealing with graphics modes has me scratching my head a bit.

    On the C64 you simply use some registers to set up what mode you want (textmode/gfx and hires/multicolor) and then some others to point where in memory your bitmap data (or character screen/font definition) is, and that's pretty much it.

     

    I've found the following memory map of the Atari CTIA/GTIA

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

     

    However, there are no registers dealing with video modes at all as far as I can see.

    I have read enough to understand that I instead need to use display lists to set up my video mode, however I can't find any good, clear examples.

    Can anyone provide a simple example on how to set up the different video modes (pure to-the-metal-assembly preferred, don't want to use any system/Basic routines)

  11. Posted

    Forgot to answer this one earlier...

     

    Was the demo done in PAL to get better graphics or just because the televisions used in your area?

     

    The PAL choice is primarily due to the fact that I live in PAL-land, have PAL 2600s and that most demoscene-interested people are in PAL-territory.

    But yeah, another bonus is that you actually get quite a lot more processing time per frame compared to NTSC. I don't think it matters in this case though. Now I haven't checked it properly, but I think all of the stuff I do here could be done on NTSC timing as well.

  12. Posted · Edited by Sdw

    Thanks for all the nice comments/feedback guys, I appreciate it.

     

    Oh, and cool to see Ed Fries getting into the demoscene! :)

     

    Are you doing that trick to double the rez?

     

    Not sure what you mean here by double res trick?

    If you are talking about the "temporal subpixel"-effect I used in an earlier demo (Sv2k11 invitro) then no, it isn't used in this demo.

  16. Posted

    While I agree that you should of course test on real hardware, the error you noticed here could also have been detected in Stella. You just need to turn on PAL color-loss emulation. Basically, PAL ROMs that run at an odd number of scanlines causes the palette to switch to black&white. And Stella correctly deals with that if you tell it to.

     

    Thanks, wasn't aware of that. Found the option now and turned it on!

  17. Posted

    I'd recommend testing on real hardware, get a Harmony cart and a cheap 2600jr or something!

    I've had a few instances where things looked fine in emulator but not on the real deal. Most recently I had some code that dropped from 312 to 311 lines sometimes, looked fine in emulator, but on real HW the frames with the dropped line turned the picture black-and-white for some reason!

     

    Also, colours of course look different. One thing I've noticed is that some luma transitions gives a horizontal dark stripe, an artifact I've actually seen on the Atari 130XE as well.

     

    If you need help testing before you get real HW, of course I'd be happy to help.

  21. Posted

    I've been experimenting with different bankswitching methods, and looking into to those that include extra RAM as well.

    One thing I've noticed is that RAM always is split into separate read/write area, for example the 256 byte area you get with CBS-cart has read from $1100-$11ff and write from $1000-$10ff.

    This seems to wase adress-space, as 512 locations are used to access 256 bytes.

    I'm guessing this split with separate read/write areas is due to some kind of limitation to how the 6507 adresses memory?

     

    Another thing I've been thinking about, if I understand things correctly, 6507 only has 12-bit adressing, meaning it can adress $000-$fff.

    However, how does it differentiate when adressing for example the $80-$ff area that it should go to cartridge or to built in 128-byte RAM?

  22. Posted

    Since my testprogram didn't use the extra RAM yet, I actually tried and renamed it to .3F instead, and then it worked on my Harmony.

    So a 32k ROM with 3F bankswitching seems to work fine.

     

    However, when running in 3E mode, it doesn't work. I tried dropping the size by removing two banks, giving me a 28k ROM, but it still didn't work.

     

    I guess now we need someone with real insight to tell us how the 3E support in Harmony works!

  23. Posted

    3E seems like a good choice. Frmo what I've found while searching threads here on the forum, Harmony should be able to handle 32kb ROM and 4kb RAM with 3E, which would be great!

    However, I'm having a hard time getting it to work.

    I've assembled a test-program, at the moment haven't even started on getting the RAM ($3e-writes) to work, just the normal $3f ROM-bankswitching.

    In Stella, it fails if I just run it as a .bin (since it autodetects the wrong bankswitching) but if I manually set it to 3E using the "Game properties", it works as expected.

     

    On my real 2600 with Harmony cart however, it doesn't work. With BIN extension, it fails to run at all, (diagonal lines) and with the extension as .3E it starts, but seems to set garbage in the registers (I get strange background color and a tone) and it locks up.

     

    Here's my example:

     

    .import source "vcs_base40.inc"

.var FRAME=$80
.var BANK=$81

.pc = $0000 "Bank1"
.fill    2048,$00

.pc = * "Bank2"
.fill    2048,$02

.pc = * "Bank3"
.fill    2048,$04

.pc = * "Bank4"
.fill    2048,$06

.pc = * "Bank5"
.fill    2048,$08

.pc = * "Bank6"
.fill    2048,$0a

.pc = * "Bank7"
.fill    2048,$0c

.pc = * "Bank8"
.fill    2048,$0e

.pc = * "Bank9"
.fill    2048,$0c

.pc = * "Bank10"
.fill    2048,$0a

.pc = * "Bank11"
.fill    2048,$08

.pc = * "Bank12"
.fill    2048,$06

.pc = * "Bank13"
.fill    2048,$04

.pc = * "Bank14"
.fill    2048,$02

.pc = * "Bank15"
.fill    2048,$64

.pc = * "Bank16"
.pseudopc $f800
{
   lda #$00
   sta $3f    
start:
   ldx #$00
   txa
clear:
  dex
  txs
  pha
  bne clear
frameloop:
   // Start of vertical blank processing
   lda #0
   sta VBLANK
   lda #2
   sta VSYNC
   lda #$00
   sta COLUBK

    // 3 scanlines of VSYNCH signal...
  sta WSYNC
   sta WSYNC
   sta WSYNC

  lda #0
   sta VSYNC		  

   // 37 scanlines of vertical blank...
   lda #127+44
   sta TIM64T
   
   // Do stuff
           
!wait:    
   lda INTIM
   and #$80
   bne !wait-
   sta WSYNC
           
  // 242 scanlines of picture...
  ldy #242
!loop:    
   sta WSYNC
   lda $f000,y
   sta COLUBK
   dey		         
   bne !loop-             

   // end of screen - enter blanking
  lda #%01000010
   sta VBLANK	      	     

   // 30 scanlines of overscan...
   lda #127+36
   sta TIM64T    
   
   inc FRAME    
   lda FRAME
   and #$0f
   bne !skip+
   inc BANK
   lda BANK
   cmp #$0f
   bne doit
   lda #$00
   sta BANK
doit:    
   sta $3f
!skip:    
       
   
!wait:    
   lda INTIM
   and #$80
   bne !wait-
   sta WSYNC

  jmp frameloop    
   rts   
   
}

.pc =$7ffa "Vectors"
   .word start // NMI
   .word start // RESET
   .word start // IRQ

     

    And here's the layout of the assembled binary

    Memory Map
----------
$0000-$07ff Bank1
$0800-$0fff Bank2
$1000-$17ff Bank3
$1800-$1fff Bank4
$2000-$27ff Bank5
$2800-$2fff Bank6
$3000-$37ff Bank7
$3800-$3fff Bank8
$4000-$47ff Bank9
$4800-$4fff Bank10
$5000-$57ff Bank11
$5800-$5fff Bank12
$6000-$67ff Bank13
$6800-$6fff Bank14
$7000-$77ff Bank15
$7800-$7867 Bank16
$7ffa-$7fff Vectors

     

    The program *should* flash the screen in all the grey colors (with color data fetched from the different banks) and then finally in red before restarting. (this is all PAL btw)

     

    Here's the compiled binary:

    http://ag1976.com/tmp/3e.bin

     

    What have I done wrong?

  25. Posted · Edited by Sdw

    If I understand things correctly, the Harmony has 32kb of space for the cartridge ROM and 8kb of RAM.

    However, there is no bankswitching method that uses all of these.

    Which of the exisiting ones gives the best combination of ROM and RAM?

    Looking at some charts of 2600 bankswitching methods, I'm guessing the E7/M-Network Bankswitch which seems to give access to 14kb of ROM and 2kb of RAM.

     

    I've also read in the manual that custom bankswitching methods could be implemented in the Harmony. Is it theoretically possible to create some kind of super-bankswitch-method that gives access to the full 32kb ROM+8kb RAM?

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...