Please post about any bugs you see in my code. If you can, please try to test these.
SwapRAM
Code: swapram:
; - Swaps two segments of RAM quickly through the stack
; - Input de -> first segment of RAM
; - hl -> second segment of RAM
; - bc -> amount of RAM to swap
; - Output RAM is quickly swapped through the stack
ld a,(hl)
push af
ld a,(de)
ld (hl),a
pop af
ld (de),a
inc hl
inc de
dec bc
ld a,b
or c
jr nz,swapram
ret
GetChecksum
Code: getchecksum:
; - Calculates a 16 bit checksum of a group of bytes
; - Input hl -> data to checksum
; - bc = number of bytes to checksum
; - Output hl = checksum
ld de,0
getchecksumloop:
ld a,(hl)
push hl
ld l,a
ld h,0
add hl,de
ex de,hl
pop hl
inc hl
dec bc
ld a,b
or c
jr nz,getchecksumloop
ex de,hl
ret
2 of 57 done. 
SetUpInt
Code: setupint:
ret
LargeSpriteHL
Code: largespritehl:
ld a,h
jp iLargeSprite
The problem is that wont they have to be compiled into the same location in memory as well?
Negatory. Due to a nifty little trick called the vector jumptable, all you need is a table of 3bytes for each routine. Each entry consists of a 1-byte "jp" opcode ($C3) followed by the 2-byte address of the routine. It doesn't matter what the address is - as long as the vector jumptable is in the proper place, it will still work. Indeed, I have managed to figure out a way not only to get the jumptable in the correct place, but work around the many problems associated with having an offpage branch table intended to be placed at the same memory location. Also, I have nearly all the routines completely rewritten and working, thanks to some help from Dan Weiss (DWedit).
Looking good so far Kerm (no bugs that I can see). I'm glad you're finally adding MOS support.
Heh, ty. Can't guarantee anything yet though - it might not work out, or my planned method for getting around the branch table problem might not work.
Well, the vector tables for ION, MOS, and DCS don't overlap, right? So there shouldn't be a problem...at least not that I can see. Why do you need a complex method?
Because of the multipage nature of Doors CS internal betas higher than 5.6.1. I don't even know if multipage is going to work at all yet; I'm still trying to convert everything into the proper format. The "branch table" tells the TI-OS how to handle bcalling onto other pages within the app, and according to TI documentation "must be a multiple of three bytes from the start of the app, directly after the header". However, that's where the MOS vector table goes, and neither can really be moved. Hence my dilemma, which I believe is solvable. I'll let you guys know if it works or not.
Oh yea that's right. I forgot this was becoming a multipage App. The MOS libs are at the very beginning of MOS? Wouldn't there have to be some instruction before them that jumps over them to the true start of the program then? Otherwise, wouldn't MOS begin by executing the first lib entry. You probably know better, as I know neither your setup, nor MOS's.
Yes, the jp RealStart is the first 3 bytes of any program, including MOS and multipage apps, but then the branch table is supposed to start. I think I got it though...
In other news, I just successfully compiled and ran Doors CS in two page form, although the majority of the second page was blank. The nonblank parts were theoretically full MOS libs
Bwa bwa waaaa....
I've made a multipage app before, and all I needed for a "branch table" was the jp real start at the top.
I'm glad it's going well.
Edit: So, wait....you have the mirage libs completely done? Than what was the point of this topic if you're already done?
Edit2: Oh, it just looks like you had a few of them completed fully. I get it.
. If you want, you can post some that need to be done, and I can try my hand at them.
No no, you were right the first time. I finished them completely since I started this topic. And the reason a multipage DCS is so challenging here is that I need both of Doors CS's pages to reference the other page, but I also need (probably) both pages to have the vector definitions at the top as well.
KermMartian wrote:
No no, you were right the first time. I finished them completely since I started this topic. And the reason a multipage DCS is so challenging here is that I need both of Doors CS's pages to reference the other page, but I also need (probably) both pages to have the vector definitions at the top as well.
57 routines in 3 days? you're a genius (but we knew that...)
I feel the smilie is enough to convey my feelings
Heh, I actually found the majority of them surprisingly easy to rewrite.
Accidental delayed doublepost. Read my post above.
Nice. So when will there be a released MOS supporting DCS? I want to be able to use DCS to debug
that program...
Yup, as I said in the Good GUI... thread, 5.6 private beta 1 will have alpha MOS support. 5.7 is expected to have stable beta support, and 5.8 should have full support.;
