New Acolyte using CPLD

[sburrow]

Hey everyone!

Welcome to the New Acolyte! It uses the Xilinx XC9572XL CPLD to reduce the chip count considerably. Here are some specs:

- 65C02 running at 6.29 MHz, double the speed of the original Acolyte.
- It currently has 64KB of RAM available and 32KB of ROM (using banking), but if I made a couple of bodges I can get up to nearly 96KB of RAM.
- Fits on a 4"x4" board comfortably. This allowed me to use a 4-layer board at a very reduced cost. That's why I like JLCPCB.
- PS/2 Keyboard, Genesis Controller port, 2-Voice square wave audio, and SD Card support.
- And most importantly, VGA display in 16 colors! If you write to ROM, the CPLD picks that up as screen configuration data. I have two modes: 256x240 16-colors and 512x240 4-colors. The 4-color mode is text mode basically, and you can even choose what other two colors you want, besides black and white.

The main idea of this board is to have the CPLD do nearly all of the logic and video signals. The biggest limitation with my particular QFP-44 CPLD chip is that it doesn't have as many pins as I wanted. To get around this, I attached a 74HCT574 to the CPLD address lines to capture the lower addresses. Then the CPLD switches those same lines to the high addresses. In a way, I saved 7 pins by adding that one chip, which gave me ability to combine all the rest of the glue logic into the CPLD.

The intention for this board is to create video games on it, primarily. I want to use it as a standard base for all of my Math Appreciation Day games. I already converted Tetris from my previous board onto this one. I hope to get a Tiny BASIC on here too, but that's not my main goal right now.

I still have to code for the Genesis Controller, and I need to try out the audio capabilities. Overall though, I am very impressed that I could double my speed, quadruple my color count, and yet reduce it's size considerably.

Attached are pictures, schematics, and my Verilog file. More to come soon. Again, I could not have gotten to this level without y'all's help and encouragement. So, really, thank you

Chad

[gfoot]

Nicely done, it looks like it's working really well!

It's interesting that you have two different colour depths supported, I'd be interested to hear how you did that. The BBC Micro did it in quite a clever way, arranging this so that it just had to shift the output shift register at a different rate and everything else was handled by software.

So in a 16 colour mode, two pixels would be encoded into one byte with their bits interleaved, and the output circuit read bits 7, 5, 3, and 1, passing those as a 4-bit number through the palette lookup. When that byte is shifted to the left, the original bits 6, 4, 2, and 0 move into the positions that are fed into the palette lookup, and the second pixel is displayed.

In a 4 colour mode, four pixels were encoded, again with bits interleaved. The output circuit still read bits 7, 5, 3, and 1, and passed them through the palette lookup. Now bits 7 and 3 are from the first pixel to be output, but bits 5 and 1 are from the third pixel! To avoid the third pixel affecting the colour of the first, you just set the palette the same for all four possibilities for bits 5 and 1, then you get the same effect and the colour of the first pixel won't be affected by the bits for the third pixel.

What that meant overall was that everything after the shift register remained the same in different display modes - the only change required was to shift the shift register at a slower speed and set the palette in a different way. Very clever, I thought. It was all done in a ULA so no schematics are available, and the main blocker to doing this with discrete parts, I think, is lack of availability of shift registers that support parallel load and also parallel output. I've considered chaining two together and reading a byte in advance, it may be a good way.

[Paganini]

Your surface mount soldering deserves its own separate wow!

[plasmo]

Great job! CPLD opens many doors.

Considering how expensive 65C22 is, you may consider eliminating it and replace with CPLD.

You can probably double, triple, or quadruple 65c02 clock now you have CPLD.

Now you’ve figured out how to solder SMT, you can try higher pins, more macrocell CPLD. It is possible to shop around and find a good, cheap source once in a long while. That was how I bought many hundreds of EPM7128S and EPM7064s from eBay cheaply.
Bill

[sburrow]

gfoot wrote:

Nicely done, it looks like it's working really well!

It's interesting that you have two different colour depths supported, I'd be interested to hear how you did that. The BBC Micro did it in quite a clever way, arranging this so that it just had to shift the output shift register at a different rate and everything else was handled by software.

Interesting stuff about the BBC, I didn't know that, but it makes sense. That's neat! And same with you, I couldn't find any parallel in/out shift registers, it's tough sometimes.

Because the CPLD is grabbing the RAM color data on PHI2-low, and it itself is outputting the RGBI colors directly from the CPLD, all I did was tell the CPLD to alter those colors to whatever configuration I want. It really is always in 512x240x4 mode, but I just say "go slower when shifting out the colors" to make it look like 256x240x16 mode.

Paganini wrote:

Your surface mount soldering deserves its own separate wow!

Yep, "Wow, it's bad", right? Gosh, those SMD resistors and capacitors were not made with hand soldering in mind And I either had the iron too hot or cold or something, or applied too much solder, because it would bead up and stay super round and often I didn't think it was actually attached to the pad properly.

For that CPLD, I posted it about it here:

viewtopic.php?f=1&t=7629&start=30#p101886

The SOIC parts are super easy, but I get bridges all over the place. I just crank up the iron and use solderwick liberally, makes it looks much better! What was upsetting to me this time was that the SOIC-20W pads on KiCad did not match up to my 74HCT574! I mean, those pads were WIDE, and the chip just *barely* managed to touch both sides at once. Ugh. I thought I had measured from the datasheet! Oh well, it worked, but when I make another batch of boards I won't be making that mistake again.

plasmo wrote:

Great job! CPLD opens many doors.

Thank you, and yes it does. One "bad" thing I have noticed though is that I'm lazy with my logic because I know I can fix it in software later. One stupid thing I did with my CPLD code was have the RAM and ROM both active at the same time. Duh!

plasmo wrote:

Considering how expensive 65C22 is, you may consider eliminating it and replace with CPLD.

True. I actually haven't used the 6522 on the Acolyte boards for a while, so this was actually different for me.

plasmo wrote:

You can probably double, triple, or quadruple 65c02 clock now you have CPLD.

One day at a time, haha

Thank y'all for the replies

Chad

[sburrow]

Can you spot the changes?

First, I have to say that I had the most utter feeling of failure last night. The board was definitely having a direct short somewhere, especially when I flexed it in the wrong direction. After a lot of time and effort, it turns out that the power switch was rubbing on a bypass solder-jumper I had on the top of the board, and causing a direct short when I would flex the board. Oops! I just ripped out the switch and soldered the bypass jumper for now. That was a long time of searching and reflowing every joint on the board!

Second, I've added some pull-up and pull-down resistors. Without them on the ROM banking pins, it would stay in the wrong ROM bank even when reset. I also added a lot of pull-ups to the gamepad port, and a small bodge wire connecting V-SYNC to /NMI. This allowed me to 'poll' the gamepad much easier. [ It's working with Tetris by the way, that was 3 days worth of software work unfortunately... ]

Third, the VIA's shift register in free-run mode only uses the lower byte of the T2 timer! That threw my two-channel sound plans off entirely, so I'm back to one-channel square wave audio. It sounds good though, and is super easy to use and doesn't need to be babysat because the VIA T1 timer takes care of it all for me.

Fourth, I created a version of BASIC(ish) for this computer. It is only 3KB in size, uses 16-bit signed integer math, and has some cool functions to make it fairly easy to use. I know it's not the best, but it's good enough for now.

I put all of my important files on Github (here https://github.com/stevenchadburrow/NewAcolyte). These don't include my bodges, but that'll be soon to come.

Thanks everyone! What a journey!

Chad

[fachat]

Congratulations, well done!

[Michael]

It's too bad there's not a <WOW!> button on this forum (grin)... It's beautiful, even with the bodge wires.

[sburrow]

Thank you guys.

A small but important update: I just got the PS/2 mouse working! That was a multi-day adventure for sure.

First off, let me link to some VERY good resources:

https://en.wikipedia.org/wiki/PS/2_port
http://www-ug.eecg.toronto.edu/msl/nios ... otocol.htm
http://www-ug.eecg.utoronto.ca/desl/nio ... otocol.htm

If you are familiar with PS/2 Keyboards, this is both similar yet different. The Keyboard does *not* need for you to send anything back, you can simply just receive at default settings. The Mouse *must* have you enable it by sending a proper code. What I did was put my keyboard CLK/DAT on CA1/PA7, but the mouse CLK/DAT on CA2/PA6. CA2 is capable of being an output pin, which is critical for the mouse. I put all signals on my single PS/2 Mini-DIN-6 port, but then used a splitter [ not all 'splitters' you find on the internet actually split the signals! ].

The procedure for sending codes is on the second link, and which codes to send are on the third link. You must follow it *exactly*! I had been thinking, "don't I need to send a start and stop bit?" Well, kindof, not really. During the process of holding the clock low, or releasing the data line, it kind of does that start/stop stuff for you.

You should receive AA, 00, then you send F4, and then you receive FA. After that, whenever you move or click, it sends 3 bytes at a time: buttons, move X, and move Y. Sounds pretty easy, but here's the problem now: because the mouse is supposed to be sensitive, and any tiny movement is a whole new set of 3 bytes, so while in normal use you get a ton of data. For the keyboard, even if you mash keys or hold keys down, you really can't get more than a handful of letters per second. Yet this mouse will give you WAY more than that, and most of it is "I moved 1 unit left, here's 3 bytes!"

Typically I set up an array/buffer for the incoming keyboard keys, which is a fairly easy setup. That was NOT working for the mouse, very impractical. So instead I retained only the current X and Y coordinates and simply added any incoming movements. After a lot of adjustments, it all finally worked, and now I can draw ugly pictures

My plans are to use the mouse for another video game, soon to come! And with that, every hardware aspect of the computer is working and also being currently used. Still plenty of software left to code.

Thanks everyone!

Chad

[sburrow]

Updates!

I just finished two more games. One is a port of "Space Invaders" from my Old Acolyte, which only took about 6 hours to finish today. But what took the most time these past weeks was my new game: "Missile Command"! I wanted to show off the PS/2 Mouse capabilities in a game, and it surely shines here. In fact, it's almost game-breaking-ly good, as it is infinitely easier to use over the keyboard and gamepad in this application. All of my games can use the Genesis gamepad and the keyboard, but only Missile Command uses the mouse.

With these games, BASIC, the monitor, SD card functions, and other stuff I literally used all but 32 bytes of my 16KB ROM area. Whatever is left will be used to jump to the other ROM bank for my 4th game. Unfortunately, I chose games that didn't require a lot of colors, so I haven't *really* been able to show off the capabilities of the 16-color video output yet. Simple slideshows aren't enough. I hope to do so with this next game!

EDIT: I added those green bars on the sides of the screen through the CPLD. It kindof differentiates the actual screen memory from what is left unused. For some reason I cannot make it dark grey because the CPLD is complaining about too many equations on a single pin. Oh well, green bars work fine for now.

Thanks everyone

Chad

[gfoot]

Nice! I like the buildings!

If you have a spare pin or macrocell you might be able to use it for a sub-expression of the one that's too complex, at the cost of a little extra propagation delay. Or does the fitter do that for you?

[sburrow]

gfoot wrote:

Nice! I like the buildings!

Thank you, but they don't collapse or blow up. Didn't have enough memory for cool stuff like that.

Quote:

If you have a spare pin or macrocell you might be able to use it for a sub-expression of the one that's too complex, at the cost of a little extra propagation delay. Or does the fitter do that for you?

I... don't know what that means I tried adjusting the "strategies" in Xilinx ISE 14.7, but to no avail. I was able to tie my high- red/green/blue lines in though, so though I cannot make dark grey on the borders, I can make light grey! So, that's good enough for now I suppose. Thank you for the encouragement George, it looks better this way.

Chad

[plasmo]

Sometimes the logic expression is too complex to fit one macrocell, so it may be helpful to break the expression into intermediate value that drives an output or a macrocell, then use the output of that macrocell to drive the remaining expression. An example:
y=x*x+(a+b+c)*z may be break down to

w=(a+b+c)*z
y=x*x+w

In Quartus schematic there is LCELL symbol that can be placed at (a+b+c)*z to combine that sub-expression into a macrocell and then use the output of that macrocell to drive the remaining equation. This approach adds a macrocell delay but simplify the logic so fitter can work. I don't know enough about Xilinx tool and its implementation of Verilog to tell you how to do it in Xilinx.
Bill

[sburrow]

plasmo wrote:

y=x*x+(a+b+c)*z may be break down to
w=(a+b+c)*z
y=x*x+w

Ah ok, I see now, thank you for the clarification Bill. So, I tried a few things like that, making new 'reg's and combining equations and whatnot. But that didn't work it seems. I think ISE is doing a lot of "optimization" and I don't think I have much control over it. If anyone else uses Xilinx ISE 14.7 and knows better, please let me know!

Then I had another idea: Instead of combining logic, what if I removed it? I had these border functions pretty deep and multiple instances of them. So I pulled them outside and gave them a more global assignment. And boom it worked! I now can have my dark grey borders

As always, my code and other relevant stuff is on my github: https://github.com/stevenchadburrow/NewAcolyte

Thank you George and Bill, I'm really happy with the new border!

Chad

[Paganini]

That looks like a pretty convincing Missile Command. I remember playing the ATARI Version in the '80s. Nice work Chad!