{fb1000000getting bad address offsets all the time. The only way I could manage it was to store the address of the constant I was trying to LDR and load in the address into a register and then load in offset one from that register into another register; confused? Next came the saving of the classified advert which is a *lot* of code. I wanted the output that it produces to look just like a letter, all neat and aligned which wasn't an easy task, believe me. It meant a lot of analysing the icons and only saving out exactly what we need. I had a routine that stripped spaces from the beginning of an icon and a routine that stripped it from the end.
As the address icons have to contain more than one address line I had to work out exactly where each line ended and save it out correctly, which meant a lot of work. First off it counts how many commas and how long it is and if it contains commas it saves the text byte by byte to the file until it comes to the comma. If there's no commas it just strips the spaces from the start and end and saves out the text. After it's saved the address it saves the phone number (if there was one) and then the date. It then saves a little header that says "Dear Sounds Riscy..."
As the advert can be one of two types "For Sale" and "Wanted", it reads in the first byte of the advert icon and if it's 87 or "W" then it knows it needs to copy out 6 bytes, but with "For Sale" it copies out 8. It then reads in the length of each advert icon and saves it out with a space inbetween each. The letter writer is very polite and says "Thanks" and puts another copy of the name below.
With saving out of the way next came printing. Out came FormEd once again to design the window and then I copied it over to the source code. I wasn't handling this part of code so I left it for the time being. Some people wanted the option of switching off the iconbar animation so next came the preferences window. Other options I was to include were "Clear music on return to desktop" which is self explanetary and "Minimise article memory" which means "Should I wipe the article when I return to the Desktop and free the extra memory for other Wimp tasks?"
At this stage we were using sprites of fonts in the window title bar so the whole window looked like a Risc PC window, but Russ said I should remove them as not many other applications that use fonts use them in the title bar. What next? Well next I handed over my code to Lovell who added his code.
{sdiv
Lovell : For my non-desktop code, I started with the plotting of the article to the screen. Plotting directly to screen memory every frame proved too slow, especially if we wanted to use music, so a compromise had to made. I used the under-rated SWI call, OS{_Word, to change the base of screen memory. This is known as using hardware scrolling, as it changes which bit of memory you view on your monitor (for that is all your desktop is, just a block of memory with a colour number stored in each location). To link the scrolling to the mouse position, I took the y position and multiplied it by 640 (width of a mode 15 screen in pixels), and added this to the screen offset. A menu appeared next, with selections that didn't actually do anything (some of which are no longer there, but we won't tell you what they were, 'cos you'll just want us to add them next time).
I started on a fresh source code file to compile an article. A weekend later, I found that the FontManager had a bug in the RISC OS 3 only Font{_ScanString SWI call, and reverted back to RISC OS 2 calls. A very lazy week later this program could change the font size and colour, and plot it, but it was very slow (about 5 seconds per page). Perhaps it was because I was being lazy that I didn't realise that a newline has an ASCII value of 10, and not 13 as I had been using for the past 5 years. It saved out a screenshot, which my other program scrolled fast. I made sure there was a copy of the text stored in 64 byte blocks of memory so I could add the hyper-linking and sprites with ease later. An insignificant week or two passed.
My Christmas exams were now over, so I spent a solid week getting linking together next. This was relatively easy. I used the two SWI calls to find out where to place the caret in a string to see which word had been clicked on in a string. I added the samples and obey file handing in about 10 minutes.
Sprite compression came next. I visited Ian to see his RISC OS 3 programmer's reference manuals (I only have the RISC OS 2 version) for how to use the Squash module. I ran tests against ArcFS, John Kortink's LZW module, my "natural" compression algorithm and Ian's "find a number of similar bytes and store it once" method. It was no surprise to find that both Ian's and my routines fell flat on their collective source codes, and Acorn's 12 bit LZW gave the best compression
