Atari v Commodore

[atariksi]

I had no problems changing the XPos once the player started displaying. And, we're talking 4x width too.

 

Easy enough to prove/disprove (which I did). Change the operand so it's changing the Background Colour, and you see the half-cycle after the operation completes.

Then change it back. Change the initial position of the player and you can work out the exact boundary of where positional/graphic changes may take place.

 

how good is atari800win emulation in such cycle exact things?

 

I don't think any PC emulation that relies on standard 1.19Mhz PC timer is going to get the accuracy of the Atari's timers correct. By the way here's another DLI source I wrote up that does stable DLIs using 25 DLIs:

 

;Example of display list interrupt on atari 800/400/600XL/800XL/XE/XEGS © 2005-2007 KSI

;Compile and boot this as an image disk on your atari computer. If you boot with BASIC cartridge or in text mode,

;DList for text mode will be modified so interrupt occurs at each mode line at exact spot on screen

;consistently without using WSYNC.

 

ORG_ = 1529

CASINI = 2 ;for trapping reset vector

VCOUNT EQU $D40B

COLBK EQU 53274

WARMSTART = 58484

;HDR_ = 6

;DW 0FFFFh

;DW ORG

;DW LastOffset-1

DB 0,3

DW ORG_

DW StartAdr

Rts

Pla

StartAdr: LDA 560 ;LSB of ptr to display list (DL)

STA 203

LDA 561 ;MSB of ptr to display list (DL)

STA 204

LDY #2 ;intr on 3rd item of DL (use 2,3,6..28)

NXTDLVAL: LDA (203),Y

CMP #65

BEQ DLISET

;EOR #$80

ORA #$80 ;set DLI bit in ANTIC display list

STA (203),Y

AND #$70

CMP #64

BNE NOTLMS

INY

INY

NOTLMS: INY

BNE NXTDLVAL

DLISET: LDA #0

STA 54286 ;NMIEN

LDA #StableDLI,L

STA 512

LDA #StableDLI,H

STA 513

LDA #128

STA 54286 ;NMIEN

Lda #0

Sta 580

Lda #1

Sta 9

Lda #StartAdr,L ;get LSB of StartAdr

Sta CASINI

Lda #StartAdr,H ;get MSB of StartAdr

Sta CASINI+1

;For text mode, subtract 24*40+192*40+32 (DList) = 8672+DLI routine

;27510 - DMA cycles

IdleLoop:

Lda 0

Lda 1

Jmp IdleLoop

;rts

;Rts

;*** Our display list interrupt subroutine; OS does BIT 54287, BPL, JMP [512] so 4+2+5 = 11 cycles. H/W

;*** vector jump from [65530]. DLI = 37 cycles. Add instr. in multiples of 3 cycles.

;*** VCount register is not as accurate as POKEY POT counter so we we can use the POT(4) to get 8-bit scan-line

;*** count 0..228.

StableDLI: PHA ;3 cycles

Lda #39

Sta 53274

Lda #12

Sta 53272

;Nop

Lda #148

Sta 53272

Lda #96

Sta 53274

PLA ;4 cycles

RTI ;6 cycles

LastOffset: ;DW 2E2,2E3,StartAdr

[Rybags]

Emulation doesn't really happen in "real time" so it doesn't matter.

 

All it has to do is build a frame 50/60 times a second and buffer sound ahead for a certain time. So long as the framerate is constant, then the experience is as real as it needs to be.

[Bryan]

Emulation doesn't really happen in "real time" so it doesn't matter.

 

All it has to do is build a frame 50/60 times a second and buffer sound ahead for a certain time. So long as the framerate is constant, then the experience is as real as it needs to be.

 

Exactly. Atari800Win builds up a frame and counts cycles as it goes. It has nothing to do with internal PC timing.

 

I've got a screen kernel I've been building up and so far Atari800Win is showing it correctly.

[Fröhn]

A8 pixel clock: 1.77 * 4 MHz

C64 pixel clock: 0.985 * 8 MHz

Why don't you get it: one C64 CPU clock tick is EXACTLY 8 pixels.

There are at least two things which affect stable raster-- instruction alignment and CPU clocks getting evenly divided into the scanline time and/or frame time.

Same for C64 and A8. I don't know why you still deny that the C64 has "evenly divided" CPU clocks.

 

I never stated that IRQs are stable automatically. On Atari, they can be made stable by properly aligning the cycles used in the background code and interrupt code.

You totally missed the point of IRQs. Also you DID implicitely state that A8 IRQs are stable automatically since you didn't mention any "JMP in main loop and count all cycles of IRQ code to always have the main loop rastertime dividable by 3"-approach. As I said: That approach is pseudo-stable. It works only when you start to code something, but quickly you will end up with IRQ jitter once your routine consists more of just constant cycle use.

 

You are a scholar for knowing the irqs instability, but you need the creativity step (ingenuity) to take it beyond that step and make it exact.

Sorry but I made a lot of IRQs stable and I know several methods. Your "know all cycles" approach only works for that few instruction IRQ vs JMP in main loop. It does NOT work for any real world situation. In fact it is totally useless and doesn't prove any stability at all.

 

It's just that some people don't bother keeping track of what's happening so think it's "unstable" raster.

Because you can't "keep track" of real world routines in that way. The clock ticks they use change all the time.

 

Okay, the C64 is minimizing the artifacting, but CIA IRQ does not know about the video beam-- it's just counting its ticks so it has to divide out evenly into scanline time and/or frame time to get the 8-pixel accuracy.

POKEY also doesn't know about video beam, but it works because 1 tick = 4 pixels. And CIA has 1 tick = 8 pixels. Now how is that not 8 pixel accurate.

[atariksi]

Emulation doesn't really happen in "real time" so it doesn't matter.

 

All it has to do is build a frame 50/60 times a second and buffer sound ahead for a certain time. So long as the framerate is constant, then the experience is as real as it needs to be.

 

Not really. Experience consists of more than just the video frame rate. You can manipulate sound registers using the same clock frequencies and humans can experience much higher than 50/60 Hz. You can also manipulate the sprites so that they take less time on an atari than on a pc to update it's screen. You can read/write joystick I/O locations at exact intervals which is impossible to do on a PC given it's timing frequency. And other things.

[atariksi]

A8 pixel clock: 1.77 * 4 MHz

C64 pixel clock: 0.985 * 8 MHz

Why don't you get it: one C64 CPU clock tick is EXACTLY 8 pixels.

There are at least two things which affect stable raster-- instruction alignment and CPU clocks getting evenly divided into the scanline time and/or frame time.

Same for C64 and A8. I don't know why you still deny that the C64 has "evenly divided" CPU clocks.

...

Because the NTSC standard is the same but your 8pixels don't correspond to the same time as Atari's 8 pixels.

 

>>I never stated that IRQs are stable automatically. On Atari, they can be made stable by properly aligning the cycles used in the background code and interrupt code.

 

>You totally missed the point of IRQs. Also you DID implicitely state that A8 IRQs are stable automatically since you didn't mention any "JMP in main loop and count all cycles of IRQ code to always have the main loop rastertime dividable by 3"-approach. As I said: That approach is pseudo-stable. It works only when you start to code something, but quickly you will end up with IRQ jitter once your routine consists more of just constant cycle use.

 

I specifically stated things have to be aligned. Don't tell me about IRQs. I posted source code in this thread. I have it tons of code working in front of me w/stability. Your ineptness to understand it is your problem.

 

>Sorry but I made a lot of IRQs stable and I know several methods. Your "know all cycles" approach only works for that few instruction IRQ vs JMP in main loop. It does NOT work for any real world situation. In fact it is totally useless and doesn't prove any stability at all.

 

I did several science projects using this approach and won prizes. So I guess those are not real world situations. But your imagination is more useful. You don't understand the Atari well enough to make your claim nor are you familiar with all the scenarios where IRQ stabilization is useful.

 

>>It's just that some people don't bother keeping track of what's happening so think it's "unstable" raster.

 

>Because you can't "keep track" of real world routines in that way. The clock ticks they use change all the time.

 

Speak for yourself. YOU can't keep track. I CAN. Don't even reply to me until you have tried out the source code I posted in this thread and applied the formula I gave for alignment. I can run digitized audio routines as well in the background.

 

>POKEY also doesn't know about video beam, but it works because 1 tick = 4 pixels. And CIA has 1 tick = 8 pixels. Now how is that not 8 pixel accurate.

 

Already answered.

[Bryan]

Not really. Experience consists of more than just the video frame rate.

