Date : Tue, 03 Jul 2018 17:23:46 +0100
From : soruk@... (Michael McConnell)
Subject: Announce: Brandy Basic - with teletext?!
[Replying back to the list]
Unfortunately, SDL 1.2 doesn't appear to have that concept of just
changing a colour palette entry and letting it do the hard work for me.
I implemented Flash in Mode 7 by maintaining two copies of the display
screen, and on the timer flipping between the two. Normal screen writes
are sent to both copies, but flashing characters only sent to one.
So, in theory, in Mode 2 and other 16-colour modes I may implement in
the same way, just for colours 8-15 write the alternative colours in the
two banks, then the bank flipping will give the illusion of flashing
colours.
On 03/07/18 15:14, Rob wrote:
> Flashing in the other modes was implemented as a binary NOT of the base
> colour specified.? The Base colours are mapped via a pallette, so you
> can have whatever colours you want in each mode, subject to the limit on
> total. Assuming the palette is supported already, (I know nothing about
> brandy basic) and changes act immediately, all you should have to do is
> add something to fiddle with the pallette for colors 8-15 at an
> appropriate frequency. Should not need to touch screen memory at all.
>
> Rob
> --
> Sent from a mobile device. Please excuse brevity or spoiling mistooks.
>
> On Tue, 3 Jul 2018, 12:41 Michael McConnell, <soruk@...
> <mailto:soruk@...>> wrote:
>
> Bad form for replying to my own post, but as it's now another day, I've
> uploaded V1.21.1 - which includes working flash (and MUCH faster
> background colour changes).
>
> The implementation I'm following is that of a BBC Micro MODE 7 (and
> testing against the version emulated by RISC OS in RPCEmu), rather than
> that of a Viewdata / broadcast Teletext display.
>
> Now I'm wondering what it would take to extend the bank switching stuff
> to the other 16-colour modes (e.g. MODE 2) to implement flashing
> colours
> there....
>
> On 02/07/18 21:49, Michael McConnell wrote:
> > I'm thinking about double buffering too, but that is a project for
> > another day!
> >
> > On 02/07/18 20:59, Rob wrote:
> >> If you can emulate an entire BBC Micro in *javascript* within a
> browser
> >> window, then I wouldn't expect a compiled native application to
> have any
> >> problems at all.
> >>
> >> FWIW, teletext graphics, and the way the various control codes
> interact,
> >> can be quite tricky to get right. Hold Graphics is the one that
> trips a
> >> lot of people up, as it can show up mistakes in the coding of other
> >> control codes (some take effect on the cell with the code, some
> only on
> >> the cell after!) And then you have to decide if you are
> implementing a
> >> "proper" viewdata/teletext display, where a double height code
> maps the
> >> line onto the line below, and ignores (but still remembers!)
> whatever is
> >> stored in memory for the second line, or a BBC Micro mode 7 where it
> >> uses that second line and can therefore produce funky effects. It is
> >> very satisfying when you get it all right!
> >>
> >> Even on a Beeb it's not that easy: Back in the 80s, I was
> contacted to
> >> write a viewdata terminal emulator for the Beeb. It was actually
> quite
> >> hard to get double height working "properly" using the Beeb's
> hardware.
> >> I.e. What happens if you overwrite the double height control
> code on the
> >> first line? All the terminal emulators I had tested got it wrong, as
> >> they had already discarded the second line (in order to cater
> for the
> >> Beeb's hardware, which needs both to be the same) and which
> should now
> >> be visible, and is allowed to contain something completely
> different to
> >> the first!? My approach was to write the data into a separate
> buffer,
> >> and copy into screen memory on the vertical sync timer. That way
> I could
> >> deal with double height, and Reveal (Conceal being another code
> that the
> >> Beeb obeys, but then has no way of revealing the hidden characters.)
> >>
> >> Rob.
> >> --
> >> Sent from a mobile device. Please excuse brevity or spoiling
> mistooks.
> >>
> >>
> >> On Mon, 2 Jul 2018, 19:38 Pete Turnbull,
> <pete@... <mailto:pete@...>
> >> <mailto:pete@...
> <mailto:pete@...>>> wrote:
> >>
> >>? ? ? On 02/07/2018 15:59, Michael McConnell wrote:
> >>? ? ? ?> I guess, with the way the screen is currently done
> (including the
> >>? ? ? other
> >>? ? ? ?> modes) that it would be computationally far to expensive
> to scan the
> >>? ? ? ?> screen for what should be flashing pixels. For Mode 7 at
> the very
> >>? ? ? least
> >>? ? ? ?> to get a 100% true emulation it would need to maintain a
> 1000 byte
> >>? ? ? ?> screen memory buffer (somewhat akin to the BBC Micro
> screen memory at
> >>? ? ? ?> &7C00) and re-render the entire screen periodically
> >>
> >>? ? ? Hmm.? Sometime in the late 1990s I wrote a Viewdata client
> for Unix (or
> >>? ? ? more specifically, for IRIX on an SGI Indy running at
> 180MHz).? I
> >>? ? ? needed
> >>? ? ? it for HOBS, the Bank of Scotland online banking system,
> which I had
> >>? ? ? previously used on a Beeb and then an A440.? I had
> graphics, flash,
> >>? ? ? double height and separate/contiguous etc working properly
> then, so I
> >>? ? ? find it hard to believe it can't be done two decades later
> on 20x
> >>? ? ? faster
> >>? ? ? processors, though I guess it might depend on what it's
> written on top
> >>? ? ? of.? I've forgotten exactly how I did it but AFAIR I did
> use a double
> >>? ? ? buffer.
> >>
> >>? ? ? --
> >>? ? ? Pete
> >>? ? ? Pete Turnbull