Sheddy

looks fantastic

I thought I had Reset dealt with on AtariMax, but it turns out that Atari800WinPlus doesn't emulate something correctly on Reset, so it didn't actually work on real hardware. The OS checksum is a PITA. If you can get the checksum it should be possible to get Reset trapped though. I haven't managed to deal with that yet either. Like the guys are saying, I set the cart header vectors in every bank to point to a little stub of code which is also in every bank in the same place. That code switches to the "initialize" bank and jumps to the initialize routine. wastes cart space. Maybe not that useful, but you can use the couple of bytes where the jump is on all the other banks except the initialize one, for something else, of course.

I think what you need to know is that STIMER only resets Timers, but not when they count down. This only happens at the next POKEY clock tick rather than from the time STIMER is written (as most of us probably used to think): so for the 1.79MHz clock, STIMER does still give precise control to any cycle in the scanline - 1 clock tick evey cycle. 15KHz clock ticks only once per scanline so it is totally dependent on when the POKEY initialize is done and the 64KHz clock is more complicated as 4 ticks happen in 112 cycles rather than the 114 in a scanline, so the IRQ start position in a scanline is not easily controlled anyway after the 1st IRQ. As Rybags says, there might be another way to change the IRQ start reliably other than POKEY initialize, but as far as we know, nobody knows how to. It'll be useful to know if there is a way

this is very nice indeed. the speed is very impressive.

great work Bryan Still trying to make sure I understand why this works though actually I have to say everyone here has done great in pinning this sucker down and creating workarounds so quickly

Nice work Avery, that pins it down nicely. Don't think no. 2 will work. You'll just be jumping back and forth by 28 cycles. But the 64KHz clock still ticks at 2 cycles less every scanline, which is when the Timer is decremented. Unless the 64KHz clock itself is reset, the timer will hit the bad cycle eventually, I think. No. 1 might work if it can be to a precise cycle. The 64KHz clock will still already hit half the cycles in a scanline position in just one frame though. I don't think you can guarantee that an IRQ alway happens on an odd (or even) cycle though, (even with c64 methods?) which I think is what may be needed to avoid the bad cycle. Looks like this will be a lot of hassle. I think I'll stick with the 1.79MHz Timers on Space Harrier for now

Thanks! Yep, works on my machine. This pretty much proves that an NMI is ignored sometimes. s64.zip

Maybe Atariksi's one "bad" cycle could explain it? The 64KHz clock doesn't hit every possible cycle position on the scanline, only every other one, as it's 2 cycles different every scan line. It might be expected to be stable more often in that case though... BTW am using ATasm assembler, although you're probably better off using MADS and Phaeron's code. I must be about the only one left still using ATasm.

