Funny bug in 1020 firmware

[ebiguy]

While trying to understand the behavior of different commands sent to the 1020, I found a funny bug which you can be easily reproduced.

I know that only a few 1020 owners have working pens but, don't worry, you do not need pens inside the 1020 for this experimentation.

 

In Basic, type and run the following program.

When you see <Esc> it means that you have to type 2 times on the Esc key and when you see <Ctrl-G> you have to type Control and G.

 

10 OPEN #2,8,0,"P:"

20 PRINT #2;"<Esc><Ctrl G>"

30 PRINT #2;"C-1"

40 CLOSE #2

[TGB1718]

What are you expecting this to do, what does it actually do ?

 

for those of us who don't have a 1020

Edited April 5, 2020 by TGB1718

[ebiguy]

8 minutes ago, TGB1718 said:

What are you expecting this to do, what does it actually do ?

It is supposed to switch to graphics mode and then to change the pen color.

Changing the pen color means that the printer head comes back on the left and rotate the head.

The normal command is C followed by a number from 0 to 3 (line 30 in the BASIC listing). Each number is one of the 4 colors.

But here I ask for color -1 and the printer start to rotate the head forever.

You have to power off the printer because I guess the head would rotate either 999 times or 65535 or maybe forever depending on the internal implementation.

I won't try as I want to keep a working 1020!

[drac030]

This does not look like a real bug, you just fed it with an out-of-bounds parameter, and the printer probably expects the controlling software to be sane and do not do that.

 

I would also be surprised if the printer actually does a number conversion, I would believe that out of your "-1" it just actually respects the "-" only.

 

What happens if you send it C4, C5, C9, CF or CZ instead?

Edited April 5, 2020 by drac030

[jamm]

It depends on your definition of "bug", but having to turn the device off after sending it an out of bounds value does sound like a bug to me.  I would expect it to ignore the value or return an error.  Worst case I'd expect it to convert the value to something in-bounds (the min, max or absolute value).

 

That's a fun little discovery!

 

 

[Rybags]

I'd guess it's only doing 8-bit maths operations.

So worst case might be 255 times not that you'd want that.

 

Ascii codes for 1 and - are 49 and 45, so potentially it could end up with a large number (assuming it's subtracting 48 from the parameter).

How about if you use something like C; ?

; is Ascii 59 which would represent 10 rotations?

[drac030]

4 minutes ago, jamm said:

having to turn the device off after sending it an out of bounds value does sound like a bug to me

Yeah, T O D A Y. In the 70s or 80s, from what I know, you were given instructions that the parameters, opcodes, arguments to functions, whatevers are such and such, and when you try something out of the specs, you get the so called "undefined results". And here is an excellent example of such.

 

Of course, it could have been done better, I guess they do AND #$0F to the number, then rotate the pens and wait until the active pen number matches the one which was sent. Since "-"&$0F = $0D, and the pen numbers are $00, $01, $02, $03, they never match. The AND should be #$03 and all would be fine.

 

Of course, I am guessing only, I really do not know the firmware's operation.

[Rybags]

Seems to be no dump of the firmware around.

From a Hackaday page I got a link http://www.buildlog.net/blog/2019/10/inktober-project-2019-post-5/

 

It seems to do 3 stepper motor iterations for each pen change, so there's probably some slightly more complex operations on the parameter to obtain the result.

[TGB1718]

35 minutes ago, drac030 said:

Yeah, T O D A Y. In the 70s or 80s, from what I know, you were given instructions that the parameters, opcodes, arguments to functions, whatevers are such and such, and when you try something out of the specs, you get the so called "undefined results". And here is an excellent example of such.

Not where I worked, during testing of code, we always threw unexpected rubbish at the code to see how it coped and fix anything that would cause problems.

Maybe others were not so diligent

[+kheller2]

2 hours ago, Rybags said:

Seems to be no dump of the firmware around.

From a Hackaday page I got a link http://www.buildlog.net/blog/2019/10/inktober-project-2019-post-5/

 

It seems to do 3 stepper motor iterations for each pen change, so there's probably some slightly more complex operations on the parameter to obtain the result.

Seriously?  No dump?  I can crack a 1020 open.  I once purchased maybe 10 of them from someone who sent them with NO packing material inside a way too large box.  Nothing left but pieces after being shipped.  I'm sure I still have some laying around.

 

[ebiguy]

4 hours ago, drac030 said:

What happens if you send it C4, C5, C9, CF or CZ instead?

Any number above 3 produces nothing (the head do not rotate/move): It means that the grammar parsing was successful but the number was out of range and the firmware just ignored the command.

With any letter after C, the head rotates to black if it was on a different color: It means that the grammar parsing was unsuccessful and the firmware executes the command but with the default parameter values (0=black).

You have to know that the printer really accepts an integer after C. For example, you can send C001 and the head rotates to the blue pen.

So I guess that, when receiving C-1, the grammar parsing is successful, the string is converted to an integer but the printer uses it as a unsigned integer.

Internally, I guess the numbers are on 16bits because all numbers can be from -999 to +999 so the head probably turns $FFFF times which is almost infinite with the rotation speed.

The bug is funny but the reverse engineering to guess the code behind is funny as well!

Feel free to give your own explanation of these behaviours

Edited April 5, 2020 by ebiguy

[drac030]

3 minutes ago, ebiguy said:

Any number above 3 produces nothing (the head do not rotate/move)

In this case it seems you are right: they check the bounds, but -1 allows to circumvent the check. This is a real bug, then.

[DanBoris]

2 hours ago, Rybags said:

Seems to be no dump of the firmware around.

From a Hackaday page I got a link http://www.buildlog.net/blog/2019/10/inktober-project-2019-post-5/

 

It seems to do 3 stepper motor iterations for each pen change, so there's probably some slightly more complex operations on the parameter to obtain the result.

There used to be a web site that had a lot of the Atari 8-bit firmware, but I can't seem to find it now. Don't remember if they had the 1020 firmware, but they had it for a lot of the peripherals.