read vptr value

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


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

Re: read vptr value

Post by ericde45 »

yes, i did the same analyze.
but that's not so easy :)

placing a branch instruction on the IRQ event vector is ok
but checking that the event is vsync is not that simple
User avatar
SKS1
Posts: 18
Joined: Sat Sep 19, 2020 12:04 am
Location: Highland Perthshire
Contact:

Re: read vptr value

Post by SKS1 »

Just check the IOC IRQ Status Register A for VSync - if it's set, clear it using IOC IRQ Clear register and just return from interrupt after calling your VSync handler. Pass everything else on to the old IRQ handler.
User avatar
SKS1
Posts: 18
Joined: Sat Sep 19, 2020 12:04 am
Location: Highland Perthshire
Contact:

Re: read vptr value

Post by SKS1 »

I'd forgotten that the palette might be written at VSync because of flashing colours (good old BBC Micro heritage).

Try using SWI OS_Byte 9,0 to force the first colour to be displayed without flashing.
User avatar
ericde45
Posts: 59
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

hello !

i am trying to modify vidc values.

i followed what qUE explained, i used customvdu to create and export a mode
i then dissassemblied it, and got the VIDC registers values from the module

on arculator, putting directly the values in the VIDC in supervisor mode is working fine

but on a real A4000, the screen loose the synchronisation

is there any steps to follow before modifying VIDC ? i tried a vsync just before, and adding nopS between the VIDC writes

maybe stop IRQ and FIRQ ? ( if anyone has a code to do this, i would be interested, as i only found an example for later ARM )
steve3000
Posts: 2442
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: read vptr value

Post by steve3000 »

So does the mode module that you created with CustomVDU work correctly on the A4000, but the values that you pulled from the disassembly do not work when you send them to the VIDC directly?

Could be many reasons for this (emulation is much more forgiving!) - what screen mode are you starting in? What monitortype is the A4000 configured for (15kHz, multi scan, vga?), and what type of screen are you using?
User avatar
ericde45
Posts: 59
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

what i did is that i noticed in the customvdu module and in the original mode 97 module made by Stephen Harrison, that there was a list of VIDC registry values, so i just put them directly in my code and push them to the VIDC
( 11 registry entries in original mode 97 module, 14 in the Customvdu version )

.long 0x803FC000
.long 0x84048000
.long 0x880ec000
.long 0x8c0a4000
.long 0x903e4000
.long 0x943ac000
.long 0xa04dc000
.long 0xa4008000
.long 0xa8094000
.long 0xAC094000
.long 0xB049C000
.long 0xB449C000
.long 0xe000000c
.long 0x9c400000

this works fine in Arculator

i don't own a Archimedes currently, so i have to ask an A4000 owner to do some tests for me.

he uses a 15 kHz RGB monitor. my code with a RMRUN of the module before, and a mode 97 call in the code, runs fine on this monitor. put my direct 'poke' in the VIDC causes the synchronisation issue

and i don't know how the Risc OS handles this list exactly.
sirbod
Posts: 1216
Joined: Mon Apr 09, 2012 9:44 am
Location: Essex
Contact:

Re: read vptr value

Post by sirbod »

ericde45 wrote:
Tue May 04, 2021 5:49 pm
on arculator, putting directly the values in the VIDC in supervisor mode is working fine

but on a real A4000, the screen loose the synchronisation
Simply put, your mode isn’t compatible with actual hardware.

It’s either too thin, too wide, too short, too tall, too little or too much front/back porch, not enough vsync or fly back period, or needs too much bandwidth!

Post your parameters and detail the low level spec of the monitor you’re trying to run it on, the two go hand in hand if you’re trying to overscan. If you’re trying to keep it VGA compatible things get a bit simpler as there’s some hard limits.
User avatar
ericde45
Posts: 59
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

the mode is working on real hardware, either the mode 97 module directly or the same rebuilt using customvdu ( i just launch the mode 97 module, then use customvdu to create an export of the mode 97)

but that's when i just set the VIDC values directly, that it is not working on real hardware. using either of the 2 modules above is working on real hardware

so i think that the module sets the VIDC values but does it a way that is working on real hardware, or change some other values somewhere in the MEMC or VIDC or anything i don't know about.

do you know how to ask Risc os to write values to the vidc ? or is there a good way to write to the vidc ?
steve3000
Posts: 2442
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: read vptr value

Post by steve3000 »

sirbod wrote:
Wed May 05, 2021 6:09 am
ericde45 wrote:
Tue May 04, 2021 5:49 pm
on arculator, putting directly the values in the VIDC in supervisor mode is working fine

