Jun 8

Early Specifications: (6th of August Update)

2,019 views42 comments

Edited: Aug 7

Alright, this is a very preliminary specification of what the C256 will be:
(Always Subject To Change)
/***************************************************************/
CPU
65C816 @ 14Mhz (working in 16Bits Expended Mode)
/***************************************************************/
Memory (Updated)
Total of 8Meg of DRAM in the system. (Again, the cost of Dynamic versus Static prevailed). You got to love the fact that you can buy 1 single piece of silicon for $2.50 that has 8Meg compared to $50.00 for Static for half the memory space. Would you have been willing to pay $45.00 dollars more for half the amount of memory?

/***************************************************************/
Video (Updated)
Graphic Chip - Code Name: VICKY
On top of being the graphic chip, VICKY will be the memory controller as well as the DMA controller and will have an interface with the Super IO chip. Which means that the data coming from Floppy for example and/or the Serial ports will be transfered directly into the memory without the need of the CPU.

Standard Graphic (bit map) Resolution 640 x 480 @ 60FPS 256Colors and 800 x 600 @ 256 Colors
 out of a 24Bits Palette, DVI (Digital & Analog) Output.

Text Modes: (Preliminary)
Multi-Font Support (PETSCII, ASCII, etc...) 8x8 and 8x16. Monochrome (16 Colors FONT/ 16 Colors Background) Special Character supports. (PS2 Keyboard characters & C64 Keyboard characters support).
Multi Color FONT (256 Colors, 1 byte per pixel) for gaming mostly since the system doesn't store those.

Sprites: (Preliminary)
12x (32x32) 256 Colors (1 Byte per pixel)

Bitmap: (Preliminary)
640x480 or 800x600 @ 256 Colors (1 Byte Per pixel) (2 Layers) (Could be used for Double buffering)

2D Game Engine: (Preliminary)
Fully DMA Data transfer (Blitter) 
Layering System (7 Layers)
Inter-layer Collision Detection system with Interrupt.
Example:
1- Sprites (Front of Screen)
2- Multi Color FONT Layer 0 with or without Sprites
3- Multi Color FONT Layer 1 with or without Sprites
4- Multi Color FONT Layer 2 with or without Sprites
5- Multi Color FONT Layer 3 with or without Sprites
6- Bitmap 1 or without Sprites
7- Bitmap 0 or without Sprites (back of Screen)

Etc...
(More details to come, will be detailed in the VICKY user manual.

/***************************************************************/
Sound (Updated)
Sound Controller Chip (local DMA) and Interrupt Controller - Code Name: BEATRIX

Stereo Output on RCA Jack with frontal Headphone Jack with volume.
2x 6581 Chip + 2x YM3812 Chip , Total of 12 Voices for each Channels.
(Early Adopter will have real SID chips, later on because of shortage, other solution will have to be devised)

Midi In / DIN Connector
Midi Out / DIN Connector

Beatrix is essentially a sequencer that will take care of feeding the data to the right chip at the right time. Beatrix has the independent control of all the Audio Chips and will be able to perform a sync write to all the chips at the same time. Vicky's DMA controller will make sure that Beatrix never runs out of Data.

/***************************************************************/
System
System Controller Chip with INT Controller / Timer  - Code Name: GAVIN
2x 6522 For Joystick and Old Keyboard Support connector
2x RS-232 Port, internal 10 Pin Headers (Super IO)
1x EPP Parallel Port (Super IO)
1x CBM 5 Pins DIN Serial port for external Floppy connectivity (1541/1571/1581)
1x Internal 3.5" Floppy with DMA Support. CBM Format support as well as FAT. (Super IO)
1x SDCARD Connector -- Deprecated -- No longer supported. Will be supported through a SD2IEC module.
1x Extended Cartridge Port (Compatible with Old C64 with extra adapter board)
2x Joystick (DB9) Port with Analog Input
1x PS2 Keyboard Din Connector (Super IO)
1x PS2 Mouse Din Connector (Super IO)
1x Internal Header Connector for expansion
1x USB to Serial for connectivity to Gavin** (This is for the developer unit only)

Software
Kernel (System Control/Disk OS)
Extended version of Basic to support Hardware features to control graphic and sound and I/Os.
Resident Monitor for Debug and Development
PC Development Suite to help the developer to design software development and games.

C64 Support? (Updated)
In the short term, the C256 Foenix development team won't be investing any time for a C64 support. As I mentioned many time, there are a gazillion ways to have a access to a C64 these days. There is no point into reinventing the wheel again. However, as I also mentioned, I tried to stay as true as possible for the hardware support as I could, like the IEC, the cartridge port, etc... So, if anybody in the future want go about it, then there will be more than welcome!


Cheers, Stefany, August 6th, 2018

Jun 8

I am happy that someone is running with this concept and the specs above sound perfect but still cutting edge for that era.  I like that floppy usage is in the spec.

Jun 8

The SID purists will probably have a fit if it does not have sockets for real SID chips but honestly they are expensive now and falling like flies. The 8580 was in fact closer to the original design spec than the 6581 was (but then folks learned to exploit the 'unintended' 6581 'features'.) 

The original SwinSID was open source I believe but not the SwinSID ultimate. I also recently came across an open source Propeller SID, which is really a SID player but I don't think it would take much to actually use I/O pins similar to the real McCoy. They only used one cog for the SID so one could do stereo easily. The source is well commented and was easy to get an idea of what they were doing. http://obex.parallax.com/object/532 is the project. Of course you could do the same logic in your custom FPGA sound chip and give it a 'SID' mode.

Jun 8

The SID has always been a point of contention because of its fandom. From my perspective I am only trying to recreate something that could have existed at the time. Back then there was a lot 6581 going around, so it is only natural that a C256 would have them. 
Now, that being said, I would like to think that with a different environment and with more time, they would have improved upon it. Which will lead me Inoxarobly to replace the real SID with a more evolve version of them at some point...

Jun 8 · Edited: Jun 8

Personally, I am not married to the SID. I could go either way on that, but adding a socket shouldn't be a huge burden. Since the SwinSID is out there, I don't see a reason not to included it. True, real SIDs will eventually be unobtainable, but we've got FGPA versions now, so that socket should still be useful. Including a YM chip will add a lot of 90's feel to the soundscape, and even a general MIDI synth should be easy enough to add in to the mix. 

I'm also thinking about memory... I'd like to see this system just start with 16MB. I understand the whole "limitations are the soul of creativity" argument, but let's be honest - this system also needs to be capable of doing real work, and I don't see artificial limitations as exciting, just as frustrating. This system is, basically, a C64 with a SuperCPU... and the SuperCPU can handle up to 16MB of RAM. Let's use the full capabilities of the CPU rather than throttle developers needlessly.

Moving on - I like the idea of an IEC port for legacy data transfer, but I also definitely think we need USB host support - as well as USB device support. USB device support? I think this system should have a type B port that emulates two serial ports with an 11Mbps baud rate (equal to USB 1.1); this would allow direct communication with a PC or other system. Virtual Port 1 would be used for debugging and run the same monitor as from the console's MONITOR command, and the Virtual Port 2 would be a data channel to allow a PC or Raspberry Pi to act as a print and file server. This would allow the Feonix to send a standard set of print commands, and the connected PC would translate those commands to whatever printer is connected. 

Keyboard and mouse - I think USB is really the only option these days. You can't buy a new PS2 anything anymore, so the system should support USB devices from the get-go.

Character set: Like the C128 VDU, the system should be able to display PETSCII graphics characters and lower case letters at the same time. Further, Code Page 437 ASCII (aka IBM Extended ASCII) should be supported. In PET ASCII, code 14 switches to text mode and 142 to Graphic mode. Add in 15 and 143 to switch to APETSCII and CP437 ASCII. 

In APETSCII mode, character codes 32-127 represent the ASCII character set, including the _, |, \, `, ~, {, and } symbols. 128-255 contains the PETSCII glyphs. (I have worked up a chart that shows how the two can co-exist.) In APETSCII mode, it's even possible to add several missing glyphs: right and down arrows, top-half-shaded and right-half-shaded boxes, and the half and diagonal solid boxes that currently require reverse printing. 

On that note, ditch reverse printing and use per-cell foreground and background colors. To reverse print, the user would simply select opposite colors. This also allows for the character generator ROM to cut the number of required symbols in half, allowing for upper-case, lower-case, and ASCII compatible symbols on the screen at the same time. A second set of glyphs should be provided for CP437 support. 

Why support Code Page 437? This would allow easier porting of DOS games and applications. 

Finally, disk and file access. I think the Feonix should stick with the CBM standard of LOAD "filename", [device], [location] convention, but with a twist: the internal hard drive should start out as the default device (ie: device 1), and if a different device number is used (eg: 8 or 9), then that should become the default until a reboot. This would allow programs to easily load overlays and data from the device used to launch the program. The use of hardcoded device IDs or path names in software should be discouraged. 

I like the uIEC standard for accessing the file system and mounting images on FAT devices. Stick with that for simplicity and compatibility. Include the JiffyDOS DOS wedge commands in BASIC and the machine monitor, and it will be very easy to navigate disks. So with JiffyDOS and IEC syntax combined, we get:

@ gets the device status or issues a DOS command
@CD changes directories and mounts disk images. 
@$  reads the directory
/ loads a BASIC program 
% loads a machine language program

Jun 10

Thanks for including MIDI support!

Jun 10

It's your project and your itch to scratch but please reconsider the memory limits. The 65C816 is a full 16 bit CPU and I don't believe the designers of the time would have purposely limited the hardware like you're suggesting. In fact it's clear that they wouldn't have because they didn't do it with the Amiga 500 which released in 1987. The C128 dropped in '85 so a theoretical C256 would have been released somewhere around the time of the Amiga 500 and by then memory expansion was well established as thing.

More importantly if you want programmers, especially game programmers, to hop onto a proto 16 bit project you've got to give them some room to breath when creating code. From a games perspective I see the C256 as slotting in as not quite an Amiga 500 but much more than a C64. 

I think you're essentially trying to build the Apple IIGS of the Commodore world which is very cool but if you unnecessarily restrict the system too much it will not take off as it should.

Jun 10 · Edited: Jun 10

A system designed at the end of eighties would have:
* Dual playfield (two transparent overlapping screens). These would probably both be 16 colors each to save memory bandwidth.
* 320x240x256 graphics mode as well, more DMA time for sprites and blitter
* Some type of DMA driven sample playback capability

There should also be interrupts for screen raster line (and registers for reading current raster beam x and y coordinates) and a way to achieve clock cycle accurate synchronization with the raster beam.

It'd be very nice if there's also 8x8 character cell based screen modes. Those were useful for better performance in 2D-games.

Jun 10 · Edited: Jun 10

If the GPU has dedicated memory, then fhe CPU doesn’t have to stop to let the GPU refresh the screen. The trick, for programmers, is to make sure you dont’t do video updates while the screen is being drawn. Raster interrupts, like fhe C64 had, can notify the programmer when the frame buffer is available for writing. Of course, this also gives the programmer the chance to do per-raster line tricks.

Jun 11

I'd honestly say that 512KB w/ a 1MB maximum expansion is a serious low-ball for 1987 spec. The IBM PC/AT (which launched in 1984) could do up to 16 MB; the Macintosh Plus (released in 1986) could do up to 4 MB; the Amiga 500 could do up to 9-- et al. With the processor chosen, I would seriously say allow for higher RAM amounts, even if you only put 512K by default.

Jun 11 · Edited: Jun 11

Okay Guys, chill out about the memory... I hear you.
I will reconsider the basic amount in the system as I understand it could undermine the possibilities of creating interesting pieces of software. I get it.

Besides, there will be an expansion connector inside, so for anybody who wants to put a Gazillions Megs in it. They will be able to, as well as other devices, like a 2.5" IDE HD or Ethernet card if anybody bothers designing the hardware and software that goes along with it.

BTW, right now, I am just a single person and I can only do so much and honestly, I would rather release something sooner than later...

Cheers!
S