Atari v Commodore

[emkay]

31 - KORONIS RIFT

 

Impressive work for both versions, the programmers worked with very high details in it. However the Atari graphics is impressive, maybe one of the few games that use all GTIA capabilities. You will need a manual to understand how to play this, not easy or intuitive interface.

 

 

????

 

Particular this game is hitting the C64 it's own version it's face and kicks it right into the next garbage can.

In no other game the difference between the Quality of the C64 and A800 game is that huge.

 

Tripple colours on the screen. Three instead of two depth layers. Fading colours.... and... and .... and.

 

Koronis Rift is THE game that shows the C64 must be the older machine there.

Edited December 17, 2008 by emkay

[atariksi]

...PC timer freq is 1.19318Mhz (standard PCs-- new nonstandard HPET doesn't qualify as most PCs don't have it nor can access it directly via applications),

...

Unless you have a PC with some higher resolution timers or audio hardware (Non-standard).

 

atariksi, where did you get those strange ideas?

 

Almost every new PC do have HPET. For starters, HPET is a mandatory requirement to get a Microsoft Vista Logo. HPET was standard even before Vista. Intel has been shipping HPET in all their chipsets for several years.

...

It's not a strange idea to compare standard PC h/w resources to Atari h/w resources or any other machine for that matter. It is strange to claim PC can emulate some hardware feature when in reality you are comparing it to a specific audio/video setup that may not exist on another system. POKEY is a standard piece of hardware on all Atari 8-bits computers. 1.19Mhz is a standard timer on all PCs. Can't even compare Atari with C64 if you put in some special hardware in C64 allowing for 16.7Million colors or something like that. HPET may have been required by Microsoft recently, but neither the HPET nor Vista are to be found in every PC. I have a 2.8Ghz PC that does not have Vista nor HPET. Quad POKEYs can also be found in some Ataris so perhaps, we want to compare their emulation using HPETs.

 

>There are other high resolution PC timers that predate HPET by many years. E.g: you have the ACPI/PM timer, and you have the APIC timer. Lastly, you have the Pentium RDTSC timer, whis is available since too long ago.

 

There are problems with RDTSC/PM timers as first they don't generate IRQ-- you can poll them. They have overhead in polling as RDTSC is specific to CPU frequency (or sometimes bus frequency) and non-serializing. Polling may prevent using them an emulator which requires other resources like keyboard input, joystick input, etc.

 

>Of course that high precision timing in the PC have many issues, OS issues being probably the most important ones. But claiming that the only standard PC hardware timer is the 1.193182 MHz PIT, is wrong.

 

I was using it in an example where you directly access the sound blaster. Visa/XP is not going to let you access the sound hardware directly anyway even if you have a faster timer. The 1.19Mhz timer is the ONLY one which is present in EVERY PC. I can be more lenient and say okay let's allow for RDTSC and PM timers, but then you still have the problem of finding a compatible sound card, generating an IRQ, etc.

 

>>For example, Sound Blaster has 1Mhz

 

>That doesn't make any sense. Since about a decade, that any audio card has an AC97 interface, or compatible, or similar. AC97 requires a 12.288 MHz (or multiple) clock. There is no way that a modern audio card would be clocked at 1 MHz.

 

As I stated there are various cards with various frequencies, but the SB standard was more widely accepted before everything required a driver/API to access. Even the newer SB cards retained backward compatibility on the hardware level by allowing you to set the divisor for the 1Mhz crystal. Regardless of the 12.2888Mhz crystal a sound card may have, they have to allow for arbitrary divisors to be set (like in POKEY or PAULA). I know some cards are limited by the API and only work at standard Windows' rates like 11Khz, 22Khz, 44Khz, ...

 

>Now, I do agree that emulation is not perfect. And I also fully agree that there are some hardware limitations that would prevent the "experience" to be identical to the one in real hardware. But the hardware timers have very little (if at all) to do with this.

 

The example was to emulate POKEY by directly writing to the DAC registers which would require a hardware timer. DAC mode operation is present on SB cards. If you don't use the DAC register, you are stuck with the buffer method has it's own guaranteed problems like latency.

 

