MEMC and first 512 KB

discuss general risc os software applications and utilities
Related forum: adventures


Post Reply
User avatar
ericde45
Posts: 103
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

MEMC and first 512 KB

Post by ericde45 »

Hello,

i'm back with my stupid questions :)
for what i have understood, the first 512 KB are the only one reachable by VIDC/DMA and then, the video memory can only be located in the first 512 KB

does anyone know if this can be changed using MEMC parameters/registers ? something like bank switching on old Z80 computers using 128 KB ( Amstrad CPC memories :D )
User avatar
IanS
Posts: 1933
Joined: Mon Aug 31, 2009 7:02 pm
Contact:

Re: MEMC and first 512 KB

Post by IanS »

It's a limitation of the MEMC.
MEMC datasheet.
MEMC datasheet.
memc-dma.PNG (71.51 KiB) Viewed 523 times
On the CPC, it relatively easy to modify the address bus before it's fed to the DRAM chips as the dram multiplexers are discrete parts on the PCB, with the multiplexors integrated into the MEMC it would be significantly more difficult to change this limitation.
User avatar
ericde45
Posts: 103
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: MEMC and first 512 KB

Post by ericde45 »

ok, thanks, the answer is clear :)

it is a very limitative feature, compared to ST or Amigas.
dp11
Posts: 1303
Joined: Sun Aug 12, 2012 9:47 pm
Contact:

Re: MEMC and first 512 KB

Post by dp11 »

Can't fix it now. Time to use another platform
gfoot
Posts: 119
Joined: Tue Apr 14, 2020 9:05 pm
Contact:

Re: MEMC and first 512 KB

Post by gfoot »

I'm curious, why do you need the screen to be higher up in physical memory? What would it enable that you can't do already?
steve3000
Posts: 2555
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: MEMC and first 512 KB

Post by steve3000 »

