quick demo:UFO

60 views
Skip to first unread message

Carl Attrill

unread,
Feb 7, 2014, 2:54:00 PM2/7/14
to fign...@googlegroups.com
Hi, I have made a demo to see how well self loading can work.
I have learned from the sprite'd utility that you can make effective use of loading blocks as you run a program, and then call up the changed code as you work. This is easy now as 0.9.8 firmware loads as a blank screen and no longer gives err #17 every time a known word is recompiled.

So in this demo you are able to load 9 simple UDGs from one block.

Step in the second block changes the value of some of the bytes while it also changes the vram location of each one.

To use this demo type in or avrdude the first block, I used 20 but you can use what you like, just alter the 'loadup' command in your second block to the block that has the byte code in it.

Load the second block up, then 

do. loadup

do. ufo

this is sound supported, space will stop the demo.

It's not the most elaborate demo you will ever see, but I now appreciate how well the FIGnition can handle multiple loops and smooth animation from very little code.

Anyway here are the fth files the hex files and a plug for the forum, it gets lonely there :-)

regards.

Carl.






ufo_pt100.hex
ufo_pt200.hex
ufodemo1.fth
ufodemo2.fth
fignition_progs.png

carl

unread,
Feb 7, 2014, 3:14:42 PM2/7/14
to fign...@googlegroups.com
here is the listing in full...

( ufo demo)
create udgs
0 c, 0 c, 0 c,
0 c, %% @ c, 65 c,
%% @ c, 0 c,
udgs vram $$ @ + 8 cmove  pokes the bytes into vram
( end of block)  save this block


: aud 64 191 42
>port> drop ; opens PD5 to sound
: beep 0 69 ic! 0 110 ic!
66 68 ic!
71 ic! 7 and 69 ic! ;
128 var %% byte value
608 var $$   vram location
: step
%% @ 2 / %% !   divide by two 
$$ @ 8 + $$ ! ; add 8 
: loadup
9 0 do i
20 load the location of your first block here
step
loop loads block 9 times
$4FB $5D i! ; this code stabilise the pointer ( todo) 
300 var && && is the vram location start
:  cycle
9 1 do 
i  vram && @ + ic!  display udg i ( 1 to 8 )
0 pause
loop drop
32 vram && @ + ic!  display a blank 
&& @ 1 + && ! ; move along
: go 
aud  audio on
300 && ! re state 300
24 0 do i cycle 
50 && @ 100 * beep 50 ( 1-9 * 100 ) beep  && location var is used
loop ;
: text 
7 10 at ." The UFO Demo"
0 14 at ." Space quits this nonsense" ;
: ufo cls text
begin go inkey 32 = until
0 0 beep ; turns sound off.


load the second block type  'loadup' then 'ufo'



Si Brindley

unread,
Feb 7, 2014, 6:59:00 PM2/7/14
to fign...@googlegroups.com
Hi Carl,

Works nicely - and congratulations: you just christened my FIGnition's sound output ;)

- Si

Si Brindley

unread,
Feb 7, 2014, 7:17:21 PM2/7/14
to fign...@googlegroups.com
Something else I learnt from this is that you can use "0 pause".  I am using "1 pause" in my little experimental animation.  Clearing the screen between frames without a pause was obviously too fast, but I thought "1 pause" was the shortest delay I could do.  Turns out processing "0 pause" is somewhere in between :)

Si Brindley

unread,
Feb 7, 2014, 7:20:06 PM2/7/14
to fign...@googlegroups.com
SpinnerAnim.m4v

carl

unread,
Feb 8, 2014, 3:51:44 AM2/8/14
to fign...@googlegroups.com
Hi Si, 
nice work,
do you have a listing for that?



On Saturday, 8 February 2014 00:20:06 UTC, Si Brindley wrote:

carl

unread,
Feb 8, 2014, 3:55:47 AM2/8/14
to fign...@googlegroups.com
It seems to me that looking at the pause command is enough of a delay, as you say without it it is too quick.
So whats quicker than 0? I guess altering the code to do less loops is the way to do it.

Julian Skidmore

unread,
Feb 8, 2014, 4:29:04 AM2/8/14
to FIGnition

Hi carl & Si,

Nothing is quicker than 0 ;-)

Actually, there are a couple of ways you can have even less pausing. But first some details about pause and why you might not want it to go faster.

Pause works by calculating a future clock value (which is clock i@+the pause value) and then it waits for clock i@ to exceed it. The wait loop is begin dup clock i@ - 0< until

That's why 0 pause will be faster because it will still wait until the clock has incremented. Of course, if your program has done quite a lot of work before you execute 0 pause then perhaps the clock will increment just as you go into the loop and it'll hardly additionally pause at all.

-1 pause won't be faster, because the built-in pause command treats -n pauses as "wait for n frames or until you press a key", so using it will generate erratic pauses. Note: the startup FIGnition logo uses -100 pause so you can cut it short by pressing a key.

One way to generate faster pauses is to use timer1. This runs at 2.5MHz so a pause of 1/100th of a second will be 25000 t1pause. The command to do this would be:

: t1pause tcnt1 i@ + begin dup tcnt1 i@ - 0< until drop ;

I can't remember the address of tcnt1 off-hand but I'll post that in my next message (it's in the atmega168 data sheet from atmel though).

However, will it help? FIGnition's display only updates at 50fps so even if you pause for <20ms you won't see the result properly, instead the user will just miss frame updates or see tearing on the screen if you start generating the second frame while the previous one is showing. Here, it's better to think about moving objects by more than 1 unit per frame and this should also reduce computation too.

Hope this helps.

-cheers julz

--
You received this message because you are subscribed to the Google Groups "FIGnition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fignition+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Si Brindley

unread,
Feb 8, 2014, 4:36:03 AM2/8/14
to fign...@googlegroups.com
FIGnition: graphics so powerful vsync is a consideration ;)

Carl, I don't have a listing although block 30 is just the published line drawing demo and 31 lists itself at the end so it's pretty much in the video.  It's also embarrassingly simplistic compared to your efforts :)

Julian Skidmore

unread,
Feb 8, 2014, 4:53:52 AM2/8/14
to fign...@googlegroups.com
Hi Si,

> FIGnition: graphics so powerful vsync is a consideration ;)

Yes - that's why it's a little more tricky to convert ZX81 games for
FIGnition, it's not naturally slow enough ;-)

Tcnt1's definition:

$84 const tcnt1

There is a use for <20ms pauses though; the logging program I wrote
for RS's inFUZE edition needs to log at >50Hz.

-cheers from Julz
>>>> <https://lh6.googleusercontent.com/-77CY8dTbMjA/UvV3iSZ7XoI/AAAAAAAAA6E/CA9rqYVJscA/s1600/SpinnerAnim.m4v>
>>>>
>>>>
>>>> On Friday, 7 February 2014 20:14:42 UTC, carl wrote:
>>>>>
>>>>> here is the listing in full...
>>>>>
>>>>> ( ufo demo)
>>>>> create udgs
>>>>> 0 c, 0 c, 0 c,
>>>>> 0 c, %% @ c, 65 c,
>>>>> %% @ c, 0 c,
>>>>> udgs vram $$ @ + 8 cmove *pokes the bytes into vram*
>>>>> ( end of block) *save this block*
>>>>>
>>>>>
>>>>> : aud 64 191 42
>>>>> >port> drop ;* opens PD5 to sound*
>>>>> : beep 0 69 ic! 0 110 ic!
>>>>> 66 68 ic!
>>>>> 71 ic! 7 and 69 ic! ;
>>>>> 128 var %% *byte value*
>>>>> 608 var $$ *vram location*
>>>>> : step
>>>>> %% @ 2 / %% ! *divide by two *
>>>>> $$ @ 8 + $$ ! ; *add 8 *
>>>>> : loadup
>>>>> 9 0 do i
>>>>> *20* load *the location of your first block here*
>>>>> step
>>>>> loop *loads block 9 times*
>>>>> $4FB $5D i! ; *this code stabilise the pointer ( todo) *
>>>>> 300 var && *&& is the vram location start*
>>>>> : cycle
>>>>> 9 1 do
>>>>> i vram && @ + ic! *display udg i ( 1 to 8 )*
>>>>> 0 pause
>>>>> loop drop
>>>>> 32 vram && @ + ic! *display a blank *
>>>>> && @ 1 + && ! ; *move along*
>>>>> : go
>>>>> aud * audio on*
>>>>> 300 && ! *re state 300*
>>>>> 24 0 do i cycle
>>>>> 50 && @ 100 * beep *50 ( 1-9 * 100 ) beep && location var is used*
>>>>> loop ;
>>>>> : text
>>>>> 7 10 at ." The UFO Demo"
>>>>> 0 14 at ." Space quits this nonsense" ;
>>>>> : ufo cls text
>>>>> begin go inkey 32 = until
>>>>> 0 0 beep ; *turns sound off.*
>>>>>
>>>>>
>>>>> *load the second block type 'loadup' then 'ufo'*
>>>>>
>>>>>
>>>>>
>>>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups
>>> "FIGnition" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an
>>> email to fignition+...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "FIGnition" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to fignition+...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> You received this message because you are subscribed to the Google Groups
> "FIGnition" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fignition+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>


--

The DIY 8-bit computer from nichemachines(tm)

carl

unread,
Feb 8, 2014, 5:33:10 AM2/8/14
to fign...@googlegroups.com
Si, 
I forgot to say thank you for trying the code out! 
:-)

if you mess about with the beep command, you get some interesting sounds, the format is normally nn nnn beep for sounds in our sound range, the && can give you some different output depending on what you do with the value. 
i.e * by 10, 25 or 100 
or 
use it the second value or the first or both.





Si Brindley

unread,
Feb 8, 2014, 6:24:25 AM2/8/14
to fign...@googlegroups.com
You're welcome. Here's a video capture of the output.
UFO.mov

carl

unread,
Feb 8, 2014, 7:42:33 AM2/8/14
to fign...@googlegroups.com
Haha nice one Si ;)


Reply all
Reply to author
Forward
0 new messages