You are a brave soul! I personally have gone down that breadboard road before, a few times, and I was highly disappointed in the breadboard itself. I know folks keep saying, "You just need to get a good breadboard", but I'm not sold. When you said you had a good signal for some seconds, and then it crashed, that could be a lot of things. You say adding bypass capacitors make the signal worse? It could be a breadboard thing!

I remember spending hours making an EEPROM programmer that would interface with my Raspberry Pi. It worked, but when I changed over to a new breadboard, it didn't work. Why? The breadboard! It "worked" only when I jiggled the wires around, ah! I was upset and my wife just came into the room and asked me how things were going. I looked at her, showed her my mess o' wires, and said, "This thing doesn't work!" and tossed the whole thing over my shoulder. Is it still sitting behind the couch to this day? Who knows

Twisted wires might be fine, but if your base of operations (your breadboard) is the trouble, anything you do on top of it might or might not work. Or it might work today but not tomorrow. Just a personal warning, that's all. I'm sure I'll catch flack for my comments. If you are sure sure sure your breadboards are not causing any problems, then proceed on!

Anyways, it's always good to start fresh. If you are set on the boardboards, then what you are doing is definitely the best course of action. Thanks for the update! Learning is happening!

Chad

Merry Christmas, 6502 world! Here's a bit of Christmas Whisky and Wiring:



Is it a good idea to mix these two things? Well, at least today it did no harm!





The project got *more simple* as I worked today. I kept going "wait, I'm not using that one for anything now, it came come back off!" The grand total, in terms of chip count, ended up being 9 ICs, a few ROMs, and a full-can oscillator. Here's where I landed:



I always start out tidy, but when I get into the thick of testing things I don't seem to be able to escape from the flying leads! O well. I did have to move the bypass caps back to the power rails. They were just getting in my way too much, and sometimes shorting out against IC leads. (Plus, they wouldn't fit over the ROMs or socketed ICs.) Still, it runs VERY stable now - I can poke it and prod it and jiggle the wires all I want and it doesn't react. Whee!

It's basically finished, in the sense that this is as far as I thought it out before I started building. The "framebuffer" EEPROM can be pretty trivially replaced with some RAM (the fast SRAM I have has an almost identical pinout). There are some immediate options for expansion. If you see that long green jumper wire going from the character ROM over to the left hand side of the top breadboard, that's the A14 line. Right now I just have two character sets in the ROM, and I can switch between them by manually moving that wire. But the ROM is 32k, so it can hold many character sets. I believe there are 3 address lines free for character set selection, so it could have up to 8. There are also some free frame-buffer address lines (3 there, as well), so I could maybe do some triple buffering.

I wonder how hard it would be to add some real terminal features, like a hardware cursor, to this. I think the next step is to sit down with a big pad and draw the schematic so that I don't lose the design if something bad happens to the breadboard!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Here is a schematic. I used AdobeScan on my phone, so it's a bit faint in places. I hope you can read it (and that I didn't miss any signals)!

Edit: And here are the timing and character generator ROMs.

Edit #2: BIN, ROM, and IMG are not allowed, but also NO EXTENSION AT ALL is not allowed? Seriously, WTF. I know how to rename a file, just tell me what extensions ARE allowed.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Aha! Good idea.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Wow, thanks for the schematic. And great job on the video output, it looks really good! Congrats!

And yes, whiskey does go well with... everything

So! Questions about the schematic:

I see the top-right corner you have some '590s spitting out A0 to A# (it got cut off, but it's a higher number). It seems those are going out. So that's output to the ROM and eventually RAM?

If those A's in the top-right corner are going to the ROM right now, and you want to replace it with RAM (so that you can make it useful of course), how will they share the address lines? You would have to bring data into it somehow? I make good use of those /G lines on those 590's myself!

The Q0 to Q7 are those possible character sets right? You can set them to 00000000 and get one set, and then 00000001 to get another set, etc?

At about the middle-right you have some other 590's that are spitting out A0 to A14. Yet all 590's I see have /G grounded. So are those different address lines? One is for the timing ROM, another is for whatever is going outside (to the ROM/RAM)? So, different A's? Is there a way for you to combine those together?

I really like your use of the 590's, the 166, the 161, and the "timing" ROM. That is basically identical to what I'm doing. Didn't you start with something like what George (gfoot) uses? Me too, BTW

Well, it seems you got the characters to display really well, AND the breadboard isn't giving you issues. So, good job, glad that's working! Thanks for the great update!