gfoot wrote:
Fri Sep 10, 2021 10:19 pm
I'm curious, why do you need the screen to be higher up in physical memory? What would it enable that you can't do already?
I think the idea is to bank switch in a different 512kb…but sadly not possible :(
User avatar
ericde45
Posts: 103
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: MEMC and first 512 KB

Post by ericde45 »

512 KB is not enough if you want to do a 1 or 2 pixel 256 colors 9 directions scroller ( without copying the whole screen each vbl )
switching bank would have been a way to have more video memory.

for example the game 'enchanted lands' on ST is using so many video screens for its scroller that it does not switch/flip video screen, the sprites are vertically sorted, top sprites are drawn first to be displayed before the electron beam reach this part of the screen.
dp11
Posts: 1303
Joined: Sun Aug 12, 2012 9:47 pm
Contact:

Re: MEMC and first 512 KB

Post by dp11 »

Well you know which platform to use then.
User avatar
ericde45
Posts: 103
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: MEMC and first 512 KB

Post by ericde45 »

if the guy who made this game, enchanted lands, did so, he would have done it on Amiga, because if you read ST's hardware specs, you would say that it is not possible to do what he did :o
gfoot
Posts: 119
Joined: Tue Apr 14, 2020 9:05 pm
Contact:

Re: MEMC and first 512 KB

Post by gfoot »

I'm not an expert on Arc graphics, but in a more general sense I don't see anything there that requires so much video memory. It looks like 320x240 or thereabouts, which is only about 64k per framebuffer. Even triple-buffering would only use about 200k. Just like on PCs well into the 90s, the main challenge is on the software side, writing the code to redraw the screen fast enough for your target frame rate.
steve3000
Posts: 2555
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: MEMC and first 512 KB

Post by steve3000 »

ericde45 wrote:
Fri Sep 10, 2021 10:46 pm
512 KB is not enough if you want to do a 1 or 2 pixel 256 colors 9 directions scroller ( without copying the whole screen each vbl )
switching bank would have been a way to have more video memory.
You can hardware scroll left/right with 2 pixel accuracy in 256 colour screen modes on the VIDC (by adjusting border size and screen start position registers :wink:). So you can keep two copies of the screen, with one shifted by a single pixel, to get 1 pixel accuracy in scrolling. So a full multidirectional scroller should fit in 512kb, unless you're going for a very large overscan screen size?
User avatar
ericde45
Posts: 103
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: MEMC and first 512 KB

Post by ericde45 »

4 screens * 2 to flip * 320*256 = 655 360

i think i need 4 screens to do an unlimited 9 directions scroller.
User avatar
IanJeffray
Posts: 1621
Joined: Sat Jun 06, 2020 3:50 pm
Location: Scotland
Contact:

Re: MEMC and first 512 KB

Post by IanJeffray »

ericde45 wrote:
Mon Sep 13, 2021 8:15 pm
4 screens * 2 to flip * 320*256 = 655 360

i think i need 4 screens to do an unlimited 9 directions scroller.
I can't see how it's useful having all those buffers, but assuming you do for whatever reason, why not just run say 320x200 ? That'd fit.

Even if you had 4 prepared buffers at 320x256, copying one of them to a single shared backbuffer at 50Hz is only 8MB/sec... and VIDC will steal half of that again, leaving you a nominal 13MB/sec (~50%) theoretical bus available even on the lowliest 8MHz-bus Arc. I've long forgotten how long it takes ARM2 to copy 4MB though and I suspect someone will tell me I'm wrong with these figures too...
gfoot
Posts: 119
Joined: Tue Apr 14, 2020 9:05 pm
Contact:

Re: MEMC and first 512 KB

Post by gfoot »

I'll be interested to hear from the experts, but I've done the maths on this before for my own non-Arc ARM2 computer, and for copy operations I think it came to just lower than the double clock rate, in bytes per second. i.e. 8MHz clock => 16MB/s maximum copy rate. We can nearly read or write 4 bytes per clock cycle, so transfer 4 bytes every 2 clock cycles, ignoring some overheads. The overheads depend on how you write the code, but my example lost around 10% of cycles to instruction fetches, loop statements, etc. So for a large block copy operation on an 8MHz machine I'd expect about 14MB/s I think.

I'd love to hear if it's possible to do better though!

The thing I don't understand about the original request is why so much buffer space is required. The game that was linked made heavy use of parallax, and the only way I know to do that - without hardware assists - is to refill the screen from scratch every frame. Hardware scrolling won't help. So like in the early PC graphics days, you need to write smart code to fill the screen efficiently, and maybe target 25Hz instead of 50Hz to get more time to spend on things other than redrawing the screen.
User avatar
ericde45
Posts: 103
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: MEMC and first 512 KB

Post by ericde45 »

the best way to make a scrolling is to only copy the new tiles, and move the video pointer.
any other way leads to 2 frames or more animation once you add sprites.
User avatar
ericde45
Posts: 103
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: MEMC and first 512 KB

Post by ericde45 »

enchanted lands does parallax in the title screen and no parallax in game...
gfoot
Posts: 119
Joined: Tue Apr 14, 2020 9:05 pm
Contact:

Re: MEMC and first 512 KB

Post by gfoot »

Ah ok fair enough, I must have only watched the title screen in the video. If the Arc supports some form of wrapping at a configurable maximum address then you'd still only need two single-screen buffers I think. It depends though.
User avatar
Rich Talbot-Watkins
Posts: 1773
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: MEMC and first 512 KB

Post by Rich Talbot-Watkins »

ericde45 wrote:
Mon Sep 13, 2021 8:15 pm
4 screens * 2 to flip * 320*256 = 655 360

i think i need 4 screens to do an unlimited 9 directions scroller.
Surely you only need 4 banks - two at each pixel offset so that you can double buffer. An R-Type style game which horizontally scrolled continuously would only need 2 banks!
User avatar
ericde45
Posts: 103
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: MEMC and first 512 KB

Post by ericde45 »

but if i want to do all directions, up down left right i would need 4 screens using video pointer modification

but as you all directly went to copy the whole screen, i made some tests and on a 12 mhz Archimedes, copying the whole screen using ldmia/stmia, with repetead instructions and short loops, seems fine and not taking that much cpu time

for 200 lignes, 256 colors, 416 pixels wide, going from clearing with zero to clearing with a background adds 16 to 20 scan lines. that's very few.

advices above about fast memory copy were completly right !
gfoot
Posts: 119
Joined: Tue Apr 14, 2020 9:05 pm
Contact:

Re: MEMC and first 512 KB

Post by gfoot »

I did some reading on the MEMC video DMA interface, and it sounds like it should support wrapping well enough to not need more buffers for more directions of scrolling. You specify an initial address (top left of the visible screen) and a start and end of video memory address. So you can scroll in any direction by changing that initial address, without changing the other two addresses at all, and redrawing the region that scrolls on, whether it's a vertical strip or a horizontal strip. At the MEMC level this is only with 16-pixel granularity, but I believe you then layer on other techniques at the VIDC level to get finer-grained horizontal scrolling.

Then to prevent the user seeing what's going on, you just need two of these buffers which you use alternately, updating one while you display the other.

Something else I saw in the datasheet is that it prevents the CPU from running more than 3 S-cycles in a row, to avoid starving the video DMA stream, and also pauses the CPU when necessary for video DMA. I think this means that large LMDIA/STMIAs will take a little longer in real-world time than you might expect based purely on the cycle counts and nominal clock frequency. My experience so far is only with ARM2, not the wider Archimedes architecture, so it's hard for me to extrapolate this.
User avatar
Rich Talbot-Watkins
Posts: 1773
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: MEMC and first 512 KB

Post by Rich Talbot-Watkins »

ericde45 wrote:
Tue Sep 14, 2021 10:02 am
but if i want to do all directions, up down left right i would need 4 screens using video pointer modification
Yes, 4 screens - this is what I was saying (you were suggesting 8 earlier on). The only thing you would need to do is to update the strips of new screen in all 4 buffers each time you scroll. Obviously, hardware scrolling would gradually move all the boundaries as new strips would overwrite the beginning/end of adjacent buffers. I think you'd need to leave a small gap between each one.
User avatar
Rich Talbot-Watkins
Posts: 1773
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: MEMC and first 512 KB

Post by Rich Talbot-Watkins »

gfoot wrote:
Tue Sep 14, 2021 11:17 am
I did some reading on the MEMC video DMA interface, and it sounds like it should support wrapping well enough to not need more buffers for more directions of scrolling. You specify an initial address (top left of the visible screen) and a start and end of video memory address. So you can scroll in any direction by changing that initial address, without changing the other two addresses at all, and redrawing the region that scrolls on, whether it's a vertical strip or a horizontal strip. At the MEMC level this is only with 16-pixel granularity, but I believe you then layer on other techniques at the VIDC level to get finer-grained horizontal scrolling.
Can you specify an end address? I thought the end address was basically fixed (although you could specify a "restart" address). If so, that probably makes life even easier.
User avatar
ericde45
Posts: 103
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: MEMC and first 512 KB

Post by ericde45 »

yes you can specify an end address but before setting the start address, and before display using this start address is started
Post Reply

Return to “32-bit acorn software: other”