Sdw

SV2k13 is indeed my target date, hopefully I'll have at least something to release by then!

Thanks bob_er, that was actually going to be my very next question - how to gain access to all the RAM!

Thanks, setting $d402/$d403 manually after the VCOUNT wait worked like a charm. Silky smooth 50fps double buffering.. Mmmmm....

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?

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?

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"?

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. Yes, that's correct. Good deduction!

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?

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! ) 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?

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)

Forgot to answer this one earlier... 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.

Thanks for all the nice comments/feedback guys, I appreciate it. Oh, and cool to see Ed Fries getting into the demoscene! 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.

Here's my new demo for 2600 (PAL) http://ag1976.com/files/Noice-Liquid_Candy.zip And here's a Youtube video if you are too lazy to download the binary!

Latest version ran perfectly on my PAL jr. Great seeing it actually running on real HW, the alternating line-display actually suits vector graphics very well!

Wow, this is some seriously impressive stuff! Is there any binaries of the fixed versions (PAL) released? I get the bankswitch-bug-bars that Glenn mentioned when I run them on my 2600Jr with a Harmony.

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

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.

cruzer: I've posted some questions on CSDb now, let's see what comes of it. Btw. hearing that you are gearing up to releasing a demo makes me wonder if I should rush out some of the routines I'm working on, so I don't get beat to it!

I use UltraEdit for editing. Kick Assembler for assembling (btw. cruzer, maybe we could convince Slammer to add some tweaks to better support writing code that's supposed to go in different banks!) Command-line window and bat file for compiling Stella for testing

Thanks all for the info, interesting stuff!

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?

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!

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?

Thanks, that's good info! But what if I want to have "normally" accessible RAM, that is RAM that I can actually put code in, access and modify with normal instructions (I like selfmodifying code ), the E7 is still my best bet?

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?