[psymps]

Sorry for the late reply, i dunno why it would have changed, here's another link just in case Chip16 program pack 09.04.2018.zip

Thank you.

I also had a further query regarding the status of the Chip16 project itself. When will the next version of the specification (1.4) be released?

 

[refraction]

I don't know, everybody who was working on it has moved on, so at this point, never.

 

[tykel]

The project is essentially frozen/dead at this point, yes.

 

[tykel]

Having said that, I sometimes still privately make some little demos and such for fun. I've attached a few here: tykel-chip16.zip.

I have also mulled adding a 1.4 or maybe a 2.0 spec version, with the following additions:

• add a new SNC x instruction (set current audio channel to x, 0..2). This would allow multi-channel audio at last.
• specify that I/O port 0xFF4-5 would be updated with the latest pressed keyboard scancode after every VBLANK event.
• clarify the representation of values in registers and memory. I.e. depending on context, they are interpreted as either 16-bit two's complement signed integers (e.g. for math operations), or 16-bit unsigned integers (e.g. for addresses).

 

[overclocked]

First Hardware Chip16!

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

I will be trying to write 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 (AE).

AE extender has:

• 12-bit VGA output
• PS/2 port
• Atari/Amiga/C64 joystick port
• SD-Card slot
• Stereo Sound output
• MIDI-input port

Original Xilinx board has:

• 3-bit VGA output
• PS/2 port
• 2 serial ports
• Ethernet port
• USB-slave port
• Simple JTAG-port
• Switches, LED's, Rotary knob, 20x2 LED-char-display
• Lots of extension pins.

This is an 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. It hasn't got the total memory needed Framebuffer+InternalMem = About 104KB! But about 81KB will have to be enough for now. It will start as 38KB Framebuffer and the rest as internal mem (About 43KB). Current frame buffer implementation is already Dual-Port so it already supports being updated Live while showing. But there is nothing to update it 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. Project will be added to github when being somewhat useful. First simple Live example picture, not that fantastic maybe.. well you have to be impressed easily to enjoy!

 

[overclocked]

And I'll keep posting, at least for my own sake if nobody else is listening! Now using the official Chip16 palette.
Output is only 12-bit so each color is represented by only 4-bit each for R,G,B. Still pretty close.

Also, this has NOT been done using my advanced tool chain for optimal Chip16 pictures, so the quality is lower.

"Just" did this instead:
1) Open file in Paint.NET
2) Resize picture to 240x240
3) Change canvas size to expand to 320x240
3) Create the Chip16 Palette in a Paint.Net compatible txt-file
4) Installing and using the Plug-in "Recolor Using Palette" which does a straight pixel-by-pixel conversion (no Dither at all) using the currently selected Palette (Chip16).
5) Save this file as a 24-bit BMP file. The file now actually only contains Chip16 compatible colors (should only be 16 different in total)
6) Run my own BmpToBin tool (github) to convert BMP file to BIN-file which suits the Chip16 platform. A new version is used locally to support: Greyscale pictures, Chip16DefaultPalette.
7) Run the BinToCoe tool (will also be added to github) which takes the above BIN-file and converts it to a format suitable for Xilinx FPGA internal memory (BRAM) initialization.

 

[overclocked]

Small update here but a very good one: blitter is now working! I think you can figure out which small part of the screen that has been copied from SystemMemory to Framebuffer by the Blitter!
For now Blitter is only implemented with a 25Mhz clock. To adhere to the strict Chip16 spec 19'2GB/s is needed (that is the same a copy the whole screen within [email protected]) but that is not possible here. I can probably increase this to atleast 100Mhz if needed. Next step will be to try and setup a full state machine to be able to set all registers and then perform several Blitter instructions.

 

[overclocked]

New update, blitter is currently clocked at 100Mhz as envisioned, so 4X faster than before which is good.
Also transparency is taken into account when blitting. Currently hardwired to color 0, but I will add a setting later.
A simple example picture shown below. Still an extra black tail at the start of blit which should not be there.

@100Mhz and 16-bit wide, a 32x32 sprite takes about: 8.03us-0.34us = 7,69us

Overhead of filling the screen with 32x32 (like a full scrolling) would be approx:
10x8 = 80 sprites total => 80*7,69us = 615,2us
1/60s is the full frametime => (1/60)/0,6152 => approx 37 times/frame =>1/37 = 2,7% of frametime is spent
This is the same as about 450 clock cycles @ 1Mhz