[...]
As a side note, i'm using wabbitemu to emulate, and i'm not sure how to record video on it...

Either with the backspace key or with "File" --> "Record GIF"

How does your method "Draw" look like? (More importantly: what kind of arguments does it take / what do they do)

From the look of the screenshot it looks like when it is shifting out a whole tile it isn't working as expected, so my guess right now is that something with
!If {GDB0}/2/2/2/2→A=0:15-A→A:End
!If {1+GDB0}/2/2/2/2→B=0:15-B→B:End
is wrong. Without really knowing what the code does, why 15-A and 15-B and not 16? (since your tiles are 16x16)

Again, I don't really understand your code yet, i might be just plain up wrong, lol

In case you need any more information on port 4 you can find it here: http://wikiti.brandonw.net/index.php?title=83Plus:Ports:04

Mind posting the whole code you currently have? The thing is, I can't see any port 03 access in your top post.

Do you run "ei" before returning from your interrupt? I did mention it in my huge post but you might have simpely over-read it ^.^

On the calculator interrupts are unfortunately a bit more complex than that.

The reason being is that TI didn't care about im2 mode, and thus the hardware is returning a random address to jump to.

What does this mean? You will need to place your interrupt handler at an address where the high and the low bytes are the same and your interrupt vector needs to be 257 bytes large.

Here's an example with the instruction tale at $8000 (note that with this way you will have to disable interrupts before archiving stuff and re-create your jump table as it uses up the first byte of ramCode)
The interrupt handler is located at $8585, we will jump to some other location straight away
; disable interrupts and set interrupt mode 2
di
im 2

; set the upper byte of the jumptable to $80
ld a,$80
ld i,a

; create the vector table (do this every time before you enable interrupts, be sure to disable interrupts before archiving / unarchiving stuff)
ld hl, $8000
ld de, $8001
ld (hl), $85
ld bc,256
ldir

; setting up the jump handler at $8585
ld hl,$8585
ld (hl),$c3 ; this is the jp instruction
ld de,InterruptHandler ; replace this with whatever label you are jumping to, where you have your interrupt handler
inc hl
ld (hl),e
inc hl
ld (hl),d

; time to enable interrupts
ei
Keep in mind that interrupts keep on disable themself, you will have to call "ei" at the end of your interrupt routine so that it'll trigger again.

You could also set up your interrupt table at $9900, just adjust setting the riger i and the vector table accordingly, that would allow you to do whatever flash operations while running the interrupt, however that means you can't use appBakUpScrn


If you are creating an app your interrupt handler will need to be in a ram location and you need to make sure you swap in the correct flash pages (or, alternatively, you may not use any bcalls at all, custom ones or system ones).


Here's the code for an app:
Note that it also uses $8584 and keyToStr
#define basepage $8584
Run:
; disable interrupts and set interrupt mode 2
di
im 2

; save whichever page we are on so that we know where to go
in a,(6)
ld (basepage),a

; set the upper byte of the jumptable to $80
ld a,$80
ld i,a

; now we copy our interrupt loader to ram, we only have to do this once
ld hl,LoadInterrupt
ld de,keyToStr
ld bc,LoadInterruptSize
ldir

; create the vector table (do this every time before you enable interrupts, be sure to disable interrupts before archiving / unarchiving stuff)
ld hl, $8000
ld de, $8001
ld (hl), $85
ld bc,256
ldir

; setting up the jump handler at $8585
ld hl,$8585
ld (hl),$c3 ; this is the jp instruction
ld de,InterruptHandler ; replace this with whatever label you are jumping to, where you have your interrupt handler
inc hl
ld (hl),e
inc hl
ld (hl),d

; time to enable interrupts
ei

; we will copy this to ram, it'll swap us the correct page in and swap back whichever page we had before
LoadInterrupt:
push af
in a,(6)
push af
ld a,(basepage)
out (6),a
call Interrupt
pop af
out (6),a
pop af
ei
ret
LoadInterruptSize = $ - LoadInterrupt

