Espansion 8k+

[armypavarmy]

scgrf-8k.zip

(710 Bytes) Downloaded 46 times

scgrf-8k.zip

(710 Bytes) Downloaded 46 times

Hello ,
I have a 3d graphics program for Vic20 8k + Ram that requires Poke44,36 before loading.
Only with the expansion "Vixen 8k-16k" and other expansion Italian Lx700) works.
With expansion "VIC1110 eFE3-Alpha and others" The poke 44.36 generates error!.
Loading Minigrafik and then the program without giving poke44,36 it works with all the other expansions.
Minigrafik uses 44.36 and loads with any set
I don't understand why.
Thanks for help

[Mike]

Any change of the BASIC start address is required to put a 0 byte into the position before that address. Furthermore, in most cases a NEW should follow to initialise BASIC memory with an empty BASIC program.

That means, just "POKE44,36" is insufficient to move the BASIC start. Depending on the power-up state of the expansion RAM, there could easily be a non-0 value at that address. In principle, it is also incomplete, as the low-byte of the BASIC start address need not necessarily be 1, and ought to be initialised as well. The correct, and full statement thus should read: POKE43,1:POKE44,36:POKE9216,0:NEW

Loading Minigrafik and then the program without giving poke44,36 it works with all the other expansions.

That happens to work just by chance. Of course MINIGRAFIK also needs to re-organize BASIC memory, to protect its own code and the display bitmap from being overwritten by the BASIC interpreter.

Note, MG puts the BASIC start to $246B, with a 0 byte at $246A being part of the MG code. While MG is active, you are not supposed to relocate the BASIC start below that address!

...

That being said, you can port "scgrf-8k" to MINIGRAFIK as follows:

Code: Select all

10 REM SENZA SCHEDA GRAFICA
100 POKE56,62
115 DIMA%(151)
120 FORK=16112TO16147:READKX:POKEK,KX:NEXT
130 SYS16112
140 DATA162,0,138,157,0,16,169,6,157,0,148,232,224,191,208,242
150 DATA169,0,170,157,0,20,232,208,250,238,5,63,173,5,63,201,32,48,237,96
160 IFPEEK(36864)<12THENPOKE36864,5:POKE36865,25
170 REM
180 POKE36866,19
190 POKE36867,21
200 POKE36879,23
210 POKE36869,205
225 T=15
235 FORY0=-9.5TO9.5STEP.7
245 FORX0=-9.5TO9.5STEP.18
255 Y=INT(SIN(SQR(X0*X0+Y0*Y0+.001))/(SQR(X0*X0+Y0*Y0+.001))*75+T*1.3)
265 X=INT((X0+9.5)*5.5)+T*.92-14
275 GOSUB310
285 NEXT:T=T+2
295 NEXT
298 W$=TI$
300 GOTO450
310 IFX<0ORX>151THENRETURN
320 IFY<0ORY>159THENRETURN
335 IFY<A%(X)THENRETURN
345 A%(X)=Y
350 Y=159-Y
360 A%=X/8:B%=Y/16
370 R1%=X-A%*8:R2%=Y-B%*16:Y=159-Y
380 V%=2^(7-R1%):C%=5120+B%*304+A%*16+R2%
390 POKEC%,V%ORPEEK(C%)
400 RETURN
450 GETG$:IFG$=""THEN450
460 SYS64802

• delete lines 100 and 120-210. Replace these with 100 @ON:@CLR
• delete line 298. W$ is not used anywhere.
• delete lines 360-390. Replace these with 360 @1,X,Y
• replace line 460 with 460 @RETURN

... which gives:

Code: Select all

10 REM SENZA SCHEDA GRAFICA
100 @ON:@CLR
115 DIMA%(151)
225 T=15
235 FORY0=-9.5TO9.5STEP.7
245 FORX0=-9.5TO9.5STEP.18
255 Y=INT(SIN(SQR(X0*X0+Y0*Y0+.001))/(SQR(X0*X0+Y0*Y0+.001))*75+T*1.3)
265 X=INT((X0+9.5)*5.5)+T*.92-14
275 GOSUB310
285 NEXT:T=T+2
295 NEXT
300 GOTO450
310 IFX<0ORX>151THENRETURN
320 IFY<0ORY>159THENRETURN
335 IFY<A%(X)THENRETURN
345 A%(X)=Y
350 Y=159-Y
360 @1,X,Y
400 RETURN
450 GETG$:IFG$=""THEN450
460 @RETURN

Changes to use MG's slightly higher resolution (160x192 vs. 152x160) left as exercise for the reader. The involved math also could need a good overhaul: the co-ordinate transforms are the wrong way round and there is no need to evaluate the same SQR() sub-expression twice.

[DarwinNE]

I remember this program, it comes from this article:

http://www.digitanto.it/Articoli/VIC-20_02.htm

It was one of the very first programs that I typed from a magazine on my VIC 20.

If I recall correctly, MC microcomputer at the beginning had a tendency to forget to put to zero the beginning of the BASIC area for VIC programs. They just instructed the reader to change addresses 43 and 44 (or just 44, like in the article above). That gave a situation where their programs tended to run only on some expansions and not on other. After a while, a reader pointed out that the zero was necessary and the problem was solved.

[armypavarmy]

thank you Mike for your precious and quick help.
All solved. long last.

[orion70]

Thanks Armando for this wonderful chunk of memories... I remember me regretting I couldn't type it in because I didn't have any RAM expansion (very expensive back then).

@DarwinNE: I was also a MC fan, couldn't wait for a new issue to literally consume it

And @Mike: needless to say, I never stop learning from you

[orion70]

...and here we are, after all these years: the revenge of the poor VIC boy

(reminds me of the Plus/4 I bought on Ebay five years ago. It was a bit of a compensation for the one I never received when I was 18: it was supposed to come as a bonus for buying a set of dishes, but the seller was a scammer and even wrote to my mother from jail to ask for money for his release - but this is another story )

[Mike]

Here's my stab at a version that fully utilizes the higher resolution of MINIGRAFIK (download). You'll have to run MG first, with at least a +8K RAM expansion:

Code: Select all

10 DIMV(159):FORU=0TO159:V(U)=192:NEXT
11 :
12 X0=-9.5:X1=9.5:DX=(X1-X0)/120
13 Y0=-9.5:Y1=9.5:DY=(Y1-Y0)/39
14 :
15 @ON:@CLR
16 FORB=0TO39:Y=Y0+DY*B
17 FORA=0TO120:X=X0+DX*A
18 R=SQR(X*X+Y*Y)
19 Z=1:IFR<>0THENZ=SIN(R)/R
20 U=A+B:V=191.5-2*B-(139*Z+13)
21 IFV(U)>VTHENV(U)=V:@1,U,V
22 NEXT
23 NEXT
24 :
25 GETA$:IFA$=""THEN25
26 @RETURN

... which results in this:



As I wrote in my previous post, the co-ordinate transforms got a good overhaul. From the integer valued loop variables A and B, the co-ordinates X and Y in the X-Y-plane of the 3D function are derived (see lines 16 and 17), as well as the pixel co-ordinates of the X-Y-plane on screen (see line 20). The screen Y co-ordinate is adjusted by the Z value of the function. The distance of the argument (X,Y) to the origin, R, is only evaluated once per pixel plot, in line 18.

With both programs, the evaluation in X and Y runs from -9.5 to 9.5, so we get the same section in the X-Y-plane to look at. The pixel plot is inlined in line 21 and omits the screen co-ordinate check. MG would anyhow stop the running program with an ?ILLEGAL QUANTITY error in case of screen co-ordinates outside the 160x192 range. The original program explicitly needed to check these, as otherwise the POKEs into the bitmap would thrash memory.

The function evaluation in line 19 uses the limit value of SIN(R)/R for R->0, which is 1, as default. For R not equal to 0, the evaluation proceeds normally. This method also avoids ?DIVISION BY ZERO errors and one does not need to 'wiggle' at the R argument to force it to unequal 0.