>E.g: An USB joystick has a significant latency. The latency is intrinsic to the USB protocol and interface. No hardware timer would help you here.

 

I would agree here USB or Gameport Joystick both are slower than Atari.

[atariksi]

For Jungle Hunt....

 

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.

 

Love that comment, some games have that issue where someone made poor color choices and wonder if their monitor or TVs color was messed up. Perhaps maybe they were programming on a monochrome monitor or B/W tv.

 

I noticed people debating the issue which computer has better colors and that is a vague issue because it comes down how someone utilizes the available colors in their game in either machine.

 

If you are including me in there, I say it's not a vague issue since your hardware capability is there to use a certain number of colors. How someone uses the colors does not affect which hardware is superior in terms of number of colors. Similarly with an emulator, I am looking at what it can achieve-- not what it is currently doing (which is probably much less than that).

[ijor]

It's not a strange idea to compare standard PC h/w resources to Atari h/w resources or any other machine for that matter...

HPET may have been required by Microsoft recently, but neither the HPET nor Vista are to be found in every PC...

There are problems with RDTSC/PM timers as first they don't generate IRQ-- you can poll them...

The 1.19Mhz timer is the ONLY one which is present in EVERY PC.

 

I wasn't talking about the comparison between PC and Atari hardware. Personally, I think this comparison doesn't make much sense, but that wasn't my point.

 

My point was about what hardware timers are available in a PC. You claimed that HPET was rare and/or non-standard, and that is wrong. You claimed that only high-end and/or non-standard PCs have other timers than the 1.19 MHz PIT, and that is wrong. Most PCs have, and they had for many years, several other timers available as standard.

 

Now you are saying that there are issues using those timers. Well, of course, I said that myself already in my previous post. I can add some additional issues and problems regarding high precision timing in the PC. But for most cases, the most important issue is the OS. It seems you like to work at the bare-metal level, but those days are gone for almost every case. (Almost) no emulator would work at the bare-metal level, and then it would depends on what hardware and software facilities the OS environment provides.

 

In this sense, it doesn't matter if the PC has HPET or not. You can't (easily) use it on Windows pre-Vista. But it also doesn't matter if the only timer is the PIT or not. In some versions of Windows, the PIT interrupt is not used, and in many cases you can't even poll the PIT at all without a custom kernel driver. Actually, in the near future the PIT won't be present anymore at all under an OS using HPET. This is because HPET has built-in PIT emulation, but the emulation is not available when HPET is being used.

 

Regardless of the 12.2888Mhz crystal a sound card may have, they have to allow for arbitrary divisors to be set (like in POKEY or PAULA). I know some cards are limited by the API and only work at standard Windows' rates like 11Khz, 22Khz, 44Khz, ...

 

Well, of course. Furthermore, many codecs (the actual chip that performs the DAC) has a fixed sample rate, or a small range. In those cases, it doesn't matter at all what the API provides or not. Some cards and drivers might accept an arbitrary sample rate, but in almost every case, the rate is translated by software or hardware at the driver or card.

 

If you don't use the DAC register, you are stuck with the buffer method has it's own guaranteed problems like latency.

 

Once again, for almost any conceivable emulator, writing directly to the DAC is not an option. That might work for your own personal computer, where you know exactly which sound card it has, which OS and version, etc. A "public" emulator can't depend on this, it must work in all (or at least in most) PCs, disregarding the exact hardware. And then, when using buffering, timers are not relevant at all.

 

Yes, this creates a latency problem. And I agree with you, there is no foolproof workaround. There is not because you don't have full control of the latency, and in some cases you don't even know what is the exact latency. Nowadays we have USB sound cards (add an additional delay), USB speakers, and we also have digital audio links. How in earth would you control the delay (let alone write directly to the DAC) when it might not be present in the PC at all?

 

Even a display might have a delay that you can't control and that you don't know. A non-CRT display might delay by one (or even more) frames when doing scaling or refresh rate adaptation (as almost every LCD display does).

 

We'll simply must learn to live with latency. Is this that relevant or not? I don't know. This is a topic for human perception issues, something that it is studied but not completely understood. Can a human perceive when the audio and video are out of sync by one frame, or by two? I don't know. Might be it can't, but it can perceive variations on the latency. Who knows.

 

