V0.6 Of Atari800 Released

[foft]

Is the Atari computer difficult to emulate? I would think that the GP32 should be able to run A800 at FS/0 with full sound and cycle exact at 60 Mhz. I would think if you can run 16 bit Genesis and Turbo grafx at full speed the 8-bit 1 Mhz Atari would be fast at any mode. Are there some weird custom chips in there that make it slow? I know that the Atari computer was designed by the Amiga guys so maybe they put some of that funky stuff in the Atari 800 too.

It seems that much Atari stuff is hard to emulate. The Lynx, and the Atari 2600 are slow too.

Yep it is another Jay Miner beast That said it would be possible to make it considerably faster. The atari800 emulator favours accuracy over speed in general.

The Atari 8-bit's main chips are:
cpu: 6502 - non-standard illegal ops are used by emus though. This could probably be sped up alot with an asm core. Indeed the Amiga port does this...
antic: Main video chip. This reads a mode list from memory for each line of the display. i.e. different video mode per line. Also does scrolling, scanline interrupts and stuff. This is one of the more complex parts of the emulator. A large optimisation to this would be writing to the GP32 screen directly (its the wrong way round!). Doing that efficiently is a significant amount of work.
gtia: Secondary video chip. Deals with colours and sprites. intra-frame colour changes are allowed, so precise cpu timing is important.
pokey: Sound chip. Has hardware interrupts. Does not do dma for sound samples. So this is written directly by cpu as volumn levels. So, again, precise cpu timing is important.

Anyway I'm sure it could be made quicker. Once my round robin queue gets back to this project again, I might try to optimise it. Sub 100MHz cycle exact would be cool!

If the 800 was a simple framebuffer, dma soundchip and plain cpu it would be very fast

Mark

 

[Antiriad]

Am i right in thinking that LJGP32 runs off a ARM ASM 6502 Core?

 

[DaveC]

Is the Atari computer difficult to emulate? I would think that the GP32 should be able to run A800 at FS/0 with full sound and cycle exact at 60 Mhz. I would think if you can run 16 bit Genesis and Turbo grafx at full speed the 8-bit 1 Mhz Atari would be fast at any mode. Are there some weird custom chips in there that make it slow? I know that the Atari computer was designed by the Amiga guys so maybe they put some of that funky stuff in the Atari 800 too.

It seems that much Atari stuff is hard to emulate. The Lynx, and the Atari 2600 are slow too.

Yep it is another Jay Miner beast That said it would be possible to make it considerably faster. The atari800 emulator favours accuracy over speed in general.

The Atari 8-bit's main chips are:
cpu: 6502 - non-standard illegal ops are used by emus though. This could probably be sped up alot with an asm core. Indeed the Amiga port does this...
antic: Main video chip. This reads a mode list from memory for each line of the display. i.e. different video mode per line. Also does scrolling, scanline interrupts and stuff. This is one of the more complex parts of the emulator. A large optimisation to this would be writing to the GP32 screen directly (its the wrong way round!). Doing that efficiently is a significant amount of work.
gtia: Secondary video chip. Deals with colours and sprites. intra-frame colour changes are allowed, so precise cpu timing is important.
pokey: Sound chip. Has hardware interrupts. Does not do dma for sound samples. So this is written directly by cpu as volumn levels. So, again, precise cpu timing is important.

Anyway I'm sure it could be made quicker. Once my round robin queue gets back to this project again, I might try to optimise it. Sub 100MHz cycle exact would be cool!

If the 800 was a simple framebuffer, dma soundchip and plain cpu it would be very fast

Mark

Sounds complicated. Well thanks for the explanation and the emu. I played around with it before but now that I got my BLU I fiddle with it much more. I can tell you it does look awesome on the BLU. It looks better now on the crisp BLUs RGB screen than it ever did on an old fuzzy TV through the RF switch in the old days

 

[CU_AMiGA]

I think i found a bug.

When playing Dig Dug (using the auto framskip mode) the game seems to mess up when the characters are ghosted and they just seem to keep moving towards the edge of the playing area and disappear somewhere else or appear later the opposite angle. Also, sometimes, the score display characters also seem to get jumbled up when the characters are moving near it. Not sure what this is.

I use the A800132 fxe version.

Regards,

 

[foft]

I think i found a bug.

When playing Dig Dug (using the auto framskip mode) the game seems to mess up when the characters are ghosted and they just seem to keep moving towards the edge of the playing area and disappear somewhere else or appear later the opposite angle. Also, sometimes, the score display characters also seem to get jumbled up when the characters are moving near it. Not sure what this is.

I use the A800132 fxe version.

Regards,

Does this only happen in auto frame skip mode? The emulator does not (can not) do the collision detection properly on the skipped frames. The general idea is that the non skipped frames are adequate for this. I know at least one game this caused problems for - Mountain King. Try turning off frame skip and let me know if that works.

I did try it myself and I think it is only in frame skip mode. But I'm not really sure what is going on in the game TBH!

Thanks,

Narj

[Edit: lol - just noticed I signed this Narj rather than Mark! Those keys are too close!]

 

[CeNTauR2]

Thanks for the emulator, nice work!
Never used an Atari before.

 

[CU_AMiGA]

I think i found a bug.

When playing Dig Dug (using the auto framskip mode) the game seems to mess up when the characters are ghosted and they just seem to keep moving towards the edge of the playing area and disappear somewhere else or appear later the opposite angle. Also, sometimes, the score display characters also seem to get jumbled up when the characters are moving near it. Not sure what this is.

I use the A800132 fxe version.

Regards,

Does this only happen in auto frame skip mode? The emulator does not (can not) do the collision detection properly on the skipped frames. The general idea is that the non skipped frames are adequate for this. I know at least one game this caused problems for - Mountain King. Try turning off frame skip and let me know if that works.

I did try it myself and I think it is only in frame skip mode. But I'm not really sure what is going on in the game TBH!

Thanks,

Narj

[Edit: lol - just noticed I signed this Narj rather than Mark! Those keys are too close!]

​

@foft,

Yeah it only happens in auto frameskip mode. It is okay in framskip mode but is slow a little. I have no gone back to v0.5 as this is much better version and i have none of those problems. I recmommend A800 gamers to use this version as well.

Regards,

Sorry for the lateness.