[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] Supported Instructions

Michael Riepe wrote:

> Fine, Ben... here is your cookie... now go back to sleep.

I had meant using a irq with a single byte I/O device that runs at a
very high speed. For example a Floppy disk controller connected to the
FIRQ line of a 6809.

> No wait... please explain to me how to use DMA for an `invalid opcode'
> trap, will you?

That is easy ... design a cpu will no invalid opcodes. :)

> Besides that, a DMA engine will have to tell the CPU that it has finished
> its job - via an interrupt, unless you're willing to waste CPU time with
> polling status bits (in that case, you could also do the data transfer
> in software and use that precious silicon for something more useful).

It seems today more time is spent converting asynchronous signals  from
irq's/ I/O devices to synchronized virtual tasks than I/O polling every
clock tick would be and having synchronization guaranteed. This might
even require (Gasp) double buffering on I/O devices.

Speaking of I/O devices ,a extended opcode could be a block move command
with checksum generation/testing done auto - magically at the same time.
More and more I think the Open-Source movement needs to start with data
base/ character set formats and I/O devices as Information as well as
Hardware needs to open and revised with a world wide aspect in mind.
Take the assumption with the byte ( given to us by IBM in the 60's) is a
good size for character data. Is that still true today? would 12, or 16
bits be better today? What about separating say computer symbols , word
processing , character information , graphic and general control like

Now I can go back to sleep Zzz. No wait I want milk to go with that
Ben Franchuk - Dawn * 12/24 bit cpu *
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/