[Coco] FPGA 6809

Tue Sep 1 00:06:41 EDT 2015

Well I think part of the problem is that there is some hardware that 
exists on the DE1 that is not on the Nano.  For example, the SD card, 
the SRAM, the sound subsystem, etc.  Also when you refer to ROMs I 
suppose you mean the flash chip on the DE1 which is also not on the 
Nano.  Otherwise, in some cases ROMs are implemented using memory 
elements inside the FPGA which I would imagine your Nano has more of 
than the DE1.

Gary told me he is close to releasing the source on his project so we'll 
see.  I know he's put a lot of work into it and is still working on a 
few little buglets.  What I would like to see is a sort of hybrid 
project where we take an FPGA and synthesize the GIME chip, 6809 CPU, 
and a few other things but then we added some of the analog hardware for 
joysticks, cassette, sound and we slap all of that on a mainboard that 
is exactly the same size as the CoCo 3 mainboard.  You could even design 
it with a socket for a real 6809/6309 that could be swapped in or out 
for 100% compatibility. Instead of a cartridge slot you could replace 
the opening with some a couple of expansion headers.  One would allow 
you to connect it to a 3rd party MPI.  The other would allow for 
expansion from the FPGA like serial I/O, RTC, etc, etc.  Then you mount 
it in your old CoCo 3 case and you're ready to go with a 100% compatible 
or a speed demon that is 95% compatible.

Actually, I'm not much of a gamer so the joysticks and sound aren't so 
important.  At 25 MHz if you had a nice audio DAC you could reproduce 
almost any sound almost effortlessly.  With a good sized SD card and 
some wav files NitrOS9 could do that as a background task with very 
little performance penalty.  I'm more interested in specialized embedded 
applications like data logging, robotic control, GPS, and things like that.

Dave Philipsen

On 8/31/2015 10:43 PM, Bill Nobel wrote:
> You know Dave, that is exactly what I am after.  Having a standalone Coco3 on a hardware layer that I can expand.  These FPGA’s have inspired me along with Grant’s and John Kent’s 6809 vhdl code to get that.  I have prodded Gary Becker for his code and have it for ver. 1.1, but I can’t get it to compile on my DE0.  He has told me there is a conversion in process for the DE0 (We have seen the boards already for VGA).  He uses verilog for his source and the ROM’s don’t compile in my Quartus, as these files seem specific to the boards he tests with.  I don’t know if Roger will ever release or sell his project, but he is still in development stage now.
>
> Bill Nobel
>
>> On Aug 31, 2015, at 9:26 PM, Dave Philipsen <dave at davebiz.com> wrote:
>>
>>
>> On 8/31/2015 9:43 PM, Bill Pierce via Coco wrote:
>>> Dave, there are actually multiple problems in trying to assemble any of the Nitros9 stuff from the repo on a Coco (or cocofpgs/emulator) in NitrOS9.
>>>
>>> First, changing a name in one file, means you need to search EVERY file in the repo for any other reference to that name, including the defs.
>> I'm not sure I'm following you.  What name would be in a source file that would be referenced in other source files?  Isn't that what the defs files are for?
>>> Second, ALL the defs need massaging and renaming as the original names have been changed making them absolutely useless from within NitrOS9 itself. You need the new defs because a lot has been added. I have most of the defs converted so I can use the newer system calls in my projects.
>> Well, I think I must have the new defs files because I would think that I wouldn't have been able to assemble Boot without errors if I hadn't.
>>> Third, in ALL the sources, all the "Section" stuff needs to be removed and in cases of "rma" sources (there are a couple), "section" needs to be replace by "psect" & "endsect" and all variable put in "vsect" and "csect". In some of the "asm" stuff, the:
>>>   
>> I will take a look at that although so far I'm not seeing any references to those terms.
>>>   ifp1
>>>   use /dd/defs/os9defs
>>>   endif
>>>
>>> has been removed and needs to be added (lwtools is one pass so it isn't needed).
>> Are you saying that an assembler operates in a single pass?  How is that possible?  How are forward references resolved?
>>> Forth, ALL the "multi-platform/multi-cpu" stuff has to be addressed (in every single file). Unless you set some equates, this stuff will drive you up the wall as EVERY file has conditionals for 2 or more build types.
>> Yes, I see that.  I've had to set some equates but so far it hasn't been too daunting.  Of course I'm not re-assembling every module....just working on Boot, REL, and Krn for now.
>>> There are a few other problems that I can't recall at the moment, but I know there is more.
>> Another problem I've already run into is the Pad directive.  I found this in the Boot module already although I don't think it should need to be used much in other modules.  Not a big problem as I can assemble and then go back and put in the right number of padding bytes and re-assemble.
>>> I started a project a while back to convert the nitros9 sources to standard OS9 format, but put it aside due to the repo was being overhauled at the time, so I moved on to other projects. It is a much bigger task than you would think!
>>> I would love to see NitrOS9 compile under NitrOS9 for a change. That would be AWSOME!.
>> I would have to agree with you on that.  I'm not trying to be critical but it seems that NitrOS9 is kind of dependent on the PC not only for assembling the modules and programs but the drivewire connection seems a little awkward in some cases to me.
>>
>> I'm definitely not bashing drivewire!  It has its place and it has been very handy to me at least for the time being because I have just recently come back to the CoCo after an almost 22 year hiatus and all I have is two brand new CoCo3s with 128K and my DE1 board for CoCo3 FPGA.  All of my disk drives, modem, MPI, B&B HD, RS232 Pak, etc. are gone.  I can't even remember exactly what happened to them over the years.  I am fortunate to have these two CoCos but even more fortunate to have the CoCo3 FPGA.  I can remember assembling the source for SuperCom back in the 80s and going of to get a snack while it crunched away (at 1.79 MHz).  Now, the 25 MHz CoCo3 FPGA especially with the SD card drivers just flies!
>>
>> Anyway, my desire to get the CoCo3 FPGA to be standalone is driving me to get this done.  And when I get it working I'll have some code that perhaps I can use on the Multicomp and maybe some other projects to get them running with NitrOS9 (maybe even Level 2).
>>
>> Dave
>>
>>> Even with the emulators, you can overclock the CPU and assembly is EXTREMELY fast. I do this in compiling C sources in NitrOS9 on Vcc. I compile at about 72mhz and a 125 file multi-source project (HUGE!) compiles in less than a minute. On a real Coco this takes about 3-4 hours.
>>>
>>>   
>>>   
>>>
>>> Bill Pierce
>>> "Charlie stole the handle, and the train it won't stop going, no way to slow down!" - Ian Anderson - Jethro Tull
>>>
>>>   
>>> My Music from the Tandy/Radio Shack Color Computer 2 & 3
>>> https://sites.google.com/site/dabarnstudio/
>>> Co-Contributor, Co-Editor for CocoPedia
>>> http://www.cocopedia.com/wiki/index.php/Main_Page
>>> Global Moderator for TRS-80/Tandy Color Computer Forums
>>> http://www.tandycoco.com/forum/
>>>
>>> E-Mail: ooogalapasooo at aol.com
>>>
>>>
>>>   
>>>   
>>> -----Original Message-----
>>> From: Dave Philipsen <dave at davebiz.com>
>>> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
>>> Sent: Mon, Aug 31, 2015 9:47 pm
>>> Subject: Re: [Coco] FPGA 6809
>>>
>>>
>>> Ok, so besides stripping all of the linefeeds and tabs I need to check for
>>> labels that are longer than eight characters.  That shouldn't be too tough to
>>> fix.  Right now, I'm assembling Boot with no errors and Krn is giving me a few;
>>> maybe 15-20.  I'll have to go look at the repo again. When I looked in the defs
>>> folder today (well at least ONE of the defs folders) the defs files I mentioned
>>> were nowhere to be found.
>>>
>>> Any progress on Multicomp-DE0?
>>>
>>> Dave Philipsen
>>>
>>>> On
>>> Aug 31, 2015, at 8:33 PM, Bill Nobel <b_nobel at hotmail.com> wrote:
>>>> That
>>> would be the reason why.  The source in SourceForge is setup for Toolshed to be
>>> compiled on a pc.  The labels in the code are setup to be longer than 8
>>> characters, which asm in Nitros9 ignores everything beyond.  Even if you get it
>>> compile you will get multiple define errors.  The DEFS files are in the repo
>>> under defs folder.
>>>> Bill Nobel
>>>>
>>>>> On Aug 31, 2015, at 6:50 PM, Dave
>>> Philipsen <dave at davebiz.com> wrote:
>>>>> I don't think so.  To be totally
>>> honest I'm not exactly sure how that works.  I'm assuming that the fitter will
>>> assign pins for you if you don't manually assign them.  If you go into the Pin
>>> Planner it should show you a diagram of the FPGA and then below that there is a
>>> section where you can see all of the pin assignments. You should be able to
>>> scroll down to the bottom of that section and double click on <<new node>> to
>>> make a pin assignment.
>>>>> Quick question on NitrOS9:  Where are the defs
>>> files found in the repository?  I am using some defs files that someone else
>>> gave me on a boot disk image but when I try to assemble the Krn module it is
>>> choking on terms like "D.MLIM", "D.FMBM", "D.BTLO", and a few others.  I have
>>> fairly recent defsfiles (2011) and the defsfile uses os9defs, rbfdefs, scfdefs,
>>> and systype.  Am I missing anything?
>>>>> Maybe I'm crazy for assembling this
>>> directly under NitrOS9 but the assembler works pretty quickly at 25 MHz.  I
>>> don't have the cross assembler and the dev system set up on a PC.
>>>>>
>>> Dave Philipsen
>>>>>> On , Bill Nobel wrote:
>>>>>> Would that be the fitter
>>> pins in the pin planner?  I saw those there
>>>>>> and I thought it was a suggested
>>> pin.
>>>>>> Bill Nobel
>>>>>>> On Aug 31, 2015, at 4:30 PM, Dave Philipsen
>>> <dave at davebiz.com> wrote:
>>>>>>> Just something else I thought of:  When starting
>>> a project out from scratch (i.e. CoCo3 or 6809 core on FPGA) there are some
>>> things to take into consideration when assigning pins to devices.  The Altera
>>> FPGAs are divided into physical banks and Altera suggests that the high speed
>>> signals such as address or data lines be grouped together within a bank or
>>> adjacent banks if at all possible.  Also, at least on some devices, there are
>>> certain banks that they consider more well suited for high speed stuff.  If you
>>> do a little research on the 'net you'll find some notes on this in the design
>>> considerations.
>>>>>>> Dave Philipsen
>>>>>>> --
>>>>>>> Coco mailing list
>>>>>>>
>>> Coco at maltedmedia.com
>>>>>>> https://pairlist5.pair.net/mailman/listinfo/coco
>>>>> -- 
>>>>> Coco mailing list
>>>>> Coco at maltedmedia.com
>>>>>
>>> https://pairlist5.pair.net/mailman/listinfo/coco
>>>> -- 
>>>> Coco mailing
>>> list
>>>> Coco at maltedmedia.com
>>>>
>>> https://pairlist5.pair.net/mailman/listinfo/coco
>>>
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus <https://www.avast.com/antivirus>
>>
>>
>> -- 
>> Coco mailing list
>> Coco at maltedmedia.com <mailto:Coco at maltedmedia.com>
>> https://pairlist5.pair.net/mailman/listinfo/coco <https://pairlist5.pair.net/mailman/listinfo/coco>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus