HOME

C-One Prototype and Details

Introducing ... the C-One

Color key for this page
( ) indicates Jeri's original data
( ) NEW STUFF, NEEDS CHECKING!

KwikJump ®tm

A Short Introduction

C-One is a project begun about 3 years ago by a gifted computer enthusiast named Jeri Ellsworth. Her original concept was to develop a Video Accelerator card for use on a Commodore C-64. The card would allow the C-64 to use SuperVGA graphics modes when connected to a standard VGA/SVGA monitor. The project was based upon FPGA chips into which her hardware functions would be preprogrammed

As time progressed Jeri had to further integrate increasingly more of the original C-64 into her FPGA design. This was necessary to overcome innate limitations of the orignal 1 MHz 64 KByte design of the stock C-64. At some point she saw that she had essentially recreated the entire C-64 in her design. Having done so, she set herself to a more ambitious task, to create a modern computer with modern computer features which would remain compatible with traditional C-64 applications

The new computer was dubbed CommodoreOne (later C-One) and represents a logical evolutionary leap for Commodore users. The goal is to provide direct access to modern computer features and peripherals while retaining and preserving the personality and features which defined the classic C-64 experience. I see C-One as the computer Commodore would have produced if they had continued to develop and enhance the C-64

A 32-bit microprocessor is also being developed by a third person, Gideon Zweijtzer. The new processor exists on FPGA and will interface directly with the C-One motherboard. It will be 6502 code compatible but expands the bus to 32 bits. The opcode set will be expanded and enhanced to accomodate 32-bit operations

A FAT-16/32 filesystem is being developed for controlling IDE drives and Compact Flash devices. The filesystem currently supports selecting and loading an FPGA image from disk on startup

Now Jeri has teamed with Jens Schoenfeld in Germany to help with development and production of the new computer. Jens has become a key player in C-One development and has worldwide recognition already as an honest and trustworthy associate. With this merger comes serious plans for the future of C-One as a reconfigurable computer. In the future it will be possible to download a new core for the FPGA to configure C-One as most any classic 8-bit computer. I imagine this will include such favorites as the Atari 2600 and 8-bit series, TI 99/4a, Tandy/CoCo and many others

C-One is a work in progress and the hardware, specifications and features are constantly changing. The information here is not a list of promises but an attempt to reflect the current state and direction of development. With that in mind, I hope the C-One Details page will serve as a useful resource to Commodore fans

News

Date: Sun, 18 May 2003

I've debugged the floppy head/motor/step control circuit today and tested it against MV's test program. I added the keyboard fifo empty = carry on the lka command. Hopefully this will fix some of the keyboard bugs MV's been experiencing. I'm adding some video control registers for the drive CPU so it can control the resolution and frequency on startup

Jeri

Date: Fri, 16 May 2003

MV and I have pretty much found all the bugs in the drive CPU's graphics controller and fixed them tonight. I've been fixing a few glitches in the memory interface between the drive CPU and the main memory and fixed a refresh problem on the SDRAM

Jeri

Date: Thu, 15 May 2003

I just implemented the loading of code into the drive cpu after booting. This allows you to write things that run independently of the main system - ideal for something like the 1581 emulator. There are a few things to think about:

  • The file should be called 0DRIVE.BIN (or 1DRIVE.BIN, etc)
  • It mustn't be any longer than 32768 bytes, and should *not* have a 2-byte load address
  • It's loaded at $4000
  • It's executed with a jmp $4000 *after* the FPGA config and any ROM image files are loaded
  • The 0DRIVE.BIN is responsible for finishing the boot sequence, the last part of the boot ROM's main routine is *not* run. Basically, this consists of resetting the 65816, and then releasing /DMA. See the code following jsr boot in main.s for an example

Of course, you can also just this as a way of not starting the 65816 (or whatever CPU is in the CPU slot). A file with just jmp * would effectively keep the main CPU off the bus, leaving the 1K100 free to do whatever it wants. I have no idea if this is useful or not, but the possibility's there

