User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: RISC OS Assembly Tutorials.

Tue Nov 05, 2013 12:07 pm

The forum has that wrong, it got the month and day backwards. (Just checked my profile to be sure that I wrote it correctly), will be updating that to be correct.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: RISC OS Assembly Tutorials.

Tue Nov 05, 2013 12:33 pm

kevans67 wrote:DavidS - totally offtopic but I have to ask you how you were exposed to RISC OS in Kansas? It sounds as if you are a longterm user. (I was actually born there, but we moved away shortly afterwards.) I never ran across it until the RPi came along.
My first exposure to RISC OS (actually Aurthur OS at the time) was wen I lived in california as a child and was given my first Archimedes A310. It had an american keyboard layout and Aurthur OS. Since then I have used almowt every version of RISC OS. And now with RISC OS 5 (Just started using version 5.x with the RPi) there are a few new tricks that I like, even if some of the old tricks no longer work.

A freind of the family knew that I enjoyed playing with different computers in the late 1980s and decided to give me my first A310, and later my first A7000 and seperately my first RiscPC, later I got a Strong ARM SA110 card for my RiscPC. Never got an A7000+, or Iyonix. Then the RPi was anounced, and the moment that RISC OS 5.19 RC8 was posted on the RPi downloads page I ordered my first RPi, and just got my 6th RPi in the Post yesterday.

I have used and programmed for Authur OS 1.20, RISC OS 2, RISC OS 3.0, RISC OS 3.10, RISC OS 3.11, RISC OS 3.5, RISC OS 3.7, RISC OS 3.8, RISC OS 4.02, RISC OS 4.39 (adjust), Risc OS 6 (Select 4i2 through Select 6i1) and all of my OS Upgrades have been gifts befor the RPi (Now I am on my own with that).

I have used the Acorn Tools since AAsm was sold as its own package, and went to ObjAsm when it replaced AAsm, and have used ASM quite a bit and now with the RPi I am looking at options of assemblers and have not made my final decision, I still like ObjAsm, though extASM is a bit more up to date. I also like the Link util included with the Norcroft tools, unfortunately not available for free. I do not do much C.

And now with the RISC OS 5.21 on the RPi I have a faster RISC OS machine than I would have dreamed 5 years ago (when it looked like the last ever RISC OS compatable system had rolled out the doors of castle).
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

User avatar
GavinW
Posts: 84
Joined: Tue Nov 01, 2011 8:11 pm
Location: UK
Contact: Website

Re: RISC OS Assembly Tutorials.

Tue Nov 05, 2013 2:46 pm

DavidS - It is very good to see a new programmer on the RISC OS scene; especially one who has to be a lot younger than us ancients. My first computer was an Acorn Atom, acquired when I was 40. I only managed to get it because one of my mother's neighbours in Cambridge had a boyfriend working for Acorn.
By the way - hope this is not impertinent - I notice that you suffer from some word-blindness. If there are occasions when some confidential assistance would be useful, you can always get in touch with
me. See http://www.wra1th.plus.com/gcw/contact.html .
otium negare negotium vanum

User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: RISC OS Assembly Tutorials.

Tue Nov 05, 2013 3:08 pm

Well this i did not know, I have been programming for RISC OS for greter than 25 years. And while I guess that 35years old is young in comparison to many I had not given it much thought. It is true that I had only released a couple of very unpopular titles in the mid 1990s, and am thus just beging to be seen by others.


FOOTER, OT
Your EMail lists as a non existent domain from my end (domain look up failed).
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

User avatar
GavinW
Posts: 84
Joined: Tue Nov 01, 2011 8:11 pm
Location: UK
Contact: Website

Re: RISC OS Assembly Tutorials.

Tue Nov 05, 2013 3:37 pm

Typo? Plusnet is the biggest ISP in the UK, so I would be surprised if they were invisible to your DNS.
otium negare negotium vanum

User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: RISC OS Assembly Tutorials.

Tue Nov 05, 2013 4:47 pm

Yes and no, I read the 1 as a lower case L.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: RISC OS Assembly Tutorials.

Tue Nov 05, 2013 4:55 pm

UPDATE : UPDATE:

I have uploaded the first Example in the thread on using a game to learn Assembly on RISC OS:
http://www.raspberrypi.org/phpBB3/viewt ... 55&t=59895
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: RISC OS Assembly Tutorials.

Tue Nov 05, 2013 9:33 pm

@DexOS:
I am about to extend the Frame buffer Fade example into a usable Graphics library to be disected. in order to demonstrate ARM assembly.

I have already modified it to do things more correctly, that is to say it obtains the bytes per row, Xres, Yres, BPP, etc from the OS by calling OS_ReadModeVariable and calculates the size for the loop by multiplying one fourth of the bytes per row by the Y resolution. And best of all it will error out if the screen depth is not 32BPP at 16M Colors.

Though enough talking here is the code.

Code: Select all

#name <TutFade2$Dir>.!RunImage
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; RISC OS Fade solid color screen to black example.                      ;;
;;     Original by: Craig Bamford,                                        ;;
;;     Translated to extASM by: David cagle                  ;;
;;     Extended and modified by: David Cagle.                 ;;
;; PURPOSE:                                                               ;;
;;     Shows how to set up direct access to a 24BPP frame buffer under    ;;
;;     RISC OS, and write into that frame buffer.  This is the first step ;;
;;     In writing the game: ShaterBrick.                                  ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;******************************************************************************
; Start
;  This is the entry point to our little example program.
;******************************************************************************
.Start
  swi OS_WriteS          ;Display NULL terminated string, innediately folowing.
  DCB "Press any key to begin",0
  ALIGN
  SWI   OS_NewLine       ;Create a line feed.


  adrl R13,StackBuffer   ;Set stack up.
  swi   OS_RemoveCursors ;Remove the cursors.

; *** Get FB Address ***
  mov   r4,#9            ;Framestore information.
  mov   r9,#&2A          ;Vector number.
  swi   OS_CallAVector   ;The purpose of this call is to call a vector directly.

  STR   R0,Fb            ;save Framestore physical base address.
  STR   R1,FbSize        ;save Framestore Size.
  MOV   R0,#&200         ;Set bit 17 (flag to doubly map)
  ORR   R0,R0,#13        ;Reason Code "Map in IO permenent"
  MOV   R2,R1            ;Set R2 to the returned size.
  ldr   r1,Fb            ;Physical address to map in.
  swi   OS_Memory        ;The purpose of this call is to perform verioous
                         ; operations for memory management.
  STR   R3,Fb            ;Save pointer to mapped area.

  swi   OS_ReadC         ;wait for keypress.

  bl    GetRes           ;Jump to our get res routine to get information about
                         ; the current screen mode.
  CMP   R0,#5            ;Vrerify that it is 24BPP (stored in 32Bit word).
  BNE   ErrCol           ;If not display an error mesage and Exit.

  bl    FadeScreen

  swi OS_WriteS          ;Display A prompt.
  DCB "PRESS ANY KEY QUIT!",0
  ALIGN
  swi   OS_ReadC         ;wait for keypress.

; *** Exit ***
  mov   r0,0             ;Define return code
  swi   OS_Exit          ;And exit.

.ErrCol
  SWI   OS_WriteS
  DCB "ERROR : Invalid Color Depth (This Program Requires 24BPP)"
  ALIGN
  MOV   R0,#0
  SWI   OS_Exit

;******************************************************************************
; Data section for frame buffer related storage.
;******************************************************************************
.ScrnRowLen       DCD 0
.ScrnX            DCD 0
.ScrnY            DCD 0
.ScrnC            DCD 0
.Fb               DCD 0  ;Framestore physical base address.
.FbSize           DCD 0  ;Framestore size.
.BGColor          DCD &00FF0000  ;AABBGGRR
  ALIGN 4

;******************************************************************************
; FillScreen:
;  Fills Screen buffer.
;   We store values directly into screen memory 1 32-bit word at a time looping
;   until we fill the entire frame buffer.   This assumes a 16Million color
;   mode and requires that the pixel format be in 32bit words with the following
;   bit offsets:
;    bits 0:7   = RED value.
;    bits 8:15  = GREEM value.
;    bits 16:23 = BLUE value.
;    bits 24:31 = Unused (set to zero).
;******************************************************************************
.FadeScreen
  stmfd r13!,{r0-r8,r12,r14} ;Store registers.

  SWI   OS_EnterOS

  ldr   r1,BGColor       ;Load r1 with color (blue-3) to fill screen buffer.

  LDR   R4,ScrnRowLen
  MOV   R4,R4,LSR#2
  LDR   R5,ScrnY
  MUL   R3,R4,R5         ;Pixel count on screen = ScrnRowLen * ScrnY

.FadeLoop
    MOV   R2,R3            ;Load the pixel count.
    ldr   r0,Fb            ;Load r0 with address of screen buffer.

.FillLoop
      str   r1,[r0],#4       ;Move 4 bytes from r1 into address in r0.
      subs  r2,r2,#1         ;R2 = R2 - 1
    bne   FillLoop         ;LOOP UNTIL R2 = 0
    SUBS  R1,R1,#&10000    ;Subtract 1 from the blue value.
  BNE FadeLoop             ;Loop until color = Black.

  SWI   OS_LeaveOS
  ldmfd r13!,{r0-r8,r12,r15} ;Restore registers and return.


;******************************************************************************
; GetRes
;   Get the resolutions and color depth of the current screen mode.
;   Fills the screen mode variables:
;     ScrnX = Width of screen in pixels.
;     ScrnY = Height of screen in pexels.
;     ScrnC = BPP in the form of (1 << ScrnC) = BPP.
;     ScrnRowLen = Number of bytes per row.
; Returns the colors in R0 in the form:
;  BPP = (1 << BPP)
;******************************************************************************
.GetRes
  STMFD R13!,{R1-R2,R14}

  MVN R0,#0                ;Use -1 in R0 to request veriables for currennt mode.
  MOV R1,#6                ;REASON get complete line lenght in Bytes.
  SWI OS_ReadModeVariable
  STR R2,ScrnRowLen        ;Save the complete line length.

  MVN R0,#0
  MOV R1,#11               ;REASON: Get the horizontal screen size in pixels.
  SWI OS_ReadModeVariable
  STR R2,ScrnX

  MVN R0,#0
  MOV R1,#12               ;REASON: Get the vertical screen size in Pixels.
  SWI OS_ReadModeVariable
  STR R2,ScrnY

  MVN R0,#0
  MOV R1,#9                ;REASON: Get BPP as BPP = (1 << BPP)
  SWI OS_ReadModeVariable
  STR R2,ScrnC
  MOV R0,R2
.GetResQ
  LDMFD R13!,{R1-R2,R15}

;******************************************************************************
; Data section for Stack.
;******************************************************************************
  DBB &1000, 0
  ALIGN 16,4
.StackBuffer      DCD 0,0
I figured that this could be useful for you at least on an informative level. Atached is a zip file containing only the source.

As always open only in RISC OS, and copy out of the zip file before use.
Last edited by DavidS on Mon Oct 31, 2016 5:05 am, edited 1 time in total.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: RISC OS Assembly Tutorials.

Tue Nov 05, 2013 11:41 pm

Nice work, i moded the mouse demo to use "OS_ReadModeVariable" which is best practise as we do not know what screen mode is set to.

Anyway i was working on displaying a BMP image, i got it to work after many problem's, here is what i came up with
http://www.dex-os.com/riscos/BMP.zip

I will post the code later once i have cleaned it up and commented it right.
Its a function that you just need to give a file name and the X Y where you want it to displayed the image on the screen

I had big problems when trying to set a off screen buffer, it keep give a data transfer error when run.
To get around this i found that there is a buffer the same size as the screen at the screen address, plus the size of the screen buffer, so it used that for a back buffer.
This must be used for scrolling by RISC OS.

So what is the right way to set a big buffer in RISC OS code ?.

Once the code is cleaned up i will start work on a basic gui window functions for single tasking app, that will be much simpler for coder than using WIMP.
Batteries not included, Some assembly required.

User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: RISC OS Assembly Tutorials.

Wed Nov 06, 2013 12:57 am

DexOS wrote:Nice work, i moded the mouse demo to use "OS_ReadModeVariable" which is best practise as we do not know what screen mode is set to.

Anyway i was working on displaying a BMP image, i got it to work after many problem's, here is what i came up with
http://www.dex-os.com/riscos/BMP.zip
I do not know if you have looked at it or not, though you may find that RISC OS sprite files are easier to deal with, especialy with the built in functions to that purpose.
I will post the code later once i have cleaned it up and commented it right.
Its a function that you just need to give a file name and the X Y where you want it to displayed the image on the screen

I had big problems when trying to set a off screen buffer, it keep give a data transfer error when run.
To get around this i found that there is a buffer the same size as the screen at the screen address, plus the size of the screen buffer, so it used that for a back buffer.
This must be used for scrolling by RISC OS.

So what is the right way to set a big buffer in RISC OS code ?.
I would allocate a dynamic area (See SWI &66 = OS_DynamicArea), or just make your WimpSlot big enough to include the needed area, and directly use the memory allocated (all of the memory starting at the end of your Absolute and extending to the limit of the WimpSlot). If your application is only going to be an application than using the alocated memory slot is the easiest way. I forget the details of doing so in single tasking, thouhg in the WIMP it is very simple.
Once the code is cleaned up i will start work on a basic gui window functions for single tasking app, that will be much simpler for coder than using WIMP.
As simple as the WIMP is to program for I am deffinitely interested to see what you will come up with.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: RISC OS Assembly Tutorials.

Wed Nov 06, 2013 1:09 am

@DexOS
I should have mentioned above that the "correct" way would probably be to use OS_Heap, though that is probably the worste way.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: RISC OS Assembly Tutorials.

Wed Nov 06, 2013 1:09 am

Thanks for the info, i will look at RISC OS sprite files.
Note: i am used to coding everything myself, as 95% of my coding is done in bare metal lol .
Batteries not included, Some assembly required.

User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: RISC OS Assembly Tutorials.

Wed Nov 06, 2013 1:24 am

DexOS wrote:Thanks for the info, i will look at RISC OS sprite files.
Note: i am used to coding everything myself, as 95% of my coding is done in bare metal lol .
This I can understand. My currently undisclosed project is in baremetel. PM Me if you want more details.

Though as the sprite operations are provided by the OS, and they are fast why not take advantage of them?
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: RISC OS Assembly Tutorials.

Wed Nov 06, 2013 3:21 am

DexOS wrote:Thanks i will give it a try, yes at the time i was running at 800*600 and got buffer size of 6mb :? .
I will try at a higher res.
Note: I was on a very old ver of RISC OS, but today i got the latest ver.
Ok it apears that the row length is significantly greater than the visable width. I think that this could be the cause of the difference in lower res modes.

And your post here got me thinking about why I was running in such a high resolution, I have switched down to 1024x768 using hdmi_group=2 and hdmi_mode=16 in the CONFIG/TXT file, and seting the WimpMode in RISC OS to X1024 Y768 C16M EX1 EY1 F60.

Still looking for a way to load code into the GPU with out effecting graphics output (like you can in the Linux distros) on Bare Metal, and by extension on RISC OS. I have played with coding for the VideoCore IV in the RPi on bare metal a little bit, though I want to be able to still use the display. Though that does not have anything to do with the tutorials by example.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: RISC OS Assembly Tutorials.

Wed Nov 06, 2013 3:39 am

Are you talking about something like this or have i misunderstood you ?
https://github.com/hermanhermitage
Batteries not included, Some assembly required.

kevans67
Posts: 20
Joined: Wed Jan 23, 2013 5:54 am

Re: RISC OS Assembly Tutorials.

Wed Nov 06, 2013 4:32 am

@DavidS - interesting. I've lived in CA since about '72 and have never seen an Archimedes. I think that one of my friends must have been working on the Newton project sometime around the time you got the Archimedes. My understanding is that Apple influenced the ARM ISA in the early days.

User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: RISC OS Assembly Tutorials.

Wed Nov 06, 2013 4:55 am

DexOS wrote:Are you talking about something like this or have i misunderstood you ?
https://github.com/hermanhermitage
Yea except with out losing video out.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: RISC OS Assembly Tutorials.

Wed Nov 06, 2013 5:05 am

kevans67 wrote:@DavidS - interesting. I've lived in CA since about '72 and have never seen an Archimedes. I think that one of my friends must have been working on the Newton project sometime around the time you got the Archimedes. My understanding is that Apple influenced the ARM ISA in the early days.
I do not think that there were very many in the Americas (including the US), the family freind had got a hold of them though, and with US layout keyboards no less. My guess is that Acorn had attempted to market them in the US at one time.

And that would be before Apple even drempt about the handhelds. And long before the first Newton prototype that used the AT&T Hobbit CPU (before Apple looked at the ARM). At that time the only systems using the ARM were made by Acorn, most of the rest of the world had not even heard of the ARM, or thought it to be a toy processor of little real value at that time. At the time Apples new products were the low cost 68020 based Macintosh LC, and the 65816 based Apple IIGS. I think that it was either 1989 or 1988 when I got my first Archimedes, and the OS was Arthur (Pre RISC OS).

The newton project may be older than I thought, though that would have definitely been when Apple was still playing with the AT&T Hobbit CPU, if the project even existed inside of Apple (I know that they used to be pretty good at keeping secretes for years at a time).
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: RISC OS Assembly Tutorials.

Wed Nov 06, 2013 6:24 am

DavidS wrote:
DexOS wrote:Thanks i will give it a try, yes at the time i was running at 800*600 and got buffer size of 6mb :? .
I will try at a higher res.
Note: I was on a very old ver of RISC OS, but today i got the latest ver.
Ok it apears that the row length is significantly greater than the visable width. I think that this could be the cause of the difference in lower res modes.[/b].
Yes, this turned out to the problem with off screen buffer not working, it was being filled with more date than the size of the from buffer.
I now use OS_ReadModeVariable and get the X Y size (which need 1 adding to them ) and multiply them to get screen size.
Batteries not included, Some assembly required.

User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: RISC OS Assembly Tutorials.

Wed Nov 06, 2013 12:33 pm

DexOS wrote:
DavidS wrote:
DexOS wrote:Thanks i will give it a try, yes at the time i was running at 800*600 and got buffer size of 6mb :? .
I will try at a higher res.
Note: I was on a very old ver of RISC OS, but today i got the latest ver.
Ok it apears that the row length is significantly greater than the visable width. I think that this could be the cause of the difference in lower res modes.[/b].
Yes, this turned out to the problem with off screen buffer not working, it was being filled with more date than the size of the from buffer.
I now use OS_ReadModeVariable and get the X Y size (which need 1 adding to them ) and multiply them to get screen size.
I found that in some of the lower resolution modes you will fill only as little as 1 fourth of the screen doing this. This is due to the length of the row being much greater than the visable width.

As writing to memory is slow by its nature, I modified the source to loop for the width, add the difference between the Xres and Rowlen in an outer loop for the number of rows, this is faster in many modes as it is not writing to a huge off screen area. I guess you could special case those modes where the RowLenght is equal to the XRes.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: RISC OS Assembly Tutorials.

Wed Nov 06, 2013 3:55 pm

Adding another entry to the game creation thread. This one to do things correctly.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

SEDev
Posts: 34
Joined: Thu Aug 02, 2012 10:55 pm

Re: RISC OS Assembly Tutorials.

Wed Nov 06, 2013 8:47 pm

DavidS wrote:This is due to the length of the row being much greater than the visable width.
The LineLengh his the number of bytes required to store an entire line. Hence it's (number of pixels * bits per pixel) / 8. In 8 bpp mode it will be the same as the X resolution. In lower a bpp it will be smaller, in higher a bpp it will be bigger than the X res.

Also keep in mind that there are two buffers that matter here. There is the buffer that's held by the video hardware (GPU on RPi, videocard on Iyonix) for which you can find the address using GraphicsV (as you're doing) or reading VDU variable 149.

The other buffer is the RISC OS screen memory which is located in main memory. Its address can be found by reading VDU variable 148. The screen memory buffer can be much smaller than the video buffer. Here on the Iyonix the screen buffer is 9 MB (1920 x 1200 @ 32bpp), the video memory is 32 MB.

I've played a bit with TutFade and the original is quite slow (on the Iyonix). There are two reasons for this: 1) the video card is at the other end of the PCI bus and sending lots of one word stores to it isn't ideal. 2) The video memory is rather big (compared to screen memory). So I modified the code to use the screen memory and it's much faster.

