Next Generation Emulation banner
1 - 20 of 173 Posts

·
Sober coder
Joined
·
472 Posts
Discussion Starter · #1 · (Edited)
Read all earlier developments from the first thread from Shendo HERE:
http://forums.ngemu.com/showthread.php?t=138170


-----------------------

Description:
ShendoXT said:
What is Chip16?

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.
Chip16 is also more interesting than Chip8, thanks to a higher resolution, colour display and expanded memory.

Full specification (latest):
http://github.com/tykel/chip16/wiki/Instructions

If you have a suggestion to improve the Chip16 specification, please post it here so it can be discussed. Provide as much detail as you can.

If you have made an emulator, game, or other software regarding Chip16, please post it here with a link. Source code preferred ;)

In the case of Chip16 games/demos: please post a ROM with a header.

Screenshots:
-----------
View attachment 216991 View attachment 216992 View attachment 216993 View attachment 216994 View attachment 216995 View attachment 216996 View attachment 216997 View attachment 216998 View attachment 216999 View attachment 217000 View attachment 217001 View attachment 217002 View attachment 217003




Links:
-----

Program pack (07/16/2012): link
Program pack (03/14/2012): link

Assembler: link

Reference emulator #1 (by refraction): RefChip16
Reference emulator #2 (by me): mash16
Online emulator: Js16
Other emulators (outdated, will not work): cottonCx

Command line image converter: img16
GUI image converter: link

Command line ROM reader/patcher (linux build, source included): View attachment 217495
GUI ROM reader/patcher (windows build): link
 

·
Sober coder
Joined
·
472 Posts
Discussion Starter · #8 · (Edited)
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.

cheers,
Paul
I think this is the way to go. Simple but flexible enough to do something interesting.
The real issue is whether we keep ops SND1..3 :/
 

·
Sober coder
Joined
·
472 Posts
Discussion Starter · #13 ·
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.
 

·
Sober coder
Joined
·
472 Posts
Discussion Starter · #22 ·
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)

Chris2Balls: Keep us posted!
 

·
Sober coder
Joined
·
472 Posts
Discussion Starter · #31 ·
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! :lol:
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.
 

·
Sober coder
Joined
·
472 Posts
Discussion Starter · #35 · (Edited)
I've made a simple example rom with source for people to learn from and build upon.
View attachment 216421
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? :D
 

·
Sober coder
Joined
·
472 Posts
Discussion Starter · #37 · (Edited)
maybe a BBC micro?
Spot on :thumb:

EDIT:
ShendoXT said:
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:
Code:
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:
Code:
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.
 

·
Sober coder
Joined
·
472 Posts
Discussion Starter · #47 ·
That looks great! :thumb: What sound is that at the bottom (pulse wave)?

Also, you speak of a 44100 Hz sample rate. This is just for the WAV files right, I seem to remember variable sample rates being mentioned? Because 44KB for 1 second of sound is not feasible! :dead:

One of your previous posts mentioned a 4-bit ADSR envelope, is that encoded in the PCM, or will it be encoded in the instruction?
 

·
Sober coder
Joined
·
472 Posts
Discussion Starter · #49 ·
eg. a typical ADSR envelope which could modulate a waveform's output amplitude might look like this:

Code:
volume
        1      /\
        |     /  \_______
        |    /           \
        |   /             \
        0    A  D    S    R
I hope this makes sense?
Got that thanks :)

So, for a 1 second sound encoded with my current scheme requires:

44100 x 1 (bytes per sample) x 1 (number of channels), or around 4.4KB.
That's 43 KB no?

We could reduce this by using 22050 sampling rate instead...it is entirely up to us (or the creator of the emulator) as to what sound quality we use ;)
Wait, the sample frequency depends on the game and how it chooses to store its samples, not the emulator, right?
 

·
Sober coder
Joined
·
472 Posts
Discussion Starter · #54 ·
Nice example, suitably retro sounding!
Also, sorry for insisting on this, but would this sound take up 100Hz * 0.310s * 1B = 31B? Or am I not getting this?
Another thing, wouldn't it be better to use sound instructions rather than ports for modulation, for better orthogonality?

Also, for timing, you can currently use VBLNK if you don't mind waiting for multiples of 16ms ;)
If anyone else is interested in a WAIT instruction, please make your voice heard!
 

·
Sober coder
Joined
·
472 Posts
Discussion Starter · #60 ·
I think it looks good. Once there is a consensus I will be able to add it to the next revision of the spec, along with PAL.
Just clarify one thing for me, what is the frequency for? How does it differ from the sample rate?
 

·
Sober coder
Joined
·
472 Posts
Discussion Starter · #62 ·
Ok, understood :thumb:
But that is not an issue for us as we are only playing it in memory and it won't hang around very long.
... I have just realised/remembered, in the current scheme we are just playing notes right? We are not storing PCM data at all. D'oh! What you were saying makes sense now, sorry about that.
I can rephrase my previous question as, how much space will a 1s tune take up (in the Chip16 memory)? I guess if we assume each note is about 200ms, about 5*1B = 5B?


Anyway, I think this sound spec looks quite reasonable. There has been discussion in the thread about how it works, with more links if necessary, so it should be within reach to code it for beginners.
As such, a few more opinions on this would be nice, but after letting it rest a little it should be added.
Pending:
Code:
0D 0X LL HH     SNP HHLL   Play Sound for HHLL miliseconds at the tone specified in address pointed to by Register X (uses current sound generator settings; ADSR, etc.).

