Starting ADFFS hangs the A3000

[Radiofan]

Some progress. I downloaded the latest source and ExtAsm and got the module to build. Then I gradually narrowed down the point of failure during the module initialisation. Commenting out the STRB line allows the module to start:

Code: Select all

	LDRB	R3,[R1,#0]			; Grab the result
	TST	R3,#&20				; Is bit 6 set?
	MOVEQ	R3,#0                           ; Yes,
	MOVNE	R3,#1                           ; No,
;	STRB	R3,IIC25MHzFitted		; Store the type of Enhancer

I was then able to get the status:

CIMG2412.JPG (1.72 MiB) Viewed 1817 times

CIMG2411.JPG (1.19 MiB) Viewed 1817 times

Strange because the WE VIDC board does have a 25MHz crystal fitted. Maybe there is something wrong with the selection of this clock.

[JonAbbott]

Thanks for that diagnostic info, I'll follow that code path and see if I spot any potential issues.

[Radiofan]

You might find the schematic helpful:

WE_SVIDC_SCH.png (156.13 KiB) Viewed 1809 times

Note that P0 and P1 are wired in reverse to S0 and S1. I have taken a look at the code in SWI_Funcs._useWEVIDCEnhancer but it's quite convoluted. I find it hard to understand what get written to out to P0-P7.

[Radiofan]

Found it. In the file SWI_Funcs:

Code: Select all

._useWEVIDCEnhancer
	MOV	R1,#WEVIDCBaseValue
	LDRB	R2,IIC25MHzFitted		; If the 25MHz clock isn't present,
	TEQ	R2,#1
	ORREQ	R1,R1,#&20			; If the 25MHz clock is there, set the 6th bit.
	ADDNE	R3,R1,#3
	ADDEQ	R3,R1,#2

The last line should be:

Code: Select all

	ADDEQ	R3,R1,#1

autovidcstatus is now showing the clock running correctly at 25.175 KHz.

I think a new version of autovidc is due...

[JonAbbott]

Well spotted, I'll correct and update the version bundled with ADFFS with the next release.

I'll have to see if it's possible to feed the changes back to GitHub, I'm not entirely sure who's maintaining it these days.

[Radiofan]

FYI, I have created a fork and a pull request for the fix to be merged into the main repo.

[JonAbbott]

I don't think anyone has access to handle the pull. Paul died many years ago and I'm not sure if he set a successor.

I've correct several other issues I've noticed and will probably go though the whole code. There's several unnecessary 26/32bit sequences in it (which I'm credited for ), I can't remember why they're there as AutoVIDC will only work on original Arc's. Our discussions are all on here, so it's probably mentioned somewhere - I've yet to look.

Once I've had time to review and test on my VIDC Enhancer, I'll post both the source and Module on here in its release thread. At some point I'll migrate all the projects I've inherited/develop/maintain over to GitHub.

[JonAbbott]

I've correct several other issues I've noticed and will probably go though the whole code.

Delving into the code turned up a can of worms, there's several bugs that cause it to break under certain conditions and I've ended up replacing large chunks, shrinking it by nearly 2KB in the process and making it ROMable.

The machine detection was being done by checking the RAM speed - so breaks on overclocked machines. I've rewritten that to determine the machine type from the chipset - it needs to know if its on an A4000/A5000 as their clocks are controlled by the OS, everything else (pre A4000) needs a VIDC Enhancer.

The clock detection was begin done by counting how many SoundDMA's occur over 30ms (so ~130ms for all four clock checks). That was problematic as it made making it ROMable difficult and was not particularly accurate. I've completely rewritten it to take over device 9 (Sound System Buffer Change) and to handle the MEMC DMA registers itself, taking the OS out of the loop. It now determines the playback speed by seeing how many T1 ticks occur over a fixed DMA length, which is an order of magnitude more accurate. I want to see how short I can make the DMA buffer before accuracy becomes an issue, to speed up the four clock checks and hopefully reduce or avoid the screen blanking.

After its worked out the clock frequencies, it currently raises a malformed Service_ModeChange to reset the VIDC clock back for the current MODE. As it can now work out the clock accurately, I might alter it to figure out which clock is active when it loads and reset it back once it's finished, avoiding the need for the Service_ModeChange.

Finally, there's some issues with its service handler, which supports RISC OS 2 and RISC OS 3.1x, but doesn't cover RISC OS 3.00 - I've yet to figure out the best way to resolve that.