Hello everyone!

Attached are the schematics and the design document for the next revision of the Acolyte Computer. The previous version is found here:

viewtopic.php?f=4&t=7388

This version is twice as fast as the previous one, thus also using twice as much Video RAM and providing color. Besides that, nearly all of the same concepts and designs have been retained.

What I did in the design document is try to cover all of the major components and design decisions for this board. It is not *super* extensive, but does include ISR code examples, timing diagrams, glue logic decisions, and I/O operations. While creating the design document, I found a flaw in one particular place in my logic (now corrected), so I am happy to have done the design document at all so that I could see my own mistakes while trying to explain them!

Auto-router is currently optimizing via count, but I do not plan on getting this printed for another week at least. It is better to leave it for a bit and come back later to see if you are still happy with it.

I am posting this here and now because I would like to see if you can spot any particular mistakes or flaws in my plan. Any extra set of eyes is MUCH appreciated.

Thank you everyone, have a wonderful day.

Chad

Hi Chad,

I just want to say that I really like this approach. Your design doc reminds me of the kind of in-depth hardware coverage you used to be able to get for old school systems. (Kind of like those Chilton manuals my dad used to have for our cars that had a technical drawing for every bolt.) One of the things that got me into retrocomputing in the first place is that the old A500 had this kind of manual, but none of my PCs ever did! That sure got frustrating.

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

Just a quick question. Do you really want SO to the CPU to be asserted whenever either SPI_MISO is low or you execute a _B opcode? That could result in the overflow flag being randomly set thus rendering it unusable for its usual purpose. It would seem more useful to assert SO if SPI_MISO is low AND a certain _B opcode is executed - this would allow the CPU to sample the SPI_MISO signal into the V flag but leave it alone otherwise. Also, note that SO is sampled on the rising edge of PHI2, which might complicate things since _B opcode detection happens when PHI2=1.

Haha, thank you, but I don't match up to Chilton in the least!



So, I have never ever used the overflow flag for anything besides... well, this. Like, in all of my coding thus far, which is closing in on year, I have never needed or even thought of using the overflow flag. Heck, I don't even use BIT operation, um, ever. Inefficient? Perhaps.

The idea with the AND gate is that I didn't have any others to spare. It works though, as far as I can tell:

MISO is normally pulled up, as is the /ILLEGAL-XB pin. If MISO stays high during a read, I will CLV, toggle the /ILLEGAL-XB pin, and it will set the V flag. If MISO stays low during a read, I will CLV, toggle /ILLEGAL-XB, and nothing changes.

The illegal opcode circuit for the '138 and '259 came directly from Dr Jefyl's own circuits, so I'm kind of relying on that here. I intend on putting some NOP's after each of these $_3 and $_B just for safety.

Thank you, good question!

Chad

That's fair enough if you are going to write all the code on the system from scratch. But if you want to use anyone else's code they might expect the V flag to do what it normally does. As an example, there's a nifty little binary to ASCII base 10 numeric conversion routine on here somewhere which uses the V flag.

Oh, like that. So, it's tied to the /ILLEGAL-XB pin which is normally high anyways. The only other thing that uses that pin is the VIDEO-MODE flip-flop, which will not be changed very often anyways. I guess I could still use things like that decimal conversion stuff, just as long as you aren't changing the screen from monochrome to 4-color mode every other clock cycle

Still, I think I do see a slight problem in my logic though. PHI2 goes high while BE is still low, meaning it could just get garbage on the '138 potentially flipping bits that should not be flipped. Normally that won't matter for the '259 because it will simply re-latch whatever just a few nanoseconds later. But the /SO pin could change unexpectedly. I'll be thinking about that. Thank you.

Chad

EDIT:

The only data present on the D-databus when BE is low is from the video ROM signals. If I rearrange my pins so that _3 and _B never happen, we are good. Thank you very much for finding that!

Another approach would be to shorten the period during which the '138 is enabled. As shown on the left (below), you presently use only one of the 138's inputs for timing information within the cycle. But you could use two, as shown on the right. For example the extra timing input could perhaps be driven by EIGHTH (although I'm not sure if that's the best choice, as I haven't been properly following the discussion, and am not sure if the waveforms included in the PDF schematic remain unchanged).

Re-purposing that '138 input will reduce the granularity with which you can discern different groups of illegal, single-cycle opcodes -- the LSB will become a don't-care -- but it looks to me as if that'll be acceptable.

By the time both timing inputs become true and the '138 becomes enabled, we need read data to be valid. If the data is still bouncing around there's a threat not only of a temporary glitch on the '259 output we do intend to write to, but also a threat of spurious writes to outputs we don't intend to write to. The former might be tolerable but the latter is not.

-- Jeff

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

Jeff, that is an excellent idea! I will have to check out the LSB stuff, because again I have nevwr used that either.

Perhaps I could use a '377 (edge triggered) instead to ensure that nothing unintended is written. I wouldnt wamt the SPI CLK to accidentally trigger! That would eliminate 4 outputs but perhaps thats worth it in the end?

Im without a computer for almost a week, but will be thinking about this in the meantime. Thank you again Jeff.

Chad

Update:

Over the Thanksgiving Week, I was not able to reach a computer. But I did ponder my design a lot. I think I figured out a new way to have output pins, and reduce chip count while doing it. Instead of using the illegal opcodes, I am now going to simply use a '377 where it is enabled when I'm writing to ROM. Obviously you cannot write to ROM, so instead the databus is diverted to the '377 where it serves as output pins for ROM banking, SPI signals, and audio. Inputs are still through the 6502's interrupt pins and /SO line. Only a small modification there, as I'm using part of the video signals to work with my SPI MISO line, kindof weird but will definitely work.

Even more, I was able to reduce the glue logic down by another chip as well. I lastly removed the monochrome 80-column support because I don't think it is a major component of what I'm trying to do here. Useful, yes, but not necessary. Most of my code for this still only uses 40-columns for BASIC and the monitor. I've had 80-column support on nearly all of my boards, and though I do like it a lot, I rarely use my computers for "productivity software".

Attached are updated schematics and a timing diagram I did in Excel. I'm just using it to verify that my glue logic does what I want it to do. I certainly am using gates in strange ways!

The next step is to verify that I can safely whittle my ROM code down to 16KB. I think it's possible, my BASIC is only 4KB and the monitor is fairly minimal as well.

Thank you everyone!

Chad

Hey everyone!

It... kind of works! Very kind of. Attached are some pictures.

The color pictures are from when I take the CPU out. The tiny white pixels is from when I put the CPU back in. The simulator screenshot is what is expected with the CPU put in. Also attached are schematics.

So, what is going on? Only the very first bit from the 74HC166 shift registers is latching. Or the others are getting cleared immediately afterwards. Or I have just entered looney-land. This seems to be a video-side only issue, because you can see that the CPU is actually DOING what it should be doing. But when it needs to be displayed, it just doesn't quite make it. Thing is, the video circuit in question is identical to ALL other boards I have used in the past, I did not change ANYTHING on that side of things.

I've probed the heck out of this thing, so here are some findings:

1) The Video sync signals from the 74HC377 seem perfect. The monitor says 60 Hz, I checked horizontal and vertical timing and they are incredibly accurate. The signals seem like square waves, I don't see any unexpected dips or weirdness. I replaced that chip as well one time and it worked the same.

2) The VISIBLE pin from the '377 is likewise working as expected. It turns off the color when it's overscanning the screen. That pin is a constant high while latching these data bits and when displaying. I have found no issues with it at all. Likewise, the speed at which the VISIBLE pin is latched onto the '377 would mean eight pixels would be on or off, not just a signal pixel.

3) The /LATCH signal timing is right on. Obviously the '377 is being latched at the same time as the '166s, and it is doing great. I once changed the logic of it's /BE pin to /PHI2 and it did exactly the same thing.

4) When I probe the /LATCH line *twice* the shift registers just stop working entirely. Yet the '377 keeps going. When I tap on the /LATCH line with *one* probe, the vertical lines just ever so slightly change. I traded out a '166 with another one from a working board and there was no change. I've taken out one shift register so only one is on at a time and no change. I'm guessing that two probes cause more capacitance or something? The probes would both show that signal, and it's strong and identical, but the shift registers don't like it at all.

5) I tried putting a small resistor in-line between the /LATCH signal and the '166s pin 15, and it only got worse though still similar. I also tried to bypass my transistors but there was still no change. The output signal from the '166 is just one pixel wide and then goes to ground every time.

6) I checked /CLK and it seems fine and opposite of CLK.

7) Again, I see the 6502 has cleared video memory and put in it's own memory. To display text characters means basically everything there is working fine: reset, stack, RAM, ROM, addressing, etc. And the right signals are reaching the '166 as well, all of the data pins show activity while /LATCH goes low, nothing is floating. And the '377 with the exact same /LATCH and /CLK signals is working fine. So, what am I missing?

8.) All chips are in the right sockets. I even tried to replace the 74HC10 and the 74HC161 and it does the same thing as well.

9) EDIT: I also have connected random datalines and clock signals and /LATCH directly to the VGA output, and I get color bars as expected. So the monitor is also working as expected.

Summary:

Both '166s are acting identical, and replacement chips do the same thing. There is no occasional noise in between the bars, it's just black. CPU is not acting strangely. The only other chip using the same /LATCH and /CLK signals is a '377 and it is working very much as expected.

Because the lack of noise, I figure it is a logic issue. But I have checked again and again and cannot find the issue! I have checked the board for any loose connections or soldering mistakes, but I cannot find any. It is just such a consistent error!

ANY suggestions are welcome. The board works, except for the video circuit.

Thank you for you time.

Chad

EDIT: Still not working "properly", but when I replace /CLK with CLK on the shift registers, it seems to work as expected. But, logically that doesn't make sense to me. I feel like it's a bandaid patch. Could it be a /CLK signal timing issue? Like, too many propagation delays or something? When I replace the /CLK on the '377 with CLK, it still works as expected as well, so maybe the '377 is just more lenient with it's latching stuff, while the '166 is very tight? Thoughts? (Picture attached)

What happens if you tie the '166 serial input to VCC instead of ground? That might help narrow down the problem.

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

Ah good idea! I just did that, no change though.

I actually broke off the leg for the /MR pin on one of them just now, oops! But it still outputs, hm.

I got my keyboard working with the funky interrupt stuff. I'll clean that up later but I'm glad that works.

So! I technically have this computer working, yay! Except I just don't understand why I need to use CLK instead of /CLK.

Regardless, I'll be making patches of this soon, and then giving a full update with code and all that eventually.

Thank you.

Chad

I was thinking you could send a whole screen of spaces, with the serial input tied high, and see if you get any "1"s. If you did, that would mean it was shifting, but the parallel load was off somehow. Also you could try sending a whole screen of "blocks" (0xFF bytes). If you saw any spaces it would show you where the control signals were off. And so on. The "nice" thing about video circuits is that when something goes wrong you can see it going wrong over and over again!

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

Seem like you are making great progress. So it is working now with shift reg ('166) clock at CLK instead of /CLK? Seems to me there are long prop delay from clocking of '590 to valid address outputs to RAM putting out valid data to be latched by '166, so changing phase of CLK may catch the data "in flight" better.

Raise the voltage makes parts run faster; raise temperature makes TTL run faster but slow down CMOS; probing with a steel needle slow down signal with your body capacitance; so use combination of these facts to find the critical path.
Bill

Thank you both. Yes, a black screen showing a color tick would indicate that something is not right! I will have to check that later.

Bill, I will probably try to use the soldering iron and the freezer to check if things change. I don't have any other fancy tools Good ideas though.

So, I was thinking, if you remember:

viewtopic.php?f=4&t=7154

With my last revision I had a flicker problem, but it would go away if I heated up the '161 clock divider. Then I swapped the '161 out with another and it seemed to work. A small update on that: Since winter is/was here, the board got cold and sure enough, the flicker came back ever so slightly. Hm! So that first '161 (the canary, as it was called) just had different margins I guess. It was either faster or slower, ever so much, that it caused the flicker. And then this newer one didn't flicker AS MUCH, but it still did in the end.

What if the timing on those shift registers was the real problem the whole time?! What if I had my /CLK hooked up to them and I should have had CLK instead? Then that original '161 might not have flickered at all! It was never the '161s fault, it was the shift register's fault. Just a hypothesis. Basically: Maybe my logic on using /CLK was wrong for the past 6 revisions, but it wasn't showing up much until I tightened my glue logic a lot. Hm.

I'll have to test that sometime, it wouldn't be hard to just bend a pin on the old computer and check.

Another thing I remember seeing last night when I was probing this board: My '377 still ran smoothly with /CLK, but when it was first getting those signals online, it had a weird semi-dip around the 2.5V range, just for a few nanoseconds. Not as clean a square wave as I wanted, but it was working so I ignored it. Perhaps that was an indicator as well, that I should have been using CLK and not /CLK the entire time. More hm.

Anyways, will do more testing later. Thank you all.

Chad