AltairZ80 simulator updated - CP/M

This is a discussion on AltairZ80 simulator updated - CP/M ; no.spam@no.uce.bellatlantic.net wrote: > > There are a lot of good reasons to do memeory mapped IO on > 8080/8085/z80 (and others) in that you ahve greater address space > and logical operations on ports are doable plus word (16bit) transfers ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 49

Thread: AltairZ80 simulator updated

  1. Re: AltairZ80 simulator updated

    no.spam@no.uce.bellatlantic.net wrote:
    >
    > There are a lot of good reasons to do memeory mapped IO on
    > 8080/8085/z80 (and others) in that you ahve greater address space
    > and logical operations on ports are doable plus word (16bit) transfers
    > in a single instruction even with 8080!
    >
    > Allison


    If memory serves me correctly, the Z-80 inserts a wait state on port
    I/O. So memory mapped devices had a speed advantage. I think that may
    be one reason why the TRS-80 Model I mapped its FDC to memory. The
    1.78MHz CPU had to really huff to service the data register.

    Amardeep

  2. Re: AltairZ80 simulator updated

    ANY processor can use memory mapped I/O; it is not something that is
    done on the CPU, it is something that is done on the I/O card. But,
    specifically, I was referring primarily to memory mapped video (which is
    still I/O)


    Axel Berger wrote:
    > *Barry Watzman* wrote on Tue, 08-07-29 02:55:
    >> memory mapped I/O

    >
    > Please correct me, but as far as I know neither the 8080 nor the 8086
    > nor any of their derivatives use memory mapped I/O. In fact this is
    > what made the IBM-AT emulator for the Atari using little more that a
    > bare 80286 possible -- all I/O were redirected to native 68000
    > subroutines and all memory accesses done directly.
    >

    ** Posted from http://www.teranews.com **

  3. Re: AltairZ80 simulator updated

    On Wed, 30 Jul 2008 23:00:28 -0400, Amardeep S Chana <"asc135 aat
    yahoo doot coom"> wrote:

    >no.spam@no.uce.bellatlantic.net wrote:
    >>
    >> There are a lot of good reasons to do memeory mapped IO on
    >> 8080/8085/z80 (and others) in that you ahve greater address space
    >> and logical operations on ports are doable plus word (16bit) transfers
    >> in a single instruction even with 8080!
    >>
    >> Allison

    >
    >If memory serves me correctly, the Z-80 inserts a wait state on port
    >I/O. So memory mapped devices had a speed advantage. I think that may
    >be one reason why the TRS-80 Model I mapped its FDC to memory. The
    >1.78MHz CPU had to really huff to service the data register.


    You are indeed correct and it can make a difference is your going
    slow.

    ALlison

    >
    >Amardeep



  4. Re: AltairZ80 simulator updated

    "CBFalconer" wrote in message
    news:48911684.12FF8EE6@yahoo.com...
    > I built my 8080 systems with a dual flipflop that was reset by the
    > reset pulse, and then counted up to three (a shift register). It
    > counted memory accesses. Until it hit three the high byte of the
    > memory access was supplied by a dipswitch (or patch board plugging
    > into a socket). This let me start execution on any of 256 possible
    > pages. Never had any urge to change it. The basic reason for the
    > construct was that, at time of conception, I had no idea what my
    > eventual monitor was going to look like.


    I have a circuit to perform a similar function on my S100 system. I made a
    modification to my RAM card to do it. After reset the RAM is disabled and
    all fetches occur from a 16 byte PROM I added to the card. As soon as a
    fetch is attempted with the MS address bit set, the circuit shuts off. That
    PROM contains a JMP to the boot ROM on my disk controller, which resides at
    Fx00H.

    - Bill


  5. Re: AltairZ80 simulator updated

    Barry Watzman schrieb:
    > ANY processor can use memory mapped I/O; it is not something that is
    > done on the CPU, it is something that is done on the I/O card. But,
    > specifically, I was referring primarily to memory mapped video (which is
    > still I/O)


    Correct is that most processors can do memory mapped I/O.
    If video memory is mapped into a processors address space, it is not
    I/O, it is memory.

    Sometime in the 40s John von Neumann invented the CPU architecture based
    on work of Alan Touring, we mostly still use. The fundamental principle
    of this machines is, that program and data can be store in read/write
    memory, so that a program can be seen as data and vi versa. I/O is
    separated from memory and works on a different bus. The 8086 used in
    PC's is von Neumann architecture, to understand the inner workings of
    such machines one could start reading:
    http://en.wikipedia.org/wiki/Von_Neumann_architecture

    If memory is common shared between two processors, like that is the case
    with video memory in PC's, this doesn't change the von Neumann principle
    of the processors. You can store a program in the video memory and run
    it, because it is memory. You cannot store a program and expect to run
    it in the registers of I/O controllers. The I/O is happening on the
    graphics processor, this one reads the video memory and does I/O then to
    generate some sort of video signal, not the 8086, that one just sees
    memory.

    Udo Munk
    --
    The real fun is building it and then using it...

  6. Re: AltairZ80 simulator updated



    "Udo Munk" wrote in message
    news:g6vg38$t9e$01$1@news.t-online.com...
    > Barry Watzman schrieb:
    >> ANY processor can use memory mapped I/O; it is not something that is done on the
    >> CPU, it is something that is done on the I/O card. But, specifically, I was
    >> referring primarily to memory mapped video (which is still I/O)

    >
    > Correct is that most processors can do memory mapped I/O.
    > If video memory is mapped into a processors address space, it is not I/O, it is
    > memory.


    Your definition of memory mapped I/O is too narrow. In common English
    usage (and I went back and checked my old issues of BYTE, Kilobaud and
    Interface Age to be sure) memory-mapped I/O refers to ANY peripheral,
    including video, that uses memory address space to function rather than
    using I/O ports.

    Tom Lake


  7. Re: AltairZ80 simulator updated

    "Udo Munk" wrote in message
    news:g6vg38$t9e$01$1@news.t-online.com...
    > http://en.wikipedia.org/wiki/Von_Neumann_architecture


    Despite what the picture at the page you reference may seem to imply, a von
    Neumann architecture does not dictate that I/O be in any way separated from
    memory. It simply requires that there be memory and that the program be
    stored there as if it were data can be treated as data. It puts no
    constraints at all on how or where I/O should be implemented.

    Indeed, the only reference to I/O in the article (fourth paragraph under
    "Description") it talking about memory mapped I/O, and illustrates well the
    advantages of MMIO.

    If I place the register that controls a stepper motor at I/O Port 0x1000 or
    put it at memory location 0x10000000, it's still an I/O device.

    If I put 1K of RAM that's the frame buffer for a display on I/O ports 0x8000
    to 0x8400 or at memory locations 0x10000400 it's still an I/O device.

    http://www.karbosguide.com/
    http://en.wikipedia.org/wiki/Memory_mapped_I/O
    http://en.wikipedia.org/wiki/Input/output (section on memory mapped I/O)
    http://webster.cs.ucr.edu/AoA/Windows/HTML/IO.html (section 7.4.1)

    - Bill


  8. Re: AltairZ80 simulator updated

    >Correct is that most processors can do memory mapped I/O.
    >If video memory is mapped into a processors address space, it is not
    >I/O, it is memory.


    I view this simply as a matter of perspective - Is it memory because it can
    be read/written/executed, or is it I/O because it provides output from the
    system.

    I used a 64x16 video card in my Altair for years just to fill in the 1K gap
    left beside the NorthStar disk controller, and the minimum 2K deselect
    in my CDC memory card ... in this application it was mainly "memory".
    I did write a few memory mapped video games for it - in this application
    I considered it I/O.

    I once had a homebrew video card which wasn't quite fast enough to
    reliably execute from but seemed to work OK for data reads/writes -
    would you still consider this memory?


    >If memory is common shared between two processors, like that is the case
    >with video memory in PC's, this doesn't change the von Neumann principle
    >of the processors. You can store a program in the video memory and run
    >it, because it is memory. You cannot store a program and expect to run
    >it in the registers of I/O controllers.


    I know of several I/O devices with read/write registers that if memory mapped
    could hold and run a very small program. And a larger one - the Cirrus EP9307
    ARM processor used in a recent project has a large (4K) block of I/O reserved
    for the ethernet controller - it is also used to hold the 2nd stage bootstrap
    when booting the processor via the serial port - this is not general purpose
    memory - it supports words only - you cannot do byte writes to it... so it
    can be slightly tricky to write code that runs in it - but it certainly can be
    done (in fact you must to boot the processor).


    My point being that I don't quite get what the argument is about - it's
    really just a poinf of view. Kinda like that old philosophy question...
    "If a tree falls in the forest is any sound produced?"

    Camp A says "sound is vibrations in the air - YES"
    Camp B says "sound is interpretation by an ear/brain - NO"

    Both camps know all the details of whats going on, and are only
    arguing over the definition of sound.

    Is a shared memory display I/O or memory?

    Camp A says "it's providing output - I/O"
    Camp B says "It's ramdom access read/write - MEMORY"

    Both camps know all the details of what is happening, and
    are only arguing over the defintion of I/O (and possibly
    memory).

    Dave

    --
    dave06a@ Low-cost firmware development tools: www.dunfield.com
    dunfield. Classic computer collection: www.classiccmp.org/dunfield
    com Some stuff I have for sale: www.dunfield.com/sale


  9. Re: AltairZ80 simulator updated

    Dave Dunfield schrieb:

    >> Correct is that most processors can do memory mapped I/O.
    >> If video memory is mapped into a processors address space, it is not
    >> I/O, it is memory.

    >
    > I view this simply as a matter of perspective - Is it memory because it can
    > be read/written/executed, or is it I/O because it provides output from the
    > system.
    >
    > I used a 64x16 video card in my Altair for years just to fill in the 1K gap
    > left beside the NorthStar disk controller, and the minimum 2K deselect
    > in my CDC memory card ... in this application it was mainly "memory".
    > I did write a few memory mapped video games for it - in this application
    > I considered it I/O.


    OK, so you as programmer consider it I/O because you want to do I/O and
    don't want to be bothered about the details how that works. Fact is that
    processor A just sees memory, that can be read, written, executed and
    that processor B reads this memory and then does I/O to generate the
    video signal.

    > I once had a homebrew video card which wasn't quite fast enough to
    > reliably execute from but seemed to work OK for data reads/writes -
    > would you still consider this memory?


    Sure is this memory, in your case it was broken memory. In nowadays
    processors one can set a no-execute flag on memory segments used to
    store data, or one can set a no-write flag on memory segments containing
    instructions to execute. Others didn't like von Neumanns idea and
    separated program and data even more.

    >> If memory is common shared between two processors, like that is the case
    >> with video memory in PC's, this doesn't change the von Neumann principle
    >> of the processors. You can store a program in the video memory and run
    >> it, because it is memory. You cannot store a program and expect to run
    >> it in the registers of I/O controllers.

    >
    > I know of several I/O devices with read/write registers that if memory mapped
    > could hold and run a very small program. And a larger one - the Cirrus EP9307
    > ARM processor used in a recent project has a large (4K) block of I/O reserved
    > for the ethernet controller - it is also used to hold the 2nd stage bootstrap
    > when booting the processor via the serial port - this is not general purpose
    > memory - it supports words only - you cannot do byte writes to it... so it
    > can be slightly tricky to write code that runs in it - but it certainly can be
    > done (in fact you must to boot the processor).


    As long as the I/O controller won't modify the memory in some unexpected
    way, you can run programs from this memory.

    > My point being that I don't quite get what the argument is about - it's
    > really just a poinf of view. Kinda like that old philosophy question...
    > "If a tree falls in the forest is any sound produced?"
    >
    > Camp A says "sound is vibrations in the air - YES"
    > Camp B says "sound is interpretation by an ear/brain - NO"


    What if I place a microphone in a forest and record what's going on?

    > Both camps know all the details of whats going on, and are only
    > arguing over the definition of sound.
    >
    > Is a shared memory display I/O or memory?
    >
    > Camp A says "it's providing output - I/O"
    > Camp B says "It's ramdom access read/write - MEMORY"
    >
    > Both camps know all the details of what is happening, and
    > are only arguing over the defintion of I/O (and possibly
    > memory).


    One camp is ignoring some facts about the inner working of this machines
    obviously. Camp A also would say it's providing I/O when they write a
    program, that does some I/O somewhere on a processor, that has no I/O
    capabilities at all and directs all I/O to other subsystems.
    That is the camp probably that just writes to mapped video memory
    without communicating with the I/O processor (uh what I/O processor, I'm
    doing I/O here), resulting in programs with a flickering video display ;-)

    >
    > Dave
    >
    > --
    > dave06a@ Low-cost firmware development tools: www.dunfield.com
    > dunfield. Classic computer collection: www.classiccmp.org/dunfield
    > com Some stuff I have for sale: www.dunfield.com/sale
    >


    Udo Munk
    --
    The real fun is building it and then using it...

  10. Re: AltairZ80 simulator updated

    >> I view this simply as a matter of perspective - Is it memory because it can
    >> be read/written/executed, or is it I/O because it provides output from the
    >> system.


    >OK, so you as programmer consider it I/O because you want to do I/O and
    >don't want to be bothered about the details how that works.


    No, I understand completely the hardware operation to a very detailed
    level. But I'm perfectly happy to consider that in this particular case, the
    device is both I/O and memory - and can be used for either purpose.


    >Fact is that
    >processor A just sees memory, that can be read, written, executed and
    >that processor B reads this memory and then does I/O to generate the
    >video signal.


    Which happens to be how many devices you would consider I/O work,
    although in some cases the "memory" is only a word wide - perhaps
    there is a size component to your definition?


    >> I once had a homebrew video card which wasn't quite fast enough to
    >> reliably execute from but seemed to work OK for data reads/writes -
    >> would you still consider this memory?


    >Sure is this memory, in your case it was broken memory.


    I disagree - the display worked flawlessly. As an I/O device it behaved
    exactly as it was designed - a group of registers which control the visual
    output in character cells. It was never designed to run code, and the
    timing for execution was known to be iffy before it was built. It happened
    to have some characteristics of a memory array ... I used this display for
    several years, and never felt the need to redesign or "fix" it.

    If I had decided not to include read logic, the display would still have
    worked, and had none of the charactistics of a memory array - a very
    small change to the schematic, yet apparently a quantum shift in the
    type of device...


    >> My point being that I don't quite get what the argument is about - it's
    >> really just a poinf of view. Kinda like that old philosophy question...
    >> "If a tree falls in the forest is any sound produced?"
    >>
    >> Camp A says "sound is vibrations in the air - YES"
    >> Camp B says "sound is interpretation by an ear/brain - NO"


    >What if I place a microphone in a forest and record what's going on?


    Camp A says - this proves that sound is produced.
    Camp B says - No, we don't disagree that there are vibrations in the
    air, and the micrphone will record the pattern - this pattern is then used
    by the playback requipment to generate actual sound.

    Either of both of the camps might also respond with:

    What if the microphone is defective?
    What is the tape is full?

    And the pointless debate rages on...


    >> Both camps know all the details of whats going on, and are only
    >> arguing over the definition of sound.
    >>
    >> Is a shared memory display I/O or memory?
    >>
    >> Camp A says "it's providing output - I/O"
    >> Camp B says "It's ramdom access read/write - MEMORY"
    >>
    >> Both camps know all the details of what is happening, and
    >> are only arguing over the defintion of I/O (and possibly
    >> memory).


    >One camp is ignoring some facts about the inner working of this machines
    >obviously.


    An opinion. My opinion is that many people who thought of their S-100 video
    system as an I/O device were knowlegable in how the data is transferred
    over the various busses to and from it. The processor does not know or care
    what manufacturers designation is on the chip on the other end of the bus. It
    knows only about the mechanics of that transfer - the action within the system
    is determined by the functionality of the device.


    >Camp A also would say it's providing I/O when they write a
    >program, that does some I/O somewhere on a processor, that has no I/O
    >capabilities at all and directs all I/O to other subsystems.


    To have no I/O capabilities, the processor would have to have no bus.
    Lots of CPUs have no specific I/O bus, yet they communicate with devices
    which would not be considered another processor (or even an intelligent
    device).

    My NorthStar disk controller was a card full of TTL, no processor or other
    smarts at all, mapped into the S-100 memory bus ... Very little on this card
    could be written and then read back like memory ... but the CPU performed
    accesses to it in exactly the same was as the video card beside it...


    >That is the camp probably that just writes to mapped video memory
    >without communicating with the I/O processor (uh what I/O processor, I'm
    >doing I/O here), resulting in programs with a flickering video display ;-)


    And if there is no read logic - is it still memory?

    What if the monitor is disconnected - is it still I/O?

    What if my 16x64 display is built using 1024 discrete read/write latches,
    each driving a decoder which directly drives the corresponding
    character cell (non video obviously) without a controller chip smart
    enough to be considered a processor - is this still memory?

    And if those latches are write only?

    What if I put the same video display on the I/O bus - is it still memory?

    (Repeat above pointless questions for the I/O bus device)

    And this equally pointless debate rages on ...


    --
    dave06a@ Low-cost firmware development tools: www.dunfield.com
    dunfield. Classic computer collection: www.classiccmp.org/dunfield
    com Some stuff I have for sale: www.dunfield.com/sale


  11. Re: AltairZ80 simulator updated

    Dave Dunfield schrieb:
    >>> I view this simply as a matter of perspective - Is it memory because it can
    >>> be read/written/executed, or is it I/O because it provides output from the
    >>> system.

    >
    >> OK, so you as programmer consider it I/O because you want to do I/O and
    >> don't want to be bothered about the details how that works.

    >
    > No, I understand completely the hardware operation to a very detailed
    > level. But I'm perfectly happy to consider that in this particular case, the
    > device is both I/O and memory - and can be used for either purpose.


    Maybe wrong worded, I'm sure that you understand the operation of this
    hardware very detailed.
    Unplug the graphics processor and continue to use the memory, no output
    anymore of course, because there are different functions at different
    levels.

    >> Fact is that
    >> processor A just sees memory, that can be read, written, executed and
    >> that processor B reads this memory and then does I/O to generate the
    >> video signal.

    >
    > Which happens to be how many devices you would consider I/O work,
    > although in some cases the "memory" is only a word wide - perhaps
    > there is a size component to your definition?


    If is is read-only and every time you read it you get the same value it
    probably is read-only memory. If the value differs, it obviously is some
    sort of memory mapped I/O device.
    If it is read-write and every time you read what you wrote before, it is
    obviously read-write memory. If it differs it either is defective or it
    is some sort of memory mapped I/O. Size doesn't matter, the
    functionality defines what it is, no?
    Of course you could realize memory that causes I/O somewhere to happen,
    with some logic connected to the memory bus, but the processor which
    only sees the memory won't know about that.

    >>> I once had a homebrew video card which wasn't quite fast enough to
    >>> reliably execute from but seemed to work OK for data reads/writes -
    >>> would you still consider this memory?

    >
    >> Sure is this memory, in your case it was broken memory.

    >
    > I disagree - the display worked flawlessly. As an I/O device it behaved
    > exactly as it was designed - a group of registers which control the visual
    > output in character cells. It was never designed to run code, and the
    > timing for execution was known to be iffy before it was built. It happened
    > to have some characteristics of a memory array ... I used this display for
    > several years, and never felt the need to redesign or "fix" it.


    What if someone else uses such a machine and figures, that the access
    time for this video memory is better than for other memory, less wait
    states. This one might tell the I/O processor to get off that memory for
    20ms and try to use it to run some very time critical code. This person
    would find that the memory won't allow to execute code reliable and
    probably would describe it as flaky. Just a matter of perspective...

    > If I had decided not to include read logic, the display would still have
    > worked, and had none of the charactistics of a memory array - a very
    > small change to the schematic, yet apparently a quantum shift in the
    > type of device...


    Write-only memory then, I/O is not the only reason why one would want that.

    >>> My point being that I don't quite get what the argument is about - it's
    >>> really just a poinf of view. Kinda like that old philosophy question...
    >>> "If a tree falls in the forest is any sound produced?"
    >>>
    >>> Camp A says "sound is vibrations in the air - YES"
    >>> Camp B says "sound is interpretation by an ear/brain - NO"

    >
    >> What if I place a microphone in a forest and record what's going on?

    >
    > Camp A says - this proves that sound is produced.
    > Camp B says - No, we don't disagree that there are vibrations in the
    > air, and the micrphone will record the pattern - this pattern is then used
    > by the playback requipment to generate actual sound.


    Well, then we put some birds and monkeys in the forest, that are trained
    to repeat what they heard. No technical recording of air vibrations
    involved anymore.

    > Either of both of the camps might also respond with:
    >
    > What if the microphone is defective?
    > What is the tape is full?


    Then I would ask them: where was the failover equipment and why wasn't
    there at least one endless tape installed?

    > And the pointless debate rages on...
    >
    >
    >>> Both camps know all the details of whats going on, and are only
    >>> arguing over the definition of sound.
    >>>
    >>> Is a shared memory display I/O or memory?
    >>>
    >>> Camp A says "it's providing output - I/O"
    >>> Camp B says "It's ramdom access read/write - MEMORY"
    >>>
    >>> Both camps know all the details of what is happening, and
    >>> are only arguing over the defintion of I/O (and possibly
    >>> memory).

    >
    >> One camp is ignoring some facts about the inner working of this machines
    >> obviously.

    >
    > An opinion. My opinion is that many people who thought of their S-100 video
    > system as an I/O device were knowlegable in how the data is transferred
    > over the various busses to and from it. The processor does not know or care
    > what manufacturers designation is on the chip on the other end of the bus. It
    > knows only about the mechanics of that transfer - the action within the system
    > is determined by the functionality of the device.


    Yep. That was what I was trying to say. The processor can only see some
    memory and does memory operations on it. If there is some sort of I/O
    processor listening too and doing stuff, then there will be some I/O
    going on, but on a different level.
    Memory mapped I/O is different from that, it places I/O registers into
    the address space of the processor and allows it to do I/O operations
    directly on this devices.

    >> Camp A also would say it's providing I/O when they write a
    >> program, that does some I/O somewhere on a processor, that has no I/O
    >> capabilities at all and directs all I/O to other subsystems.

    >
    > To have no I/O capabilities, the processor would have to have no bus.
    > Lots of CPUs have no specific I/O bus, yet they communicate with devices
    > which would not be considered another processor (or even an intelligent
    > device).


    A FPU has no I/O bus. From the CPU you write into the FPU registers,
    start some calculation and read the result from the registers. The FPU
    can't do any I/O operations on I/O devices, it just can crunch numbers.
    There are enough distributed systems where I/O is directed to I/O
    processors, number crunching directed to FPUs and program control
    directed to some sort of general processor.
    Of course there have been FPU's with I/O bus to communicate with a CPU.
    That was too slow, so now the both units share some registers internally.

    > My NorthStar disk controller was a card full of TTL, no processor or other
    > smarts at all, mapped into the S-100 memory bus ... Very little on this card
    > could be written and then read back like memory ... but the CPU performed
    > accesses to it in exactly the same was as the video card beside it...


    Memory mapped I/O.

    >> That is the camp probably that just writes to mapped video memory
    >> without communicating with the I/O processor (uh what I/O processor, I'm
    >> doing I/O here), resulting in programs with a flickering video display ;-)

    >
    > And if there is no read logic - is it still memory?


    Write-only memory.

    > What if the monitor is disconnected - is it still I/O?


    The graphics processor continues to generate a video signal with I/O,
    unplug it too.

    > What if my 16x64 display is built using 1024 discrete read/write latches,
    > each driving a decoder which directly drives the corresponding
    > character cell (non video obviously) without a controller chip smart
    > enough to be considered a processor - is this still memory?


    As long as you can read back what you wrote before that is memory. Even
    if you decide to use magnetic cores for each cell it is memory.

    > And if those latches are write only?


    Write-only memory.

    > What if I put the same video display on the I/O bus - is it still memory?


    No memory at all.

    > (Repeat above pointless questions for the I/O bus device)
    >
    > And this equally pointless debate rages on ...


    Well, lets stop it then and agree on that we have machines, we can run
    programs on this machines, this machines do something when programs are
    run on them. Should be easy enough for everyone and nothing to argue
    about anymore.

    > --
    > dave06a@ Low-cost firmware development tools: www.dunfield.com
    > dunfield. Classic computer collection: www.classiccmp.org/dunfield
    > com Some stuff I have for sale: www.dunfield.com/sale


    Udo Munk
    --
    The real fun is building it and then using it...

  12. Re: AltairZ80 simulator updated

    On Aug 2, 8:39*am, Udo Munk wrote:
    > Dave Dunfield schrieb:
    >
    > >>> I view this simply as a matter of perspective - Is it memory because it can
    > >>> be read/written/executed, or is it I/O because it provides output from the
    > >>> system.

    >
    > >> OK, so you as programmer consider it I/O because you want to do I/O and
    > >> don't want to be bothered about the details how that works.

    >
    > > No, I understand completely the hardware operation to a very detailed
    > > level. But I'm perfectly happy to consider that in this particular case, the
    > > device is both I/O and memory - and can be used for either purpose.

    >
    > Maybe wrong worded, I'm sure that you understand the operation of this
    > hardware very detailed.
    > Unplug the graphics processor and continue to use the memory, no output
    > anymore of course, because there are different functions at different
    > levels.
    >
    > >> Fact is that
    > >> processor A just sees memory, that can be read, written, executed and
    > >> that processor B reads this memory and then does I/O to generate the
    > >> video signal.

    >
    > > Which happens to be how many devices you would consider I/O work,
    > > although in some cases the "memory" is only a word wide - perhaps
    > > there is a size component to your definition?

    >
    > If is is read-only and every time you read it you get the same value it
    > probably is read-only memory. If the value differs, it obviously is some
    > sort of memory mapped I/O device.
    > If it is read-write and every time you read what you wrote before, it is
    > obviously read-write memory. If it differs it either is defective or it
    > is some sort of memory mapped I/O. Size doesn't matter, the
    > functionality defines what it is, no?
    > Of course you could realize memory that causes I/O somewhere to happen,
    > with some logic connected to the memory bus, but the processor which
    > only sees the memory won't know about that.
    >
    > >>> I once had a homebrew video card which wasn't quite fast enough to
    > >>> reliably execute from but seemed to work OK for data reads/writes -
    > >>> would you still consider this memory?

    >
    > >> Sure is this memory, in your case it was broken memory.

    >
    > > I disagree - the display worked flawlessly. As an I/O device it behaved
    > > exactly as it was designed - *a group of registers which control the visual
    > > output in character cells. It was never designed to run code, and the
    > > timing for execution was known to be iffy before it was built. It happened
    > > to have some characteristics of a memory array ... I used this display for
    > > several years, and never felt the need to redesign or "fix" it.

    >
    > What if someone else uses such a machine and figures, that the access
    > time for this video memory is better than for other memory, less wait
    > states. This one might tell the I/O processor to get off that memory for
    > 20ms and try to use it to run some very time critical code. This person
    > would find that the memory won't allow to execute code reliable and
    > probably would describe it as flaky. Just a matter of perspective...
    >
    > > If I had decided not to include read logic, the display would still have
    > > worked, and had none of the charactistics of a memory array - a very
    > > small change to the schematic, yet apparently a quantum shift in the
    > > type of device...

    >
    > Write-only memory then, I/O is not the only reason why one would want that.
    >
    > >>> My point being that I don't quite get what the argument is about - it's
    > >>> really just a poinf of view. Kinda like that old philosophy question....
    > >>> "If a tree falls in the forest is any sound produced?"

    >
    > >>> Camp A says "sound is vibrations in the air - YES"
    > >>> Camp B says "sound is interpretation by an ear/brain - NO"

    >
    > >> What if I place a microphone in a forest and record what's going on?

    >
    > > Camp A says - this proves that sound is produced.
    > > Camp B says - No, we don't disagree that there are vibrations in the
    > > air, and the micrphone will record the pattern - this pattern is then used
    > > by the playback requipment to generate actual sound.

    >
    > Well, then we put some birds and monkeys in the forest, that are trained
    > to repeat what they heard. No technical recording of air vibrations
    > involved anymore.
    >
    > > Either of both of the *camps might also respond with:

    >
    > > * What if the microphone is defective?
    > > * What is the tape is full?

    >
    > Then I would ask them: where was the failover equipment and why wasn't
    > there at least one endless tape installed?
    >
    >
    >
    > > And the pointless debate rages on...

    >
    > >>> Both camps know all the details of whats going on, and are only
    > >>> arguing over the definition of sound.

    >
    > >>> Is a shared memory display I/O or memory?

    >
    > >>> Camp A says "it's providing output - I/O"
    > >>> Camp B says "It's ramdom access read/write - MEMORY"

    >
    > >>> Both camps know all the details of what is happening, and
    > >>> are only arguing over the defintion of I/O (and possibly
    > >>> memory).

    >
    > >> One camp is ignoring some facts about the inner working of this machines
    > >> obviously.

    >
    > > An opinion. My opinion is that many people who thought of their S-100 video
    > > system as an I/O device were knowlegable in how the data is transferred
    > > over the various busses to and from it. The processor does not know or care
    > > what manufacturers designation is on the chip on the other end of the bus. It
    > > knows only about the mechanics of that transfer - the action within thesystem
    > > is determined by the functionality of the device.

    >
    > Yep. That was what I was trying to say. The processor can only see some
    > memory and does memory operations on it. If there is some sort of I/O
    > processor listening too and doing stuff, then there will be some I/O
    > going on, but on a different level.
    > Memory mapped I/O is different from that, it places I/O registers into
    > the address space of the processor and allows it to do I/O operations
    > directly on this devices.
    >
    > >> Camp A also would say it's providing I/O when they write a
    > >> program, that does some I/O somewhere on a processor, that has no I/O
    > >> capabilities at all and directs all I/O to other subsystems.

    >
    > > To have no I/O capabilities, the processor would have to have no bus.
    > > Lots of *CPUs have no specific I/O bus, yet they communicate with devices
    > > which would not be considered another processor (or even an intelligent
    > > device).

    >
    > A FPU has no I/O bus. From the CPU you write into the FPU registers,
    > start some calculation and read the result from the registers. The FPU
    > can't do any I/O operations on I/O devices, it just can crunch numbers.
    > There are enough distributed systems where I/O is directed to I/O
    > processors, number crunching directed to FPUs and program control
    > directed to some sort of general processor.
    > Of course there have been FPU's with I/O bus to communicate with a CPU.
    > That was too slow, so now the both units share some registers internally.
    >
    > > My NorthStar disk controller was a card full of TTL, no processor or other
    > > smarts at all, mapped into the S-100 memory bus ... Very little on thiscard
    > > could be written and then read back like memory ... but the CPU performed
    > > accesses to it in exactly the same was as the video card beside it...

    >
    > Memory mapped I/O.
    >
    > >> That is the camp probably that just writes to mapped video memory
    > >> without communicating with the I/O processor (uh what I/O processor, I'm
    > >> doing I/O here), resulting in programs with a flickering video display;-)

    >
    > > And if there is no read logic - is it still memory?

    >
    > Write-only memory.
    >
    > > What if the monitor is disconnected - is it still I/O?

    >
    > The graphics processor continues to generate a video signal with I/O,
    > unplug it too.
    >
    > > What if my 16x64 display is built using 1024 discrete read/write latches,
    > > each driving a decoder which directly drives the corresponding
    > > character cell (non video obviously) without a controller chip smart
    > > enough to be considered a processor - is this still memory?

    >
    > As long as you can read back what you wrote before that is memory. Even
    > if you decide to use magnetic cores for each cell it is memory.
    >
    > > And if those latches are write only?

    >
    > Write-only memory.
    >
    > > What if I put the same video display on the I/O bus - is it still memory?

    >
    > No memory at all.
    >
    > > (Repeat above pointless questions for the I/O bus device)

    >
    > > And this equally pointless debate rages on ...

    >
    > Well, lets stop it then and agree on that we have machines, we can run
    > programs on this machines, this machines do something when programs are
    > run on them. Should be easy enough for everyone and nothing to argue
    > about anymore.
    >
    > > --
    > > dave06a@ * *Low-cost firmware development tools: *www.dunfield.com
    > > dunfield. * Classic computer collection: *www.classiccmp.org/dunfield
    > > com * * * * Some stuff I have for sale: *www.dunfield.com/sale

    >
    > Udo Munk
    > --
    > The real fun is building it and then using it...


    This new version of AltairZ80 supports the Cromemco 4/16/64-FDC disk
    controller. This is the controller used by 86-DOS and MS-DOS 1.25,
    and it can also be used to run Cromemco CDOS 2.58 from Dave Dunfield's
    disk archive site.

    For a brief time, I attempted to get Z80 Cromix running, without
    success. I wonder if anyone else in the group is up to the challenge
    of making it work. I don't know much about Cromix, and it is likely
    it is relying on some interrupt-driven facet of the hatdware which is
    either not fully implemented in the simulation, or has a bug.

    I was also unable to get California Computer Systems CP/M working. I
    did get the MOSS monitor running, and I do have the CCS boot disk
    image if anyone is interested. The CCS disk controller is very
    similar to the Cromemco, and the problem I had with CCS CP/M was
    definitely related to the disk controller. It would be an interesting
    challenge for someone who has an interest in CCS or has a CCS system.

    With the ImageDisk support in the simulator now, it is a very useful
    tool for reviving old hardware. I have already revived one S100 boat
    anchor I had sitting in my garage, by creating a CP/M boot disk using
    the simulator and CBIOS sources. I used the simulator to assemble
    everything, and to create an IMD disk image, which I then wrote to an
    8" floppy using Dave Dunfield's IMD program.

    It booted on the real hardware on the first try.

    -Howard

  13. Re: AltairZ80 simulator updated

    On Sat, 02 Aug 2008 12:03:20 +0200, Udo Munk
    wrote:

    >Dave Dunfield schrieb:
    >
    >>> Correct is that most processors can do memory mapped I/O.
    >>> If video memory is mapped into a processors address space, it is not
    >>> I/O, it is memory.

    >>
    >> I view this simply as a matter of perspective - Is it memory because it can
    >> be read/written/executed, or is it I/O because it provides output from the
    >> system.
    >>
    >> I used a 64x16 video card in my Altair for years just to fill in the 1K gap
    >> left beside the NorthStar disk controller, and the minimum 2K deselect
    >> in my CDC memory card ... in this application it was mainly "memory".
    >> I did write a few memory mapped video games for it - in this application
    >> I considered it I/O.

    >
    >OK, so you as programmer consider it I/O because you want to do I/O and
    >don't want to be bothered about the details how that works. Fact is that
    >processor A just sees memory, that can be read, written, executed and
    >that processor B reads this memory and then does I/O to generate the
    >video signal.
    >
    >> I once had a homebrew video card which wasn't quite fast enough to
    >> reliably execute from but seemed to work OK for data reads/writes -
    >> would you still consider this memory?

    >
    >Sure is this memory, in your case it was broken memory. In nowadays
    >processors one can set a no-execute flag on memory segments used to
    >store data, or one can set a no-write flag on memory segments containing
    >instructions to execute. Others didn't like von Neumanns idea and
    >separated program and data even more.
    >
    >>> If memory is common shared between two processors, like that is the case
    >>> with video memory in PC's, this doesn't change the von Neumann principle
    >>> of the processors. You can store a program in the video memory and run
    >>> it, because it is memory. You cannot store a program and expect to run
    >>> it in the registers of I/O controllers.

    >>
    >> I know of several I/O devices with read/write registers that if memory mapped
    >> could hold and run a very small program. And a larger one - the Cirrus EP9307
    >> ARM processor used in a recent project has a large (4K) block of I/O reserved
    >> for the ethernet controller - it is also used to hold the 2nd stage bootstrap
    >> when booting the processor via the serial port - this is not general purpose
    >> memory - it supports words only - you cannot do byte writes to it... so it
    >> can be slightly tricky to write code that runs in it - but it certainly can be
    >> done (in fact you must to boot the processor).

    >
    >As long as the I/O controller won't modify the memory in some unexpected
    >way, you can run programs from this memory.
    >
    >> My point being that I don't quite get what the argument is about - it's
    >> really just a poinf of view. Kinda like that old philosophy question...
    >> "If a tree falls in the forest is any sound produced?"
    >>
    >> Camp A says "sound is vibrations in the air - YES"
    >> Camp B says "sound is interpretation by an ear/brain - NO"

    >
    >What if I place a microphone in a forest and record what's going on?
    >
    >> Both camps know all the details of whats going on, and are only
    >> arguing over the definition of sound.
    >>
    >> Is a shared memory display I/O or memory?
    >>
    >> Camp A says "it's providing output - I/O"
    >> Camp B says "It's ramdom access read/write - MEMORY"
    >>
    >> Both camps know all the details of what is happening, and
    >> are only arguing over the defintion of I/O (and possibly
    >> memory).

    >
    >One camp is ignoring some facts about the inner working of this machines
    >obviously. Camp A also would say it's providing I/O when they write a
    >program, that does some I/O somewhere on a processor, that has no I/O
    >capabilities at all and directs all I/O to other subsystems.
    >That is the camp probably that just writes to mapped video memory
    >without communicating with the I/O processor (uh what I/O processor, I'm
    >doing I/O here), resulting in programs with a flickering video display ;-)


    the bottom line is IO is any read or write of data to devices that
    interact with the environment or user. The 6800 and 6502 had no
    specific IO instructions you hang a interface off the memory bus.
    8080/8085/z80 have specific instructions for a seperate poll of
    addresses that re specificall not memory for IO. However,
    if you choose to you can put an 8255 as memory or IO and whatever
    it interfaces to is still IO. Anything else is being contrairian.

    Allison




    >
    >>
    >> Dave
    >>
    >> --
    >> dave06a@ Low-cost firmware development tools: www.dunfield.com
    >> dunfield. Classic computer collection: www.classiccmp.org/dunfield
    >> com Some stuff I have for sale: www.dunfield.com/sale
    >>

    >
    >Udo Munk



  14. Re: AltairZ80 simulator updated

    On Sat, 02 Aug 2008 17:39:11 +0200, Udo Munk
    wrote:

    >Dave Dunfield schrieb:
    >>>> I view this simply as a matter of perspective - Is it memory because it can
    >>>> be read/written/executed, or is it I/O because it provides output from the
    >>>> system.

    >>
    >>> OK, so you as programmer consider it I/O because you want to do I/O and
    >>> don't want to be bothered about the details how that works.

    >>
    >> No, I understand completely the hardware operation to a very detailed
    >> level. But I'm perfectly happy to consider that in this particular case, the
    >> device is both I/O and memory - and can be used for either purpose.

    >
    >Maybe wrong worded, I'm sure that you understand the operation of this
    >hardware very detailed.
    >Unplug the graphics processor and continue to use the memory, no output
    >anymore of course, because there are different functions at different
    >levels.


    What if there is no graphics processor? Most S100 and other 64kx16
    display cards were basically a memory array with a output stream tap
    do a character rom and a shiftregister. the rest of the logic was a
    bunch of counters to time and correcly clock events. At best it could
    be called sequential logic but processor never.

    I my case I have a VDM1 that is indeed that. And it worked just like
    1k of ram you could ececute programs in that space and it would
    have stuff (trash) on the video for the area loaded with instructions.
    Often a stack crash would fill it with the same character pairs. It's
    still IO, that it's intent, it's reason to exist.


    Allison



    >
    >>> Fact is that
    >>> processor A just sees memory, that can be read, written, executed and
    >>> that processor B reads this memory and then does I/O to generate the
    >>> video signal.

    >>
    >> Which happens to be how many devices you would consider I/O work,
    >> although in some cases the "memory" is only a word wide - perhaps
    >> there is a size component to your definition?

    >
    >If is is read-only and every time you read it you get the same value it
    >probably is read-only memory. If the value differs, it obviously is some
    >sort of memory mapped I/O device.
    >If it is read-write and every time you read what you wrote before, it is
    >obviously read-write memory. If it differs it either is defective or it
    >is some sort of memory mapped I/O. Size doesn't matter, the
    >functionality defines what it is, no?
    >Of course you could realize memory that causes I/O somewhere to happen,
    >with some logic connected to the memory bus, but the processor which
    >only sees the memory won't know about that.
    >
    >>>> I once had a homebrew video card which wasn't quite fast enough to
    >>>> reliably execute from but seemed to work OK for data reads/writes -
    >>>> would you still consider this memory?

    >>
    >>> Sure is this memory, in your case it was broken memory.

    >>
    >> I disagree - the display worked flawlessly. As an I/O device it behaved
    >> exactly as it was designed - a group of registers which control the visual
    >> output in character cells. It was never designed to run code, and the
    >> timing for execution was known to be iffy before it was built. It happened
    >> to have some characteristics of a memory array ... I used this display for
    >> several years, and never felt the need to redesign or "fix" it.

    >
    >What if someone else uses such a machine and figures, that the access
    >time for this video memory is better than for other memory, less wait
    >states. This one might tell the I/O processor to get off that memory for
    >20ms and try to use it to run some very time critical code. This person
    >would find that the memory won't allow to execute code reliable and
    >probably would describe it as flaky. Just a matter of perspective...
    >
    >> If I had decided not to include read logic, the display would still have
    >> worked, and had none of the charactistics of a memory array - a very
    >> small change to the schematic, yet apparently a quantum shift in the
    >> type of device...

    >
    >Write-only memory then, I/O is not the only reason why one would want that.
    >
    >>>> My point being that I don't quite get what the argument is about - it's
    >>>> really just a poinf of view. Kinda like that old philosophy question...
    >>>> "If a tree falls in the forest is any sound produced?"
    >>>>
    >>>> Camp A says "sound is vibrations in the air - YES"
    >>>> Camp B says "sound is interpretation by an ear/brain - NO"

    >>
    >>> What if I place a microphone in a forest and record what's going on?

    >>
    >> Camp A says - this proves that sound is produced.
    >> Camp B says - No, we don't disagree that there are vibrations in the
    >> air, and the micrphone will record the pattern - this pattern is then used
    >> by the playback requipment to generate actual sound.

    >
    >Well, then we put some birds and monkeys in the forest, that are trained
    >to repeat what they heard. No technical recording of air vibrations
    >involved anymore.
    >
    >> Either of both of the camps might also respond with:
    >>
    >> What if the microphone is defective?
    >> What is the tape is full?

    >
    >Then I would ask them: where was the failover equipment and why wasn't
    >there at least one endless tape installed?
    >
    >> And the pointless debate rages on...
    >>
    >>
    >>>> Both camps know all the details of whats going on, and are only
    >>>> arguing over the definition of sound.
    >>>>
    >>>> Is a shared memory display I/O or memory?
    >>>>
    >>>> Camp A says "it's providing output - I/O"
    >>>> Camp B says "It's ramdom access read/write - MEMORY"
    >>>>
    >>>> Both camps know all the details of what is happening, and
    >>>> are only arguing over the defintion of I/O (and possibly
    >>>> memory).

    >>
    >>> One camp is ignoring some facts about the inner working of this machines
    >>> obviously.

    >>
    >> An opinion. My opinion is that many people who thought of their S-100 video
    >> system as an I/O device were knowlegable in how the data is transferred
    >> over the various busses to and from it. The processor does not know or care
    >> what manufacturers designation is on the chip on the other end of the bus. It
    >> knows only about the mechanics of that transfer - the action within the system
    >> is determined by the functionality of the device.

    >
    >Yep. That was what I was trying to say. The processor can only see some
    >memory and does memory operations on it. If there is some sort of I/O
    >processor listening too and doing stuff, then there will be some I/O
    >going on, but on a different level.
    >Memory mapped I/O is different from that, it places I/O registers into
    >the address space of the processor and allows it to do I/O operations
    >directly on this devices.
    >
    >>> Camp A also would say it's providing I/O when they write a
    >>> program, that does some I/O somewhere on a processor, that has no I/O
    >>> capabilities at all and directs all I/O to other subsystems.

    >>
    >> To have no I/O capabilities, the processor would have to have no bus.
    >> Lots of CPUs have no specific I/O bus, yet they communicate with devices
    >> which would not be considered another processor (or even an intelligent
    >> device).

    >
    >A FPU has no I/O bus. From the CPU you write into the FPU registers,
    >start some calculation and read the result from the registers. The FPU
    >can't do any I/O operations on I/O devices, it just can crunch numbers.
    >There are enough distributed systems where I/O is directed to I/O
    >processors, number crunching directed to FPUs and program control
    >directed to some sort of general processor.
    >Of course there have been FPU's with I/O bus to communicate with a CPU.
    >That was too slow, so now the both units share some registers internally.
    >
    >> My NorthStar disk controller was a card full of TTL, no processor or other
    >> smarts at all, mapped into the S-100 memory bus ... Very little on this card
    >> could be written and then read back like memory ... but the CPU performed
    >> accesses to it in exactly the same was as the video card beside it...

    >
    >Memory mapped I/O.
    >
    >>> That is the camp probably that just writes to mapped video memory
    >>> without communicating with the I/O processor (uh what I/O processor, I'm
    >>> doing I/O here), resulting in programs with a flickering video display ;-)

    >>
    >> And if there is no read logic - is it still memory?

    >
    >Write-only memory.
    >
    >> What if the monitor is disconnected - is it still I/O?

    >
    >The graphics processor continues to generate a video signal with I/O,
    >unplug it too.
    >
    >> What if my 16x64 display is built using 1024 discrete read/write latches,
    >> each driving a decoder which directly drives the corresponding
    >> character cell (non video obviously) without a controller chip smart
    >> enough to be considered a processor - is this still memory?

    >
    >As long as you can read back what you wrote before that is memory. Even
    >if you decide to use magnetic cores for each cell it is memory.
    >
    >> And if those latches are write only?

    >
    >Write-only memory.
    >
    >> What if I put the same video display on the I/O bus - is it still memory?

    >
    >No memory at all.
    >
    >> (Repeat above pointless questions for the I/O bus device)
    >>
    >> And this equally pointless debate rages on ...

    >
    >Well, lets stop it then and agree on that we have machines, we can run
    >programs on this machines, this machines do something when programs are
    >run on them. Should be easy enough for everyone and nothing to argue
    >about anymore.
    >
    >> --
    >> dave06a@ Low-cost firmware development tools: www.dunfield.com
    >> dunfield. Classic computer collection: www.classiccmp.org/dunfield
    >> com Some stuff I have for sale: www.dunfield.com/sale

    >
    >Udo Munk



  15. Re: AltairZ80 simulator updated

    On Sat, 2 Aug 2008 16:10:51 -0700 (PDT), Howard Harte
    wrote:

    Much snippage...

    >For a brief time, I attempted to get Z80 Cromix running, without
    >success. I wonder if anyone else in the group is up to the challenge
    >of making it work. I don't know much about Cromix, and it is likely
    >it is relying on some interrupt-driven facet of the hatdware which is
    >either not fully implemented in the simulation, or has a bug.


    Likely as memory serves the CP/U was setup with a good interrupt
    chain.

    >I was also unable to get California Computer Systems CP/M working. I
    >did get the MOSS monitor running, and I do have the CCS boot disk
    >image if anyone is interested. The CCS disk controller is very
    >similar to the Cromemco, and the problem I had with CCS CP/M was
    >definitely related to the disk controller. It would be an interesting
    >challenge for someone who has an interest in CCS or has a CCS system.


    I have one and theres nothing special off the top of my head. Save
    for I think the bank swicthing scheme allow both MOSS and FDC mounted
    2716s to be selected. Rather than run on memory I pulled the 2422
    manual and that is indeed the case. You need the disk boot rom or
    it's analog.

    >With the ImageDisk support in the simulator now, it is a very useful
    >tool for reviving old hardware. I have already revived one S100 boat
    >anchor I had sitting in my garage, by creating a CP/M boot disk using
    >the simulator and CBIOS sources. I used the simulator to assemble
    >everything, and to create an IMD disk image, which I then wrote to an
    >8" floppy using Dave Dunfield's IMD program.


    This is a good thing. More tools.

    Allison

    >
    >It booted on the real hardware on the first try.
    >
    >-Howard



  16. Re: AltairZ80 simulator updated

    Dave Dunfield wrote:
    (snip)

    > No, I understand completely the hardware operation to a very detailed
    > level. But I'm perfectly happy to consider that in this particular case, the
    > device is both I/O and memory - and can be used for either purpose.


    Reminds me of SunOS which had device mapped memory. For VME
    based Suns there were devices like /dev/vme24d32. (VME has
    separate address spaces for each address width and data width.)

    SunOS also has the usual unix memory mapped files.

    Combining the two, you can have memory mapped memory where
    some part of the VME address space maps into some place
    in the process virtual address space.

    Memory and I/O aren't so separate after all.

    -- glen


  17. Re: AltairZ80 simulator updated

    >Maybe wrong worded, I'm sure that you understand the operation of this
    >hardware very detailed.
    >Unplug the graphics processor and continue to use the memory, no output
    >anymore of course, because there are different functions at different
    >levels.


    Um... what graphics processor?
    In this case, a few multiplexors, shift registers and sequencing logic.
    (I suppose we could launch into a debate over what constitutes a processor,
    but lets not).


    >If is is read-only and every time you read it you get the same value it
    >probably is read-only memory. If the value differs, it obviously is some
    >sort of memory mapped I/O device.


    What if it's a read/write configuration register in an I/O device (such
    as the baud-rate divisor in a UART)?

    Whats it it's a read/write latch that always returns the compliment of
    it's last written value ...? What if it's a more complex function (like
    an encryption device)?


    >If it is read-write and every time you read what you wrote before, it is
    >obviously read-write memory. If it differs it either is defective or it
    >is some sort of memory mapped I/O. Size doesn't matter, the functionality
    >defines what it is, no?


    Agreed - but the topic seems to be on exactly the functionality
    differentiates memory from I/O...


    >Of course you could realize memory that causes I/O somewhere to happen,
    >with some logic connected to the memory bus, but the processor which
    >only sees the memory won't know about that.


    But the processor also doesn't "know about" the memory - all it "knows"
    is how to do a bus transfer. What "knows" if a particular address should
    be expected to return the value last written is the software - which also
    knows about the video output, because it was written produce video output,
    not just to manipulate values in memory (my various monitors etc. would
    not have subroutines to manage the memory-mapped display if the display
    did not exist - I would have no reason to treat this block of memory as
    special).


    >What if someone else uses such a machine and figures, that the access
    >time for this video memory is better than for other memory, less wait
    >states. This one might tell the I/O processor to get off that memory for
    >20ms and try to use it to run some very time critical code. This person
    >would find that the memory won't allow to execute code reliable and
    >probably would describe it as flaky. Just a matter of perspective...


    Again I disagree - the purpose for which this particular hardware was
    designed was to produce a video display - there are lots of devices which
    it used outside of their design intent will either not work at all, or
    will work unreliably for that purpose - I do not consider these devices
    or their designs "flaky" - I would consider the problem to be that someone
    mistook a piece of I/O hardware (which happens to be memory mapped) for
    general purpose memory.


    >> If I had decided not to include read logic, the display would still have
    >> worked, and had none of the charactistics of a memory array - a very
    >> small change to the schematic, yet apparently a quantum shift in the
    >> type of device...

    >
    >Write-only memory then, I/O is not the only reason why one would want that.


    Curious if you consider unimplemented address space on the bus normally
    used for system memory access (open bus) to be "write only memory"?

    Also curious as to a practical use for "write only memory" that is not a
    method of I/O (In my above example, the video display is I/O - specifically
    'O'). I suppose you could flush a DMA device to unimplemented address (if
    the DMA controller doesn't fault).


    >> Camp B says - No, we don't disagree that there are vibrations in the
    >> air, and the micrphone will record the pattern - this pattern is then used
    >> by the playback requipment to generate actual sound.

    >
    >Well, then we put some birds and monkeys in the forest, that are trained
    >to repeat what they heard. No technical recording of air vibrations
    >involved anymore.


    At this point Camp-B would become split, with those that think sound is
    the interpretation of vibrations by any type of ear/brain conceeding that
    in this particular case sound is produced, and those which think that sound
    is the interpretation of vibrations by a human ear/brain stating that just
    because the recording device is organic it doesn't change the reasoning.

    And the pointless debate rages on...


    >Yep. That was what I was trying to say. The processor can only see some
    >memory and does memory operations on it. If there is some sort of I/O
    >processor listening too and doing stuff, then there will be some I/O
    >going on, but on a different level.
    >Memory mapped I/O is different from that, it places I/O registers into
    >the address space of the processor and allows it to do I/O operations
    >directly on this devices.


    Hold that thought...

    >> What if my 16x64 display is built using 1024 discrete read/write latches,
    >> each driving a decoder which directly drives the corresponding
    >> character cell (non video obviously) without a controller chip smart
    >> enough to be considered a processor - is this still memory?

    >
    >As long as you can read back what you wrote before that is memory. Even
    >if you decide to use magnetic cores for each cell it is memory.


    So the baud-rate divisor register in my memory-mapped UART is memory
    because it always returns the last value written ... ?

    What about a UART with the transmit connected to the receive (loopback),
    I write a value to the data register, and after some time it shows up in
    the receive register - same address .... This meets your requirement.
    Is it memory?

    If the answer is NO to the above, then it would seem that this argument
    is expecting a "ram chip", or at least a generally accepted form of
    ramdom-access-memory hardware, not specific functionality of the device.


    >> And if there is no read logic - is it still memory?

    >
    >Write-only memory.


    So if the baud-rate register which can be read/written in memory, then
    would the above argument not suggest that the configuration registers
    which do not return the last written value are also memory - just write
    only memory?

    It would seem that this argument is conditioned on it being a memory
    bus, not a particular functionality of the device.


    >> My NorthStar disk controller was a card full of TTL, no processor or other
    >> smarts at all, mapped into the S-100 memory bus ... Very little on this card
    >> could be written and then read back like memory ... but the CPU performed
    >> accesses to it in exactly the same was as the video card beside it...

    >
    >Memory mapped I/O.


    >> What if I put the same video display on the I/O bus - is it still memory?

    >
    >No memory at all.


    I don't think you can have it both ways - if a RAM chip based video display
    connected to the memory bus is memory (specifically memory mapped memory),
    and a non-RAM chip based device attached to the memory bus is memory mapped
    I/O, then would not a RAM-chip based device connected to the I/O bus be
    I/O mapped memory by your own arguments?


    >> And if those latches are write only?

    >
    >Write-only memory.


    So a RAM chip based video display is memory.
    A discreet latch based video display is memory.
    A discreet latch driving the front panel leds - also memory?
    But not if on the I/O bus?

    One of my first printers was a Model 43 teletype which I bit-based
    using the interrupt-enable output on the 8080 processor (this system
    didn't use interrupts) ... neither memory or I/O bus involved in any
    way ... I consider it I/O ... ?

    On some of my 6809 systems, I mapped a write-only system control
    latch to the system ROM address space - so reading gives the boot
    ROM, and writing controls certain system functions ... I consider
    it memory on read, and I/O on write ...

    Perhaps some of the confusion comes from the concept of an memory
    bus and an I/O bus ... Intel processor have the concept of memory
    space and I/O space ... Mostek and Motorola devices did not. I
    admit that when I first came to the 6809 from the 8080, it seemed
    "wrong" to be doing I/O via memory space. But the truth is that
    it's the same address and data bus - the only difference is that
    some instructions toggle different strobes - LDA strobed -RD while
    IN strobed -IOR. Not logically any different than external decoding
    to split the address space on the 6809 into memory and I/O regions.
    Instead of the opcode determining the type of access, it was the
    address.


    >Well, lets stop it then and agree on that we have machines, we can run
    >programs on this machines, this machines do something when programs are
    >run on them. Should be easy enough for everyone and nothing to argue
    >about anymore.


    On this I wholeheartedly agree :-)


    --
    dave06a@ Low-cost firmware development tools: www.dunfield.com
    dunfield. Classic computer collection: www.classiccmp.org/dunfield
    com Some stuff I have for sale: www.dunfield.com/sale


  18. Re: AltairZ80 simulator updated

    Dave Dunfield wrote:
    (snip)

    > I don't think you can have it both ways - if a RAM chip based video display
    > connected to the memory bus is memory (specifically memory mapped memory),
    > and a non-RAM chip based device attached to the memory bus is memory mapped
    > I/O, then would not a RAM-chip based device connected to the I/O bus be
    > I/O mapped memory by your own arguments?


    At some point it is a continuum, such that you can get closer and
    closer to being an I/O device and away from being memory.

    I might consider that some I/O operations are irreversible, and
    so are definitely I/O. Writing to a physical printer, for example.

    Writing to video RAM can be reversed by rewriting the data.
    How about a display card with no monitor connected to the output?

    -- glen


  19. Re: AltairZ80 simulator updated

    Dave Dunfield schrieb:
    >> Maybe wrong worded, I'm sure that you understand the operation of this
    >> hardware very detailed.
    >> Unplug the graphics processor and continue to use the memory, no output
    >> anymore of course, because there are different functions at different
    >> levels.

    >
    > Um... what graphics processor?
    > In this case, a few multiplexors, shift registers and sequencing logic.
    > (I suppose we could launch into a debate over what constitutes a processor,
    > but lets not).


    At least the hardware needs to read out the memory, one bye after the
    other, so there must be some register that gets incremented with every
    access. Maybe an indexed access to a character ROM is done with that value.
    Some computation is needed and then the resulting value is written into
    a DAC to generated the video signal. This program is easy enough to
    implement with TTL hardware, nevertheless GPU's are used for that since
    ages, to get more control over the generated video signal. I don't know
    if your TTL logic implements the minimal characteristics of a processor,
    the integrated GPU's probably do.

    >
    >> If is is read-only and every time you read it you get the same value it
    >> probably is read-only memory. If the value differs, it obviously is some
    >> sort of memory mapped I/O device.

    >
    > What if it's a read/write configuration register in an I/O device (such
    > as the baud-rate divisor in a UART)?


    Then you can use it as memory and in this example even no input/output
    is done yet.

    > Whats it it's a read/write latch that always returns the compliment of
    > it's last written value ...? What if it's a more complex function (like
    > an encryption device)?


    From memory you expect to read back what you wrote, this sure is some
    sort of I/O device.

    >> What if someone else uses such a machine and figures, that the access
    >> time for this video memory is better than for other memory, less wait
    >> states. This one might tell the I/O processor to get off that memory for
    >> 20ms and try to use it to run some very time critical code. This person
    >> would find that the memory won't allow to execute code reliable and
    >> probably would describe it as flaky. Just a matter of perspective...

    >
    > Again I disagree - the purpose for which this particular hardware was
    > designed was to produce a video display - there are lots of devices which
    > it used outside of their design intent will either not work at all, or
    > will work unreliably for that purpose - I do not consider these devices
    > or their designs "flaky" - I would consider the problem to be that someone
    > mistook a piece of I/O hardware (which happens to be memory mapped) for
    > general purpose memory.


    This is a lame excuse for not properly designed hardware ;-) I want to
    use a memory mapped display to run self modifying code in the video
    memory, so that I can watch the code changes on the display. Kinda game
    of life, to see if future generations possibly stop to evolute. For this
    application your hardware just is broken. Yes you never designed it for
    that, but I don't want to know, I just want to use the machine for my
    needs. Doesn't work, broken, have to get another one.

    >>> If I had decided not to include read logic, the display would still have
    >>> worked, and had none of the charactistics of a memory array - a very
    >>> small change to the schematic, yet apparently a quantum shift in the
    >>> type of device...

    >> Write-only memory then, I/O is not the only reason why one would want that.

    >
    > Curious if you consider unimplemented address space on the bus normally
    > used for system memory access (open bus) to be "write only memory"?


    Of course not, that is a null device.

    > Also curious as to a practical use for "write only memory" that is not a
    > method of I/O (In my above example, the video display is I/O - specifically
    > 'O'). I suppose you could flush a DMA device to unimplemented address (if
    > the DMA controller doesn't fault).


    Blackboxes to protocol events of a machine, without that it can be read
    or otherwise tampered with in this machine.

    >>> Camp B says - No, we don't disagree that there are vibrations in the
    >>> air, and the micrphone will record the pattern - this pattern is then used
    >>> by the playback requipment to generate actual sound.

    >> Well, then we put some birds and monkeys in the forest, that are trained
    >> to repeat what they heard. No technical recording of air vibrations
    >> involved anymore.

    >
    > At this point Camp-B would become split, with those that think sound is
    > the interpretation of vibrations by any type of ear/brain conceeding that
    > in this particular case sound is produced, and those which think that sound
    > is the interpretation of vibrations by a human ear/brain stating that just
    > because the recording device is organic it doesn't change the reasoning.
    >
    > And the pointless debate rages on...


    No it stops here, because camp B2 now obviously is ignoring facts and so
    is wrong. We know that animals are not organic recording devices, even
    if some could be trained to do that. We know that animals react to sound
    and do interpretations on their own. In that example animals will run
    away if they hear sounds of a falling tree. They will do so even if no
    human around, telling them about the sound and that they might be in
    danger. And future generations of robots used to explore the universe
    will have to react to sound too, even if no human has ever been on that
    planet yet.

    > So the baud-rate divisor register in my memory-mapped UART is memory
    > because it always returns the last value written ... ?


    Could be used for this.

    > What about a UART with the transmit connected to the receive (loopback),
    > I write a value to the data register, and after some time it shows up in
    > the receive register - same address .... This meets your requirement.
    > Is it memory?


    I write 80 to the UART. I read 0 back from it, I read 0 back from it, I
    read 0 back from it, then I read back 80. I would not use this as memory
    and it won't meet my requirements and probably neither your's.

    > If the answer is NO to the above, then it would seem that this argument
    > is expecting a "ram chip", or at least a generally accepted form of
    > ramdom-access-memory hardware, not specific functionality of the device.
    >
    >
    >>> And if there is no read logic - is it still memory?

    >> Write-only memory.

    >
    > So if the baud-rate register which can be read/written in memory, then
    > would the above argument not suggest that the configuration registers
    > which do not return the last written value are also memory - just write
    > only memory?
    >
    > It would seem that this argument is conditioned on it being a memory
    > bus, not a particular functionality of the device.


    Aha, well try to use memory that returns inverted from what was written
    into it. No problem for data, one can correct the problem, but one can't
    run program code from this.

    > Perhaps some of the confusion comes from the concept of an memory
    > bus and an I/O bus ... Intel processor have the concept of memory
    > space and I/O space ... Mostek and Motorola devices did not. I
    > admit that when I first came to the 6809 from the 8080, it seemed
    > "wrong" to be doing I/O via memory space. But the truth is that
    > it's the same address and data bus - the only difference is that
    > some instructions toggle different strobes - LDA strobed -RD while
    > IN strobed -IOR. Not logically any different than external decoding
    > to split the address space on the 6809 into memory and I/O regions.
    > Instead of the opcode determining the type of access, it was the
    > address.


    Nothing wrong with that, many devices like network controllers, disk
    controllers, video displays have memory buffers to be mapped into the
    address space of the host CPU, even if that one has a separate I/O bus.
    Most of this devices will do nothing if you read/write the memory
    buffers, the I/O hardware needs some more information about what to do next.

    >> Well, lets stop it then and agree on that we have machines, we can run
    >> programs on this machines, this machines do something when programs are
    >> run on them. Should be easy enough for everyone and nothing to argue
    >> about anymore.

    >
    > On this I wholeheartedly agree :-)


    :-)

    > --
    > dave06a@ Low-cost firmware development tools: www.dunfield.com
    > dunfield. Classic computer collection: www.classiccmp.org/dunfield
    > com Some stuff I have for sale: www.dunfield.com/sale
    >


    Udo Munk
    --
    The real fun is building it and then using it...

  20. Re: AltairZ80 simulator updated

    >> Um... what graphics processor?
    >> In this case, a few multiplexors, shift registers and sequencing logic.
    >> (I suppose we could launch into a debate over what constitutes a processor,
    >> but lets not).


    >At least the hardware needs to read out the memory, one bye after the
    >other, so there must be some register that gets incremented with every
    >access. Maybe an indexed access to a character ROM is done with that value.
    >Some computation is needed and then the resulting value is written into
    >a DAC to generated the video signal. This program is easy enough to
    >implement with TTL hardware, nevertheless GPU's are used for that since
    >ages, to get more control over the generated video signal. I don't know
    >if your TTL logic implements the minimal characteristics of a processor,
    >the integrated GPU's probably do.


    The fact that it's an intelligent processor or relatively dumb TTL sequencer
    is not really relavent - the issue is that it's a dual port RAM and information
    is being extracted from it by another means than the original processor bus.
    In other words information is flowing from the computer through the RAM chip
    and on to an external device.



    >> What if it's a read/write configuration register in an I/O device (such
    >> as the baud-rate divisor in a UART)?


    >Then you can use it as memory and in this example even no input/output
    >is done yet.


    I agree with this - but for some reason, if the UART exists on a pus called
    an I/O bus, it no longer becomes memory (by your earlier arguments)... ?


    >> Again I disagree - the purpose for which this particular hardware was
    >> designed was to produce a video display - there are lots of devices which
    >> it used outside of their design intent will either not work at all, or
    >> will work unreliably for that purpose - I do not consider these devices
    >> or their designs "flaky" - I would consider the problem to be that someone
    >> mistook a piece of I/O hardware (which happens to be memory mapped) for
    >> general purpose memory.


    >This is a lame excuse for not properly designed hardware ;-) I want to
    >use a memory mapped display to run self modifying code in the video
    >memory, so that I can watch the code changes on the display. Kinda game
    >of life, to see if future generations possibly stop to evolute. For this
    >application your hardware just is broken. Yes you never designed it for
    >that, but I don't want to know, I just want to use the machine for my
    >needs. Doesn't work, broken, have to get another one.


    Ok - now I understand, if you wish to use a device for a purpose it was
    neither intended nor designed to do, your very wish contradicts the basis
    of that design and renders it broken. Just so we know we are having a
    rational doscussion.


    >> Also curious as to a practical use for "write only memory" that is not a
    >> method of I/O (In my above example, the video display is I/O - specifically
    >> 'O'). I suppose you could flush a DMA device to unimplemented address (if
    >> the DMA controller doesn't fault).


    >Blackboxes to protocol events of a machine, without that it can be read
    >or otherwise tampered with in this machine.


    Ah... but it seems to me that this does get read at some point. So I guess
    you are adding the requirment that the read has to take place over same
    bus as the write occured.



    >> At this point Camp-B would become split, with those that think sound is
    >> the interpretation of vibrations by any type of ear/brain conceeding that
    >> in this particular case sound is produced, and those which think that sound
    >> is the interpretation of vibrations by a human ear/brain stating that just
    >> because the recording device is organic it doesn't change the reasoning.
    >>
    >> And the pointless debate rages on...


    >No it stops here, because camp B2 now obviously is ignoring facts and so
    >is wrong. We know that animals are not organic recording devices, even
    >if some could be trained to do that. We know that animals react to sound
    >and do interpretations on their own. In that example animals will run
    >away if they hear sounds of a falling tree. They will do so even if no
    >human around, telling them about the sound and that they might be in
    >danger. And future generations of robots used to explore the universe
    >will have to react to sound too, even if no human has ever been on that
    >planet yet.


    I'm glad you resolved that ... many a philosophy prof could benefit from
    this knowlege ... there's just that nagging little thing about the differing
    viewpoints on the definition of sound. (at the onset I mentioned that there
    is no doubt on either side that vibrations in the air are occuring).

    I did make a mistake in not reminding you after your last response that one
    of the original conditions in this very old debate is that "no one is around
    to hear it" - queue fruther debates on what constitutes "no one".

    Just as I have no doubt about what is occuding when a system outputs
    data to a memory mapped console. My viewpoint is that when used for
    this function, it's an I/O device - yours differs, and clearly nobody is going
    to convince anybody else of their viewpoint.

    FWIW, I happen to be a Camp-A type on the "tree falls in the forest"
    debate - but I understand and appreciate the viewpoinrs of Camp-B.


    >> What about a UART with the transmit connected to the receive (loopback),
    >> I write a value to the data register, and after some time it shows up in
    >> the receive register - same address .... This meets your requirement.
    >> Is it memory?


    >I write 80 to the UART. I read 0 back from it, I read 0 back from it, I
    >read 0 back from it, then I read back 80. I would not use this as memory
    >and it won't meet my requirements and probably neither your's.


    This meets your originally stated requirements (that what you must be able
    to read back what you write) - so now you must update the requirements and
    add a speed of response factor?

    Come to think about it, even the original requirement has a little niggling
    problem with ROM.


    >> If the answer is NO to the above, then it would seem that this argument
    >> is expecting a "ram chip", or at least a generally accepted form of
    >> ramdom-access-memory hardware, not specific functionality of the device.


    ?



    >> So if the baud-rate register which can be read/written in memory, then
    >> would the above argument not suggest that the configuration registers
    >> which do not return the last written value are also memory - just write
    >> only memory?
    >>
    >> It would seem that this argument is conditioned on it being a memory
    >> bus, not a particular functionality of the device.


    >Aha, well try to use memory that returns inverted from what was written
    >into it. No problem for data, one can correct the problem, but one can't
    >run program code from this.


    Aha indeed - we have another requirement - the processor must be
    able to execute from said memory - the list grows. [And why couldn't
    you execute from it - if your loader inverts the data before it stores it,
    the cpu could run quite nicely from it]

    This also has a niggling problem with ROM (sinewave table for example,
    not very executable).


    >> Perhaps some of the confusion comes from the concept of an memory
    >> bus and an I/O bus ... Intel processor have the concept of memory
    >> space and I/O space ... Mostek and Motorola devices did not. I
    >> admit that when I first came to the 6809 from the 8080, it seemed
    >> "wrong" to be doing I/O via memory space. But the truth is that
    >> it's the same address and data bus - the only difference is that
    >> some instructions toggle different strobes - LDA strobed -RD while
    >> IN strobed -IOR. Not logically any different than external decoding
    >> to split the address space on the 6809 into memory and I/O regions.
    >> Instead of the opcode determining the type of access, it was the
    >> address.


    >Nothing wrong with that, many devices like network controllers, disk
    >controllers, video displays have memory buffers to be mapped into the
    >address space of the host CPU, even if that one has a separate I/O bus.
    >Most of this devices will do nothing if you read/write the memory
    >buffers, the I/O hardware needs some more information about what to do next.


    Ok - I guess I've lost track of your original argument as this is all agreeable
    to me.

    To my viewpoint, the terminology applied to a device should represent the
    primary function of the device in a system - a video display to me is an I/O
    (specifically 'O') device because it's primary purpose is to move information
    from the system to the operator.

    I have no trouble with the fact that some implementations of this type of
    device may exhibit charactistics in common with general purpose memory,
    and can even be used like general purpose memory (ignoring for the moment
    the "noise" occurring on the screen) however just like the baud rate divisor
    register in the UART, this is not it's primary function in the system, and I
    don't think of it as "just more memory".

    The fact that we need an ever increasing in complexity set of rules to set
    the defintiion of memory to match charactistics possible in such devices
    tells us that this is not a clearly defined boundary.

    Nuff said.


    --
    dave06a@ Low-cost firmware development tools: www.dunfield.com
    dunfield. Classic computer collection: www.classiccmp.org/dunfield
    com Some stuff I have for sale: www.dunfield.com/sale


+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast