AltairZ80 simulator updated - CP/M

This is a discussion on AltairZ80 simulator updated - CP/M ; >> 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 ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 49 of 49

Thread: AltairZ80 simulator updated

  1. Re: AltairZ80 simulator updated

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


    exactly my point - there is not necessarily a clearly defined boundary
    between memory and I/O - so statements like "a video card is memory
    and not I/O" don't seem to make sense.


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


    Well ... if you really want to argue this, I disagree that you can reverse
    the video display by rewriting the data - it's purpose is to output information
    to an operator - once the operator has seen it, that information is out. He
    might write it down, he might just remember it. It's not a reliable system,
    the operator might not be looking at it during the interval when the
    information is visible, however thats just a charactistic of video displays.

    The operator might remove the paper off the printer without reading it as
    well (darn - I ment to print that on company stationary).

    As far as the computer is concerned, once the data is output to the printer
    it's interface reverts to the same stable state it was in before the output
    begain - so from an "inside the computer" sense, the display is actually
    more permanant (it takes extra work to revert it to it's original state).

    In either case, information has been output - in fact, the fact that this
    has occured is what makes it an I/O device (instead of just memory).


    >How about a display card with no monitor connected to the output?


    If it's a memory mapped card, it can be used as memory - I mentioned
    this when I first jumped into this argument. I have no trouble with that,
    but I still consider it fundamentally an I/O board - but it can be used for
    memory.

    But .. this is not what the quote above was discussing. The original
    assertion was that a video card is memory NOT I/O - and through
    a convolutions of "what if's" it came out that it's memory if it's on
    the memory bus, but not if it's on the I/O bus, while other devices
    which do not exhibit the charactistic of memory are considered
    I/O devices on the memory bus.

    If you acknowlege the existing the "memory mapped I/O", then
    you must acknowlege the possibility of "IO mapped memory"
    (in fact I've seen this done).

    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


  2. Re: AltairZ80 simulator updated

    Dave Dunfield schrieb:
    >> 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.


    If I told the logic to stop working, because I wish to update the memory
    and I don't want flickering, there is no output. If I need 3 days to
    compute the new contents for the video memory, there will be no output
    the next 3 days. After that done I allow the logic to read this memory
    and do output again.

    >>> 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)... ?


    Machines with a separate I/O bus won't allow all and any memory
    operations on that, special I/O instructions are required.

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


    A computer is a universal device that can be instructed to do many
    things via programs. Often the creativity of a user goes well beyond the
    capabilities of the machine, because someone never thought about this
    kind of usage. That teaches us to implement this machines very carefully
    to not stop anyone using them as they like. This is difficult of course
    and as long it is documented what the machine does and what not, the
    user can figure, if this machine is right for his needs, and if not so
    choose another one. If there is memory in a machine I want to use it as
    such, for reading, writing and for executing code. If that won't work
    reliable then I need another machine which does.

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


    No, why? As far as I know blackboxes are brought to a lab to read the
    contents out of the memory, because the machine using it for logging
    only can write into it and no one operating the machine is able to
    tamper with this log in any way.

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


    Well, that was not too difficult to resolve ;-)

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


    Not even the most esoteric philosophy prof will try to convince me, that
    a mic and some electronic parts and some mechanical parts that react on
    sound in some way, are "some one"? And if so, what about the stones in a
    forest, they are "some one" too?

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


    No, but that is not necessary anyway, why should we all have the same
    viewpoints?

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


    I do understand the viewpoint of camp B, but I proofed that something is
    wrong with it ;-)

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


    Ah c'mon on, you know how memory works. From memory you can read back
    what you wrote before at any time. If that differs at any time it's
    either not memory or it's broken.

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


    No. The wait states are added by the bus logic and the processor doesn't
    know about and it won't do anything special on slow memory. Of course
    now you will mention half broken memory designs requiring NOPs in the
    code, so that improperly designed memory will work ;-)

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


    That requirement was defined in the 40th already by von Neumann and
    others, nothing really new.
    And if there is no loader that could invert the bits? Then I have to
    open the CPU chip and insert one my self?

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


    Data can be executed as code. If that results into anything meaningful
    is another question. Building a CPU with instructions that do something
    useful with a sinewave table would be possible, but for what? There are
    architectures available that won't execute any data for cases where such
    things are very unwanted. And there also are ideas to build
    architectures, where the data is the central point of view and the logic
    to process the data adjusts to it. That's how our brains seem to work
    somehow, this is not a wetware processor with a fixed instruction set
    given by whom ever.

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


    I was arguing that nothing happens if I read/write some memory. If I
    want something to happen, because that memory is shared by multiple
    processors, I need to tell the other guys about it.

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


    Yes of course, but by writing into some memory nothing happens.

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


    Yep.

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


    All that is needed is appropriate documentation about what will happen
    if I read/write/execute memory range x-y, that is all.

    > Nuff said.


    Agreed.

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

  3. Re: AltairZ80 simulator updated


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


    >If I told the logic to stop working, because I wish to update the memory
    >and I don't want flickering, there is no output. If I need 3 days to
    >compute the new contents for the video memory, there will be no output
    >the next 3 days. After that done I allow the logic to read this memory
    >and do output again.


    Ok ... so what? nanoseconds or days - both memory and I/O support the
    use of wait states, duration does not change the technique.



    >> 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)... ?


    >Machines with a separate I/O bus won't allow all and any memory
    >operations on that, special I/O instructions are required.


    Again ... so what? Do you have a new requirement that certain addressing
    modes must be available for memory?


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


    >A computer is a universal device that can be instructed to do many
    > ...
    >. If there is memory in a machine I want to use it as
    >such, for reading, writing and for executing code. If that won't work
    >reliable then I need another machine which does.


    Sadly a computer is not a universal device - no matter how hard I try,
    I can't get it to run hot enough to cook my breakfast -- do I consider it
    broken because of this ... no

    The registers in a video card are only "memory" because you insist
    that they are memory - I see no requirement for a video card to contain
    functional memory.

    I don't really see what this has to do with the original discussion on the
    terminology of memory and I/O ....


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


    >No, why? As far as I know blackboxes are brought to a lab to read the
    >contents out of the memory, because the machine using it for logging
    >only can write into it and no one operating the machine is able to
    >tamper with this log in any way.


    So as stated above, it can be read - just not over the same processor bus
    that was used to write it (wait ... didn't I already say this).

    Just checked, and none of my "universal" computers seem to have black
    box write only memories in them... Again, not really sure why this continues
    to be relavent to the discussion - but good fodder for arguing every point
    it seems.


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


    >Well, that was not too difficult to resolve ;-)


    Of course, with a certain viewpoint you can resolve most anything to your
    own satisfaction.


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


    >Not even the most esoteric philosophy prof will try to convince me, that
    >a mic and some electronic parts and some mechanical parts that react on
    >sound in some way, are "some one"? And if so, what about the stones in a
    >forest, they are "some one" too?


    Never suggested that they were (this was in reference to the animals).



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


    >I do understand the viewpoint of camp B, but I proofed that something is
    >wrong with it ;-)



    Of course, with a certain viewpoint you can prove most anything to your
    own satisfaction.



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


    >Ah c'mon on, you know how memory works. From memory you can read back
    >what you wrote before at any time. If that differs at any time it's
    >either not memory or it's broken.


    Yes, I do - but I'm not the one trying to define what memory is, and updating
    my requirements as needed to keep it ... I stated from the beginning that my
    S-100 video card (which I consider an I/O card) could be used for memory.


    >No. The wait states are added by the bus logic and the processor doesn't
    >know about and it won't do anything special on slow memory. Of course
    >now you will mention half broken memory designs requiring NOPs in the
    >code, so that improperly designed memory will work ;-)


    You still missed the point - it worked perfectly for read/write, and that was
    all it was designed for - You only consider it broken because of your viewpoint
    that it has to be something else because it resides on a processor memory
    bus and has some charactistics of general purpose memory.


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


    >That requirement was defined in the 40th already by von Neumann and
    >others, nothing really new.
    >And if there is no loader that could invert the bits? Then I have to
    >open the CPU chip and insert one my self?


    There's always a loader - it may be a software program running on the
    system loading into RAM, or it may be done at the factory when read-only
    memory is manufactured - or it could be an exteral programmer with
    re-writable devices.


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


    >Data can be executed as code. If that results into anything meaningful
    >is another question. Building a CPU with instructions that do something
    >useful with a sinewave table would be possible, but for what? There are
    >architectures available that won't execute any data for cases where such
    >things are very unwanted. And there also are ideas to build
    >architectures, where the data is the central point of view and the logic
    >to process the data adjusts to it. That's how our brains seem to work
    >somehow, this is not a wetware processor with a fixed instruction set
    >given by whom ever.


    Again the point is missed, which is that the "rules" whereby you define
    what is memory and what is not are not as hard and fast as you would
    think - you indicated that executing from it was a requirement for memory
    - that voids many static data tables. (and if you don't care about the
    content of code - only that the CPU tries to execute "something" - that
    will happen no matter what is connected to the bus, so "nothing" becomes
    oerfectly valid)


    >I was arguing that nothing happens if I read/write some memory. If I
    >want something to happen, because that memory is shared by multiple
    >processors, I need to tell the other guys about it.


    Not necessarily - inter-processer communication through dial-port memory
    is often synchronized by control data in the memory itself - My S-100
    video display did not require I/O ports, it just "always" shows the content
    of the video RAM.


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


    >Yes of course, but by writing into some memory nothing happens.


    The content of the video screen changes.... is this nothing.



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


    >All that is needed is appropriate documentation about what will happen
    >if I read/write/execute memory range x-y, that is all.


    That entirely depends on what's in the address range x-y ... might be
    memory, might be memory mapped I/O, which may or may not have
    charactistics similar to general purpose memory.


    >> Nuff said.


    >Agreed.


    Apparently not ... however if you have a burning desire to have the last word
    please respond. I have stated my viewpoint, and see no benefit to continuing...


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


  4. Re: AltairZ80 simulator updated

    Dave Dunfield schrieb:
    >> If I told the logic to stop working, because I wish to update the memory
    >> and I don't want flickering, there is no output. If I need 3 days to
    >> compute the new contents for the video memory, there will be no output
    >> the next 3 days. After that done I allow the logic to read this memory
    >> and do output again.

    >
    > Ok ... so what? nanoseconds or days - both memory and I/O support the
    > use of wait states, duration does not change the technique.


    There is no memory or I/O device with 3 day wait states. The host
    processor is reading and writing the memory like nuts and there still is
    no output, because the graphics logic was told not to output anything,
    different level of operation.

    >> Machines with a separate I/O bus won't allow all and any memory
    >> operations on that, special I/O instructions are required.

    >
    > Again ... so what? Do you have a new requirement that certain addressing
    > modes must be available for memory?


    It is not my requirement and it is not new. The manufacturer of a
    processor defines the addressing modes for memory.

    >> A computer is a universal device that can be instructed to do many
    >> ...
    >> . If there is memory in a machine I want to use it as
    >> such, for reading, writing and for executing code. If that won't work
    >> reliable then I need another machine which does.

    >
    > Sadly a computer is not a universal device - no matter how hard I try,
    > I can't get it to run hot enough to cook my breakfast -- do I consider it
    > broken because of this ... no


    Then you didn't try hard enough. Cooking your breakfast is trivial
    compared to computer equipment building cars from thousands of parts. If
    you don't want to build your own then buy one in Japan, this guys are
    pretty good at this.

    > The registers in a video card are only "memory" because you insist
    > that they are memory - I see no requirement for a video card to contain
    > functional memory.


    Weren't we talking about video cards that map memory into the host
    processors address space?

    >> No, why? As far as I know blackboxes are brought to a lab to read the
    >> contents out of the memory, because the machine using it for logging
    >> only can write into it and no one operating the machine is able to
    >> tamper with this log in any way.

    >
    > So as stated above, it can be read - just not over the same processor bus
    > that was used to write it (wait ... didn't I already say this).


    The processor using it as logging device can write only into it. Of
    course you can remove it into another device that can read it. But that
    is a different machine then with other capabilities.

    > Just checked, and none of my "universal" computers seem to have black
    > box write only memories in them... Again, not really sure why this continues
    > to be relavent to the discussion - but good fodder for arguing every point
    > it seems.


    And because your computers doesn't have this, write-only memory doesn't
    exist? I would suggest to add such a thing, then your computer has one
    too, and then it exists.

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

    >
    >> Well, that was not too difficult to resolve ;-)

    >
    > Of course, with a certain viewpoint you can resolve most anything to your
    > own satisfaction.


    Yep.

    >> Not even the most esoteric philosophy prof will try to convince me, that
    >> a mic and some electronic parts and some mechanical parts that react on
    >> sound in some way, are "some one"? And if so, what about the stones in a
    >> forest, they are "some one" too?

    >
    > Never suggested that they were (this was in reference to the animals).


    I know and because I can accept that animals are "some one", same as
    humans are "some one", I asked about robots exploring the forest and
    about stones just being there. Of course it is a trap question, so you
    avoided the answer ;-)

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

    >
    >> I do understand the viewpoint of camp B, but I proofed that something is
    >> wrong with it ;-)

    >
    >
    > Of course, with a certain viewpoint you can prove most anything to your
    > own satisfaction.


    Yep.

    >
    >> Ah c'mon on, you know how memory works. From memory you can read back
    >> what you wrote before at any time. If that differs at any time it's
    >> either not memory or it's broken.

    >
    > Yes, I do - but I'm not the one trying to define what memory is, and updating
    > my requirements as needed to keep it ... I stated from the beginning that my
    > S-100 video card (which I consider an I/O card) could be used for memory.


    Nor am I trying to define what memory is, because that can be read in
    the specs of any processor. It just is memory for the host processor, if
    the video logic does generate output or not doesn't depend on the usage
    of the memory by the host processor.

    >> No. The wait states are added by the bus logic and the processor doesn't
    >> know about and it won't do anything special on slow memory. Of course
    >> now you will mention half broken memory designs requiring NOPs in the
    >> code, so that improperly designed memory will work ;-)

    >
    > You still missed the point - it worked perfectly for read/write, and that was
    > all it was designed for - You only consider it broken because of your viewpoint
    > that it has to be something else because it resides on a processor memory
    > bus and has some charactistics of general purpose memory.


    I do that? I only use the specs of the processor that tells me how I can
    use memory. If it's not working as described something is wrong with it.

    >> That requirement was defined in the 40th already by von Neumann and
    >> others, nothing really new.
    >> And if there is no loader that could invert the bits? Then I have to
    >> open the CPU chip and insert one my self?

    >
    > There's always a loader - it may be a software program running on the
    > system loading into RAM, or it may be done at the factory when read-only
    > memory is manufactured - or it could be an exteral programmer with
    > re-writable devices.


    There is not always a loader and machines without any still are
    operational and in use.

    >> Data can be executed as code. If that results into anything meaningful
    >> is another question. Building a CPU with instructions that do something
    >> useful with a sinewave table would be possible, but for what? There are
    >> architectures available that won't execute any data for cases where such
    >> things are very unwanted. And there also are ideas to build
    >> architectures, where the data is the central point of view and the logic
    >> to process the data adjusts to it. That's how our brains seem to work
    >> somehow, this is not a wetware processor with a fixed instruction set
    >> given by whom ever.

    >
    > Again the point is missed, which is that the "rules" whereby you define
    > what is memory and what is not are not as hard and fast as you would
    > think - you indicated that executing from it was a requirement for memory


    Again, I didn't define that, von Neumann did, and manufactures of
    processors made the things working as he defined.

    > - that voids many static data tables. (and if you don't care about the
    > content of code - only that the CPU tries to execute "something" - that
    > will happen no matter what is connected to the bus, so "nothing" becomes
    > oerfectly valid)


    Exactly that was the idea. It proofed to have some deficits, so other
    architectures were designed. The processors in a couple of years
    probably won't execute data anymore.

    >> I was arguing that nothing happens if I read/write some memory. If I
    >> want something to happen, because that memory is shared by multiple
    >> processors, I need to tell the other guys about it.

    >
    > Not necessarily - inter-processer communication through dial-port memory
    > is often synchronized by control data in the memory itself - My S-100
    > video display did not require I/O ports, it just "always" shows the content
    > of the video RAM.


    I wrote that communication between two and more processors requires some
    sort of communication. How that is done doesn't matter.

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

    >
    >> Yes of course, but by writing into some memory nothing happens.

    >
    > The content of the video screen changes.... is this nothing.


    It doesn't change, the memory cells written change, otherwise nothing
    happens.

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

    >
    >> All that is needed is appropriate documentation about what will happen
    >> if I read/write/execute memory range x-y, that is all.

    >
    > That entirely depends on what's in the address range x-y ... might be
    > memory, might be memory mapped I/O, which may or may not have
    > charactistics similar to general purpose memory.


    Yep.

    >>> Nuff said.

    >
    >> Agreed.

    >
    > Apparently not ... however if you have a burning desire to have the last word
    > please respond. I have stated my viewpoint, and see no benefit to continuing...


    Done.

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

  5. Re: AltairZ80 simulator updated

    You just want to keep going don'ch ya. Ok


    >There is no memory or I/O device with 3 day wait states. The host
    >processor is reading and writing the memory like nuts and there still is
    >no output, because the graphics logic was told not to output anything,
    >different level of operation.


    Point missed entirely - Duration of the wait state doesn't change the
    principal ... I see nothing to be gained in following this further (btw,
    wait states can apply to memory as well as I/O, so they are not
    really relavent to a discussion on which is which).


    >>> Machines with a separate I/O bus won't allow all and any memory
    >>> operations on that, special I/O instructions are required.

    >>
    >> Again ... so what? Do you have a new requirement that certain addressing
    >> modes must be available for memory?


    >It is not my requirement and it is not new. The manufacturer of a
    >processor defines the addressing modes for memory.


    Again point missed entirely (the 8080 has far fewer addressing modes
    than the 6809 - yet pretty much everyone (even 6809 users) still considers
    that it can use memory. All that is needed to access memory is the basic
    ability to read and write) - the I/O bus has the ability to read/write - if I
    attach a RAM chip to it and use it to store data (I've done this with small
    non-volatile devices) it's I/O mapped memory.


    >>> A computer is a universal device that can be instructed to do many
    >>> ...
    >>> . If there is memory in a machine I want to use it as
    >>> such, for reading, writing and for executing code. If that won't work
    >>> reliable then I need another machine which does.

    >>
    >> Sadly a computer is not a universal device - no matter how hard I try,
    >> I can't get it to run hot enough to cook my breakfast -- do I consider it
    >> broken because of this ... no


    >Then you didn't try hard enough. Cooking your breakfast is trivial
    >compared to computer equipment building cars from thousands of parts. If
    >you don't want to build your own then buy one in Japan, this guys are
    >pretty good at this.


    Again point missed entirely (that a computer is not a universal device)
    My computer wasn't designed to BE a stove - it could certainly control a stove,
    but I don't consider it broken because it can't BE one ... Some (many) memory
    mapped devices are not designed to BE memory .. they might be all or partially
    usable as memory, but designs which don't happen to BE memory are not
    broken. I'd provide another example, but to what point.


    >> The registers in a video card are only "memory" because you insist
    >> that they are memory - I see no requirement for a video card to contain
    >> functional memory.


    >Weren't we talking about video cards that map memory into the host
    >processors address space?


    No, we are talking about video cards which appear on the host computer
    bus which happens to also be used for general purpose memory, and have
    charactistics which are like general purpose memory - they may or may not
    contain an actual chip with a designation known to be a RAM chip, but that is
    irrelavent to the functional design of the device as a whole (I've used RAM
    chips in lots of things that have no function resembling general purpose
    memory).


    >>> No, why? As far as I know blackboxes are brought to a lab to read the
    >>> contents out of the memory, because the machine using it for logging
    >>> only can write into it and no one operating the machine is able to
    >>> tamper with this log in any way.

    >>
    >> So as stated above, it can be read - just not over the same processor bus
    >> that was used to write it (wait ... didn't I already say this).


    >The processor using it as logging device can write only into it. Of
    >course you can remove it into another device that can read it. But that
    >is a different machine then with other capabilities.


    Point missed - the recording device is outputting data from the system.

    Perhaps I can simplify it for you - how about the fact that blackbox
    software recording devices are not mapped into of general purpose
    addressable memory address space. To do so would A) eat gobs of
    memory space (some of these devices hold a LOT of data) , B) void
    the intent of the device because the monitored system would have to
    know about (and manage) the layout of data in the device and could write
    data out of sequence (which would invalidate the history) and C) allow
    the device to be corrupted by errant writes by the monitored system.

    In fact, blackbox software recording devices most often appear as I/O
    (which might be memory mapped) and contain their own internal memory
    sequencing logic. The host processor does not see it as memory, write-
    only or otherwise. You need another example of useful "write only memory"
    which does not perform I/O or otherwise output data from the system.



    >>> Not even the most esoteric philosophy prof will try to convince me, that
    >>> a mic and some electronic parts and some mechanical parts that react on
    >>> sound in some way, are "some one"? And if so, what about the stones in a
    >>> forest, they are "some one" too?

    >>
    >> Never suggested that they were (this was in reference to the animals).


    >I know and because I can accept that animals are "some one", same as
    >humans are "some one", I asked about robots exploring the forest and
    >about stones just being there. Of course it is a trap question, so you
    >avoided the answer ;-)


    No, it just didn't seem relavent - the Camp-B argument is that the robot
    responds to vibrations in the air, but that is not necessarily sound (the
    whole point of this pointless debate is a definition of sound - and my point
    in mentioning it in the first place is that arguing over the definition of
    memory and I/O is equally pointless - but you seem to have missed
    that)



    >Nor am I trying to define what memory is, because that can be read in
    >the specs of any processor. It just is memory for the host processor, if
    >the video logic does generate output or not doesn't depend on the usage
    >of the memory by the host processor.


    Yet you argue up and down that if I use a chip normally used for RAM as
    part of the bus interface to a video card attached to the processor bus used
    to access general purpose memory it has to be memory and is broken
    if the design does not support all the capabilities of general purpose memory.
    In the next breath you state that the same RAM chip placed on the I/O bus
    (and fully read-writable by the processor) is NOT memory.


    >> You still missed the point - it worked perfectly for read/write, and that was
    >> all it was designed for - You only consider it broken because of your viewpoint
    >> that it has to be something else because it resides on a processor memory
    >> bus and has some charactistics of general purpose memory.


    >I do that? I only use the specs of the processor that tells me how I can
    >use memory. If it's not working as described something is wrong with it.


    So - by that definition, any memory mapped I/O device which is write only,
    or maps different registers into reads is broken ... I personally don't think
    so, but you are entitled to your viewpoint.

    (btw - If I were planning to use a video subsystems buffer as general purpose
    memory, I wouldn't just consult the CPU specifications and assume it would
    work.- I would place much more import on the video subsystem specifications.
    "looks like a fish, smells like a fish, tasts like a fish --- must BE a fish"
    doesn't always apply in this business... I've spent many an hour staring at a
    scope and scratching my head in learning that over the years).


    >> There's always a loader - it may be a software program running on the
    >> system loading into RAM, or it may be done at the factory when read-only
    >> memory is manufactured - or it could be an exteral programmer with
    >> re-writable devices.


    >There is not always a loader and machines without any still are
    >operational and in use.


    Another point missed - there is always some means of putting the program
    into memory. It may not reside on the system executing the code (ROM),
    but there is always the possibility to encode the data representing the
    code in any way that might be required (any algorithmic pattern generated
    by the code data would be no different to encode into memory that the
    original code).


    >> Again the point is missed, which is that the "rules" whereby you define
    >> what is memory and what is not are not as hard and fast as you would
    >> think - you indicated that executing from it was a requirement for memory


    >Again, I didn't define that, von Neumann did, and manufactures of
    >processors made the things working as he defined.


    von Neuman specified the concept of stored program, and people
    liked the idea and built machines which worked that way .... and I agree
    that memory is required to execute code in a von Neumann architecture,
    however excution of code is not a requirement for memory - I'd give an
    example, but why open another pointless path.

    IIRC von Neuman speced. no requirement that everything attached to
    the computers memory bus has to be functional memory or considered
    to be functional memory.


    >> - that voids many static data tables. (and if you don't care about the
    >> content of code - only that the CPU tries to execute "something" - that
    >> will happen no matter what is connected to the bus, so "nothing" becomes
    >> oerfectly valid)


    >Exactly that was the idea. It proofed to have some deficits, so other
    >architectures were designed. The processors in a couple of years
    >probably won't execute data anymore.


    Point missed - (these are examples of how your stated requrement to
    execute from memory cannot always apply) - I see no benefit in
    persuing another example.


    >>> I was arguing that nothing happens if I read/write some memory. If I
    >>> want something to happen, because that memory is shared by multiple
    >>> processors, I need to tell the other guys about it.

    >>
    >> Not necessarily - inter-processer communication through dial-port memory
    >> is often synchronized by control data in the memory itself - My S-100
    >> video display did not require I/O ports, it just "always" shows the content
    >> of the video RAM.


    >I wrote that communication between two and more processors requires some
    >sort of communication. How that is done doesn't matter.


    Point missed - consider your statements

    - Anything on the memory bus that looks somewhat like memory is memory
    - Nothing happens if I read/write memory
    - communication between two and more processors requires some
    sort of communication. How that is done doesn't matter.

    These statements are contradictory in the case of a shared memory interface
    with the control channel embedded in the shared address space (a very
    common construct) - I see nothing toi be gained in persuing another example.


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

    >>
    >>> Yes of course, but by writing into some memory nothing happens.

    >>
    >> The content of the video screen changes.... is this nothing.


    >It doesn't change, the memory cells written change, otherwise nothing
    >happens.


    ??

    The pattern being shifted out to the video monitor changes - causing the
    words on the screen to change... If those happen to say something like
    "THE REACTOR COOLING SYSTEM HAS FAILED" you can bet that
    lots of other things will happen ... And the interesting point, is that even if
    the host computer cannot read back what it wrote to this memory address
    space (which may or may not consist of devices bearing designations
    known to be memory devices) - those external things will still happen.
    If those words were instead written to an unused block of general purpose
    memory due to a programming error, then this would be a very serious
    software bug. The point (in case it was missed) being that the purpose of
    the display is to provide information to the operator, not to store those
    inside the computer - in my viewpoint, that makes it an I/O device.

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


  6. Re: AltairZ80 simulator updated

    --{ Udo Munk a plopé ceci: }--

    > There is no memory or I/O device with 3 day wait states. The host



    Just try a NFS mount over a http://www.ietf.org/rfc/rfc1149.txt
    compliant link. You've got your three days


    --

    Ne pas utiliser la gnôle des marais quand un futex vous a jeté
    un sort de catégorie "use gdb, you lamer".


  7. Re: AltairZ80 simulator updated

    Thierry B. wrote:

    > --{ Udo Munk a plopé ceci: }--


    >>There is no memory or I/O device with 3 day wait states. The host


    > Just try a NFS mount over a http://www.ietf.org/rfc/rfc1149.txt
    > compliant link. You've got your three days


    I believe I have done it longer than three days. I once
    had diskless machines wait over three days for the server
    to come back up. When it did, the clients continued on just
    fine.

    NFS is interesting in this case. It is normal for I/O
    wait to be done at a low level in the OS, such that one
    can't easily break out of it. (Especially for data
    integrity reasons.)

    -- glen


  8. Re: AltairZ80 simulator updated

    > Just try a NFS mount over a http://www.ietf.org/rfc/rfc1149.txt
    > compliant link. You've got your three days


    Floppies aren't that heavy, you might get it to fit in one "packet" with
    an unusual variant of forward error correction.

    De

  9. Re: AltairZ80 simulator updated

    Dennis Boone wrote:

    > > Just try a NFS mount over a http://www.ietf.org/rfc/rfc1149.txt
    > > compliant link. You've got your three days

    >
    > Floppies aren't that heavy, you might get it to fit in one "packet" with
    > an unusual variant of forward error correction.


    Oops. I forgot about that one.

    But NFS does really work with three day delay. I have done it.

    I have also sold a computer that others still had mounted.
    That would have been more than three days.

    -- glen


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