The "emulation experience" would never be 100% as the real one. For many of us, it is about nostalgic issues that remind us when we were kids/teens or youngs. At this level, even the feeling of the keyboard, the blurring of the old TV, the sound of the tape-loader, the occasional (or not) error, etc, etc, are part of the "experience". How you could possible emulate this?

[atariksi]

It's not a strange idea to compare standard PC h/w resources to Atari h/w resources or any other machine for that matter...

HPET may have been required by Microsoft recently, but neither the HPET nor Vista are to be found in every PC...

There are problems with RDTSC/PM timers as first they don't generate IRQ-- you can poll them...

The 1.19Mhz timer is the ONLY one which is present in EVERY PC.

 

I wasn't talking about the comparison between PC and Atari hardware. Personally, I think this comparison doesn't make much sense, but that wasn't my point.

 

My point was about what hardware timers are available in a PC. You claimed that HPET was rare and/or non-standard, and that is wrong. You claimed that only high-end and/or non-standard PCs have other timers than the 1.19 MHz PIT, and that is wrong. Most PCs have, and they had for many years, several other timers available as standard.

...

It's non-standard as far as every pc (or even most pcs) having it. If by standard you mean someone declaring it a standard then that's not what I mean. I gave the example of the Atari 8-bit computer having the same timer regardless of which machine. HPET is relatively new; I would say less than 1% of PCs have it. As I stated, I have a 2.8Ghz DELL machine that does not have it and I bet there are millions of people who have this or similar machines w/o HPET. I don't get what you mean by APIC timer-- APIC is just the interrupt controller. There's a PM timer but that does not generate IRQ and has I/O port read overhead. As you may know I/O port reading is slow and will drop the accuracy even if it's at a higher frequency.

 

>Now you are saying that there are issues using those timers. Well, of course, I said that myself already in my previous post. I can add some additional issues and problems regarding high precision timing in the PC. But for most cases, the most important issue is the OS. It seems you like to work at the bare-metal level, but those days are gone for almost every case. (Almost) no emulator would work at the bare-metal level, and then it would depends on what hardware and software facilities the OS environment provides.

 

You can still do bare-metal level work although more and more hardware is becoming non-standard and people have to go through drivers/API and make everything more inefficient. There are issues with RDTSC-- you can read about it on your own as well not being able to generate IRQ.

 

>Once again, for almost any conceivable emulator, writing directly to the DAC is not an option. That might work for your own personal computer, where you know exactly which sound card it has, which OS and version, etc. A "public" emulator can't depend on this, it must work in all (or at least in most) PCs, disregarding the exact hardware. And then, when using buffering, timers are not relevant at all.

 

Sound Blaster was a standard when people wrote for older Windows like 3.1 since DOS was in the background and compatibility had to be at hardware level (I/O port level). Timing is still relevant even if you use buffered method of updating display every 1/60 second. You have to sync up to Atari's VBlanking or something similar otherwise you may be updating display while Atari is not done with a frame (phase shifted frame).

 

>Yes, this creates a latency problem. And I agree with you, there is no foolproof workaround.

 

That's why I was trying to give the emulation the benefit of doubt of doing DAC method so at least latency problem won't be there, but timing problem would be. But now you have both.

 

>We'll simply must learn to live with latency. Is this that relevant or not? I don't know. This is a topic for human perception issues, something that it is studied but not completely understood. Can a human perceive when the audio and video are out of sync by one frame, or by two? I don't know. Might be it can't, but it can perceive variations on the latency. Who knows.

 

You can definitely point out cases where it makes a difference and that's all you need to show emulation has timing problems. You may be familiar with updating images during vertical retrace (like they did on CGA and perhaps ST) where if you don't finish the image and update part of it next frame, you can definitely discern that from one that gets updated during vertical retrace. And you know very well dropping balls, lip synching, etc. where motion is faster than what 60 fps captures so audio must correspond to the frame especially when triggered off by joystick/keyboard input.

 

