[Coco] Introduction

[Jayeson Lee-Steere]

John,

Thanks for the info. You are getting years ahead of me! I was thinking that
attaching one to the Coco cartridge connector port and programming the FPGA
to log bus activity into the SRAM would be good for creating accurate
timing reference for software emulations. That is sounds fairly simple and
in my comfort zone. Anyway, I ordered the 200K gate version. Still need a
prototyping board with the card edge though...

- Jayeson

On Sun, Feb 24, 2013 at 7:51 PM, John Kent <jekent at optusnet.com.au> wrote:

>
> Hi Jayeson,
>
> The XuLA-200 is too small for a CoCo implementation, as it' only has a
> 200Kgate FPGA. It's big enough for a basic 6809 design with serial port,
> PS/2 keyboard and VDU. The CoCo3FPGA design was originally implemented on a
> 1MGate Spartan 3 Starter board, although now the Altera/terasic DE1 board
> is used. The XuLA2, which uses a 1.5Mgate Spartan 6 so would be big enough
> to implement a full CoCo3FPGA design however Gary Becker has only released
> binaries to his CoCo3FPGA design for the DE1 board so it's not possible to
> port it to anything else unless he releases the source.
>
> I did make a start on a 6847 VDG, and a PS/2 keyboard to scan code matrix
> wouldn't be too difficult. I think Mark McDougall has been working on a
> CoCo1/CoCo2 design.
>
> The Altera / Terasic DE1 board has more peripherals on it such as RS232,
> VGA, SD Card, PS/2 interface and so on, so it's easier to implement a
> complete system where as the XuLA boards is more intended to be used with a
> carrier board with the peripherals you want on it.
>
> There is a steep learning curve getting into FPGA design, particularly if
> you want to implement something as complex as a microprocessor core, or
> complete system on a chip although the complexity can vary. Old CPUs like
> the 68XX, 65XX and 8085/Z80 essentially consist of a state machine that
> generates the instruction cycles which is controlled by the opcodes and
> controls the data paths to the registers, ALU, condition codes and memory.
>
> Modern designs tend to be pipelined RISC Harvard architectures that latch
> the internal signals and register values between stages so that the
> instruction cycles can be run in parallel. You typically have instruction
> and data cache connected to shared memory so that you can be reading
> instructions and reading and writing data at the same time. The CPU
> arbitrates external memory access between data and instruction cache. A
> RISC piplelined CPU design would be the logical next step for me to take,
> although there are already quite a few open source RISC CPU architectures
> out there.
>
> VHDL & Verilog are similar in many ways to many standard programming
> languages. The thing to remember is though that you are generating a
> hardware description rather than a set of instructions to execute on a
> computer. A computer is effectively time division multplexing the ALU logic
> between variables in memory.
>
> Some people think that the transition from software to a hardware
> description can be a difficult change to make, although personally I didn't
> find that. Having some hardware design experience helps and having a fair
> idea of the nature of code generated by software compilers helps also in
> understanding what the synthesis software is doing. If you understand the
> code generated by switch / case statements in C and can see the analogy to
> a hardware decoder chip then you have a fair idea of what a case / when
> statement in VHDL generates.
>
> If you want to get into FPGAs I suggest you start off with a simple
> project and work your way up. There are web sites that have open source
> FPGA cores that you can study and learn how they are designed. The appeal
> for me is trying to understand how the chips that I have used in digital
> designs over the years work.
>
> If you understand the basics of digital design it's not hard to use the
> basic building blocks to create a new design for whatever you want. It just
> takes a bit of persistence, enthusiasm and dedication to getting there.
>
> John.
>
>
> On 24/02/2013 9:19 PM, Jayeson Lee-Steere wrote:
>
>> John, I was just looking over your FPGA pages. Always wished I could just
>> whip up whatever I want with one, but the barrier to entry is fairly high.
>> I know logic well enough but those languages seem like Voodoo to me. Still
>> the XESS XuLA boards look like a semi-easy place to start. I'm thinking
>> one
>> of those mounted on a board with a Coco cartridge connector, implementing
>> a
>> Dungeons of Daggorath ROM and logging the bus signals would be just the
>> ticket...
>>
>> - Jayeson
>>
>>
>>
> --
> http://www.johnkent.com.au
> http://members.optusnet.com.**au/jekent<http://members.optusnet.com.au/jekent>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/**mailman/listinfo/coco<http://five.pairlist.net/mailman/listinfo/coco>
>