Well, playing an Atari game on a PC is a different experience anyway.

You can manipulate sound registers using the same clock frequencies and humans can experience much higher than 50/60 Hz.

?? The sound is generated as a sample. If you emulate cycle exact sound, then you get cycle exact sound.

You can also manipulate the sprites so that they take less time on an atari than on a pc to update it's screen.

I don't see how this matters when you have so much CPU power to throw at the problem.

You can read/write joystick I/O locations at exact intervals which is impossible to do on a PC given it's timing frequency. And other things.

Well, if you need cycle exact IO, then you need a real machine. I don't think that's really the goal of emulation, though.

[atariksi]

Break it...

 

Crack Up...

You rock, thanks! If I wasn't on my iPhone right now, I'd try them out right this instant! Even have paddle controllers ready to go.

 

..Al

 

How do I post an attachment image file of an atari disk with a reply? I tried to do attachment of ATRDLI2.IMG but it states that this type of file cannot be attached. It's just a sector dump of Atari disk (<16K).

[atariksi]

Not really. Experience consists of more than just the video frame rate.

Well, playing an Atari game on a PC is a different experience anyway.

You can manipulate sound registers using the same clock frequencies and humans can experience much higher than 50/60 Hz.

?? The sound is generated as a sample. If you emulate cycle exact sound, then you get cycle exact sound.

You can also manipulate the sprites so that they take less time on an atari than on a pc to update it's screen.

I don't see how this matters when you have so much CPU power to throw at the problem.

You can read/write joystick I/O locations at exact intervals which is impossible to do on a PC given it's timing frequency. And other things.

Well, if you need cycle exact IO, then you need a real machine. I don't think that's really the goal of emulation, though.

 

In order emulate cycle exact sound, you need cycle exact hardware access to sound card on PC. That's the initial problem and then once you do get access the problem becomes matching frequencies and timing. You don't really have CPU power to throw around in some cases where timing is also critical.

Well at least for I/O you need to be able to read the joystick and PC joystick is slower than Atari joystick.

[Fröhn]

Because the NTSC standard is the same but your 8pixels don't correspond to the same time as Atari's 8 pixels.

A8 and C64 have different pixel clocks, that's why both can have an integer divider of pixel clock/cpu clock and still be in sync with the rasterlines. NTSC doesn't know "pixels".

 

I specifically stated things have to be aligned. Don't tell me about IRQs. I posted source code in this thread. I have it tons of code working in front of me w/stability. Your ineptness to understand it is your problem.

Tons of stable IRQs with WSYNC. IRQs are unstable on A8 and C64 in the same way, that is why WSYNC is needed, or other methods like double-IRQ, DMA based sync, timer based sync etc.

 

You don't understand the Atari well enough to make your claim nor are you familiar with all the scenarios where IRQ stabilization is useful.

I am not that bad at Atari as you think.

 

Speak for yourself. YOU can't keep track. I CAN. Don't even reply to me until you have tried out the source code I posted in this thread and applied the formula I gave for alignment. I can run digitized audio routines as well in the background.

I don't need to try out your source because my IRQ is the same once I use a self-JMP as main loop (and pseudo-stable too). But once you actually have real code in the main program or IRQ running, the pseudo-stability is gone because it is NOT stable. And as for real world applications: Even if you manage to get your code pseudo-stable (which is highly unlikely if its more than just simple loops): Add a music, or add some user input stuff -> stability gone.

[Bryan]

In order emulate cycle exact sound, you need cycle exact hardware access to sound card on PC. That's the initial problem and then once you do get access the problem becomes matching frequencies and timing. You don't really have CPU power to throw around in some cases where timing is also critical.

Well at least for I/O you need to be able to read the joystick and PC joystick is slower than Atari joystick.

Well, if you want to create super-sonic effects (like the Pokey sawtooth) you'll need to emulate that effect in software, but it can all be done. You can create a sample that represents the audible output quite precisely. It may not be cycle aligned with a real raster in some particular way, but I don't see how that's important for emulation.

[Albert]

How do I post an attachment image file of an atari disk with a reply? I tried to do attachment of ATRDLI2.IMG but it states that this type of file cannot be attached. It's just a sector dump of Atari disk (

ZIP the file first and then you will be able to attach it.

 

..Al

[Crazyace]

