Chip16 is intended as a fairly easy to implement, well documented and community supported system which would aid beginners when writing their emulator.
This would solve many CHIP8 inconsistencies as well as undocumented features sometimes (possibly) added by interpreter authors themselves.
CHIP16 has a regular D-PAD controller with 4 buttons in contrast to CHIP8's somewhat messy 16 keys keyboard.
Wow that was unexpected! Big shame he doesn't want to continue thanks for all your work shendo, hopefully those of us who contribute will make you proud
As this is supposed to be somebodies first emulator (a bit more in depth than chip8 anyway) so we dont want anything too complex for sound. A simple tone with pitch/length control is more than enough imo.
As this is supposed to be somebodies first emulator (a bit more in depth than chip8 anyway) so we dont want anything too complex for sound. A simple tone with pitch/length control is more than enough imo.
So are we sticking with these, or making some changes?
Code:
09 00 00 00 SND0 Stop playing sounds.
0A 00 LL HH SND1 HHLL Play 500Hz tone for HHLL miliseconds.
0B 00 LL HH SND2 HHLL Play 1000Hz tone for HHLL miliseconds.
0C 00 LL HH SND3 HHLL Play 1500Hz tone for HHLL miliseconds.
If someone can already make an emulator that can play 3 different tones (the three existing instructions), why couldn't we change it so there is only one sound instruction instead of 3 with variable tone as presented in the other thread by refraction?
Code:
0D 0X LL HH SNP Play PCM Sound for HHLL miliseconds at the tone specified in
address pointed to by Register X
This wouldn't make the emulator any harder to build would it? A tone is a tone....in this case it would be variable instead of fixed.
So are we sticking with these, or making some changes?
Code:
09 00 00 00 SND0 Stop playing sounds.
0A 00 LL HH SND1 HHLL Play 500Hz tone for HHLL miliseconds.
0B 00 LL HH SND2 HHLL Play 1000Hz tone for HHLL miliseconds.
0C 00 LL HH SND3 HHLL Play 1500Hz tone for HHLL miliseconds.
If someone can already make an emulator that can play 3 different tones (the three existing instructions), why couldn't we change it so there is only one sound instruction instead of 3 with variable tone as presented in the other thread by refraction?
Code:
0D 0X LL HH SNP Play PCM Sound for HHLL miliseconds at the tone specified in
address pointed to by Register X
This wouldn't make the emulator any harder to build would it? A tone is a tone....in this case it would be variable instead of fixed.
I had a look on my hd quickly, I reckon there are about 6-7 ROMs that use sound, and only one or two I don't have source code to. So recompiling with a new instruction would be easy, and hex-editing is a possibility for the remaining one or two.
09 00 00 00 SND0 Stop playing sounds.
0A 00 LL HH SND1 HHLL Play 500Hz tone for HHLL miliseconds.
0B 00 LL HH SND2 HHLL Play 1000Hz tone for HHLL miliseconds.
0C 00 LL HH SND3 HHLL Play 1500Hz tone for HHLL miliseconds.
...
Code:
0D 0X LL HH SNP Play PCM Sound for HHLL miliseconds at the tone specified in
address pointed to by Register X
these instructions don't make much sense, since they don't talk about what type of wave the sound is.
we can either keep sound generation really primitive, or we can make it a more simplified version of what consoles have.
if we want good sounding games, we obviously don't want primitive sound. but at the same time, how many of us are going to code a chip16 game with cool music?
someone should read up on how the old-gen systems do their sound, and propose a simplified version (they tended to over-complicate things due to hw restrictions).
The intention was so you have more choice of tones for movement, death noses or maybe a short ditty. Not expecting any maestros here. And sound wave tone is fine imo
The intention was so you have more choice of tones for movement, death noses or maybe a short ditty. Not expecting any maestros here. And sound wave tone is fine imo
ok so the palette is almost ready.
i'm tweaking v7 of the palette, consider pure white as a transparent colour.
the final touches will be creating pixel art with it, and not just converting existing art.
I only just noticed this, but aren't some of these op codes a problem?
Code:
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:
Code:
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:
Code:
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 only just noticed this, but aren't some of these op codes a problem?
Code:
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:
Code:
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:
Code:
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)
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.
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
//Need to make sure result isnt 0 and is in range.
if(randval > IMMEDIATE) randval -= 1;
REG_X = randval;
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).
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
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Related Threads
?
?
?
?
?
Next Generation Emulation
2.2M posts
459.8K members
Since 2001
A forum community dedicated to all emulation enthusiasts. Come Join discussion on all platforms from Nintendo, Microsoft Xbox, Sony Playstation, to PC. Coding, tips, builds, specs, tricks and more.