PM 1.5

[PM 1.5]

looks fantastic

[Trapping Reset for AtariMax cart]

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.

[How can POKEY IRQ Timers mess up NMI timing?]

One question.. is doing:

 

lda #0

sta SKCTL

 

.. wait loop ..

 

lda #3

sta SKCTL

 

the only way to change the IRQ start at different cycles in a scanline ??

 

independent of the clock (15, 64 or 1.79)? and STIMER doesn't have any role in that??

 

thanks..

 

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

[Project "M", Stage 1]

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

[How can POKEY IRQ Timers mess up NMI timing?]

Here is a solution that works without any extra mucking about in the interrupt code.

 

AUDF is changed from 15 to 14, which creates a repeating interrupt pattern that can avoid the NMI (but the pitch is a little higher). The timer is aligned with WSYNC and the sample plays without issues.

 

There are only changes to the init routine (marked with asterisks).

 

EDIT: I revised the attachment. The first one had the wrong source file.

 

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

[How can POKEY IRQ Timers mess up NMI timing?]

Nice work Avery, that pins it down nicely.

 

 

Looks like Antic can't help then... for a moment I thought "Hey, turn on missile DMA" but that doesn't work.

 

I also tried various stuff to try and sync STIMER so that it was aligned with the /28 clock.

That's useless though because it will spoil stuff like chords or near notes in phasing/flanging arrangements.

 

But, I've come up with 2 possible solutions, possibly both might have to be used together:

 

1. During VBlank, momentarily set AUDF1 to 00 and change AUDCTL to put Voice 1 in 1.79 MHz mode.

Wait a little bit, then put the normal Timer constant back into AUDF1 and set AUDCTL back so Voice 1 is in 64 Khz mode again.

 

2. In our Timer routine, altenate AUDF1 between 2 adjacent frequencies... in theory that should cause the timing jitter to just alternate between 2 differing values.

 

In theory, by going to 1.79 Mhz mode, and setting AUDF1 to 00 we should accomplish something similar to using STIMER.

We reset voice 1 to a known state, although given that the docs say there's 4 cycles overhead for an AUDF reload in 1.79 MHz mode, that might be an acceptable solution.

 

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

[How can POKEY IRQ Timers mess up NMI timing?]

Chris,

 

Try this for me:

 

1. Add a sta NMIRES to the end of DLI code:

 

dli

pha
txa
pha
ldx table_index
lda colour_table,x
sta WSYNC
sta COLBK
sta sample_value
inc table_index
pla
tax
pla
sta NMIRES	
rti

 

Then make the beginning of the irq look like this:

 

irq
pha	; save a
tya
pha
lda NMIST
nop
and NMIST;2 checks!
bpl continue;skip if not set

;insert a virtual DLI here
ldy table_index
lda colour_table,y
sta WSYNC
sta COLBK
inc table_index

continue

lda sample_value
sta AUDC1; play sample ASAP to minimise DMA lag
tya.....
......and so on....

 

That worked for me provided I put the NOP spacer in between the first and second read of NMIST.

 

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

s64.zip

[How can POKEY IRQ Timers mess up NMI timing?]

I've been messing around with it and it occasionally becomes stable, but I can't tell why.

 

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.

[How can POKEY IRQ Timers mess up NMI timing?]

Here's what I'm guessing at this point:

 

The Atari is about the only machine that freezes the clock to stop the CPU. Most other machines have a different scheme. Perhaps if an NMI and IRQ both happen while the clock is stopped, the CPU is unable to sort them out like it normally would. I haven't looked at the datasheet in a while, but perhaps the timing diagrams might be of assistance.

 

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)

[How can POKEY IRQ Timers mess up NMI timing?]

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

[How can POKEY IRQ Timers mess up NMI timing?]

The CPU based clock (1.79Mhz) works as long as it's phase shifted away from the DLI. The 15Khz cannot be phase shifted from the tests that I did. Even if you delay STIMER, the 15Khz interrupt seems to occur at exact same spot on the scanline. Enclosed below is the IRQ-based code that locks out the System Reset NMI on Atari 400/800-- but it doesn't work if I use 15Khz timer regardless of phase shift. By the way, I see you are optimizing code by writing directly to ROM vector area, but then you mine as well do STA ZP1 and STX ZP2 rather than to PHA, TXA/PHA and reverse for exiting from DLI.

 

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.

[How can POKEY IRQ Timers mess up NMI timing?]

The CPU based clock (1.79Mhz) works as long as it's phase shifted away from the DLI. The 15Khz cannot be phase shifted from the tests that I did. Even if you delay STIMER, the 15Khz interrupt seems to occur at exact same spot on the scanline. Enclosed below is the IRQ-based code that locks out the System Reset NMI on Atari 400/800-- but it doesn't work if I use 15Khz timer regardless of phase shift. By the way, I see you are optimizing code by writing directly to ROM vector area, but then you mine as well do STA ZP1 and STX ZP2 rather than to PHA, TXA/PHA and reverse for exiting from DLI.

 

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.

[How can POKEY IRQ Timers mess up NMI timing?]

I'd get my 'scope onto the NMI line and see what's going on internally, but I've virtually trashed one machine in the last 24 hours... don't want to risk another just yet.

 

ha, ha! sounds like you've been having fun. what are you up to now? (the interlace discovery is very cool BTW)

 

I took out the sta WSYNC to see where the DLI was being serviced. It's about 1/3 of the way across (well, that's where the COLBK change is)- unless you're playing sound- then it scoots around.

 

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

[How can POKEY IRQ Timers mess up NMI timing?]

I wonder what it would do on an 800 without a 6502C (if the PORTB stuff was removed).

 

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.

[How can POKEY IRQ Timers mess up NMI timing?]

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

 

That's not an exact align there for the timer, it could drift a couple of cycles either way.

 

I'd change it a bit. Put the reset SKCTL and poly stuff before the wait loop. Do a STA WSYNC immediately before the STA STIMER. That should make the IRQ occur earlier in the scanline, might be enough to stop if interfering with the NMIs.

 

If that don't work, I'd try different delay loops after the WSYNC until you hit the sweet spot.

 

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

[How can POKEY IRQ Timers mess up NMI timing?]

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

[Envision question]

Well, no luck so far. At the beginning of my code I link to a test character set (gotten by Exporting from Envision PC) with the following:

 

*=$800

.INCBIN TESTER

 

And the TESTER file looks something like this:

 

.BY 0,0,0,0,0,0,0,0

.BY 0,24,24,24,24,0,24,0

.BY 0,102,102,102,0,0,0,0

.BY 0,102,255,102,102,255,102,0

 

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

[Envision question]

Envision 8bits? press the "W" to "write data statements" and select MAC65 format.. I don't remember if you can save the font and the map to different files..

 

Envision PC? you use "E" to export the font and "S" to save a binary map

 

if you already have the data in decimal format I think that you should be able to use it in Atasm..

if you were using MADS you could just include the binary file

 

NRV

 

Hi Avram,

 

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

[Space Harrier, OM&TS, Turrican ....]

btw. Sheddy...are you planning to use the Corina cart?

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.

[Space Harrier, OM&TS, Turrican ....]

Sheddy...

 

stage 6,7 ROCK!!! don't loose the faith and your pation... and don't get attacked by other people...they can be so demanding...

 

let see who is faster in finishing... me with Beyond Evil or you...

 

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

[Space Harrier, OM&TS, Turrican ....]

http://sheddyshack.co.uk/

 

We are all loosing our minds with this one, it is so great and so seemingly near completion. On knees pleading Sheddy please Please PLEASE...... please?

 

I have loved playing the individual levels and demo! This is better than most released games!

 

Space Harrier on the XE rules

 

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.

[Atari v Commodore]

Start to make a C64 version of Space Harrier with a real Gameplay resolution of 160x100, and see the C64 whining.

Using graphics? Too slow. It would end in a "Mood" resolution of 40x50

Using multiple Sprites? This would slowdown the cpu to effective 500-600MHz. Not much for game calculations, where the Atari has around 1.5MHz left. Oops... this made my calculations wrong. The Gain would be up to 300% then

 

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

[Atari v Commodore]

Sheddy. 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!) ... (I do love my Atari and I'd love someone to prove me wrong, but I don't see it happening

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!

[Atari v Commodore]

Both Atari and C64 mode 160*200*16 is restricted. A non-restricted mode would be 160*200*16 where any arbitrary color can be at any point. Doesn't making your 160*200 and 320*200 less restricted require CPU overhead? I would say that c64 rippoffs would be worse than getting a higher color content and porting it to Atari. Better to have original applications targetted to the Atari machine taking into account how the colors work. That way even with 5 colors/scanline at 160*200 one can at least take advantage of faster repainting and less memory usage and for static imagery use tricks like mid-screen color changes/interlace/overlapping pmgs/priorities/etc. Sometimes tricks are better than a high bandwidth requiring more memory usage.

 

...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).

[Animal Party]

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.