ULA&RAM above 32767 - Sinclair

This is a discussion on ULA&RAM above 32767 - Sinclair ; I've recently participated in a thread about Spectrum's ULA so I tried to find some additional data but didn't succeed. I would like to find an explanation about ULA NOT slowing down programs located above the address of 32767 (#f777) ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: ULA&RAM above 32767

  1. ULA&RAM above 32767

    I've recently participated in a thread about Spectrum's ULA so I tried
    to find some additional data but didn't succeed. I would like to find
    an explanation about ULA NOT slowing down programs located above the
    address of 32767 (#f777) when reading from video memory.

    I am aware of the fact that ULA&procesor can't read RAM in the same
    time (*) so loaders and sound routines shouldn't take place in the 1st
    16K of the Spectrum's RAM but don't remember what *exactly* happens in
    the upper 32K :-/

    (*)
    I also know Spectrum's memory map
    --
    Chupo

  2. Re: ULA&RAM above 32767

    Chupo did eloquently scribble:
    > I've recently participated in a thread about Spectrum's ULA so I tried
    > to find some additional data but didn't succeed. I would like to find
    > an explanation about ULA NOT slowing down programs located above the
    > address of 32767 (#f777) when reading from video memory.


    Memory is separated into 4 "banks" if you will...
    The bottom 16k is the only one tied to the ULA because it's the only RAM
    that the ULA has to read regularely for screen updates)

    That's why contention doesn't affect the top 32K. The ULA doesn't touch it.
    --
    __________________________________________________ ____________________________
    | spike1@freenet.co.uk | |
    |Andrew Halliwell BSc(hons)| "The day Microsoft makes something that doesn't |
    | in | suck is probably the day they start making |
    | Computer science | vacuum cleaners" - Ernst Jan Plugge |
    ------------------------------------------------------------------------------

  3. Re: ULA&RAM above 32767

    In article , @freenet.co.uk> says...



    > That's why contention doesn't affect the top 32K. The ULA doesn't touch it.
    >


    Thanx very much!
    --
    Chupo

  4. Re: ULA&RAM above 32767

    Chupo escribi├│:
    > 16K of the Spectrum's RAM but don't remember what *exactly* happens in
    > the upper 32K :-/


    The Spectrum memory map is physically divided into two data buses. One
    of this buses is tied directly to the ULA, and the other one is tied
    directly to the CPU.

    Splitting data buses allows CPU and ULA to perform bus cycles to its
    corresponding memory, at the same time.

    The problem is how to communicate the two data buses so the CPU can read
    and write to memory in the other data bus.

    A modern design would employ a bus arbitrer, such as the one present in
    the Commodore Amiga design. In this computer, the concept of FastMEM,
    ChipMEM, etc... relates to the availability of that RAM to the CPU. If I
    remember well, ChipMEM is tied to the DMA logic, and it's used to
    generate video signal, sound, disk DMA, etc. FastMEM is tied to the
    68000, and it's not accesiible to DMA, so the CPU is the only device to
    control it.

    Some 8-bit computers use time slicing by means of letting the videochip
    to access memory on the rising edge of the clock signal, and the CPU on
    the falling edge (or having two clocks ****ed one quarter of period and
    using each one to control video chip and CPU). This was possible due to
    the fact that RAM memory were much faster than CPU's at that time.

    Some others use transceiver that isolate the buses, and only allows data
    coming thru one to another qhen they detect a bus cycle from the CPU
    trying to access memory in the other bus. This is a simple way to
    implement a bus arbitrer. The Dragon Computer uses a 74LS series chip
    called.... ┬┐SAM? to perform this task.

    The Spectrum uses the cheapest of all these methods: it uses resistors
    to isolate the two buses. The ULA monitors CPU operations and it ties
    CPU clock high only when the CPU tries to access to memory in the ULA
    data bus when the ULA itself is performing a read cycle bus.

    If the CPU only accesses memory at locations above #7FFF (i.e. A15=1),
    the ULA monitor logic will rest assured that the current bus cycle won't
    access memory on its data bus, so the CPU clock can run continously.

    Hope this helps.... sometimes I'm not very lucky with my english
    "speeches"

    --
    Miguel Angel

  5. Re: ULA&RAM above 32767

    McLeod / IdeaFix did eloquently scribble:
    > Chupo escribiˇ:
    >> 16K of the Spectrum's RAM but don't remember what *exactly* happens in
    >> the upper 32K :-/


    > The Spectrum memory map is physically divided into two data buses. One
    > of this buses is tied directly to the ULA, and the other one is tied
    > directly to the CPU.


    > Splitting data buses allows CPU and ULA to perform bus cycles to its
    > corresponding memory, at the same time.


    > The problem is how to communicate the two data buses so the CPU can read
    > and write to memory in the other data bus.


    > A modern design would employ a bus arbitrer, such as the one present in
    > the Commodore Amiga design. In this computer, the concept of FastMEM,
    > ChipMEM, etc... relates to the availability of that RAM to the CPU. If I
    > remember well, ChipMEM is tied to the DMA logic, and it's used to
    > generate video signal, sound, disk DMA, etc. FastMEM is tied to the
    > 68000, and it's not accesiible to DMA, so the CPU is the only device to
    > control it.


    > Some 8-bit computers use time slicing by means of letting the videochip
    > to access memory on the rising edge of the clock signal, and the CPU on
    > the falling edge (or having two clocks ****ed one quarter of period and
    > using each one to control video chip and CPU). This was possible due to
    > the fact that RAM memory were much faster than CPU's at that time.


    > Some others use transceiver that isolate the buses, and only allows data
    > coming thru one to another qhen they detect a bus cycle from the CPU
    > trying to access memory in the other bus. This is a simple way to
    > implement a bus arbitrer. The Dragon Computer uses a 74LS series chip
    > called.... ┐SAM? to perform this task.


    > The Spectrum uses the cheapest of all these methods: it uses resistors
    > to isolate the two buses. The ULA monitors CPU operations and it ties
    > CPU clock high only when the CPU tries to access to memory in the ULA
    > data bus when the ULA itself is performing a read cycle bus.


    > If the CPU only accesses memory at locations above #7FFF (i.e. A15=1),
    > the ULA monitor logic will rest assured that the current bus cycle won't
    > access memory on its data bus, so the CPU clock can run continously.


    > Hope this helps.... sometimes I'm not very lucky with my english
    > "speeches"


    Well, it was certainly more detailed than my explanation!

    --
    __________________________________________________ ____________________________
    | spike1@freenet.co.uk | "Are you pondering what I'm pondering Pinky?" |
    |Andrew Halliwell BSc(hons)| |
    | in | "I think so brain, but this time, you control |
    | Computer Science | the Encounter suit, and I'll do the voice..." |
    ------------------------------------------------------------------------------

  6. Re: ULA&RAM above 32767

    On Wed, 2 May 2007 19:34:20 +0200, Chupo wrote:

    >I am aware of the fact that ULA&procesor can't read RAM in the same
    >time (*) so loaders and sound routines shouldn't take place in the 1st
    >16K of the Spectrum's RAM [...]


    In theory, it's perfectly possible to place a loader in the lower 16K
    of RAM.

    In practice, I've never tried it on real hardware yet.

    http://homepage.ntlworld.com/mark.woodmass/amaurote.csw

  7. Re: ULA&RAM above 32767

    On May 2, 9:53 pm, Woody wrote:
    > In theory, it's perfectly possible to place a loader in the lower 16K
    > of RAM.
    > In practice, I've never tried it on real hardware yet.


    I doubt it would be reliable although there seems to be a fair bit of
    flexibility built into the tape routines. The 16K game "Cruising on
    Broadway" has a ZX Printer driver written in the first 16K of RAM. The
    routine disables interrupts and is similar to the ROM routine but
    because the stylus skips past the sensor while the ULA has access to
    the RAM, printouts of the screen become increasingly staggered to the
    right of the paper.

    --
    G.


  8. Re: ULA&RAM above 32767

    Yes and it answered the eternal question of why they did it that way, and
    thus we all now know, it was cheaper, I guess we should have guessed!

    Brian

    --
    Brian Gaff....Note, this account does not accept Bcc: email.
    graphics are great, but the blind can't hear them
    Email: briang1@blueyonder.co.uk
    __________________________________________________ __________________________________________________ __________


    wrote in message
    newsm7ng4-rgq.ln1@ridcully.ntlworld.com...
    > McLeod / IdeaFix did eloquently scribble:
    >> Chupo escribiˇ:
    >>> 16K of the Spectrum's RAM but don't remember what *exactly* happens in
    >>> the upper 32K :-/

    >
    >> The Spectrum memory map is physically divided into two data buses. One
    >> of this buses is tied directly to the ULA, and the other one is tied
    >> directly to the CPU.

    >
    >> Splitting data buses allows CPU and ULA to perform bus cycles to its
    >> corresponding memory, at the same time.

    >
    >> The problem is how to communicate the two data buses so the CPU can read
    >> and write to memory in the other data bus.

    >
    >> A modern design would employ a bus arbitrer, such as the one present in
    >> the Commodore Amiga design. In this computer, the concept of FastMEM,
    >> ChipMEM, etc... relates to the availability of that RAM to the CPU. If I
    >> remember well, ChipMEM is tied to the DMA logic, and it's used to
    >> generate video signal, sound, disk DMA, etc. FastMEM is tied to the
    >> 68000, and it's not accesiible to DMA, so the CPU is the only device to
    >> control it.

    >
    >> Some 8-bit computers use time slicing by means of letting the videochip
    >> to access memory on the rising edge of the clock signal, and the CPU on
    >> the falling edge (or having two clocks ****ed one quarter of period and
    >> using each one to control video chip and CPU). This was possible due to
    >> the fact that RAM memory were much faster than CPU's at that time.

    >
    >> Some others use transceiver that isolate the buses, and only allows data
    >> coming thru one to another qhen they detect a bus cycle from the CPU
    >> trying to access memory in the other bus. This is a simple way to
    >> implement a bus arbitrer. The Dragon Computer uses a 74LS series chip
    >> called.... ┐SAM? to perform this task.

    >
    >> The Spectrum uses the cheapest of all these methods: it uses resistors
    >> to isolate the two buses. The ULA monitors CPU operations and it ties
    >> CPU clock high only when the CPU tries to access to memory in the ULA
    >> data bus when the ULA itself is performing a read cycle bus.

    >
    >> If the CPU only accesses memory at locations above #7FFF (i.e. A15=1),
    >> the ULA monitor logic will rest assured that the current bus cycle won't
    >> access memory on its data bus, so the CPU clock can run continously.

    >
    >> Hope this helps.... sometimes I'm not very lucky with my english
    >> "speeches"

    >
    > Well, it was certainly more detailed than my explanation!
    >
    > --
    > __________________________________________________ ____________________________
    > | spike1@freenet.co.uk | "Are you pondering what I'm pondering Pinky?"
    > |
    > |Andrew Halliwell BSc(hons)|
    > |
    > | in | "I think so brain, but this time, you control
    > |
    > | Computer Science | the Encounter suit, and I'll do the
    > voice..." |
    > ------------------------------------------------------------------------------



  9. Re: ULA&RAM above 32767

    On 2 May 2007 17:02:40 -0700, Geoff Wearmouth
    wrote:

    >On May 2, 9:53 pm, Woody wrote:
    >> In theory, it's perfectly possible to place a loader in the lower 16K
    >> of RAM.
    >> In practice, I've never tried it on real hardware yet.

    >
    >I doubt it would be reliable although there seems to be a fair bit of
    >flexibility built into the tape routines.


    I'm positive the ROM tape routines would fail in contended memory. I'm
    not so sure my tape code would fail, but until I've actually tried it
    on real hardware...

  10. Re: ULA&RAM above 32767

    In article , McLeod / IdeaFix
    says...



    > Hope this helps.... sometimes I'm not very lucky with my english
    > "speeches"
    >


    Neither am I :-)) What can I say - a huge thanx!
    --
    Chupo

  11. Re: ULA&RAM above 32767

    In article , Woody
    says...
    > On Wed, 2 May 2007 19:34:20 +0200, Chupo wrote:
    >
    > >I am aware of the fact that ULA&procesor can't read RAM in the same
    > >time (*) so loaders and sound routines shouldn't take place in the 1st
    > >16K of the Spectrum's RAM [...]

    >
    > In theory, it's perfectly possible to place a loader in the lower 16K
    > of RAM.
    >
    > In practice, I've never tried it on real hardware yet.
    >
    > http://homepage.ntlworld.com/mark.woodmass/amaurote.csw
    >


    I believe the copy of the standard loader would work even in the lower
    RAM but turbo loaders could have some troubles.
    --
    Chupo

  12. Re: ULA&RAM above 32767

    I think the ROM routines would probably work fine in contended RAM,
    however as far as I'm aware the lower 16K (the ROM) is *not*
    contended. I may have misread the documents though.

    Also, I'd like to know what the contention is on the sideways banks in
    the Timex machines, because presumably if you're mapping a cartridge
    bank over RAM accessed by the ULA, there's no contention as the ULA is
    still accessing the bank in RAM whereas the Z80 is addressing the one
    paged in from the cartridge.


  13. Re: ULA&RAM above 32767

    Sinclair PC200 512k (V1.5) on 3 May 2007
    Loading cheveron@gmail.com .SYS.....
    : I think the ROM routines would probably work fine in contended RAM,
    : however as far as I'm aware the lower 16K (the ROM) is *not*
    : contended.

    On the +3, you can copy the ROM into contended RAM and try. I couldn't get
    the ROM tape routines to work in that configuration, and I have a hazy
    memory of seeing POKEs that had to be applied to change the timings. The
    tones produced by a save definitely sound flat to me.

    In fact, come to think of it, I posted on 13 February 1994 saying that the
    tape routines didn't work.

    --
    --------------------------- ,@@.o ,@@. SPELL SUCCEEDS
    John Elliott | @@@@ @@@@ n \_O_
    CHAOS in a sig... | '||` '||` Hr \I `
    --------------------------- JL JL I\ /\\

  14. Re: ULA&RAM above 32767

    cheveron@gmail.com wrote:
    > Also, I'd like to know what the contention is on the sideways banks in
    > the Timex machines, because presumably if you're mapping a cartridge
    > bank over RAM accessed by the ULA, there's no contention as the ULA is
    > still accessing the bank in RAM whereas the Z80 is addressing the one
    > paged in from the cartridge.


    I don't think the sideways banks in the Timex machines are contended as
    the SCLD always reads the screen from the HOME bank regardless of
    paging. I don't have a RAM cartridge to test this though.

    Fred

  15. Re: ULA&RAM above 32767

    On May 4, 6:24 pm, Fred wrote:

    > I don't think the sideways banks in the Timex machines are contended as
    > the SCLD always reads the screen from the HOME bank regardless of
    > paging. I don't have a RAM cartridge to test this though.


    There is a way to test without a cartridge. Just page in
    the dock over the 16k video ram area and repeatedly
    read data from there for, say, 10 seconds and count the
    number of interrupts in that time. Compare the number
    of interrupts to the same program running with the HOME
    bank paged in. The test program should run above 32k, of
    course.



  16. Re: ULA&RAM above 32767

    A936@hotmail.com wrote:
    > On May 4, 6:24 pm, Fred wrote:
    >
    >> I don't think the sideways banks in the Timex machines are contended as
    >> the SCLD always reads the screen from the HOME bank regardless of
    >> paging. I don't have a RAM cartridge to test this though.

    >
    > There is a way to test without a cartridge. Just page in
    > the dock over the 16k video ram area and repeatedly
    > read data from there for, say, 10 seconds and count the
    > number of interrupts in that time. Compare the number
    > of interrupts to the same program running with the HOME
    > bank paged in. The test program should run above 32k, of
    > course.


    I'll give it a try at some point.

    Fred

  17. Re: ULA&RAM above 32767

    On Thu, 03 May 2007 16:46:12 GMT, Woody
    wrote:

    >On 2 May 2007 17:02:40 -0700, Geoff Wearmouth
    >wrote:
    >
    >>On May 2, 9:53 pm, Woody wrote:
    >>> In theory, it's perfectly possible to place a loader in the lower 16K
    >>> of RAM.
    >>> In practice, I've never tried it on real hardware yet.

    >>
    >>I doubt it would be reliable although there seems to be a fair bit of
    >>flexibility built into the tape routines.

    >
    >I'm positive the ROM tape routines would fail in contended memory. I'm
    >not so sure my tape code would fail, but until I've actually tried it
    >on real hardware...


    And it doesn't work!

+ Reply to Thread