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
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
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
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
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
H as it had this in sent box, I think the FBI scoffed it lol
This is going sound odd but whats new
I am looking for the original postal address for MGT , SamCo SamTech
Also if anyone is in contact with Bruce Gordon .. or has a last known
address / phone / email for him could they
On Monday 23. February 2009, kisyfier wrote:
I am looking for the original postal address for MGT , SamCo
SamTech
ftp://ftp.nvg.ntnu.no/pub/sam-
coupe/PR/MGT_SamCo_WestCoast/brochures/SAMBrochure.pdf
-Frode
--
^ Frode Tennebø | email: fr...@tennebo.com | fr...@irc ^
| with
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).
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
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
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
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
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
13 matches
Mail list logo
