Complexity
potatohead
Posts: 10,261
Well, I finally got some quality time with the latest build.
You know, I find myself familiar with the changes in a basic sense. When I see an error, or something won't assemble, I generally know what it is. But, there is a lot of reading through docs, and reading through old docs to see what I might have to unlearn too.
One thing stung me last night:
...used to be:
Was getting the fractal program I wrote moved over to the new build. Ended up doing a copy-paste from the current video sample driver code, into the program in order to see this one. Old habits die hard.
I'm still having trouble firing off another COG. The way the old code was written, the load address was compensated for with something like:
I seem to recall we've fixed this, or there is a directive to fix it, so that the label "fstart" could be used directly, but I can't seem to find where that discussion was.
Our current P2 doc is good. Most answers I needed are there. I think we could use a periodic table of instructions, and some clever reference card type things, but I found the doc useful.
Assembler changes aren't so well documented though.
Another one I ran into was the changes on waitvid. Now it can hold larger immediate values. This is good, because a simple, non parametric, video driver can be done thus:
...which is good! However, I ran into some trouble redoing it as cog variables so that it can be parameterized:
...only to get "register cannot exceed $1ff" at times I didn't yet understand why. I'm sure it has to do with the new addressing types, but we've only lightly discussed those. Older code could have constants with the same labels / names as COG locations could. I don't see that being true anymore, but it could be something else too. I've just started digging, and for now got a successful assembly, I think, by eliminating that redundancy.
Kind of random, but what is the current monitor entry code? Went looking for that too, didn't find it yet.
All in all, I got some things running, but for cog starting. I'm about to go through, and generate a listing so I can pick through it, sans the monitor and it's bug Chip is fixing right now.
Overall, we've moved farther away from that, "jump in and get it running" attribute we all value, and I'm not yet even touching all the task complexity or HUBEX..
There is quite a bit here to absorb now, and only some of that is related to unlearning. A new user is going to have to get to work! We might consider presenting a core subset of features and PASM to get people going, just to keep the number of things one has to know to a sane level at first so that success is likely.
Just some observations and questions, I'm hoping generate some quick answers while I'm looking for them myself.
You know, I find myself familiar with the changes in a basic sense. When I see an error, or something won't assemble, I generally know what it is. But, there is a lot of reading through docs, and reading through old docs to see what I might have to unlearn too.
One thing stung me last night:
vsynch waitvid #v_bs,#c_sh 'vertical sync high
waitvid #v_hs,#c_sl
waitvid #v_hr,#c_sh
djnz x,@vsynch
ret
...used to be:
vsynch waitvid v_bs,c_sh 'vertical sync high
waitvid v_hs,c_sl
waitvid v_hr,c_sh
djnz x,@vsynch
vsynch_ret ret
Was getting the fractal program I wrote moved over to the new build. Ended up doing a copy-paste from the current video sample driver code, into the program in order to see this one. Old habits die hard.
I'm still having trouble firing off another COG. The way the old code was written, the load address was compensated for with something like:
fstart_addr long @fstart+$e80
I seem to recall we've fixed this, or there is a directive to fix it, so that the label "fstart" could be used directly, but I can't seem to find where that discussion was.
Our current P2 doc is good. Most answers I needed are there. I think we could use a periodic table of instructions, and some clever reference card type things, but I found the doc useful.
Assembler changes aren't so well documented though.
Another one I ran into was the changes on waitvid. Now it can hold larger immediate values. This is good, because a simple, non parametric, video driver can be done thus:
CON
s = 43 'scales DAC output (s = 0..128)
r = s * 78 / 128 'adjusts for modulator expansion
lntsc = 3640 'NTSC colorburst cycles per line * 16
sntsc = 624 'NTSC colorburst cycles per sync * 16
v_bo = (lntsc-sntsc-256*9)/2 'left/right border
v_bs = 100 'before sync horizontal sync
v_sn = 269 'sync
v_bc = 50 'before colorburst
v_cb = 144 'colorburst
v_bv = sntsc-144-50-269-100 'before visible
--more stuff--
hsync waitvid #v_bs,#c_sh 'horizontal sync
waitvid #v_sn,#c_sl
retd
waitvid #v_bc,#c_sh
waitvid #v_cb,c_cb
waitvid #v_bv,#c_sh
...which is good! However, I ran into some trouble redoing it as cog variables so that it can be parameterized:
DAT org
---some stuff---
hsync waitvid v_bs,c_sh 'horizontal sync
waitvid v_sn,c_sl
hsync_ret retd 'Pipeline... get ready to return
waitvid v_bc,c_sh
waitvid v_cb,c_cb
waitvid v_bv,c_sh 'End of subroutine and actually return
DAT
v_bo long (lntsc-sntsc-256*9)/2 'left/right border
v_bs long 100 'before sync horizontal sync
v_sn long 269 'sync
v_bc long 50 'before colorburst
v_cb long 144 'colorburst
v_bv long sntsc-144-50-269-100 'before visible
v_hs long 135 'high sync high vertical sync
v_hr long lntsc/2-135-100 'high sync remainder
...only to get "register cannot exceed $1ff" at times I didn't yet understand why. I'm sure it has to do with the new addressing types, but we've only lightly discussed those. Older code could have constants with the same labels / names as COG locations could. I don't see that being true anymore, but it could be something else too. I've just started digging, and for now got a successful assembly, I think, by eliminating that redundancy.
Kind of random, but what is the current monitor entry code? Went looking for that too, didn't find it yet.
All in all, I got some things running, but for cog starting. I'm about to go through, and generate a listing so I can pick through it, sans the monitor and it's bug Chip is fixing right now.
Overall, we've moved farther away from that, "jump in and get it running" attribute we all value, and I'm not yet even touching all the task complexity or HUBEX..
There is quite a bit here to absorb now, and only some of that is related to unlearning. A new user is going to have to get to work! We might consider presenting a core subset of features and PASM to get people going, just to keep the number of things one has to know to a sane level at first so that success is likely.
Just some observations and questions, I'm hoping generate some quick answers while I'm looking for them myself.
Comments
It's @start_address+$e00, not $e80. I went back a few pnut.exe versions and still got "register exceeds $1ff" when mixing constants and cog labels. Not sure what happened on that one, and it's a lot of work to go back through the forum posts to see what build that code actually ran on.
Which leaves the monitor entry, which is:
' Run monitor
'
monitor coginit monitor_ptr,monitor_par
monitor_ptr long $70C 'monitor address
monitor_par long 90 << 9 + 91 'monitor parameter (tx_pin=90, rx_pin=91)
'
I've not been able to make this work on a second Prop Plug. Is this correct? Monitor comes up normally on P2 start, but does not respond when called.
A couple of quick observations
On "register cannot exceed $1ff"
Try inserting a ORGH directive before your variables in HUB.
Cheers
Brian
Well, maybe. It won't answer on either the default pins, or pins 3 & 5, where I will normally insert a second Prop Plug.
Not done with this yet, but here is the fractal ported to this FPGA build. It needs some basic navigation to examine the set more interactively...
Yes, it's TV. I may change that. Or you can! Post if you do please. That's the display I have setup on my laptop, via capture card... For what it's worth, the new video signal quality is in a whole other league compared to P1. Besides, I like TV.
@ozpropdev, Brian --> Thanks for your postings! I've learned a lot.