Re: [Ql-Users] Memory contention (CPU / ULA)
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 QLs, is it? Not if there is a GC or SGC. Then the memory is only slowed down when writing to it, because the GC/SGC actually maps a 'shadow' memory area to the same place. The way it works is that when data is written to those addresses, it is written both to the RAM driven by the ULA and the appropriate area of GC/SGC RAM. The slowest one dictates the speed, so that's the ULA. When data is read, it is only read from the fast GC/SGC RAM at the same address. This way code is executed (very) much faster from those addresses, but the ULA also gets a copy of all the data taht needs to be displayed on the screen. logic must have been a really tight squeeze because it would have been very easy to add a screen 2 and 3... And that would be really great to have more than two screens, no blinking Flash bit...etc. It is actually possible to add screen 2/3 switching with external logic. The ULA has two memory CAS signals, one for each bank of 64k. It also has a signal that is activated when the ULA is doing screen refresh. Screen refresh is always done in the bank selected by the CAS0 signal, if external logic activates the CAS1 signal instead, the ULA will address the top 64k of the built-in memory to do screen refreshes. Ok, I have discovered interesting ULA behavior. I cannot change screen mode earlier than on the ~5th line of the screen. ULA simply ignores status of the port. Do you know why? I have never seen this, it is possible that the fram interrupt routine forces data into the control port, so your data gets overwritten. N. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Memory contention (CPU / ULA)
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 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Memory contention (CPU / ULA)
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 memory, because slow memory is equally slow on all QLs, is it? Referring to your info about memory expansions - not all are running at full speed and I want to avoid timing my stuff for different hardware. logic must have been a really tight squeeze because it would have been very easy to add a screen 2 and 3... And that would be really great to have more than two screens, no blinking Flash bit...etc. Ok, I have discovered interesting ULA behavior. I cannot change screen mode earlier than on the ~5th line of the screen. ULA simply ignores status of the port. Do you know why? Jan -- www.icq.atlas.cz/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Memory contention (CPU / ULA)
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 these times. OK, I will measure read/write time in the vram anyway. ULA should somehow share bus with CPU, it should not lock memory the whole TV frame refresh. 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. The ULA actually requests the bus only during the active display portion of the whole screen raster generated. The total raster generated is 640x312 of which 512x256 is used, so the ULA requests the bus about 66% of each frame (one frame takes 20ms). During this time the ULA reads screen RAm bytes in bursts of 4 bytes each, to it's internal buffer. It uses page mode DRAM access to do so, otherwise it would take approximately twice the time. Depending on the synch between the CU bus cycles and the ULA timing, at best the CPU can get 50% of available memory bandwidth, and usually less. When all is said and done, you come out with about 50-60% bandwidth long term. It shoul dbe mnoted that this is true for the whole 128k of internal RAM, even though the screen memory cannod reside in the second 64k - the ULA logic must have been a really tight squeeze because it would have been very easy to add a screen 2 and 3... Some memory expansions like the Trump Card are not as limited, you do not get any delays accessing the extended RAM there. Most RAM expansions (the notable exception being some schemes which used internal piggy-back RAM expansion also driven by the ULA) are considerably faster. Expanderam/TrumpCard are not as fast as they could be but a great deal faster than the ULA addressed RAM. SuperQboard was known as the fastest, running at the full speed of the CPU. Best, N ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Memory contention (CPU / ULA)
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 somehow share bus with CPU, it should not lock memory the whole TV frame refresh. Some memory expansions like the Trump Card are not as limited, you do not get any delays accessing the extended RAM there. On Amiga there is Chip RAM and Fast RAM. Chip RAM is shared between CPU and all coprocessors. In chip RAM is program running slower, because coprocessors has priority over CPU. Fast RAM is used only for CPU, therefore program runs faster here. I think this is case of Trump (and Sandy?). Extended memory is Fast and base lower 128k of RAM (??? or 64k of VRAMs only?) is Chip (slow), because it's shared with ULA. The same exists on ZX Spectrum, but it's well documented/implemented feature of ZX hardware. I think Sinclair didn't reinvent the wheel and used the same principle on QL. Is there any emulator emulating that feature? No emulator comes anywhere near a cycle-exact emulation. OK. Thanks. -- www.icq.atlas.cz/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Memory contention (CPU / ULA)
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 emulator emulating that feature? Thanks, Jan -- www.icq.atlas.cz/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Memory contention (CPU / ULA)
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 it? 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. Some memory expansions like the Trump Card are not as limited, you do not get any delays accessing the extended RAM there. Is there any emulator emulating that feature? No emulator comes anywhere near a cycle-exact emulation. Emulators providing QL-like speed only arbitrarily slow down the emulation to roughly equal the speed. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
