Remainder operation:

As per the spec., Z and N flags are set respectively when: the result is 0, and bit[15] of the result is set.

Remainder (%) is defined as: (a % n) = (a - (n * int(a/n))), not to be confused with the modulus.

It could be useful to have a txt file including the spec (machine specification and instruction set), as simple as possible, to allow off-line work.

Bitwise NOT operation:

As per the spec., Z and N flags are set respectively when: the result is 0, and bit[15] of the result is set.

Bitwise NOT is defined as flipping all the bits of a number.

To be able to create pictures/resources that have their size description internally (self-containment) this would be great.
F.e. this would read as a sprite of size 32x32 placed at Xpos,Ypos

LDI R0, Xpos
LDI R1, Ypos
LDI R2, SpriteData
SPR R2
ADDI R2,2
DRW R0,R1,R2

SpriteData:
db 0x10, 0x20, spritedata

When doing advanced libraries, I see the need for heavy stack usage. To keep all registers unaffected, an initial POP/PUSH of all registers used within the function is a must.

Then to make functions with in- and outparameters as generic as possible, these shall NOT use registers as their calling convention. Either using predetermined addresses for calling parameters to specific libraries or using stack seem to be the best possiblity. Both seem OK, but i really like the stack-based calling convention better. To be able to lift inparameters from stack to memory without destroying/using more registers, the use of especially PUSH (RX) and POP (RX) would help, which would use the address of RX to interact with the stack.

Is there a way to read the SP today? I know we can write to SP: LDI SP, HHLL
Maybe that could be useful to be able to read also?

I was looking at the thread on ngemu and found an addition proposition, for 8 bits loads :

In both instructions, HH of RX is zeroed.

This was proposed by @paulfnicholls

I'm not sure where the current forum are, so I just though I see if anyone's alive. I've though about this for a long while, but though I'll give it a try.

I will be writing it for one of my current 4 boards. It is the Xilinx Spartan 3E-1600E and it also uses a home-built extension board called Arcade Extender. Older FPGA board but it will suit this project good enough. First version will be using internal BRAM memories for both Framebuffer and Internal memory. Current memory is already Dual-Port so already support being updated Live while showing without any hick-up. But there is nothing to update with yet! :-) Just a static picture in pre-loaded in Framebuffer at build time.

Started with a 320x240 Framebuffer for 4-bit grey color. This will then be converted to a palletized 4-bit color mode, as supported by Chip16. It will be added to github when being somewhat useful.

What is the current status of the CHIP16 project?

More specifically, when will the next specification (1.4) be released?

There is currently no easy way to access the stack pointer (SP) for easy function argument access. Instead, it is currently necessary to reserve registers for passing values, or to pop all the parameters at once.

I propose the following instructions to solve this:

Allowing additional operations to directly modify SP would involve extensive additions to nearly all instruction groups, this solution is simpler.

A function call of type

foo(x,y,z);

would be translated as

push x
push y
push z
call foo

with foo maybe starting as follows:

foo:
    mov r0, sp ; stack pointer is recorded
    ; either manipulate r0, or pop, to access variables
    mov sp, r0
    ret

Modulo operation:

As per the spec., Z and N flags are set respectively when: the result is 0, and bit[15] of the result is set.

Modulus (MOD) is defined as: (a MOD n) = ((n + a % n) % n), where % is the remainder.

To be able to implement stuff like:

• BASIC interpreter
• Console
• Nice simple input windows

it would ge great to have a I/O registerfor a normal QWERTY-keyboard.
The addition is small and would give lots of new possibilities.

I'm implementing sound support for a chip16 emulator, and have questions, which aren't currently answered by the spec:

• What are the default values of the sound generation parameters?
• What should SNP rx, duration with rx == 0 do? The same as SND0?

Support at least one external directory from which external files could be loaded into Chip16 mem would be nice. The implementation of a emulator could do whatever it like of course, but the simplest implementation would be to just map one directory on the physical drive.

Suggestion of minimal changes for most functionality:

GETFILE X,Y,Z - used to enumerate and "search" for files, also check sizes
X - Number of file to fetch from directory, used for enumeration, INPUT
Y- Holds the address where to put the name as a zero-terminated string, INPUT
Z - Size of file (up to 64K), OUTPUT

LOADFILE X,Y,Z - used to load files by name, f.e. one that is returned by GETFILE
X = Name zero-terminated string, INPUT
Y = Startaddress, INPUT
Z= Length of file, OUTPUT

SAVEFILE X,Y,Z - create a new file or overrite and old file.
X = Name zero-terminated string, INPUT
Y = Startaddress, INPUT
Z= Length of file, INPUT

@tykel
Hi, i was browsing the Herdle asm code and found conditional jump as :
"jmx ..." , but the spec states it should be the jx form.

Is there an error in one of those ?

Motivation : The specifications changes will be updated on GH, so will the docs and discussions, so I think the assembler should be linked to this repository, because it has to change as soon as the spec change.

Extra motivation : When an instruction request is posted on GH, it should be "closed" only if it has been added to the assembler, and can be added to a specification only if it is closed. Therefore, the assembler will always refer to the latest spec. Tagged branches could be used to track the major changes of the assembler and to allow the use of an old version if needed.

Technical details : the tchip16 is available on google code, and is under GNU GPL v3, that means it can be forked and reused under the GNU GPL license. Of course the original paternity should be mentionned, but it should be able to be modified by the community (commits by upstream members or pull requests from the simple followers, etc).

This is my state of mind and just an open discussion, don't want to offense anyone.

One thing missing from Chip16 is a GetPixel. Because the framebuffer isn't mapped to memory it is impossible to know pixel state after you drawn if you don't make a clone of the framebuffer in memory. Including such a feature will make more nice graphics effects easier to implement and also the platform more complete.

Maybe even a GetSprite which takes a specified part of the screen and makes a copy of it into Chip16 RAM. Like DRW but backwards in the other direction. Could probably used for some nice effects.

Simple implementation that gvies even MORE control is:

0F 00 0N 00 SDD - Set Draw Direction
n=0 default draw sprites in frame buffer
n=1 default draw sprites from frame buffer into memory

It should also adhere to the FLIP flag copying a flipped version both ways.

The specification mentions a 16 byte header but the following table only accounts for 14 bytes. Should the checksum field be 4 instead of 2 bytes long?

I couldn't add a comment to the old discussion so I started a new one.
A sub-frame timer would keep track of how much time or how many instructions have elapsed since last Counter Reset sound useful. That is a tick counter either for instructions or us (which would actually be the same in this case..) could be quite nice. Could be used to keep track of frame rate for apps and usage of Chip16 resources. As a maximizing tool when trying optimize and keep 60 Hz or just for statistics.

Hi there. I propose a few improvements to the further chip16 specs (not the 1.3) that is, a time management.

That would mean as an example adding instructions to get the time the emulator has been running for, in seconds maybe and a resetable counter more precise in ms as an example.

Goal : being able to have a time notion in c16 roms, such as timed event and more...

Such modifications would probably require new registers in the cpu.

What do you think?

For platform games implemented in Chip16, I think there is a need to be able to have more than 1 single color being a so called background color, BGC. Just take Super Mario as an example. Background graphics will be quite boring if only a single color is allowed. This is also true for maybe a car game.. Not even possible to have a road consisting of drawn lines or asphalt drawn from more than 1 single color. It will collide on everything drawn excluding the base color.

Suggestion 1:
Maybe a separate 16-bit memory-mapped register (2 8-bit addresses after each other) with just 1 bit stating if the ColorIndex is used for background or not.
0 - NotBackground
1 - Background

0xFFF4 - BGIndexReg0 7654'3210
0xFFF5 - BGIndexReg1 FEDC'BA98

OR a single instruction more similar to Chip16 design today:

Suggestion 2:
BGCI x - where the 16-bit value in register Rx is set but is hidden and can't be reread.

Each bit is mapped to the corresponding colorIndex (0-15)
The logic for the above would follow the same patterns are today,
ColorIndex numbers with corresponding bit set to 0 or 1 does NOT collide with other indexes set to 1 (background). Bits set to 0 (NotBackground) WILL collide with itself and other ColorIndex numbers that have the corresponding bit in BGCI register set to 0.

To still keep the current behavior of BGC for old programs, the inital value BGCI is:
0000000000000001
which makes ColorIndex0 as Background and all others a NotBackground.
Also when using BGC only the bit given as nibble parameter n will be set and the rest will be cleared. This way, future emulation implementers can exchange the underlying representation of the 4-bit BGC to JUST using a 16-bit BGCI

I was looking at the thread on ngemu and found an addition proposition, for 8 bits stores :

This was proposed by @paulfnicholls

Hi. Here i propose to add 2 new operations to perform an incrementation and a decrementation.

Motivation : Easier for loops or counters.

Unless I'm seriously wrong somewhere, I think it should be clarified that when talking about signed registers, only the 16 general registers shall be signed. Does it make sense to talk about a signed program counter, or a stack pointer?

Currently there is no clear way of knowing when individual instructions were introduced into the specification.

Adding a new column, "Spec." or "Rev. introduced" with the specification number the instruction first appeared in, would be useful for this.

A little research is needed to go over the instructions, but will make future change management a good deal easier.

Aiming for introduction in Specification 1.3.

The instructions page lists SAL instructions with identical opcodes to the SHL equivalents:

Can these be removed?

P.S. Why is there no opcode 0x11?

This defect was discovered in the course of clean CHIP16 emulator implementation with Wind River Simics framework, using only wiki specifications.

An excerpt from current Instructions list:

Let us consider a program with CALL and matching RET at the end of called subroutine.

1. During CALL, PC points to currently executed execution, that is, to CALL itself. This value is saved on the stack.
2. Execution goes to the subroutine entry point and proceeds through its body.
3. RET is encountered. It loads PC with a value from stack. But that previously saved value points to CALL itself, not to an instruction following it.
4. CALL gets executed again, resulting in the second transition to the subroutine. An endless loop is thus created.

The problem comes from the fact that CALL should have saved PC+4 on the stack, so that a subsequent instruction is fetched after RET.

My proposed fix to the specifications looks like this (the change is in bold):

Other CALL variants are also affected and should be fixed as well.

Alternatively, PC could have been incremented by 4 at RET, not CALL, with the same net effect. Yet, the latter variant does not align well with CALL-RET semantics found in other CPU arhitectures.

Bitwise NEG operation:

As per the spec., Z and N flags are set respectively when: the result is 0, and bit[15] of the result is set.

Negate (NEG) is defined as the number multiplied by -1, in two's complement representation.