That's fantastic - thanks. The VIEW that I disassembled had also evidently been heavily 'squeezed' to fit in the E00-FFF space - several 'crazy' sequences and loops just to save a byte or two here and there vs how a sane person would have written it.I've attached the full source of the SJ *VIEW (BBC Basic ASM source) - it's fairly well commented, but has the usual sort of obfuscations caused by squeezing the code for size.
I'm intrigued by the top comment "Has the ability to VIEW through bridges by transferring in 1KB blocks" - this must be a limitation of bridges I wasn't aware of / hadn't considered -- though there's a similar apparent RISC OS limitation that I had to work around with !ViewBeeb in that it faults PEEKs of greater than 8KB. -- the original VIEW code just does one whopper up to the full 20KB. I shall have to get my bridge out and see what limitation it actually has. Fortuitously, a MODE 7 screen is only 1KB anyway.
HA! I hit that problem when developing ViewBeeb running on RiscPC/etc - even in BASIC, it turns around the PEEK after the RPC so quickly a poor Beeb hasn't had time to set up the buffer, so I actually have a true timed delay in there (0.2 sec) which 'fixes' this. The original VIEW has no specific delay implemented between these calls.There's a theoretical issue that I thought could be something to do with it, but on investigation probably not. The OS Procedure Call &85 takes a while to execute (ie. the RPC transaction on the network takes place under NMI interrupts, but the actual execution of the code - in this case code to extract all the mode data and collect it into a little buffer - takes place a bit later under an IRQ posted by the NMI handler.) The DNFS code has some comments about how you tell if the buffer contents are valid, but they don't seem to match the code, and the SJ *VIEW doesn't seem to do anything about it (presumably assumes that things are slow enough that it's always ready by the time we read it).
Statistics: Posted by IanJeffray — Sun Jun 01, 2025 12:57 am