Finally I changed the code to OS_Plot to plot a rectangle the same size as the screen with the background colour. This is faster still as it is accelerated by the video card. To put it into numbers:

Using video memory: 240 s
Using screen memory: 44 s
Using OS_Plot: 1.6 s

I don't know if graphics acceleration has been implemented on the RPi but using OS_Plot might be worth a look.

User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: RISC OS Assembly Tutorials.

Wed Nov 06, 2013 9:01 pm

@SEDev

No there is not graphics accelleration on the RPi. The Row length on my RPi when running in 1024x768x32bpp (and hdmi_group=2 hdmi_mode=16) is 4096 pixels (16768Bytes) thus I am only writing to the first 4096Bytes (1024 pixels) in the current implementation (or what ever the current XRes is).

You may wish to take a look at the Version that I posted today and see how it compares. Due to the lack of accelleration and the fact that Video Memory is in the main SDRAM chip it is faster than using OS_Plot on the RPi. Though it is good to know that it works with the IYONIX. That is with a NVidea video card correct???
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

AMcS
Posts: 184
Joined: Sun Jan 06, 2013 11:23 am
Location: Dublin, Ireland

Re: RISC OS Assembly Tutorials.

Wed Nov 06, 2013 9:39 pm

kevans67 wrote:@DavidS - interesting. I've lived in CA since about '72 and have never seen an Archimedes. I think that one of my friends must have been working on the Newton project sometime around the time you got the Archimedes. My understanding is that Apple influenced the ARM ISA in the early days.
Not particularly early days.... Acorn released the first ARM chip (with no Apple involvement) in 1985, the second iteration ARM 2 (which only added the MLA and MUL instruction, added a coprocessor bus and was clocked a bit faster) was released in both the Acorn Archimedes (the first mass market RISC computer released in 1987) and in the Acorn "Springboard" PC co-processor card which turned a fairly pedestrian PC into a high powered workstation (see http://acorn.chriswhy.co.uk/docs/Mags/P ... board.pdf)

Apple didn't really get involved in the ARM ISA until ARM610 and the Apple Newton. Again as far as I know they required that the ARM would permit either big or little endian data (this was a historical affectation because Apple had used the Motorola M68000 in their Lisa and Macintosh - and that has different byte ordering from the other processors (such as Intel, ARM etc.,)). The second thing they required was that the Program Counter (PC/R15) would no longer contain both the PC and Status flags (Acorn originally did have the PC/PSR in R15 as it meant you could preserve or restore BOTH the Program counter and Flags with one LDMFD or STMFD instruction saving some time and one additional instruction). Apple didn't see the need and thought having a 32 bit PC was better than having a 26Bit one.

The Apple R15 arrangement allowed for much larger programs (up to 4GB) while the Acorn one allowed only 64MB (if you find any Acorn RISC OS program that size - even ones ported from Linux please let me know.... as I'd be very surprised).

In the ARM610 (used in the Newton and RISC PC) the R15 use could be used in either the mode favoured by Apple (32bit) or the one favoured by Acorn (26Bit PC) mode. The last processor to support both was the DEC StrongARM all processors after that used a 32bit PC and RISC OS had to be updated to support this use.

User avatar
DavidS
Posts: 3096
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: RISC OS Assembly Tutorials.

Sun Feb 15, 2015 5:51 pm

Sorry for the long absence. I got myself to wrapped in the wron side of RISC OS programming for a bit, and got frustrated to the point that I used only my Atari computers for the last, I think it has been over a year??

Though I will always preffer RISC OS. I think that I will work on providing a new set of assembly language tutorials for RISC OS, on this forum. I will use a simple game to show the application of programming a dynamic updating WIMP application in RISC OS using pure assembly language. I will provide examples in both ExtASM and BBC BASIC V format.

I am again on my RPi, and that is again my main computer with RISC OS as the only operating system. I am just going to treat RISC OS itself as closed source, just as I did for years before ROOL came about.

I will start a new thread for the new set of assembly language programming tutorials. I hope that some enjoy this.
26-Bit R15 to 32-bit. 16-bit addressing to 24-bit. ARM and 65xx two CPU's that continue on, and are better than ever. Assembly Language forever :) .

Return to “RISCOS”

Who is online

Users browsing this forum: No registered users and 2 guests