Possibly, but it still behaves badly even when not using WSYNC. Does the clock get stopped for other things? (Can't be DMA, lots of machines do that)

Seemingly knowledgeable resource about 6502 interrupts http://www.6502.org/tutorials/interrupts.html states NMIs have priority over IRQs in event of a clash. This doesn't seem to be so with Atari on what we've seen so far I still hope that there is a flaw in the code somewhere, but it isn't looking good

OK, I see what you mean now. (As an aside, according to Altirra emu author Avery Lee, when POKEY is initialized should relate to where that spot on the scanline is for 15KHz as there is nothing else that particularly syncs it) I don't understand how your code disables reset NMI yet, but it could well be related to the glitches I'm seeing. Yes, no hardcore optimizes have been done! purely example code. On the slower clocks when you hit STIMER doesn't matter much - it doesn't reset the base clock. The timer will count down only when the base clock changes. I didn't understand this until recently.

OK, I see what you mean now. (As an aside, according to Altirra emu author Avery Lee, when POKEY is initialized should relate to where that spot on the scanline is for 15KHz as there is nothing else that particularly syncs it) I don't understand how your code disables reset NMI yet, but it could well be related to the glitches I'm seeing. Yes, no hardcore optimizes have been done! purely example code.

ha, ha! sounds like you've been having fun. what are you up to now? (the interlace discovery is very cool BTW) interesting. no way should the sound affect when the DLI is serviced that much here's the code using the OS, which should also work on an 800. Programs in the zip as before. If anyone can try and see if the colours glitch and wobble with s64.xex on a real 800 it'd be much appreciated. ATARI=0 .include "equates.asm" ; variables *=$f0 sample .ds 2 sample_nybble .ds 1 sample_value .ds 1 sample_size .ds 1 table_index .ds 1 *=$02e0 .byte <run,>run ; initial run address ; main code *=$2000 run sei lda #0 sta NMIEN ; turn off NMI's sta POKMSK sta IRQEN ; disable IRQ's lda #<irq ; use immediate IRQ vector (no other OS IRQ's will happen) sta VIMIRQ lda #>irq sta VIMIRQ+1 lda #<dlist ; set up a display list sta SDLSTL lda #>dlist sta SDLSTH lda #<vbi ; set up an immediate VBI sta VVBLKI lda #>vbi sta VVBLKI+1 lda #<dli ; set up a DLI sta VDSLST lda #>dli sta VDSLST+1 lda #128+64 ; turn on NMI's - DLI's and VBI sta NMIEN cli ; enable IRQ's ldx #0 run1 txa asl a sta colour_table,x ; create a table of colours dex bne run1 ; initialize sample play irq play jsr init ; initialize the sample to play wait1 lda TRIG0 ; any other stuff can go here, but... beq wait1 ; just wait until fire button is pressed wait2 lda TRIG0 ; bne wait2 beq play ; end of main code init lda #<sample_start sta sample lda #>sample_start sta sample+1 lda #[>sample_end->sample_start] sta sample_size ; sample size in 256 byte pages lda #0 ; ~64KHz POKEY clock ; lda #1 ; ~15KHz POKEY clock sta AUDCTL lda #15 ; ~64KHz clock divided by 16 = ~4Khz ; lda #3 ; ~15KHz clock divided by 4 = ~4KHz sta AUDF1 ; in timer 1 lda #0 sta sample_nybble ; initialize nybble sta AUDC1 lda #1 sta IRQEN ; enable timer 1 sta POKMSK ldx #$18 stx sample_value ; an initial sample value (with volume only bit) lda #$70 wait3 cmp VCOUNT bne wait3 ; sync to a scanline (only relevant when 15KHz) stx STIMER ; start timers rts ; IRQ irq pha ; save a lda sample_value sta AUDC1 ; play sample ASAP to minimise DMA lag tya pha ; save y ldy #0 lda #1 sty IRQEN ; reset interrupt sta IRQEN ; re-enable only timer 1 eor sample_nybble ; switch between 0 and 1 (right and left nybble) sta sample_nybble beq irq1 lda (sample),y lsr a lsr a lsr a lsr a ; left nybble of sample bpl irq2 ; always branch irq1 lda (sample),y and #$0f ; right nybble of sample inc sample ; next lo byte of sample bne irq2 inc sample+1 ; next hi byte of sample dec sample_size ; check if at end of sample bne irq2 ; branch if not tya sta IRQEN ; end of sample - reset interrupt sta POKMSK beq irq3 ; always branch irq2 ora #$10 ; turn on volume only bit irq3 sta sample_value ; save sample to play next irq pla tay pla ; restore y and a rti ; DLI dli pha txa pha ldx table_index lda colour_table,x sta WSYNC sta COLBK inc table_index pla tax pla rti ; VBI vbi lda #0 sta table_index ; reset table index sta COLBK jmp SYSVBV ; 58463 - do system vertical blank processes ; display list *=$2400 dlist .byte $70,$70,$70 .byte $8D+$40,<screen_start,>screen_start .byte $8D,$D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D .byte $8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D .byte $8D,$D,$D,$8D,$8D,$D,$8D,$8D,$8D,$8D .byte $8D,$D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D .byte $8D,$D,$8D,$8D,$8D,$8D,$D,$8D,$8D,$8D .byte $8D,$D,$8D,$D,$8D,$8D,$D,$8D,$8D,$8D .byte $8D,$D,$8D,$8D,$8D,$D,$8D,$8D,$8D,$8D .byte $8D,$D,$8D,$8D,$D,$8D,$8D,$8D,$8D,$8D .byte $8D,$D,$8D,$D,$8D,$8D,$8D,$8D,$8D,$8D .byte $8D,$D,$D,$D,$D .byte $41,<dlist,>dlist ; sample data *=$2800 ; NB start on a 256 byte page boundary ; sample will stop playing at nearest page boundary if not a multiple of 256 bytes sample_start .incbin "raygun44.raw" ; 4KHz, 4-bit raw sample data sample_end ; screen data *=$8000 screen_start ; colour table *=$9000 colour_table samplesOS.zip

yes, that would be interesting. I did try the code with the OS and it has the same problem. I'll post it so someone can give it a go.

Sta STIMER will reset timers to zero for IRQ; what is initializing SKCTL accomplishing? True, he should base things on WSYNC so he knows the EXACT cycle when things start but his problem is the 64Khz mode since that's misaligned with scanline rate anyway. He needs to use some divisor (prime # or something) so that DLI triggerring and IRQ triggerring cycles never overlap assuming that's the entire issue here. yes, sorry, starting timers with the 64KHz clock at a certain point in a scanline is a red herring to the main concern. It should drift 2 cycles every scan line. The code is only in there because it was enough to help avoid the NMI's with the 15KHz and I just left it in there when changing the code to use the 64KHz clock. the reset SKCTL was just a test to see if polycounters made any difference to timers (if they do it is subtle) The main concern is why IRQ's can affect NMI's so badly? Keeping IRQ's from triggering at/near NMI's avoids the problem, but doesn't explain the problem. I don't think the IRQ latency can be it if the 15KHz works. If the NMI's aren't actually being ignored, maybe they are being delayed by the IRQ if they trigger at the same time? I'm still tending towards thinking Rybags is correct and this is a 6502C "feature". It is a shame if that is the case, as even with it getting interrupted by NMI's, sample playing with 64KHz clock sounds pretty good on real hardware, and only needs 1 channel. Why do you think the CPU based POKEY clock shouldn't work Atariksi? It can trigger at a specific point in the scan line as per the 15KHz clock. Or do you just mean the lax timing when starting the timer (no WSYNC etc.)?