but on a real A4000, the screen loose the synchronisation
Simply put, your mode isn’t compatible with actual hardware.
Not quite right if it's the mode module I wrote for Xavier (as Eric has just added). This does work on the A4000...because I wrote it and tested it on the A4000. ;)

But we really need to see the code... There is more to changing screen modes than just sending values to VIDC if you're using newer hardware (the A4000) than the original 8 MHz Archimedes range (A305, A310, A4x0, A3000).

For example, the A4000 contains multiple clock speed crystals for the VIDC, have you selected the correct VIDC speed for your screen mode using the clock select latch?
User avatar
ericde45
Posts: 59
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

my code is the following. very simple :)
is the clock select latch part of the VIDC registers ? or is it in MEMC ? ( searching through scanned PDF of VLSI books does not work very well using OCR :) )

MOV R0,#19
SWI OS_Byte

SWI 22
MOVNV R0,R0




; update pointeur video hardware
ldr r0,screenaddr1_MEMC
mov r0,r0,lsr #4
mov r0,r0,lsl #2
mov r1,#0x3600000
add r0,r0,r1
str r0,[r0]


adr R3,table_mode97
ldr R2,[R3],#4 ; nb de registres
mov r0,#0x3400000

boucle_mode97:
ldr R1,[R3],#4
str r1,[r0]
mov r0,r0
mov r0,r0
mov r0,r0
mov r0,r0
mov r0,r0
.rept 20
nop
.endr

subs R2,R2,#1
bgt boucle_mode97


teqp r15,#0
mov r0,r0

table_mode97:
.long 14
; values coming from customvdu
.long 0x803FC000
.long 0x84048000
.long 0x880ec000
.long 0x8c0a4000
.long 0x903e4000
.long 0x943ac000
.long 0xa04dc000
.long 0xa4008000
.long 0xa8094000
.long 0xAC094000
.long 0xB049C000
.long 0xB449C000
.long 0xe000000c
.long 0x9c400000


----------------------
the values from your module are :

.long 0x803FC000
.long 0x84048000
.long 0x880EC000
.long 0x8C0A4000
.long 0x903E4000
.long 0x943AC000
.long 0xA8094000
.long 0xAC094000
.long 0xB049C000
.long 0xB449C000
.long 0xE000000C
steve3000
Posts: 2442
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: read vptr value

Post by steve3000 »

Yes, nice and simple code :) although you don’t need any NOPs when sending data to VIDC, so you can remove the list of “MOV R0,R0”s.

Your code is making a few assumptions (that MEMC is set up, and a 15KHz screen is in use) but should work fine on the original Archimedes hardware (A305, A310, A4x0, A3000) - which are covered by the VLSI book.

However your code will not work correctly on the A4000, because you don’t account for the new hardware (you assume 24MHz clock, and sync polarity settings - both of these can be changed on the A4000). You need to refer to the A4000/A3020/A3010 technical ref. manual to understand the additional hardware - in this case the clock select and sync polarity latch (these are not part of the VIDC itself).

Alternatively, you could trigger RISC OS mode change call to a similar mode eg. MODE 9, then poke your values to VIDC (although if you do this, it might just be easier to use the mode module and change to MODE 97).
User avatar
ericde45
Posts: 59
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

thanks for all the information i will read the A4000 technical manual :)

i don't want to have the mode 97 file outside my own EXE
but if i am not able to sort this out, i found a solution i think, using your mode 97 + SWI OS_Module 10, to run the mode 97 module from memory, and so i can include it in my EXE :)

( i could also include rasterman this way i think ? )
User avatar
SKS1
Posts: 18
Joined: Sat Sep 19, 2020 12:04 am
Location: Highland Perthshire
Contact:

Re: read vptr value

Post by SKS1 »

Always get RISC OS to set up the system for you as suggested, either by changing first to the best-match mode (one with same bpp, at least as wide and deep as your desired mode) and changing as few VIDC registers as needed, or use a custom mode module. You can't assume that there will be a contiguous set of pages set aside for your screen memory unless you go this route.
User avatar
ericde45
Posts: 59
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

yes, for the video memory allocation, i use the risc os calls
but i set the video pointer myself
i run with 2 pointers for each screen, 1 pointer for real address , 1 pointer for logical address translated by MEMC
steve3000
Posts: 2442
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: read vptr value

Post by steve3000 »

SKS1 wrote:
Wed May 05, 2021 11:22 am
Always get RISC OS to set up the system for you as suggested, either by changing first to the best-match mode (one with same bpp, at least as wide and deep as your desired mode) and changing as few VIDC registers as needed, or use a custom mode module. You can't assume that there will be a contiguous set of pages set aside for your screen memory unless you go this route.
I’d completely agree with this approach.