Thanks to Jeri and Jens putting off the release a little bit, I've had a chance to improve the boot rom a *lot*. The code has really matured over the last two weeks. So what's left to do? My TODO list for 1.0 currently consists of:

  • Add FLASH.BIN loading (needed for upgrading the 29F010, this is a showstopper)
  • Fix drive size display (anyone with a good routine for printing a 32-bit sector count in a friendly fashion, intelligently placing the comma and selecting the right prefix? Pitch in!)
  • Add low level floppy support (Adrian's waiting for Jeri to implement the floppy instructions)
  • Fix a bug in FAT12 loading (still investigating this one, possibly Adrian's)
  • Add version number printing, for easy identification of boot ROMs
  • Add a readme.txt with instructions, acknowledgements, and so forth

Unless any new bugs crop up, the boot rom will then be finished (in the sense that it behaves according to the spec). I'll be branching the code into a 1.0 tree as soon as I figure out how to do it with CVS

Date: Fri, 9 May 2003

First I would like to thank MagerValp and Adrian for working so hard on the boot up code. It's really coming along nicely. I'll be sending the second developer board out today to Adrian, so he can start testing his code on real hardware

I've been trying to get over a bad flu/cold that I picked up the day after I got home. I guess being sleep deprived so many days before I flew home didn't help my immune system any. I'm feeling much better each day now and have started to get more and more done

I've fixed a bug that MV discovered in the drive cpu's adc abs,y, where the flags and values were not being stored. I've done a lot of work on the new DMA transfer circuit between the main system memory and the drive cpu. The circuit for flashing is now done and ready for software. I've also fixed a few bugs in the main memory arbitration. I'll try to post an update every few days from now on, since we are on the final stretch

Jeri

Date: Fri, 09 May 2003

I can't answer for Jens or Jeri, but the boot code is making a lot of progress. Instead of burning a new eprom every time I compile a new version, I made a small rom that receives the boot code over RS-232. This means that it now takes about 10 seconds for me to test the code, instead of 10 minutes. Development speed up, frustration level down

The code is at the point where it almost does what it's supposed to. The code to select a configuration by holding down 0..9 got a long overdue fix last night. Bus scanning is still a bit flaky, but it at least seems to find all the hard drives I throw at it (including CF cards). CD-ROMs are still not cooperating though. Filesystem handling has been completely abstracted, making it possible for me to start working on the ISO9660 support. Adrian Gonzalez has joined the project, and will be working on floppy support and flash upgrade code

FAT12 is almost done (it's just a variant on FAT16), and he's also thinking about putting 1581 support in there. I've added some more stuff to the project homepage http://c1boot.sourceforge.net/ including a small news section. I'll try to keep it updated whenever there's a significant feature added or a particularly nasty bug has been squashed.

magervalp2000

Date: Tue, 29 Apr 2003

I wanted to let everyone know that the production of c1's is going well and that I've been away from email for quite some time. I'll do my best to confirm the orders that have arrived by email before I leave. The first board shipped shipped yesterday to MV who is programming the drive boot code! Well back to work.. The boards come off the machines at about 1 every 6 minutes and it's taking a lot longer than that to test each one

Jeri

April 10, 2003

C-One production started

After more than two years development time, the C-One production has started. It'll start selling on may 5th in Germany and the Netherlands. Our other European partners should have the boards by may 9th, when the board will also be launched in North America

Many projects have dealt with re-configurable computers so far, but none of them is as consistent and flexible as the C-One. Other projects only kept parts of the hardware re-configurable, but the C-One can change the behaviour of it's chipset even during runtime. Therefore, the C-One is the world's first re-configurable computer. Read more on the official homepage of the C-One: www.c64upgra.de/c-one

There has been silence from our side for the past weeks. The main reason was that we focused on the work, taking all the time off any spare time activity. The Delfina production was kind of a dress rehersal for the C-One production, as it was organized as precise as we are now organising the C-One production. A new PCB production partner has proved to deliver very high quality at decent prices, and - most important - with a highly predictable production schedule. Since all other partners who deliver parts and services for the production of individual Computers are known to be in time, the following timetable will presumably be 95% accurate

As you can see, the next three weeks will be very busy. Please understand that we probably will not answer all questions in time until the production is done. The chance to implement physical changes is long gone. Adding an internal IEC is not possible any more. Moving the CF connector to a different position is impossible. The C-64 cartridge connector has now half an inch space to the audio connector, more was not possible. If you make suggestions for changes now, please understand that we can only implement it if this can be done with a core change. All physical things are written in stone now

Our stress level will be a lot higher than usual until the end of the month. The best time to get questions answered will probably be the Breakpoint Party, any other day might either be too busy to answer email, or we're too far away from the next internet-connected computer

  • April 7th: All electrical testing on the January prototype board is done
  • April 8th: Final changes on the motherboard done
  • April 9th: PCB data for copper layers, solderstop and drill data confirmed
  • April 10th: Inner layer production starts
  • April 11th: Deadline for silkscreen data
  • April 14th: Prepreg and outer layer mounting, drilling starts
  • April 15th: Drilled sample arrives at assembly house to prepare machine setup
  • April 18th to 21st: Breakpoint Party. The one and only existing C-One rev 2 will be on display there. Working!
  • April 22nd: SMD lasermask will be delivered
  • April 24th: Board house delivers boards to electrical test house
  • April 25th: pick up PCBs at board house, drive to the assembly company immediately
  • April 25th: (probably evening): Start setup of the machines
  • April 26th: With a little luck, the first C-One out of the mass-production will be fired up
  • April 27th: If there are any flaws, this day is reserved to locate the faults (assembly company does not work on Sundays anyway :-))
  • April 28th to April 30th: Mass production of 300 boards. Jeri and I will be present at the assembly house to do online testing and support the workforce. Early startup ROMs will be programmed with the latest version
  • May 1st: Jeri's flight home to Portland, Oregon USA with as many boards in her luggage as the weight will allow :-)
  • May 2nd: First shipments to retail partners of individual Computers
  • May 5th: Shipments arrive at German retail partners, shipping to customers can start
  • May 9th: By now, all European partners should have received their shipments of C-One boards
  • May 12th: Jeri should have completed all the work that was left undone during the past five months. Shipment of the boards to North American customers starts

To make things clear again: This is a developer board. Do not buy it for what it may become in the future. If you buy it, then buy it for what it is right now: A board that will experience a lot of core changes. You will need a PC to have access to the Internet, because that will be the only place where you can retrieve new cores. Depending on the state of the early startup ROM (which is not re-configurable!), you can either boot from CD (CD-writer in the PC necessary!), or from CompactFlash (CF cardwriter for the PC necessary!). Booting from CF and from hard drive is already implemented. Booting from CD is not yet implemented, but MagerValp is already working on it. Thanks again for his great support in getting the early startup procedure to work

The big difference between developer board and user board will be the availability of software and cores. We've paid thousands of Euros for tooling cost, which are impossible to pay with just a production run of 300. If the design would be changed in any way, we'd have to pay tooling cost again, and this is totally out of the question

What does developer board mean?

  • you will have to remove the CPU out of it's socket if you want to use a CPU card
  • you will have to remove the ROM chip out of it's socket to upgrade to a new early startup procedure
  • you will have to be flexible with your programming, because memory maps might change slightly as cores evolve
  • there will be bugs in the cores. So many bugs that many C64 programs won't run until the cores are adapted
  • you will have to be patient. If you can't wait a week or two for the next core, don't buy now!
  • it cannot outperform a PC. It will never do!

If you have any doubts, don't buy now. Only buy after all doubts are gone. And again -- Only buy for what the machine is at the time of your order. Do not buy it for something it might become in the future, because our plans might change without notice:

  • if you want to run CP/M, wait until the Z80 CPU module and the corresponding CBIOS is available
  • if you want to run C64 games and demos cycle-accurate, wait until the 6502 module is available
  • if you want to use it as VIC-20, wait until the VIC-20 core is available
  • if you want to use it as PET, wait until the PET core is available
  • if you want to use it as Ohio Scientific Challenger, wait until the Challenger core is available
  • if you want to use it as ZX-81, wait until the doorstop core is available
  • if you want to use it as Spectrum, wait until the Speccy core is available
  • if you want to use it as Apple II (e, GS), wait until the Apple II core is available
  • if you want to use it as a dual-monitor system, wait until the secondary monitor adapter is available
  • if you want to play Atari 2600 games, wait until the Atari 2600 core is available

...you get the point: If you want something and it's not coming fast enough ... Learn VHDL and do it yourself! Oh, and if you're not prepared to pay a nominal fee for each core, then never buy the machine

Jeri Ellsworth
Jens Schoenfeld

C-One Overview

Some of the following text was copied from the CommodoreOne website because that site is sometimes unresponsive due to overwhelming traffic. It was originally posted by Jeri Ellsworth, developer of the C-One

The CommodoreOne computer started off as a 2002 enhanced adaptation of the Commodore 64. During development it evolved into the C-One Re-Configurable Computer, a new class of computer where the chips do not have dedicated tasks any more. By programming the FPGAs with new cores, it should be possible to turn the C-One into clones of famous 80's computers like the C-64, VIC-20, Plus/4, TI-99/4a, Atari 2600, Atari 8-bit series, Sinclair Spectrum, ZX81, Schneider CPC and others. It can of course also be a completely new computer with specs unknown to these milestones in computer history

Here is a General Overview of the features of the C-One as of December 22, 2002. Some features may change slightly as development progresses

What it is
  • The C-One computer is a 2002 enhanced adaptation of the Commodore 64. While retaining almost all of the original's capabilities the C-One adds modern features, interfacing and capabilities and fills a sorely needed gap in the hobbyist computer market
  • The estimated price will be around $200 USD (249,- EUR including German sales tax of 16%). User will need to supply a ATX style case, ATX power supply, disk drive(s), PS/2 keyboard and mouse and an SVGA capable monitor

Features/Product Description

Physical Appearance
Power
  • Connectors on the C-One will be ATX-style. The C-One board is designed for a 5vDC power source and accommodations have been made to keep the machine as laptop/portable capable as possible
  • ATX power-down can be controlled by software
CPU/Speed
  • The main processor of the C1 is a 65c816 processor running approximately at 20 MHz. The 65c816 is a 6502 compatible processor with a 24 bit address range. Extra instructions that access the full memory range are added to the 6502 core. The C-One has a processor slot for any other 8-bit CPU such as a real 6502, Z80, 6809 or even the Z8S180. Pinouts and footprints are also documentented to the public
    • Software throttle for classic 64 speeds
  • The system bus runs at 50MHz, the 60Hz CIA clock of the system is provided by internal circuitry
  • Secondary 6502 processor for I/O support
SuperVIC Video Capabilities
  • VGA monitor output
  • VIC-II compatible in all video modes, 60Hz/50Hz emulation is software selectable
  • Classic Emulation & SuperVIC Mode is software selectable
  • Extended video modes as well as combination modes with classic VIC-II modes are possible
    • Memory addresses of features (character matrix, screen memory, color RAM, etc.) are each 24 bit addressable (except for the color palette which resides inside the chip's memory)
    • 16MB video RAM with adjustable mirroring/or relocation from CPU memory
    • Max Resolution 1280x1024 Sync settings from 60Hz-? (depends on resolution)
    • Maximum of 256 colors out of a palette of 65,535 in regular and linear modes
    • A special Chunky video mode with access to entire palette (limitations apply)
    • Graphics modes include 64 style cell video and linear video
    • Hardware based line drawing/fill & pattern fills/overlay, scaling?
    • Overscan
    • Windowing mode (view a portion of a 1280x1024 display on a 320x200 window & scroll)
    • Full byte Color RAM can be moved now!
    • Blitter functions (BLock Image TRansfer) Logical operation AND, OR, XOR
    • On-Board Copper Processor *
  • 8 Sprites
    • Can have up to 256x256 resolution
    • Can use classic linear or 64 video style graphics (pick up screen image?)
    • Mouse controlled mouse sprite
    • Based on a 320 dot clock (same pixel size/position on all video modes)
    • Video expansion connector for digital and analog video expansions
MonsterSID Audio
  • Classic SID Emulation (including address mirroring)
  • MonsterSID Mode
    • 16 stereo SID voices (1-8 left, 9-16 right)
    • Sync and Ring Modulation and filtering on all voices
    • Extra voices mapped in order after the first three
  • DMA audio
    • 8 Stereo voices (4 left, 4 right)
    • 64k internal sound memory (sound or instruments) as well as access to main CPU memory for playing DMA clips
    • Variable sample playback rate
    • Audio resolution of 8 bits
    • DMA segment playback can be either continuous (loop) or one-shot (note/segment)
    • two sockets for classic SID chips, Monster SID audio can be routed through their analog filters (prepared for more analog audio routing)
Memory
  • Computer memory is expected to be 32 MegaBytes of SDRAM, 16 of which is the main processor RAM and another 16 Megs accessible by the Video Controller. Memory is no longer fixed at 32MB. The user can install any size of SD-RAM module up to 1 GigaByte. The CPU will have access to this large chunk of memory with a simple banking register which itself is outside the CPU (not a true MMU). For the ROM emulation, some banks are write-once and thereafter read-only
  • 64K RAM for MonsterSID (DMA Audio or Instrument clips)
  • The System will have a small boot ROM (8-16k) which will handle power-on initialization
  • Main OS storage will be via a Compact Flash media interface with card which is designed to hold the C-One's operating system(s) as well as other data. There is no limit to card capacity (current Flash Cards contain up to 512 MB memory) Flash media is hot swappable
Internal I/O
  • 3.5″ floppy drive connector with 1581 emulation (using PC drive) with 64k RAM
  • IDE Interface with DMA support **
  • Compact Flash Media Slot (see 'Memory' above)
  • LCD Interface (TTL LCD style)
Internal Expansion
  • C-64 compatible Cartridge Slot
  • Up to two PCI connectors (factory-stuffed only one)
  • Capability to configure C1 system chip settings externally
  • Two Amiga 1200 compatible clock-ports for expansion
External Interfacing
  • PS/2 Keyboard port with either Commodore-64 matrix emulation (configurable) or raw data access
  • PS/2 Mouse with 1351 emulation and bi-directional communication support
  • IEC Serial Connector supporting Commodore VIC/64/264/128 drives and printers
  • 2 Joystick Ports (Paddles supported with classic SID chips installed)
    • Joystick lines can also be emulated via keyboard
  • Centronix Parallel port - can act as C-64 User Port with adapter
  • Geek Port (whatever spare lines are left)
* About the Copper
The Copper processor is designed to make adjustments to the video chip on the fly. As the video chip draws the screen the copper can be set to activate at specific pixel locations - upon activation it can modify the video registers with new values. This is how split screen, layered screen and/or mixed video effects are so easy on the Amiga. The Copper command list has three commands:
  • Wait for Raster Value
  • Skip Function if Event
  • Store Value to Register
** Floppy/IDE Interface
In the initial release these interfaces will not have any support software (with the exception of 1581 emulation), it is hoped that with the ease of interfacing to the floppy and IDE drives a more software oriented individual will develop the necessary support software for these devices

General Information

Keyboard Decoder Look Up Table (LUT) Programming Instructions

  • Remember Pause key doesn't repeat
  • The restore key needs to be defined and will not be user changeable since it is hardwired and not scanned by Row/Col strobes
  • Key map LUT is 256 bytes long
  • Non-extended scan codes are directly addressed from location 0 - 127 (0xxxxxxx LSB)
  • Extended and shifted scan codes are addressable at scan code + 128 (1xxxxxxx LSB)
  • Numeric Keypad keys map to the extended keys when shift is depressed (i.e. 7 = home, 9 = page up...)
  • Some extended keys have multiple scan codes and if two entries into the matrix are not needed then all scan codes need to point to the same matrix location. The SHIFT scan code generated when num lock on is now blocked on all extended keys (you may still manually shift or force shift these keys)
  • Left and right shift keys must be mapped in both shifted and non-shifted halves of the LUT to these locations or lock ups will happen
    • Row(7) col(1) for left
    • Row(6) col(4) for Right

LUT data needs to be arranged

Bits 7-6
  • "00" - Normal operation to 8x8 matrix
  • "01" - Extended matrix operation (d02f bits 0-2, joy 1,2)
  • "10" - Block shift
  • "11" - Force Shift
Bits 5-3 Column select
  • 8X8 matrix operations
    • Column of bit to set on key press
  • Extended
    • "000" - "010" (d02f extended column scan)
    • "011" - Joy 1
    • "100" - Joy 2
Bits 2-0 Row Select
  • 8x8 matrix operation
    • Row of bit to be set on key press
  • Extended
    • "000" - "111" (d02f extended row scan)
  • Joy Mode
    • Bit 0 - Joy 0
    • Bit 1 - Joy 1
    • Bit 2 - Joy 2
    • Bit 3 - Joy 3
    • Bit 4 - button1
    • Bit 5 - button2
    • Bit 6 - button3
    • Bit 7 - button4

To set a bit in the 8x8 matrix, assign a row and column in the LUT that corresponds to the keyboards scan code. You can disable the shift keys when you want to map a character to an un-shifted location with the block shift command. Mapping an un-shifted character to a shifted location requires the uses of the force shift command. The block and force shifts can only be used in the 8x8 matrix. When in the extended matrix command you can set bits in the d02f extended columns and the joystick bits

Examples
LUT address (hex)Bits
Un-shifted = scan code7-65-32-0
Shifted = scan code + 128CommandColumnRow
Map un-shifted key 'A' to the matrix location for 'A'
1C00001010
Map shifted key 'A' to the matrix location for shift 'A' (no need to force a shift here if a shifted key 'A' is desired)
9C00001010
Map shifted 'quote' key to matrix location for shift '@' (still no need to force shift because it�s still a shifted key)
D200111011
Map shifted '+' key to un-shifted matrix location for '+' (the shift key bit is present on the matrix and must be blocked to cross this key over to the un-shifted side also notice that by blocking the shift we still need to map from the shifted half of the LUT)
D510101000
Map un-shifted ';' key to shifted matrix location for '=' (the shift bit must be forced onto the matrix for this crossing and does not change which half of the LUT we map from)
4C11110101
Map un-shifted 'Z' key to joy1 button1 (must set command to extended column to access joysticks)
1C01011100
Map un-shifted 'F9' key to extended matrix col(0) row(1)
0A01000001

Q and A

General Questions

Is C-One an expansion cartridge for my C-64/128?
No, C-One is an entirely new computing platform designed from scratch with a C-64 at it's heart
What kind of PC do I need to use C-One?
None at all. C-One is not an emulator nor is it an accessory for a PC. It is an entirely new computing platform designed from scratch with a C-64 at it's heart
I would like to know if the emulation of the C64 is real (ie hardware level) or software emulation (like the emulators for pc etc)?
Good question! The C-One is an entirely new computer. Jeri has incorporated all the functions of a C-64 into her own hardware. No software emulation is involved here. This project has been made possible by recent advances in programmable logic chips
What software in my current collection will run on C-One?
Hopefully a large percentage of existing C-64 software will run on C-One. Because C-One will use a 65816 processor, I expect compatibility to be similar to that of the SuperCPU (probably a little better.) Many programs have already been patched for 65816 compatibility and high-speed operation. For more info, see The SuperCPU Home
How C-64 compatible will C-One really be?
Effort is being made to keep it as compatible as possible without sacrificing the new goodies. The C-One mode with MonsterSID and SuperVIC will still be C64 compatible but not 100%. If you have really tricky games, demos or other stuff that goes wild on the IO registers, it might not work on the C-One core. In such a case, you just choose a different core on power-up. Indeed, even after the C-One boards have shipped compatibility refinements and bug-fixing will continue being worked on and updates to be made
When updates are available how will my C-One get updated?
That's the beauty of C-One, the updates will be made with software. In the past computer updates were made by replacing chips on the motherboard, as Commodore replaced VIC-II and KERNAL chips when bugs were fixed. With C-One we can distribute updates to our users via internet download or on disk. You'll be able to make the updates yourself through the software interface
The original C64 had very predictable timing, e.g. cycles per line depending on number of shown spites. Will the C-One be able to emulate this timing perfectly?
The timing relations between the CPU and the display will not be affected. Please note that the C-One DOES NOT EMULATE, it really clones the hardware. C-One has a flickerfixer (hardware unit that generates a VGA compatible picture), and today's monitors are made to sync to varying frequencies. The part not emulating, but cloning even results in an internal pixel clock of 8 Mhz, which is used to transport data from the SuperVIC to the flickerfixer
Will C-One have a cassette port for my tape drive? I wanna run my old games on tapes!
No but it should be possible to build an interface to connect C-64 compatible tape drives. Currently it is thought that this interface would connect to the "Geek Port" but it is not yet defined
Will the Cassette control lines still be available at $0001?
The addresses $0000 and $0001 will float on the lines normally used for cassette. This means that a person could make an address decoder for this location and register the data lines used for cassette
Will the [RS-232 port] be a user port connection or a real COM port? Will it have a real 6551 ACIA driving it, like SwiftLink-style?
The RS-232 serial port will be replaced by two Amiga 1200 compatible clock port connectors, because the Silversurfer serial port for the Amiga computer is exactly this. Since it is produced in high quantities, it's cheaper to use that instead of buying new 16c550 UARTs. Plus, it gives you the opportunity to use Amiga add-ons that go on that port. The clock-port is polled I/O only. The two clockports are pin-per-pin equal, like a pass-through. This is to make it compatible with one clock module and one serial port
What kinds of devices are supported by the joystick ports?
Digital joysticks (Atari-type) and devices compatible with digital joysticks will work.
Can the joystick ports be used to drive miscellaneous digital I/O devices?
The lines on the joystick ports are input-only, so they cannot be used for anything other than joysticks and other input devices that also work on the C64
Light pens and light guns are digital input devices. Will they work?
I ran the LP line over to the 1k30 just in case we wanted to do a light pen. It may be a little tricky since the VGA output isn't necessarily synced with the VIC in the 1k100
What about game paddles and other analog input devices?
The C-One has both real SID sockets wired to the joystick ports. The analog inputs for game paddles are only available with classic SID chip installed
What about the TOD clock?
Yes, it will have the TOD...
How much memory can the CPU actually address?
The 65816 itself has a 24-bit address space (16 MegaBytes). From a programming perspective it functions more like a 16-bit address bus with an 8-bit extension tacked on. That way the 65816 can directly execute classic 6502 code without modification inside 64 KiloByte banks
How does the 16MB bank switching scheme work?
I haven't defined the banking yet. I can't bank it all at once or you will lose zero page so I may bank only the upper 8 megs or something. It will have a simple banking system at first. Later we can look into the possibility of a real MMU
The original C-64 expansion port does not offer us the top 8 address lines that a 65816 can ordinarily access. How can we access 24-bit addresses on the C-One expansion port?
The upper 8 bits of the address is time multiplexed and can be captured on the cartridge port with a D type latch (74ls373)
What kind of memory should I use in C-One? How many slots are on C-One mobo?
Use the fastest SIMM module you can find (smallest ns number) (Fast page or EDO, EDO preferred). You can tell the speed by looking at the chips on the module, e.g.: sn14411441 -60 is 60 ns DRAM. The c-One uses a 5v power supply for the SIMM, but the FPGA inputs are tolerant for either 5v or 3.3v. 5v SIMMS are recommended because 3.3v ones might get too hot. There is one DIMM socket which supports 66, 100 and 133 MHz SDRAM modules. DIMMS must be 3.3v (5v's don't fit the socket).
What is the MM Memory?
Video memory and CPU memory are still in the same memory module, but for higher resolutions, this would mean a slowdown for the processor. To get around this, there is a framebuffer that is only updated if the VIC (or other cloned display chip) updates the screen. This framebuffer has it's own strip of memory in a SIMM socket. Since the memory on that module is not restricted to graphics, but music can also be stored any played back without CPU usage, we call this the MultiMedia Memory

The CPU fetches from SDRAM and the SuperVIC also fetches from SDRAM. The SuperVIC outputs a stream of RGB values that are stored into the MM memory. The scan converter/buffer reads the RGB values and displays them at higher VGA scanrates. This system allows any VIC timing (pal/ntsc) to be displayed on any standard VGA monitor. For higher resolutions we can choose the rate the RGB data is streamed from the VIC. For example we could maintain the 8mhz VIC rate and take longer to update each frame or speed up the VIC for faster updates. Another feature is suspending the VIC updates and displaying the last contents of the frame buffer when more CPU cycles are needed

The MM memory (Multi-Media memory) is any standard 72-pin SIMM, parity or non-parity of 60 nano-seconds or more. I think it should be a minimum of 4 Megbytes. The maximum size for the multimedia memory is 128MB. It can be accessed by DMA only (ie you can't execute system programs in it.) The 6502 core excutes code for disk access here. SID and 6502 can access it only. The scan-doubler uses it, but the SuperVIC gets it's data from system memory (SDRAM)
Will C-One work with Commodore and CMD disk drives?
I have tested the prototype with many of the CBM, CMD peripherals and various fast loaders and it seems to work well
Can the 3.5″ drive read and write MFM-encoded (PC format) floppies?
I've built a MFM encoder and decoder that can write at 1.44 data rates. It can read sectors, write sectors, read tracks, write tracks, perform the checksums and seek a track. I've been working on a 6502 core (minus BCD) that has built in opcodes for IDE and floppy, but the biggest problem is that there is no software written yet
Can C-One DMA to/from an IDE drive?
The C-One can DMA from floppy, IDE and compact flash directly to memory which is much faster than a polled system, but the PIO registers are also available
Will the C-One have special DOS for the hard disk filesystem?
This will be up to the programmers. I'm just authoring the hardware at this point
If you have a Commodore 64 core installed in your C-One, how are you supposed to access harddisks, CD-ROMs and other non-tape/floppy kinds of media?
At first: Not at all. The drivers are not available, but they are being worked on. The first thing will be the 1581 emulation, so you can use a cheap 1.44M drive as a 1581 drive from the C64 side. The next step after that will be handling .d81 images on harddisk or compact flash media that is FAT16 or FAT32 formatted, so they are easily interchanged with PCs. A third step after that could be the implementation of a bigger filesystem - anything is possible, the system is re-configurable without having to open the computer, and you can update by downloading cores from the internet
How large of a hard drive is supported?
Not yet defined. At this time I don't think the hardware puts any limit on IDE disk capacity. It will depend entirely upon the IDE filesystem developed by the software people
Will the C1 have a calendar/clock like PCs? This would be cool...
RTC is expensive, because it's not only the chip, but also the batteries, charging circuit and stuff. Of course it's only a few dollars more, but since we have the clock-ports, there's a perfect place to add an RTC for those who want to run OSes that require one
What's this I hear about a 6510 being used as a second processor?
I've added a port that a cpu card will plug into on the new revision and someone can plug a 6809, 6502 or what ever into it. The CPU card will be able to carry the 65816, 6502, 65C02, Z80 and 6809. This will enable the C-One to act like nearly any computer of the 80s just by exchanging the CPU card and the program in the CF card. And yes, the 6510 ports are simulated, and yes, it's possible to add interfaces on the CPU card. The slot will be documented, so third party companies can produce hardware for it
Will there be versions of C-One for other cassic computer systems besides the C-64?
The FPGA can be re-configured with a different program in the CompactFlash card. As soon as there's time and the need for a faster bus (for example a 2nd source vendor wanting to add some features to an existing design), this will be done. I'm really looking forward to playing Atari 2600 games on it, and to turn it into my first machine ever, the Sinclair ZX-81. For instance, Jeri said that she had produced a version that makes the board a VIC-20
Can I put multiple system cores (eg VIC-20, PET/CBM, +4/C16/C116) on the same CF card as the C64 cores? How can I choose one of them at boot time?
Yes. Currently the early startup gives you the choice of up to ten cores that are selected with the numbers 0 to 9 on the PS/2 keyboard. The CF card must be FAT16 or FAT32 formatted, and the core files must be in a directory called BOOT. ROM files are also located as straight binary files on the CF card or harddisk
What prevents a rogue program from re-configuring the hardware against my will?
The early startup flash ROM has a write protect jumper so the machine will never be accidentally rendered brain dead
Does this mean we can expect C-128 support with BASIC 7.0?
C128 is a double-processor design. This will presumably not work with the current concept of the C-One
Is the C-One mainboard fully micro-ATX compliant?
It's a midi-sized board, not micro. Four slots are occupied, where full-size uses five, and micro uses three (the one thing that's important is four slots). The dimensions are 10.58 x 7.38 x 1.5 inches (about 270 x 190 mm), so it is definately not micro-ATX size and the case needs 4 expansion slots. The board will not change more than a 1/4 inch in any direction. MicroATX is defined to be 9.6 x 9.6 inches, so the C-One is in between a full ATX board (9.6 by 12 inches) and microATX, because it uses four slots. To be safe we should say that it requires a standard ATX case. There must be space for C-64 cartridge slot and the clock port expansions that will point down from the clock port.
Are there any plans to shrink the motherboard to fit the Mini-ATX form factor standard? I'd like a small, slick desktop case placed underneath my monitor
No chance to go any smaller. The board is exactly one slot wider than mini-ATX, so it should fit in more cases than normal ATX sized boards
Would the C-One fit in a laptop case? Would it work?
The C-One is a low-power design. The most power consuming parts are the memory modules and (if installed) legacy CPUs. I have two contacts to Asian manufacturers who supply "cases only", that means case, keyboard and display (don't know about batteries and PSUs). The board will not fit in those cases because of all the connectors standing way too high above the PCB. We have a high-standoff DB25 printer port, a double-stack PS/2, and 90 degree memory module slots. A C-One Laptop would be a different PCB, and I doubt that it will have the same specifications due to lack of space (volume and backpanel). Let this be our goal for 2004 :-)
How many PCI slots are there?
The initial plan was to have a single PCI slot for networking. Space allowed us to have a second one, but the order to the Asian supplier was already processed, so we have to deal with what we have, and that's one PCI slot per board. Currently there is only one PCI slot but provisions will be made for a second PCI connector to be added. Soldering on the board should only be done by educated, experienced persons
What kinds of cards will work in the PCI slot(s)?
The reason for the PCI slot(s) is to satisfy the desire for networking, and all networking cards fit perfectly. If you want to connect special things, a riser card may help
I hope the PCI slot will support bus-mastering, otherwise I can't use it for my processor
The PCI slot does support bus mastering (In theory), but it still needs to be tested
PCI is supposed to be a 32-bit bus but 65816 is not a 32-bit processor. How does C-One interface with the 32-bit bus?
Yes, PCI is a 32-bit bus. PCI can DMA to the SDRAM by Bus Mastering. The PCI to SDRAM path is necked down to 16-bit x 60mhz but that is still transparent to the PCI. It will be stalled every fourth longword so the new column can be opened on the SDRAM. Delays would be no problem since a standard PC would do it in regular intervals anyway. The path from PCI to MM memory is 32-bit
How can I access the Compact Flash card when the board is inside an ATX case? Even if I open the ATX case it looks like the CF slot may be blocked by the 5.25 drive bays?
The CF slot can be jumpered as Master or Slave on the Secondary IDE Channel. If you need access to the CF slot from the outside then there are ATA-to-CF adaptors which can be connected to a ATA CF Card Reader installed in a 3.5 drive bay of your case. The C-One's CF card slot can be used either as Secondary slot (if jumpered properly), or you can still use three IDE/ATA devices by leaving the internal CF slot empty. So yes, you can end up with two functioning CF card slots, but this reduces the number of IDE/ATA devices to two

Copper Images and Memory Setup

Making a memory image for startup and using the copper to configure registers

  • On start up the C-One loads the configuration data into the FPGA from the compact flash which tells the C-One what it�s hardware is supposed to mimic (c64 register set)
  • Next the C-One checks for a depressed key. If depressed (the key� not you) check LUT for location in the Compact Flash to DMA Memory image and Copper list
  • When finished with DMA then the Copper is triggered to load registers preset

Example Copper list

Start: Set Register select command $FF
Value Bit(7 downto 0) (VIC, SID, CIA1/CIA2* , KeyLut1, KeyLut2, Red, Green, Blue)
Store Command $FE
Address
Value
Address
Value
Address
Value
Address
Value
Address <= CPU reset control register $d030
Value <= Release CPU�s reset line command1 $55
Address <= CPU reset control register $d030
Value <= Release CPU�s reset line command2 $AA <= released at this point
Wait command $FD

*CIA 2 selected with bit 7 of address byte

The memory image should have the reset vector set to the entry point of the program

C-One�s memory map for startup

0: 0000 => FFFF RAM
1: 0000 => 1FFF Kernal
1: 2000 => 3FFF Basic
1: 6000 => 61FF Character ROM
1: 7000 => Start of Copper list

MonsterSID Data

Programming MonsterSID DMA

This is a very early draft of how the MonsterSID DMA is programmed and will definitely change before the C-One�s release

DMA
DMA is an acronym for Direct Memory Access and is a method of automatically fetching data from memory without the CPU intervention. The M-SID has 8 DMA channels the can function simultaneously. Four directed to the right channel and four to the left. They merge with the channels in front of the filters and volume control, but do not in front of the envelope generators
Resolution
In the current prototype I�m experimenting with a dual channel 16-bit digital-to-analog converter (DAC), but this may drop to 12 depending on the overall machines cost
Pre-scaling
The DMA fetches are derived from a 2MHz tick and are pre-scaled with a 16-bit value. This 16-bit value is used to control the sample playback speed and is independent between channels

Modes

The DMA controller also has two modes of operation
One-shot
In one-shot mode the DMA is triggered from a source and played until it encounters the value FF in the sample data then stops
Continuous
In continuous mode the DMA controller restarts when it encounters value FF in the sample data
Start Position
Each DMA channel has a 16-bit start value to indicate the beginning of the sample
Memory
The M-SID has 64k of non-shared memory. The memory access registers are low address byte, high address byte and data byte. Every time the low address register is written the MonsterSID will write the contents of the data into its memory
Sync and Ring
The DMA Channels can be sync and ring modulated from the waveform generators and the waveform generators can be sync and ring modulated from the DMA channels

The new SID has ports directly to the L/R DAC's so you won't need to use the volume register to play digitized samples. The DMA controller should be considered when coding the new SAM because all you need to write is an speed register, upper memory byte and lower byte. Every time you write a value to the lower byte it starts the DMA running until it reaches 0 in the data or if in continuous mode it loops at the 0

This is what the MonsterSID can do now, but I have a lot of fun features I want to add to the MonsterSID before I ship the C-One!

MonsterSID Q and A

On my own C-64 boards, 6581 uses 470 pico-Farad filter capacitors and 8580 uses 22 nano-Farad filter capacitors. Which type is implemented on MonsterSID?
I was planning on having both values avalable with a jumper
How is sound output provided on C-One?
The two RCA connectors can be connected to your home stereo system. You may use standard PC speakers with the appropriate adaptor
How many filters will the MonsterSID have?
Two, Left/Right
Can the 8 DMA voices and 16 SID voices be used simultaneously?
Yes, 4 left, 4 right, no envelope control and only left/right volume control shared with voices
I'm wondering if I could ask you a bit more about the "MonsterSID"? What sort of frequency range or response does it have? Is it the same as the original? How high can it go???
It's exactly the same freq range as the original
Can the volume control still play digis?
Yes, the vol control can still play digis
I suppose its obvious that the DMA will be used for waveform generation, what sort of output can it generate, 4, 8 or 16 bit? Are all 16 voices the same as the original, with the four shapes? Can you use the voices (pulse) or the filters to produce samples like the original?
(4) 8-bit DMA channels that access a small 64 KiloByte SRAM. The sync and ring can be redirected to multiple channels at once and the DMA channels also
How do they work? Are there 2 DMA and 8 voices per channel? I suppose there is no stereo-SID compatibility? Does using a sample also use a voice? Do all of the DMA share the 64K?
They have two modes of operation, Continuous and One-shot. They each have a register for the playback speed and start index register. When the DMA controller encounters a value of 00000000 it will loop or stop. They work with channel 1/2's voice 1/2's ADSR also. It will need a jumper wire attached when used with a real C=64 to decode the mirrors into the new registers
Will the 64 KB sound buffer be mapped into the C-One's address space?
No it is accessed similar to the VDC in the 128. (Editor's Note: The C-128 VDC is accessed by writing to a "window-register", which does exist in the C-128 memory map. The VDC RAM is external to the system bus and cannot be accessed directly by the CPU. You write values to the VDC RAM by going through the "window-register"
Will MonsterSID have "line in" or "microphone" input?
No plans for these at the moment
I remember hearing something about defining custom waveforms for the SID voices. Is this a planned feature?
The DMA channels can be used to create virtually any shape waveform, but I'm thinking about having adjustible rising and falling edge rates on the waveform generators
8 DMA channels, playback of MODs should be easy, yes? Are you still shooting at 16bit DAC?
Mods should be really easy. It has a 16-bit Sanyo DAC. [For MODs with more than 8 channels] I suppose the Blitter could mix the MODs with the AND miniterm
How would the blitter be of help in audio channel mixing?
Couldn't you set channel 1 to one sample and channel two to another and do an AND function on them?
Any new features in addition to sync, ring modulation, and filters for SID?
The SID has more flexible ring and sync modulation now and can be sync and ring moudlated from the DMA channels. The filters are interesting since they have 5 constants between 127 and -127 which determine the cutoff frequencies. I exposed these to the programmer to adjust, but I haven't tested it yet. I hope this will keep the whiners quiet if it doesn't sound exactly like the original because they can adjust it themselves. The SID's filters can be set with the copper on start up so the settings will always be the way they like them

SuperVIC

Programming The Color Look Up Tables (CLUTs)

The color looks up tables are used for planar and cell video modes to generate a 16-bit RGB color values from an 8-bit addressable table. These 8-bit values give you a maximum of 256 colors per screen assuming you don�t change the CLUTs during the scan and your video mode can support all 8-bit values

The C-One�s 16-bit color output is 5-bits red, 6-bits green and 5-bits blue color intensity which allows a maximum palette of 65535 color

  • The 5-bit red memory location is at $d100 in bank 0, 256 bytes long and entries should be written (MSB XXXXX000)
  • The 6-bit green memory location is at $d200 in bank 0, 256 bytes long and entries should be written (MSB XXXXXX00)
  • The 5-bit blue memory location is at $d300 in bank 0, 256 bytes long and entries should be written (MSB XXXXX000)
If you would like to send a CLUT default startup to be included with the C-One please use this ASCII format
AddressEntry
0:01010;
1:10101;
2:00111;
blah blah blah...
FF:01110;

There should be three files Red Green Blue and all 256 entries must have a value

SuperVIC FAQ

I'm not famliar with graphics. Can anybody explain this in "dummy" langauage, please?
Planar
The color information is made up of many monochrome bitmaps stacked on top of each other and the depth of these stacked bitmaps determine the maximum colors on the screen. Example 4 planes = 16 colors. More about Planar Graphics
Chunky
Every pixel contains 16 bits of color info. PC-style graphics mode that is very wasteful, but allows every color from the pallette to be used on the same screen. More about Chunky Graphics
Copper
It stands for CO-ProcEssoR and is just made up of useful graphics opcodes. More about COPpeR
Blitter
This is a bit mover circuit that can move blocks of data from on memory location to another while performing mask type functions against the data. More about Blitter
Can anybody reply to my previous question about how would the VIC functions work on the C-One? I'm really worried about this :)
The legacy registers are identical to the original VIC-II. To access the extended register you store the magic sequence into a memory location $D02F and all the new registers are mapped $D030 - $D3FF
Color Memory for the VIC-II 40-column display is usually mapped to $d800-$dbff. Will it be possible to relocate Color Memory?
The color attribute memory can be moved anywhere in a 16 MByte space
What kind of video display do I use with C-One?
C-One requires a VGA/SVGA (PC compatible) monitor. VGA was chosen because it supports more display modes with higher resolution and more colors
Can I use my old Commodore monitor (eg 1702 or 1902) or TV?
You cannot use a composite monitor or television because the VGA video output of C-One is not compatible with these devices. Might work if you buy one of those VGA/TV converters. (Editor's Note: The ones I've seen have very poor picture)
What about other Commodore monitors?
Well, there is some speculation on that but we don't really know yet. According to Ville Jouppi the Commodore monitors below might work with C-One. More information to come; No guarantees on this yet!
  • CBM 1403 13 inch VGA
  • CBM 1407 14 inch VGA Monochrome, 64 grey tones
  • CBM 1428 14 inch Multi-sync VGA monitor, no sound
  • CBM 1450 Monochrome BISYNC monitor
  • CBM 1930 14 inch VGA .31mm dot pitch
  • CBM 1934 14 inch VGA .39mm dot pitch
  • CBM 1935-II 14 inch SVGA, .28mm dot pitch, MPR-II low radiation
  • CBM 1936 14 inch SVGA .28mm dot pitch
  • CBM 1940 Amiga Multiscan Monitor
  • CBM 1942 Amiga Multiscan Monitor
  • CBM 1950 13 inch MultiScan
  • CBM 1960 13 inch MultiScan

Why don't you build a VGA/TV converter into C-One?
The VGA to composite converter would be very expensive since the C-One's video timing in some of the modes are out of range of low cost converters. The higher cost converters contain expensive dual port field memories that store an entire frame at a time, then display the data at a lower frame rate. I have to be careful with the adding $$$, since it drives the price up very quickly
Can I use more than one monitor?
There are no plans to support multiple monitors
Ahem. What about us in PAL-land? This has to be made switchable :-)
The video is already switchable between PAL and NTSC and the CPU clock can be set PAL/NTSC. The TOD is updated from the h_sync (60Hz) and will work correctly as it was intended, but what I need to make absolutely sure is that people are not driving the TODs with say 50Hz and setting the 60Hz bit for some reason

It doesn't have a set of registers that you increment for the x,y coordinates, but a start address and modulo that the programmer needs calculate for any given super bitmap

Example:
A chunky super bitmap array that is arranged 2048x1024 pixels located at memory location h1023 and a viewable screen of 320x200.

For cell modes all values need to be divided by the cell size (8 for C-64 cells) and can only scroll by one cell at a time (haha! Thought you were done with the smooth scroll registers didn't ya?) I'm excited to see the demo coders get their hands on this mode!

Do what you call cell modes include character modes or only bitmap modes with cell addressing? Will windowing work in character modes too?
Cell Rasters vs Linear Rasters
When I refer to cells I'm talking about the way the address generator rasterizes the data. Cell raster lines are organized in memory like this-- byte0, byte8, byte16 .....and so on. Linear chunky is-- byte0, byte1, byte2....Super bitmaps work in all modes, chunky, cell and planar Cell Rasters Linear Rasters
byte_0byte_8byte_16byte_24 byte_0byte_1byte_2byte_3

Will there be character modes with more colors per character than the C-64? Will there be new text modes and different font sizes available?
Yes, hopefully this should include all C-65 modes. These will all be illustrated in the documentation
How many colors are available in the various modes?
Is there an 8-bpp chunky mode (ie a paletted, one-byte-per-pixel mode)? A mode like this has plenty of colours for games and since it's a single byte per pixel it should be nice and fast to draw on
Yes, it's already there
Since the C-1 is getting all its pixel frequencies off a single clock - that, coupled with the copper, mean that we'll be able to use Amiga-style draggable screens?
Yes, Everything is synced from one clk
How does overscan work? What's fetched in the borders for all the normal modes?
Nothing unless you set the start and stop registers there. The vertical stop register can cause some strange things to happen if you set them out of the screens resolution. The address generator doesn't reset
How does windowing mode differ from the super bitmaps?
Windowing is the same as superbitmaps. Super bitmaps are set with a line size and modulo to be added at the end of the line. Super bitmaps are really really fast for scrolling in any direction. Almost zero CPU cycles needed to do it. It's going to be very exciting to see what the demo guys will do with it
What about the LCD connector? I'm pretty sure Jeri meant the HD44780 equipped LCDs (common kind of parallel LCDs) when she designed that in
When I said TTL I meant the RGB interface. Some interface at TTL levels, but most today use LVDS which my board doesn't directly support. The TTL LCD's I'm talking about have a parallel interface. Usually 4 bits red, 4 green, 4 blue, hsync, vsync. They were used in older laptops (Apple especially).
I was wondering how the C-One mapped "classic mode" graphics onto a VGA display? I assume that to get full screen at the low res of the C64 that each C=64 pixel is mapped as a chunky VGA pixel? Is this done in HW in the new VIC?
The Final board has a framebuffer that takes care of the higher frequencies. You could consider this as the "flickerfixer" that might be familiar to Amiga users. Even if the VIC is in "full compatibility mode", emulatong 15 khz horizontal frequency, the display output will be sent at VGA rate to the monitor. This gives us the opportunity to sync the VIC (or any other video chip that we want to have) to the CPU, and still have a VGA monitor. Now that the monitor output is decoupled, we can go back to the "old days" when everything on the homecomputers was run off of one crystal (the typical Commodore design)

Blitter Q&A

How does the Blitter work?
Blitter has the same correlators (sp?) and miniterms as the Amiga. Blitter can grab chunks of data and move them around in memory faster than the processor. This works in main memory as well as video memory
What can the blitter do, how is it set up?
The Blitter has two channels you select the start location of each in memory and how long each line is to be. Then the modulo to be added at the end of each line and the length of the blit in total bytes. Then you set the destination, modulo and the function to do with the data (AND, OR, XOR, ROTATE, CORNER-TURN). Then you trigger it or set it to trigger on raster position
Can the blitter move stuff around in main memory or just between main memory and video memory? Is it faster than MVP/MVN?
You can move stuff anywhere in the memory, but the blitter will slow the processor if you are moving in main memory. The blitter is a lot faster than the CPU
I understand the Blitter can move bits between arbitrary memory ranges. Can it spreading the bits out wider as they go? Can it EOR them against a mask before depositing them in the target range? For instance, if page $0400 were full of $FF bytes, could you move them to page $0500 and (by spreading them apart by 1 bit as they go) fill up both pages $0500 and $0600 with $AA bytes?
The blitter will be able to do this
Will the Blitter arguments be 24 or 32 bits wide?
I think I'll keep the source and destination 24 bits with a 8-bit Bank register. The modulus is 16 bits

Technical Details
How is it done? (Technical)
As mentioned, the C-One project is possible thanks to programmable logic technology. Traditionally computers are constructed with integrated circuit chips containing many densly packed logic gates. Each chip is designed to serve a specific purpose and that purpose only. VIC, CIA and 6510 in the C-64 are examples of these traditional integrated circuit chips. Programmable logic chips are able to be custom configured as to what functions they provide. PLA (Programmable Logic Array) 82s100 in the C-64 is such a programmable logic chip which provides functions specifically tailored to the C-64. Recent advances in programmable logic chips makes them affordable and flexible enough for a project like C-One. The FPGA (Field Programmable Gate Array) chips in C-One belong to this latter class of integrated circuits as described below by Jens Schoenfeld:
The two main chips carry out different tasks, depending on the needs of the program. The technology used is called FPGA - field programmable gate arrays. These chips can be programmed to do the tasks that the chips of the C-64 or other computers have done. It's no emulation, but it's a re-implementation of the chips that are no longer available since many years.

The one thing that is not contained in the FPGAs is the main processor - it would take too much space, resulting in too high cost. To maintain flexibility, the CPU resides on a card that can be exchanged by the user - as simple as plugging in a PCI card.

After a cold start, the FPGA programs are loaded from a mass-storage device like harddrive, disk drive or a compact flash card. What's described in one short sentence is a giant leap in computer technology: The hardware can be altered by the user without even opening the computer!

There are two FPGAs, one with 30,000 gates and one with 100,000 gates. The smaller (30K gates) one of the two chips is totally freely programmable and is changable on the fly. We'll publish tutorials, free development tools and code examples to upload new cores into it. The bigger FPGA has 100K gates, and we might be able to increase the board clock from 50 MHz to 60 MHz.

Programming the small FPGA enables you to make your own graphics processor, add DSP-like effects (PAL/NTSC colour smearing emulation), use the flicker-fixer memory for sound (because the Sound DAC is also hooked to the FPGA), add sound decoding hardware, add Blitter functions, do your very own textmodes, hardware-Window management - anything you can think of.

You won't even have to be a hardware person. With VHDL (Virtual Hardware Description Language) and the necessary tutorials, sample sources and an easy design flow, you'll learn very quick what reconfigurable hardware is about. No soldering iron needed! Not only we can turn your base machine into a new computer by supplying a new core for the big FPGA, also you can add completely new hardware features that your program might need.

Think about a game that uses horizontal scrolling - why not make a hardware that copies huge chunks of the display memory on it's own on every vertical blank, and you only have to update the new parts that are scrolled in with the CPU. Think of a mixed-mode of bitplane, chunky and character display on one screen that your CPU benefits from: Imagine an adventure game where the player accesses a computer terminal, the surroundings are bitplane/chunky/high-colour graphics, and the display contents of the terminal are characters, rotated by 15 degrees, slightly distorded because of the perspective. Horrible to solve with CPU horsepower, but easily done in VHDL.

More ideas for the sound: Lowpass/highpass/bandpass filters, frequency shift for the sound as the player enters an underwater world, adding echo/hall effects when he enters the secret chamber of his worst enemy. Make your lowpass filters scream by letting them oscillate on their resonant frequency, and have it sound as fat as a real TB-303 (for those not into electronic music, it's a legendary bass synthesizer Roland).

Not only multimedia applications can be done in the 30K FPGA, also CPU-supporting hardware like a multiplier, divider or run-length encoder/decoder can be made. A perfect sinewave calculation may support your vector-graphics. Speaking of vector-graphics, full matrix calculations could be done! These ALU (Arithmetic Logic Unit) extensions can calculate a lot faster than your CPU can turn around and fetch the result (well, if you're not calculating a fractal in the chip :-)). Why waste CPU horsepower on loading graphics? The 30K FPGA has direct access to the harddrive and the floppy drive, so if you want to show an animation, load the truncated data, unpack then on-the-fly and show them without the CPU ever having touched the data!

The re-configuration of the FPGA can be done as often as you want. It does not wear out (of course!), and the process takes a fraction of a second (as fast as you can transfer 65 KBytes data with your processor), so you can optimize the hardware for anything you want to do at this part of your software (that is, at this game level, or on this screen of your midi-synthesizer software).

Even some pins of the geek port are freely programmable, so you can make your own hardware that communicates with the multimedia/ALU extension part of the computer through your very own, proprietary, optimized protocol. Who needs CPU horse power? We have reconfigurable hardware, the possibilities are unlimited!

Re-configurable hardware is something unknown in the PC world. It's a giant leap in computer technology in that a computer can load it's hardware behaviour on a system reset, and is therefore upgradable in the field. In the case C-One, while the CPU is running, parts of the hardware can be upgraded.

The programs for the two FPGAs are loaded on every system startup, so any bad program can do whatever it likes to, it's set to default on every power-cycle. A cold start (power-cycle) can load the two FPGA programs from harddisk, Compact Flash or from a floppy. The floppy method is by far the slowest, taking about 13 seconds for the 389 KBytes data to be transferred, but it's the easiest method when trying out a new hardware configuration that you just downloaded from the internet. You won't need a CF card reader/writer, the data can be copied from floppy to the CF on the C-One (or to your harddrive).

Re-configuring causes a full shutdown of the slave section for a fraction of a second. I would not rely on data to retain in the memory and neither graphics nor sound will work during the process. No mass storage device can be accessed during re-config. Theonly thing that works is the CPU, it's memory and some ports. Early startup enables mass storage, giving the CPU access to new config files. These config files have to be loaded into the system memory (SDRAM), and then the slave section can be shut down for re-config. After re-config, the mass storage devices are back online, assuming they are not kicked out to make room for other stuff. In such a case, the programmer has to think ahead and have a config file available in system memory to re-configure another time.

The FPGAs are braindead if you switch the C-One on, and they always have to be fully programmed. The entire FPGA has to be programmed. You cannot program a part of the chip. This is done in the early startup procedure which is currently under development. This early startup procedure loads the FPGA cores on every system startup.

The FPGA programming process is about in the few 100 milliseconds range. The current betaboard configures the small FPGA out of the ROM in about a quarter of a second (this is a guess, I never measured the time). This is about the time the CPU will also take for re-configuration, as the slowest part is the FPGA itself. The amount of data to be moved is 65K for the small FPGA and 259K for the big FPGA

You always generate full cores, a composition of Jeri's and your core. If it does not work, try again. You can always go back to where you started. In software terms, you will get Jeri's core as kind of object code that can be linked with your work. Don't worry, you can't kill your machine experimenting with the FPGAs!
Processor Slot (Technical)
Timings:
Making a CPU card always goes together with making a new FPGA core. Since timing on all processors is (at least slightly) different, you'll have to adapt the mainboard to every new CPU. You can re-define certain lines for that, for example the VPA line is not available on the Z80. These lines are GPIOs on the FPGA, and can be turned into anything you may need
  • The only thing you cannot re-define is the BE (bus enable) and the ready lines. As soon as BE is inactive, you have to tri-state the complete bus (address, R/W and data), so other devices can use the board bus (for example IDE DMA). Same for the ready signal, the DMA hardware must be able to halt the processor for an unknown amount of cycles
  • Be careful with clock-stretching for the halting: Some processors (like the real 6502) are dynamic, and forget their internal state if the clock is streched too long. Most CPUs can be halted anyway, and if that's not possible, make your own FPGA core that either uses no DMA at all, or stops the DMA to give the CPU a cycle every now and then. As you can see, the CPUclock line is also a GPIO and can be adapted to your needs as well
  • The re-configurable hardware eases the design of a CPU card a lot. I expect to have only a few parts on a CPU card, especially tristate buffers for those CPUs that cannot tri-state the bus, but other CPUs might be connectable without glue logic
  • We'll publish a reference design for CPU cards about the same time the C-One baords will be released, and that will include a CPU detection scheme. We're thinking of weak pull up/down resistors on the address lines, so the FPGA can read the type of CPU in the slot, and choose the proper FPGA core accordingly
  • MDB[0..7] refers to the multiplexed data bus. During Phi2 low, the data lines carry the upper eight bits of the address (A16 to A23), so the 65816 can come in a 40-pin package although it has much more signals
  • CPU_reset is independant of the entire system reset. Your CPU card must obey this reset signal, because it is only released after all FPGAs have been configured and the memory has been set up for operation (SDRAM needs some init procedure!) No matter what core you're using, the CPU_reset signal is active-low, meaning it's pulled to GND until both FPGAs are configured. This cannot be changed, because it's controlled by the early startup circuit, which is only re-configurable with special equipment and the right CPLD sources. Since this is Jeri's intellectual property, this will not be published. If you need an active-high reset signal, an inverter will have to do
  • Using the CPU slot requires the user to remove the 65816 CPU. The socket and the slot can never be used at the same time. If someone wants to design a dual-cpu card that also incorporates the 65816, he must have a 65816 socket on his card
Bus Speed (Technical)

Those of you who have followed the development of the C-One since the very beginning know that the first prototype was running at a bus frequency of 50 MHz. The January rev 2 prototype which is the base for the currently running production has one significant change: It uses a PLL to generate the bus frequency. This has two big advantages:

  1. the FSB frequency is user-selectable
  2. the C-One will pass CE without any problems

The choices for the FSB frequency are:

  • 33.87 Mhz
  • 50.80 Mhz
  • 52.92 Mhz
  • 67.74 Mhz (Factory Default)
  • 84.67 Mhz
  • 89.96 Mhz
  • 101.61 Mhz
  • 105.84 Mhz
  • 135.48 Mhz

The board will be shipped in the 67.74 Mhz configuration to ensure proper functionality with every SIMM module, which is mandatory for the early startup procedure. This SIMM module must be at least 4 MB in size, and the speed grade must be 60 ns or faster. During our tests here, we cranked up the FSB to 105.84 Mhz, and got the C-One to pass early startup with a high-quality 60 ns EDO memory module. 60ns FPM modules work up to 89.96 Mhz.

These are the absolute maximum ratings. As the memory modules get hot, their speed goes down, and pixels on the screen start flickering. Please also note that the horizontal and vertical frequency of the VGA output also changes with the FSB, so your monitor must support the generated frequencies (which are still being adjusted, we'll publish the actual frequencies later).

The highest FSB frequency of 135.48 Mhz is not supported with the current early startup procedure, and probably will not be any time soon. Other frequencies between the steps given cannot be generated without adding another crystal, which falls under the topic aftermarket tuning, and cannot be done without a soldering iron.

Every core will be made for a specific clock rate. Overclocking a core might be possible, but is really not recommended, just as in the PC world. The different FSB frequencies are meant to add to the flexibility, not to unreliability!

C-One Resources on the WWWeb

Sales and Support

Software

Development and Programming

Pictures and Stories

General Reference

These places have pictures and descriptions of ATX cases and power supplies:

Subscribe to CommodoreOne
Powered by groups.yahoo.com

HOME

This page was last updated August 13, 2005
© Dredd Productions, Ltd
Hosted by www.Geocities.ws

1