Image Map Image Map
Page 2 of 2 FirstFirst 12
Results 11 to 15 of 15

Thread: Kaypro 4-83 graphic overlay

  1. #11

    Default

    Quote Originally Posted by Eudimorphodon View Post
    ... I was about to say I'm still a little confused, but I think I get it? I was about to say the datasheet I have for the '166 seems to indicate that when you hold "clear" the output at Qh is low, so that shouldn't really be any different than if clear isn't held low and the '166 is happily running along clocking out the low states it's getting from pin 1 being grounded, but... in the kaypro I assume the problem is you're still getting the "load" pin toggled and loading random memory contents even when you're out of the active video area, so you're pulling "clear" to squelch that.
    Yes the Kaypro counters keep running and thus /DCTC is also active during the retrace/blanking periods.

    (Would it be any more efficient to make the shift register load switchable on/and/off by the GAL instead of manipulating clear? I guess it probably wouldn't make much difference. At least the takeaway is my scheme should be fine as long as I'm only generating load signals in the active area.)
    Since the dotclock is not fed into the GAL it would be tricky to rely on the GAL to generate the load for the shift register.

    Yeah, I was trying to think at one point if a scheme like that with latches really helped me, but I keep getting stuck on the fact that while you might be able to use one to make *writes* synchronous you're boned when the CPU wants to read from memory; either you take the glitch or you need to generate wait states because you won't be able to preload a read latch for when the CPU request comes in.
    For reading you could do the same, it just takes two accesses: one for setting the address and the second for reading the data. That is what is happening with my board also since the /ENA pulse is happening after read from the PIO, and the data is thus latched too late, a second 'IN' instruction then reads the PIO latched data.


    Since the TRS-80 is one of my design inspirations I was looking at how the Model III de-glitched its display (the Model I didn't), and if I understand its service manual correctly it basically has logic to pull down the WAIT signal for the Z80 if video RAM is accessed outside of a blanking area and holds it until it goes into blank. Worst case that would halt the CPU for 64 character's worth of video output. (IE, it looks like it makes no attempt to make the access hold any more granular than that.) If that's a legit way to go that's easy, I could just implement similar logic that defines "not in blank" by that line that lets the load counter in the GAL run. It does seem like there should be a "smarter" way to do it, though, definitely.

    (Ultimately maybe I don't care about video glitch artifacts as long as I can actually make the memory read/writes reliable, but glitch free would be "nice".)
    On the Acorn Atom the video is also not synchronized to the CPU (and they used a 6502 and an 6847 which can do that perfectly!) and with the games they just waited for the vertical blank to appear and then read/write the screen data. Outside that area there was also 'snow' on the screen.. Alas a lot of CPU cycles were lost..

    Here's a picture of the video output from mine as it stands. I just this week solved a problem with another function I had the GAL for, which was a selectable 2:1 clock divider for the pixel clock so I could do both "high" and low-res modes in hardware. (512 vs 256 pixel; the TRS-80 and some of the S-100 cards I want to be able to emulate had 32 column modes.) Shows high and low res alternately running with the same source bitmap. (With the lower res I can move a 32 bytes "viewport" around on a 64 byte line by adjusting counter offsets.)

    Attachment 64175
    Pictures look very nice, and yes you can do some real magic with those GAL's but I often run out of outputs...

  2. #12
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    2,940

    Default

    Quote Originally Posted by gertk View Post
    Since the dotclock is not fed into the GAL it would be tricky to rely on the GAL to generate the load for the shift register.
    Yeah, I wasn't thinking of having the GAL generate the load, just mute it if you're not in the blanking area, IE, psuedocode:

    /SRLOAD = /BLANK * /DCTC

    Where "blank" is whatever combination of conditions that say you're on an active section of a line... but, actually, how you're doing it with holding clear is probably better. The thing that actually pushed me over into generating the LOAD signal with the GAL on my design is I was having some spurious issues after I added the "low-res" clock divider that looked like issues with the LOAD signal registering, and I *think* the culprit may have been the propagation delay added to the pixel clock was causing it to "miss" the load signal going direct from the timing. Whatever it was generating the load signal on a counter again directly in phase with the pixel clock cleaned it up. I suppose there's a chance if you gated LOAD on the GAL it would put the shifted pixels slightly out of register with the Kaypro's pixels?

    For reading you could do the same, it just takes two accesses: one for setting the address and the second for reading the data. That is what is happening with my board also since the /ENA pulse is happening after read from the PIO, and the data is thus latched too late, a second 'IN' instruction then reads the PIO latched data.
    I was planning to make my board straight memory-mapped (although there will probably be a page register so it doesn't actually take a full 12k+ of linear address space, at least unless you want it to), so I don't have the PIO load cycles to get a jump on the memory addresses. Pretty much stuck with techniques that work inside of a single memory read/write cycle.

    Something that's crossed my mind is maybe having some kind of "state machine" based on the SR load counter that would present a wait state on video memory access if it happens within, say, 3/4's of the character cycle leading up to the shift register load, but open it up for a couple bits immediately after the load has been latched. I need to sit down with a piece of paper and compare the machine state timing of the Z-80 with a cycle like that and see if that would leave useful windows long enough for the Z-80 to shove in a read or write and finish with enough time for the address bus to switch back to the "CRTC" and settle to get a clean pixel output for the shift register. Depending on the ratio between CPU speed and character timing I have a feeling it might just end up synchronously sampling T-states during the "wrong" period and ride to the end of the active line anyway, making it the same as the Model III's wait-for-blank method.

    (At 12mhz there's an odd number of pixel clocks per line with my timing, so drifting in and out of "register" would be a real possibility too.)

    On the Acorn Atom the video is also not synchronized to the CPU (and they used a 6502 and an 6847 which can do that perfectly!) and with the games they just waited for the vertical blank to appear and then read/write the screen data. Outside that area there was also 'snow' on the screen.. Alas a lot of CPU cycles were lost..
    I vaguely recall the early versions of the Commodore PET used memory too slow for the 6502's lockstep to work, so they had a vertical refresh interrupt that they intended all screen updates to happen during. (Which means they hash if you write directly to the screen.) But later ones did the timing sync thing?

    Pictures look very nice, and yes you can do some real magic with those GAL's but I often run out of outputs...
    Doing things like counters in GALs makes me realize it's probably time to suck it up and try a full CPLD. It's kind of a bummer there aren't any "internal" registers, if you want a counter you lose an output for every bit. :P
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  3. #13

    Default

    Some years ago I connected an 8 bit ISA VGA card to a Z80: http://kgelabs.nl/?p=147
    Needed a special 'initial wait state generator' to get the memory access right (see the handdrawn circuit on that page above)

    The VGA card asserted the /WAIT line too late for the Z80 to act upon (especially during writes). The circuit now asserts the /WAIT line almost immediately after /MREQ and holds it for the first cycles.
    After the circuit has taken /WAIT low, the VGA card itself takes the /WAIT over until the memory access is done.

  4. #14
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    2,940

    Default

    Quote Originally Posted by gertk View Post
    The VGA card asserted the /WAIT line too late for the Z80 to act upon (especially during writes). The circuit now asserts the /WAIT line almost immediately after /MREQ and holds it for the first cycles.
    After the circuit has taken /WAIT low, the VGA card itself takes the /WAIT over until the memory access is done.
    Huh. Looking at an ISA reference it says "Devices using this signal to insert wait states should drive it low immediately after detecting a valid address decode and an active read or write command". I guess the important part there is the "and an active read or write command"; looking at the graphs for a Z-80 bus cycle the Z80 on a read cycle asserts READ at the *same time* as MREQ, while the ISA bus timing does show IOCHRDY not coming until after the read/write pulse starts. So I guess always pre-emptively toggling the insertion of a WAIT on decode is indeed what you'd have to do to be sure when adapting an ISA device.

    Thanks you for this, I was looking for some practical examples of how to do WAITs on the Z80.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  5. #15

    Default

    Small update:

    I noticed that the 79th column of my graphics overlay only displayed the leftmost pixel. Seems the horizontal sync signal I used for blanking starts at the beginning of the character..
    By using the horizontal sync signal from pin E2 it now displays the 79th column correctly but als column 80, 81 82 etc.. up to the end of the screen...
    Not a real big problem as you can simply wipe those bytes and then it is fine.

    The 1010101 dot patterns which sometimes occured on the far left side are gone now.
    Still I am getting minor corruption on random places on screen during writes and can not lay my finger on those.
    I reprogrammed the GAL to also emit an /OE signal for the ram hoping it might help but it made no difference.

    The graphics video on/off is now done by an additional logic equation on the reset of the shift register and works fine freeing up an output pin on the GAL (now used for the /OE of the RAM)

    The inversion of the graphics output of the shift register is now done by the unused NAND port of U15 (lifted pins 1, 2, 3 and 6 from the socket, video from the graphics board enters on pin 1+2 and pin 3 is connected to pin 6 for mixing with the original Kaypro output)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •