Yeah questions for the learning geek wahoo first one.
Asm in 28 days Day 14 wrote:

Via the Code Stream
Immediately after the CALL to the procedure, place the parameters inline with one or several .DB or .DW statements. Okay, this looks real cool, but the way to access these parameters may elude you until you realize that the return address, the top stack value, is the address of the first parameter. So you pop HL, and if off to the races (this is one of those rare exceptions to the rule of not popping without pushing something first).
Now one problem, if you put back the return address, you will return right after the CALL and the data block will be executed as code. This is solved by modifying the return address so that it points to just after the parameters. Not too difficult to do that because you will usually be at the end of the parameter list when you want to return anyway.

Program 14-4
LD HL, 0
LD (CurRow), HL
CALL Print_Out
.DB "I ain't not a dorkus", 0
RET

Print_Out:
; Get the return address/address of parameter
POP HL
_Loop:
LD A, (HL)
INC HL
OR A
JR Z, _Done
b_call(_PutC)
JR _Loop
_Done:
; Much better than POP HL \ RET
JP (HL)
You have no excuse for not understanding the code stream mechanism — you've been using it all this time! b_call(xxxx) is macro (you should know at least that much by now) that expands to

RST 28h
.DW xxxx
RST is the same as CALL, but you can clearly see that the code stream is in use here.
The code stream really is one of the more convenient ways to pass input, and code-stream parameters implement variable-length parameters quite effectively. The string parameter to Print_Out can be any length and the routine will always come off without a hitch.

For all its convenience, the code stream mechanism is not without its disadvantages. First, if you fail to pass exactly the right number of parameters in exactly the right format, the code stream becomes the crash stream. Try leaving off the zero byte, Print_Out prints garbage and returns to god-knows-where. Or you might accidently add in a second zero. Then Print_Out returns in the midst of the string and tries to execute ASCII codes as instruction opcodes. Again, this usually results in a crash (actually most characters will be 8-bit loads that may or may not be harmless).


Can any one explain this better? :/
What it's doing is that it's looking at the bytes after the CALL statement. When the processor executes a CALL statement, PC is pushed onto the stack and it jumps to the location after the CALL statement, which is in little-endian. When the processor executes RET, the value at the top of the stack is popped off into PC. That code is exploiting that by popping PC off the stack into HL, and it's reading the bytes located at (HL) and (HL+1). After it does that, it returns with JP (HL), since the value of PC was popped off the stack.
rst and call will push the address of the the next instruction to the stack, like
Code:
call #_0x4008
dec bc  // <--- Stack contains address for this
pop af


and a ret simply does something similar to

Code:
pop iy
jp (iy)
Without using iy, of course. This topic is about passing static parameters to a function by leaving the data after the call
Code:
call DoSomething
.db 1
.db 2


This is opposed to dynamic paramter passing like

Code:
ld b,1
ld c,1
push bc
call DoSomething


To read the "code stream" to get your statically passed parameters (with .db/.dw after the function), you can do something like this

Code:
DoSomething:
  pop ix // This is the return address, and points to the first .db
  ld a,(ix+0) // load first .db
  ld c,(ix+1) // loads second .db
  // bad way of doing it, but
  inc iy
  inc iy // placing the return address down 2 bytes _past_ the data
  push iy // Get back there
  add a,c
  ret


For a BCALL, it looks like

Code:
rst ____ // whatever
.dw DispHL


The OS will do the same thing as above to get that parameter. if you don't chance the return address, then you could end up calling a random OP, while changing it will let the program flow and be uneffected by the data

I think that this was written badly, but just ask if you gte confused
That made so much more sense than asm in 28 days thank you ^_^

Next one can some one explain SMC better than 28 days? that was confusing as well :/
Here is an example from BatLib/ReCode:

-BatLib commands use the OS parser to parse the arguments and return the result
-ReCode uses its own parser to parse commands
-ReCode lets the user use some BatLib commands


If ReCode is running, BatLib uses a different call to parse commands. What I do is when BatLib starts, a spot in RAM has the code for "jp LoadIncrement" where LoadIncrement is used to fetch the next argument. When ReCode is started, the address of the jump is changed to point to the ReCode parser.

This is faster than using flags or something boring like that to determine which call to use, but it uses 3 bytes of RAM XD

So, BatLib commands just call a jump, and that determines how the command is parsed Smile