>The "emulation experience" would never be 100% as the real one. For many of us, it is about nostalgic issues that remind us when we were kids/teens or youngs. At this level, even the feeling of the keyboard, the blurring of the old TV, the sound of the tape-loader, the occasional (or not) error, etc, etc, are part of the "experience". How you could possible emulate this?

 

The feelings aside, I am pointing about some technical differences that can be overcome if the hardware differences weren't there and people had direct access to hardware ports.

[ijor]

The feelings aside, I am pointing about some technical differences that can be overcome if the hardware differences weren't there and people had direct access to hardware ports.

 

Atariksi, I love bare-metal work as much as you do. I guess most of us that were involved with vintage computers do. But in a modern PC it doesn't make much sense, and you're fighting a lost fight.

 

In theory, bare-metal emulation could be more accurate. But do you have an idea what would have happened to the PC and the whole industry, if most development would have done at the bare-metal level? You might not like APIs and drivers, but they are too good a concept. It is thanks to them, and thanks that most development doesn't touch the hardware or count cycles, that the hardware advanced so much and so fast.

 

And please don't start with the idea of respecting backward compatibility at the bare-metal level. Yes, of course it would be possible, but it would be more difficult, more expensive and slower. And above all, who cares nowadays (except you, and me if you want)?

 

Until not too long ago, PCs were extremely compatible with legacy hardware. Newer PCs are more and more legacy-free. It is likely that in the near future your lovely PIT timer won't be there anymore on newer PCs.

 

You want to run some software or operating system that the new hardware doesn't support, then use virtualization. I found Vmware to be one of the most useful and valuable software ever produced. You need more accuracy at the DOS level, then run a DOSbox emulator or BOSCH. That's not enough for you? Well, possibly, but then you (or we) are f*d. The industry doesn't care about some crazy vintage computer people that want to run their emulators with a few microseconds more accurately. And honestly, I doubt we can't blame them for not caring.

Edited December 18, 2008 by ijor

[R6502A]

Once again, R-Type. Where Oswald said, it is a good game on the Spectrum.

Just let's have a closer look at the graphics itself.

 

I have marked the position red/with arrows where you have to take care about.

 

The game is just using "char" animation and the object with the higher priority is drawn last. Games like Turrican, Test Drive or Space Harrier on the C64 work partially the same, where the sprites are not enough.

Does anyone know one commercial (machine language) game on the A8 that works also on this resolution for object-movement?

 

And no, Drop Zone doesn't move in charmode steps. It rolls graphics data inside char-clusters...

 

Donkey Kong Jnr on the Atari 8 bit uses a character screen and the graphics are moved in character steps, and it plays quite well.

[R6502A]

Me Too.

 

Love how the guy designed his silicon. It's worth noting that after so many years, more continues to be realized from it. This is probably my favorite Atari attribute.

 

Speaking of load times from cassette! Ghost Hunter on A400 took about 20 minutes as well. I don't think it was that big of a game either. Remember being able to make lunch, waiting for that thing. Which was faster? C64 or Atari from the cassette?

 

 

The Atari 1010 program recorder was a joke for load times. 16k games took 5 minutes and Dropzone from tape took about 10 minutes to load.

[Allas]

32 - MARIO BROSS

 

Atari screenshots

 

The best version of Mario Bross on Atari include a lot of additions as intermediate shows, better design platforms, better pictures, more colors. A great classic well done on Atari. I prefer this version (XE version), but others could prefer the old version o hacked version because the good speed motion.

 

C64 screenshots

Edited December 19, 2008 by Allas

[Rybags]

The C64 or practically any other computer was faster, so far as baud rate goes.

But, the C64 penalised itself - it stores the program twice and does error correction off the second copy.

 

The block size/baud rate was a bit rediculous. They could have easily used about 750 bps instead of 600, and 256 or even 512 or 1K blocksizes.

A bigger blocksize on it's own makes a difference.

 

Before I had a disk drive, I made a tape with the 8K Atari AsmEd cartridge image. It loaded mega-quick.

 

Had a 1 or 2 block Stage 1, then the entire 8K cart was saved after about an extra 2 second gap in a single block at something like 850 bps.

[Rybags]

Mario Bros maybe isn't a fair comparison. The later version was much better. The orignal one looked shit and they probably based the '64 conversion from it.

