read vptr value

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


User avatar
ericde45
Posts: 30
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

many thanks

i found this link to learn the begining :

https://github.com/scottjmoore/a3000demo

https://github.com/kieranhj/doom-fire

the second link has nice looking code.
User avatar
qUE
Posts: 86
Joined: Tue Dec 16, 2014 11:39 pm
Location: Bristol
Contact:

Re: read vptr value

Post by qUE »

No problem, all us Archimedes coders are here to help when we can :)

Regarding the first code link, the sprite plotting is un-optimised, it should be noted that word aligned memory accesses are far faster than byte access on the ARM2/3 machines, although probably not as noticeable on ARM running at 200MHz up :)

LDMIA/STMIA are even faster, you can load chunks of memory in/out of a bunch of registers in one instruction. Again word alignment is important, you'll get an exception if it's offset.

Second link; relies heavily on RISC OS, so if you do decide to go down latching the IRQ vector for timing and your own video/sound routines you won't be able to reliably use the SWI calls, as anything which require RISC OS's interrupt routines will likely crash hard.

I should also mention there's an assembler built into RISC OS's BASIC ([OPT pass::]), it's powerful but lacks any new instructions past ARM2/3 (although these can be macro'd with DEF FN) so YMMV. I use it for building my music production system for all kinds of ARM architectures, but it is probably a madman's obsession rather than practical :D

There's also an issue with what's faster on ARM2/3 isn't necessarily faster on newer ARM, instruction conditions are a devil in the detail imo, you can optimise out steering branches in your code and essentially make loops do a multitude of things, but it doesn't play so well with the branch prediction on later systems. So make sure you know what architecture you're targeting.

Don't shy away from looking at BBC BASIC ARM assembler code because it's not the same assembler, the syntax is pretty much the same across assemblers (with maybe exception of oddities like Goldroad on the GBA).

Good luck in making a demo, intro or game :)
User avatar
ericde45
Posts: 30
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

hello

i am still trying to learn how to code on Archimedes without using the SWI

i am currently trying to set the video pointer where i want. i tried the following code, but it does not seem to change the 'vinit' value
whatever i sub from my #screenstart, nothing changes

does RISCOS change back the value during interrupts that i do not know of ?
or my code is wrong ?


.equ screenstart, 0x1FEC000

;supervisor mode
SWI 22

;Vinit = &3600000+(val>>4)<<2

mov r0,#screenstart
sub r0,r0,#0x8000
mov r0,r0,lsr #4
mov r0,r0,lsl #2
mov r1,#0x3600000
add r0,r0,r1
mov r1,#0x3600000
str r0,[r1]


TEQP PC,#0
MOVNV R0,R0
User avatar
SKS1
Posts: 12
Joined: Sat Sep 19, 2020 12:04 am
Location: Highland Perthshire
Contact:

Re: read vptr value

Post by SKS1 »

Looks like you are trying to set up DMA from a virtual address - this is not possible. MEMC performs DMA for VIDC from physical addresses, so your Vinit needs to be the physical address (zero-based) of the pages to which you are writing in your program. By adding in such a large number to &03600000, you aren't setting Vinit but probably hitting the memory address translation!
User avatar
ericde45
Posts: 30
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

ok, i just tried with 0x2000

and the memory displayed seems to be always the same, as i move a little dot in the RISCOS video memory and i can still see it.

i sent the same value to vstart. id does not change anything
Last edited by ericde45 on Mon Apr 05, 2021 4:14 pm, edited 1 time in total.
User avatar
SKS1
Posts: 12
Joined: Sat Sep 19, 2020 12:04 am
Location: Highland Perthshire
Contact:

Re: read vptr value

Post by SKS1 »

Try setting Vinit to zero and incrementing it *slowly* - you should see the current screen contents scroll.
Last edited by SKS1 on Mon Apr 05, 2021 4:42 pm, edited 1 time in total.
User avatar
ericde45
Posts: 30
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

no, still not working

there is something wrong in my way to change the memc register i think
User avatar
SKS1
Posts: 12
Joined: Sat Sep 19, 2020 12:04 am
Location: Highland Perthshire
Contact:

Re: read vptr value

Post by SKS1 »

Yes, change:

mov r1,#0x3600000
add r0,r0,r1
mov r1,#0x3600000
str r0,[r1]

to

mov r1,#0x3600000
add r0,r0,r1
str r0,[r0]

Edit: MEMC is not attached to the data bus - data for registers is taken from parts of the address.
User avatar
ericde45
Posts: 30
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

really strange code, but this this it seems to change the video pointer this time ! thanks a lot.

i have now to think about where to write my moving dot, i am doing it in the event handler , on vsync interrupt.
i have to read again the memc pdf :)
User avatar
qUE
Posts: 86
Joined: Tue Dec 16, 2014 11:39 pm
Location: Bristol
Contact:

Re: read vptr value

Post by qUE »

My mentions;

To program custom modes, I cannot recommend enough downloading !CustomVDU, it exports a module for your mode or standard modes which you can look at in the disassembler in !StrongEd to see how it's programming the VIDC.

Although you really need to understand how CRTs process the video signal as it's not just I want a resolution of width, height and colour depth. It' far more complex in having to assume the CRT has set a timing and you're fitting your mode into that, sync stripes, bit throughput you name it.

Setting the MEMC is quirky if you need to go there, and I mean QUIRKY. You write the address to itself, iirc the upper part of the word is the index and the lower part is the data, so everything is STR rN,[rN].

Pointer addresses for video, sound, etc. are limited to the first 512K of physical memory. MEMC translates the physical space into virtual which is why the video seems way up in the high addresses in RISC OS where as it's actually at the start of RAM, I suspect this is because the hardware doesn't see the MEMC address translation and just pure unpaged memory.

Now I can't stress enough, in all honesty, unless you're planning to ROM the code I cannot see the advantage of not just poaching RISC OS's internal SWI capabilities before you go into your code. There's no shame in using it, it's efficiently coded, saves a lot of datasheet headaches. IMO you'll get absolutely no gain from fiddling the video modes manually, you're constrained by the video output so you'll so find yourself scaling back to whatever that's capable of.

However, RGB colour swapping tricks to increase colour depth like what Arabella demo and Steve3000's stuff does, does require base address start/end fiddling, but I think Steve3000 has made something to ease that process.

This said if you're just trying to move the video address base to flip between rendering planes, hardware scrolling like for shmups or like I mentioned RGB swapping, then I can't see a problem with just modifying the base start and end of video as you want. But don't forget all your RISC OS compatibility will vamoose (i.e. text rendering for debug) because ROS keeps note of it's own base address in virtual page zero which is modified by it's SWI routines.
User avatar
ericde45
Posts: 30
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

hi again.

so i am able to change the video pointer

i set the video pointer to $2000
but when trying to write for example at $2000+3200, in 256 color mode, , nothing seems to change on screen
i traced my code with qdbug, and i see that the memory is filled with the values i store there.
i am doing the str to $2000 under supervisor mode

so, i am wondering, when i write $2000 to the vinit, is it an absolute value ? does the video memory read starting $2000 ? or is it some kind of offset ?
or is there any riscos protection , even in supervisor mode, not allowing me to write at $2000 ?
User avatar
SKS1
Posts: 12
Joined: Sat Sep 19, 2020 12:04 am
Location: Highland Perthshire
Contact:

Re: read vptr value

Post by SKS1 »

Your program doesn't see the same memory map as the MEMC DMA, which doesn't go through any address translation.

If you insist on trying to write to physical memory, you need to add &02000000 to your addresses and access it in a privileged mode.

Easier is to write to the memory-mapped copy of screen memory below &02000000 - you can read its base address using OS_ReadVDUVariables (ScreenStart)
User avatar
ericde45
Posts: 30
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

thanks , i will try that

and about using the OS system calls, i know that would be easier and more compatible with newer Archimedes

but i coded demos on ST and Amiga and i am really aware that you need to go deeper than the OS calls, , and try working directly with hardware chips, and then once you understood how they work, you can get try finding tricks to go further than the computer was design to be used

for example on ST, either fullscreen and horizontal hardware scrolling would never have been done if some guys did not dig in the direct access to chips. enchanted lands is a game using hardware tricks and the result for an ST if great.

and on Amiga, you could do the same kind of tricks, for example using floppy disc DMAs to fill the screen added to the blitter.

i am starting from very far from this on Archimedes, but i have years to learn ( i hope ! :D ) and as i am getting old, i don't care about asking stupid noob questions.

and thanks a lot for all the answers and for your time.

edit : this time i see the modified screen memory. thanks !
User avatar
ericde45
Posts: 30
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

hello here today !

i am still struggling with the memory video address

for what i understand from different sources, vinit is just an offset related to the screen memory base address.
when allowing screen memory using Riscos calls, i am able to change the screen memory base address

but how do you change the screen memory base address directly ?

it does not seems that vinit is the real value for video memory address

or am i all wrong about this ?
User avatar
ericde45
Posts: 30
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

to complete my question, when running this code :

MOV r0, #DynArea_Screen
SWI OS_ReadDynamicArea

in return i get r0 = video memory base address

MOV r0, #DynArea_Screen
MOV r2, #320*256*2
SUBS r1, r2, r1
SWI OS_ChangeDynamicArea

allocates 320*256*2 bytes for video memory

MOV r0, #DynArea_Screen
SWI OS_ReadDynamicArea

r0 = the new video memory base address

so riscos is able to change the video memory base address :)

i saw that Steve dissassembled riscos, but i am no able to search in all the lines to find the code modifying the video memory pointer.
User avatar
SKS1
Posts: 12
Joined: Sat Sep 19, 2020 12:04 am
Location: Highland Perthshire
Contact:

Re: read vptr value

Post by SKS1 »

Remember that the DynamicArea API deals with user-addressable memory (on pre-ARMv3 this is always below &02000000); MEMC DMA registers deal with physical memory, starting at zero.

RISC OS with MEMC always accumulates enough contiguous physical pages at physical memory zero to accommodate the display mode, with those pages also being mapped below &02000000 to make life easier for the graphics code when hardware scrolling. It is usual for MEMC Vstart and Vinit to be zero on a mode change.

Are you using an ARM2 emulation? RISC OS 2 or 3.1?
User avatar
ericde45
Posts: 30
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

yes, i am working with arculator + vasm on my PC
riscos 3.11

so if i understand well, the video memory real address is really 0 ?
User avatar
SKS1
Posts: 12
Joined: Sat Sep 19, 2020 12:04 am
Location: Highland Perthshire
Contact:

Re: read vptr value

Post by SKS1 »

Yes, physical addresses as seen by MEMC begin at zero. As its DMA registers can only access the bottom 512KB of physical memory, zero was an easy choice for the start of display physical memory.

I think that Vstart/Vend/Vinit are only set on MODE change and not on OS_ChangeDynamicArea, so set up your target MODE first to get VIDC and MEMC coherent then change the screen's DynamicArea size to twice the read-back value if you are wanting to hardware double-buffer, where it's up to you to set Vstart/Vend/Vinit as needed.
User avatar
ericde45
Posts: 30
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

ok, i am so used to have the OS / system calls at the bottom of the memory.

ARM / Archimedes is another world :)

thanks for your patience !
User avatar
SKS1
Posts: 12
Joined: Sat Sep 19, 2020 12:04 am
Location: Highland Perthshire
Contact:

Re: read vptr value

Post by SKS1 »

OS lives in ROM, 'up there'. Bear in mind, as others have sagely noted before, that this bash-the-devices approach is limited to a subset of real RISC OS systems!
User avatar
ericde45
Posts: 30
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

just to show you that i am struggling ahead :

https://youtu.be/JlXiXlv4gm0
User avatar
ericde45
Posts: 30
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

one step is achieved :

https://youtu.be/qg_g7wCmYb4

red = cpu time for CLS + 3D calculations for 8 points + drawing the lines
256 colors, so 80Kb of CLS
Post Reply

Return to “32-bit acorn software: other”