DE1 Coco3FPGA

[tcdev]

This now builds without error. However, I can't test it atm because I don't have a spare VGA monitor. I'll endeavour to test it tomorrow.

[aaronwolfe]

This now builds without error. However, I can't test it atm because I don't have a spare VGA monitor. I'll endeavour to test it tomorrow.

When I try to build, I get the following errors:

Error: Node instance "GLBCPU09" instantiates undefined entity "CPU09"
Error: Node instance "coco_keyboard" instantiates undefined entity "COCOKEY"
Error: Node instance "COM1" instantiates undefined entity "glb6850"
Error: Node instance "COM2" instantiates undefined entity "glb6551"

Any ideas? I might just be doing something wrong. I just did a new checkout from svn and loaded the coco3-becker.qpf in Quartus, hit build.

[tcdev]

You need to unzip the COCO3FPGA_V1.1.zip file into a directory named "unzip" in the same directory as the zip file (i.e. src/platform/coco3-becker/unzip)

[aaronwolfe]

yes, that makes a big difference :) it now builds with some warning but successfully.

sending it to the board results in the dACE display on the 7 segment and night rider lights, but little else. again I may just be doing something wrong, will consult docs more and wait till you have time to test.

thanks again.

[boisy]

yes, that makes a big difference :) it now builds with some warning but successfully.

sending it to the board results in the dACE display on the 7 segment and night rider lights, but little else. again I may just be doing something wrong, will consult docs more and wait till you have time to test.

thanks again.

Aaron, good news. I emailed Mark and he thinks its a simple issue to fix and will get to it soon. I'm anxious to try it out on my DE1. Thanks again Mark for your efforts.

[tcdev]

Hmmm.... seems I have given people a bit of a bum-steer....

I could've sworn I had it running on the DE1, but now I see I've only ever had it running on the DE2 and P2/A (custom) hardware. These boards have an EP2C35 on them, with more RAM. The Coco3FPGA as-is doesn't fit on the DE1's EP2C20.

However, it should be a relatively simple matter to move the ROM images into the DE1 flash memory. I'll get right onto it. I've already fixed one problem, which was causing it to build in a matter of a few minutes - a sure sign something isn't right.

Stay tuned!

[tcdev]

I've just finished modifying the project for external ROMs in flash, and it builds OK. Only ~50% logic utilisation...

