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.
read vptr value
Re: read vptr value
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
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
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
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
Re: read vptr value
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
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
Re: read vptr value
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!
Re: read vptr value
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
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.
Re: read vptr value
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.
Re: read vptr value
no, still not working
there is something wrong in my way to change the memc register i think
there is something wrong in my way to change the memc register i think
Re: read vptr value
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.
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.
Re: read vptr value
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
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
Re: read vptr value
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.
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.
Re: read vptr value
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 ?
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 ?
Re: read vptr value
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)
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)
Re: read vptr value
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 ! ) 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 !
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 !
) 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 !
Re: read vptr value
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 ?
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 ?
Re: read vptr value
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.
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.
Re: read vptr value
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?
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?
Re: read vptr value
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 ?
riscos 3.11
so if i understand well, the video memory real address is really 0 ?
Re: read vptr value
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.
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.
Re: read vptr value
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 !
ARM / Archimedes is another world
thanks for your patience !
Re: read vptr value
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!
Re: read vptr value
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
https://youtu.be/qg_g7wCmYb4
red = cpu time for CLS + 3D calculations for 8 points + drawing the lines
256 colors, so 80Kb of CLS