Chad

Hi Chad,



Thank you!



You get right to the heart of the matter! I was just pondering that very thing. In the top right I kind of sketched out an abstract zone for "frame buffer." Right now it's just a ROM, but eventually RAM, as you suggest. The cutoff part is A11. The low order 590 (7 bits) is what character we're on; the high order 590 (5 bits) is what row. So, the current character is a 12 bit address. This wastes some RAM, but made things a lot simpler. (I got the idea from Gerry Kane, so it's suitably retro. )

As for how to interface... well... I'm not sure yet. Some options I'm considering (but there might be more I don't know of yet):

* Ignore it. Just give the CPU access to RAM willy nilly and live with some garbled output during video writes (this is oldschool, but I probably won't do it, because I don't like garbled video, and it's not a very fun way to solve the problem.)

* Dual port VRAM. This is what I'd like to do, but unless I can find some dual port ram that costs less than $13 per kilobyte (!) I probably won't go this route either. I've been reading some old threads where Dr. Jeffyl suggests you can roll your own "dual port RAM" using FIFOs and some logic, but that it's more complicated. This might not be so bad; I bet I would learn a lot from figuring out how to do that.

* Clock phase juggling. CLK_P is the master pixel clock of 25.175MHz. The output shift register needs to read from the character ROM once every 8 of those (so, roughly π MHz). The LOAD_P pulse that triggers the shift register loading is active LOW; when it goes HIGH, it clocks the lower order 590 to move on to the next charter. The 590s then just sit there for the next 7 pixels asserting the address of the current character. As long as we move in and out fast enough for the character ROM's outputs to settle before the next load, we should be able to write to the RAM here without disturbing anything. I think a 6502 at CLK_P2 (roughly 12.6MHz) should be able to do that, with a little clever gating. Could be tricky though. I will probably try this first, because I can do it with parts on hand.



Q0 - Q7 is the output of the frame buffer ROM/RAM. All of the ROM data sheets call them Q (I guess because outputs are Q) but I think of them as D0 - D7. The two 590s input the 12 bit X,Y address of the current screen location, and whatever byte is stored in the frame buffer that location comes out on its Q0 - Q7. Those are fed into the ADDRESS lines of the character generator ROM, along with a 4 bit scan line code, which causes the character generator ROM to emit pixel data on its own Q0 - Q7 lines. IOW, the character generator ROM gets an ASCII code (8 bit extended in this case) and a scan line code (4 bits), and those 12 bits address one byte of pixels; hence, characters are 8 pixels wide and 16 pixels tall, because I am lazy about computer math and like to do things in bytes. So, in case this is confusing (I'm finding it remarkably tricky to describe this in natural language), we have two different 12 bit addresses: one is a 5 by 7 bit address into the frame buffer that causes it to emit a byte of data. We will interpret that byte of data as an ASCII code, which is used as part of 12 bit address number two, which is an 8 by 4 bit address into the character rom that gets us one 8 pixel wide line of pixels out of the 16 lines of pixels we need to draw a whole character!

You can switch character sets by decoding A12, 13, and 14 on the character generator ROM, but right now I only have 2 character sets in there, so I'm just using a jumper wire on A12 to switch between them. (That is the meaning of the crudely drawn switch in that area of the schematic.)



That's correct! The two 590s on the left are driving the timing ROM, the two on the right are scanning the frame buffer; separate address buses. The two timing ROM 590s are chained together to make a 15 bit counter, just like George's. The two on the right are clocked separately; one is for the row (i.e., the text row, 0 - 29) and the other is for the column (i.e., which specific character we're on, 0 - 79). George had everything come out of his ROM, including color data, since he was going for pixel-based graphics. Since I want a text terminal I got rid of all that and used two bits to create the HBLANK\ and VBLANK\ signals. I still have 3 unused bits coming off the timing ROM, but I haven't thought of anything interesting to do with them. The timing pulses are two characters (16 pixels) long, so they're two slow for any kind of character related data.



Thanks for taking such an interest in my project! The breadboards are behaving pretty well. A few twisted ground return wires for the longer signals helped a LOT. I did have a few breadboard related glitches to track down - a loose connection on one of the the column counter address lines was causing some ghostly intermittent repeats, but it seems rock solid now.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Ah yes, this is the hardest part, in my opinion. I made a whole topic on this very thing way back in the day:

viewtopic.php?f=4&t=6957

I went with your option 3, but my 6502 is running at "pi" MHz, not 12!



Ah! Now that makes sense, thank you for that clarification. I like that, data lines going into the address lines.



I'm interested because you are going down the same road I am going down. Or went down. And I'm learning as well Thank you!

Chad

Paganini, your report echoes what Adrian said in this post:
Potentially crappy connections, and the challenge of ground distribution, are the two Achilles' heels of solderless breadboards.

At least ground distribution is something you can take measures to deal with. And that's something worth knowing and talking about. For example, as you know, the added ground return wires need to be grounded at both ends. And clock lines are typically the ones that most urgently need this ground return attention.

But it's not really possible to correct the effects of a low quality breadboard. If you haven't purchased a good one, your only choice is to trust your luck, and hope the suffering is minimal (ie, doesn't sabotage your enthusiasm for the project).

ETA: Radical Brad recommends the breadboards from Twin Industries.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Well, maybe I will try that first and work my way up. Thanks for the link! I was just reading your thread about dual port RAM, but hadn't yet come across the one you just posted.



Yes; for the long twisted pair wires I tried to ground the return wires *at the chip ground pins,* rather than at some random point on the ground rail. That way I had a ground wire running, e.g., from the ground pin of the oscillator to the ground pin of the counter it was driving, 6 - 8 inches away, twisted around the clock signal wire.

I read your posts in the thread you linked (along with the posts *they* link to) quite a few times when I was working on my "I/O board" and having trouble getting ungarbled signals from my PS/2 keyboard. Your comments about return current, along with the annotated photos were *extremely* helpful!

It's interesting to watch the scope while working with things powered up; adding / removing / rearranging the bypass capacitors makes almost no difference, but there are places where if even *one* of the ground return leads comes undone, the scope goes haywire and there are visible glitches on the VGA monitor.

Since you're here, I have a question about "best" practice for bypass caps on breadboards. Due to the length of the leads, it's not always possible to get a bypass cap across VCC and GND by the shortest path - if the chip is in a socket, for example (it's too tall), or if it's a larger chip like a DIP40 MPU or a DIP28 ROM. In those cases I can get a bypass cap very close to ONE of VCC or GND. In those cases, would it make sense to use two bypass caps per chip, one very close to VCC and the other very close to GND? Like this:



(I know I just said that bypass caps don't seem to make a lot of difference on breadboards, but I want to get the best results I can, even if that means small gains from little details.)



A brief excursion into my breadboard experiences:

My first breadboard came with one of those ELEGOO electronics kits from Amazon (basically designed for introductory Arduino experiments). It was pretty terrible. I think I threw it out. I got a couple of Jameco "Valuepro" breadboards because they're supposed to be very well built. I don't like them either; it's true the connections are sturdy, but the little jaws are SO stiff my jumper wires will bend and telescope rather than go in! The ones I'm using right now are "BusBoard Prototype Systems," the same as Ben Eater uses. They seem like a good middle road between quality and price (they're about $8 for an 830 tie point one). I really like the the look of the ones Radical Brad uses (and I think they're the same ones that the Debug Innovations guy uses), but I wasn't aware of them at the time. These Bus Board ones are working fine for now, but I will probably get some of those Twin ones eventually. I did peel all the sticky backing off the Bus Board ones so that I can get at the little clips and replace the ones that get bent or lose their pinching power.

Edit: I just took a quick look at Vulcan 74 again, and they're not quite the same breadboards. I think the Debug Innovations guy is using these high temperature ones: https://www.digikey.com/en/products/detail/twin-industries/TW-E40-1020-P/3946270

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Welp, I did a little waveform drawing this evening, and tried attaching G\ of the frame buffer scanner '590s to CLK_8. Looks like πMhz is going to be the way to go for no fuss interleaved access to video RAM. I can use CLK_8 both as phi2 and as the G\ (OE\) signal to the `590s that scan the frame buffer. I will have to do a little decoding glue logic to get Blue April to talk to the video RAM (and also, I will have to install the video RAM!), so I will try that tomorrow or so. As a more long term plan, though, I am thinking that I have some CMD 65c02s that run at 4Mhz. I could use one of those as the "GPU" and have Blue April communicate over RS232 (or maybe even SPI), leaving her free to operate at a higher clock frequency.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

I did order some dual-port RAM; but it will take a while for it to get here. Also, it is a bit like solving the problem with money, rather than with brains. So in the meantime, I'm taking the opportunity to try and understand interleaved access using Ø1. There is surprisingly little information about how to do this to be found, beyond the general observation that many old designs took this approach, and the general observation that "the 6502 stays off the bus during Ø1." I don't quite see how this is true. It appears to me that the 6502 uses the address bus for the entire cycle, setting up the control signals (including the address) near the beginning of Ø1, and holding them all the way until the end of Ø2. I can see that, if you are fast enough, you could disconnect the 6502 from the address bus, complete a transaction, and reconnect the 6052 in time for it to finish what it was doing; but that seems a lot more complicated than just hooking an inverted clock signal up to a clock pin (or, in my case, gating RAM access with an inverted clock signal).

Here is a little timing diagram I made. My video circuit timings are at the top: a 25.175 Mhz signal, and a LOAD_P pulse. LOAD_P is generated by inverting the terminal count of a `163 that counts 8..F. The `166 shift register gets the next byte of pixel data from the character rom on the falling edge of LOAD_P; the `590 x/y address counters increment on the rising edge of LOAD_P. Below that is a timing diagram for a 6502 READ cycle, which I copied and slightly simplified from one of my books. Am I making a mistake somewhere?

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

That is exactly where I have my '166 loaded as well, at the end of PHI2-low.

The 6502 is ON the data and address buses while PHI2 is low. But it is not required for it to be on that bus, thus you can use the BE pin or some '245s. The problem with the BE pin is that if you attach it directly to PHI2, it will take the signals OFF the bus at the start of PHI2-low. But the 6502 reads in data on the falling edge of PHI2, so you could have some glitches there. What I do is extend the BE high period through PHI2-high part of the way into PHI2-low.

If you do it this way, make sure you qualify your RAM to the second half of PHI2 high. That was a big problem I had with some previous boards.

Also, if your master 25.175 MHz clock is directly connected to the '166 clock pin, good. If you are using the inverted signal, I found that I get glitches. THAT was an issue I had for many past boards and didn't even know it until I just tried it one day.

You are taking the very same journey I did, and still am on

Chad

Hahah, that's great Chad! That means you can give me hints when I get stuck!

I had a kind of discouraging day over the weekend: I rebuilt the circuit from the schematic, both to check the schematic for errors (I only found one!) and to tidy up the breadboard, make some wires shorter and so on. The previous messier version actually seemed slightly more robust - the new tidier version has a noisier ground. I get some purple vertical bars if I plug the LCD's ground line in some places, but not in other places. But, that wasn't the really frustrating part; the video looked good on my IBM monitor I've been using for test; and I could navigate the frame-buffer as expected (I made a new ROM that puts a 'V' in each of the four corners and uses some of the semigraphics characters to draw a box in the middle.) But then I plugged it into my larger and newer ASUS monitor; it doesn't like my signal AT ALL. It's drawing a bunch of extra Vs during the blanking period, there's a lot of vertical glitching. I've had to travel back to IL for a funeral, so I won't get to work on it this week, but it is frustrating. I guess maybe my IBM monitor is more forgiving than the other one, and my signals are not as good as I thought they were.



OK, that makes sense. The chip I was thinking of using for this project has the Rockwell extensions, but not the WDC ones, so no BE pin. I think that means I will need some buffers to isolate the RAM from the CPU so that the 590s can drive it during Ø2 LOW. I do have a drawer of buffers, so that shouldn't be too hard (I hope!)



Yes, the '166 and the '163 that produces its load pulse are both clocked directly by the full can oscillator. I think that part of the design is good! In addition (in concept, since I'm still just drawing pictures and haven't hooked a 6502 up to this yet) the same '163 that generates the load pulse will also generate Ø2, so they should never get out of phase.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

While reading about bus timing and address decoding this week I came across a set of articles called "Nuts & Volts" in a short lived ATARI spinoff magazine called COMPUTE II that was devoted to SBCs. I really like them! I poked around the forums a bit with google, and it doesn't look like they've been referenced previously, so I will put links to them here. They don't seem like quite the right type of thing for the "data books" thread, or for the "logic design recommendations" thread.

https://www.atarimagazines.com/computei ... /page9.php
https://www.atarimagazines.com/computei ... page17.php
https://www.atarimagazines.com/computei ... page15.php

They are, of course, old, and so the author is only talking about 1 / 2 MHz NMOS processors with TTL / LS logic. Still, I think they are very clearly written, and I wonder what happened to the author. It seems like his book about microcomputer design and maintenance mentioned in the first column sadly never materialized.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad