You can use the standard safeRAM areas and/or create yourself an Appvar or two to use.
I will be using the standard areas, for sure, but I think I'll also be using some other sections like the MD5 areas. Would it be a bad idea to use the editCursor, editTop, editBtm, editTail areas?
Only if you have an edit buffer open while you're messing with those. 
All the other safeRAM areas together are insufficient? 
All the other safeRAM areas together are insufficient?
No, I just prefer to use large areas to store large portions of information. If I only have one or two bytes of data to use, I think it makes sense to just use a one or two byte scrap ram area. Am I wrong?
ZippyDee wrote:
No, I just prefer to use large areas to store large portions of information. If I only have one or two bytes of data to use, I think it makes sense to just use a one or two byte scrap ram area. Am I wrong?
Well, in most programs you need a whole scad of little one and two byte pieces, along with a few larger 8 or 16 or whatever-byte pieces, so those all usually get jumbled together in named compartments of standard safeRAM, for example from Oblit:
Code:
calccount .equ saferam2 ;1 byte
totalplayers .equ calccount+1 ;1 byte
PingSendTimer .equ totalplayers+1 ;2 bytes
whichcalc .equ PingSendTimer+2 ;1 byte
whichturn .equ whichcalc+1 ;1 byte
aimpower .equ whichturn+1 ;1 byte
aimupdatecount .equ aimpower+1 ;1 byte
firing .equ aimupdatecount+1 ;2 bytes
posx .equ firing+2 ;2 bytes
posy .equ posx+2 ;2 bytes
velx .equ posy+2 ;2 bytes
vely .equ velx+2 ;2 bytes
interfaceybase .equ vely+2 ;1 byte
thisminplayers .equ interfaceybase+1 ;1 byte
Begin_NACK .equ thisminplayers+1 ;1 byte
curwind .equ Begin_NACK+1 ;1 byte
aishooting .equ curwind+1 ;1 byte
curaimer .equ aishooting+1 ;9 bytes
idarray .equ curaimer+9 ;remaining bytes
costheta .equ velx ;alias for AI aiming
sintheta .equ vely ;alias for AI aiming
theta .equ posx ;ditto
starttheta .equ posx+1 ;ditto
constQ .equ posy ;ditto
aiaimpower .equ aimupdatecount ;ditto
Okay, I'm trying to make an interrupt for blinking the cursor. This is my interrupt right now:
Code:
But this is crashing the app...Did I do something wrong with it?
EDIT: added some comments
Code:
CursorInterrupt:
di
ex af, af' ;' the green from apostrophes annoys me
exx
ld hl, cursorCounter ;My counter byte
xor a
out (3), a
cp (hl)
jp nz, CurIntRet
ld (hl), 80
ld a, char_curInsert ;This is used in zPutChar to draw the "insert" cursor
ld hl, (pencol)
push hl
ld hl, 0
ld (pencol), hl
ld bc, (pencol)
ld d, c
ld e, b
call zPutChar
pop hl
ld (pencol), hl
ld hl, (flags+curflags)
ld a, (hl)
xor 8
ld (hl), a
CurIntRet:
ld hl, cursorCounter
dec (hl)
ld a, INTRPT_MASK ;%00001011
out (3), a
exx
ex af, af' ;'
ei
ret
But this is crashing the app...Did I do something wrong with it?
EDIT: added some comments
I can't figure that part out...I don't know how to set it up. I want to have both the lookup-table AND the interrupt somewhere within statVars (I'm using other ram areas). Pretending that I know nothing about how to set up an interrupt, because I don't, how do I set up this a thing?
ZippyDee wrote:
I can't figure that part out...I don't know how to set it up. I want to have both the lookup-table AND the interrupt somewhere within statVars (I'm using other ram areas). Pretending that I know nothing about how to set up an interrupt, because I don't, how do I set up this a thing?
Well, for starters, you need to at least have a stub for your interrupt somewhere with a repeating byte of address, like $9999 or $9A9A or $9B9B. ASM in 28 Days has a flawed interrupts tutorial, but it will at least get you on the right track as far as memory areas goes. After you take a look, we'll have to clarify some stuff about the proper use of Ports 3 and 4.
Would $8A8A work? As I said, I want to keep it all within statVars if possible, I'm using the AppBackupScreen for a back buffer in grayscale...
Also, I found this tutorial as well: http://tifreakware.net/tutorials/83p/a/intguide.htm
But again, I don't know how to get that to work all within statVars.
Also, I found this tutorial as well: http://tifreakware.net/tutorials/83p/a/intguide.htm
But again, I don't know how to get that to work all within statVars.
ZippyDee wrote:
Would $8A8A work? As I said, I want to keep it all within statVars if possible, I'm using the AppBackupScreen for a back buffer in grayscale...
Also, I found this tutorial as well: http://tifreakware.net/tutorials/83p/a/intguide.htm
But again, I don't know how to get that to work all within statVars.
$8A8A would certainly work. Part of the problem is that register 'i' will hold a byte, then ir (if i=$AB, then r is a random number $XY, so $ABXY) points to a pointer to the interrupt routine, but becaus it's random, $AB00 through $AC00 (257 bytes) must all point to the interrupt routine. Because you can start at any byte, if you used something like $6789, you could land on a word reading $6789 or one reading $8967, hence the need for a doubled address. Also, I found this tutorial as well: http://tifreakware.net/tutorials/83p/a/intguide.htm
But again, I don't know how to get that to work all within statVars.
ZippyDee wrote:
Okay, so now that I've got my interrupt at $8A8A, how do I set up the lookup table?
Did you take a look at Day 23 of ASM in 28 Days yet? It has some very helpful background information.
Will I have to use $8B00 through $8C00 for the LUT? If so, I guess I need to see if my interrupt fits between $8A8A and $8AFF.....I don't think I have 257 bytes at $8C00, do I?
Okay, I think I did it right, but it's still crashing the calc. What am I doing wrong with this setup:
Code:
Also, I changed the "jp nz, CurIntRet" in the interrupt itself to "jr nz, CurIntRet" because I realized that would have posed some issues.....
Code:
di
ld hl, $8B00
ld de, $8B01
ld bc, 256
ld (hl),$8A
ldir
ld hl, CursorInterrupt
ld de, $8A8A
ld bc, CursorInterruptEnd-CursorInterrupt
ldir
ld a, $8A
ld i, a
ld a, INTRPT_MASK ;%00001011
out (3), a
im 2
ei
Also, I changed the "jp nz, CurIntRet" in the interrupt itself to "jr nz, CurIntRet" because I realized that would have posed some issues.....
Can you show us the contents of CursorInterrupt? Or is it the same as what you have up there? Also, if it would be helpful, I can email you the CALCnet 2.2 interrupt framework for you to glance through.
Edit: Hold on, is your interrupt body in an app? If so, you need to have your RAM stub do page-swapping, for when the OS has a page of its own swapped into the App back for the purposes of a bcall.
Edit: Hold on, is your interrupt body in an app? If so, you need to have your RAM stub do page-swapping, for when the OS has a page of its own swapped into the App back for the purposes of a bcall.
The interrupt is copied to $8A8A. But the interrupt CALLS a routine inside the app......is that bad? Would it be better to just do a page swap and run the whole thing from in the body of the app?
ZippyDee wrote:
The interrupt is copied to $8A8A. But the interrupt CALLS a routine inside the app......is that bad? Would it be better to just do a page swap and run the whole thing from in the body of the app?
Just load the contents of port 6, push it, load your app's page to port 6, do the call, then restore the pushed value to port 6 from the stack.
How do I know what the app's page is?
Also, the code in the interrupt is the same as above with the sole change being that it uses jr instead of jp.
And this is gonna be doing text-editing, so would direct input be a better way to go? Or should I stick with getCSC?
Also, the code in the interrupt is the same as above with the sole change being that it uses jr instead of jp.
And this is gonna be doing text-editing, so would direct input be a better way to go? Or should I stick with getCSC?
ZippyDee wrote:
How do I know what the app's page is?
Also, the code in the interrupt is the same as above with the sole change being that it uses jr instead of jp.
And this is gonna be doing text-editing, so would direct input be a better way to go? Or should I stick with getCSC?
If the interrupt setup runs inside your app, right? Then you can grab the value of port 6 during the setup and modify the requisite byte in the RAM stub routine after you copy it. Also, the code in the interrupt is the same as above with the sole change being that it uses jr instead of jp.
And this is gonna be doing text-editing, so would direct input be a better way to go? Or should I stick with getCSC?
Register to Join the Conversation
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
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