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

[Eudimorphodon]

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

http://www.6502.org/users/sjgray/projects/editrom/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.

 

[Ruud]

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.

 

[Eudimorphodon]

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?

 

[Eudimorphodon]

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/Arcana/Visualizing 65xx Timing/Visualizing 65xx CPU Timing.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.)

 

[Jove]

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

 

[Eudimorphodon]

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.

 

[Jove]

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

I forgot that was you!

 

[dave_m]

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

 

[Eudimorphodon]

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.

 

[Eudimorphodon]

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.

 

[dave_m]

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.

Come to think of it, later updates of your PETTEST diagnostics include the CRTC initialization and they have been run on all PETS.

 

[Eudimorphodon]

So my WDC65C02s showed up in the mail. Tomorrow I should receive the *six* cheap breadboards I ordered to daisy-chain together (there was no way this was going to fit on my nice two-strip harness), so unless it's overridden by "real life" priorities I guess I know what my weekend is.

It is interesting that there's actually a 40 column no-CRTC business-keyboard EDIT ROM on the Zimmer's site; I thought both No-CRTC and 40-column were mutually exclusive with business keyboard. If I can cobble together the other parts needed to implement the keyboard interface I *could* potentially borrow a business keyboard for this bizarre mission. (I have a complete basket case of an 8032 in the garage.) Imagine I'd have to deal with de-oxidizing the keyswitches, though...

 

[Eudimorphodon]

Another obscure question about Commodore PET hardware.

Another obscure question about Commodore PET hardware.

I would have started another thread since technically this is a question about another aspect of the PET hardware, but I thought it might be better to keep things together:

