Raspberry Pi RC16

Steve, I am genuinely serious about updating Zap :-)

As Steve suggests, if people are unfamiliar with git, I would certainly encourage them to learn more about it. There are plenty of excellent resources online for it, and yes git has become a complex and comprehensive tool but the 80/20 rule still applies: you can do an awful lot with git using just a handful of its commands. And git is every bit as relevant for individual developers as it is for teams.

There is a git client in development at the moment that hopefully isn’t far off a v1.0 release, which will hopefully make the RISC OS experience more immediately palatable. Please avoid using CVS wherever possible.

Steve, I am genuinely serious about updating Zap :-)

In that case I’ll collect my sources together.

You’ll find them here: https://heyrick.eu/random/zapsrc20200620.zip

One thing to look at when updating Zap is it’s support for “Big Mode” on the ARMBook. Currently it just ignores it. The only editor I’ve tried that does work correctly is Edit; StrongEd is totally unusable.

What is big mode? I haven’t worked out how Zap chooses character size.

What is big mode? I haven’t worked out how Zap chooses character size.

Snap. I wondered that too.

I’ve got a range of Pi modes from 1920×1080 to 3840×2160 I can use on my monitor, and Zap seems perfectly happy and usable in all of them.

Perhaps it comes out wrong in the 180×180 modes? If so, then everything would appear to be half the expected size? Is that what’s happening?

Scaling mistakes happen from time to time. I don’t think the ARCbbs local terminal ever properly got fixed (Ricky Sarge tended to tell us which words to patch in the executable). And in modern times, it’s woefully easy to get DDT to make a mess of its text redraw (giving half height text in full height spacing). And that’s some of the nicer redraw mistakes it makes. Others can be… weird. ;-)

What is big mode?

An EX0 EY0 mode. If Zap is in any way hard-coded to the idea that there are two OS units to a pixel, and a lot of software of that vintage was, then it could well have issues.

David, as shipped, StrongEd should be OK in BigMode (if not perfect). Some modes may need you to alter the font size though, as I think I only configured basemode and maybe one or two others “out of the box”. Basically, newer versions should be OK, esp if you pick a suitable font.

Zap also should be “ok” if not perfect.

If Zap is in any way hard-coded to the idea that there are two OS units to a pixel, and a lot of software of that vintage was,

One really ought to have looked at the eigen values. It isn’t enough to assume things like that, as back in the day quite a number of people had 2:4 (rectangular pixel) modes and monitors that were basically TVs without the receiver bit. ¹

What may be happening is that ZapRedraw might have optimised routines for the two screen layouts known at the time (2:2 and 2:4) which is why it’s really fast, but not having any functionality for dealing with 1:1 modes…because they didn’t exist until recently.

That’s my €0,02.

¹ The last thing my AKF12 ever did before giving up the ghost was being connected to a DVD player that could output component RGB on its SCART. The film Fly Away Home looked absolutely amazing as a monitor gives a much more stable picture ² even when interlacing.

² Well, most should. The infamous Microvetic Cub, not so much. ;-) But at least MODE 0 was readable!

Is there a way to fake this on a Pi to see what happens? Just interested.

You know, of course, that you can always fake up bigger text by…switching to a bigger font. ;-)

not having any functionality for dealing with 1:1 modes…because they didn’t exist until recently.

*cough* Mode 22 *cough*

Eh? 22 is 768×288. That’s surely rectangular pixel?

Apologies. I’d only ever seen it on a multisync monitor and I assumed it was square pixel. It was Acorn’s first attempt at a “magnified” display… so what would it have been? EX1 EY0 perhaps?

Rick, just run at 1920×1080 (or any other moderately sized base resolution) then menu over the display manager and alter the mode string, adding EX0 EY0. You’ll now be in the same mode, but everything will be twice as large in each direction. Then run your software and see how you get on. It is also worth trying to switch into said mode mid-session, just to see if anything breaks.

Is there a way to fake this on a Pi to see what happens? Just interested.

Yup; just add EX0 EY0 to your mode string. It’s best to set it before the desktop loads, otherwise it’ll use upscaled 34×34 icons instead of 68×68 ones.

Edit: Andrew snuck in before me! :)

And since this thread has apparently turned into a discussion about Zap, can anyone tell me the idea behind ZapFonts? At a glance these fonts don’t seem to be anything special and I’m not sure why it doesn’t just use the standard system-wide fonts.

Zap can use the standard outline fonts, but it works best with its own bitmap fonts. There are many, in many different sizes, including a few UCS (!).
That’s what ZapFonts is for.

StrongEd is totally unusable.

StrongED’s stable release (4.69f11) has issues in ex0/ey0 screen modes but the latest test release (4.70a13) should be fine. In fact, I’m writing this using StrongED in an ex0/ey0 screen mode. All font types (system, bitmap and outline) can be used without problems.

can anyone tell me the idea behind ZapFonts?

Both Zap and StrongED were created around 1990 when computing power was considerably less than it is today. Outline fonts require a lot more horsepower than bitmap fonts so the latter are better if you want fast redraw.

The OS however only supports one bitmap font: the system font. Support for more bitmap fonts and at different sizes has to come from applications themselves. Zap and StrongED are 2 applications that provide such support by offering a collection of bitmap fonts to choose from.

Since there’s no support in the OS, bitmap fonts are written directly to the screen buffer. All the OS does is setting up redraw rectangles everything else is done by ZapRedraw/StrongED. This also explains why these bitmap fonts do not scale when changing the eigen values, an 8×16 character is always written as 8×16 pixels.

All the OS does is setting up redraw rectangles everything else is done by ZapRedraw/StrongED

Does this mean StrongED uses ZapRedraw? What I’m interested in at the moment is what controls the (flashing) cursor position. Zap can turn it off, but is there a common OS method for positioning it manually. There are VDU commands, but they appear to be linked to a moving target in a scrolling window, and where is the C representation of VDU a, b, c etc.?

The OS however only supports one bitmap font: the system font. Support for more bitmap fonts and at different sizes has to come from applications themselves.

I thought I’d seen details of bitmap fonts in one of the PRMs (I don’t have them handy at the moment). It seems that this one was available as far back as RISC OS 2, although I might be misunderstanding.

If Zap is in any way hard-coded to the idea that there are two OS units to a pixel, and a lot of software of that vintage was,

I tested all the combinations of Ex0 to Ex2 and Ey0 to Ey2 a few years ago and fixed a few issues which were included in Rick’s “Zap Ultimate” releases.

and fixed a few issues

Sources?

Does this mean StrongED uses ZapRedraw?

StrongED doesn’t use ZapRedraw, it has its own code to plot bitmap characters.

what controls the (flashing) cursor position.

The application in StrongED’s case (and probably Zap too).

I thought I’d seen details of bitmap fonts in one of the PRMs

The bitmap fonts described in the PRMs refer to outline fonts that have been pre-stored at a specific size in a font’s directory to speed up caching. They need to be plotted using the Font Manager, and can be proportional or non-proportional.

The System bitmap font in the one used by VDU and OS_Write calls. The System font is non-proportional meaning that things like working out where to wrap a line is relatively straightforward, with a proportial font this is more complicated.