UDGs on 8 Kb+ expanded

[jalavera]

Hi!

I'm trying to get some UDG on a 8Kb+ Expanded VIC-20 to work using Quetzalcoatl (or assembler).

On unexpanded I do this:
poke 36869,255 ($9005,$FF)
Then I poke from 7168 ($1C00) with desired values to customize udg.
Pokeing screen from 7680 ($1E00) with 0,1,2,3, etc I obtain the desired udg on a fixed sreen position.

Which are the corresponding memory adresses to do the same on an expanded 8Kb++?

Thanks for your help!!!

[Mike]

Please check these four threads:

o Reorganising 8k RAM?,

o New release: 3 New Fonts for Your Vic,

o How to reinit 16k expansion? and, most importantly,

o VIC-20 Memory Layout.

In any case, the position of text screen and character generator is defined by VIC register $9005 (as you already know), and bit 7 (value 128) of $9002, which adds 512 to the text screen (and colour RAM) base address.

As for using Quetzalcoatl, you need to make sure it produces an executable program that doesn't overlap with possible positions of text screen and character definitions. If you can't do that, you're out of luck.


Edit: the "VICG" target of Quetzalcoatl is most probably what you need: a full character set at $1000, the screen at $1800, and runtime+executable following that at $1A00.

What does *not* work as intended is the "VICH" target. This one assumes a 4K character set (double-height chars) from $1400..$23FF, which does not work on real hardware (and, in fact, relies on a implementation fault/bug in *very* *early* VICE emulators).

[jalavera]

Thanks for the information. I read it, but i'm not able to run any program using quetzalcoatl VICG target as you suggested.
I explain all steps to see if anyone can help.

1) First. Here is the Quetzalcoatl code to test (test.c):

Code: Select all

const int c=30720,d=7980;
int z=0;
char input;
byte duck[32]={14,27,63,31,15,7,15,31,0,0,0,0,0,192,112,188,31,29,30,15,3,1,1,3,206,30,124,248,224,64,64,224};
char clearscreen=(char)147;

void load_udgs(void)
{
  for (z=0; z<32; z++) memory[7168+z]=duck[z]; 
}
void inic(void)
{
 putln(clearscreen); 
 memory[36869]=255; 
 memory[36879]=13; putln(clearscreen); 
}
void draw_duck(void)
{
 memory[d]=0;memory[d+c]=5;
 memory[d+1]=1;memory[d+c+1]=5;
 memory[d+22]=2;memory[d+c+22]=5;
 memory[d+23]=3;memory[d+c+23]=5;
}
void main(void)
{
 load_udgs();
 inic();
 draw_duck();
}

2) I compile with no changes the default UPLRTIME.ASM to UPLRVICG.OBJ by using:

Code: Select all

quetzal -Dtarget=7 -cm uplrvicg.obj uplrtime.asm

3) Then I compile test.c using "VICG" target:

Code: Select all

quetzal -b -r vicg -o test.prg test.c

4) Compiler ends without any warning or error:

Code: Select all

Quetzalcoatl C/UPL 6502 Cross Compiler 2.1.0 BETA www.kdef.com/geek/vic
Copyright Brendan Jones, 1998-2006. All Rights Reserved.
Debugged, augmented, and tested by Harry Dodgson, 2005.

You must read and agree to the terms in LEGAL.TXT before using this software.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

WARNING: This is a BETA release, built on Oct  9 2006 at 12:59:11.
         This BETA release is incomplete and known to contain bugs.

I: Module patos.        Segment Sizes: Code:    197 bytes. Data:     36 bytes.
I: Module uplrtime.     Segment Sizes: Code:   4180 bytes. Data:      0 bytes.
I: Created a one-time BASIC Bootstrap (assuming BASIC begins at 4096).
I: Executable starts at address 4096, and is 4413 bytes long.
I: Success!  Saved executable patos.prg.  Entry point at 8460.
I: This is a vicg executable; You must reconfigure memory before loading it:
   poke 36869,224:poke648,24:print chr$(147) or use a vicg snapshot.
I: To then run the executable on an expanded VIC-20 then type SYS 8460 or RUN.

5) Put resulting PRG in a D64 image. Now I have test.d64 with test.prg inside.

6) Run VICE emulator with FULL memory blocks enabled.

7) Attach D64 image (test.d64) to "drive 8".

8.) Type in Vice as suggested for Quetzalcoatl.

Code: Select all

poke 36869,224:poke648,24:print chr$(147)

9) Type in Vice:

Code: Select all

LOAD"TEST",8

10) Some @@@@@@ appears then READY.

11) If I type RUN then ?UNDEF'D STATEMENT ERROR

