[SPECTRUM] How to use the background colors in basic?
GzavSnap
I had to type-in a game from http://www.hebdogiciel.fr
And plan to change ZmakeBas from Russel Mark.(to add inverted
chars/background colors) [http://zx81.ordi5.free.fr/tools/]
But, if you use "E" and the 0 to 7 key, i can't back to the normal screen!
"E"+"1" put a tag in the basic programme : 11h + 01h
To switch to the blue background color.
But, i can't retrive the transpartent color to type-in the end of line!
10 print "hello ("E"+"1" ) World":cls
where [ World":cls] background steel in blue.
Is there any tag to back to the transparent characters?
Thanks in advance.
spi...@freenet.co.uk
No, your only option is to change it back to the colour it was before the
change , so if it's a standard speccy screen (black on white) then you'd
need to set the background back to white at the end of "World".
The embedded colour codes don't cover transparent and complimentary.
Just use
10 PRINT "hello ";PAPER 1;"World":CLS
--
| spi...@freenet.co.uk | |
| Andrew Halliwell BSc | "ARSE! GERLS!! DRINK! DRINK! DRINK!!!" |
| in | "THAT WOULD BE AN ECUMENICAL MATTER!...FECK!!!! |
| Computer Science | - Father Jack in "Father Ted" |
Paul E Collins
> The embedded colour codes don't cover transparent and complimentary.
I just tried poking in an "ink 9" sequence out of curiosity. I wrote the
program line:
1 PRINT "[ink6]test"
and then poked a 9 over the 6. Strangely, it had no apparent effect on the
listing, which still showed a change to yellow ink. How can this be?
Program bytes from 23755:
0, 1, 10, 0, 245, 34, 16, 9, 116, 101, 115, 116, 34, 13...
Eq.
Matthew Westcott
I just tried the same thing (entering that line, then POKE 23762,9) and
it had the desired effect: it overwrote the yellow ink, and on viewing
the listing with PAPER 1 set, it correctly changed the ink from black to
white at that point.
However, to answer the original question, I don't think there's a way of
embedding a control code to say "revert to the original permanent
attributes".
Incidentally, the latest version of zmakebas allows you to insert
control codes (and any other arbitrary bytes) into the listing using the
syntax \{123} (decimal) or \{0x1f} (hex).
GzavSnap
HI,
Ok spike1.
ZmakeBas updated at [http://zx81.ordi5.free.fr/tools/]
CF HTML doc. [specials characters]
Have Fun.
Edward
> Incidentally, the latest version of zmakebas allows you to insert
> control codes (and any other arbitrary bytes) into the listing using the
> syntax \{123} (decimal) or \{0x1f} (hex).
Just sayin'.
--
"Sanity" is the last refuge of the unimaginative.
visit my useless website -- http://dev-null.chu.cam.ac.uk
Paul E Collins
> However, to answer the original question, I don't think there's a way of
> embedding a control code to say "revert to the original permanent
> attributes".
The Plus D disk system added a surprisingly useful CLS# command, which
cleared the screen *and* the attributes. Whenever I write a program, even a
lame CSSCGC entry, I always feel obliged to do it completely and thoroughly
in the first line (OVER and all), and it's very tedious.
Eq.
Paul E Collins
> I just tried the same thing (entering that line, then POKE 23762,9) and it
> had the desired effect: it overwrote the yellow ink, and on viewing the
> listing with PAPER 1 set, it correctly changed the ink from black to white
> at that point.
Well, this is really weird. I tried it again, and Spectaculator *does* leave
the ink as yellow in the listing, even when the byte at 23762 can clearly be
seen (by PEEKing) to be 9, or 1, or anything else.
It could be an emulation bug in Spectaculator, but since that doesn't have
any special BASIC optimisations (as far as I know) it's hard to imagine how.
Can someone clear up this strange mystery?
Eq.
Paul E Collins
> leave the ink as yellow in the listing, even when the byte at 23762 can
> clearly be seen (by PEEKing) to be 9, or 1, or anything else.
>
> It could be an emulation bug in Spectaculator, but since that doesn't have
> any special BASIC optimisations (as far as I know) it's hard to imagine
> how.
>
> Can someone clear up this strange mystery?
Okay, stranger and stranger. I got someone else to try it (in Mac Fuse) and
it worked as expected for him. Then I found out he was emulating a +3 in 48
mode, whereas I have been emulating a +2 in 48 mode.
I emulated a +3 and it worked properly; a genuine 48 and it worked properly.
Then I switched back to +2 mode and *it worked as well*. I closed
Spectaculator, relaunched it (as a +2 again): got the same weird behaviour,
1 (blue) in memory but yellow on screen.
And now I can't reproduce it at all. I *definitely* saw this, on about four
occasions across two days, and I double-checked my PEEKing (f'nar). There is
something very subtly wrong here. If I can do it again, I will save a
snapshot, but right now it doesn't seem to be happening.
It's like that bloody register that behaves differently depending on how hot
the machine is, eh?
Eq.
Paul E Collins
>> Well, this is really weird. I tried it again, and Spectaculator *does*
>> leave the ink as yellow in the listing, even when the byte at 23762 can
>> clearly be seen (by PEEKing) to be 9, or 1, or anything else.
I've done it again, and this time I have proof:
http://aloneonline.net/weird.szx
http://aloneonline.net/weird.z80
Somebody please look at these and explain before I go mad :)
Eq.
Matthew Westcott
You have a second copy of the program in memory beginning at 23813, and
this seems to be the one that the BASIC environment is pointing at:
poking 23820 does the right thing.
Unless it's just a weird default that FUSE is setting when I load it, it
appears that your snapshot has Interface 1 enabled, and - dredging
through my vague recollections of using microdrives - I believe they
attached special behaviour to the RUN command where it would load a
specific 'autorun' file off the cartridge. So, my theory is:
- Spectrum boots up; Interface 1 is inactive
- You type in your program. It gets stored at 23755
- You enter RUN, which activates the IF2 (either that, or it happens
when you break out of the program, and the IF1 traps the RST 08 call.
Something like that) and causes it to initialise its stream area and
assorted gunk
- In the process the BASIC listing gets relocated to 23820, and system
variables are updated to point there
- 23755 is now an unused bit of memory (the printer buffer, possibly?)
so the old copy of the code doesn't get overwritten, and remains there
to confuse you.
Edward
copies of a program line (afaik without an IF1, though I use FUSE so if
it /does/ have a weird default then I may be talking nonsense). As I
understand it, when you are editing a program line (or typing in a 'line
0' for immediate execution), you don't edit in-place but rather the edit
buffer is stored elsewhere in RAM, in fact just below the program area.
When you enter the completed line, it is stored back into the program
area, but *the editing buffer doesn't get overwritten*. As a result,
there's a vestigial copy of the line which will never again be read
from, so if you've poked into that instead of the actual program line,
it won't affect the colour.
-Edward
GzavSnap
Hi,
http://zx81.ordi5.free.fr/tools/zmakebas-1.1.zip
Updated.
Changed : Foreground and background colors + Tzx format.
Have fun.
GzavSnap
Hi Matthew,
| > Incidentally, the latest version of zmakebas allows you to insert
| > control codes (and any other arbitrary bytes) into the listing using the
| > syntax \{123} (decimal) or \{0x1f} (hex).
| ... as does bast, since version 0.1.6, with syntax \1f (hex only).
Is there any links to download this release?
google throw me to the 1.1 release!
Guesser
Matthew Westcott
Hmm, you're right... 1.2 seems to be missing from the ibiblio server.
I've uploaded it here:
ftp://ftp.untergrund.net/users/gasman/zx/zmakebas-1.2.tar.gz