Okay, it worked that time. I don't know why it didn't work the first time I tried it, maybe I transferred the wrong .8xp file. Thank you very much all, sorry I was so bad at phrasing my question.

I tried the all-on-one-line approach, and the same thing happened. The issue is that the path is appearing in the filename once the program is transferred to the emulator. Instead of BACKGRND, it's C:\Asm\Spasm\BACKGRND. I just want to be able to remove the path from the beginning of the filename when I transfer the program to the emulator.

cd "C:\asm\spasm"
spasm.exe BACKGRND.txt
binpac8x.py BACKGRND.bin

8xp file is attached, along with notepad file.

Just noticed something else weird. The program file is wayyyyy smaller than it should be. It's 76 bytes, and the program has a single table bigger than that. I looked at the .bin file I got from the assembler and that's apparently 0 bytes. Is this a windows problem or an assembler problem?

EDIT: Nevermind, re-assembled the program and it's back to up to the proper 710 bytes. Just a weird glitch I guess.

EDITTACULAR: Another screenshot, showing how the program name changes on the home screen.

I'm sorry to come running here for help so quickly this time, but I haven't been able to find this out anywhere else. I recently downloaded wabbitemu, since I was sick of clearing my ram all of the time, and SPASM, since I was sick of typing assembly programs on the calculator all the time. I got spasm to work just fine, and it's churning out lovely .8xp files just like I want it to. However, whenever I try to drag-and-drop a program file into wabbitemu, it's stored into the calculator as "C:\Asm\Spasm\program.exe", which, of course, generates a syntax error when I try to run it. How can I fix this?

Thanks, and sorry for asking two questions in a row  .

  di
  ld a,$99
  ld i,a
  ld hl,$9900
  ld de, $9901
  ld (hl),$9A
  ld bc,256
  ldir
  ld ix,$9A9A
  ld (ix+0),$C3
  ld hl,Interrupt
  ld (ix+1),l
  ld (ix+2),h
  im 2
  ld a,%00001011
  out (3),a
  ld e,$FF
  ei
Loop:
  jr Loop
Interrupt:
  di
  xor a
  out (3),a
  ld a,$26
  out ($10),a
  call WasteTime
  ld a,$9C
  out ($10),a
  call WasteTime
  ld a,e
  srl a
  srl a
  out ($11),a
  dec e
  ld a,%00001011
  out (3),a
  ei
  ret
WasteTime:
  ld l,10
WasteLoop:
  nop
  nop
  nop
  nop
  dec l
  jr nz,WasteLoop
  ret

My code as it is currently, by request of Sorunome. Thanks Eems for the link.

Edit Sorunome: added code-tags

Tried that as well.

Spent a little while tinkering with the program this morning, and I have two things that are definitely not solutions.

1. I output %00001011 to port 3 during setup, output %00000000 at the beginning of the interrupt routine, and reverted it to %00001011 at the end, which I think is what Geekboy was suggesting. I changed reti to ret as well, but I wouldn't really call that a proposed solution, just an optimization.

2. I added two "srl a"s before "out ($11),a". This way, the pixels to be displayed only change every 4 interrupts i.e. 35 times a second, which is well within the LCD's refresh rate. The problem persisted, and I didn't expect it to, as I don't think the interrupt routine is running a second time.

I might try some more solutions later but I'm out of ideas at the moment.

EDIT: changing the interrupt setup to a full table now

---

Ok, I replaced the interrupt setup with the following code, similar to Sorunome's, but with a slight optimization using ix instead of hl, and moving the table to $9900 since I was more familiar with that area of RAM.

ld a,$99
ld i,a
ld hl,$9900
ld de, $9901
ld (hl),$9A
ld bc,256
ldir
ld ix,$9A9A
ld (ix+0),$C3
ld hl,Interrupt
ld (ix+1),l
ld (ix+2),h
im 2

Unfortunately, it had the same result. The specified 8 pixels set, and no updates.


_{Edit (Eeems): Merged double post}