12) No LIST. No RUN. No SYS

Thank you!

[vicist]

For characters placed at 7168 and 8k+ ram the poke is:-

poke 36869,(peek(36869)and240)+15
or
poke 36869,207

I tried both and they work OK.

[jalavera]

poke 36869,(peek(36869)and240)+15
or
poke 36869,207

Ok. Thanks. But I have to change 36869,255 to 36869,207 in test.c source or I have lo leave 255 in test.c. Or write poke36869,207:poke648,24:print chr$(147) in Emulator? Or both changes?

I think I test all options and it doesn't work

[vicist]

const int c=30720,d=7980;

I presume c=colour and d=display.

This is wrong!
Expanded colour starts at 37888 and display starts at 4096.

[jalavera]

I update the code to fit expanded needs. Here it is:

Code: Select all

const int c=33792,d=4396; // where 'c' is color offset: 37888-4096 & 'd' is DUCK expanded screen position.
int z=0;
char input;
byte duck[32]={14,27,63,31,15,7,15,31,0,0,0,0,0,192,112,188,31,29,30,15,3,1,1,3,206,30,124,248,224,64,64,224};
char clearscreen=(char)147;

void load_udgs(void)
{
  for (z=0; z<32; z++) memory[7168+z]=duck[z]; 
}
void inic(void)
{
 putln(clearscreen); 
 memory[36869]=207; 
 memory[36879]=13; putln(clearscreen); 
}
void draw_duck(void)
{
 memory[d]=0;memory[d+c]=5;
 memory[d+1]=1;memory[d+c+1]=5;
 memory[d+22]=2;memory[d+c+22]=5;
 memory[d+23]=3;memory[d+c+23]=5;
}
void main(void)
{
 load_udgs();
 inic();
 draw_duck();
}

I'd changed expanded color references, display position and 36869,255 to 36869,207 as vicist suggested.

I presume c=colour and d=display.

Not exactly. 'c' is colour offset (respect a fix position in screen). So it is 37888 - 4096
'd' is a fix screen position to start drawing the dack (4 UDGSs).

One more difference is that code is compiled with quetzalcoatl as VICX target (not VICG as Mike suggested). My surprise is that it works!. The target prg file runs ok on expanded VIC without the need to do some POKEing before. I thought it was not possible to do. I was wrong. Next questions are:

Why I need VICG target if UDGs works with VICX target?
Why VICG is not working in this case? What I have to change to make it work? In this case, Do I need some POKEing before run? Are the suggested quetzal good for this purpose?

Sorry for too many questions. I apologize.

Thanks.

[vicist]

const int c=30720,d=7980;

I presume c=colour and d=display.

This is wrong!

Not exactly. 'c' is colour offset (respect a fix position in screen). So it is 37888 - 4096

Apart from pointing you to the correct colour/display start addresses for 8k+ expanded ram, I was pointing out that your math was wrong.

38400-7980 = 30420 not 30720.

[jalavera]

Unexpanded screen starts at 7680. d=7980 means 300 positions after 7680 (7680+300) and in my first program was a fix position to draw the duck. This could be another number. Maths were ok. In fact, in newer version this 'd' number is different adopting of course the expanded screen codes you pointed.
The problems were on 4096 (instead of 7680) and on 37888 (instead of 38400). This 'c' value on expanded is (37888-4096=33792) instead of (38400-7680=30720) on unexpanded, in my program.
Changing POKE 36869,255 (for unexpanded) to POKE 36869,207 (for expanded) was another error. Thanks for pointing this too.

[vicist]

You are correct. It's my math that is wrong.

I apologise.

[jalavera]

Hi!

Finally I want to switch to cc65 because quetzalcoat is very buggy from my point of view. In fact it's not being update since at least 10 years and seems to not be updated in the futures

I never program in C so it's a little difficult to me to start to do it.
I found the way to write something "for beginers" and my first question is how can I make something similiar to:

PRINT CHR$(142), in BASIC

I tested cputc (from conio.h) but it only writes printble stuff (not screen codes). What's the suitable way to do it??

Thanks.

[groepaz]

conio is optimized portable console output, so it doesnt understand any of the petscii control codes... if you want that, use stdio functions, putchar() would be the function that can do it. that said, its probably a better idea to write to the respective VIC registers directly (someone else can probably tell what that would be) - since the stdio functions have quite a bit of overhead and sometimes give undesirable results.

[jalavera]

Finally I found an easy and "cheap" way: #include <cbm.h>.
For instance, cbm_k_bsout((char)142); do the job.
This <cbm.h> only adds 15 bytes to compiled program,
so no need to use <stdio.h> (if not needed) which adds some hundreds bytes.
Thanks!