; now we have our actual interrupt handler
Interrupt:
; we can do whatever here, since LoadInterrupt already does ei we don't have to do it in here
ret

Why does the Interrupt address has to be at a place where high and low bytes match?
Well, let's say you set i to $80 so that the interrupt jump-tabe starts at $8000. Now, let's say you want to have the handler at, like $9876
For that you'd want to set these bytes starting at $8000:
.db $76,$98 ; reverse order due to little endian-ness
.db $76,$98
.db $76,$98
.db $76,$98
.db $76,$98

etc.
Now, let's say the interrupt fires and the hardware reports as lower byte 0, so we take the address at $8000, which is $9876.
If the hardware reports 2 we take the address at $8002, which is $9876

That all seems fine. However, the addresses the hardware reports are seemingly random, so let's say the hardware reports 1
Now we take the address at $8001 which is $7698. Woops, that shouldn't happen.
You overgo this by only using addresses where the high and the low bytes match

EDIT: As Runer112 pointed out, you don't actually need the upper and lower bytes to match, you'd need to have two handlers then, though, in this example one at $9876 and one at $7698 (while the later is actually not possible as that isn't ram, which just shows how much easier it is if you have the upper and lower bytes matched)
Why must the interrupt vector be 257 bytes large?
Especially, why not 256 bytes?
Well, 256 bytes would be sufficiant if the hardware could only reply 0 - $FE
However, if the hardware replies $FF, then we are looking for the address at $80FF which consists of one byte at $80FF and one byte at $8100, thus we need a 257-bytes large vector table

Quote from: Runer112 on August 22, 2016, 06:47:40 pm

Looks pretty neat. However, I should point out that you've somehow lost all the plus signs (not just here, on git as well).

Are floats not part of the plan? I'd be slightly disappointed if that's the case. I recognize the pain of supporting them on hardware without an FPU (or even a good ALU), but any programs involving serious math or graphics really need them.

Thanks
Oh, and thank you for pointing that out. I have really not noticed that
EDIT: FIXED.

Floats are not going to be part of the default instruction set. Floats are not going to be part of the default extended instruction set. They might be something added to the extended instruction set at a later point, but they will be one thing, incredibly slow. Fixed-point however, will be supported by the default extended instruction set and it will certainly be a lot faster

What kind of fixed point? 8.8? I'd definitally recommend adding floating point or something similar, even if it is slow, it's still way simpler than having to write the routines yourself.

This design limit was set early on, as really none of the platforms I am targeting have a dedicated float processor or float instructions. Most platforms are 16 or 32-bit microcontrollers or the 84+ which all use soft float. Using float for the main data type would be totally silly and adding more than one data type is making everything way too complex and RAM-consuming.

Yet people will probably still want to program things with floating point variables, and having slower ones in an extendended instruction set or something, like you mentioned, would allow that while trying to encourage the user to rather use like 8.8 fixed point.

Hey,

So, I'm wanting to program a game where I draw a tilemap for the background and have masked sprites for the character and objects/enemies, etc. It'd be a side-scrolling game

I read here that the quickest way to get a tilemap to shift is by using the Horizontal or Vertical commands. You then redraw the side the direction the map shifted. Like, if the map moves down, you redraw that side, etc. This avoids drawing the whole map over again.

Sounds right

If the screen has masked sprites on it, will they shift along with everything else when I use the Horizontal/Vertical commands? How could I avoid it?

Yes, the masked sprite would also shift along

It probably has to do with the front and back buffers, but I dont know too much about them, so an explanation on buffers could be helpful!

There are multiple ways in solving this problem, as you already suggested back and front buffers, i'll explain that one.
The following is assuming you don't use grayscale, only black/white.

So, basically you draw your tilemap to the back buffer (you know, with the ^r command), and then also shift the back-buffer (whith Horizontal+^r etc.)

Then, when drawing the screen, you copy the back buffer to the front buffer: Copy(L3)

After that, you draw your masked sprite to the front buffer (with your normal commands)

And then with DispGraph the screen gets updated.

I hope that made sense somehow