C-One

From IndividualComputers
Jump to: navigation, search
(thumbnail)
C-One rev0 Prototype
(thumbnail)
C-One Production Board
(thumbnail)
FPGA Extender Prototype
(thumbnail)
FPGA Extender Production Board

Contents

General

The C-One marks the biggest loss in iComp's company history. It was meant to be a C64 replacement, but Jeri Ellsworth - the original designer of the board - never delivered the cores that she had been paid for. Other people took up that job, and individual Computers created add-on boards to put the C-One into usable condition.

The C-One marks a milestone in computer history, as it's the first computer to be built completely without CPU and without graphics chips, just with FPGAs. Just over 200 units are in the field.

If you are looking for a affordable FPGA platform, look at the Chameleon.

Cores

  • ZX-One core - Spectrum 48k core for C-One with extender (Version 1.0 - May 8th, 2011)

Author: Alessandro Dorigatti license: Modified BSD license (see archive) Z80 CPU core by Daniel Wallner Spectrum Roms are (C) Amstrad, included freely according to Cliff Lawson

Chameleon features on your C-One for free! C64 reverse-engineering work from the Chameleon project has been used for this core. Features: 2MB cycle-exact REU, IEC support, framebuffer-based VGA output Author: Peter Wendrich (NL)

Chameleon features on your C-One for free! C64 reverse-engineering work from the Chameleon project has been used for this core. Features: 2MB cycle-exact REU, IEC support, framebuffer-based VGA output Author: Peter Wendrich (NL)

Please use the latest system flash for this core. with a great deal of help from Tobias Gubener in porting Xilinx code to Altera and a little bit of help from BeRo, Groepaz and Jens Schoenfeld C64 reverse-engineering work from the Chameleon project has been used for this core. Author: Peter Wendrich (NL)

This archive contains the latest version of the Turbo CPC that can either run the standard Amstrad CPC roms, or the latest version of SymbOS (also contained in the archive). Before you can run one of these new cores, please update to system flash V0.61, which is also contained in this archive. For your convenience, Turbo CPC and the system flash always have the same version number. Authors: Tobias Gubener, Jörn "Prodatron" Mika

This core clones the Schneider CPC 464 computer. Lots of extensions, including loading DSK images from CF card or CD, memory expansion, optional roms. This file is also contained in the betatester archive. Author: Tobias Gubener

This core clones the Schneider CPC 6128 computer. Lots of extensions, including loading DSK images from CF card or CD, memory expansion, optional roms. This file is also contained in the betatester archive. Author: Tobias Gubener

This core clones the Amstrad/Schneider CPC with a 12Mhz Z80 processor, realtime-switchable between normal and turbo speed with F9 and F10 keys. This is the first core to use the SD-Ram of the C-One! Uses the OpenCores Z80 core by Daniel Wallner, adapted to the Altera Quartus design software. Full source now open! Author: Tobias Gubener Z80 core author: Daniel Wallner

  • VIC-20 core by MikeJ, ported by Tobias Gubener (V1.2, august 17th, 2006)

This core clones the predecessor of the legendary C64, the VIC-20 (AKA VC-20 in Germany or VIC-1001 in Japan). Roms taken from ftp.funet.fi, firmware section. You can also find other character and Kernal roms there! Full sources (Quartus project directory) included! This core clones the PAL version of the computer. Authors: MikeJ and Tobias Gubener, with help of Dirk and Oliver. Also check the FPGA Arcade site for the original source.

These cores demonstrate the new capabilities of the extended gbmuxer and the new graphics modes that come with the latest system flash. Both cores include the full FPGA sources, and a tool to convert your own pictures, including the C source of that. Before you try them, make sure to update your system flash! Author: Tobias Gubener

This file is provided for historical reasons. This is Jeri Ellsworth's outdated C64 NTSC half-compatible core (will output VGA graphics, but behave like almost like an NTSC C64). Requires the CPU/RAM card - will utilize the 128K S-Ram only, and disable the 65816 processor. Better use Peter Wendrich's C64 core, as Jeri Ellsworth only made big promises, but still did not deliver what she has been paid for. Author: Jeri Ellsworth

FPGA extender

Amstrad/Schneider CPC core with DSK support at "insane speed"! Author: Tobias Gubener (D)

This core requires a kickstart ROM file with IDE support. Although still recommended, the IDE modification is not necessary, as this core does not use a real harddrive on the IDE port(s). Version with patches and ARM software by Jakub Bednarski, port by Tobias Gubener. read the readme.txt file in the binary archive for more information. Authors: Dennis van Weeren, Jakub Bednarski, Tobias Gubener

This core requires a kickstart ROM file with IDE support. The IDE modification is not necessary any more, but cutting off the CSEL pins (first part of the document) is still recommended. Version with patches by Jakub Bednarski, port by Tobias Gubener. Activates the primary IDE port for use with the Amiga. Includes 11M memory option. Authors: Dennis van Weeren, Jakub Bednarski, Tobias Gubener

This core requires a kickstart ROM file. Version with patches by Jakub Bednarski, port by Tobias Gubener (now with 11M memory!) with tiny bits of help from Jens Schoenfeld for autoconfig-mem Authors: Dennis van Weeren, Jakub Bednarski, Tobias Gubener

Newboot

Newboot is the new C-One startup core. Newboot brings a completely new life to your C-One - no matter if you have the FGPA extender card or not. Why should you upgrade?

  • all-new colourful startup screen
  • much faster than BigBoot
  • can be controlled with joystick or keyboard
  • almost any number of cores per card
  • cores and target software can be loaded from CF at the same time
  • user can choose his own icons for each core
  • Newboot can re-configure the Slave FPGA
  • support for FPGA extender card
  • fully backwards compatible with BigBoot

With all these new features, there's also one drawback: Newboot cannot load cores from CD-Rom drives any more. With flash cards being larger than the average DVD already, we believe that this won't really affect you in everyday-life.

Preparations

  • Full Newboot archive

This archive contains everything you need to get your C-One launched. Please download and unpack the complete archive with all subdirectories to the root directory of a CF card. version 2.01 november 29th, 2008. New: Now with Minimig core and updated/bugfixed C64 onefile-loader Download: File:NewbootV201.zip (2.6 MByte) core Authors: Tobias Gubener, Peter Wendrich, MikeJ, Dennis van Weeren BigBoot authors: Per "MagerValp" Olofsson, Tobias Gubener Newboot author: Tobias Gubener

Unpack the complete directory structure to your CF card. If the card was not empty, you will notice that the archive blends in with your existing BigBoot installation, as it will show a new entry number 0 called "Preview new startup".

The preview lets you try the new look without flashing. This is required, because we have found some SIMM modules to be incompatible with Newboot. Newboot is now improved to a degree where we have solved all problems with SIMM modules, but you are still encouraged to do this test: Select the preview and enjoy all the new icons:

Newboot sel flash.jpg

Now that you are in the new startup screen, your first goal is to get back to the BigBoot screen. You do that by moving the cursor (the C-One logo and frame around the icons) over the BigBoot-icon (the funny hand-drawn one). Either press the joystick button or the return key to make your selection. Are you back now? Great, if you see the familiar blue/yellow BigBoot screen, just re-confirm the version number in the top left corner of the screen: It should now show V1.01, as a sign that BigBoot has been launched from Newboot. This is it, you're ready to update your C-One!

In case something did not work as expected, you should NOT flash your C-One. Instead, you should exchange the 72-pin SIMM module for a new one. The speed should be 60ns or faster (some 70ns types also work), it can be EDO or FPM memory, and it must be 1MByte or larger. We have successfully tested lots of modules, and don't have a single one that doesn't work with this release version. Your module will most probably work - if it doesn't, please contact us, so we can find out what's the cause.

If you have a SIMM module that works fine with the procedure described above, you are ready to write Newboot to the system flash of your C-One. This is done from the graphical selector of Newboot: Please select the "Flash the new startup core" icon (the one with the text-only icon):

Newboot sel Bigboot.jpg

After flashing, you are prompted to power-cycle your C-One.

The one thing you need to understand about Newboot is it's directory structure. We have prepared a separate page for this, as it's a lot to read. Click here for the explanation of the directory structure. In short: Every menu item has it's own graphics and cores. Changing between menu levels really means that FPGAs are re-configured. This is happening so fast that you will hardly notice it - the monitor loses sync for a split second, and then you're in the next menu item. For the first time, the true power of the C-One is being utilized: Both FPGAs can re-configure each other while running. With the old BigBoot, the 1k30 was fixed, and the 1k100 was re-configured according to the menu item that you have chosen. With NewBoot, both FPGAs are re-configured a number of times while you are browsing through the menu.

There is hardly any explanation necessary for using the menu - move the cursor with the joystick or the cursor keys and select with the joystick button or the enter key. This will either start a core, or get one level deeper into the menu structure. If you want to go up in the menu structure, press the ESC key.

Directory structure

The directory structure pretty much represents the menu structure of Newboot. On power-up, Newboot launches the core that's found in the root directory of the card. This sounds like you are limited to one core, but the whole secret to this is that there is a selector-core. The selector-core will look for a directory called "c1dcores" that can contain up to twelve directories with cores:

  • root dir
    • boot.bin - selector binary data, belongs to selector core
    • cone-sys.bin - old BigBoot system flash file, not explained here
    • extender.rbf - core file for FPGA extender card, belongs to the selector core
    • marker.raw - graphical cursor that you move over the core icons
    • select.raw - graphical icon for this core/dir (not displayed in root dir)
    • selectbg.raw - background graphics, belongs to the selector core
    • support.rbf - config data (core) for the 1k100 FPGA, belongs to the selector core
    • [dir]boot (old BigBoot directory, not explained here)
    • [dir]c1dcores - this directory belongs to the selector core of the root dir
      • [dir]bb_classic
        • emu.bin - BigBoot classic binary data, placed in 72-pin SIMM
        • select.raw - graphical icon for this core/dir, used by the selector core of the root dir
        • support.bin - config data (core) for the 1k30 FPGA
        • support.rbf - temporary config data (core) for the 1k100 FPGA
      • [dir]c64
        • select.raw - graphical icon for this core/dir, used by the selector core of the root dir
        • support.rbf - temporary core for the 1k100
        • boot.bin - binary data, executed by startup during config phase
        • char.rom - the C64 character rom
        • basic.rom - the C64 basic rom ($a000)
        • kernal.rom - the C64 kernal rom ($e000)
        • target.rbf - the C64 core, loaded into 1k100 after uploading all roms
      • [dir]c64_demo_pal
        • select.raw - graphical icon for this core/dir (displayed by the selector of the root dir)
        • select.txt - text file that is overlaid over select.raw, this file is used by the selector core of the root dir (optional)
        • boot.bin - selector binary data, belongs to selector core of this directory
        • marker.raw - graphical cursor that you move over the core icons, belongs to the selector in this directory
        • selectbg.raw - background graphics, belongs to the selector core of this directory
        • support.rbf - config data (core) for the 1k100 FPGA, belongs to the selector core of this directory
        • [dir]c1dcores - this directory belongs to the selector core of this directory
          • [dir]c64_1
            • select.raw - graphical icon for this core/dir, used by the selector core of the c64_demo_pal dir
            • support.rbf - temporary core for the 1k100
            • boot.bin - binary data, executed by startup during config phase
            • char.rom - the C64 character rom
            • basic.rom - the C64 basic rom ($a000)
            • kernal.rom - the C64 kernal rom ($e000)
            • target.rbf - the C64 core, loaded into 1k100 after uploading all roms
            • Utopia.prg - program file for the C64 core. This file is automatically loaded and started (RUN) in the C64 core.
          • [dir]c64_2 same structure as c64_1, additional:
            • select.txt - textfile that is overlaid over the select.raw graphics. Gives a nicer appearance, especially with the long filename of the PRG file in this dir!
            • The Didgery Demo.prg - program file with a long filename (loaded&started automatically)
          • [dir]c64_3 (same structure as c64_1)
          • [dir]c64_4 (same structure as c64_1)

As you can see, the selector can be nested, and you can generate an almost infinite tree of cores. Currently the depth limit is (todo: Insert dirtree limit) selectors nested. You can browse the structure by selecting an icon with the joystick button or the enter-key of the keyboard. To go up one level, press the ESC key on the keyboard.

Each selector can have it's own appearance with individual backgroud graphics, icons and markers. The structure found in the new release package shows an example of the possibilities, but doesn't really go fancy with graphics or an especially deep directory tree. It's meant to be an example, not a software collection!

You can also minimize the structure to a single core without a selector at all: Just take one of the cores and copy it to the root dir of your card. This will launch the core without displaying a menu at all! A C64 that is launched this way only needs about six seconds from cold-start to the READY prompt.

You are encouraged to experiment with the directory structure of Newboot!

Board Modifications

This board modification increases the cartridge port compatibility. All boards shipped after spring 2008 already have this mod installed. The mod is required for many cartridges out there, so it's recommended to keep your board consistent with the other boards out there. Authors: Peter Wendrich and Jens Schönfeld

This document describes a number of modifications that need to be done in order to activate the IDE ports of the C-One for the Minimig cores V1.25 and higher. Published on popular request. Authors: Tobias Gubener and Jens Schönfeld

Developer Information

This document answers all questions that a core developer might have. If you want to write a core, this is your main source of information. We're continuously working on this file, and should it leave any questions, feel free to ask. Your input is welcome! Author: Peter Wendrich

  • C-One FPGA extender info (updated november 22nd, 2008)

The C-One FPGA extender allows you to use a Minimig core with a HUGE Cyclone3 FPGA. Here's the part that's interesting for developers: The Schematics and the Quartus pin file, directly taken from the Minimig Quartus-project (meaning it's proven to work!). Authors: Tobias Gubener and Jens Schönfeld

This file is for FPGA developers who want to make their own cores using the Quartus development software (free from Altera). Not all pins have been defined, as this only implements the GB muxer and the S-Ram on the CPU/RAM card. Get more pinout information from the schematics. Author: Tobias Gubener

This file is for information only. Although it's possible to re-configure the 1k30 from the 1k100's side, we consider this to be the "step after next", so this file is provided for educational use only. Author: Tobias Gubener

This subdesign joins gbmux and the audio shifter, and adds a few new features. Use the latest system flash to use the new graphics modes. Author: Tobias Gubener

The two FPGAs are connected with an 8-bit bus that serves as communication channel between the two FPGAs. The 1k30 has all the VGA interfaces, but many cores will generate the picture in the 1k100. This subdesign will take your high-colour RGB data, your pixelclock, HSync and VSync and transport it over to the 1k30, which will display the data. The same file also transports audio data and recieves ROM data from the early startup menu "BigBoot". Build your own 1k100 cores around this file! AHDL file with comments currently in German. Author: Tobias Gubener

  • Audio shifter (for historical reasons only, replaced by GBridge)

This might make it a little easier for you to bring your 16-bit stereo audio data into the right format that gbmux accepts. AHDL file, currently commented in German. Author: Tobias Gubener

GBridge

gbridge

  • GBmode: Selects one of two graphics modes, and can be toggled dynamically.
    • low: 25 Mhz pixel clock mode with 65k colours (hi-colour)
    • high: 33,8Mhz pixel clock mode with 4096 colours (only upper 4 bits of digital RGB values, like Amiga-OCS)
  • sysclk: connect to 101Mhz board clock, that's pin 79 of the 1k100.
  • vid 15..0: These are the binary video bits, mapped as follows:
    • vid[15..11] = blue[4..0]
    • vid[10..5] = green[5..0]
    • vid[4..0] = red[4..0]

Note that in 33,8 Mhz pixel clock mode, vid[11, 6, 5, 0] are unused and should be set to 0.

  • vsync, hsync: inputs to the gbridge, should be VGA frequencies, but can be any scan rate, because they're passed to the monitor directly.
  • pixelclkena: Output, this is the pixelclock that the gbridge generates. The name might be a bit confusing, as it can also be used as a clock_enable for the board clock, but it has turned out to be more stable to use this as an async clock. Pixels are sampled on the falling edge of the signal. In 25 Mhz mode, the signal is 25% high, and 75% low, while in 33Mhz mode, the signal is 33% high, and 67% low.
  • gb[6..0], gb[7] This is the graphics bus, just connect to the respective pins of the 1k100. The reason why gb[7] is in a different place is that the signal plays a special role in the protocol - just ignore, you can't change very much on the protocol anyway ;-)
  • right[15..0] and left[15..0] These are the audio signals that are sent to the CD audio DAC. Just connect your binary audio signal to these lines. At this point, there's no way for you to find out when the word is latched. Please sync your audio source to the 2Mhz signal, as 48 clocks are used to clock the data into the DAC (resulting in exactly 44,1khz audio). A later version will make the LRclock available to the 1k100 design, so you can sync your source to the DAC.
  • SID1Mhz: Input to gbridge. This signal is routed to the SID directly, delayed by about 20 to 60ns (25 Mhz mode) or 20 to 80ns in 33Mhz mode. This eases syncing the SID chips to the 1k100 design, and it's for giving the chips the most precise clock that you can generate out of the base clock. Note that the SID derives all tones from this clock, so the differece between PAL and NTSC clock makes a huge difference to the human ear - even to those who are not very audio-phile!
  • ioselect[3..0] These signals are for accessing the IO stuff of the C-One, like IDE, clockports, flashrom and all the other stuff (see schematics). Data can be read/written on the mdb[7..0] bus. Bit combinations are like this:
    • 1111 sets all signals high (default)
    • 0111 unused
    • 1110 IOW
    • 0110 IOR
    • 1101 IDE2 write
    • 0101 IDE2 read
    • 1100 IDE1 write
    • 0100 IDE1 read
    • 1011 FDC write
    • 0011 FDC read

All other combinations are unused, please don't use, as we might need them for future enhancements.

If you want to access things that use IOW and IOR, you have to set the csel[] signals properly *before* sending the respective signal to the 1k30.

Accessing the FDC means that you're talking to the emulated NEC765 chip of the early startup core. This can be used to add a NEC765-based floppy drive emulation to your core. The early startup is still running in the background, and the floppy emulation runs at the same time. A command list with the additional commands that load a disk image will be added later.

  • ioshift, ioshiftclk: Please connect to the respective pins - these are necessary for the communication with the 7064 CPLD, which has most of the IO connections like joystick and LPT bus.
  • adr[19..0], data[7..0], iowr, memwr These lines are for transferring rom images during early startup, and for having a connection between the Z80 processor of the early startup to possible periphals in the 1k100. On a memory-write, the address and data lines reflect the location and contents of the memory cell. The actual write is initiated with a low pulse of memwr. Same applies to iowr, with the difference that iowr goes low for IO accesses of the Z80 processor.
  • wrshift[14..0] These are internal signals of gbridge that are used to time the release of iowr or memwr. Just ignore if you don't want to change the timing of these signals. If you want to, have a look at the source!
  • lpt_bsy and joystick signals:
    • JoyA[5] Joystick port A FIRE1 (normal fire) signal, active-high
    • JoyA[4] Joystick port A FIRE2 (right mouse button) signal, active-high
    • JoyA[3] Joystick port A RIGHT signal, active-high
    • JoyA[2] Joystick port A LEFT signal, active-high
    • JoyA[1] Joystick port A DOWN signal, active-high
    • JoyA[0] Joystick port A UP signal, active-high
    • JoyB[5] Joystick port A FIRE1 (normal fire) signal, active-high
    • JoyB[4] Joystick port A FIRE2 (right mouse button) signal, active-high
    • JoyB[3] Joystick port A RIGHT signal, active-high
    • JoyB[2] Joystick port A LEFT signal, active-high
    • JoyB[1] Joystick port A DOWN signal, active-high
    • JoyB[0] Joystick port A UP signal, active-high

The lpt_bsy signal comes directly from the centronics port. Not inverted!

The 2Mhz signal is an output from gbridge. This is the 2Mhz signal that is used for communication with the Audio DAC, and is transferred by gbridge into the 1k100. There's a small phase shift between this 2Mhz clock and the real clock that is routed to the DAC, it's the same as with the 1Mhz SID clock: delayed by about 20 to 60ns (25 Mhz mode) and 20 to 80ns in 33Mhz mode. There is no correlation between the 1Mhz SID clock and the 2Mhz DAC clock! The delay for one of the signals can be 20ns, while it can be 60ns for the other. Also note the the 2Mhz signal is a 2,1168Mhz - if you want to be precise ;-)

The joystick and lpt_bsy signals are part of the shift-register communication with the 7064 CPLD. If the ioshift signal is only used by the 1k100, the ioshiftclk can be any clock, as long as it's connected to pin 168 of the 1k100. ioshiftclk is available on the 1k100, but not on the 1k30. However, the 1k30 needs access to the joystick signals in some cases (mainly the CPC cores), so it needs to have some syncronity on the ioshift signal. This can ONLY be achieved by connecting the 2Mhz signal of gbridge to the ioshiftclk signal and to pin 168 of the 1k100 (which goes directly to the clock pin of the 7064).

Schematics

Intermediate version. These schematics do not show some of the jumper wires, and they don't show the Instant-On flash rework. However, you get a good idea of how the system is built, and if you have questions, we're happy to answer. Author: Jeri Ellsworth

Every C-One is delivered with the "Instant-on" board, which is soldered to one of the clockports, the 3032 CPLD and two spots on the mainboard. Author: Jens Schönfeld

CPU Slot

CPU Slot Footprint CPU Slot Dimensions CPU Slot Pinout

Clock Port

C1-clock-con.gif

Video Port

Video Port Pinout

Links

Retrieved from "http://wiki.icomp.de/w/index.php?title=C-One&oldid=6340"
Personal tools
Namespaces

Variants
Actions
Navigation
Icomp
Print/export
Administration