[Tezz]

Yea, the revamped MB was a nice improvement although I thought the original Mario Bros wasn't too bad personally

[Albert]

32 - MARIO BROSS

All these great comparison shots probably deserve their own thread.

 

..Al

[birdie3]

Strange Commodore vs. Atari question. Hopefully someone can help.

 

I am looking to acquire a few of the better Atari disk games likely from ebay. I often notice that the Commodore version of the game will be recorded onto the other side of an Atari disk. If I scour ebay for Commodore disks and buy a few, will any of these have the Atari 800 version on the other side? I guess I am looking for an easier way to find some of these games seeing that the many of the Commodore disks appear to be in greater abundance at times.

[potatohead]

Not to over talk Al, but I kind of like them sprinkled through. They've sparked some great discussion that has been good to read and informative. For what that's worth...

[Albert]

Not to over talk Al, but I kind of like them sprinkled through. They've sparked some great discussion that has been good to read and informative. For what that's worth...

It's nice seeing them in this thread, yes--they help break up much of the technical talk. But I also think it would be great to see a thread of these one after another..

 

..Al

[FastRobPlus]

Strange Commodore vs. Atari question. Hopefully someone can help.

 

I am looking to acquire a few of the better Atari disk games likely from ebay. I often notice that the Commodore version of the game will be recorded onto the other side of an Atari disk. If I scour ebay for Commodore disks and buy a few, will any of these have the Atari 800 version on the other side? I guess I am looking for an easier way to find some of these games seeing that the many of the Commodore disks appear to be in greater abundance at times.

 

Smart idea.

The biggest issue is that the companies were not always consistent in making the flippies. They were often created for specific retail channels (K-Mart, Jafco, Federated) where both systems were likely to be in play. The best examples of this are the rock bottom budget packaging titles that Cosmi and Mastertronic used for their US retail shelf-hanging line of games. They almost always made those disks "flippies"

 

Here are some companies that tended to mix Atari and C64 in one package:

Cosmi

Mastertronic

Access

Avalon Hill

Microprose

Artworx

Epyx (Especially the Lucasfilm games)

 

There may be some more I've forgotten. Check out my classic games tradelist and search the notes column for C64

[potatohead]

Not to over talk Al, but I kind of like them sprinkled through. They've sparked some great discussion that has been good to read and informative. For what that's worth...

It's nice seeing them in this thread, yes--they help break up much of the technical talk. But I also think it would be great to see a thread of these one after another..

 

..Al

 

Yeah, I'm up for that too. It's been really interesting to see so many titles posted up back to back!

[Tezz]

Strange Commodore vs. Atari question. Hopefully someone can help.

 

I am looking to acquire a few of the better Atari disk games likely from ebay. I often notice that the Commodore version of the game will be recorded onto the other side of an Atari disk. If I scour ebay for Commodore disks and buy a few, will any of these have the Atari 800 version on the other side? I guess I am looking for an easier way to find some of these games seeing that the many of the Commodore disks appear to be in greater abundance at times.

I can add that International Karate from System 3 was a flip disk with both versions.

[atariksi]

...

In theory, bare-metal emulation could be more accurate. But do you have an idea what would have happened to the PC and the whole industry, if most development would have done at the bare-metal level? You might not like APIs and drivers, but they are too good a concept. It is thanks to them, and thanks that most development doesn't touch the hardware or count cycles, that the hardware advanced so much and so fast.

 

And please don't start with the idea of respecting backward compatibility at the bare-metal level. Yes, of course it would be possible, but it would be more difficult, more expensive and slower. And above all, who cares nowadays (except you, and me if you want)?

...

You can have hardware level compatibility and stil advance the architecture. Just see the VGA cards-- they kept the A000:0000 memory mapped area and their standard I/O ports while going from 8-bit ISA -> 16-bit ISA -> VESA Local bus (32-bit) -> PCI 32-bit -> AGP. It went from like some cards doing 1MB/second to now > 100MB/second. I am not against having APIs. Having both options gives more flexibility for programmers. Keyboards also work off of 60h..64h.

 

>Until not too long ago, PCs were extremely compatible with legacy hardware. Newer PCs are more and more legacy-free. It is likely that in the near future your lovely PIT timer won't be there anymore on newer PCs.

 