0E AD SR VT     SNG AD, VTSR   Sound generator (applies to all sound tones which follow).
                                  A = attack  (0..15)
                                  D = decay   (0..15)
                                  S = sustain (0..15, volume)
                                  R = release (0..15)
                                  V = volume  (0..15)
                                  T = type of sound:
                                     00 = triangle wave
                                     01 = sawtooth wave
                                     02 = pulse wave (is just square for now)
                                     03 = noise
                                     non-valid values default to 0 output

D0 00 LL HH    PAL HHLL   Load the palette starting at address HHLL, 48 bytes; used for all drawing since last vblank.

D1 0x 00 00    PAL Rx   Load the palette starting at the address pointed to by Register X, 48 bytes; used for all drawing since last vblank.
 

·
Sober coder
Joined
·
472 Posts
Discussion Starter · #64 ·
It probably doesn't matter that much as it's the first instruction with an immediate field larger than 16 bits. It makes more sense to keep ADSR stuff together, as you pointed out, although remember that numbers are stored in little-endian format - so it may make more sense for the instruction to be encoded as
Code:
0E SR AD VT     SNG ADSR, VT   Sound generator [...]
for consistency.
 

·
Sober coder
Joined
·
472 Posts
Discussion Starter · #69 ·
Thanks Paul! I actually used those as references to compare results with my palette. Dawnbringer's palette is the better of the two, overall. ;)
However, if the palette switch command is put into the next C16 update, it means I could potentially use all three at different times, which could be quite interesting... it could encourage pixel artists to work on a specific palette for a specific idea, which means it could give a visual identity to a game, or at least an atmosphere of a level. I'll be looking forward to that. :)
It is being added ;)
 

·
Sober coder
Joined
·
472 Posts
Discussion Starter · #71 ·
The beginnings of something:
View attachment 216554
Straightforward tilemapping for now, in a hacked CottonCx to use Chris's palette.
A single screen takes 300B just for tiles, so for a full-fledged game some form of compression is necessary, which I have kind of worked out, so hopefully we should have a little game when I'm less busy :)
 

·
Sober coder
Joined
·
472 Posts
Discussion Starter · #73 ·
what if you cheated and ran the game in a smaller window? so it took up say, half the screen (like old spectrum games used to do :p)
And have a HUD filling half the screen? Brilliant! :lol:
 

·
Sober coder
Joined
·
472 Posts
Discussion Starter · #77 ·
Two quick questions if I may? How are you storing the tiles in the game (without compression of course), and how do you get 300B for the screen of tiles?

Just curious :)
Well, I didn't mention it, but I stored 80 16*16px tiles, which weigh in at 10240 bytes as a one-off cost for graphics data. Then the tilemap is simply an array of bytes, which are tile indexes. You can fit 20*15 tiles on a screen, hence 20*15*1 = 300 bytes / screen, as game data.
Hi, all

Does anyone have a normal chip16 debbuger? I need it to improve my pascal to chip16 translator (compiler). I need options for viewing opcodes, memory and registers in trace mode. It would be great if someone has built a debugger into emulator.
Hi Tronix, there is a debugger in Shendo's emu, NetChip16; unfortunately it is not quite up to date regarding the instruction set I think... Someone else was making a debugger (the one with Youtube videos), I'm not quite sure what happened to that.
 

·
Sober coder
Joined
·
472 Posts
Discussion Starter · #83 ·
Ok, here we go: spec v1.0 is out. Why 1.0? Because I feel Chip16 has reached a stage where it can be used for non-trivial things now.
See OP for full spec.

New instructions:
Code:
0D 0X LL HH     SNP Rx, HHLL   Play Sound for HHLL miliseconds at the tone specified in address pointed to by Register X (uses current sound generator settings; ADSR, etc.).

0E AD SR VT     SNG AD, VTSR   Sound generator (applies to all sound tones which follow).
                                  A = attack  (0..15)
                                  D = decay   (0..15)
                                  S = sustain (0..15, volume)
                                  R = release (0..15)
                                  V = volume  (0..15)
                                  T = type of sound:
                                     00 = triangle wave
                                     01 = sawtooth wave
                                     02 = pulse wave (is just square for now)
                                     03 = noise
                                     non-valid values default to 0 output

D0 00 LL HH    PAL HHLL   Load the palette starting at address HHLL, 16*3 bytes, RGB format; used for all drawing since last vblank.

D1 0x 00 00    PAL Rx   Load the palette starting at the address pointed to by Register X, 16*3 bytes, RGB format; used for all drawing since last vblank.
Gentlemen, please update your emulators! I will be updating tchip16 ASAP.
 

·
Sober coder
Joined
·
472 Posts
Discussion Starter · #85 ·
Very nice, thank you very much!
Could you possibly make a couple more sounds/tunes just to see what is possible with this sound generator?
 

·
Sober coder
Joined
·
472 Posts
Discussion Starter · #88 · (Edited)
Very nice, thank you very much!
I was going to suggest making some reference sounds to calibrate people's sound emu to, but (assuming this works correctly) we don't seem to need that anymore!

Oh, and just a question, in your program there are separate note and octave types... how do these relate to the "tone" specified in the new spec?
 
1 - 20 of 173 Posts
Top