PDA

View Full Version : BASIC Programming on the Tektronix 4052



Philcogrump
December 30th, 2005, 10:12 PM
I recently repaired my Tektronix 4052 a few weeks ago, a few of you might remember my question about its hardware problems over a year ago. Now it comes alive with a wonderful blinking cursor :rolleyes: and runs TekBASIC right out of the ROM.

I've been playing with this computer in the past two weeks experimenting with TekBASIC; its version of BASIC is noticeably different from many other versions of BASIC. Some differences are noteworthy: it does not seem to allow multiple commands on one line, ie. 100 PRINT "HELLO" : END. Its vector drawing capability allows it to draw a line with a very simple command, DRAW X,Y (which is the final point of the line, the initial point would be the next line after the user presses return, unless a MOVE X,Y command is used to move the cursor to the initial point before drawing the line). Additionally, it has a statement called POINTER X,Y,Z$ which activates the pointer (looks like a upside down mouse pointer) and that command ends when the user presses any key (which is stored in Z$, and X,Y values of the pointer position are stored). The POINTER is useful for GUI-like programs or so.

I'll say, this is one neat computer and unique because of its vector-based display and the DVST screen, which stores the picture instead of storing the video data in RAM. If one made a loop program to print a message repeatedly, the effect of the computer drawing every letter very quickly from left to right, top to bottom is noticeable - like a neat looking comet across every line.

The downfalls of the DVST and this form of TekBASIC is that it is very limiting when it comes to programming games. If anyone knows otherwise, I have not found a command in the manuals for the 4052 that will read directly from the keyboard without requiring the RETURN key to be pressed. INPUT S$ requires the RETURN key to be pressed, I've tried a variety of commands like READ $31, S$ (which theorically means read from device 31, aka. the computer's built-in keyboard and store that into S$). This only gave me a syntax error, and I've tried INKEY$, which didn't work either.

Also, despite not being able to read from the keyboard, the 4052 cannot do animated graphics because of the DVST. It cannot simply make a line then move that line over, the previous position of the line will still remain on the DVST. The only way to erase is to use the PAGE command, and that makes a green flash that lasts just under a second. Thus, it is limits the graphics of certain games, especially those that contain moving objects. I was told that to make moving objects without the DVST storing, the computer has to be programmed in write-through mode, which is the same concept as the POINTER and cursor, the intensity is just right under the point where the DVST starts to store, thus the pointer and cursor can blink and move around without leaving trails. I think this only worked on the 4054, the bigger and higher-ended version of the 4052 and even had high-res graphics. If anyone knows how to make the 4052 do a custom write-through then I'd love to know.

The only games I've thought of that would work just fine and not be limited by these shortfalls is BlackJack, and I'm currently working on a version of that game for TekBASIC. Did anyone already make a BlackJack program for another version of BASIC, that would be a useful reference.

CP/M User
December 31st, 2005, 12:59 PM
"Philcogrump" wrote:

> I've been playing with this computer in the past two weeks
> experimenting with TekBASIC; its version of BASIC is noticeably
> different from many other versions of BASIC. Some differences are
> noteworthy: it does not seem to allow multiple commands on one line,
> ie. 100 PRINT "HELLO" : END.

That's good - I like the idea of simply having one command per line, it
would have to make the program easier to read. Just put some REMarks
around the code in question to make the routine standout.

> Its vector drawing capability allows it to draw a line with a very simple
> command, DRAW X,Y (which is the final point of the line, the initial point
> would be the next line after the user presses return, unless a MOVE X,Y
> command is used to move the cursor to the initial point before drawing
> the line).

This sounds exactly the same as my Amstrads BASIC - simply use the
MOVE to tell basic where you want to start drawning & use the DRAW in
conjuction with the destination of the line! :-)

Do you have PLOT do you know. On an Amstrad PLOT can also be used to
set a position, however it PLOTs a Point, from that point though, DRAW
can be used which moves from what Plotted Point to where-ever your
moving. (PLOT does not require MOVE cause the your simply plotting the
position onscreen as to where you want the point & nothing else).

> Additionally, it has a statement called POINTER X,Y,Z$ which activates
> the pointer (looks like a upside down mouse pointer) and that
> command ends when the user presses any key (which is stored in Z$,
> and X,Y values of the pointer position are stored). The POINTER is
> useful for GUI-like programs or so.

That sounds very nifty.

> I'll say, this is one neat computer and unique because of its vector-
> based display and the DVST screen, which stores the picture instead of
> storing the video data in RAM. If one made a loop program to print a
> message repeatedly, the effect of the computer drawing every letter
> very quickly from left to right, top to bottom is noticeable - like a neat
> looking comet across every line.

> The downfalls of the DVST and this form of TekBASIC is that it is very
> limiting when it comes to programming games. If anyone knows
> otherwise, I have not found a command in the manuals for the 4052
> that will read directly from the keyboard without requiring the RETURN
> key to be pressed. INPUT S$ requires the RETURN key to be pressed,
> I've tried a variety of commands like READ $31, S$ (which theorically
> means read from device 31, aka. the computer's built-in keyboard and
> store that into S$). This only gave me a syntax error, and I've tried
> INKEY$, which didn't work either.

Okay, with this, I thought it maybe possible to simply write some
assembly routine & acess this through some M/C in the BASIC. What kind
of processor does this use do you know? Maybe with that sort of
information if this machine uses a common CPU - you could perhaps
lookup some assembly site with genetic code. The only other thing I can
think of failing that is perhaps there's some Firmware (which the
computer provides) which allow easier access to the keyboard.

However there maybe a BASIC equivalent. Based on some BASIC from
my Usborne book which suggests alternatives (for the different computers
it uses) they have things like GET A$, LET A$=INKEY$(0), LET A$=KEY$,
if this machine uses something simular to an Apple ][ based BASIC, you'd
have:

LET A$=""
IF PEEK(-16384)>127 THEN GET A$

Also if something like CLS doesn't work try HOME (just a thought).

> Also, despite not being able to read from the keyboard, the 4052
> cannot do animated graphics because of the DVST. It cannot simply
> make a line then move that line over, the previous position of the line
> will still remain on the DVST. The only way to erase is to use the PAGE
> command, and that makes a green flash that lasts just under a second.

If you had PLOT you could do some simple Animation (or something
equivalent which PLOTs a Point). I did a small Bouncy Ball routine which
uses an array to draw the ball - because I made the array such a large
size with 0s on the outer side the Plot would simply remove the old Ball
when moved. Unfortunately this idea I had was quite slow on my 4Mhz
Amstrad! :-( Thought it was perfect for the IBM based machine (I tried it
on my 386 at 16Mhz which thought nothing of it a 12Mhz 286 should be
able to cope with it - but it's obviously a speed issue).

If it's text based stuff, on an Amstrad you had the LOCATE x,y command
which simply sets the text position onscreen - one common practice with
Games was to record the old position while in that process of moving that
character to it's new position & then using PRINT" "; to delete it. Many
systems have simular statements though it does the same thing the lingo
is different (unfortunately).

> Thus, it is limits the graphics of certain games, especially those that
> contain moving objects. I was told that to make moving objects without
> the DVST storing, the computer has to be programmed in write-through
> mode, which is the same concept as the POINTER and cursor, the
> intensity is just right under the point where the DVST starts to store,
> thus the pointer and cursor can blink and move around without leaving
> trails. I think this only worked on the 4054, the bigger and higher-
> ended version of the 4052 and even had high-res graphics. If anyone
> knows how to make the 4052 do a custom write-through then I'd love
> to know.

Sorry I'm unsure as to this! :-(

> The only games I've thought of that would work just fine and not be
> limited by these shortfalls is BlackJack, and I'm currently working on a
> version of that game for TekBASIC. Did anyone already make a
> BlackJack program for another version of BASIC, that would be a
> useful reference.

'Fraid not, unfortunatly.

I think with a little bit of Assembly, it may go a long way with some of
those problems.

CP/M User.

Philcogrump
December 31st, 2005, 09:29 PM
[quote="CP/M User"]

Do you have PLOT do you know. On an Amstrad PLOT can also be used to
set a position, however it PLOTs a Point, from that point though, DRAW
can be used which moves from what Plotted Point to where-ever your
moving. (PLOT does not require MOVE cause the your simply plotting the
position onscreen as to where you want the point & nothing else).

No, PLOT x,y for example results in a syntax error, the manual does not mention PLOT so it is obviously not included in TekBASIC.

--------

Okay, with this, I thought it maybe possible to simply write some
assembly routine & acess this through some M/C in the BASIC. What kind
of processor does this use do you know? Maybe with that sort of
information if this machine uses a common CPU - you could perhaps
lookup some assembly site with genetic code. The only other thing I can
think of failing that is perhaps there's some Firmware (which the
computer provides) which allow easier access to the keyboard.

I think the keyboard reading is probably not supported by TekBASIC because I've looked up every code in the reference manual for TekBASIC, unfortunately.

The 4052 uses four bit-slice 2904 CPUs, I believe to expand the data length to 16 bits (or the address, can't remember). The clock generator gives out roughly 50MHz, so I suppose this computer runs at 50MHz or in the tens of MHz range. The reason Tek used the 2904s and some sophiscated hardware in the 4052 was to make it "emulate" a 6800 processor, that way Tektronix didn't have to come out with a whole new series of the same programs for the 4052 and the original 6800-based programs for the 4051 would be compatable with the 4052. I don't know about assembly programming on this, it does not seem as sophiscated as Apple II BASIC, but I don't know since I never had an Apple II nor used one. I ought get an Apple II because I've heard of some nice things about Apple II BASIC, I saw one for sale once a long time ago for $45 but turned it down.

------------

However there maybe a BASIC equivalent. Based on some BASIC from
my Usborne book which suggests alternatives (for the different computers
it uses) they have things like GET A$, LET A$=INKEY$(0), LET A$=KEY$,
if this machine uses something simular to an Apple ][ based BASIC, you'd
have:

LET A$=""
IF PEEK(-16384)>127 THEN GET A$

Also if something like CLS doesn't work try HOME (just a thought).


All of these commands resulted in a syntax error. For the IF THEN command, TekBASIC requires a line number right after the THEN so it can do a GOTO command, it couldn't be anything else like GET A$ or X=0 or whatever, it is always a line number. However, HOME brings the cursor back to the upper left corner.

-----------

If it's text based stuff, on an Amstrad you had the LOCATE x,y command
which simply sets the text position onscreen - one common practice with
Games was to record the old position while in that process of moving that
character to it's new position & then using PRINT" "; to delete it. Many
systems have simular statements though it does the same thing the lingo
is different (unfortunately).


Yeah, but the DVST stores everything, to show my point, if one does this:

100 MOVE 10,10
200 PRINT "O"
300 MOVE 10,10
400 PRINT "H"

The result would be a O and H overlapping in the same cursor position, if line 400 was PRINT "" to "delete" it then the O would still remain because of the DVST.

CP/M User
December 31st, 2005, 11:51 PM
"Philcogrump" wrote:

> No, PLOT x,y for example results in a syntax error, the manual does
> not mention PLOT so it is obviously not included in TekBASIC.

Yeah, seems to me we're dealing with a pure vector system. But when I think about it it maybe possible to write a PLOT routine simply out of MOVE & DRAW statements (not sure how fast it would perform though). Does your system support GOSUBs & RETURNs?
It would be a lot better if it did. Also can you change colours (e.g. tell the machine which colour to use, even if it's a monochrome system it's still relevant) - if not we maybe able to fool the machine, but if you can draw a blank you could get some animation happening - by making the image appear to move.

That pointer statement sounds interesting - that on it's own suggests it possible to change the colours around.

> I think the keyboard reading is probably not supported by TekBASIC
> because I've looked up every code in the reference manual for
> TekBASIC, unfortunately.

Yeah, bit of a worry this cause for a simple game you need some direct interaction for that arcade gaming feel. I just wondered what INPUT $31 might do? Or perhaps there's a second paramater in which this statement collects the input from the keyboard & store it into a variable. Sometimes I see a INPUT seperated with "," or ";". Does the manual say something about 31?

> The 4052 uses four bit-slice 2904 CPUs, I believe to expand the data
> length to 16 bits (or the address, can't remember). The clock generator
> gives out roughly 50MHz, so I suppose this computer runs at 50MHz or
> in the tens of MHz range. The reason Tek used the 2904s and some
> sophiscated hardware in the 4052 was to make it "emulate" a 6800
> processor, that way Tektronix didn't have to come out with a whole new
> series of the same programs for the 4052 and the original 6800-based
> programs for the 4051 would be compatable with the 4052. I don't
> know about assembly programming on this, it does not seem as
> sophiscated as Apple II BASIC, but I don't know since I never had an
> Apple II nor used one. I ought get an Apple II because I've heard of
> some nice things about Apple II BASIC, I saw one for sale once a long
> time ago for $45 but turned it down.

Yeah, Apple ][s are fine, I don't use them a lot myself, but seem to have collected a broad range of programs. Other BASICs which while they appear more limited - takes some clever thinking to get something going & some assembly knowledge. Unfortunately my lack of assembly for this particular processor makes me useless. Maybe worthwhile trying to source out books from second-hand bookstores online perhaps & try to establish what is available. Or if there's any websites which deal with programming (unfortunately I haven't found any).

> All of these commands resulted in a syntax error. For the IF THEN
> command, TekBASIC requires a line number right after the THEN so it
> can do a GOTO command, it couldn't be anything else like GET A$ or
> X=0 or whatever, it is always a line number. However, HOME brings the
> cursor back to the upper left corner.

Could it be a GOSUB? if for instance it could be - it would make it far easier to make a PLOT routine (discussed earlier).

Also, what kind of resolution does this machine have (if you know)?
And what kind of output does this machine have for a program like this?:


10 MOVE 0,0
20 DRAW 10,0
30 MOVE 399,199
40 DRAW 389,199

On some machines the resolution works slightly differently. e.g. IBMs 0 Y Co-Ordinate begin at the top of the screen & usually the X Co-Ordinate goes from Left to Right of the screen. On an Amstrad CPC for example the 0 Y Co-ordinate beings at the bottom of the screen & works it's way up (silly I know but that's how it works). On both machines the X Co-ordinate moves from Left to Right 0 being on the left & 399 or whatever being the far right (if it was 400 pixels wide), however the CPC has 3 Screen modes & each resolution varies depending on how low the resolution is!! For example in the highest mode (640x200) pixels are 1 point away. In Medium (320x200) it's 2 pixels away - so point 1 maybe 0 but the next one is 2, 4 & so on. And low (180x200) is 4. While each of these change so does the screen colour - with the high resolution having 2 colours, medium 4 colours & low having 16 colours. Hence a CGA based display.

And did HOME actually clear the screen or did it just return the cursor back to the upper left hand corner & do nothing else?

> Yeah, but the DVST stores everything, to show my point, if one does
> this:

> 100 MOVE 10,10
> 200 PRINT "O"
> 300 MOVE 10,10
> 400 PRINT "H"

> The result would be a O and H overlapping in the same cursor position,
> if line 400 was PRINT "" to "delete" it then the O would still remain
> because of the DVST.

Okay that's interesting - so every piece of output is represented as a Graphic of sorts. Wouldn't a space within a print statement delete the character - so it looks like this:

500 MOVE 10,10
600 PRINT " "

Or does the offending space in question simply do nothing & leave the imprint?

Also does this machine support CHR$(n) function?

CP/M User.

Philcogrump
January 1st, 2006, 09:12 PM
[quote="CP/M User"]

Yeah, seems to me we're dealing with a pure vector system. But when I think about it it maybe possible to write a PLOT routine simply out of MOVE & DRAW statements (not sure how fast it would perform though). Does your system support GOSUBs & RETURNs?

Yes, it does support GOSUB and RETURNs. MOVE and DRAW at the same point makes a PLOT behavior by drawing a dot at that point (and that can only be erased by erasing the whole screen using PAGE). The computer is pretty fast at drawing/plotting, you could check out the Lines! program I made that shows how fast the computer draws lines, I have a MPEG and some pictures of it here: http://members.aol.com/philcogrump/temp/

-------------

It would be a lot better if it did. Also can you change colours (e.g. tell the machine which colour to use, even if it's a monochrome system it's still relevant) - if not we maybe able to fool the machine, but if you can draw a blank you could get some animation happening - by making the image appear to move.

I don't think that would be possible, I think the 4054 or some of the 4010-series terminals supported a write-through that changed the color to orange which the DVST could not store. Other than that, I don't think the 4052 does colors, plus the manual does not mention that. The only thing that would be "color-relevant" are for some plotters, which had a pen changer.

-------------

That pointer statement sounds interesting - that on it's own suggests it possible to change the colours around.

The manual says that some other uses of the POINTER statement was besides using it for GUI-based stuff, it could be used to return a X,Y value of any point on the graph, simply point to a part of the graph and it would tell you the X,Y value. Pretty useful for math applications.

-------------

Yeah, bit of a worry this cause for a simple game you need some direct interaction for that arcade gaming feel. I just wondered what INPUT $31 might do? Or perhaps there's a second paramater in which this statement collects the input from the keyboard & store it into a variable. Sometimes I see a INPUT seperated with "," or ";". Does the manual say something about 31?

@31 (I noticed I typed in $31 in my earlier post by accident) means it would read from device 31 which was the keyboard (INPUT reads from the keyboard by default anyway), and it requires a RETURN after whatever is inputted in the keyboard.

---------

Also, what kind of resolution does this machine have (if you know)?

Advertisements for the 4052 says 1024x780 viewable points, 1024x1024 addressable points; 72 characters (upper and lower ASCII) per line, 35 lines.

------------

And what kind of output does this machine have for a program like this?:


10 MOVE 0,0
20 DRAW 10,0
30 MOVE 399,199
40 DRAW 389,199

On some machines the resolution works slightly differently. e.g. IBMs 0 Y Co-Ordinate begin at the top of the screen & usually the X Co-Ordinate goes from Left to Right of the screen. On an Amstrad CPC for example the 0 Y Co-ordinate beings at the bottom of the screen & works it's way up (silly I know but that's how it works). On both machines the X Co-ordinate moves from Left to Right 0 being on the left & 399 or whatever being the far right (if it was 400 pixels wide), however the CPC has 3 Screen modes & each resolution varies depending on how low the resolution is!! For example in the highest mode (640x200) pixels are 1 point away. In Medium (320x200) it's 2 pixels away - so point 1 maybe 0 but the next one is 2, 4 & so on. And low (180x200) is 4. While each of these change so does the screen colour - with the high resolution having 2 colours, medium 4 colours & low having 16 colours. Hence a CGA based display.

Ah, yes. The 4052's screen at start up is based on the Cartesian plane, X is 0 to 130 from left to right, Y is 0 to 100 from bottom to top. The INIT command sets this "window" when executed in BASIC. The "window" can be changed using the WINDOW -x,x,-y,y command, and AXIS a,b sets the intervals for the X and Y values. This makes the 4052 capable of graphing like TI graphing calculators, very neat and useful.

----------

And did HOME actually clear the screen or did it just return the cursor back to the upper left hand corner & do nothing else?

HOME returns the cursor back to the upper left, nothing else. Whatever is still on the DVST remains. PAGE will erase the screen and home the cursor.

----------

Okay that's interesting - so every piece of output is represented as a Graphic of sorts. Wouldn't a space within a print statement delete the character - so it looks like this:

500 MOVE 10,10
600 PRINT " "

Or does the offending space in question simply do nothing & leave the imprint?


The DVST serves as the "video" memory, when the computer draws a character or so, it does not have to store it in memory after it draws, the DVST takes care of that. So, a PRINT "" is just an extra piece of information for the RAMs to hold for execution, but does not erase it off the DVST, the only way to erase on the DVST was to use the PAGE and start everything all over again on the screen.

-----------

Also does this machine support CHR$(n) function?

I'm not sure, I think there were a few mentions of that in the manual, but there is a FONT command that actually can pull out different characters of other languages, ie. German, Spanish, Danish, Business, Graphic, etc.

CP/M User
January 2nd, 2006, 09:54 PM
"Philcogrump" wrote:

> Yes, it does support GOSUB and RETURNs.

Okay, I just wondered if the IF THEN statement would take a GOSUB after
the THEN? Otherwise it would be using many GOTOs inbetween routines.
Another useful statement I know of is ON <variable> GOSUB
<line_number> which merely goes to a specific line on the condition of
the variable. I've got a funny feeling though that it's not a standard BASIC command (unless this machine used it like others did).

> MOVE and DRAW at the same point makes a PLOT behavior by drawing
> a dot at that point (and that can only be erased by erasing the whole
> screen using PAGE). The computer is pretty fast at drawing/plotting,
> you could check out the Lines! program I made that shows how fast the
> computer draws lines, I have a MPEG and some pictures of it here:
> http://members.aol.com/philcogrump/temp/

Yes, very quick at vectors. I looked at your MPEG & could see what the PAGE command does, it's just a pity it's a tad slow. I was just wonderning if PAGE had options or is it simply a statement with no parameters?

> I don't think that would be possible, I think the 4054 or some of the
> 4010-series terminals supported a write-through that changed the color > to orange which the DVST could not store. Other than that, I don't think
> the 4052 does colors, plus the manual does not mention that. The only
> thing that would be "color-relevant" are for some plotters, which had a
> pen changer.

Okay, cause I was perhaps looking for something which turns the pen off - which would perhaps blank a dot from the position it was in & could be turned back on. It's hard to tell since the manual could be referning to it in a different context - but performed the same operation.

>> That pointer statement sounds interesting - that on it's own suggests it
>> possible to change the colours around.

> The manual says that some other uses of the POINTER statement was
> besides using it for GUI-based stuff, it could be used to return a X,Y
> value of any point on the graph, simply point to a part of the graph and
> it would tell you the X,Y value. Pretty useful for math applications.

In this situation I thought it maybe possible to use POINTER for some kind of game - it seems to have the power to whatever - so could be used as your character. It's just a shame you can't really reshape it (or can you?), certainally might work in a game like Missile Attack, which is simply a crosshair.

> @31 (I noticed I typed in $31 in my earlier post by accident) means it
> would read from device 31 which was the keyboard (INPUT reads from
> the keyboard by default anyway), and it requires a RETURN after
> whatever is inputted in the keyboard.

Yeah, well I just thought that your 31 statement if use in conjunction with INPUT may bypass the return press not sure if any other BASIC machines use this, but in Turbo Pascal 3.x for instance, the READ statement can change from becomming a form of INPUT & take direct input from the KBD function. Don't be confused with the READ of TP & BASIC though, usually BASICs READ variable is used in conjunction with DATA statements.

>> Also, what kind of resolution does this machine have (if you know)?

> Advertisements for the 4052 says 1024x780 viewable points,
> 1024x1024 addressable points; 72 characters (upper and lower ASCII)
> per line, 35 lines.

That's a lot.

>> And what kind of output does this machine have for a program like
>> this?:

> Ah, yes. The 4052's screen at start up is based on the Cartesian plane,
> X is 0 to 130 from left to right, Y is 0 to 100 from bottom to top. The
> INIT command sets this "window" when executed in BASIC.
> The "window" can be changed using the WINDOW -x,x,-y,y command,
> and AXIS a,b sets the intervals for the X and Y values. This makes the
> 4052 capable of graphing like TI graphing calculators, very neat and
> useful.

Could a couple of WINDOWs be actually setup & cleared seperately using the PAGE command? That would be extermely handy if it could.

> The DVST serves as the "video" memory, when the computer draws a
> character or so, it does not have to store it in memory after it draws,
> the DVST takes care of that. So, a PRINT "" is just an extra piece of
> information for the RAMs to hold for execution, but does not erase it off
> the DVST, the only way to erase on the DVST was to use the PAGE and
> start everything all over again on the screen.

Okay, I just wondered if you could poke with - this would be very hard to work out the screen address & to clear an area you want gone - that's the only problem - but it could still be done. You'd need the structure of the screen to work this out though (quite possibly).

CP/M User.

Philcogrump
January 3rd, 2006, 05:20 PM
[quote="CP/M User"]

Okay, I just wondered if the IF THEN statement would take a GOSUB after
the THEN?
Nope, after the THEN there must be a line number or a syntax error will automatically appear. The line number after the THEN is executed by a GOTO statement, not a GOSUB.

--------------

Otherwise it would be using many GOTOs inbetween routines.
Another useful statement I know of is ON <variable> GOSUB
<line_number> which merely goes to a specific line on the condition of
the variable. I've got a funny feeling though that it's not a standard BASIC command (unless this machine used it like others did).

I think the manual mentioned something about ON and OFF statements, can't recall exactly what they did.
---------------------

Yes, very quick at vectors. I looked at your MPEG & could see what the PAGE command does, it's just a pity it's a tad slow. I was just wonderning if PAGE had options or is it simply a statement with no parameters?

Yeah, it is a pity. The PAGE has no parameters, it is a striaght statement.

------------------

In this situation I thought it maybe possible to use POINTER for some kind of game - it seems to have the power to whatever - so could be used as your character. It's just a shame you can't really reshape it (or can you?), certainally might work in a game like Missile Attack, which is simply a crosshair.

The 4054 according to a friend had dynamic graphics (a $2000 extra option) and supported write-through graphics that could be shaped manually. The 4052 doesn't support this as far as I know.

I hadn't thought of Missile Attack, that might work (now I'm tempted to experiment when I have the time)... though it'd be interesting to see the trails of the old lines and explosions (remember the DVST stores everything that is drawn, even if it is blank).

---------------------

> @31 (I noticed I typed in $31 in my earlier post by accident) means it
> would read from device 31 which was the keyboard (INPUT reads from
> the keyboard by default anyway), and it requires a RETURN after
> whatever is inputted in the keyboard.

Yeah, well I just thought that your 31 statement if use in conjunction with INPUT may bypass the return press not sure if any other BASIC machines use this, but in Turbo Pascal 3.x for instance, the READ statement can change from becomming a form of INPUT & take direct input from the KBD function. Don't be confused with the READ of TP & BASIC though, usually BASICs READ variable is used in conjunction with DATA statements.

The manual said something about READ being used in conjunction with DATA, and I think there was mention of using @33 for the tape drive, I think I did try that at 31 with an error message.

---------------

Could a couple of WINDOWs be actually setup & cleared seperately using the PAGE command? That would be extermely handy if it could.

Yes, you could set a window for -10,10,-10,10 then clear it using PAGE then make a new one at -20,20,-20,20 or whatsoever. I think there is another command called VIEWPORT which is like a zoom function on the certain window.

--------------

Okay, I just wondered if you could poke with - this would be very hard to work out the screen address & to clear an area you want gone - that's the only problem - but it could still be done.

There is no "screen address" because there is no video RAM on the board, the DVST acts like RAM, plus it does not have addressable areas on the screen, it is simple like an Etch A Sketch pad, which can only be erased by shaking it (which is what the PAGE does for the DVST).

-------------

You'd need the structure of the screen to work this out though (quite possibly).

There is only one thing I can think of that would make dynamic graphics possible, but it requires adjustments to the hardware. First I'd have to enter the program when I can actually see it on the DVST, then when I'm ready to run it then I could turn down the brightness of the CRT so it is below the level of storage for the DVST, so the computer acts like a Vectrex game system. However, this is too much of a hassle and the picture would be dim so I wouldn't bother.

Terry Yager
January 3rd, 2006, 06:10 PM
I think the manual mentioned something about ON and OFF statements, can't recall exactly what they did.

Would that be like a MOTOR ON/OFF statement, for the cassette recorder, or mebbe even equivalent to a PSET/PRESET comand to turn a pixel on/off? (Forgive me, I'm not a programmer).

--T

carlsson
January 4th, 2006, 04:53 AM
David A. Lien has a chapter specifically about Tektronix Basic in his Basic Handbook. Translated from English to Swedish back to English:


Tektronix 4050 series computers have an extended Basic with many reserved words and possibilities not found in other Basic dialects. The following list is an overview of these words. In most cases it is not possible to translate these statements word by word to another Basic dialect.

AXIS: Draws X and Y axis with markings on the graphic screen
BAPPEN: Merges a binary program to the program in memory
BOLD: Loads a binary program from tape
BRIGHTNESS: Manages the 4054 screen (?)
BSAVE: Saves a binary program to tape
CHARSIZE: Selects number of characters per row and number of rows on 4054
COPY: Copies screen output
DASH: Manages graphic screen (?)
FIND: Finds start of a tape file
FONT: Selects font (e.g. Spanish, German, Swedish)
FUZZ: Selects precision in number of digits used for comparison, approximation with 0. Example: FUZZ 6, 1E-5. Two numbers are considered equal if six digits are the same. Numbers whose absolute value < 1E-5 are worth 0.
GIN: Reads the cursor position and saves the coordinates
INIT: Restores variables to a random value
KILL: Removes a file from directory
LINK: Links programs
MARK: Prepares tape for recording of data or program
MPY: Matrix multiplication
MTPACK: Adjusts tape recorder
OFF: Disables the interrupt function
OLD: Reads ASCII files from tape
PAGE: Clears screen, cursor to upper left corner (home)
POINTER: Assigns coordinates from outer controller (joystick)
POLL: Reads outer device, returns information about the unit
PRINT@: Prints values to physical and logical units
RBYTE: Reads one or more bytes from GPIB (instrument bus). Stores in a variable.
RDRAW: Draws distances on graphic screen
REP: Deals with characters in strings similar to MID$
RMOVE: Moves cursor
ROTATE: Moves cursor and draws distances according to angle
SCALE: Sets scale factor on graphic screen
SECRET: Secret code for files
SUM: Counts the sum of elements in a field
TLIST: Lists names and sizes of files on tape
VIEWPORT: Defines the size of a graphic image
WBYTE: Sends one or more bytes to GPIB
WINDOW: Defines maximum and minimum values to fit in the screen format

Most other words in Tektronix Basic corresponds with other Basic dialects and are explained in the Basic handbook.

There may be more keywords that differ, but Lien never found them. The reason he made these appendices was in case an owner of a different computer came across a listing for Acorn Atom, Atari 400/800, Tektronix, TRS-80 CoCo or any DOS based computer (CP/M, MS-DOS?).

Terry Yager
January 4th, 2006, 01:12 PM
Hmmmn, I wonder if there even is a way to address a single pixel on a vector-graphics system?

--T

Philcogrump
January 4th, 2006, 05:00 PM
That is a good majority of the programming commands shown in my Tektronix 4050-series Reference Manual. There are ROM packs that plugs into the "ROM backpack" of the computer that can expand the system's BASIC capabilities for certain operations, right now I have two: Real Time Clock which stores the date and time (though it has to be set every time the computer is turned on) and a 4052-to-4907 pack that provides extra commands for the 4052 to control the 4907 8" floppy disk drive (that ROM pack has some bad bits anyway).

Terry, what do you mean by addressing a single pixel on the graphics computer? If you meant as in addressing to video RAM, then this is not possible because the computer has no video RAM whatsoever, the DVST is the virtual RAM for video. Like I was explaining to CP/M User, if you wrote at a certain location on the screen, it could not be read again like a terminal-based display like most of the other computers of the 70s and early 80s. I understand that for instance, PRINT "HELLO" then PRINT " " would erase the HELLO in that area of video memory on those computers, but on the 4052. The HELLO is not stored in any memory when the program is executed, the DVST stores that for display purposes.

Thus, the other computers as far as I know could read from that specific location in video and return what is stored there, and the 4052 could never do that because the DVST is a purely output-only device and cannot provide any input back into the system. In fact, READ @32,A$ which theorically means read from the display and store that into A$ would be an illegal I/O command because of what I mentioned earlier.

Terry Yager
January 4th, 2006, 05:32 PM
Yeah, that's pretty much what I was thinking, it's completely different from sum'n like a TRS-80, where the whole screen is mapped into memory.

--T

CP/M User
January 6th, 2006, 11:14 PM
Yeah, well I'm kinda out of ideas what you could do to eliminate output to
the screen. In a way it's great you can have a computer with lightnight
fast output, but then you need to remove stuff from the screen to make
an effective game. This might have to involve some direct talking to the
hardware (in this case the display) for this to happen which, unfortunately
would invove some assembly perhaps, but could be extremely hard to
find the relevant material (if there's any) - certainally the 'net maybe able
to help e.g. Online Bookshops, websites (which might be tight) on the
Tektronix 4052 or even Google Groups - try searching (in advance
search) for old groups between 1981-1990 for example with the following
contexts "Tektronix 4052"+"Keyboard" and "Tektronix
4052"+"Clear"+"Screen" or "Display".

CP/M User.

Philcogrump
January 7th, 2006, 05:04 PM
Yeah. However, I've been in contact with someone who actually programmed games for the 4052, so hopefully after he replies back I might make some progress in understanding how to do this.

I'm less worried about the display's limitations, but the fact I'm unable to read from the keyboards directly without requiring RETURN is the bigger problem. Indeed, the DVST limits the scope of the games I could program on it, but without direct keyboard reading, the list of possible games becomes much shorter.

nikola-wan
March 24th, 2018, 07:36 AM
Yeah. However, I've been in contact with someone who actually programmed games for the 4052, so hopefully after he replies back I might make some progress in understanding how to do this.

I'm less worried about the display's limitations, but the fact I'm unable to read from the keyboards directly without requiring RETURN is the bigger problem. Indeed, the DVST limits the scope of the games I could program on it, but without direct keyboard reading, the list of possible games becomes much shorter.

Browsing this forum for Tektronix - found this old thread.

Jon - you have probably already learned this - but the Tek 405x function keys are the keys they intend for single key interrupt use without the need for INPUT statements.

Monty