Silly Program
Moderator: Moderators
Silly Program
Here is a silly program to make your vic a completely new look:
1 PRINT"{CLR}WAIT...": J=32768: FORT=5120 TO 7166 STEP 2: I=PEEK(J): POKET,I: POKET+1,I: J=J+1: NEXT
2 POKE56,20: POKE52,20: POKE36867,23: POKE36869,253: REM J DANIELS 1996
READY.
1 PRINT"{CLR}WAIT...": J=32768: FORT=5120 TO 7166 STEP 2: I=PEEK(J): POKET,I: POKET+1,I: J=J+1: NEXT
2 POKE56,20: POKE52,20: POKE36867,23: POKE36869,253: REM J DANIELS 1996
READY.
Last edited by Jeff-20 on Mon Aug 02, 2004 11:00 am, edited 1 time in total.
I think there is a way, but I don't remember. It may not be in the Ref guide. I think it may be in the Compute VIC series books.Anonymous wrote:so what I really want to know is what one byte value address you zap inthe kernel to make it so a linefeed happens after using the visible part of the screen
it sucks that it still lets you use the unvisible area...
I don't think there is an easy way to solve scrolling, since the kernel is fixed at 22 characters x 23 rows, no matter how you modify the VIC-I screen resolution. You would have to hack your own kernel which looks into RAM or VIC-I registers, but since the routine for scrolling probably is quite optimized, I'm not sure how easy it is to make it flexible.
On the other hand, since each character on screen takes 8x16 pixels, you could take advantage of this and get a bigger display than normally:
POKE 36865,17:POKE 36867,35
On the other hand, since each character on screen takes 8x16 pixels, you could take advantage of this and get a bigger display than normally:
POKE 36865,17:POKE 36867,35
Anders Carlsson
Sorry, no; the Basic and Kernal are ROMs. I explained the VIC-20 memory model in detail in another phpBB forum last week, but I can paste it here as well since it is quite on-topic:
$0000-03FF: 1K of "low" RAM, mainly system memory but in theory possible to use for your own needs if you bypass both Basic and Kernel.
$0400-$0FFF: Empty slot where the 3K expansion cartridge fits
$1000-$1DFF: 3.5K of "user" RAM
$1E00-$1FFF: 0.5K of screen memory (which is part of the user RAM)
$2000-$7FFF: Three empty slots of 8K each (total 24K for expansion)
$8000-$8FFF: Character ROM
$9000-$93FF: I/O blocks address space (VIC-I, VIA etc)
$9400-$97FF: Colour memory RAM in nybbles (four bits/byte)
$9800-$9FFF: I/O blocks address space (probably for expansion)
$A000-$BFFF: Empty slot for 8K RAM/ROM (games cartridges etc)
$C000-$DFFF: 8K Basic ROM
$E000-$FFFF: 8K Kernel ROM
The screen memory is shifted from $1E00 to $1000 when 8K or more expansion RAM is added, to ensure a continuous workspace for Basic.
So the user RAM is 4K, but 0.5 kB is "stolen" by the graphics. Here we get 3.5 kB. Since it is possible to fill the screen memory with code or data, some people still see it as 4 kB (but beware of clearing the screen!). If you add the "low" RAM, we end at 5 kB. If we also count the 1 kB of nybbles as 0.5 kB of RAM, there is a total of 5.5 kB...
On the C64 however, which has 64K of RAM, it is possible to copy the ROMs into the beneath RAM and then make changes, but not even there I'm sure you can alter too much.
There is a zeropage address, $00D5 (decimal 213) which contains the logical line length, but changing that value will only be useful to confuse Basic whether a line break has occurred, i.e. if the current logical line spans over more than one physical line or not.
The following address contains the current screen line, so maybe you can
somehow use an interrupt which will set the current screen line outside the logical screen as soon as the cursor is outside of the visible area, force a scroll and then return the cursor to where it really was, if you understand how I'm thinking. I have not tried this myself, so I don't know if it will work...
This routine does not work (as it should). It will limit you to move beyond maxline (e.g. 10), but there will not occur any elegant scrolling. Maybe some other ZP registers have to be set to make scrolling occur. It also has a bug in that the logical line can be extended past several physical lines (see above), so one can fill the last "allowed" line with more content, cause a line wrap and then cheat the routine.
It may be a good source to continue working with, but I would suggest to disassemble the following Kernel routines to learn more:
$E8E8 : check decrement of line counter
$E8FA : check increment of line counter
$E975 : screen scrolling routines
Woo.. technical after only ten posts, but this was about programming, right?
$0000-03FF: 1K of "low" RAM, mainly system memory but in theory possible to use for your own needs if you bypass both Basic and Kernel.
$0400-$0FFF: Empty slot where the 3K expansion cartridge fits
$1000-$1DFF: 3.5K of "user" RAM
$1E00-$1FFF: 0.5K of screen memory (which is part of the user RAM)
$2000-$7FFF: Three empty slots of 8K each (total 24K for expansion)
$8000-$8FFF: Character ROM
$9000-$93FF: I/O blocks address space (VIC-I, VIA etc)
$9400-$97FF: Colour memory RAM in nybbles (four bits/byte)
$9800-$9FFF: I/O blocks address space (probably for expansion)
$A000-$BFFF: Empty slot for 8K RAM/ROM (games cartridges etc)
$C000-$DFFF: 8K Basic ROM
$E000-$FFFF: 8K Kernel ROM
The screen memory is shifted from $1E00 to $1000 when 8K or more expansion RAM is added, to ensure a continuous workspace for Basic.
So the user RAM is 4K, but 0.5 kB is "stolen" by the graphics. Here we get 3.5 kB. Since it is possible to fill the screen memory with code or data, some people still see it as 4 kB (but beware of clearing the screen!). If you add the "low" RAM, we end at 5 kB. If we also count the 1 kB of nybbles as 0.5 kB of RAM, there is a total of 5.5 kB...
On the C64 however, which has 64K of RAM, it is possible to copy the ROMs into the beneath RAM and then make changes, but not even there I'm sure you can alter too much.
There is a zeropage address, $00D5 (decimal 213) which contains the logical line length, but changing that value will only be useful to confuse Basic whether a line break has occurred, i.e. if the current logical line spans over more than one physical line or not.
The following address contains the current screen line, so maybe you can
somehow use an interrupt which will set the current screen line outside the logical screen as soon as the cursor is outside of the visible area, force a scroll and then return the cursor to where it really was, if you understand how I'm thinking. I have not tried this myself, so I don't know if it will work...
Code: Select all
start:
SEI
LDA #<irq
STA $0314
LDA #>irq
STA $0315
LDA #0
STA code-1
CLI
RTS
irq:
LDA code-1
BEQ normal
LDA #maxline
STA $D6
LDA #0
STA code-1
BEQ out
normal:
LDA $D6
CMP #maxline+1
BMI out
LDA #1
STA code-1
LDA #22
STA $D6
out:
JMP $EABF
It may be a good source to continue working with, but I would suggest to disassemble the following Kernel routines to learn more:
$E8E8 : check decrement of line counter
$E8FA : check increment of line counter
$E975 : screen scrolling routines
Woo.. technical after only ten posts, but this was about programming, right?
Anders Carlsson
i just been schooled!!
i don't feel like i've started to even mess with machine code...
but what you are saying makes perfect logical sense...
i think if I was to actually use this char set mode it would be within a program where you wouldn't need to worry about scrolling because you have control...
still, it's a fun investigation
i don't feel like i've started to even mess with machine code...
but what you are saying makes perfect logical sense...
i think if I was to actually use this char set mode it would be within a program where you wouldn't need to worry about scrolling because you have control...
still, it's a fun investigation
Some day I might return to looking into why the posted routine is not enough.. I had a similar one where I saved the current row ($D6) and restored it rather than setting it at a fixed row, and then scrolling happened but there was no limitation on window size and things became screwed up after a while.
I also lived only with Basic for the first six years or so, but somewhere around the age of 15, I got my Action Replay (for the Commodore 64) and had a quick way to enter machine code. However, I didn't do anything serious until five years later, being invited to the Veni Vidi VIC! demo, and I still think I'm an amateur when it comes to realizing the full potential in combining instructions so 1+1=3. I haven't looked into the illegal (undocumented, sometimes unreliable) op-codes yet.
I also lived only with Basic for the first six years or so, but somewhere around the age of 15, I got my Action Replay (for the Commodore 64) and had a quick way to enter machine code. However, I didn't do anything serious until five years later, being invited to the Veni Vidi VIC! demo, and I still think I'm an amateur when it comes to realizing the full potential in combining instructions so 1+1=3. I haven't looked into the illegal (undocumented, sometimes unreliable) op-codes yet.
Anders Carlsson
Given we're still talking VIC-20 here (now, why wouldn't we?), that is more or less dirt easy:
"Remove" horizontal borders:
POKE 36864,6 : POKE 36866,28+PEEK(36866)AND128
"Remove" vertical borders:
POKE 36865,14 : POKE 36867,70
For NTSC, adjust the values (6,28,14 and 70) slightly. Notice how some garbage below the writable area appears. This area can be POKEd into action, given that the screen memory starts on 7168 or before (so the VIC-I chip has a full kilobyte to read and write from).
"Remove" horizontal borders:
POKE 36864,6 : POKE 36866,28+PEEK(36866)AND128
"Remove" vertical borders:
POKE 36865,14 : POKE 36867,70
For NTSC, adjust the values (6,28,14 and 70) slightly. Notice how some garbage below the writable area appears. This area can be POKEd into action, given that the screen memory starts on 7168 or before (so the VIC-I chip has a full kilobyte to read and write from).
Anders Carlsson