That's bad. More and more inexact api calls. Legacy free means all those applications that use direct I/O for real-time stuff won't work and people have to work with inexact bloated api calls.

 

>...The industry doesn't care about some crazy vintage computer people that want to run their emulators with a few microseconds more accurately. And honestly, I doubt we can't blame them for not caring.

 

Sorry, not microseconds-- milliseconds. Changing a pixel color or value in memory mapped area with a MOV is faster and more exact than calling a bunch of API functions.

[atariksi]

I claim you CANNOT hit every 8th pixel on C64 consistently. C64 is less accurate regardless of where on the display. The 0.985Mhz is not accurate enough to do horizontal splits at any arbitrary 8th pixel. I don't think it can do every 16th pixel.

0.985 = 8 pixels/cycle. Or for NTSC C64: 1.02 MHz = 8 pixels/cycle.

 

For A8 : 1.79 = 4pixels/cycle, so really the A8 is more accurate than the c64 in this case.

 

He does reluctantly accept it's more accurate, but for Gr.8 (320*200) he's not accepting.

 

Anyway, here's code for Stable DLI (no WSYNC):

 

;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,

 

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

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:

;Nop

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 = 25 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

;Nop

Lda #96

Sta 53274

PLA ;4 cycles

RTI ;6 cycles

LastOffset: ;DW 2E2,2E3,StartAdr

 

any chance to get binaries instead of the source???

 

Okay, I am including binary for the following source code which does 25 DLIs at exact pixel boundaries w/o flicker:

 

;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

atrdli2.zip

[supercat]

Until not too long ago, PCs were extremely compatible with legacy hardware. Newer PCs are more and more legacy-free. It is likely that in the near future your lovely PIT timer won't be there anymore on newer PCs.

 

I wish Microsoft would either do a decent job of providing a virtual old-style PC, or else provide the OS hooks for someone else to do it. Even if it would be necessary to do cycle-by-cycle emulation, modern machines could still run programs that were written for something like a 386 at least as fast as the original machines would run.

[patjomki]

Atari 2007 game entries :

 

 

Atari 2008 game entries :

 

 

 

It will be interesting to see a brief of C64 complete productions those years.

 

Found the following releases for ATARI 2008:

 

Animal Party

Blackbox

Bomb Jack (conversion)

Cookie Monster

Eckn+

Fireball 1k

Gwobby's Adventure

Hobgoblin (conversion)

Indiana Jones III - Tajemstvi Svateho Gralu

Knight Lore (conversion)

Loops of Zen

Metagalactic Llamas (conversion)

Night Driver (conversion)

Raim

Sudoku (Isaac Davis)

Swapz

Yoomp! (NTSC version)

 

For C64 (2008):

 

1k-mini-bdash

20 Zeilen Limostand

ABCPanic

Artillery Duel Network 1.0

B-Bert

Black Hole

Block Fill

Cacktus Jack

Cavelon64

Das Duell der Piraten

Flakeshake

Flakeshake1k+Src

Flapper

Gold Quest 4

Hyper Duel

Ice Box

Imaginator V2

Laser Hawk

NetRacer 1.1

Not Even Human

Nyaaaah! - The Resurrection - Redux

Nyaaaah! 11 V2

P1x3l-pushr

Paddlepong

Shiftball

Shredz64 (<- This is the only one that really impresses me, also Laser Hawk isn't bad as well)

Stacker

 

 

Although in ATARI's lineup there are a lot of conversions I believe in 2008 it is more impressive than the one for the C64.

 

Regards,

 

patjomki

[+remowilliams]

The best examples of this are the rock bottom budget packaging titles that Cosmi and Mastertronic used for their US retail shelf-hanging line of games. They almost always made those disks "flippies"

Yeah, I've got a bunch of the Mastertronic A8/C64 flippies. Also have some SSI A8/Apple II flippies. My favorite was when they combined two different computer formats on the same side of the disk. Ninja was one of those types of disks.

[Allas]

Thank you Patjomki for your recopilation.

 

This C64 game NetRacer seems very near to Speed Up! Atari game.