In order emulate cycle exact sound, you need cycle exact hardware access to sound card on PC. That's the initial problem and then once you do get access the problem becomes matching frequencies and timing. You don't really have CPU power to throw around in some cases where timing is also critical.

Well at least for I/O you need to be able to read the joystick and PC joystick is slower than Atari joystick.

Well, if you want to create super-sonic effects (like the Pokey sawtooth) you'll need to emulate that effect in software, but it can all be done. You can create a sample that represents the audible output quite precisely. It may not be cycle aligned with a real raster in some particular way, but I don't see how that's important for emulation.

 

Does Atari800Win emulate the pokey interference audio waveforms?

[Rybags]

The Pokey emulation engine is kind of seperate (?)

 

And, IIRC, it's interpolated to 48,000 samples/sec or whatever rate you happen to select. That's why stuff like triangle waveforms don't work in emulation since they depend on interaction of 2 waveforms that is happening at small divisors of the 1.77 MHz system clock.

[Bryan]

Does Atari800Win emulate the pokey interference audio waveforms?

To a degree. It sort of recognizes what you're trying to do and plays an appropriate sound. It's far from complete, though.

[Rybags]

Full Pokey emulation would be really nice, but would probably come with a big performance hit.

 

ed - by "full", I also mean proper cycle exact emulation of Timers, not just updating per scanline.

Edited December 16, 2008 by Rybags

[Bryan]

Full Pokey emulation would be really nice, but would probably come with a big performance hit.

 

ed - by "full", I also mean proper cycle exact emulation of Timers, not just updating per scanline.

The best emulation would be to actually simulate the hardware to generate a 1.8MHz data stream, and then low-pass filter that to about 14-18KHz. You'd have all the Pokey effects perfectly generated, and yes you'd need a beefy machine.

 

-Bry

[Fröhn]

Full Pokey emulation would be really nice, but would probably come with a big performance hit.

 

ed - by "full", I also mean proper cycle exact emulation of Timers, not just updating per scanline.

The best emulation would be to actually simulate the hardware to generate a 1.8MHz data stream, and then low-pass filter that to about 14-18KHz. You'd have all the Pokey effects perfectly generated, and yes you'd need a beefy machine.

You don't even need to do that. Simply accumulate all sample values on the fly and then divide by sample count. This already gives a quite ok filter.

[Allas]

30 - JUNGLE HUNT

 

Atari screenshots

 

A classic game, both versions had been programmed equal, only differs from color choice. Off course, the Atari version have the better set if we want to imagine a jungle.

 

C64 screenshots

[Rybags]

Gotta say - both versions look like they were programmed by someone with bad colour-blindness.

 

So many Atari games were let down by something as simple as piss-poor colour choices.

[thorfdbg]

The Pokey emulation engine is kind of seperate (?)

 

And, IIRC, it's interpolated to 48,000 samples/sec or whatever rate you happen to select. That's why stuff like triangle waveforms don't work in emulation since they depend on interaction of 2 waveforms that is happening at small divisors of the 1.77 MHz system clock.

Interesting that you say they "don't work". They surely *do* work in my emulator... All it takes is a nonlinear output mapping to reproduce the effect - which is emulated....

 

So long,

Thomas

[thorfdbg]

Full Pokey emulation would be really nice, but would probably come with a big performance hit.

 

ed - by "full", I also mean proper cycle exact emulation of Timers, not just updating per scanline.

The best emulation would be to actually simulate the hardware to generate a 1.8MHz data stream, and then low-pass filter that to about 14-18KHz. You'd have all the Pokey effects perfectly generated, and yes you'd need a beefy machine.

 

-Bry

Not really. A standard PC can do that. Heck, my PC can do that, as that's exactly what my emulator is doing. There is no "discover which type of sound the guy wants to play" logic in the code. It just comes out the right way in first place...

 

So long,

Thomas

[Rybags]

Doubt it.

 

emkay should know every little nuance of emulated Pokey sounds - he's usually the first to step up and criticise it.

[ApolloBoy]

Gotta say - both versions look like they were programmed by someone with bad colour-blindness.

 

So many Atari games were let down by something as simple as piss-poor colour choices.

 

Well the A8 version doesn't look so bad, but the C64 version... Ack.

[emkay]

Doubt it.

 

emkay should know every little nuance of emulated Pokey sounds - he's usually the first to step up and criticise it.

 

Yep!