Hi, I saw your Chip-8 Assembler and Emulator, they're great btw :3
but...
Unfortunately, there's a bug that might you solve,
Your emulator terminates when running this Chip-8 program:
Cycle counter 2
(actually, i did fix it so it could running on your chip-8 emulator now ._.)
Cycle counter 2 (Fixed)
I have more Chip-8 program that written by mine,
currently... Implementation of Single Precision Floating Number Arithmetic in progress,
The plan is to render mandelbrot, (even if it slow as hell)
It's written using Octo's assembler

What is an Issue?

The program suddenly terminates, simply running this CHIP-8 Instruction:
AFFF then FF55 or FF65,

My suggestion,
Loading register from memory at 0xFFF loads v0, but v1-vF settled to the zero,
Saving register to memory at 0xFFF only save v0, v1-vF values won't saved to memory

But what's method are used by my own Chip-8 emulator?
Loading register from memory at 0xFFF loads all register from memory 0xFFF & 0xFFF
Saving register to memory at 0xFFF save all register to memory 0xFFF & 0xFFF
So, memory values between 0x000 - 0x00E may changed due this instruction.

Sincerely, Thanks~
A-KouZ1

1NNN 	CALL NNN 	Call CHIP-8 subroutine at NNN
2NNN 	JP NNN 	        Jump to address NNN

Should be the other way round I think.....

fuwangqin@fuwangqin-pc:~/go/src/CHIP-8$ go build -ldflags "-H windowsgui"

CHIP-8

./main.go:248: undefined: sdl.LoadBMP_RW
./main.go:338: cannot convert ev.File (type string) to type *C.char
./main.go:339: undefined: sdl.KeyDownEvent
./main.go:340: ev.Keysym undefined (type sdl.Event is interface with no methods)
./main.go:343: ev.Keysym undefined (type sdl.Event is interface with no methods)
./main.go:398: undefined: sdl.KeyUpEvent
./main.go:399: ev.Keysym undefined (type sdl.Event is interface with no methods)
./main.go:581: cannot use x (type int) as type int32 in argument to Renderer.DrawPoint
./main.go:581: cannot use y (type int) as type int32 in argument to Renderer.DrawPoint
./main.go:658: cannot use x (type int) as type int32 in argument to Renderer.DrawLine
./main.go:658: too many errors

Your readme lists 0x00BN as an SCHIP instruction which scrolls the screen up by N pixels. To the best of my knowledge SCHIP does not provide this instruction. It's a strange omission, admittedly. If you wish to keep this instruction, I'd advise categorizing it as an EXTENDED operation.

You might also consider altering the encoding to 0x00DN, as this would be compatible with XO-Chip, a set of extended instructions introduced in my emulator toolchain and used in several existing games.

Have a look at this discussion for some primary research. If you based your instruction set information on something other than the reference material gathered by @trapexit, it would be good to reach out to them and clear this up; CHIP-8 already has plenty of confusion surrounding its behavior!

You might also find this useful- it contains some details on quirks and undocumented bugs in the various canonical HP-48 interpreters.

Hello, @massung.

• https://raw.githubusercontent.com/massung/CHIP-8/master/font.bmp

Above is your 5x7 font file, what tools and fonts did you use to generate it?

I feel it is a very beautiful bitmap font. I'm glad if you can answer.

I can't get bip sounds from this release.

Hi,
I'm trying to build your emulator but i get a panic with the binary.

panic: Conflicting window flags specified
goroutine 1 [running, locked to thread]:
main.createWindow()
C:/Users/rsrim/go/src/github.com/massung/CHIP-8/main.go:217 +0x17d
main.main()
C:/Users/rsrim/go/src/github.com/massung/CHIP-8/main.go:173 +0x274

Any ideas ?

Hi,
first of all I like that this is one of the few implementations that also has an assembler, and the UI is clean and nice!

I just found that the implementation suffers from some issues in the arithmetic opcodes:

8xy4: The way the overflow is detected breaks on use cases where x == y, so 8004 with v0 = 80 gives 0 and VF=0 which is wrong.

8xy5, 8xy6, 8xy7 and 8xyE all have the issue that VF is set first, breaking if VF is one of the operands, the typical solution is to set the flag result into a temp, set Vx to the result of the operation and set VF to that temp then. This also correctly handles the case that x is F as in CHIP-8 for arithmetic operations with VF as the result register the flag and not the operation result should be in VF.

This VF order issue is a quite common one as many documentations either lack the information or the description is kinda misleading. But as Octo uses this behavior with VF to implement additional pseudo SKIPs by using an operation on VF and skipping on the result to not overwrite other registers, any modern program that is using one of these skip variants is going to fail in this emulator. It is the behavior of the original CHIP-8/CHIP-48/SCHIP-1.x interpreters.

The excellent test suite from Timendus (https://github.com/Timendus/chip8-test-suite) has a flags test that can be used to check this.

Also the Fx1E handling is propagating a myth, while the discussion in Chromatophores HP-48 analysis repo talks about the possibility of an Amiga Interpreter that shows this behavior, none of the three currently known interpreters does this, so it is just a theory. The only game that might profit from it (the infamous Spacefight 2091 from that discussion) actually only "needs" VF to be reset and is broken even with this "fix", Chromatophore made a fixed version of the game fixing two bugs and not needing this. Also this behavior instead breaks other games that correctly do not expect VF to be erased by Fx1E, so it is doing more harm than good. If it would be configurable and off by default, okay, but this way it's more of a problem. (And yes, like in the scroll-up case, trapexit's documentation is incorrect in this regard.