SCALE bug

hydrophilic
Global Moderator

Posts: 794

SCALE bug Mar 2, 2015 7:03:29 GMT

Quote

Post by hydrophilic on Mar 2, 2015 7:03:29 GMT

Here is a new bug brought to my attention by Donno128: SCALE is broken with custom X/Y values -- well *some* values.

In case you are not familiar with SCALE, let me give you the background details...

So standard BASIC of the Plus/4 and C=128 have two "real" bitmap modes... often called "hi-res" and "multicolor" (or more briefly, HR and MC). Going off-topic a bit, there are two extra "software" modes that mix bitmap and text mode. I won't discuss them here to avoid confusion

So in hi-res mode, the screen is physically divided into 320(H) by 200(V) pixels... and in multicolor mode, the physical bitmap is 160(H) by 200(V) pixels. I think anyone familiar with TED / VIC-II graphics knows this.

Because these values are quite arbitrary (and mode-specific), somebody at CBM thought it would be a good idea to implement a SCALE command. This allows "logical" coordinates to be used with bitmap commands (instead of "physical" coordinates).

This idea is a good thing as it allows, for example, a generic program to be written with some logical SCALE factor that will work "acceptably" no matter which physical mode is used... "acceptable" means it would look approximately the same, but there may be some "minor" differences... (and "minor" means the program should work most of the time, but could cause trouble in marginal cases... especially with PAINT)

*ANYWAY*

