IRC log started Sat Nov 20 14:07
> OK.
> Now Rick, I must warn you that there is a strict Wildstar policy in effect here, so if things get out of hand I may have to banish you.
> As to betas, nope, no new beta -- 1.6 is it.
> As to hockey, what can I say?  Robin Harbron Rules!
*** Topic for #slang: SuperCPU required!
*** #slang MagerValp!cl3polof@panini.cling.gu.se 1100975535
Pub: #slang     Wildstar @Wyndex @RobinH @MagerValp
<MagerValp> ah
*Wildstar* Can you tell me what the policy is
<MagerValp> keyboard works much better when plugged in
*Wildstar* I am primarily keeping quiet.
> I've noticed that...
<MagerValp> gotta find a fresh 3.5" disk for this...
> Rick: Yup, just behave yourself and all will be well :)
<MagerValp> hrm
<MagerValp> 25, write error,01,00
<MagerValp> bummer
<MagerValp> trying another disk...
> No rush.
<MagerValp> there we go
<MagerValp> copying files
<MagerValp> serslave has many faults, but it sure is fast
<MagerValp> copy done
<MagerValp> heh
<MagerValp> ah fudge
<MagerValp> still have the bug where it doesn't copy files with spaces in the name
> I have to delete files to make everything fit on a .d81 now.  The source is, like, big.
> Ah, sorry about that.
<MagerValp> oookay
<MagerValp> all fixed
<MagerValp> loadingz0r slangz0r
> Now, do we have any sort of agenda here, or is it just free-form?
<MagerValp> (scan
<MagerValp> erp
<MagerValp> well... groepaz was also interested
> Like, do you want to talk about specific things, or code and ask questions as we go, or ...?
<MagerValp> but he timed out a while ago
<MagerValp> basically, i have a free evening, and a fresh copy of slang :)
> OK :)
> If things slow down I will start going back and forth between here and my floor, but I have the afternoon.
> (Um, that would be the floor I am putting in.)
<MagerValp> a-ha
<MagerValp> so
<MagerValp> libraries
<MagerValp> we have them noe?
<MagerValp> now
> Yes!
> (Sorry, got one more thing to do... brb...)
> OK, we've actually always had libraries, it's just that nowthe system is much more useful/practical.
> All a library is is a set of (sub)routines.
<MagerValp> alright
> They might be fixed in memory somewhere (an external asm library, say Mr. Mouse or Blarg or lib3d)
<MagerValp> and local variables?
> They might be a relocatable file (REL).
<MagerValp> cool
> And they might be a PUT file to be compiled.
> Also, they might be Slang code, or asm code.
> But the point is that it's just a set of routines.
> The idea here is to interface to those routines in a simple/useful way.
<MagerValp> right
> So, take the core library.
> I put two versions in the .zip -- "core.c.s" and "core.l".  Core.l is a REL file for use by the linker.
> core.c.s is a file you can just load in to the editor.
> What I did is take one of my standard libraries (diskio, in this case) that I use all the time in asm, and extract a few routines.
<MagerValp> no core.c.s in slangb16.zip
<MagerValp> got the ext file and the l file
> Ah, putcore.c.s
> I renamed it to keep confusion down.
> Actually, let me back up a second.
> Let's take the case of an external, pre-compiled library, say Blarg.
> Blarg has a little jump table to call routines for setting up bitmap mode, drawing lines, and so forth.
<MagerValp> right
> (I'm just going to take each of the three different library types in turn.)
> So let's say the call to the line routine is at $C006.
> And the line routine wants four variables set up: x1,y1,x2,y2 all 16-bit signed.
> What you can do is write a line of code like:
> (Oh, and let's say those variables are in zero page, at $69-70)
> So you can write a line of code like:
> sub asm line(int x1@$69, int y1@$6b, int x2@$6d, int y2@$6f)
> Oops:
> sub asm line@$c006(int x1@$69, int y1@$6b, int x2@$6d, int y2@$6f)
> And now you can make calls like
> line(10,10,300,190)
> from a program.
<MagerValp> excellent
> So let me go through that line of code quickly.
<MagerValp> yeah, being able to specify exactly how args are passed makes it easy to interface existing code
> "sub" of course means "define a subroutine", but the "asm" modified says to just set up the variables, and not start a new scope or whatever.
> i.e. sub asm is for calling routines that exist elsewhere in some other form.
<MagerValp> ahh
> The rest is self-explanatory, I think.
<MagerValp> what's the difference between sub asm and sub ext then?
> "sum asm" is like "pretend there's the following subroutine"
> "ext" is a linker command.
<MagerValp> oh
> With sub asm, you'll always use an @-var for the subroutine.
> And all of the variables, too.  Nothing is allocated, just the names are set up.
> With ext, the subroutine and all of the variable addresses will be resolved at link time.
> Here are some forbidden things:
*** Greg_-_ (~ajirc@mki3-pl-ri46.kos.net) has joined channel #slang
<MagerValp> oh hey greg
> sub asm ext
> Hola Greg
> sub ext blah@... -- no ext @-vars.
<MagerValp> k, making sense
> Let me stay focused on the original thing, though, and explain all that in a few minutes.
*** Greg_2 (~ajirc@mki7-pl-ri8.kos.net) has joined channel #slang
<Greg_2> ah. hi. 
<MagerValp> :)
> The bottom line is that for a fixed library -- something you load separately -- you can set up a list of sub asm stubs to interface the code in a natural way.
> Hola Greg :)
<Greg_2> :)
> The really important thing in 1.6 is the addition of @a @ax etc. as "variables".
> Since lots of asm routines pass variables in the registers.
<MagerValp> yeah
<RobinH> man, lost 9-8 in the semi-final... not even making it to the final this year
*** Signoff: Greg_-_ (Ping timeout: 182 seconds)
> You mean... Robin Harbron doesn't rule?
> I'm crushed.
<RobinH> Apparently not :/  Oh well, about time this guy who beat me made it to the final... :)
> Greg: Want me to repeat anything?  Like, so you know what we're talking about? :)
<RobinH> Slang might good for writing Wings appz
<MagerValp> i dunno
<RobinH> hmmm, but I guess the code/test cycle would be a real hassle
<Greg_2> ah,I just dropped in cuz I'm having a hard time concentrating on anything else atm. 
<MagerValp> wings is written in and around C
<MagerValp> g :)
> works for me!
<Greg_2> It's written in 65816 assembly.
<MagerValp> well, right, yeah
<MagerValp> and C
<MagerValp> :)
<Greg_2> yeah.
<Greg_2> we'd need a slang compiler that runs in WiNGs for it to be really useful.
> OK then, the next type of library would be a PUT-library -- a library of routines that you can include in your own programs.
> I mean, a library of _source code_ routines to include in a program.
<MagerValp> basically #include?
> Sort-of, but not really, since you have #include header files for all sorts of precompiled libs.
<MagerValp> sure, but all #include does is insert the ascii source from another file at that point
> Yeah.
<MagerValp> but
<MagerValp> like .include or whatever the assembler directive is :)
<MagerValp> hactually
> But I don't want to confuse this with C libraries.
<MagerValp> consider calling it "include" :)
> Well, one reason I've been avoiding that is that I don't want people putting "includes" all at the top of the program and then wondering why things don't work.
> The Sirius command is "PUT".
> So, have a look at printdemo.s
> You'll notice the last line of the code is something like  PUT "putcore.c.s"
<MagerValp> printtest.g.s :)
> Which is like appending the file putcore.c.s to the code.
> Heh :)
<MagerValp> erm
<MagerValp> single quotes?
> Doesn't matter.
> At least, I think it doesn't matter...
<MagerValp> k
> Go ahead and compile it.
> (and run it, for that matter)
<MagerValp> btw, after assemble it'd be good if you could start the code with S or something
> As opposed to exiting to the monitor?
<MagerValp> right
<MagerValp> just a shortcut
> OK, I'll give it some thought.
<MagerValp> saves typing "g 1000" a lot :)
> (Problem #1 arises if you're compiling, say, a program with a BASIC header)
<MagerValp> right
> Anyways, I'll give it some thought.
> Assuming it runs, go ahead and load in the file "putcore.c.s"
> Putcore is just a subset of my "diskio" library that I use in pretty much all my programs.
<MagerValp> gah... my fingers insist on typing out the .s
<MagerValp> stupid fingers
> It has a mult/div routine, a printnum routine, a strout routine, etc.
> Heh.
> I did two things to the code.
> First, I renamed all the variables to have a ] in front of them.
<MagerValp> which makes it look kinda weird imho... heh
> A variable like "]loop" is actually valid in Sirius, but nobody uses them, so I've sorta mentally reserved them for compiler use.
<MagerValp> k
> Yup, but the reason I did that is so that it won't conflict with any vars in a slang program.
> This is not a great way to do a library, btw.  But this is a special case.
> That is, unless you start creating vars like ]mult16 there will be no conflicts -.
> The second thing that I added was a set of sub asm statements down at the end of the code.
<MagerValp> right...
> So all that code does is create a couple of Slang subroutine interfaces.  That's it.
> I could have created slang subroutines, with the assembly code as the subroutine, instead of using sub asm, but I was testing things.
> Now, check this out:
<MagerValp> just a quickie
> In the printtest code, comment out the PUT line (put a * or a ; in the first column)
<MagerValp> are () optional for subroutines with no args?
> No -- required.
<MagerValp> k
> I could make it optional, but decided not to.
<MagerValp> yeah
> So anyways, comment out that line and compile the program -- you should get an error.
<MagerValp> ahhh, DisableTimerAIRQ isn't a subroutine, gotcha
<MagerValp> yup, got error
<MagerValp> informing me of my lameness
<MagerValp> brb, getting a drink
> The trick here is that the "print" command actually calls that subroutine.
> Like, the compiler is looking in the source code for a routine called "]strout" or whatever it is.
> Not outside of the source code -- actually as part of the source code.
> So that PUT file just adds the subroutines that print is looking for.
> You could totally fake PRINT out by creating a different routine.
> subroutine
> with the same name.
> But that's why ] is reserved :).
> Similarly, multiplication and division call the ]mult16 and ]div16 routines in the core library.
> The third type of library -- using the linker -- works the same way, but now the routines are resolved at link time.
> I'll explain that in a bit...
<MagerValp> hmmkay
<MagerValp> so if we want to use print, we have to "put 'putcore.c.s'" at the end?
> Yup.
> Technically you could append it, but that's a Bad Idea.
<MagerValp> k
> For reasons of new library revisions, etc.
> Anyways, does that make sense?
<MagerValp> sure
> It's really simple, but maybe I've made it more complicated.
> The bottom line is just what you said: to use print _or_ to use multiplication/division you need to have the core library.
> And if you're not using the linker, you need to PUT it.
<MagerValp> k
<MagerValp> is there a GetKey command?
> There's actually a sort-of exception: I've added the command "sprint" which doesn't require the library, but only prints strings.
> Not yet.
<MagerValp> k
> Very easy to add, however.
> I think the syntax will be getkey(a)
> Also, inupt(a)
> 1st question though: do you expect getkey to wait for a keypress or not?
> Like, there'll be one command that waits and another that doesn't, I just have to decide on a naming convention.
<MagerValp> both :P
<MagerValp> well, getkey and waitkey
> Yeah, something like that.  Anyways, that's just a matter of updating the slangdef file.
> Very easy.
> Ready for the third kind of library, a linker library?
<MagerValp> actually, i started coding a tetris here... :)
<MagerValp> and i'm not sure how i define a subroutine that returns a variable
<MagerValp> and would sub asm getkey@$ffe4()<-k@A be correct?
> unfortunately no.
> @A doesn't currently work for return variables.  Bummer.
<MagerValp> ah...
<MagerValp> hrm
> A really simple thing you can do, though, is:
> sub getkey<-byte key
>   jsr $ffe4
>   sta key
>   rts
> Kinda retarded, but...
<MagerValp> s/retarded/straightforward/
<MagerValp> not sub getkey()<-byte key?
> There's another thing which I haven't implemented yet which is coming next time.
> Yeah, getkey()<-...
<MagerValp> k
<MagerValp> oh, and could i get "endsub" as an alias for rts?
<MagerValp> :)
> Yeah, it's in there.
> endsub
<MagerValp> oh, ah, ok
> I don't remember if I've put string comparisons in yet or not.
> Like, no if a$ = 'a'
<MagerValp> k
<MagerValp> and then key=getkey()<-key?
> Instead you'll have to if a=65 kind of crap.
> Yup!
<MagerValp> cool
> Well, not really -- getkey(key) would be cool.
<MagerValp> maybe you should have 'x' be chars, and "x" be strings?
> The nice thing about having ' and " valid is that you can use one when you need the other quote in the string.
<MagerValp> true
> Anyways, I think I've got it all worked out how to do it, I just need to implement it :)
> What the delineation is is whether it's a single character.
<MagerValp> hrm
<MagerValp> program crashed :P
<MagerValp> how do i get back to slang?
> sys 54016
> Always be sure to end your program with a brk.  Yeah, kind-of obnoxious.
> I will be adding an "endbrk" and "endrts" command or some such.
> 54016 is $d300, btw.
*** Signoff: Greg_2 (Ping timeout: 182 seconds)
<MagerValp> back
<MagerValp> k, that did the trick
> The brk?
<MagerValp> sys54016
> Ah :)
<MagerValp> code never reached my brk :)
<MagerValp> guess this'd be a good time to show me the debugger...
<MagerValp> heh
> Robin usually puts a line in that maps NMI to 54016
<MagerValp> ah
> So you can hit restore to go right back to the editor.
> Alrighty then, debugger.
> Unless it's easier to just use print statements or whatever.
<MagerValp> return@$0318, return=$d300?
> yeah, int nmi@$0318 or whatever
<MagerValp> k
> Do you have 16M?
<MagerValp> sure do
> Lemme show you something really quick.
> Exit to the monitor.
> Then type "i 080000"
> That's where your program text is stored while the editor is working on it.
> Now type "i f4fa00" or so.
> You should again see your program text around there somewhere.
<MagerValp> yeah
> When you exit to the monitor or to basic, the source code is copied as high as it will go.
> This frees up lower areas of SuperRAM for program use.
> But the reason I mention this is that if you ever have a really bad crash, that for some reason hoses the 54016 restart, you can manually save the text from jammon.
> In Case Of Emergency
> Just so you know!
<MagerValp> good to know
<MagerValp> so... debug?
> Ah.
> Sorry, was afk.
> Stick a brk at some point before the bug.  Or we can start from $1000.
<MagerValp> yeah, it b0rks in the first loop, $1000 is ok
> OK, once the brk is in there, start the program from the monitor and it will immediately pop you out at the brk.
> What is the loop code, btw?
> Or, what does the loop do?
<MagerValp> repeat
> (Well, what's the loop _supposed_ to do :)
<MagerValp>   k=waitkey()<-k
<MagerValp>   if k=32
<MagerValp>     Game()
<MagerValp>   endif
<MagerValp> until k=51
> And what does Game() do?
<MagerValp> start with space, quit with q
<MagerValp> nuthin
<MagerValp> :)
> But it has an endsub?
<MagerValp> yup
> OK
> This should be easy from the debugger.
> Go ahead and add the brk, and g 1000
<MagerValp> k
> Now type !d
> ! toggles stuff' !d toggles "debugging mode", which is mostly a display mode.
> Then type "d" to disassemble starting from the current point.
> You should see the code on the right, with the "brk" instruction highlighted.
<MagerValp> yep
> Now you can use "z" to single step through the code.  z has the same syntax as d.  Type "z <addr>", where <addr> is the brk address+1.
> Now you can just type "z" to execute the highlighted instruction.
<MagerValp> hmm
<MagerValp> that skipped two steps
<MagerValp> weird
<MagerValp> lemme restart
> The first one?
> What z does is execute the instruction, then stop at the next instruction.
<MagerValp> just atpyo
<MagerValp> ahem
> OK :)
<MagerValp> though
<MagerValp> the first command is sprint
<MagerValp> and it printed the string
<MagerValp> then froze
<MagerValp> yep
<MagerValp> tried again
> OK, here's something to be aware of.
> In the assembler, "do 0" will disable assembly, and "fin" will finish the do conditional.
> So this is a really handy way to comment out huge sections of code.
<MagerValp> k
<MagerValp> still
<MagerValp> shouldn't i be zingle ztepping the print routine?
> Just bracket it with a "do 0/fin" -- this allows you to zero in on code that might be causing problems.
> Does the brk occur before the sprint?
<MagerValp> yup
> Then yeah, you should see the sprint.
<MagerValp> weird
<MagerValp> removed the sprint
<MagerValp> z 100b
<MagerValp> same thing
<MagerValp> (just no message)
<MagerValp> runs full tilt
<MagerValp> does it enter jsr's?
> So the sprint is causing the problem?
<MagerValp> not anymore, i commented it out
> You can toggle whether it follows jsr's.
<MagerValp> it goes into my repeat/while
<MagerValp> and loops forever
<MagerValp> no cursor back
> ?
<MagerValp> indeed
> Well, just start from z 1000
> If it's only at 100b :)
> What is the sprint line, btw?
> sprint "press a key" or something?
<MagerValp> yeah
> What's the exact line?
<MagerValp> ok, jsr $100e :P
<MagerValp> er
<MagerValp> -ok
<MagerValp> when it hits a jsr, it goes into full speed
> Meaning it no longer single steps?
> Is the loop inside the jsr?
> Rather, what's at the jsr?
<MagerValp> yes
> OK.
<MagerValp> the repeat loop
> By default, single-stepping does not follow subroutines.
> To toggle this, type !j
<MagerValp> ah
> Then it will go into the subroutines.
<MagerValp> there we go :)
> Sorry! :)
<MagerValp> hrm
> But you'll want to turn this off for, say, jsr $ffd2
<MagerValp> now if i could also see my source at the same time...
<MagerValp> right
<MagerValp> m 080000?
> Yeah, I've thought about that.  Basically it's a good memory excercise.
> You can do that, but do it from the non-debugging mode.
> Type !d
> Then i 080000
<MagerValp> ah
<MagerValp> ugh, disassembly doesn't follow the z display
<MagerValp> z cursor
> ?
<MagerValp> like a jsr off the current display
> Oh, hit d again.
<MagerValp> well yeah
<MagerValp> might want to make that automagic though :)
> I'll think about it.
> The thing is, sometimes you're in a loop that's slightly bigger than the screen, say.
<MagerValp> also, making return on an empty line repeat the last command would be nice
> For what sort of situation?
<MagerValp> z
<MagerValp> z
<MagerValp> z
<MagerValp> z
<MagerValp>  :)
> Well...... we'll see :)
<MagerValp> hrm, now it's waiting for $c6
<MagerValp> how do i write 1 to $c6?
> Use m
> Then cursor over the line.
<MagerValp> exit !d mode?
> m 00c6 probably
> Either way.
<MagerValp> didn't like it in !d mode
> The kernal is going to not like it though.
<MagerValp> didn't like it in normal mode either
> Like, Jammon uses the kernal, so it'll take effect immediately.
<MagerValp> ohhh
<MagerValp> hah
<MagerValp> d'oh
> :)
> One thing you can do is fudge it.
> This is just your getkey routine, right?
> Code should look like
> jsr wherever
<MagerValp> ýeah
> lda xxxx
> sta yyyy
<MagerValp> have'em return 51?
> just load .A with 51 (using the cursor) then z from that sta yyyy instruction.
> Oooh, let me show you another cool command.
> Exit debugging mode, and type "n 'q'"
> n is "number"; you could also do "n 51"
<MagerValp> changed lda $c6 to lda #$01
> Ah.
<MagerValp> ahh
> And it will print the number in base 10, 16, and the ascii char.  Really useful :)
> Argument can be in decimal, hex, binary, or ascii, I think.
<MagerValp> bug found
> Yes?
<MagerValp> k=$51, not k=51
<MagerValp> :P
> Ah, bummer.
<MagerValp> stoopid
<MagerValp> but hey, now i know how the debugger works
> Why did that make it crash, though?  It was just in the busy loop?
> Yeah!
<MagerValp> just a busy loop
<MagerValp> ok
<MagerValp> program quits on q, and prints "GAME'D" on space
> I think that the debugger is probably less-useful for slang programs; like, a simple print statement would have found that one fast.
<MagerValp> that's like 23-27% of Tetris
> Heh :)
<MagerValp> heh, everyone's using 23-27% nowadays...
<MagerValp> yeah, hard to follow slang code
<MagerValp> compiler output isn't quite what it could be i guess...
> The next core release will include a block move command -- useful for, say, copying down the default charset to modify it.
> Well, it's actually pretty good.
> The compiler output, that is.
<MagerValp> certainly does the job
> Some thing you see that are goofy-looking are there on purpose.
> Because the compiler can't look ahead, only behind.
<MagerValp> ah
> Or because it has to preserve a register, or whatever.
> Sometimes it's signed/unsigned stuff, too -- like, using a uint instead of an int will make things much simpler.
<MagerValp> doesn't seem to reuse regs though
<MagerValp> like
<MagerValp> lda foo
<MagerValp> sta bar
<MagerValp> lda foo
<MagerValp> sta baz
<MagerValp> instead of
<MagerValp> lda foo
<MagerValp> sta bar
<MagerValp> sta baz
*** Signoff: RobinH (Read error: Connection reset by peer)
> The problem is that no longer works for ints, say.
> It _does_ keep track of X and Y stuff, though.
<MagerValp> k
<MagerValp> really minor issue though
> But if you find cases where that can be fixed, I'll implement it.
<MagerValp> ok, so to see how the linker works...
> I've tried to keep that kind of stuff to  a minimum -- really breaks my heart seeing the compiler output some things.
<MagerValp> let's put the display code in a different buffer
> Ah, simple linker thing.
<MagerValp> i now have a main(), a DisplayTitle(), and a Game()
> In different buffers?
<MagerValp> no, one buffer still
> What do you want to link? :)
<MagerValp> in the next one i'll do ClearScreen(), DrawBoard(), and DrawPiece()
> Ah, I see.
<MagerValp> then link the two
> As long as we're clear that the linker is somehwat more obnoxious for smaller programs.
<MagerValp> sure
> i.e. that this is just for practice :)
<MagerValp> right-o
<MagerValp> used to linkers now, use it with cc65 all the time
> k
> And are you using putcore?
<MagerValp> no
> OK.
> Because I'll also show you how to link the core library in.
<MagerValp> well, won't do any harm will it
> There's two steps if using the core library with the linker.
> Want to do a quick test?
<MagerValp> sure
> OK.
> Try typing a program like the following:
>   rel
>   put 'core.ext.s'
>   byte b
>   b = -3*2
>   print "b=" b    <- note could also have done print "b=",b
>   brk
> Then compile.
> That PUT at the top contains lines like "sub ext ]mult16(...)" -- you can look at it in the editor.
> But that first PUT is what's critical here.
> Then save the output code to some file, like "ptest".
<MagerValp> SAVE'D
> Then, in a different buffer, do something like
>   link $c000
>   ptest.l
>   core.l
> and compile.
<MagerValp> yep, worked just dandy
<MagerValp> ...what's wdm $42 though?
<MagerValp> er
<MagerValp> wdm $3d
<MagerValp> before the brk
> "b=" :)
> In assembly, that's like
>   jsr STROUT
<MagerValp> oooh
<MagerValp> ah
<MagerValp> hehe
>   txt 'b='
>   dfb 00
<MagerValp> gotcha
> And THAT is a big pain when single-stepping, btw.
> What you have to do is put a BRK after the 00 -- where STROUT returns to.
> Using something like "b c01e" or whatever to set the breakpoint.
> z will just put a brk right after the JSR STROUT, call STROUT, and get all confused.
<MagerValp> yeah
> Anyways, the thing I wanted to point out is that the core interface is contained in core.ext.s, and the actual routines aren't present until link time.
<MagerValp> don't think any debuggers i know of that handles that gracefully
> Without that put "core.ext.s" line it won't work.
<MagerValp> k
<MagerValp> so
<MagerValp> how do i make my own?
> Right.
<MagerValp> should all my files start with rel, or just all but the "main" one?
> Three commands: REL, EXT, and ENT
> Any relocatable file starts with REL.
> i.e. any file to be used with the linker.
> So, all files start with REL :)
> (Except the one containing the link command)
<MagerValp> k
> If a routine somewhere wants to access a subroutine (or a variable!) in a different module, you have to do two things.
> Actually, first load in the file "slang.ext"
> To see the syntax of a sub ext.
<MagerValp> no such file in my zip
> Well, slang.ext.s
<MagerValp> nope
> There has to be -- we used it in the PUT above :)
<MagerValp> you mean core.ext.s?
> Ah, sorry, core.ext.s 
> bleah
<MagerValp> hokay
> You'll notice that instead of "sub asm" it contains a bunch of sub ext.
<MagerValp> yup
> So all it's doing is setting up some EXTernal interfaces to be resolved at link time.
> The actual subroutines are contained in the "core.l" file.
> And the interfaces tell the REL module how to call them.
<MagerValp> so...
> So let's say you have PROG1 and PROG2
<MagerValp> i need an extra file with sub ext, that i PUT into the main file?
> And PROG1 wants to call a subroutine in PROG2.
> Nah, just type the "sub ext" line directly into the file.
<MagerValp> k
> PROG1 needs to have a line like "sub ext ...."
> And PROG2 needs to have the sub be a "sub ent ..."
> So you can just cut and paste, really.
<MagerValp> hmm
<MagerValp> and sub ext needs the full prototype with args and all?
> Yeah -- because it needs to know how to pass the args (size, signed, place, etc.)
<MagerValp> damn, wish i had tv-in on my PC, i could give you a direct feed of my monitor...
<MagerValp> k
> Maybe it helps to think of it as a "ghost" subroutine.
<MagerValp> and for variables?
<MagerValp> just a plain C prototype :)
> Same thing.  "int ext blah"
> That says, "create a variable called "blah", and treat it like an int, but it's outside of the program somewhere"
<MagerValp> what was the "for" syntax again?
> for i=1:n step blah
> (I think :)
<MagerValp> endfor?
> yeah.
> Or next.
> I should have posted a slang example using the linker on the BBS.
<MagerValp> well
<MagerValp> i'll post my tetris code
<MagerValp> working or not :)
<MagerValp> should be a good example
<MagerValp> hmm
<MagerValp> possible editor display bug
<MagerValp> when lines are > 40 chars
<MagerValp> it prints /
<MagerValp> in column 40
<MagerValp> and on the next screen it starts with char 41
> Yeah, that's intentional.
<MagerValp> so you can see char 39 and 41, but 40 is hidden under /
> Right.
<MagerValp> ?
<MagerValp> but then you can't see what's written there
> Well, on the occasions where you really need to see it you can use ins/del
<MagerValp> :P
> Basically any method is obnoxious.
> I could use half-screens, etc. etc.
> Like, ctrl-k could move over a half-screen, or whatever.
> But they're all irritating in one way or another.
<MagerValp> make it move 39 chars to the right
<MagerValp> abc/def
> Yup, that's an option too.
<MagerValp> instead of abc/ef
> I'll think about it :)
<MagerValp> :)
> (I mean, really, I will! :)
<MagerValp> hmm, i have to compile and save object file to disk before linking?
> Unfortunately, yes.
> With big files -- big codes -- this isn't as big of a deal.
> But I will make it so that you can compile directly to disk.
<MagerValp> some kind of makefile-ish buffer would be cool
<MagerValp> link $1000
<MagerValp> assemble tetris.s to tetris.l
<MagerValp> :)
> Good heavens, no.
<MagerValp> hehe
> The whole idea is to not have to recompile.
<MagerValp> true
> I will post my Slang example sometime.
> Linking takes 14 seconds.
> If I had to compile it all, each time?  Ouch.  Minutes.
> I hate to even think about it!
<MagerValp> hehe
<MagerValp> that
<MagerValp> erp
<MagerValp> that's the thing with make though, it only recompiles if the source has changed
<MagerValp> if not, it grabs the old binary
> Right -- but for that you need a datestamp or something.
> But there's no reason for that here.
<MagerValp> well, if the buffer is in ram, check if it's modified
<MagerValp> nah
> Like, you compile it when you compile it, then you're done.
<MagerValp> would've just saved me all of like three keystrokes right now :P
> And keep the link file in a buffer.
<MagerValp> and since i'm learning, i'm jumping around a lot
<MagerValp> when you're actually working on something, it's smoother
<MagerValp> aaanyway
<MagerValp> unresolved external
<MagerValp> hmm
> Did you declare it as an ENT?
> In the code where it actually resides?
<MagerValp> sure did
<MagerValp> sub ent ClearScreen()
<MagerValp> *code*
<MagerValp> endsub
<MagerValp> sub ent DrawBoard()
<MagerValp> *code*
<MagerValp> endsub
<MagerValp> then
> OK
<MagerValp> in tetris.s
<MagerValp> i have two sub ext foo()
> sub ext ClearScreen() ?
<MagerValp> yepo
> OK, what's the linkfile look like?
<MagerValp> and DrawBoard
<MagerValp> link $1000
<MagerValp> tetris.l
<MagerValp> screen.l
> And you're sure that the .l files are correct?  (Like, didn't accidentally save both as tetris.l?"
<MagerValp> right you are
<MagerValp> tet.l
<MagerValp> hmm
<MagerValp> no wait
<MagerValp> i *have* tet.l in the link file
> I am trying it... just a sec...
<MagerValp> hrm
<MagerValp> actually
<MagerValp> uresolved EXT: clearscreen
<MagerValp> lower case
<MagerValp> is it case sensitive?
> Yeah, that's fine.
> No.
> OK, my little program worked.
> Two sub ents, two sub exts
<MagerValp> yeah...
<MagerValp> hmm
> I even used ClearScreen and DrawBoard :)
<MagerValp> dunno what i'm doing wrong, but it's probably something stupid
> Basically I am just relieved that it works.
> That there's not some horrible bug I've overlooked.
> Try compiling and saving them again?
<MagerValp> sub ext ClearScreen() at the top of tetris.s, just after rel
> ok
<MagerValp> yeah, trying again
> What I did was create two files.  First one is
>   rel
>   sub ext ClearScreen()
>   sub ext DrawBoard()
> byte b
> b=1
> ClearScreen()
> DrawBoard()
>   inc $d020
>   brk
> The second program is
>   rel
> sub ent ClearScreen()
>   lda #00
>   sta $d020
> endsub
> sub ent DrawBoard()
>   lda #00
>   sta $d021
> endsub
<MagerValp> yep
<MagerValp> worked this time
<MagerValp> must've been something silly
> Great! :)
> "OK it worked" is like music to my ears.
<MagerValp> didn't print the text though
<MagerValp> and it didn't draw the board...
<MagerValp> hmm
> heh
> BTW, have you checked out spritedemo.s?
<MagerValp> yeah
> ok
<MagerValp> gnnf
<MagerValp> brain is slowing down here
<MagerValp> maybe we should call it a night
<MagerValp> i should have enough to keep me going for a while
> Sounds good.
> Talk to you in a few days.
<MagerValp> :)
*** MagerValp has left channel #slang
*** Signoff: Wildstar (Quit: Leaving)
*** Window LOG is OFF
IRC log ended Sat Nov 20 23:16