Eventually, by dint of much tweaking and testing, colour output from OSI basic to an ANSI terminal. The downside, of course, is that there are a dozen characters of overhead per character...

The lack of any way of passing a parameter to a subroutine other than in a global variable makes it annoying; the gymnastics through which one must jump to convert a numeric parameter into a suitably formatted text stream are just a courtesy detail!

Neil

Unfortunately, it appears that the escaped characters count towards Basic's line-length so new lines appear in odd places; as a result it's not terribly useful.

i think it would make more sense to add new BASIC commands to change text colors, cursor position, etc. instead of doing it manually within existing commands.
though depending on how extendable the BASIC you use is, that might be difficult.

In the BASIC versions I'm familiar with, a semi-colon after a PRINT statement suppresses a carriage return. If that's true in your case, then the PRINT at 110 is printing a carriage return but the PRINT at line 40 is not. So each time the color is changed you move to the next line down. That seems to be the point, or the "HELLO"s would be separated by blank lines.

But you could get much the same effect by putting a semi-colon after line 110 and dropping the one after line 40.

You could make it slightly faster by putting CHR$(27) + "[" in its own global variable and using that global in line 110, eliminating one string concatenation each time you call it.

I'm not sure why RIGHT$(STR$(FGND), 2) since STR$(FGND) should only be two characters to start with, unless STR$() somehow gives a more than two character result. Does it have a leading space?

Actually, because of carriage return suppression you should be able to get away with:

PRINT CHR$(27);"[';RIGHT$(STR$(FGND), 2);";40m";

and do away with all concatenation whatsoever. Or this:

PRINT CHR$(27);"[';RIGHT$(STR$(FGND), 2);";40m";MESG$

and

MESG$="HELLO"

or whatever string you like. That should print whatever is in MESG$ on its own line in whatever color you specify.

If you can create string arrays, you could populate the first seven elements with the results of CHR$(27) + '[" + RIGHT$(STR$(FGND), 2) + ";40m" and then:

PRINT COLR$(FGND-30);MESG$

• This is Microsoft Basic, originally 8k for the OSI development board
• The semicolons are the way they are because I forgot to put on after 110 and there was less typing involved to change the earlier line but yes, it was intended that each gets its own line.
• Putting the escape in a global would help, yes.
• Initially I used semicolons inline, but got confused with the inline colons in the escape (originally I had all three parameters included), hence the concatenation. I haven't looked at the code to see if it's doing the same thing with + and just printing with no space, or whether it goes to a temporary string first and then outputs the lot. I suspect the first, which is probably a little quicker.
• STR$ appears to introduce a leading blank space - perhaps a slot for a - symbol, hence the RIGHT$
• Yes, building the string would speed things. In any case, you'd probably want to reset to normal white on black sooner or later.

I think this basic allows calls to assembly language, so with that one could write a routine that sets the colour by writing the escape code directly to the serial port which would (a) probably be easier; (b) certainly be faster; and (c) wouldn't involve the line position count. But I'll have to see if there's a way to pass a variable to assembly.

Neil

You may be able to add USR(x) functions if you can write them in assembler and load them prior to running the program.

One way I used to do that in Applesoft was to write the code, and then I had a program that converted the code into BASIC DATA statements and a loop to poke it into the location it's running at ...

then you could do



and so on.

You need to poke the start address of the machine code into some locations and you can pick up the argument elsewhere too. Sorry if this is a little vague - I've not used OSI Basic, but have used others and I just quickly checked the manual at: http://osi.marks-lab.com/reference/file ... in_ROM.pdf See pages 13 and 14.

More work, but worth it?

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Hmm. This version declares itself OSI but I think Grant has moved things around a bit. There are references to USR locations at 0x0A and a couple past there, but I can't at a quick look see where (or if) USR is executed in the code. USR(I) returns a syntax error. My Microtan 65 basic manual suggests different load addresses for USR.

This was just a quick 'for fun' attempt to see what might work, so I probably won't take it any further.

Neil

Try

If you get an array error then it's not supported... (according to the sources, anyway) and if this is Grants UK101 thing, then it's supposed to be the original ROM but the monitor was the one that he hacked to make work on serial rather than the TV out - which I only just learned about in the past day or so as I was looking at it for another project... (platform for a TinyBasic, but that's another story)


-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

It gives an FC error, so I guess it's not there.

This is the basic he listed for his minimum chip count computer. http://searle.x10host.com/6502/osi_bas.zip, with the only changes an echo loop until a '+' is received, and the keyword table made lower case (I HATE BEING SHOUTED AT!).

Ay well, something to consider another time.

Neil