Trouble is, I'm at home and my DE1 is at work. So I can't test until tomorrow morning... :(

[boisy]

I've just finished modifying the project for external ROMs in flash, and it builds OK. Only ~50% logic utilisation...

Trouble is, I'm at home and my DE1 is at work. So I can't test until tomorrow morning... :(

This is the 32K CoCo 3 ROM correct? I was reading through Gary's document and it appears that he includes logic for the MPI, ORC-90, and several game ROMs. I presume those are part of the 50% utilization?

Anxious to try this out here on my DE1. Please let us know the results of your tests and when you have updated the svn repository. Thanks.

[tcdev]

Yes, you need to move the various BASIC and ROM-PAK roms out of the FPGA on-chip memory and into the flash on the DE1. It's a little messy because Gary has a separate ENA for each 2KB block, and because I'm fixing it in a rush I've simply exported those signals and then re-encoded them into high-order address lines on the flash.

Sorry to say, the 1st pass doesn't quite work. But at least now I get some video output. I'm not entirely surprised - it has all been a quick hack job spread over a series of free 5-minutes slots whilst waiting for the wife, cooking dinner, etc. Not conducive to error-free FPGA design I'm afraid. :(

I *will* find time very soon to sit down and get it going, and to do a nicer job of it. I'm torn between absolutely minimising the changes required from Gary's original file (in order to better accommodate his future updates), and moving the rom files outside Gary's main coco3fpga.v file. There it's much cleaner to implement build-time options of using external flash on smaller FPGAs, and for still using on-chip RAM and simply instantiating them at a higher level in the design.

FWIW once the roms are in flash, it might then be viable to add an option for programming the flash with a series of rompak images, selectable by the DE1 switches, as an extension to the MPI implementation.

I'd like to say I'll get it done at lunchtime, but I'm on a very short day today as I'm going up the coast this afternoon for the night. I will almost certainly get the time to do it tomorrow night though - the wife is out with the girls.

Sorry for the delay, I know what it's like to have a new toy and not be able to use it. Perhaps you should grab the official Minimig .SOF, load up an SD card with some cool Amiga games, and have a play with that until the Coco is ready? Now *that* is an impressive effort!!! :cool:

[tcdev]

I will almost certainly get the time to do it tomorrow night though - the wife is out with the girls.
On again, off again, on again - the result - I left the ^%$ #@ DE1 at work and, with no car, couldn't go in and pick it up. :mad:

At least I actually got time to play the PS3... Ridge Racer 7 demo - nice!!! :cool:

[boisy]

On again, off again, on again - the result - I left the ^%$ #@ DE1 at work and, with no car, couldn't go in and pick it up. :mad:

At least I actually got time to play the PS3... Ridge Racer 7 demo - nice!!! :cool:

Awwww, I was really looking forward to having the CoCo 3 to play with this weekend. Kidding aside, do you think it will be working soon?

[tcdev]

Awwww, I was really looking forward to having the CoCo 3 to play with this weekend. Kidding aside, do you think it will be working soon?
I've brought the DE1 home to work on it tonight. I would like to think that I can get it going tonight! Fingers firmly crossed... :D

[tcdev]

Good news. I've just checked in a working version for the DE1.

Still making a few cosmetic improvements, and will check in again later tonight.

If you're really impatient, here's what you need to do:

1. Get the latest source tree from SVN
2. Using the DE1 Control Panel Software, program the flash with the sw/src/platform/coco3-becker/roms/coco3roms.bin file
3. Open the coco3-becker Quartus project and re-build
4. Program the DE1 FPGA and viola!

I'm yet to check the serial link (floppy emulation), but I'll do that tonight too...

[tcdev]

The good news:

* Coco BASIC and Disk Basic working OK
* DE1 buttons and switches now hooked up
* Disk commands sent to server via RS232

The bad news:

* Disk commands crash the Coco.

No idea why atm. Might have to go back to DE2/P2 hardware and see if there are any hints...

[boisy]

The good news:

* Coco BASIC and Disk Basic working OK
* DE1 buttons and switches now hooked up
* Disk commands sent to server via RS232

The bad news:

* Disk commands crash the Coco.

No idea why atm. Might have to go back to DE2/P2 hardware and see if there are any hints...

I've managed to get it running but noticed, as you did, that disk commands bring the machine into a tailspin. Other notes:

- The KEY0 button does not act like Gary says in his docs (emulates holding the CTRL-ALT button). Instead, pressing KEY0 acts like a reset.
- Even after powering off and on the board, and reloading the SOF file, I notice that I don't get the full DECB sign-on but instead the OK prompt at the top of the screen. It's almost as though the CoCo 3 isn't fully reset properly.

I've got the server utility up and running on the Windows 7 side, but I guess until the issue with the serial port and disk commands are resolved things are in limbo.

We're closer!

[tcdev]

The KEY0 button does not act like Gary says in his docs (emulates holding the CTRL-ALT button). Instead, pressing KEY0 acts like a reset.
I noticed that too, and was a little puzzled myself. I can't recall if I've ever seen the "Easter Egg" work on the Coco3FPGA. I'll have to revisit the button mappings and see if there's anything stupid I've done...

[An aside - the DE1/DE2 buttons are notoriously prone to failure. My buttons are a bit dodgy now, and I need to press some of them quite hard to have them register. I guess it's only a matter of time before they start to fail altogether.] :mad:

Even after powering off and on the board, and reloading the SOF file, I notice that I don't get the full DECB sign-on but instead the OK prompt at the top of the screen. It's almost as though the CoCo 3 isn't fully reset properly.
This has long been an issue. I suspect that the SRAM is retaining its contents sufficiently well during power-off due to the board receiving power via the USB port (you can actually run a lot of designs solely off USB if the board is sucking less than 500mA). A POKE 113,0 before reset does result in the banner being displayed again.

I've got the server utility up and running on the Windows 7 side, but I guess until the issue with the serial port and disk commands are resolved things are in limbo.
Yup. I'll keep working on this as I get the chance. Since it all runs on the DE2/P2, there can't be too much wrong...

[boisy]

I noticed that too, and was a little puzzled myself. I can't recall if I've ever seen the "Easter Egg" work on the Coco3FPGA. I'll have to revisit the button mappings and see if there's anything stupid I've done...

[An aside - the DE1/DE2 buttons are notoriously prone to failure. My buttons are a bit dodgy now, and I need to press some of them quite hard to have them register. I guess it's only a matter of time before they start to fail altogether.] :mad:


This has long been an issue. I suspect that the SRAM is retaining its contents sufficiently well during power-off due to the board receiving power via the USB port (you can actually run a lot of designs solely off USB if the board is sucking less than 500mA). A POKE 113,0 before reset does result in the banner being displayed again.


Yup. I'll keep working on this as I get the chance. Since it all runs on the DE2/P2, there can't be too much wrong...

FYI, I had to unplug both the power connector AND the USB for power to be completely drained. Let it stay off for about 30 seconds then plugged everything in and I got the full ECB sign on again. If you leave the USB plugged in, the board still has power!

Also button 2 acts to halt the CPU, but I have noticed that at times, when I hold down and then release, the CoCo crashes.

[tcdev]

Also button 2 acts to halt the CPU, but I have noticed that at times, when I hold down and then release, the CoCo crashes.
Gary's documentation warns that this can cause the system to be unstable, and that it shouldn't be used extensively. Reading between the lines, I'm guessing it means the Coco may crash when using it.

I've just re-built the existing source base for my P2A hardware, and it runs OK, including disk transfer commands. I'm now re-building for DE1...

The only difference between the two should be the roms being read from flash on the DE1, as opposed to internal RAM for the P2A. Both are Cyclone II devices, so the differences should be minimal.

The only suspect is the new ROM image I created from Gary's verilog files, though since that process is automated with a batch file, I can't see where it could go wrong. I've checked and double-checked the order and assignment of flash addresse lines and enable signals - still nothing. :confused:

Guess I need to look a little closer...

[tcdev]

As I get the chance here and there, trying a few things...

This morning I was looking at the timing. Have vastly improved the timing performance of the build - the number of failed paths is down from 460+ to 60, and there's not really anything left that could conceivably cause the Coco to crash. So I've eliminated that cause...

Time to look at the bigger picture, and also re-confirm the ROM image...

[tcdev]

Gary has given me some clues about the problem...

The BASIC and DISK BASIC ROMs are read into RAM at bootup, where they are patched by the Coco3, so the flash shouldn't be an issue.

However, when the system is reading from "disk", the CPU speed is switched to max. :eek: Looks like this is the heart of the problem. I'll focus on this area.

[boisy]

Gary has given me some clues about the problem...

The BASIC and DISK BASIC ROMs are read into RAM at bootup, where they are patched by the Coco3, so the flash shouldn't be an issue.

However, when the system is reading from "disk", the CPU speed is switched to max. :eek: Looks like this is the heart of the problem. I'll focus on this area.

Thanks for the hard work! I presume Gary is back from his out of country trip?

[tcdev]

Thanks for the hard work! I presume Gary is back from his out of country trip?
Apparently not - he said I was "lucky" that he got the email so quickly... :D

[tcdev]

Yesterday afternoon I built the DE2 version, using internal RAM. Got plenty of timing errors - much like the DE1 initial bild - but it still ran flawlessly.

I've built the external ROM version, but have to wait until I get into work to try it out. If that fails, then I can't see how it could be a timing problem. :confused:

[tcdev]

This is actually good news! :D

Because the DE2 runs perfectly well with the ROMs in on-chip RAM, this means that there is something wrong with my changes for running the ROMs in external flash.

Next step - "emulate" the flash in the DE2 version in internal ram.

[tcdev]

I'm beginning to suspect that the problem is Coco3FPGA accessing the flash at 25MHz. The DE1 flash is 70ns - 25MHz == 40ns. I need to examine the flash access cycles in more detail...

FYI I put half the roms in flash, and half in on-chip RAM. I managed to get a disk directory working, but it was unreliable.

[boisy]

I'm beginning to suspect that the problem is Coco3FPGA accessing the flash at 25MHz. The DE1 flash is 70ns - 25MHz == 40ns. I need to examine the flash access cycles in more detail...

FYI I put half the roms in flash, and half in on-chip RAM. I managed to get a disk directory working, but it was unreliable.

Good detective work. Sounds plausible. Is there a way to slow down access to the flash specifically without affecting access times for the rest of the devices?

[tcdev]

Good detective work. Sounds plausible. Is there a way to slow down access to the flash specifically without affecting access times for the rest of the devices?
Sorry for the delay. Aside from work, I've been busy finishing up a TRS-80 (Model 4) software project that was 95% done when the DE1 Coco3FPGA came along. It had been languishing for over a week, having previously promised an imminent release, and I really needed to knock it off whilst it was fresh in my mind and I hadn't forgotten how everything works. It's done now; just needs a little more play-testing and I'll announce it on the relevant newsgroups in a few days.

An aside - I had resolved recently not to juggle too many projects simultaneously as I have been known to do in the past, resulting in plenty of things on the boil, but absolutely ZERO finished. I need to adhere to having only 1 (or perhaps 2) projects going at any one time, and seeing them through.

That said, I can now devote full attention to the Coco3FPGA on DE1, and I will not be working on any other projects (I have another TRS-80 project lined up) until it's working. It has me puzzled atm, as the flash should only be accessed during system boot as the Coco 3 copies the ROMs into system RAM. My last build did have some diagnostic signals, but didn't manage to shed any light on what was happening. I think what I need to do now is set up a simulation for the whole system. There's a bit of work involved in that, I'll keep you posted.

Again, sorry for the delay.

[aaronwolfe]

that's great news, i have been lurking and following the progress here. thanks for working on this one :)

[boisy]

Has there been any progress made on the CoCo 3 FPGA DE-1 port? The last message was on February 16th, almost a month ago.