vc-20: orb mega demo was updated (fastloader and 6 new screens)
category: general [glöplog]
fast link: orb mega demo
do you know this?
things you always wanted to code but you never managed?... because of different reasons like: no time, not at the top of the prio list, job or too lazy ?
back when i was 13 fast- and irq loaders on c64 popped up and i was totally fascinated of this stuff. till then i only did a few intros.. and i said to myself... one day...i will code my own fastloader.
and just 31 years later... i finally did it :)
the fastloader is done since 7 or 8 years but i wanted to fastload our vc20 demo "omd" and that was a real problem since there isn't enough memory left to hold the fastloader in memory...
so the entire project went to sleep for some years.
but one day i had the idea...why not download the fastloader code from floppy memory before?... so i did...
the download needs 28 bytes in memory this is even smaller than the old loader ;)
so just have a look to our updated "orb mega demo delux" for vc20
including:
-fastloader: on the fly gcr decode (can be done faster i know was enough for the vc20)
-5 new 4mat tunes
-6 new screens
-two new effects from 4mat
-the end part has been totally rewritten by 4mat
-three new effects from ultra
-all screen of ultra have been reworked to fade out clean
-some of the screens got a facelift
-samples and replay in the checkboard zoomer was updated. we recognised it's almost
not hearable on real hardware.
-fixed bugs
in two screens we are using the unconnected ram feature discovered by viznut...
the demo comes with two different starters on disk:
"omd.full"
shows all effects old and new...
so if you have some time left start this one runtime is almost 16 minutes...
"omd.new.parts"
if you fed up with the old effects you can run this one
shows only the new effects... but with intro and endpart
runtime is almost 10 minutes...
cheers
ultra
do you know this?
things you always wanted to code but you never managed?... because of different reasons like: no time, not at the top of the prio list, job or too lazy ?
back when i was 13 fast- and irq loaders on c64 popped up and i was totally fascinated of this stuff. till then i only did a few intros.. and i said to myself... one day...i will code my own fastloader.
and just 31 years later... i finally did it :)
the fastloader is done since 7 or 8 years but i wanted to fastload our vc20 demo "omd" and that was a real problem since there isn't enough memory left to hold the fastloader in memory...
so the entire project went to sleep for some years.
but one day i had the idea...why not download the fastloader code from floppy memory before?... so i did...
the download needs 28 bytes in memory this is even smaller than the old loader ;)
so just have a look to our updated "orb mega demo delux" for vc20
including:
-fastloader: on the fly gcr decode (can be done faster i know was enough for the vc20)
-5 new 4mat tunes
-6 new screens
-two new effects from 4mat
-the end part has been totally rewritten by 4mat
-three new effects from ultra
-all screen of ultra have been reworked to fade out clean
-some of the screens got a facelift
-samples and replay in the checkboard zoomer was updated. we recognised it's almost
not hearable on real hardware.
-fixed bugs
in two screens we are using the unconnected ram feature discovered by viznut...
the demo comes with two different starters on disk:
"omd.full"
shows all effects old and new...
so if you have some time left start this one runtime is almost 16 minutes...
"omd.new.parts"
if you fed up with the old effects you can run this one
shows only the new effects... but with intro and endpart
runtime is almost 10 minutes...
cheers
ultra
Fantastic work! Re-watching the whole thing now, congratulations on achieving and surpassing your goal! Looking forward to the new content :)
That kicked ass :)
Also interesting to learn a little about the 'unconnected ram'. I thought at first "what, they put some ram in there but didn't bother to use it?!" but the truth is maybe more interesting for coders :D
Also interesting to learn a little about the 'unconnected ram'. I thought at first "what, they put some ram in there but didn't bother to use it?!" but the truth is maybe more interesting for coders :D
indeed... @unconnected ram. this opens up new worlds on vc-20.
for those who aren't that much into vc20. the vc20 can only
display chars for gfx.
so you have a char memory and a screen memory (which chars are
displayed where)
with the unconnected ram effect you can place any gfx line
at any position on screen.
how does that work?
you can set the positon of the screen/char mem to different
positions on vc-20. on the unexpanded vc20 there is
as you maybe know quite less memory (5kb only) so
it is possible to set the screen/char memory to places where
no ram is connected...
if you do for example in basic you get a screen
with strange effects on screen. i recognised this
when i was 13 on my first vc20 but never investigated this.
besides i was too small to understand i just coded some
datalines with asm code...;)
if you set the videochip in that mode the video chip
reads back the last byte which was on the bus.
for example a:
cmp #$55
which is in hex
$c9 $55
c9 is ignored $55 is read back from the video chip and displayed
this explained the not static display if you set in basic. it's
moving the entire time because it outputs stuff from the current
running code.
advantages of this mode:
-you can display every gfx on any place
-some kind of realtime decompression is possible
for example:
lda ($00,x)
2 bytes
outputs 3 bytes of 0 (if the ram and x is set correctly) on screen.
compared to:
cmp #$55
cmp #$55
cmp #$55
6 bytes
there are alot of other tricks you can save memory. so you need
a special converter to create the output code.
disadvantges:
-needs 100% cycle excat code. if the code is just shifted by one cylce
the $c9 (upper example) is displayed instead of the gfx)
-gfx is almost twice as long than before (because the gfx must be included
in the code)
-needs 100% of cpu time since the cpu outs the gfx
-x-shift hw register does not work as planned. quite logical
because if you output the gfx by yourself it cannot shift.
you have to shift your code.
i guess 4 bit of the hw reg works never tried.
-ever wondered why there is always a strange yellow in the unconnected
ram effects? one color is fixed the colors from the char color ram.
it must be $0f (f is yellow). it seems the the data which is read back
is anded with the color ram
as you can see has alot disadvantages but still you can code
new effects with it ;)
first used (so far i know) in impo 3 by viznut/pwp... really
a great trick... thanks :)
further reading:
ftp://www.zimmers.net/pub/cbm/vic20/programming/vic20frontiers.txt
cheers ultra
for those who aren't that much into vc20. the vc20 can only
display chars for gfx.
so you have a char memory and a screen memory (which chars are
displayed where)
with the unconnected ram effect you can place any gfx line
at any position on screen.
how does that work?
you can set the positon of the screen/char mem to different
positions on vc-20. on the unexpanded vc20 there is
as you maybe know quite less memory (5kb only) so
it is possible to set the screen/char memory to places where
no ram is connected...
if you do for example in basic you get a screen
with strange effects on screen. i recognised this
when i was 13 on my first vc20 but never investigated this.
besides i was too small to understand i just coded some
datalines with asm code...;)
if you set the videochip in that mode the video chip
reads back the last byte which was on the bus.
for example a:
cmp #$55
which is in hex
$c9 $55
c9 is ignored $55 is read back from the video chip and displayed
this explained the not static display if you set in basic. it's
moving the entire time because it outputs stuff from the current
running code.
advantages of this mode:
-you can display every gfx on any place
-some kind of realtime decompression is possible
for example:
lda ($00,x)
2 bytes
outputs 3 bytes of 0 (if the ram and x is set correctly) on screen.
compared to:
cmp #$55
cmp #$55
cmp #$55
6 bytes
there are alot of other tricks you can save memory. so you need
a special converter to create the output code.
disadvantges:
-needs 100% cycle excat code. if the code is just shifted by one cylce
the $c9 (upper example) is displayed instead of the gfx)
-gfx is almost twice as long than before (because the gfx must be included
in the code)
-needs 100% of cpu time since the cpu outs the gfx
-x-shift hw register does not work as planned. quite logical
because if you output the gfx by yourself it cannot shift.
you have to shift your code.
i guess 4 bit of the hw reg works never tried.
-ever wondered why there is always a strange yellow in the unconnected
ram effects? one color is fixed the colors from the char color ram.
it must be $0f (f is yellow). it seems the the data which is read back
is anded with the color ram
as you can see has alot disadvantages but still you can code
new effects with it ;)
first used (so far i know) in impo 3 by viznut/pwp... really
a great trick... thanks :)
further reading:
ftp://www.zimmers.net/pub/cbm/vic20/programming/vic20frontiers.txt
cheers ultra
Sweet!
