Announcement

Collapse

Forum Rules and Etiquette

Our mission ...

This forum is part of our mission to promote the preservation of vintage computers through education and outreach. (In real life we also run events and have a museum.) We encourage you to join us, participate, share your knowledge, and enjoy.

This forum has been around in this format for over 15 years. These rules and guidelines help us maintain a healthy and active community, and we moderate the forum to keep things on track. Please familiarize yourself with these rules and guidelines.


Rule 1: Remain civil and respectful

There are several hundred people who actively participate here. People come from all different backgrounds and will have different ways of seeing things. You will not agree with everything you read here. Back-and-forth discussions are fine but do not cross the line into rude or disrespectful behavior.

Conduct yourself as you would at any other place where people come together in person to discuss their hobby. If you wouldn't say something to somebody in person, then you probably should not be writing it here.

This should be obvious but, just in case: profanity, threats, slurs against any group (sexual, racial, gender, etc.) will not be tolerated.


Rule 2: Stay close to the original topic being discussed
  • If you are starting a new thread choose a reasonable sub-forum to start your thread. (If you choose incorrectly don't worry, we can fix that.)
  • If you are responding to a thread, stay on topic - the original poster was trying to achieve something. You can always start a new thread instead of potentially "hijacking" an existing thread.



Rule 3: Contribute something meaningful

To put things in engineering terms, we value a high signal to noise ratio. Coming here should not be a waste of time.
  • This is not a chat room. If you are taking less than 30 seconds to make a post then you are probably doing something wrong. A post should be on topic, clear, and contribute something meaningful to the discussion. If people read your posts and feel that their time as been wasted, they will stop reading your posts. Worse yet, they will stop visiting and we'll lose their experience and contributions.
  • Do not bump threads.
  • Do not "necro-post" unless you are following up to a specific person on a specific thread. And even then, that person may have moved on. Just start a new thread for your related topic.
  • Use the Private Message system for posts that are targeted at a specific person.


Rule 4: "PM Sent!" messages (or, how to use the Private Message system)

This forum has a private message feature that we want people to use for messages that are not of general interest to other members.

In short, if you are going to reply to a thread and that reply is targeted to a specific individual and not of interest to anybody else (either now or in the future) then send a private message instead.

Here are some obvious examples of when you should not reply to a thread and use the PM system instead:
  • "PM Sent!": Do not tell the rest of us that you sent a PM ... the forum software will tell the other person that they have a PM waiting.
  • "How much is shipping to ....": This is a very specific and directed question that is not of interest to anybody else.


Why do we have this policy? Sending a "PM Sent!" type message basically wastes everybody else's time by making them having to scroll past a post in a thread that looks to be updated, when the update is not meaningful. And the person you are sending the PM to will be notified by the forum software that they have a message waiting for them. Look up at the top near the right edge where it says 'Notifications' ... if you have a PM waiting, it will tell you there.

Rule 5: Copyright and other legal issues

We are here to discuss vintage computing, so discussing software, books, and other intellectual property that is on-topic is fine. We don't want people using these forums to discuss or enable copyright violations or other things that are against the law; whether you agree with the law or not is irrelevant. Do not use our resources for something that is legally or morally questionable.

Our discussions here generally fall under "fair use." Telling people how to pirate a software title is an example of something that is not allowable here.


Reporting problematic posts

If you see spam, a wildly off-topic post, or something abusive or illegal please report the thread by clicking on the "Report Post" icon. (It looks like an exclamation point in a triangle and it is available under every post.) This send a notification to all of the moderators, so somebody will see it and deal with it.

If you are unsure you may consider sending a private message to a moderator instead.


New user moderation

New users are directly moderated so that we can weed spammers out early. This means that for your first 10 posts you will have some delay before they are seen. We understand this can be disruptive to the flow of conversation and we try to keep up with our new user moderation duties to avoid undue inconvenience. Please do not make duplicate posts, extra posts to bump your post count, or ask the moderators to expedite this process; 10 moderated posts will go by quickly.

New users also have a smaller personal message inbox limit and are rate limited when sending PMs to other users.


Other suggestions
  • Use Google, books, or other definitive sources. There is a lot of information out there.
  • Don't make people guess at what you are trying to say; we are not mind readers. Be clear and concise.
  • Spelling and grammar are not rated, but they do make a post easier to read.
See more
See less

Kaypro 4-83 graphic overlay

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Still struggling with the weird stray pixels and corruptions.
    When I write horiziontal lines almost no corruption happens, when writing vertical lines stray pixels appear at random places.

    Hope you can see this video: https://www.youtube.com/watch?v=_fJVwtxcsWM

    The hash is quite visible when hammering the read/writes but it causes no permanent corruptions.
    Last edited by gertk; October 27, 2020, 02:07 AM.

    Comment


      #17
      Originally posted by gertk View Post
      Hope you can see this video: https://www.youtube.com/watch?v=_fJVwtxcsWM

      The hash is quite visible when hammering the read/writes but it causes no permanent corruptions.
      Huh. So when you so "no permanent corruptions" do you mean the offset/extra dots that are appearing between the vertical "pinstripes" don't read back as incorrect if you read the memory contents back? (Because they do seem to be stable on the screen.)
      My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

      Comment


        #18
        ... wait, never mind the above, I realized you were just referring to the hash not leaving a mark.

        In the video it kind of looked like a lot of the dots were offset a consistent distance from the column they were supposed to be in, could this be simply a noise/crosstalk issue? I spent hobby time this weekend rebuilding my prototype to use an AVR 324 instead of a 328 for the timing generator, and after neatening up the wiring I have significantly reduced “jailbar” interference, but that’s let me notice some individual flickering dots. What’s interesting about them is their locations are pretty consistent and I can make them go away by resting my hand on the data bus wires; it’s like certain magic combinations of address and data bus conditions can add up to enough noise to trigger a glitch.
        My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

        Comment


          #19
          Originally posted by Eudimorphodon View Post
          ... wait, never mind the above, I realized you were just referring to the hash not leaving a mark.

          In the video it kind of looked like a lot of the dots were offset a consistent distance from the column they were supposed to be in, could this be simply a noise/crosstalk issue? I spent hobby time this weekend rebuilding my prototype to use an AVR 324 instead of a 328 for the timing generator, and after neatening up the wiring I have significantly reduced “jailbar” interference, but that’s let me notice some individual flickering dots. What’s interesting about them is their locations are pretty consistent and I can make them go away by resting my hand on the data bus wires; it’s like certain magic combinations of address and data bus conditions can add up to enough noise to trigger a glitch.
          Yes I was thinking about interference also but the only way I could influence the corruptions is by laying my fingers on the pins of the buffer and/or latches and squeezing hard.
          Viewing the signals with the oscilloscope they are nice and square.

          My guess is that the write timing is too critical. Since the SRAM /WR pulse is generated by the PIO's BRDY signal and this also switches the outputs around from the counters to the latches, the moment the SRAM /WR rises the address latches and databuffer also leave the SRAM address- and databus and the counter outputs take over again.
          According to the datasheet of the SRAM the write hold time can be as short as 0 ns so in theory it should work.

          Another possibility is that the latches are too slow (74HC573) and the address they provide is not stable as the SRAM /WR pulse is released.

          The length of the BRDY pulse from the PIO (with BSTB and BRDY connected together) should be one clock cycle (200 ns as my CPU is clocked at 5 MHz at the moment but switching it back to 2.5 MHz makes no difference, in the circuit diagram it is difficult to see if the PIO and SIO chips are also clocked from the same source as the CPU, have to check with the oscilloscope.

          If not reading or writing the SRAM through the PIO the screen is rocksteady, never misses a pixel, in fact I only reset both counters at once on the vertical sync and there are no weird byte shifts or such per line.


          I will try to replace the latches with edge triggered 74HC574 or 74F574 instead of the transparant 74HC573 latches I have in there now, if no succes I will hook up the Salea16 logic analyzer to the board and see what is going on...

          Comment


            #20
            For laughs here's a picture of one of those magic "flickering yet persistent" dots on my prototype. Cleaning up the wiring on the breadboard nixed most of them, but that one dot visible under the pterosaur's chin in low-res mode below:

            324proto_32column.jpg

            Was still around, at least in the initial round of testing I did yesterday evening. (I generated a couple new test plates with information useful for actually verifying that I was getting the correct number of pixels per line, et al, and demo displaying different-width framebuffers offset in different memory locations and doing horizontal/vertical hardware scrolling.) I could make it go away by putting my finger on the flash chip, and then disappeared mystly after I yanked out the MCU for reprogramming the second time and shoved some wiring around a little. Curiously the dot was *not* there in high-res mode, even though that's referencing the same location on the same frame buffer, only in low res. Some very minor timing difference...

            (I have a suspicion based on the location of the glitch that this is related to address line A12 updating, because in the wiring rats-nest that crosses a wire that shares a pull-up between the shift register and the ROM chip...)

            The lesson I'm taking away from this is that noise/crosstalk/signal integrity is a harsh mistress when you're playing with multi-mhz circuits. I'm sure this is going to be super-fun now that I'm about out of excuses to not start working on the RAM interfacing/contention circuitry.
            Last edited by Eudimorphodon; October 29, 2020, 12:04 PM.
            My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

            Comment


              #21
              Yes I found out timing is crucial and datasheets can be very unclear... I now have replaced both the HC573 latches with 16V8 GAL's as 74F574 are hard to get and I didn't want to wait (...) hoping they might be a bit faster and edge triggered but now I can not even get those GAL's to work properly... Pfff.... They should latch on the rising edge of the clock signal but al I seem to get is 'transparancy'. Need to fiddle a bit more with those.

              Also the datasheets of the SRAM chips I have are unclear on what signal the data is stored into the cell, only in the IS61C256 datasheet is an example of using the SRAM with /CE and /OE permanently low and it says the write cycle is then /WE controlled. And then I found out that my GAL16V8's programmed as latches didn't work

              Comment


                #22
                GAL as latch problem solved: seems the compiler refuses to generate registered outputs if either the CLK pin (pin 1) is named, or the /OE pin (pin 11) is named, or you assign output enables to the (registered) outputs. And it does it silently..

                Progress so far: if I enable the latch and buffer outputs (and thereby disable the counter outputs) with an additional IO line from the PIO and let the BRDY just handle the /WR pulse for the SRAM it works flawlessy, no more pixel errors. Reading and writing is fine.
                Disadvantage of this scenario is speed, I now have to enable the outputs, then perform read or write and then disable the outputs again.
                The hash stripes just get longer this way but at least they are black during this period.

                The /OE and /CS of the SRAM are now constant at GND level, just the /WR gets pulsed.

                Comment


                  #23
                  This is the result so far, no more stray pixels..

                  justlines_ok.jpg

                  Comment


                    #24
                    And another update

                    The stray pixels were generated by address bus conflicts between the counter outputs and the latch outputs.
                    It seems the 74HC590a releases the output quite slow.

                    By means of an extra delay in the GAL (connecting an output to an input) I managed to get the outputs of the counters released a little bit before the latches come onto the bus and I can also delay and squeeze the /WR pulse in between. So effectively a write to the SRAM is reduced to a single OUT instruction, that is after setting up the address in the address latches before.
                    The 'hash' is now reduced to small stripes (about 200 ns in length...)

                    Comment

                    Working...
                    X