Chip16 Official thread (Development/Suggestions)

[paul_nicholls]

I only just noticed this, but aren't some of these op codes a problem?

B0 0X 0N 00	SHL RX, N		Logical    Shift value in register X left N times.  Affects [z,n]
B1 0X 0N 00	SHR RX, N		Logical    Shift value in register X right N times. Affects [z,n]
B0 0X 0N 00	SAL RX, N		Arithmetic Shift value in register X left N times.  Affects [z,n] (same as SHL)
B2 0X 0N 00	SAR RX, N		Arithmetic Shift value in register X right N times. Affects [z,n]
B3 YX 00 00	SHL RX, RY		Logical    Shift value in register X left by the value in (RY & 0xf).  Affects [z,n]
B4 YX 00 00	SHR RX, RY		Logical    Shift value in register X right by the value in (RY & 0xf). Affects [z,n]
B3 YX 00 00	SAL RX, RY		Arithmetic Shift value in register X left by the value in (RY & 0xf).  Affects [z,n] (same as SHL)
B5 YX 00 00	SAR RX, RY		Arithmetic Shift value in register X right by the value in (RY & 0xf). Affects [z,n]

Unless it has changed and not been updated I can see these duplicates:

B0 0X 0N 00	SHL RX, N		Logical    Shift value in register X left N times.  Affects [z,n]
B0 0X 0N 00	SAL RX, N		Arithmetic Shift value in register X left N times.  Affects [z,n] (same as SHL)

and these ones:

B3 YX 00 00	SHL RX, RY		Logical    Shift value in register X left by the value in (RY & 0xf).  Affects [z,n]
B3 YX 00 00	SAL RX, RY		Arithmetic Shift value in register X left by the value in (RY & 0xf).  Affects [z,n] (same as SHL)

[tykel]

Originally Posted by paul_nicholls

I only just noticed this, but aren't some of these op codes a problem?

B0 0X 0N 00	SHL RX, N		Logical    Shift value in register X left N times.  Affects [z,n]
B1 0X 0N 00	SHR RX, N		Logical    Shift value in register X right N times. Affects [z,n]
B0 0X 0N 00	SAL RX, N		Arithmetic Shift value in register X left N times.  Affects [z,n] (same as SHL)
B2 0X 0N 00	SAR RX, N		Arithmetic Shift value in register X right N times. Affects [z,n]
B3 YX 00 00	SHL RX, RY		Logical    Shift value in register X left by the value in (RY & 0xf).  Affects [z,n]
B4 YX 00 00	SHR RX, RY		Logical    Shift value in register X right by the value in (RY & 0xf). Affects [z,n]
B3 YX 00 00	SAL RX, RY		Arithmetic Shift value in register X left by the value in (RY & 0xf).  Affects [z,n] (same as SHL)
B5 YX 00 00	SAR RX, RY		Arithmetic Shift value in register X right by the value in (RY & 0xf). Affects [z,n]

Unless it has changed and not been updated I can see these duplicates:

B0 0X 0N 00	SHL RX, N		Logical    Shift value in register X left N times.  Affects [z,n]
B0 0X 0N 00	SAL RX, N		Arithmetic Shift value in register X left N times.  Affects [z,n] (same as SHL)

and these ones:

B3 YX 00 00	SHL RX, RY		Logical    Shift value in register X left by the value in (RY & 0xf).  Affects [z,n]
B3 YX 00 00	SAL RX, RY		Arithmetic Shift value in register X left by the value in (RY & 0xf).  Affects [z,n] (same as SHL)

I thought the same at first.
In fact, they are just equivalent operations, and the mnemonics translate to the same opcodes.
The reason for this is that right-shifting can extend the sign bit (SAR) or not (SHR); however left-shifting can not extend the sign bit, SAL and SHL are there for consistency in the instruction set. (In the same way some condition codes in the Sign Flag have multiple aliases)

Chris2Balls: Keep us posted!

__________________

tchip16 (chip16 assembler) Js16 (browser chip16 emulator)
mash16 (chip16 emulator) img16 (chip16 sprite converter)
______________________________________

Desktop: i5 750 @ 3.6 Ghz, 4GB ram, GTX 570 OC | Windows 7 Pro 64
Laptop: (Thinkpad) i5 430M, 4GB ram, Intel IGP | Arch Linux, Windows 7 Pro 64

[paul_nicholls]

Ok, thanks for the info tykel

In my mind, I was expecting them to do different things...

[Celestion]

Hi,