Although if you’re working outside RISC OS, and not planning to return to RISC OS or use any OS calls at all, you can avoid the memory paging issue by switching to physical memory space (and trampling over RISC OS workspace...!).
User avatar
ericde45
Posts: 59
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

ok so i read the A4000 trm pdf

and i added this before poking the VIDC :

;Video control latch
ldr R2,valeur_IOC
MOV R0,#0
STRB R0,[R2]

valeur_IOC: .long 0x3350048

as i understood, the frequency on the older Archimedes is 24 mhz

and at the beginning of my code, i initialize in mode 9 as you said a few messages before
steve3000
Posts: 2442
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: read vptr value

Post by steve3000 »

Yes, that should set the clock speed and sync polarity correctly. Just make sure your code exits properly (missing exit code after the teqp r15,#0 in the above example). :wink:
User avatar
ericde45
Posts: 59
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

Xavier tested this version with IOC register modfication, and it still does not work on his A4000+monitor
a version including your module + SWI OS_Module 10 to call it, is working fine.
steve3000
Posts: 2442
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: read vptr value

Post by steve3000 »

Ah yes. there is another problem!

You have not set up the E0000000 control register! This is only partly defined by CustomVDU, and is missing the DMA fetch request timing bits (bits 4&5), because these vary depending on the RAM speed of the computer you’re using.

The A4000 has 12MHz RAM, so you need to programme them correctly or the display will flicker and appear out of sync (although technically it’s the data which is out of sync, not the display timings). RISC OS fills in the missing DMA bits based on its calculation of the RAM speed, when performing any screen mode changes. This DMA issue won’t appear on any emulators.
User avatar
ericde45
Posts: 59
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

in my table, the value before the last value is : .long 0xe000000c
the end of this value is 0b0000 1100

and in your module it is also 0xE000000C

which sets :
DMA Request
00 - End of Word 0,4

from the VLSI VIDC documentation

what did i miss there ?
steve3000
Posts: 2442
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: read vptr value

Post by steve3000 »

ericde45 wrote:
Wed May 05, 2021 10:00 pm
in my table, the value before the last value is : .long 0xe000000c
the end of this value is 0b0000 1100

and in your module it is also 0xE000000C

which sets :
DMA Request
00 - End of Word 0,4

from the VLSI VIDC documentation

what did i miss there ?
You missed that CustomVDU doesn't set the correct value for 12MHz RAM on the A4000. So you've used the incorrect value, because CustomVDU provides the wrong value - since it knows RISC OS doesn't use this value, RISC OS calculates the required value itself at time of MODE change. If you're not using RISC OS, you need to determine the RAM speed (or read from RISC OS zero page) and adjust bits 4&5 of CR depending on the RAM speed. I've never seen details of the required calculation published anywhere unfortunately. In the past I've used trial and error to determine the correct value (only 4 possibilities) for 8MHz and 12MHz computers, then stored a table to use this at run-time. Although beware if your code ever runs on an overclocked computer, because then you can't rely on a table and really need to calculate the RAM speed and determine the correct value...

If you want to find how RISC OS does the calculation, you can read through the disassembled code in my RISC OS disassembly, I think I have flagged the MODE change code...but not sure I gave many comments on these though.
User avatar
ericde45
Posts: 59
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

thanks for the long answer

i already saw your Risc OS dissassembly, and that's a huge work to dive in.

you must have spent a lot of time working on Risc OS.
Total respect for this, by the way !
User avatar
ericde45
Posts: 59
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: read vptr value

Post by ericde45 »

next steps :
- i tried mode 9 + no modification of value 0xE000000C : does not work on real A4000

i tried the 4 values for 0xE000000C, with bits 4 & 5 ( DMA request ) : none of them works

what is working is including your mode 97 in my EXE, and call it from memory, so using the Risc OS mode command.

i think that i will come back to this when i have a real Archimedes on my desktop.

this tests rise a question : if the bits 4 & 5 change linked to the hardware, optimising the memory access of the ASM code including DMA accesses optimisation, is quite useless ?
steve3000
Posts: 2442
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: read vptr value

Post by steve3000 »

You can optimise your code for memory access timings, eg. using quad-word aligned loads, which make a real improvement.

I'm not sure you can 'optimise' any DMA (other than disable/enable or maybe tweak timing of sound DMA) because these are all fixed in hardware.
Post Reply

Return to “32-bit acorn software: other”