Will work on Orics with ROM 1.1 (impossible with ROM1.0 unless the program takes loads of RAM).
The program is using the lower TEXT line so it works both in HIRES or TEXT mode.
The progress bar flashes as the program is loading, and inverts the video as the bar is progressing, so it does not hide or destruct a screen that could have been loaded before. It also avoids using any character as they may be redefined by a loaded program.

The goal was to have it running, being visible and hiding nothing, whatever the state (Hires, and so on). It could be nicer (colour, chars...) at the risk of being affected by pre-loaded modifications.
This can be changed to have sexier look, but destructive for the screen....

I tried something similar with the fast loader for SkoolDaze, where a progress bar was shown (in my case it went from left to right and bounced back using two colors) but the code plus the loader used up too much space in page 1 leaving not enough room for he stack :/

Nice and useful indeed!
What about to merge it with the parity checker and mark in color where check is failed... just and idea .
BTW, Is there any particular reason to support only ROM1.1 (except different address of the used rom routines) ?

Marking in color wouldn't be easy (attributes management + code size increasing) but that's a very good idea!

About ROM 1.0/1.1: in ROM 1.1, loading routines have been re-written and divided in several sub-routines:
- initialize the VIA
- display 'Searching'
- wait for synchro and read header
- display loading and program name
- read a byte
-check if program ends
... and so on!
That means you can call these subroutines and put your own code in between.

But in ROM 1.0, almost everything is done without subroutine, so you can't insert your code.
The only solution would be to copy in RAM the Atmos routines to modifiy them at will, but then my code would jump from something like 130 bytes to probably 1 or 2 kb.

This opens two other problems for me:
1/ Tried at least to detect the ROM1.0 with the progress bar, and then simply CLOAD the next program (to make it transparent with ROM 1.0), but I didn't even manage to. Geoff Phillips gives hints on how to proceed in his book, but this stops the auto-run. So after few days of trying various things, I gave up.
2/ there's a project I started long ago but totally forgot that could be interesting: make standard, minimal and universal (ROM 1.1 or 1.0) loading tape routines in RAM, whatever the size (1k ?) that could be the starting point of any further "tape loading modification" that would then work on any ROM.

Interesting idea. It doesn't say Searching or Loading on the status bar so why not put the display up there out of the way of the main screen ?

It doesn't here because it's a HIRES screen loading
Searching and Loading are still there in TEXT mode. I first planned having the progress bar up there, but it wouldn't work anymore in Hires screen. Only the last 3 text lines are common to both modes!

Very true about the Hires screen loading not really needing a progress bar. But you can:
1- load a Hires screen
2- then load a big program
=> for the 2nd program, the progress bar could be useful, and in Hires screen.

Anyway, I'm currently cleaning the source code and writing a doc before release of the 1st version. Other versions with different looks will probably be released (maybe less "universal" with existing programs, but nicer and with errors detection display).
Letting the user chose the starting address on screen is an idea...

I always wondered why the Oric designers did not include any way of watching the progress of loading. Border colour changes, as in Speccy or C64, but also something simpler as a small animation in one corner of the screen.

It is horrible to keep waiting for a game to load when the Oric had hanged up after the first 3 seconds :/ ... the noise stops and the machine keeps on Loading.. or, even worse in Hires mode, where you simply can't see what is going on at all!

I guess it is just one of the many little details the designers missed (such as being able to access overlay ram without an interface, a way to deactivate serial attributes, buffering in the expansion port,...).

Yeah. I like the loading used by the Electron which loaded in blocks and it said on screen which block was loading. If one part failed you could go back and try loading that again without having to redo the whole lot.

It would be handy to know how much is left to load - i.e a countdown rather than a count up. Or something like percentage shown. Would that sort of thing be possible or is there too little room?

It would be handy to know how much is left to load - i.e a countdown rather than a count up. Or something like percentage shown. Would that sort of thing be possible or is there too little room?

If you look carfully, right after the progress bar program has loaded, it displays immediately the boundaries of the progress bar. Thus you know where it starts, and where it ends.
Displaying a time estimation would be complicated because:
- there are two possible speeds (Fast or Slow)
- according to the data, in Fast mode, the length will be different ("0" longer thant "1")

Percenatge: I begun working at it last year (to display the % on a single byte on screen), but it's faaaar from finished, not sure it could work fast enough, and would make the program about 3 times bigger. So I wouldn't say "impossible" yet, it could be possible but for a specific program, that knows where in RAM it can load the progress bar program.
That's something I'd like to try some day (I'd also love to finish the turbo routines )

EDIT: by the way, the progress bar is divided in 32 parts, so each byte simply means about 3% of the program has loaded