If you look at the documentation for the C128 (either in the C128 System Guide that comes with the computer, or the "bible" known as C128 Programmer's Reference Guide) then you will find the following documentation....

SCALE [n, XMAX, YMAX]

where:

n = 0 or 1 (off or on [physical or logical])

XMAX = physical-X to 32767 (only if n=1... ignored if n=0)

YMAX = physical-Y to 32767 (only if n=1)

(P.S.: from memory the same thing is documented for Plus/4, although I have not verified this)

For both VIC-II and TED (both BASIC 3.5 and 7.0), the "physical-Y" is always 200, thus...

YMAX = 200 to 32767 (only if n=1)

However, for both VIC-II and TED, the "physical-X" will be either 160 or 320 depending on bitmap mode (for our purposes, GRAPHIC 1 or GRAPHIC 3). Thus...

XMAX = 320 to 32767 (if n=1 and "hi-res" mode)

or

XMAX = 160 to 32767 (if n=1 and "multicolor" mode)

Well I hope that makes sense to everybody, because things only get worse!

Donno128 recently reported to me that "the VIC screen scale command has been broken back to Plus/4 compatibility... It does not accept x and y arguments but reports a division by zero error"

Well I tried some "marginal" values and got errors in C128 (have not tested Plus/4). Edit: I got same error with Plus/4 using GRAPHIC 3,1: SCALE 1,200,200 /Edit

My investigation is not complete, but from both standard BASIC of Plus/4 and C128 (version 3.5 and 7.0, respectively) I did get an error... but for me the error was ILLEGAL QUANTITY ERROR.

So attached are 3 BASIC programs... the first and second (for Plus/4 and C128) attempt to use SCALE of 200x200 in multicolor mode... but they give ILLEGAL QUANTITY ERROR [in 20].

The third program (only tested on C128) , "works" at first (i.e., no error message) but according to the SCALE used, the BOX should be completely ON-SCREEN... however if you run it on your C128 (probably Plus/4 too) you see the first box drawn is NOT fully on-screen... it gets "cut-off" (on the right).

Thus, it seems the problem is BAD DOCUMENTATION!

Upon further investigation (the C128 ROMs), it seems the problem is ROM bug... you see each video mode ("hi-res" or "multicolor") should use a different "scale factor"... but the ROM uses a hard-coded value without any regard to the current screen mode:

;perform SCALE . F6960 20 F4 87 JSR $87F4 ;Evaluate to unsigned byte in .X . F6963 E0 02 CPX #$02 ;limit boolean . F6965 90 03 BCC $696A ;less than ok .... F696A 8E 6A 11 STX $116A ;scaleM; set on (1) or off (0) . F696D 20 86 03 JSR $0386 ;chrGot . F6970 D0 14 BNE $6986 ;no terminator, get SCALE values .... F6986 20 C4 69 JSR $69C4 ;Skip comma & evaluate positive 16 bit number to FAC . F6989 A9 D8 LDA #$D8 ;address of SCALE horizontal factor (lo) . F698B A0 69 LDY #$69 ;(hi) ***** hard-coded value = NOT mode specific ****** . F698D 20 89 8A JSR $8A89 ;ROMupk: Copy float from address .YA to arg . F6990 20 4C 8B JSR $8B4C ;FdivT: fac = arg / fac . F6993 20 15 88 JSR $8815 ;FAC to unsigned integer in .AY and poker . F6996 C9 00 CMP #$00 ;test hi byte . F6998 D0 04 BNE $699E . F699A C0 00 CPY #$00 ;test lo byte . F699C F0 37 BEQ $69D5 ;Illegal Quantity Error . F699E 48 PHA . F699F 98 TYA . F69A0 48 PHA . F69A1 20 C4 69 JSR $69C4 ;Skip comma & evaluate positive 16 bit number to fac . F69A4 A9 DD LDA #$DD ;address of SCALE vertical factor (lo) . F69A6 A0 69 LDY #$69 ;(hi) . F69A8 20 89 8A JSR $8A89 ;ROMupk: Copy float from address .YA to arg . F69AB 20 4C 8B JSR $8B4C ;FdivT: fac = arg / fac . F69AE 20 15 88 JSR $8815 ;fac to unsigned integer in .AY and poker . F69B1 C9 00 CMP #$00 ;test hi byte . F69B3 D0 04 BNE $69B9 . F69B5 C0 00 CPY #$00 ;test lo byte . F69B7 F0 1C BEQ $69D5 ;Illegal Quantity Error . F69B9 84 89 STY $89 ;scaleY(lo) . F69BB 85 8A STA $8A ;scaleY(hi) . F69BD 68 PLA . F69BE 85 87 STA $87 ;scaleX(lo) . F69C0 68 PLA . F69C1 85 88 STA $88 ;scaleX(hi) . F69C3 60 RTS
So the documentation is NOT true to the real ROM behavior... in particular...

. F6989 A9 D8 LDA #$D8 ;address of SCALE horizontal factor (lo) . F698B A0 69 LDY #$69 ;(hi) ***** hard-coded value = NOT mode specific ****** . F698D 20 89 8A JSR $8A89 ;ROMupk: Copy float from address .YA to arg
It seems like BASIC should use a different SCALE factor (near the hex address $6989 on the C128) based on the current mode. Donno128 reported that SCALE works correctly with BASIC 7.80 when using 80-column screen (because my software actually tests the video mode), however for non-80 column (VIC) screen the original ROM routine is used (which does NOT test the mode).

And so there is a bug with 40 columns... blame the ROM or blame the documentation (but don't blame me )

I could patch my BASIC 7.80 to correct for this bug in the original ROMs... but of course that risks breaking compatibility with existing software. Considering SCALE is not very popular (from my limited survey of C128 software) this might be acceptable...

What do you folks think?

Tell us off-the-top-of-your-head, or if you are a real Commie, do some tests on your favorite machine and then report...

Edit

Oh yeah, here are the BASIC programs I used for testing... the one with "+4" in the name is for Plus/4 (shock ) and the other 2 are for C128.

+Edit 2

I noticed the forum software renamed "+4" in the first filename to simply "4"... I guess this is a Linux limitation on filenames?

/Edit 2

/Edit

Attachments:

scale 4 200x200 (70 B)

scale 200x200 (132 B)

scale 320x200 (132 B)

Last Edit: Mar 2, 2015 7:31:44 GMT by hydrophilic: Thought of something else...

I'm kupo for Kupo Nuts!
∇ • hydrophilic ≠ 0

donno128
Vic 20 User

"All the bits that's fit to PRINT#"

Posts: 113

SCALE bug Mar 3, 2015 2:47:27 GMT

Quote

Post by donno128 on Mar 3, 2015 2:47:27 GMT

On the real machine...
SCALE treats true CIRCLES differently depending on how they are made.
A circle created with just the radius, CIRCLE1,xc,yc,xr will not
change proportionally whether it is drawn with
SCALE1,1280,640 or
SCALE1,640,480
activated.
A circle created with x and y radius, such as CIRCLE1,xc,yc,xr,yr
will change proportionally if drawn with
SCALE1,1280,640 or
SCALE1,640,1280
<scratches head>
This seems to me to be a bug. Or maybe just to be expected...
The second coordinate is available for SCALE to act on.

But...

In VICE the circle will change proportionally
whether the y radius is added in the CIRCLE command or not
under
SCALE1,1280,640 or
SCALE1,640,1280
<scratches head>
Here is a program that demonstrates the difference.
Try it on the real and the virtual and see
CIRCLESCALE.D64 (170.75 KB)

Last Edit: Mar 3, 2015 3:43:25 GMT by donno128: Needed done.

Let us not talk falsely now
The hour is getting late

donno128 Vic 20 User "All the bits that's fit to PRINT#" Posts: 113	SCALE bug Mar 3, 2015 2:50:21 GMT Quote Select Post Deselect Post Link to Post Member Give Gift Back to Top Post by donno128 on Mar 3, 2015 2:50:21 GMT Gotta getta life.
	Last Edit: Mar 6, 2015 19:03:53 GMT by donno128: too wordy Let us not talk falsely now The hour is getting late

robertb
C128 User

Posts: 1,129

SCALE bug Mar 3, 2015 3:13:44 GMT

Quote

Post by robertb on Mar 3, 2015 3:13:44 GMT

hydrophilic wrote:

> I could patch my BASIC 7.80 to correct for this bug in the original ROMs... but of course that risks breaking compatibility
> with existing software.

I would not like breaking compatibility.

FCUG celebrating 33 years,
Robert Bernardo
Fresno Commodore User Group
www.dickestel.com/fcug.htm
July 18-19 Commodore Vegas Expo v11 2015 -
www.portcommodore.com/commvex

hydrophilic
Global Moderator

Posts: 794

SCALE bug Mar 3, 2015 10:14:55 GMT

Quote

Post by hydrophilic on Mar 3, 2015 10:14:55 GMT

robertb,
I tried to keep my BASIC 7.80 as true to the original ROM as possible... thus it exhibits the "original bugs"... or, as some programmers might say "features"

If I ever get the time (my employer is very anal about granting time-off), I hope to release BASIC 7.81 (well, anything over 7.80 )... that will correct bugs and add new features... Most important would be custom VDC screen sizes (like 78x24 cells for us poor 16K VRAM people)... and/or 80x100 cells for the more luxurious owner of 64K VRAM (i.e, cell size of 8x2)

donno128,
Well CIRCLE is quite more complex than BOX (used my test programs)...
I have not dissected Plus/4 ROM, but on C128 ROM, there is a test for video mode... if multi-color mode is active, the "X-Scale" is cut in half (I'm pretty sure... very remote possibility that Y-Scale is doubled)...

So yeah, that is why I used BOX (and not CIRCLE) in my test programs...

I was wrong before in thinking that v3.5 (Plus/4) was the same as v7.0 (C128) in regards to BOX/CIRCLE/SCALE... they are very similar, but also important differences that I need to investigate...

My investigation continues... but thanks for everyone's feedback... it gives me a direction search

Edit

donno128,

I now see that X/Y values used with SCALE will generate SYNTAX ERROR on Plus/4... not possible with BASIC 3.5 (only with BASIC v7+)!

I tired your "CIRCLESCALE.D64" on Plus/4 and only got errors (umm C128 only?)

I tired your "CIRCLESCALE.D64" on C128 (with original v7.0 BASIC) and it ran without error (not sure if SCALE worked)...

Currently I am testing in VICE (too lazy / not enough free-time) to test on my real C128... but it seems to work (no errors)... well I assume there is *some* SCALE problem...

I have to guess this is issue specific to CIRCLE (and not SCALE in particular) ??

I will continue to investigate... but if you have any "hints" then please share!! (So I can isolate that pesky bug!)

/Edit

Last Edit: Mar 3, 2015 10:43:15 GMT by hydrophilic: Thought of something else...

I'm kupo for Kupo Nuts!
∇ • hydrophilic ≠ 0

hydrophilic
Global Moderator

Posts: 794

SCALE bug Mar 4, 2015 7:47:29 GMT

Quote

Post by hydrophilic on Mar 4, 2015 7:47:29 GMT

Mar 3, 2015 2:47:27 GMT donno128 said:

On the real machine...
SCALE treats true CIRCLES differently depending on how they are made.
A circle created with just the radius, CIRCLE1,xc,yc,xr will not
change proportionally whether it is drawn with
SCALE1,1280,640 or
SCALE1,640,480
activated.
A circle created with x and y radius, such as CIRCLE1,xc,yc,xr,yr
will change proportionally if drawn with
SCALE1,1280,640 or
SCALE1,640,1280
...But...

In VICE the circle will change proportionally
whether the y radius is added in the CIRCLE command or not
under
SCALE1,1280,640 or
SCALE1,640,1280
<scratches head>
Here is a program that demonstrates the difference.
Try it on the real and the virtual and see

This may be a ROM issue... VICE uses (by default) the latest version of official CBM ROMs... for example, start-up message is "COPYRIGHT 1986" but on some C128s (I believe all flat C128s in the USA), older ROMs are active (COPYRIGHT 1985). At this time, I can't say this is the main discrepancy between VICE and real C128 (but it is a good candidate )

O.M.G.

It seems we have uncovered a real can of worms here!

Well maybe those "worms" always existed, but today we expose them to the light of truth! (sorry for sappy poetry, but I gotta be me)

So an example, provided by donno128,

A circle created with just the radius, CIRCLE1,xc,yc,xr will not
change proportionally whether it is drawn with...
SCALE1,1280,640 
or
SCALE1,640,480

Please note that donno128 gives two very different aspect ratios... the first is 2:1 (1280/640) while the second is 4:3 (640/480)

donno 640.bmp (51.11 KB)

donno 1280.bmp (51.11 KB)

Check out those images I get with VICE ... they are rather different, but SHOULD BE EXPECTED because of different aspect ratio... (P.S., C128 PRG file = donno 1280 (52 B))

Anyway, important to note that each "circle" has a different shape...

In the first image it is "short and fat", but in the second image it is "tall and thin".

This is due to ASPECT RATIO (x_scale / y_scale)

Now lets change things around a bit... (my lame test program = hydro 800 (108 B))...

10 graphic 2,1 20 scale 1,400,300 :rem 4/3 30 circle 1,250,100, 100 40 getkey a$ 50 graphic2,1 60 scale 1, 800,600 :rem 4/3 70 circle 1,250,100, 100

Due to the change in SCALE, the circle will not appear in the same location (or size)... but, it is always the same shape!

Both "circles" have the same shape because of the same aspect ratio (4:3)

Oh yeah, hear are my 4:3 images...

hydro 400.bmp (51.11 KB)

hydro 800.bmp (51.11 KB)

Sorry I did not have time tonight to address another serious issue raised by Donno128... "A circle created with x and y radius, such as CIRCLE1,xc,yc,xr,yr
will change proportionally if ..."

Err, my investigation into SCALE continues !

Last Edit: Mar 4, 2015 9:05:16 GMT by hydrophilic: Typos!

I'm kupo for Kupo Nuts!
∇ • hydrophilic ≠ 0

Post by hydrophilic on Mar 2, 2015 7:03:29 GMT

Post by donno128 on Mar 3, 2015 2:47:27 GMT

Post by donno128 on Mar 3, 2015 2:50:21 GMT

Post by robertb on Mar 3, 2015 3:13:44 GMT

Post by hydrophilic on Mar 3, 2015 10:14:55 GMT

Post by hydrophilic on Mar 4, 2015 7:47:29 GMT

Quick Reply