I've been doing some experimenting, but I'm at a loss to understand what's going on here: Try the two programs in the attached zip file on a real XL/XE machine. press the joystick fire button! 1) s15.xex program. This works as expected. Nice colours down the screen and a raygun sound when firing 2) s64.xex program. Same, except the colours glitch and shift when firing. program 1 syncs an IRQ exactly to a scan line using the ~15KHz clock (using 1.79MHz also works). program 2 is using the ~64KHz Pokey clock. This doesn't sync exactly to a scan line (2 cycles out every line) But why is program 2 causing such a big problem? The DLI's are NMI's (Non Maskable) so should always run at the correct time regardless of what the IRQ is doing? They are obviously not though. Note that this behaviour doesn't show up on any emulators I've tried, even those that supposedly have cycle exact POKEY emulation. But it happens on my PAL 800XL and 130XE. I thought I was beginning to understand the POKEY timers, but now I'm not sure Maybe if an IRQ and NMI happen at exactly the same time the NMI doesn't get done? (I'd always heard to the contrary though) Here's the code. Yes, I know it can be made faster, but it is only an example. Unfortunately I have passed the 64KHz code off as a good way to do sample playback before, but it's not much good if it doesn't work on real hardware. ; IRQ sample playback ; NB XL/XE only ATARI=0 .include "equates.asm" ; variables *=$f0 sample .ds 2 sample_nybble .ds 1 sample_value .ds 1 sample_size .ds 1 table_index .ds 1 trigger .ds 1 *=$02e0 .byte <run,>run ; initial run address ; main code *=$2000 run lda #0 sta NMIEN ; turn off NMI's sei sta IRQEN ; disable IRQ's lda #128+32+16+2 ; bit 7 on - ram at $5000, bits 4&5 on - 130XE compatible sta PORTB ; bit 1 on - disable os & rom, bit 0 off - disable basic lda #<nmi ; setup custom NMI handler sta $fffa lda #>nmi sta $fffa+1 lda #<irq ; setup custom IRQ handler sta $fffe lda #>irq sta $fffe+1 lda #<dlist ; set up a display list sta DLISTL lda #>dlist sta DLISTH lda #2+32 ; enable normal width screen+screen dma sta DMACTL lda #128+64 sta NMIEN ; turn on NMI's - DLI's and VBI cli ; enable IRQ's ldx #0 run1 txa asl a sta colour_table,x ; create a table of colours dex bne run1 ; initialize sample play irq play jsr init ; initialize the sample to play wait1 lda TRIG0 ; any other stuff can go here, but... beq wait1 ; just wait until fire button is pressed wait2 lda TRIG0 bne wait2 beq play ; end of main code init sei lda #<sample_start sta sample lda #>sample_start sta sample+1 lda #[>sample_end->sample_start] sta sample_size ; sample size in 256 byte pages lda #0 ;1 ; 0=POKEY 64KHz, 1=15KHz sta AUDCTL lda #15 ;3 ; ~64KHz clock 16 = ~4Khz timer, ~15KHz clock 4 = ~4KHz sta AUDF1 ; in timer 1 lda #$f0 ; test - no polycounters + volume only sta AUDC1 lda #1 sta IRQEN ; enable timer 1 lda #0 sta sample_nybble ; initialize nybble ldx #$f8 stx sample_value ; an initial sample value (with no polycounters + volume only bit) lda #$70 wait3 cmp VCOUNT bne wait3 ; sync to a scanline lda #0 sta SKCTL lda #3 sta SKCTL ; test - reset pokey and polycounters sta STIMER ; start timers cli rts ; IRQ irq pha ; save a lda sample_value sta AUDC1 ; play sample ASAP to minimise DMA lag tya pha ; save y ldy #0 sty IRQEN ; reset interrupt lda #1 sta IRQEN ; re-enable only timer 1 eor sample_nybble ; switch between 0 and 1 (right and left nybble) sta sample_nybble beq irq1 lda (sample),y lsr a lsr a lsr a lsr a ; left nybble of sample bpl irq2 ; always branch irq1 lda (sample),y and #$0f ; right nybble of sample inc sample ; next lo byte of sample bne irq2 inc sample+1 ; next hi byte of sample dec sample_size ; check if at end of sample bne irq2 ; branch if not tya sta IRQEN ; end of sample - reset interrupt beq irq3 ; always branch irq2 ora #$f0 ; no polycounters+volume only bit irq3 sta sample_value ; save sample to play next irq pla tay pla ; restore y and a rti ; NMI nmi pha bit NMIST ; check for cause of interrupt bvs vbi ; branch if a VBI ; DLI dli txa pha ldx table_index lda colour_table,x sta WSYNC sta COLBK inc table_index pla tax pla rti ; VBI ; critical vbi vbi sta NMIRES ; reset interrupt txa pha ; save x tya pha lda #0 sta table_index ; reset table index sta COLBK ; tsx ; lda $104,x ; and #$04 ; bne vbiexit ; exit VBI if VBI interrupted an IRQ ; cli ; allow IRQ to interrupt from now on ; deferred VBI here vbiexit pla tay pla tax pla ; restore x and a rti ; display list with some random DLIS *=$2400 dlist .byte $70,$70,$70 .byte $8D+$40,<screen_start,>screen_start .byte $8D,$D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D .byte $8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D .byte $8D,$D,$D,$8D,$8D,$D,$8D,$8D,$8D,$8D .byte $8D,$D,$8D,$8D,$8D,$8D,$8D,$8D,$8D,$8D .byte $8D,$D,$8D,$8D,$8D,$8D,$D,$8D,$8D,$8D .byte $8D,$D,$8D,$D,$8D,$8D,$D,$8D,$8D,$8D .byte $8D,$D,$8D,$8D,$8D,$D,$8D,$8D,$8D,$8D .byte $8D,$D,$8D,$8D,$D,$8D,$8D,$8D,$8D,$8D .byte $8D,$D,$8D,$D,$8D,$8D,$8D,$8D,$8D,$8D .byte $8D,$D,$D,$D,$D .byte $41,<dlist,>dlist ; sample data *=$2800 ; NB start on a 256 byte page boundary ; sample will stop playing at nearest page boundary if not a multiple of 256 bytes sample_start .incbin "raygun44.raw" ; 4KHz, 4-bit raw sample data sample_end ; screen data *=$8000 screen_start ; colour table *=$9000 colour_table samples.zip

And the TESTER file looks something like this: And all I manage to do is crash the emulator! Any ideas what I'm doing wong? Ah, OK, that isn't a binary file. You need to use .INCLUDE rather than .INCBIN However it should have .BYTE at beginning of lines. Export to MAC/65 should make it do that. Decimal values will work fine, doen't have to be Hex for ATasm. Maybe something else is causing the crash. Maybe try and manually enter a few of the .BYTE lines and see if you still get crashes then

Hi Avram, you can include the binary file in ATasm by using .incbin

no point now, although the SRAM in it is nice. AtariMax 8Mbit seems pretty well suited though, as people can download games to it themselves. No other versions apart from cart are really viable due to how the game works.

I like what you're doing with Beyond Evil But I think a race to finish first will not be so interesting - No tortoise and hare, but tortoise and tortoise @Miker, I haven't clear finish date, but I want to finally finish it this year

Thanks! if it's any consolation, I'm losing my mind too about getting this done with. This is a weird coincidence - I post an update on my site after almost a year, and this thread gets resurrected just a few hours before that. The graphics and patterns take a while to do, but I'm doing my best to get things finished. Things should progress better soon as the graphics and patterns get reused a lot throughout the game.

hello... you are comparing 64k machine with 320k... so then I can use RAM expansion aswell, and REU (ram expansion unit) for the c64 has.. DMA.. and the c64 can display colors... without interlace... I am seeing a whining emkay... or.. if I wouldnt use the DMA on the REU, then.. as I dont need interlace to add colors, I can draw the scenery twice as fast... only one bitmap to update... c64 will be faster even this way I can also see where the C64 would have issues with game port like Space Harrier, or anything that is going have lots of moving objects on the screen. Even if you use the C64 color map & sprites, you're still limited by the 1Mhz CPU speed. Coding something like this has to be real efficient. let me explain: - a8 space harrier uses 320k, c64 one uses 64k (and 20 years earlier) 320k allows to precalculate many many many things. - if I use the factory default ram expansion to equal the rams, then I will also have an extra hw, since its built in, (DMA) which copyes bytes at 1byte/cycle speed. pretty handy to draw software sprites. - a8 version uses interlace -> it fills 2 bitmap instead of just one. c64 can add colors using just 1 bitmap = 2x faster than a8 method- > will be faster. (1.7/2 vs 1 mhz) without DMA logic. only demo version of Space Harrier needs 128K RAM, current cart version needs 64K RAM. (Cart is 1MB though!)

Yea, it's def not easy to reproduce that's for sure but I hasten to add that there is plenty more that can be achived without a doubt on the Atari. Crownland is a step in the right direction, the first of a new generation finally pushing things outside of the box as you are too with your exceptional project Chris. I wish there were more coders active on the Atari scene. We need less talk and more action. Now that bj is complete, we have been working on a new game project, many months of work ahead but watch this space. I think what you have done with Bomb Jack is amazing, but it does just have static screens and is an easy game for the C64 to do (and could be polished a lot more on the C64 as well, as TMR says) I hope you and Emkay are right about Crownland being just the start, and am already looking forward to your next project!

...and the Atari is much more restricted than the C64 at 160*200*16. Returning to the original question of the topic, as far as games go, the vast majority of games are going to look better on the C64 because it can have more colours and resolution per scan line than the Atari, and it has much better and more useful sprites. Sure, you can compensate for some of these limitations on the Atari with interrupts and CPU (which C64 also can do of course), but you can't do them ALL at the same time - CPU and interrupts waste so many more cycles compared to the video chip DMA. Crownland is probably the best looking platformer so far on the Atari. But it is specially designed for the Atari and limited to a few enemies. Other well known platform games won't work as well as a C64 version could easily be, or won't be as colourful, (or both!) - however skilled the programmer. We shouldn't compare to poorly programmed C64 games either. (I do love my Atari and I'd love someone to prove me wrong, but I don't see it happening).

Great work Allas, this looks fantastic! I was thinking about doing a "bashing" game like this a while ago, but this is much better than what I had in mind.