I wanted to point out an issue with the RND instruction emulated in C or C++ with the rand() function.
The problem appears in cottonvibes's emulator playing starfield and probably in other emulators written in C.

This seems to come from the rand() function which generate random integers between 0 and RAND_MAX (which is generally 32767) and starfield asks for full 16-bits range.
That results in a no fullscreen starfield.

Moreover, if you do :

R[x] = rand()%(HHLL + 1)

the bottom right hand corner isn't drawn.
Doing

R[x] = rand()&(HHLL + 1)

solve this issue.

As a beginner maybe i'm mistaking though.

Attached Images

	cottonChip16.PNG (20.8 KB, 18 views)
	QtChip16.PNG (21.7 KB, 18 views)

---

Last edited by Celestion; November 9th, 2011 at 20:46..

[refraction]

Maze is best to show this, I did something like

V =(rand()%HHLL+1)-1

If you don't do the minus 1 it can go out of range requested

Update:

This is what i do exactly

randval = rand() % ((unsigned short)IMMEDIATE+1); //Apparently if IMMEDIATE is 1, it always generates 0 O_o
//Need to make sure result isnt 0 and is in range.
if(randval > IMMEDIATE) randval -= 1;
REG_X = randval;

__________________

http://www.pcsx2.net
Intel i7 920 @ 3.4Ghz, POV GTX 570 1.3Gb, 1.8Tb HD space, 6Gb OCZ Reaper PC3-14400 Triple Channel
Dont PM me for help, use the forums, thats what its for!

My Chip16 Emulator RefChip16 http://code.google.com/p/refchip16/

---

Last edited by refraction; November 10th, 2011 at 12:58..

[paul_nicholls]

Hey all,
I am thinking of trying to make my own emulator, and I am unsure as how to do 'correct' timing in the CPU. The spec says that the CPU is 1MHz, which is 1uS per CPU update.

First, this seems much quicker than I might get a software timer to give me a time between updates, so I am unsure how I am going to get an 'accurate' count (ignoring Windows not being a true multi-tasking OS).

Is QueryPerformanceCounter going to have enough resolution for this? GetTickCount only supplies around 1mS of resolution...

If I can get ok timing, then I see I can do the CPU updates one of two ways:

1) Decode and execute one instruction per CPU tick, and keep track of when to do the next instruction update (global time variable)

2) Decode and execute N instructions per update, and then wait the remainder of the time left in a N * 1uS update chunk before doing the next bunch of updates.

Any ideas?

Am I being too worried about this part of the machine?

cheers,
Paul

---

Last edited by paul_nicholls; November 10th, 2011 at 05:12..

[cottonvibes]

Originally Posted by paul_nicholls

Hi cottonvibes, I did post some of my sound thoughts in the previous thread here:

http://forums.ngemu.com/showpost.php...&postcount=626
http://forums.ngemu.com/showpost.php...&postcount=627
http://forums.ngemu.com/showpost.php...&postcount=628
http://forums.ngemu.com/showpost.php...&postcount=629

I don't know if you saw those?

Maybe they are too complex, and can be modified? I don't know...I did like them myself

What do you think?

cheers,
Paul

i do like the direction your sound ideas take over the simple sine-wave idea. although maybe its better to use sound-ports for the values instead of encoding them as part of the instruction or from registers, this allows the program to dynamically alter the sound properties instead of hard coding them as an instruction. to program the APU you just write to the mem-mapped ports, which are APU-registers.

something we might need though are sound interrupts or an APU state register.
cuz if you're playing a note, how does the game know that its done in order to play another note?
it needs to be able to detect when the note is finished so it can play the next note.

__________________

"It was, of course, a lie what you read about my religious convictions, a lie which is being systematically repeated. I do not believe in a personal God and I have never denied this but have expressed it clearly. If something is in me which can be called religious then it is the unbounded admiration for the structure of the world so far as our science can reveal it." - Albert Einstein
check out my blog

[cottonvibes]

Originally Posted by paul_nicholls

Hey all,
I am thinking of trying to make my own emulator, and I am unsure as how to do 'correct' timing in the CPU. The spec says that the CPU is 1MHz, which is 1uS per CPU update.

First, this seems much quicker than I might get a software timer to give me a time between updates, so I am unsure how I am going to get an 'accurate' count (ignoring Windows not being a true multi-tasking OS).

Is QueryPerformanceCounter going to have enough resolution for this? GetTickCount only supplies around 1mS of resolution...

If I can get ok timing, then I see I can do the CPU updates one of two ways:

1) Decode and execute one instruction per CPU tick, and keep track of when to do the next instruction update (global time variable)

2) Decode and execute N instructions per update, and then wait the remainder of the time left in a N * 1uS update chunk before doing the next bunch of updates.

Any ideas?

Am I being too worried about this part of the machine?

cheers,
Paul

i used QueryPerformanceCounter(), and the direction you want to take is the second one.
no-emulator times each instruction individually, they do N instruction chunks, then limit the frame rate by waiting/sleeping for the remainder of the time if it finished early.
N = instructions per frame (which is 1,000,000 / 60 since chip16 has a frame-rate of 60fps).

__________________

"It was, of course, a lie what you read about my religious convictions, a lie which is being systematically repeated. I do not believe in a personal God and I have never denied this but have expressed it clearly. If something is in me which can be called religious then it is the unbounded admiration for the structure of the world so far as our science can reveal it." - Albert Einstein
check out my blog

[paul_nicholls]

Originally Posted by cottonvibes

i do like the direction your sound ideas take over the simple sine-wave idea. although maybe its better to use sound-ports for the values instead of encoding them as part of the instruction or from registers, this allows the program to dynamically alter the sound properties instead of hard coding them as an instruction. to program the APU you just write to the mem-mapped ports, which are APU-registers.

something we might need though are sound interrupts or an APU state register.
cuz if you're playing a note, how does the game know that its done in order to play another note?
it needs to be able to detect when the note is finished so it can play the next note.

Glad you like my sound ideas
Hmm..having sound ports (memory mapped) is a very good idea! We could do something similar to the c64, but without filtering and all the other baggage; ie. only worry about the simpler parts like ADSR, volume, and wave types.

With detecting the end of a note, perhaps we could have a bit (per voice) that is cleared (or set) when a voice finished playing...similar to the vblank?

PS .I am actually just about to try creating programming a class to create some C64-like sounds using similar techniques to the SID (phase-accumulating oscillator + envelope generator).

If I can get some ok results, I will share the code.

cheers,
Paul

[paul_nicholls]

Originally Posted by cottonvibes

i used QueryPerformanceCounter(), and the direction you want to take is the second one.
no-emulator times each instruction individually, they do N instruction chunks, then limit the frame rate by waiting/sleeping for the remainder of the time if it finished early.
N = instructions per frame (which is 1,000,000 / 60 since chip16 has a frame-rate of 60fps).

Cool! Thanks mate

cheers,
Paul

[tykel]

Originally Posted by cottonvibes

i do like the direction your sound ideas take over the simple sine-wave idea. although maybe its better to use sound-ports for the values instead of encoding them as part of the instruction or from registers, this allows the program to dynamically alter the sound properties instead of hard coding them as an instruction. to program the APU you just write to the mem-mapped ports, which are APU-registers.

something we might need though are sound interrupts or an APU state register.
cuz if you're playing a note, how does the game know that its done in order to play another note?
it needs to be able to detect when the note is finished so it can play the next note.

I think the sound instructions should stay as similar to DRW as possible, for consistency.
So maybe, in line with this, have instructions similar in function to BGC and SPR, for sound properties (see paul_nicholls' post) -- and one or two SND opcodes for playing the sound.

I like the idea of sound interrupts!
Two possible issues: won't this make interrupts for other things (drawing, user-defined) desirable aswell? And how much does it complicate the implementation?

And since you talk of ports... An idea I have been toying around with is defining some read-write general purpose memory ports (say 0xFFF4 - 0xFFFF) which would be updated every VBLNK; so the value in the ports would be sent out, and a new value would replace it from input, for example. Or otherwise have a set of read-only, and a set write-only. One of the ports could be PFLAGS (port flags), which masks whether the ports have been written to or not. This could be used by the system to only send different values.
These serial ports could be used for netplay, or interacting with the outside.
Just an idea, anyway

And I added you to the contributors' list, paul_nicholls.

__________________

tchip16 (chip16 assembler) Js16 (browser chip16 emulator)
mash16 (chip16 emulator) img16 (chip16 sprite converter)
______________________________________

Desktop: i5 750 @ 3.6 Ghz, 4GB ram, GTX 570 OC | Windows 7 Pro 64
Laptop: (Thinkpad) i5 430M, 4GB ram, Intel IGP | Arch Linux, Windows 7 Pro 64

[refraction]

Originally Posted by paul_nicholls

Hey all,
I am thinking of trying to make my own emulator, and I am unsure as how to do 'correct' timing in the CPU. The spec says that the CPU is 1MHz, which is 1uS per CPU update.

First, this seems much quicker than I might get a software timer to give me a time between updates, so I am unsure how I am going to get an 'accurate' count (ignoring Windows not being a true multi-tasking OS).

I've kinda done it a cheaty way in my emulator, but it works.

Every cycle i add 1 to "cycles" variable, but i also have another variable called "nextvsync" and every time cycles == nextvsync i add (1000000 / 60) on to nextvsync. It seems to work ok :P

Then to stop it going to fast, im actually using Direct3D, so i have told it to enable vertical syncing.

This would be ok on most systems as many use 60hz for their screen these days, but of course once you get someone whos got a 120hz monitor, id be screwed xD so in the end ill probably have to resort to QueryPerformanceCounter()

__________________

http://www.pcsx2.net
Intel i7 920 @ 3.4Ghz, POV GTX 570 1.3Gb, 1.8Tb HD space, 6Gb OCZ Reaper PC3-14400 Triple Channel
Dont PM me for help, use the forums, thats what its for!

My Chip16 Emulator RefChip16 http://code.google.com/p/refchip16/

[paul_nicholls]

Originally Posted by tykel

And I added you to the contributors' list, paul_nicholls.

Neat! Thanks tykel

[paul_nicholls]

Originally Posted by refraction

I've kinda done it a cheaty way in my emulator, but it works.

Every cycle i add 1 to "cycles" variable, but i also have another variable called "nextvsync" and every time cycles == nextvsync i add (1000000 / 60) on to nextvsync. It seems to work ok :P

Then to stop it going to fast, im actually using Direct3D, so i have told it to enable vertical syncing.

This would be ok on most systems as many use 60hz for their screen these days, but of course once you get someone whos got a 120hz monitor, id be screwed xD so in the end ill probably have to resort to QueryPerformanceCounter()

Thanks for the tips refraction
hmm...thinking about it, I might try something like this:

const
  render_fps   = 60;
  cpu_update   = 1e-6;
  render_ticks = (1/render_fps) / cpu_update;

procedure TChip16.DoUpdateStep;
begin
  // read and process op-code
  UpdateCPU();

  // see if time to do a render update
  // sets VSYNC bit to true when done.
  FRenderTick := FRenderTick + 1;
  if FRenderTick >= render_ticks then
  begin
    FRenderTick := FRenderTick - render_ticks;

    RenderFrame();
  end;
end;

procedure TChip16.Update(aFrameTime: Single);
begin
  FUpdateTime := FUpdateTime + aFrameTime;

  // do as many updates as possible
  while FUpdateTime >= cpu_update do
  begin
    DoUpdateStep();

    FUpdateTime := FUpdateTime - cpu_update;
  end;
end;

This just might work a treat, and it shouldn't matter what frame rate it is running on, or what VSync (if any)...

I will have to try it

cheers,
Paul

---

Last edited by paul_nicholls; November 10th, 2011 at 11:36..

[tykel]

I've made a simple example rom with source for people to learn from and build upon.
c16-textdisp.png
Press A to print text, it will print on a new line every time, and go to a new screen when it reaches the bottom.
I have included the latest tchip16 if you haven't got it, it has some nice new features!

Also, can anyone guess what classic computer the font is taken from?

Attached Files

TextExample.zip (41.7 KB, 14 views)

__________________

tchip16 (chip16 assembler) Js16 (browser chip16 emulator)
mash16 (chip16 emulator) img16 (chip16 sprite converter)
______________________________________

Desktop: i5 750 @ 3.6 Ghz, 4GB ram, GTX 570 OC | Windows 7 Pro 64
Laptop: (Thinkpad) i5 430M, 4GB ram, Intel IGP | Arch Linux, Windows 7 Pro 64

---

Last edited by tykel; November 13th, 2011 at 15:40..

[paul_nicholls]

Not sure on the font, I am sure it isn't from the C64...maybe a BBC micro?

[tykel]

Originally Posted by paul_nicholls

maybe a BBC micro?

Spot on

EDIT:

Originally Posted by ShendoXT

Maybe we should add a LOAD PAL opcode after all...

I totally agree. It allows for nice changes like Chris's wizardry, without affecting any existing games.
It could also be used for in-game palette swapping, to save on the amount of graphics required!
So, I will be adding the following opcode in the next spec revision, unless there are any reservations:

0F 00 LL HH    PAL HHLL    Loads the palette from memory at address HHLL. Colors are stored as 3 byte RGB triples.

You read 48 bytes from HHLL. Also, calling PAL means all the graphics now use the palette.
So no cheating like on the C64/VIC

And let's get a consensus on the sound! I think we agree on the format of the new SND instruction:

0D 0X LL HH    SNP HHLL    Play PCM Sound for HHLL miliseconds at the tone specified in address pointed to by Register X

This sound data (PCM?), how big should it be? 4 or 8 bytes I would imagine?
We need to define the other instructions, the modifiers.

__________________

tchip16 (chip16 assembler) Js16 (browser chip16 emulator)
mash16 (chip16 emulator) img16 (chip16 sprite converter)
______________________________________

Desktop: i5 750 @ 3.6 Ghz, 4GB ram, GTX 570 OC | Windows 7 Pro 64
Laptop: (Thinkpad) i5 430M, 4GB ram, Intel IGP | Arch Linux, Windows 7 Pro 64

---

Last edited by tykel; November 14th, 2011 at 10:34..

[paul_nicholls]

I would imagine that the PCB should be 8-Bit (Signed?)...4-Bit would be waaayy too yuck

As to the sound modifiers, how about something like this (memory-mapped like the C64)?

0x0000 - Start of ROM.

0xFDED - Sound Control Register         *
0xFDEE - Sound Attack/Decay Register    *
0xFDEF - Sound Sustain/Release Register *

0xFDF0 - Start of stack (512 bytes).
0xFFF0 - IO ports.

* = see details below

Control Register Bits
---------------------

D7 D6 D5 D4 D3 D2 D1 D0            W = 2 bit waveform
x  x  x  x  x  x  W  W               0x00 = triangle
                                     0x01 = sawtooth
                                     0x02 = square
                                     0x03 = noise

Attack/Decay Register Bits
--------------------------

D7 D6 D5 D4 D3 D2 D1 D0            A = attack nibble (0-15, time value)
A  A  A  A  D  D  D  D             D = decay nibble  (0..15, time value)

Sustain/Release Register Bits
-----------------------------

D7 D6 D5 D4 D3 D2 D1 D0            S = sustain nibble (0..15, volume)
S  S  S  S  R  R  R  R             R = release nibble (0..15, time value)

ADSR Envelope Values
VALUE  ATTACK RATE DECAY RATE RELEASE RATE
0      2 ms        6 ms       6 ms
1      8 ms        24 ms      24 ms
2      16 ms       48 ms      48 ms
3      24 ms       72 ms      72 ms
4      38 ms       114 ms     114 ms
5      56 ms       168 ms     168 ms
6      68 ms       204 ms     204 ms
7      80 ms       240 ms     240 ms
8      100 ms      .3 sec     .3 sec
9      .25 sec     .75 sec    .75 sec
10     .5 sec      1.5 sec    1.5 sec
11     .8 sec      2.4 sec    2.4 sec
12     1 sec       3 sec      3 sec
13     3 sec       9 sec      9 sec
14     5 sec       15 sec     15 sec
15     8 sec       24 sec     24 sec

I am working on some code to generate the waveforms and ADSR stuff that I will share when done...

cheers,
Paul

---

Last edited by paul_nicholls; November 15th, 2011 at 20:14..

[Prads]

Originally Posted by refraction

This would be ok on most systems as many use 60hz for their screen these days, but of course once you get someone whos got a 120hz monitor, id be screwed xD so in the end ill probably have to resort to QueryPerformanceCounter()

No need to use high resolution timer, you can just use timeGetTime() and then render a frame every 16 milliseconds to get 60Hz (62.5 to be exact).

Here's how my frame timer class looks like:

FrameTimer::FrameTimer() {
	TIMECAPS timeCaps;
	//Find out the maximum resolution possible in the hardware
	if (timeGetDevCaps(&timeCaps, sizeof(timeCaps)) == MMSYSERR_NOERROR)
		maxResolution = timeCaps.wPeriodMin;
	else
		maxResolution = 1;	//Just trying our luck with 1

	timeBeginPeriod(maxResolution);
	previousTime = timeGetTime();
}

FrameTimer::~FrameTimer() { timeEndPeriod(maxResolution); }

//Returns true if difference between previous time and current time is more or equal to 16 milliseconds
bool FrameTimer::renderTime() {
	currentTime = timeGetTime();
	if (currentTime - previousTime >= 16 || currentTime < previousTime) {
		previousTime = currentTime;
		return true;
	}
	return false;
}

__________________
My Programming Projects: www.pradsprojects.com

[paul_nicholls]

Thanks for the info Prads
Oh, and your website looks interesting...some cool projects there

cheers,
Paul