Re: Fully detailed instruction timing breakdown?

2009-02-24 Thread Simon Owen
Andrew Collier wrote: He didn't include code, but he described counting the number of NOP instructions executed between two consecutive frame interrupts. I've knocked up my own version, which uses the block of NOPs, but with a DEC A ; JP Z at the start to exit once the test is complete. They

Re: Fully detailed instruction timing breakdown?

2009-02-24 Thread Simon Owen
Simon Owen wrote: The value I get in SimCoupe is 119792 I'll check it's the same on the real machine tonight. Same same. Si

Re: Fully detailed instruction timing breakdown?

2009-02-23 Thread Simon Owen
Simon Cooke wrote: I was wondering… does anyone have a fully-detailed breakdown of instruction timings for the SAM? Including at various points in the screen? It's hard to have a complete list for anything but the smallest instructions. For longer instructions it depends on how they fall

Re: Fully detailed instruction timing breakdown?

2009-02-23 Thread Thomas Harte
Possibly a bit tediously realpolitik, but surely it'd be easiest just to write a routine that shoots out new palette values as quickly as possible for at least as long as the pixel area, set it to alternate between black and white, do a quick frame grab using a TV capture card and write a hasty

Re: Fully detailed instruction timing breakdown?

2009-02-23 Thread LCD
Yes, LCD would be very curious about this too, and it would be possible to include such a mode in Retro-X (Amiga HAM6 is included by the way). So if there is a viewer and a standartised data format, I would be happy to include this in Retro-X. If someone does not know the program yet, get it

Re: Fully detailed instruction timing breakdown?

2009-02-23 Thread Simon Owen
Andrew Collier wrote: I think the only question it doesn't answer is what happens to the 112 t-state difference between the number of t-states measured with the screen off (119696) and the number that would be expected from the timing characteristics of the screen display (119808). Doesn't

Re: Fully detailed instruction timing breakdown?

2009-02-23 Thread Andrew Collier
On Mon, Feb 23, 2009 at 12:25 PM, Simon Owen simon.o...@simcoupe.org wrote: Andrew Collier wrote: I think the only question it doesn't answer is what happens to the 112 t-state difference between the number of t-states measured with the screen off (119696) and the number that would be expected

Re: Fully detailed instruction timing breakdown?

2009-02-23 Thread Simon Owen
Thomas Harte wrote: surely it'd be easiest just to write a routine that shoots out new palette values as quickly as possible It depends how controlled the changes need to be... An unrolled block of OUTI instructions can make 13 changes across a main screen scanline (including both borders).

Re: Fully detailed instruction timing breakdown?

2009-02-23 Thread LCD
Simon Owen schrieb: Thomas Harte wrote: surely it'd be easiest just to write a routine that shoots out new palette values as quickly as possible It depends how controlled the changes need to be... An unrolled block of OUTI instructions can make 13 changes across a main screen

Re: Fully detailed instruction timing breakdown?

2009-02-23 Thread Simon Owen
Andrew Collier wrote: That would mean there should be 384*312=119808 t-states between frame interrupts, but according to that article, if you measure the number of instructions executed during a frame, then even with the screen off it turns out to be slightly fewer than expected. I'd be

Re: Fully detailed instruction timing breakdown?

2009-02-23 Thread Simon Owen
LCD wrote: But just a idea: Using Stack Pointer (PUSH) to write in CLUT memory area would be faster than LD Command, right? It certainly would be if SAM's palette was memory-mapped. Unfortunately it's only accessible through 16-bit I/O ports, so we're limited to the slow updates of each CLUT

Re: Fully detailed instruction timing breakdown?

2009-02-23 Thread LCD
Simon Owen schrieb: LCD wrote: But just a idea: Using Stack Pointer (PUSH) to write in CLUT memory area would be faster than LD Command, right? It certainly would be if SAM's palette was memory-mapped. Unfortunately it's only accessible through 16-bit I/O ports, so we're limited to

Re: Fully detailed instruction timing breakdown?

2009-02-23 Thread Andrew Collier
On 24 Feb 2009, at 00:27, Simon Owen wrote: Andrew Collier wrote: That would mean there should be 384*312=119808 t-states between frame interrupts, but according to that article, if you measure the number of instructions executed during a frame, then even with the screen off it turns out to

Re: Fully detailed instruction timing breakdown?

2009-02-22 Thread Andrew Collier
On 21 Feb 2009, at 21:38, Simon Cooke wrote: Hey guys… I was wondering… does anyone have a fully-detailed breakdown of instruction timings for the SAM? Including at various points in the screen? I’m tempted to write a code-generator to render bitmaps in more than the 16 colors

Fully detailed instruction timing breakdown?

2009-02-21 Thread Simon Cooke
Hey guys. I was wondering. does anyone have a fully-detailed breakdown of instruction timings for the SAM? Including at various points in the screen? I'm tempted to write a code-generator to render bitmaps in more than the 16 colors available, using a genetic algorithm (or even a monte