I found this description of how the PET I/O area is decoded. According to it the two 6821s and single 6822 "officially" live in the 256 bytes between E800-E8FF (with goofy incomplete decoding that allows multiple chips to be enabled at once if you're not careful), but my vague recollection is that this area is actually incompletely decoded on the early PETs so "shadows" of this area repeat through the whole 2K area?

(The page I'm referencing says "In the board #4 the I/O size has been reduced to this page, allowing for more ROM space in $E900-$EFFF for nationalized keyboard mappings", which implies at least that fully decoding the upper 8 bits of the I/O space *was* a late development in the PET's lifespan?)

For the rotgut "PET Workalike" I'm working on I'm looking for a safe place to put a communication register to pass values to the video processor. (To allow switching between normal PET text and a bitmap graphics mode, etc.) Does anyone know off the top of their head if there's anything in the BASIC 2 ROMs or any common PET software that hits the I/O area at one of the "shadow" copies of the 2K address space instead of the E800-E8FF block?

Also, I guess so far as it goes, the page also says that the base address for the CRTC in the CRTC PETs was E880. How safe would it be to decode the register to something between E880 and E8FF? (IE, fully decode and restrict the 6821s/6822 to their stated E810,E820, and E840 addresses?)

None of this really matters for the basic text-only smoke test, I guess, but I'm trying to think ahead a little.

 

[dave_m]

I think the area at $E800 to E80F is open for additional I/O.

 

[Eudimorphodon]

Hrm.

In a related question, I'm realizing my eyes are starting to glaze over a little trying to understand the interrupt structure of the PET, and which parts *must* be present to get to a minimally functional system. (IE, blinking cursor at a BASIC prompt and able to take keyboard input.)

Using the "2001-N" schematics as a baseline, sheet 3, there's a signal called "VIDEO ON" that's connected to CB1 on PIA C7, and PB5 on VIA C5. In this explanation of the so-called "killer poke" it says:

... The second feature was the vertical retrace input at VIA Port B ($e840, 59456), bit 5. In the kernal's print routine there is a loop that waits for this input to become low. Thus the video memory is only used by the CPU in the off-screen area. Of course it takes a lot of time to wait for the vertical retrace when the electron beam is at the beginning of the screen.

This is where the fast print poke comes in. The poke sets the VIA PB5 to low output. This way the kernal always thinks the electron beam is at the retrace (it always reads the output register value on port B for output pins, not the pin voltage level), and immediately prints to the screen. This is faster, but produces snow on the screen on the old PETs. The vertical retrace signal is generated by the video logic, that is discrete TTL in the old models (without the CRTC chip). It is also used as an interrupt input to generate the system interrupt (CB1, PIA1)...

Trying to parse this it sounds like there are *two* different things that depend on this signal from the video circuitry; it sets a bit on port B on the VIA which is *polled*(?) to figure out if the machine is in the video blanking area for screen writes, and it also generates a 60hz interrupt via the PIO?

So a couple questions (there are probably more that will crop up) that I'm coming away with:

1: Considering I'm intending to (at least try) to use non-contending CPU/Video memory cycle timing would it make sense to just tie bit 5 of VIA B to a pull-down resistor? (IE, effectively give it the same input as it'd have if someone had "killer poke"-ed it?) Or is there a reason it should be tied to the blanking signal? (assuming it actually is just *polled* and doesn't generate an interrupt.)

2: For the system interrupt (and/or the blanking signal if we do need it for #1), is a signal that goes "low" immediately after the last active line on the screen is painted and stays low until the last blank line before the active area starts all that's needed, or does there need to be some kind of resettable flip-flop logic implemented outside of the PIO to cancel the signal when it's acknowledged? (My plan was to use a line on the MCU that's acting as a CTRC to act as this signal.) I *assume* not because otherwise the signal would go away and the VIA wouldn't be able to poll it, but...?

3: It *looks* like this is the case, but for now am I free to ignore/omit the second PIO? It looks like it's pretty much dedicated to the IEEE port.

4: Are there interrupts I need to worry about in the base PET other than the vertical blanking?

 

[dave_m]

1. If intended to to be compatible with BASIC 2, you should ground the input to VIA PB5. If only BASIC 4 used, you can ignore this input.
2. No hardware acknowledge needed, the transition of Vertical Drive/VideoOn pulse is programmed in the PIA to cause an IRQ.
3. If IEEE not used, yes PIA not needed.
4. No, it is the only interrupt used.

 

[Eudimorphodon]

2. No hardware acknowledge needed, the transition of Vertical Drive/VideoOn pulse is programmed in the PIA to cause an IRQ.

Sweet. And just to make sure I'm not being dyslexic, the "Video On" signal should be "low" in the blanking area and "high" during the active lines, correct? (IE, CB1 on PIA1 is edge-triggered on the high->low transition.)

If this is it then this should go together pretty easily. (Famous last words.) I still need to come up with some kind of keyboard to hang off the PIA, but I'll burn that bridge when I come to it.

 

[dave_m]

Yes on blanking signal.

For a cheap keyboard, consider a keyboard from a broken C64. It uses the same connector as the PET. Steve Gray already has an EDIT ROM mapping for it. But if needed in a PET chassis, you will need to lose the RUN/STOP key to get it to fit, and you will need a cable extender (as I remember, a standard 40 pin ribbon cable like an IDE or some-such can be used. You need one row of 20 pins).

 

[Eudimorphodon]

I do have an empty PET chassis (without either a keyboard or working monitor, alas), but for the smoke testing this thing is just going to live on a bunch of breadboards, so I'm not too worried about physically fitting any particular case right now. (Driving a real PET monitor would be a possibility but I'd have to make some changes to separate vertical and horizontal sync, as it is they come out of the MCU as an already combined composite signal that's mixed with the shift register output.)

Unfortunately I don't have any broken C64s around either. I do have a couple 8x8 matrix TRS-80 keyboards that I was wondering if I could build a custom ROM for based on Steve Gray's C64 matrix, but it looks to me like the TRS-80 has fewer keys so it might be a challenge to make it useful. (The diagrams I can find of the C64 keyboard show it effectively fills the full matrix, while the TRS-80 has six dead openings.) I don't really quite understand how shift/modifier keys work in the editor code. (Well, it's probably an understatement to suggest that's all I don't understand.) I'm sure a smart person could use the three F1-F3 keys as enough modifiers to make it work...

I do *also* have a broken 8032, so I could lay hands on a "Business Keyboard", but I'm sure it'll badly need to be cleaned/de-oxidized before it registers keypresses. But I guess that might be the low-hanging-fruit way out for now.

 

[Eudimorphodon]

... on the keyboard question, I just happened across a nice blog snippet about pin change interrupts on the AVR CPU, it has me foolishly optimistic that maybe I could without too much hacking come up with a PS/2 or serial interface that interfaces directly to the PIA. (IE, get rid of the 74145 1-in-10 decoder and just watch the four row output pins directly.) It's nice that the PET scans one keyboard row at a time, it's not the gawdaful memory-mapped grid-mess that the TRS-80 uses. (I've been puzzling over that problem and don't see a good way to solve that which doesn't involve a crosspoint matrix switch.)