[Coco] FPGA 6809

Dave Philipsen dave at davebiz.com
Mon Aug 31 12:42:50 EDT 2015


Ok, so here are a couple of things to check on your DE0 nano:

The 50 MHz clock oscillator comes in on pin R8.  In the Quartus Pin 
Planner you should have an entry with "clk" as the node name, direction 
as "Input", and location as "PIN_R8".

One of the pushbutton switches comes in on pin J15.  In the Pin Planner 
you should have an entry with "n_reset" as the node name, direction as 
"Input", and location as "PIN_J15". With this setup KEY0 will become 
your reset button.

In the assignment editor you can add an entry that assigns a weak 
pull-up resistor to the n_reset signal.

I found these locations by downloading the DE0 nano manual from Terasic. 
  On my DE1 board, of course, they are at different locations but I do 
recall having to get those set before the board would do anything.

My earlier reference to the VHDL being like C code was more pertaining 
to the syntax of it and the way it's laid out.  I realize that VHDL is 
not a programming language that sequentially steps through lines of code 
but it does bear some resemblance to C code in some ways.

Dave Philipsen


On , Bill Nobel wrote:
> I have done a few different schemes for this.  The only thing to
> remember is that KRN is the only module that needs to be placed at a
> certain location in memory (the very top end of 64k) as the tail end
> of KRN has the reset and IRQ vectors that the 6809 relies on to do
> it’s  power up and IRQ processing.  I have done a preload using DOS to
> get a program loaded that then processes a lot more.
> 
> Bill Nobel
> 
>> On Aug 31, 2015, at 12:14 AM, Dave Philipsen <dave at davebiz.com> wrote:
>> 
>> Ok, I knew I'd seen your name floating around somewhere....must have 
>> been when I downloaded the NitrOS9 stuff from Sourceforge.  You're 
>> just the guy I need to talk to then!  Here's my current dilemma:
>> 
>> I see that the Boot, REL, and Krn modules reside on the boot track and 
>> they are limited in size to $1200 bytes.  I have surmised that this 
>> limitation is due to the fact that the originally floppy storage 
>> medium had $1200 bytes in a track and it was convenient to load in one 
>> track (track 34) and then relocate that data to a more convenient 
>> place in memory.  There, the Boot module has just enough smarts to 
>> initialize the storage device and read raw sectors.  The Krn module 
>> has just enough of the OS9 system to get the rest of the operating 
>> system loaded in from the OS9Boot file.  Well, the code I have for 
>> initializing the SD card and for reading sectors so far is just a 
>> little too large to fit into the space of the existing Boot module.  
>> Additionally, it seems there are some 'hard-coded' portions of these 
>> three modules and that is why there is some padding in the source code 
>> so that the modules always retain a certain size.  So my question is; 
>> wouldn't it be possible to adjust these three modules to allow for a 
>> slightly larger boot track?  I'm thinking that instead of loading the 
>> boot track from $D00 - 1F00 perhaps we could add two more sectors and 
>> copy the boot track with a size of $1400 to the area of $B00 - 1F00 
>> (of memory block 3F).  This obviously wouldn't work on a real stock 
>> CoCo 3 since the DOS command is hard coded to load just 18 sectors but 
>> I'm loooking more at a customized version.  There is another way to do 
>> this too and that would be to do a two-step load of the boot track but 
>> I'm not really keen on that idea.
>> 
>> Dave Philipsen
>> 
>> 
>> On 8/31/2015 12:49 AM, Bill Nobel wrote:
>>> I definitely agree with the Nitros9 part, as I am part of the 
>>> creators.  I am so looking forward to SD card and possible TCP/IP via 
>>> RS-232 (beyond DriveWire).
>>> 
>>> Bill Nobel
>>> 
>>>> On Aug 30, 2015, at 11:41 PM, Dave Philipsen <dave at davebiz.com> 
>>>> wrote:
>>>> 
>>>> I have not yet seen Roger's project.  Does he have a website?  I 
>>>> definitely like what Gary has done on the DE1.  To me there is 
>>>> nothing like having a standalone little 6809 computer that can run 
>>>> NitrOS9 at 25 MHz!  Gary just released a new version with support 
>>>> for SD cards and I'm working on getting it to boot OS9 from the SD 
>>>> card with some software that will allow me to create partitions on 
>>>> the SD card.  Drivewire is a nice concept but for some reason I just 
>>>> can't warm up to the idea of having to have a PC running next to my 
>>>> OS9 computer.  It's great for printing or accessing the internet I 
>>>> guess but I really like the fact that we're getting really close to 
>>>> having a relatively fast little computer that boots NitrOS9 on its 
>>>> own, requires very little power, and has plenty of on-board storage 
>>>> capability.
>>>> 
>>>> Dave Philipsen
>>>> 
>>>> 
>>>> On 8/31/2015 12:19 AM, Bill Nobel wrote:
>>>>> That is correct.  I would like to achieve various 6809 systems (the 
>>>>> main being a Coco).  Yes Roger & Gary Becker have their projects 
>>>>> going (I prefer Gary’s better) I tried taking Grant’s code direct 
>>>>> to De0 with pin re-assingment. This didn’t work under newest 
>>>>> versions of Quartus, so I have been trying to fix the varieties for 
>>>>> my own sentiment.  Once I have them working Everyone gets.
>>>>> 
>>>>> Bill Nobel
>>>>> 
>>>>>> On Aug 30, 2015, at 10:58 PM, Dave Philipsen <dave at davebiz.com> 
>>>>>> wrote:
>>>>>> 
>>>>>> Interesting.  So when you are speaking in terms of "bdf" does that 
>>>>>> mean you are actually drawing a schematic for your implementation?
>>>>>> 
>>>>>> Dave
>>>>>> 
>>>>>> 
>>>>>> On 8/30/2015 11:52 PM, Bill Nobel wrote:
>>>>>>> Exactly what I am talking about David.  Grant defines his CS 
>>>>>>> lines in code vs .bdf (or symbols) My knowledge of FPGA’s is in 
>>>>>>> schematic form.
>>>>>>> 
>>>>>>> Bill Nobel
>>>>>>> 
>>>>>>>> On Aug 30, 2015, at 10:46 PM, Dave Philipsen <dave at davebiz.com> 
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Actually, I stand corrected.  Grant doesn't actually "marry" the 
>>>>>>>> buses in his project and he explains why on his website:
>>>>>>>> 
>>>>>>>> Similarly, all these CPUs have an 8-bit data bus. For the 
>>>>>>>> discrete components, the data bus is bidirectional. This could 
>>>>>>>> have been implemented in VHDL as bidirectional to match. 
>>>>>>>> However, the VHDL components (including RAM and ROM) tend to 
>>>>>>>> have separate incoming and outgoing data buses - this makes it 
>>>>>>>> easier to interface. Therefore the 8-bit data bus found on a CPU 
>>>>>>>> is represented as two separate data buses and are connected to 
>>>>>>>> the two data buses on the breadboard.
>>>>>>>> 
>>>>>>>> eg
>>>>>>>> di => cpuDataIn,
>>>>>>>> do => cpuDataOut
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> This code in Multicomp attaches the different peripherals to the 
>>>>>>>> CPU read data bus when the respective chip select goes low:
>>>>>>>> 
>>>>>>>> cpuDataIn <=
>>>>>>>> interface1DataOut when n_interface1CS = '0' else
>>>>>>>> interface2DataOut when n_interface2CS = '0' else
>>>>>>>> sdCardDataOut when n_sdCardCS = '0' else
>>>>>>>> basRomData when n_basRomCS = '0' else
>>>>>>>> internalRam1DataOut when n_internalRam1CS= '0' else
>>>>>>>> sramData when n_externalRamCS= '0' else
>>>>>>>> x"FF";
>>>>>>>> 
>>>>>>>> 
>>>>>>>> An example of connecting the CPU write data bus to an external 
>>>>>>>> RAM chip is found here:
>>>>>>>> 
>>>>>>>> sramAddress(15 downto 0) <= cpuAddress(15 downto 0);
>>>>>>>> sramData <= cpuDataOut when n_WR='0' else (others => 'Z');
>>>>>>>> n_sRamWE <= n_memWR;
>>>>>>>> n_sRamOE <= n_memRD;
>>>>>>>> n_sRamCS <= n_externalRamCS;
>>>>>>>> 
>>>>>>>> This is the way he keeps it flexible in order to work with both 
>>>>>>>> the "internal" VHDL devices which may use separate data buses as 
>>>>>>>> well as the real external devices that normally use a single 
>>>>>>>> bi-directional bus.  Additionally, there are some physical 
>>>>>>>> devices which do not require the chip select to be active in 
>>>>>>>> order to perform a write operation.
>>>>>>>> 
>>>>>>>> Dave Philipsen
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 8/30/2015 10:42 PM, Bill Nobel wrote:
>>>>>>>>> I have gone over Grants code extensively and I never found a 
>>>>>>>>> symbol file for Chip select. I see the CS lines defined, but 
>>>>>>>>> not such as Roger’s define for a symbol file.
>>>>>>>>> 
>>>>>>>>> Bill Nobel
>>>>>>>>> 
>>>>>>>>>> On Aug 30, 2015, at 9:23 PM, Dave Philipsen <dave at davebiz.com> 
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> If you take a look at the VHDL code in Grant Searle's 
>>>>>>>>>> Multicomp project you'll find an example of this too.
>>>>>>>>>> 
>>>>>>>>>> Dave Philipsen
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 8/30/2015 8:53 PM, Bill Nobel wrote:
>>>>>>>>>>> I have to post this here,  A HUGE shout out to Roger Taylor 
>>>>>>>>>>> for directing me in the right direction for the bus marriage 
>>>>>>>>>>> on the FPGA versions of the 6809.  I am a noob when it comes 
>>>>>>>>>>> to these things and was having trouble marrying the data_in 
>>>>>>>>>>> data_out busses together to form a actual bi-directional bus. 
>>>>>>>>>>>  I thought I was needing to build a circuit with 
>>>>>>>>>>> latches/buffers, and he decides to give me a ~20 line piece 
>>>>>>>>>>> of vhdl code that does the whole works based on Chip selects. 
>>>>>>>>>>> Woo hoo….
>>>>>>>>>>> 
>>>>>>>>>>> Bill Nobel
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> ---
>>>>>>>>>> This email has been checked for viruses by Avast antivirus 
>>>>>>>>>> software.
>>>>>>>>>> https://www.avast.com/antivirus
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> 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
>>>>>>>> 
>>>>>>>> --
>>>>>>>> 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
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> 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> 
>>>> <https://www.avast.com/antivirus <https://www.avast.com/antivirus>>
>>>> 
>>>> 
>>>> --
>>>> Coco mailing list
>>>> Coco at maltedmedia.com <mailto:Coco at maltedmedia.com> 
>>>> <mailto:Coco at maltedmedia.com <mailto:Coco at maltedmedia.com>>
>>>> https://pairlist5.pair.net/mailman/listinfo/coco 
>>>> <https://pairlist5.pair.net/mailman/listinfo/coco> 
>>>> <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 <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>


More information about the Coco mailing list