Unexpanded VIC 20 Memory

Basic and Machine Language

Moderator: Moderators

Legacy
Vic 20 Enthusiast
Posts: 154
Joined: Wed Dec 31, 2008 4:01 pm

Post by Legacy »

So I've been studying and I've made some revisions and here is the final copy of the Fill Screen Program , please let me know what could be improved upon or if I've done all I can. Thank You!

Code: Select all

#processor 6502		;vic 20 processor	program size 512 bytes?

	org $033C	;store ML program at sys 828 (tape buffer)
	
char	equ $01		;$01 = screen code A
colr	equ 5		  ;color green
scr1	equ $1e00	;first 256 screen RAM locations
scr2	equ $1eff	;because one byte can only handle 255 numbers
col1	equ $9600	;color RAM 38400
col2	equ $96FA	;color RAM 38656

	ldy #$00	;set y register or 'counter' to immidiate zero 0 

loop			;fill screen RAM with char $01 - A

	lda #char	;load accumulator with "A"-$01
	sta scr1,y	;store contents of accumulator to 7680 with absolute value 0
	sta scr2,y	;
	lda #colr	;load AC with color byte
	sta col1,y	;poke 38400,5
	sta col2,y	;poke 38656,5			
	iny		;increase y by one so next screen/color memory positions are pointed to
	bne loop	;if Y != 0 then keep increasing the value until both pages are full 
	
	rts		;return from loop when pages are full

This is a type of indexed looping , used to transfer memory from one place to another (screen memory to cassette buffer in this case)

Compile with : dasm fillscreen.asm -ofillscreen.prg

SYS828 to run from VICE unexpanded


*now i remember about seeing an article here that explains ML on the vic is useless you can do everything you need to with POKES and SYS828, and BASIC, is that true...
Leeeeee
soldering master
Posts: 396
Joined: Fri Apr 23, 2004 8:14 am

Post by Leeeeee »

A few points..

One byte can handle 256 different values from $00 to $FF inclusive.

I set scrn2 to $1EFA because the screen RAM ends at $1FF9, the last six bytes in the second page are unused, and it is easier to overlap the two 256 byte fills by six bytes than to fill exactly 506 bytes. For the same reason I set colp2 to $96FA because the colour RAM ends at $97F9. It wouldn't matter in this case if you overwrote those six bytes but shortcuts like that can come later.

I used char EQU "A"-$40 because it makes it easier to change the character. E.g. changing it to char EQU "W"-$40 and letting the assembler calculate the value of "W"-$40 is easier than looking up the PETSCII value for W.

The Y register is used as an index, the address mode is called absolute indexed addressing, the value of scrn1, for example, is the absolute value. This is just one of many addressing modes that the 6502 can use, you should learn them all, what they do and the terms used to refer to these modes then you will understand better what others mean and they will understand you better. This leads to less frustration.

In your version you have changed a comment to read ;load accumulator with "A"-$01" which is wrong, the value is "A"-$40, and not as usefull as the original comment because now if you change the char equate you will need to change this comment as well. I realise it's not much of a problem in such a short program but programs can easily run into hundreds or even thousands of lines of source and maintaining comments like that becomes a chore. Better just say ;load accumulator with fill character which will be true whatever the value of that fill character is.

The program does not transfer memory from one place to another but fills the screen and colour memories with the preset values.

Lee.
Richard James
Vic 20 Devotee
Posts: 269
Joined: Mon Feb 04, 2008 6:06 am

Post by Richard James »

This program can be rewritten in BASIC to help you understand.

Code: Select all

10 FOR I = 0 TO 255
20 POKE 7680 + I, 1
30 POKE 7936 + I, 1
40 POKE 38400 + I, 5
50 POKE 38656 + I, 5
40 NEXT
Change is inevitable except from a vending machine.
Legacy
Vic 20 Enthusiast
Posts: 154
Joined: Wed Dec 31, 2008 4:01 pm

Post by Legacy »

:idea: :roll: well that was kinda slow compared to the speed of pure pwnage

Thank you Leeeeeeeeeee, but arent we also putting a value from ROM (character screen codes) into the screen memory, which involves transferring bytes of memory...we're loading A ROM character memory into screen character codes, which is what absolute indexing does, transfers memory. I know the values are preset, but we didn't create them, they had to be extracted and moved into new locations.

and last time i checked 8191-7680 = 512 locations, oh but i see what your saying there is only 506 squares (22x23) on the screen, so where does it stop? 8185 i assume and what happens to those 6 bytes they are overwritten which i could modify later as my skills progress as you have, alrighty then, whats next!?
Commodore Explorer
Vic 20 Newbie
Posts: 11
Joined: Thu Jan 31, 2008 12:37 pm

Post by Commodore Explorer »

Legacy wrote:

Code: Select all

#processor 6502		;vic 20 processor	program size 512 bytes?
Your program, when assembled, is actually 22 bytes long. (DASM will produce a 24-byte file -- the first two bytes are the load address which determines where in memory the program should reside.)

If you are writing a program in the cassette buffer, you have a maximum size of 196 bytes. The first byte of the cassette buffer is 828 ($033C) and last byte is 1019 ($03FB), but there are four unused bytes beyond it (1020 to 1023), for a total of 196.

Immediately above the cassette buffer (at higher addresses) is the 3K RAM expansion area, which is empty and unusable without a 3K RAM Expansion or Super Expander cartridge.

If you're writing in machine language, you can always break the program into multiple segments that are not contiguous and have the code jump from one segment to the next. A lot of cartridge software is like this. The VIC's memory map reserves 8K for game cartridges, but a lot of cartridges are 16K. One half of the cartridge is located in the 8K area reserved for cartridges, and the other half is located elsewhere. Being able to break up the code is one of the advantages of machine language.
Legacy wrote:now i remember about seeing an article here that explains ML on the vic is useless you can do everything you need to with POKES and SYS828, and BASIC, is that true...
Which article was that? It's possible you may have misunderstood.

Machine language certainly isn't useless. Its big advantage is speed -- it can accomplish things much more quickly. There are other advantages, too, as I mentioned above. But it's a lot harder to use than BASIC. There are times when it doesn't make sense to develop a program in machine language when BASIC would do the job just as well. A BASIC program is a lot easier to maintain and easier for a person to read and understand.

Keep in mind that "SYS 828" is a BASIC command, but it calls a machine-language subroutine at address 828 ($033C). So if you use SYS 828 in a BASIC program, you're using machine language.

The VIC had plenty of professionally published software written in BASIC, including some games. There was also a lot of software that was written mostly in BASIC but with machine-language subroutines for extra speed where it was needed. In those cases, if you typed LIST, you would occasionally see a SYS command to a particular address where a machine-language subroutine started.

There's nothing BASIC can do that machine language cannot because the BASIC interpreter is written in machine language. If you have a copy of the VIC's memory map, you'll see that the second-last 8K block of memory is designated "BASIC ROM" -- that's the BASIC interpreter. It is written in machine language and it interprets and executes BASIC programs by translating them into machine language as they are being run.

But some things are a lot easier to do in BASIC, like dealing with floating-point numbers or manipulating strings. BASIC has the routines built-in to deal with them. With machine language, you'll either have to call BASIC's routines or write your own.
Legacy
Vic 20 Enthusiast
Posts: 154
Joined: Wed Dec 31, 2008 4:01 pm

Post by Legacy »

I actually just learned all of that except the 24byte length thank you!

now how would I go about getting the program to self execute upon loading, not having to write in SYS 828


so much for you tube being educational... boray where can i get a copy of that book! :lol: http://www.youtube.com/watch?v=3tMdcU8kmZQ
stop taunting me with it and give it up already
Richard James
Vic 20 Devotee
Posts: 269
Joined: Mon Feb 04, 2008 6:06 am

Post by Richard James »

The VIC-20 uses a type of Tile Mapped Display. There are three components.
1) The character data (normally set to the character ROM)
2) What characters to display where. Screen memory
3) What Colour to display each tile.

In the program above you are only altering 2 and 3. The VIC chip automatically puts the right bits on the screen, it gets the information from the character ROM.

By pokeing 7680 with 1 we are just telling the VIC chip to copy the data from the character ROM at 1 to that section of the screen. Since we filled the entire screen with 1 the VIC chip copies the same data to each location. In this case it would use a 8x8bit image.

Our program did not copy this data. The VIC does not have a bitmapped display.

To create custom graphics we need to move the location the VIC chip picks up the character memory from ROM to elsewhere in memory. Then we alter that location in memory.

I leave the rest of the questions up to you.
Change is inevitable except from a vending machine.
Commodore Explorer
Vic 20 Newbie
Posts: 11
Joined: Thu Jan 31, 2008 12:37 pm

Post by Commodore Explorer »

Legacy wrote:now how would I go about getting the program to self execute upon loading, not having to write in SYS 828
Do you want it to run the machine-language program when you type RUN, instead of when you type SYS 828? (First you load the program, then type RUN, and then the machine-language program executes.)

Or do you want it to execute immediately after loading without any user intervention? (This would be similar to some Commodore 64 software and games where the user would load the program with LOAD "*",8,1 and the program would load and then start running without the user ever having to type RUN.)
User avatar
Mike
Herr VC
Posts: 4841
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

Richard James wrote:The VIC does not have a bitmapped display.
Did you ever try out VICtoria Gold Ed.? Or MINIGRAFIK?

In its brevity, your claim is false. Even though a "text" register map is necessary for the VIC chip to access the pattern data, it can be set up with certain fixed contents, so that any displayed pixel corresponds to a certain bit in memory. That is a bitmapped display.

Michael
carlsson
Class of '6502
Posts: 5516
Joined: Wed Mar 10, 2004 1:41 am

Post by carlsson »

I'd call it simulated bitmap, as the resolution is not only limited to the size of RAM, but also the number of characters in the character generator. Similarly, developing routines for software sprites won't give the VIC hardware real sprites, just a replacement that in many aspects can be used in the same way.

But the approach of bitmapping through redefined characters has a benefit: sometimes you can optimize the bitmap, reusing the same character several times. For most part the screen still will appear bitmapped, but no redudancy. I did this on the Mega-Cart Stayin' Alive intro, freeing enough white space to fit a scroller.
Anders Carlsson

Image Image Image Image Image
User avatar
Mike
Herr VC
Posts: 4841
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

carlsson wrote:I'd call it simulated bitmap, as the resolution is not only limited to the size of RAM, but also the number of characters in the character generator.
For all intents, and purposes, it is a bitmap. A limitation by its size - be it by available RAM, or address generator range (done with the text register) - is no argument for, or against that fact.
Similarly, developing routines for software sprites won't give the VIC hardware real sprites, just a replacement that in many aspects can be used in the same way.
Agreed. On the Amiga, they are called blitter objects.
But the approach of bitmapping through redefined characters has a benefit: sometimes you can optimize the bitmap, reusing the same character several times.
Then you have a graphical, even hi-res display, yes. But not a bitmap anymore.

Michael
Richard James
Vic 20 Devotee
Posts: 269
Joined: Mon Feb 04, 2008 6:06 am

Post by Richard James »

I does not help to call it a bitmapped display when people are trying to write programs for it, it will just confuse them especially if they are used to computers with real bitmapped displays.

You can't poke into a place in the VIC's memory to draw a dot on the screen, you can on a bitmapped system like the Atari ST.
Change is inevitable except from a vending machine.
User avatar
Mike
Herr VC
Posts: 4841
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

Richard James wrote:I does not help to call it a bitmapped display when people are trying to write programs for it, it will just confuse them especially if they are used to computers with real bitmapped displays.
I don't think I can confuse anybody about that.
You can't poke into a place in the VIC's memory to draw a dot on the screen, you can on a bitmapped system like the Atari ST.
Once the hires screen has been set up by MINIGRAFIK, I am perfectly able to set a single point via POKE into the bitmap as follows:

somewhere earlier in the program:

Code: Select all

DIMB(7):S=1:FORI=0TO7:B(7-I)=S:S=S*2:NEXT
to plot a single point:

Code: Select all

AD=4352+INT(X/8)*192+Y:POKEAD,PEEK(AD)ORB(XAND7)
or simply use MINIGRAFIK's point plot command:

Code: Select all

@1,X,Y
which internally works in the same way, but also takes care of the colour RAM.

In no way is this different from other bitmapped display systems. They will have other addressing schemes, of course.

Michael
Legacy
Vic 20 Enthusiast
Posts: 154
Joined: Wed Dec 31, 2008 4:01 pm

Post by Legacy »

Mike, how do i use this minigrafik program??

And yea, even i know the vic can be bitmapped as explained in the programmers refrence manual, however it is very unpractical on the unexpanded vic because putting the whole screen into hi-resolution mode is very memory intensive, but you can bitmap small sections at a time to handle what you want. i got the minigrafik program and loaded it, does that mean my system is now in hi-res mode and I can use the special @ commands?

Also I've written a FILL/CLEAR routines for DASM but I want to add another routine to slow down the cycles a bit, I've got the For...Next loop written I'm having a hard time implementing it. I need some kind of main logic loop or something. And still trying to find out how to RUN this program automaticaly on VICE without doing a SYStem call.


***WARNING: DO NOT RUN IF YOU HAVE SEIZURES***

Code: Select all

;FILL SCREEN/CLEAR SCREEN ROUTINES
#processor 6502		

	org $033C	;store ML program at sys 828 (tape buffer)
	
char	equ " "-$40	;blank space
char2  equ " "-$41	;
colr	equ 5		;color green
colr2  equ 1		;color white
scr1	equ $1e00	;first 256 screen RAM locations
scr2	equ $1efc	;because one byte can only handle 255 numbers
col1	equ $9600	;color RAM 38400
col2	equ $96fc	; 50/50 screen split
;------------------------------------------------------------------------------------------
	ldy #$00	;set y register or 'counter' to immidiate zero 0 

fillscrn		;fill screen RAM with char $01 - A
	lda #char	;load accumulator with "A"-$41
	sta scr1,y	;store contents of accumulator to 7680 with absolute value 0
	sta scr2,y	;
	lda #colr	;load AC with color byte
	sta col1,y	;poke 38400,5
	sta col2,y	;poke 38656,5			
	iny		;increase y + 1
	bne fillscrn	;if Y != 0 then keep increasing 0-255(x2 page 1/2)
	
;-------------------------------------------------------------------------------------------
clear        		;dosent' really clear, just fills with new color
	ldx #$00	;set x counter to 0
clslp 
        lda #char2	;store 0 in accumulator
        sta scr1,x	;store 0 into first screen position 1st page
        sta scr2,x	;store 0 into first position	2nd page
        lda #colr2	;fill 7680 with black
        sta col1,x	;colorcode 0
        sta col2,x	;page2
        inx		;increase x
        bne clslp

	jmp fillscrn
;-------------------------------------------------------------------------------------------
;
;routine to slow down the loop - double imbedded FOR...NEXT loop
;(y counts 255, x counts 100....0)
;
;	ldx	#100	;1st loop
;	ldy	#0     ;2nd loop
;slolp
;	dey		; 
;	bne	slolp	;if y isnt 0, decrease it again-inner loop
;	dex		;decrease outter loop
;	bne	slolp	;if x != 0, decrease outter loop (total 100x255cycles or 25,500)
;	
;---------------------------------------------------------------------------------------------
sorry if formatting is off, im using notepad and tab keys

i was thinking too, i dont know much about it, but isnt there a shift bit instruction, now what if we implemented the shift bit in one of those routines , we could kill 2 birds with one stone the on bit would be one color, and the off bit would be another. is that possible or does each routine need its own parameters. ive looped this one and its too fast to even distinguish one color from another.
User avatar
Mike
Herr VC
Posts: 4841
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post by Mike »

Legacy wrote:Mike, how do i use this minigrafik program??

i got the minigrafik program and loaded it, does that mean my system is now in hi-res mode and I can use the special @ commands?
There is the data loader for version 4.02, which writes the executable of MINIGRAFIK (5 blocks) to disk.

You LOAD, and RUN this program (a LIST gives 2008 SYS 4622), then the VIC greets you again - with slightly less memory available -, the @ commands are available, and you can try out the various programs I posted in the thread 'Hires Graphics'.

VICtoria Gold also uses MINIGRAFIK, which here is automatically initialised before starting the main program.

Have fun,

Michael
Post Reply