Image Map Image Map
Page 1 of 3 123 LastLast
Results 1 to 10 of 28

Thread: A dumb (but obscure) Commodore PET video implementation question: Hardware cursor?

  1. #1
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    3,284

    Default A dumb (but obscure) Commodore PET video implementation question: Hardware cursor?

    Today I stumbled across Steve Gray's build-your-own custom EDIT ROM project:

    http://www.6502.org/users/sjgray/pro...rom/index.html

    Because, short version, I might possibly have an interest in a custom EDIT ROM (and maybe Kernel?) in the next couple months. I just started poking around the code, and while I'm *pretty* sure I know the answer I want to double check:

    Do Commodore PETs have a hardware cursor? I don't *remember* the non-CRTC having one, but do the CRTC-equipped ones avail themselves of the cursor register in their 6845 chip? I *thought* both just used a software loop to update/blink the cursor... and I hope that's actually the case, because the alternative throws a minor monkey wrench into my plans.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  2. #2

    Default

    Yes, it is an hardware cursor. The MOS 6545 is based on Motorola's 6845 and that one has an hardware cursor to start with.

    Weird detail: Motorola's 6845 cannot replace the 6546 but the UM6845 and the Hitachi 6845 can. It has to do with how some registers are treated but I don't know the details anymore.
    With kind regards / met vriendelijke groet, Ruud Baltissen

    www.baltissen.org

  3. #3
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    3,284

    Default

    Quote Originally Posted by Ruud View Post
    Yes, it is an hardware cursor. The MOS 6545 is based on Motorola's 6845 and that one has an hardware cursor to start with.
    I know the chip has a hardware cursor output line, but does the PET actually use it? I was digging through that edit ROM code some more and I think I found the “blink the cursor” code, which *looks* like it uses the CPU to alternately write a cursor character over whatever is at a screen memory location and restore it, but I haven’t remotely digested the whole thing.

    Edit: N/M, probably.The light bulb came on that checking the schematics might help, and according to the schematics for the “universal” boards posted on Zimmers pin 19 on the CRTC is NC. So even if you programmed the cursor register it wouldn’t do anything. So unless it does a blink using some stand-alone address matching register to be compatible with one in non-crtc PETs I’m probably good?
    Last edited by Eudimorphodon; December 9th, 2020 at 06:59 AM.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  4. #4
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    3,284

    Default

    Maybe a little context of why I'm asking dumb questions about the PET might be useful.

    In a few other places I've mentioned in passing that I'm working on a kind of "Generic" memory-mapped video output circuit which uses an AVR CPU basically as a "self-programming" CRTC, the idea being to come up with something that can transparently emulate a number of arbitrary different memory-mapped video systems from the 1970's. (Early S-100 cards, TRS-80, etc.) I'm *pretty* much done with the pixel-pushing part, at least to the point that it's time to interface it to a computer, and while my initial motivation was targeting Z80-based machines it occurred to me that the easiest thing might be to build a 6502-based computer on a breadboard. But why a 6502? My design uses a GAL chip to implement a state machine which automatically triggers the shift register load once every eight pixel clocks, and my vague understanding of how the 6502 handles its bus had it occur to me that I *should* be able to program into the same chip a "Phi clock" to transparently share the same memory chip between the 6502 and the video output with no WAIT state handshaking.

    I've programmed a GAL to implement a Phi output that should result in an effective 1mhz CPU clock in 40 column mode, and ordered a WDC6502, because that includes a line to tri-state the address and data busses. So I *think* all I need to do is add some '244 or '245 buffers on the address lines going from the "CRTC" to RAM and have them and the tri-state pin on the 6502 active on opposite phases of the Phi2 clock to glue the two together? Basically I'm going by this:

    https://laughtonelectronics.com/Arca...%20Timing.html

    I am kind of wondering if I may need to hold the memory to the 6502 for another extra half-tick of the 8mhz source after Phi goes low to make sure the memory read/write is latched when Phi2 goes low? Has anyone else built something like this?

    Anyway, a 6502 with a memory-mapped screen and little else is basically a PET, so I figured I could *probably* use 2001 ROM set to get a splash on the screen. Obviously I won't get keyboard input or a blinking cursor without the 6521 and 6522s. (And I'll need to generate a vblank interrupt too?) I have a set of those, but I was wondering how difficult it'd be to hack up an edit ROM to substitute some kind of brain-dead PS/2 or serial keyboard hack for the original PET scanning code, since I don't really have a spare PET keyboard matrix lying around.

    That leads to another couple dumb questions: my vague understanding is that most of the 6545's registers are write-only? Will a Commodore EDIT ROM that has 6545 initialization code work in a PET with "hardwired" video (IE, can you pull the ROMs from a "universal-board" 4032 and plug them into a "dynamic-board" model) as long as the "hardwired" video is the correct format, or would the CRTC initialization code have to be yanked out if I tried hacking a ROM from Sgray's source?

    (My circuit does have selectable video modes, including full bitmap graphics, which I intend to expose to the CPU "somehow" for switching, but I wasn't intending to try to actually emulate a CRTC, which I'm not even sure would be feasible. Just something simple like "once a frame read this latch to see which of (x-many choices) video modes", at least at first.)
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  5. #5
    Join Date
    May 2019
    Location
    San Diego CA
    Posts
    208

    Default

    Ben Eater's latest worst video card ever video actually has quite a bit of good information about 6502 timing.

    He is not interleaving like the Apple II did (and you plan to), but there are some details about timing of the tri-state bus timing.

    https://www.youtube.com/watch?v=BUTHtNrpwiI

  6. #6
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    3,284

    Default

    Yeah, I've been watching his worst video card series; I actually linked to it on a video I stuck on my own pathetic YouTube channel about phase one of this project.

    FWIW, the techniques he describes in his interface-it-to-the-6502 videos are definitely going in my mental toolbox for interfacing to a Z-80. I know an issue he would have with his system if he tried to overlay video and CPU access time is his effective pixel clock is 5mhz *and* he needs to hold the memory to the pixel the entire time (IE, it's one memory read per pixel, 100% duty cycle) because he doesn't have a latch or a shift register. To try to overlay the I/O requests I think the best he could possibly do is add a latch and with some help from the 10mhz crystal source come up with signals to run at an effective 5mhz CPU clock. I don't think the memory devices he's using would handle that.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  7. #7
    Join Date
    May 2019
    Location
    San Diego CA
    Posts
    208

    Default

    It might be a "pathetic" YouTube channel, but i'm subscribed!

    I forgot that was you!

  8. #8
    Join Date
    Feb 2009
    Location
    Southern California, USA
    Posts
    3,129

    Default

    Quote Originally Posted by Eudimorphodon View Post

    I am kind of wondering if I may need to hold the memory to the 6502 for another extra half-tick of the 8mhz source after Phi goes low to make sure the memory read/write is latched when Phi2 goes low?
    The spec from the Rockwell 6502 Hardware Manual has a hold time of 10 nS minimum and 30 nS typical for data after drop of phase 2. The normal delay of chip selects being deselected may take care of this. I've never added special delays, but 60 nS shouldn't hurt.

    That leads to another couple dumb questions: my vague understanding is that most of the 6545's registers are write-only? Will a Commodore EDIT ROM that has 6545 initialization code work in a PET with "hardwired" video (IE, can you pull the ROMs from a "universal-board" 4032 and plug them into a "dynamic-board" model) as long as the "hardwired" video is the correct format, or would the CRTC initialization code have to be yanked out if I tried hacking a ROM from Sgray's source?
    The CRTC initialization code is only run on power up and there should not be a problem is there is no 6545 CRTC installed and hard logic is used for video timing. There are versions of BASIC 4 that run on the older PETs, but I have never checked to see if the CRTC code has been deleted. I assume it has.
    -Dave

  9. #9
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    3,284

    Default

    Quote Originally Posted by TheDrip View Post
    It might be a "pathetic" YouTube channel, but i'm subscribed!
    Heh, thanks.

    I keep meaning to slap together episode II of the video card epic, which will probably be a diversion into using GALs to do **** your microcontroller is too slow to do.

    Part of me realizes that between using MCUs and GALs I might as well go with an FPGA for the whole mess, but I'm enjoying the tinker-toy aspect of being able to stick with breadboard-able parts.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  10. #10
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    3,284

    Default

    Quote Originally Posted by dave_m View Post
    The spec from the Rockwell 6502 Hardware Manual has a hold time of 10 nS minimum and 30 nS typical for data after drop of phase 2. The normal delay of chip selects being deselected may take care of this. I've never added special delays, but 60 nS shouldn't hurt.
    Hm. Well, it's easy enough for me to try it both ways. Since I'm using a GAL as a state machine I can tweak it easily enough with essentially 16mhz resolution. (I can gate against the high/low state of the input clock.) If just the chip select hold time is enough that would be "handy" because in *theory* the way it's set up I might have the option of running the CPU at 2mhz as well as 1mhz. (IE, go low-high twice per pixel output time, with the video system essentially only using a 25% duty cycle instead of 50%.) It might depend on how much delay adds up from having both a fast RAM chip and a Flash chip (character generator) in the output chain in front of the shift register instead of what I have now, which is just the flash. (The MCU adjusts frame starting addresses to cycle through a couple static bitmap plates.) I've connected the output enable/CE of the flash to the Phi clock and a 25/75% low/high is working okay. (If I'm doing the math correctly my current cycle gives me 125 ns between Phi falling and the shift register load signal. My Flash chips are rated for 70ns, I have 55ns, 35ns, and 15ns SRAM I can stick in front of that. I'm hoping the 55ns will work because it's "big" and would easily serve as entirety of system RAM for a pretty fancy 6502 system, the faster chips are 32K.)

    The WDC 65C02 I'm planning to use is rated for 14mhz, so hopefully it'll have a nice fast memory read latch time?

    The CRTC initialization code is only run on power up and there should not be a problem is there is no 6545 CRTC installed and hard logic is used for video timing. There are versions of BASIC 4 that run on the older PETs, but I have never checked to see if the CRTC code has been deleted. I assume it has.
    Yeah, it's kind of confusing. I know there's a special BASIC4 EDIT ROM for using in a "universal board" connected to a 9" PET monitor because it needs different CRTC programming than a 12", but I'm not entirely clear if a "Dynamic" board would care if the code was there or not.

    (Hrm. I guess there *are* a couple ROMs on Zimmers that say:

    edit-4-b.901474-02.bin 2009-08-18 2048
    Screen editor for BASIC 4, business keyboard, no CRTC (40 columns)
    edit-4-n.901447-29.bin 2009-08-18 2048
    Screen editor for BASIC 4, normal keyboard, no CRTC (40 columns)
    But... yeah. My assumption it is just crams the registers and doesn't care if anything's listening... so... I guess I'll find out. Still several eggs that need to hatch before I count that chicken.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

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
  •