[Coco] CoCoFest Online - For those that just simply could not go.
Boisy G. Pitre
boisy at tee-boy.com
Wed May 25 10:50:05 EDT 2011
On May 25, 2011, at 5:54 AM, John Kent wrote:
> Hi Aaron,
>
> I look forward to seeing Steve Bjork's video.
>
> The FPGA stuff I guess lead on to more serious applications than just 8 bit microcomputers. I used the 6809 design to learn about microprocessor design. The next step I guess is to make a pipe lined design where the fetch, decode, read, execute and write cycles are pipe lined. I'm not sure if the 6809 lends itself to that sort of design, as some of the instructions need the result of the previous instruction to be completed first. There might be ways to work around that by putting bubbles (?) or stalls in the pipe line.
>
> I was also wondering about implementing a Harvard architecture for the 6809 with separate data and instruction buses. You'd have separate instruction and data cache connected to shared memory. Self modifying code would require cache coherency between the instruction and data cache, but I'm not sure how many programs for the 6809 really resort to using self modifying code.
>
> I know some members of the list would like to see a FPGA HD6309. I'm concerned though that adding the extra instructions would slow the design down. The timing is already marginal at 25MHz. 25MHz is a good frequency for the pixel clock, for the display so slowing that down any reduces the screen resolution. Also many of the FPGA boards use a 50MHz clock or multiple / fraction there of, so it's relatively easy to divide the clock by 2 to generate 25MHz. There are digital clock managers on the Spartan 3 and Cyclone 2 that allow you to generate different clock frequencies, but you still have the pixel clock to worry about. It's best to use synchronous clocks across the whole design to prevent race and metastable conditions on the flip flops.
John,
Historically, the 6309 has delivered on two fronts:
1. Speed. Obvious instructions like "tfm" to do block copy, as well as the enhanced MUL and DIV instructions made certain things considerably faster.
2. Size. The same functionality could be done with less code, and so programs had a size savings.
Speed is no longer a consideration since we're dealing with a new platform that can run at high speeds, but size can still be an issue. NitrOS-9/6809 Level 2's GrfDrv module for instance, is large enough that it required a move to a "16K GrfDrv" model which the 6309 version doesn't need. This 16K model does cause certain problems for us.
Ideally, a 6309 FPGA would be great, especially since NitrOS-9 has invested so much into 6309 compatibility, but it certainly is not mandatory. I'm hoping that similar gains in FPGA technology that we've seen over the last few years can bring down the price for even more powerful boards that can accommodate a 6309 with minimal cost.
> John.
>
> On 25/05/2011 3:43 PM, Aaron Wolfe wrote:
>> I haven't seen the video capture on the FTP site, but if it's just a
>> recording of the live feed, there will certainly be long periods of
>> the same shot. I did try to move it around from time to time and to
>> put it close to the seminars, but I was pretty busy doing other things
>> at the fest. I think some serious cutting/editing would need to be
>> done in order to have something enjoyable to watch.
>>
>> I did monitor the coco IRC channel most of the time and tried to
>> respond to requests made there for a closeup of this or that or a
>> chance to say hi to someone. For instance we did a short
>> demonstration of the FPGA, the coco I/O board and the new video modes
>> for the internet folks, and Frank P. and Steve B. talked to them for a
>> bit. We had over a dozen people in the IRC channel for the entire
>> fest from what I saw, so lots of good conversations there as folks
>> watched the sometimes boring feed :)
>>
>> Steve Bjork took high def video of various fest happenings, and I
>> think this would make a much better starting place for a "highlights"
>> video in the style of Allen's past work. There might only be a few
>> minutes worth saving out of the entire live feed, if it captured
>> anything that Steve missed.
>>
>> -Aaron
>
> --
> http://www.johnkent.com.au
> http://members.optusnet.com.au/jekent
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
More information about the Coco
mailing list