On Tue, 21 Aug 2007 19:39:50 +0200, Palenicek Jan [EMAIL PROTECTED] wrote:
Hi Nasta, Thanks for great info.
Thanks, thinking more about it, I should still address my time critical
routines into this slow-ULA memory rather than to expanded memory,
because slow memory is equally slow on all
ZN wrote:
The actual sharing is quite complex and effectively slows down the CPU
access buy some 40% or so, unless there is shadowing involved, like with
the GC and SGC.
[...]
Ah, look who's still alive :-) Thanks for the details, that was
interesting for me, too.
Marcel
Hi Nasta, Thanks for great info.
available memory bandwidth, and usually less. When all is said and done,
you come out with about 50-60% bandwidth long term.
Thanks, thinking more about it, I should still address my time critical
routines into this slow-ULA memory rather than to expanded
On Tue, 14 Aug 2007 09:35:43 +0200, Palenicek Jan [EMAIL PROTECTED] wrote:
Thanks Marcel!
I'm no hardware guy, but I'm pretty sure the ULA locks ALL internal
memory during screen refresh, i.e. depending on model (EU/US) 50 or 60
times per second. The CPU cannot access anything at all during
Thanks Marcel!
I'm no hardware guy, but I'm pretty sure the ULA locks ALL internal
memory during screen refresh, i.e. depending on model (EU/US) 50 or 60
times per second. The CPU cannot access anything at all during these
times.
OK, I will measure read/write time in the vram anyway. ULA should
Hi all,
I am working on some timing critical routines for standard QL w/wo SandyQboard
512 (no GC, no Aurora). Do you know how is memory shared between CPU and ULA?
Do you know how (if at all) is memory delayed when you need to access videoram
at the same time ULA is accessing it? Is there any
Palenicek Jan wrote:
I am working on some timing critical routines for standard QL w/wo
SandyQboard 512 (no GC, no Aurora). Do you know how is memory shared
between CPU and ULA? Do you know how (if at all) is memory delayed
when you need to access videoram at the same time ULA is accessing