(Sorry, that is still confusing, isn't it?)
Yeah it kinda is, I mean I get the concept but not so much the execution :/
Hmm, okay then... Here is an example similar to what I used in my first asm libraries that included a sprite command:

Here is the code for the sprite routine... Here only one byte changes:

Code:

;Inputs:
;     HL points to the byte in plotSScreen to start drawing
;     DE points to the sprite data
;
  ld bc,080Ch
Loop:
  ld a,(de)         ;1A
Logic:
  nop               ;00      This gets changed to some form of logic!!!
  ld (hl),a         ;77
  inc de            ;13
  ld a,b            ;78
  ld b,0            ;0600
  add hl,bc         ;09
  ld b,a            ;47
  djnz Loop         ;10F5
  ret               ;C9



Code:

ld a,Method         ;Method is the logic to use. 0=AND, 1=XOR, 2=OR, 3=Overwrite
and 3
rlca
rlca
rlca
add a,$A6           ;A6=and (hl)
ld (Logic),a

Does this help to give an idea of how to use SMC? There are other forms and this is a pretty straight forward way...
That actually helped alot Xeda! Thank you!!

This may actually prove useful for the ideas I have if I come up with something else I need help with I will post thanks!
Awesome! I am glad it helped and I hope it brings some new, crazy/convoluted ideas to the mix >Very Happy
Indeed, that's one way to do argument passing. The x86/Linux model of stack manipulation actually pushes the arguments onto the stack to construct a new stack frame, reserves space for local variables, and THEN calls (and pushes the return address in the appropriate place), so this is something of a variation on a theme.
Ok so I have finished Asm In 28 Days And while overly informative I found it totally worthless in the graphics department. That being said any one know a good tutorial that goes over graphics a bit better than Asm In 28 Days?
geekboy1011 wrote:
Ok so I have finished Asm In 28 Days And while overly informative I found it totally worthless in the graphics department. That being said any one know a good tutorial that goes over graphics a bit better than Asm In 28 Days?
I wouldn't say it's useless; it just doesn't explain how to use things like the Ion libraries built into Doors CS. Smile I don't know of any particular tutorials, though; what do you have in mind that you want to be able to do?
Well currently my thought train is geared torwards the features in CaDanite. Which sadly does not have a thread here yet, but I plan on it entailing a grey scale sprite editor which is probably the most complex part of it graphics wise.

As for the other projects I plan to take one of them is a grey scale puzzle game. Tix is what that would be so I need to figure out how to do graphics for that.

So just basic grey scale and graphics really and the best way/ways to do so in your opinions.

Also I would rather it not be geared torwards dcs as CaDanite will be an app and I am thinking Tix may end up to be as well if I include a lot of levels.
Why an on-calc grayscale sprite editor instead of using a standard image editor and a converter, or MSPaint and SourceCoder, or something? Are you asking what the best way to do grayscale is, then? I tend to favor Jim E's grayscale engine as being quite straightforward and easy to use. You then need to understand how to draw sprites, and text, and lines, and all that, I think.
On Calc for CaDanite we intend(more like I intend but meh) it to be fully functional Ide for CaDan.
The way we have been planning level packs for cadan is they include and hold all the graphics for the Stages. Be it backgrounds character sprites etc. That being said its just to keep it fully functional with out the need of a computer.

And I will look at the grayscale thing. As for graphics Hot_Dogs tutorial is helping alot so Thank you guys ^_^
Eh, what is it helping with? Just be sure you keep using hexadecimal and don't start using decimal for addresses or something. Wink Makes sense about trying to make it fully on-calc, although that might get challenging over time. Smile
Kerm wrote:
Makes sense about trying to make it fully on-calc, although that might get challenging over time.


Well possibly but I am not to concenered about size so a giant LUT will probably be abused for my sanity... then its just formatting the header which will be a pain other than that I am being told it should be pretty straight forward to "compile" the scripts.

Kerm wrote:
Eh, what is it helping with?

Hot_Dog's tutorials have a nice section on graphics and sprites, in apendix B I believe. It also comes with some sprite routines and something else(which I forget what is atm) which helps alot. Something I feel Asm in 28 days was lacking
Can some one explain how to change between app pages and such in multipage apps? reading tutorials and what hotdog calls branch tables are slightly making my head spin :/

As an idea has occured thanks to SirCmpwn I would also like info on how to read and write from the swap sector and if its feasible for semi long term storage (CaDanite has a concept which might include app hoping to test scripts I need a place to store all of CaDanite's ram data and such :/)

Code:
Hot_Dog's tutorials have a nice section on graphics and sprites, in apendix B I believe. It also comes with some sprite routines and something else(which I forget what is atm) which helps alot. Something I feel Asm in 28 days was lacking
Can I safely assume he simply copied out the open-source Ion sprite routines (not that there's anything wrong with that, of course). I'll have to take a look at some point. No, the swap sector is very very much not the right way to do any kind of storage, short or long term; why would you possible want to do that? How much RAM data would CaDanite have? What's wrong with AppVars?
Im not to sure and thats what Sir suggested so yeah Razz
As for storage space needed (This is all conjecture in my head so far)

~3-4 LUTs for compiling needs and such

actual storage space for the script being worked on and then space as well to hold the script during compilation

^ im not overy worried about this normally its when we call CaDan from CaDanite that I forsee issues in this I mean, CaDanite will have to work around all the ram CaDan is using OR backup and store every thing its working with and resume on script testings exit which involves backing up the in ram working script the compiled script and some other info that it stores to know what you are working with/doing within the script

(I hope that made sense :/ if it doesn't ask I'll try to clarify or nag me on irc)

So yeah I have no idea on Ram reqs yet as its still up in the air based on what Iambian packs into external script files
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 3
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement