[Coco] Are MC68B09E's and HM63C09E's as well as various support chips still available?

Computer Doc computerdoc at sc.rr.com
Sat May 26 21:58:45 EDT 2012



-----Original Message-----
From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On
Behalf Of John Kent
Sent: Saturday, May 26, 2012 9:11 AM
To: CoCoList for Color Computer Enthusiasts
Subject: Re: [Coco] Are MC68B09E's and HM63C09E's as well as various support
chips still available?



On 26/05/2012 9:59 PM, jdaggett at gate.net wrote:
> John Kind of in the same mode as you are. I started some ideas on a
> 6309 instruction set. I have done little with it over the past year. 
> Right now I am trying to get some PCB designs for an automated 
> Christmas display this year. Starting to get through the busiest time 
> of the year for work and can get some extra time later this summer 
> maybe I can resume that work. I kind of like that Xess XuLA board.
> Thanks for the tip on that. Better price and a bit more simpler than 
> Enterpoint's Craignell modules. Outside the SDRAM, it is a neat little 
> module. james

Hi James,

I've implemented the E & F registers and the W register and dual operand
instructions. I think I implemented the additional indexing modes, but I'll
have to check that. There are a few extensions to the indirect absolute
addressing mode that use the additional bits in the indexing byte to auto
increment the W register, and a few other W addressing modes that i have not
implemented yet.

I have yet to implement the mode register. It talks about native mode, which
I assume is 6309 mode. It seems a bit back to front as I would have thought
native mode meant that it ran in 6809 mode. I thought I'd use that flag to
introduce some idle cycles to make the 6809 mode more cycle accurate.

I've yet to implement the AIM, OIM, TIM and the other one whatever it is.
There are the block move instructions yet to come and the bit operators
(that do some interesting things) as well as the multiply and divide
instructions. I have implemented a 32 bit divide as a separate module and
I've implemented a separate hardware multiply using the hardware multipliers
in the FPGA. I thought I might implement a multiplier using shift and adds,
which would be slower than using hardware multipliers but might be more
cycle accurate and won't require special features in the FPGA.

I've made the CPU so you can specify the number of data and address bits. 8
bit data bus and 16 bit address bus in the default minimum. 
Since the number of cycles in the multiply or divide will depend on the size
of the data or accumulator, I can't code the multiply and divide into to
state sequencer as i have done in the past as the states are enumerated and
aren't dynamic, as far as I'm aware. There may be ways around that, but it
will require more investigation on my behalf.

The block move instructions are interruptable. If you interrupt during a
block transfer, it re-runs the instruction using the current register values
on return, so that presents some challenges in the design of the interrupts.

A start stop approach is not good for maintaining where I am in the design,
but other commitments pop up that need attention. I tend to spread myself a
bit thin at times with too many different projects on the go but at least it
maintains my interest.

John.
.

John, 

Your skills and talents are quite impressive!  I really like what you are
saying about coding the 6309 instruction set.  Implementing a microprocessor
instruction set is very fascinating to me.   I wish I knew how to learn it
all, but since I don't know beans about FPGAs and VHDL coding or simulating
8-bit microprocessors - yet, I was wondering is it important to add idle
cycles to slow down the implementation of the 6809 mode and why make the
cycle timing accurate when you can make it better and faster?  I'm not
criticizing, just curious.  Since the more recent technology runs so much
faster, I've been trying to figure out how to get a faster CPU with the 6809
and 6309 instruction set so I can utilize the faster memories, serial port
chips, etc.  I'd like to somehow wire up a 25MHZ COCO3 with added features
in hardware as opposed to software as many of you have done all in one FPGA
which is really cool by the way.  It's all as fascinating now as it was in
the beginning learning computers in the first place 35 years ago.  My first
experience was programming in BASIC in high school on an ASR-33 Teletype
with paper tape reader and punch communicating over a 300 baud acoustically
coupled modem over a phone line to Clemson University's PDP-8e Minicomputer!
Those were the days when you could watch your program print out
letter-by-letter.  Whew, that took a loooong time! (intentionally
misspelled)  I thought I'd share a little of my very beginnings in high
school.  Thank you for taking time out of your busy schedule to share your
computer engineering prowess.  I love all your posts.  They are always
informative.  It's a real treat to be able to communicate directly with
people whose articles I've read over the years and appreciated. 

Kip

--
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