Part 1 of PRM

OK. The Character Sets page is unhappy with some of the UniCode chars (e.g.  ) so I’ll investigate further. I’d also like to eliminate the white space between cell borders.

Edit: Re: cell borders – I’ll try global table borders, then turning off in rows/cells as required (the opposite of my current attempt). (No luck. If someone knows how to do this in Textile, please incorporate to see how it looks.)

1. Knock up a BASIC prog to generate textile code for the first table;
2. Check for other standard alphabets;
3. Tackle BFont and teletext chars (images will presumably need to hosted for these).

I think the problem is that characters 128-159 (aka x80 to x9F) aren’t part of the Latin 1 character set (Although I think 128 is now standardised as being the euro symbol). And since they weren’t/aren’t part of the standard, RISC OS has been happily inventing its own uses for the characters (e.g. window furniture icons). So you might have to do some digging through all the different Unicode symbol codepages to find appropriate Unicode characters for use on the web. Or you could resort to displaying images – perhaps taken directly from the RISC OS system font (I’m guessing there won’t be any copyright issues with reproducing the font on the wiki – after all, the font is freely available in source form from CVS).

Similarly for the BBC/teletext font – RISC OS 5 uses a “high-res” bitmap font in mode 7, so if you can find the source to that in CVS then you should be able to reproduce it as-is. There’s a doc about the high-res teletext mode here, although I’m not sure if the relevant source bitmaps are anywhere nearby. (That doc also contains some info about new VDU codes, so those will have to be wikified at some point too)

I think the problem is that characters 128-159 (aka x80 to x9F) aren’t part of the Latin 1 character set…

In RISC OS 2 characters &80 – &9F (128 – 159) are undefined.
In RISC OS 3 (version 3.00) characters &80 – &8B (128 – 139) are undefined.

I’m happy to resort to using images if necessary, but I’d have to ensure they’re of sensible dimensions and outline fonts might be better as SVGs. As for the HiResTTX font, that’ll be the pièce de résistance of the Character Sets docs!

I’m happy to resort to using images if necessary, but I’d have to ensure they’re of sensible dimensions and outline fonts might be better as SVGs.

I updated the character sets table to display the html/ascii codes, but as you say some of the codes are not the same, or undefined. If the ROOL guys find some spare time in their rather hectic schedules to update the wiki to handle images then this is definetly a page that would a prime candiate to use it.

@Trev,

I also noticed that the text was copied and pasted directly from Acorn’s PRMs. Unfortunately we do cannot do this due to copyright restrictions, so it will need to be rewritten. Sorry about being the bearer of bad news. It’s a nuisance, but necessary.

Thanks Alan. I see you’ve also corrected my row/col encoding error in the output generated for the table. (Do you have a Textile table generator/translator or something? I used loops in BASIC and ended up *SPOOLing the output, after forgetting that file handling output results in strings being reversed.)

As for the direct copy/paste, it should be considered as a proof document for the moment. I’ll paraphrase/rewrite when I can (maybe tonight but certainly within the next week).

I used loops in BASIC and ended up *SPOOLing the output, after forgetting that file handling output results in strings being reversed.

Use BPUT :)

Use BPUT :)

Thanks from a resident novice… never really learnt all this, as was cassette based at the time!

Do you have a Textile table generator/translator or something?

When creating large textile tables, I create an Excel spreadsheet. By using formulas it becomes a pretty quick thing to produce. Then I simply copy and paste into Word, and then quickly remove all the Tab characters. Job done.

Just for your info, I haven’t been doing any ROOL documenting as I wanted to take a break for a while, and then some other commitments came my way, but I hope to get started again pretty soon. Part 2 – next stop.

A big well done to everyone working to improve RISC OS. It’s pretty exciting to see so much activity and improvements being made. From bug squashing to complete video driver implementations.

I also noticed that the text was copied and pasted directly from Acorn’s PRMs.

Character Sets has now been reworked. I’ve also used strikethrough in some RO2 references but this can be removed if undesirable or out of keeping with the rest of the PRMs.

VDU Codes now includes a link to a separate VDU 24 page. Alan, if you’d like to amend the layout in accordance with a house style please do so. I’ll then continue with the rest of the VDU codes as and when I find time. Thanks.

I’m also wondering whether the (embryonic) tables within Character Sets should be migrated to a separate page (or pages, meaning people could easily view different char sets in separate windows). Suggestions?

Alan, thanks for the amendments. Recent additional pages are based on BBC BASIC docs – I’ll amend with reference to StrongHelp docs when possible. Apologies for inaccuracies in the mean time.

I’m having some difficulty using internal hyperlinks without headings (e.g. works for the Latin1 alphabet and Stroking and Filling but not VDU 20 . I’d like to cross reference to specific rows within the table, e.g. ‘See also’ within VDU 19 .

I’ll tackle VDU 23 next, listing all on one page with internal hyperlinks (which should work fine in conjunction with headings).

TIA for comments/advice/amendments.

I’ve made the necessary change so VDU 19 references the correct row in the VDU Codes document.

Also added some new anchors up to VDU 22 for you, but didn’t do the rest as I’m not sure how you intend to handle codes such as VDU 23,2-5. I’ll leave that for you!

Looking really good. Great work mate.

• Various bits need updating to reflect 26/32bit neutrality issues – “Error handling – an introduction” talks about the PSR bits being in R15, “Technical details” (of SWIs) mentions using MOVS/ORRS to return from the SWI code, etc.

Just a cross reference for when we’re on to Part 2 (a little premature, I know):

Ticket #201 – Documentation change: size of error buffer will require incorporation within Program Environment > Handlers > Error.