[Coco] FPGA 6809
Bill Nobel
b_nobel at hotmail.com
Mon Aug 31 12:03:42 EDT 2015
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