Acolyte Revision - Schematics and Documents

[fachat]

Try drawing a timing diagram, and include all the chip timing delays including margins. Start with the clock, draw the first derived signals, then measure them to see if that worked. Continue 'downstream' until you find the problem.

[sburrow]

sburrow wrote:

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.

Update:

Indeed! Thank you Jeff [ EDIT: it was Bill (plasmo), thank you Bill! But still thank you Jeff too! ] for telling me to save my "canary" 74HC161 many months ago! I pulled it out of the parts collection, plugged it into the old board, flicker-city. THEN I took the '166 shift register and changed /CLK to CLK and the flicker immediately disappeared! I tried the canary '161 in this new board and it worked immediately as well. So, now it is clear: I had my clock logic wrong from MANY boards ago. It just so happened to not be a issue until a more recent design. Fixed.

Secondly:

I was unofficially supporting the use of a 62256 32KB SRAM chip in place of the 128KB SRAM chip I'm currently using. But, even running the most basic and simple test programs all failed with it. So I set up to draw just a single byte on the screen, and sure enough trash started showing up on the screen, as if it were reading a floating databus. So, why was this happening here? It just so happens that my particular 62256 is also just a hair faster than the '1008 I was using, so it was writing twice per cycle, once garbage and the other was intended.

I had a spare 3x NAND gate after doing the last surgery, so I did a LOT of surgery and qualified the /WE pin to the second-half of PHI2-high. And sure enough, the 62256 works now, as well as the bigger '1008. The whole time, it was a FLUKE that my RAM was actually working!

Two flicker issues solved!

Now, my next issue is the auto-adjust on the screen. It seems my monitor "doesn't like" my new video ROM signals as much as previously. It is still running smoothly at 60 Hz, but I need to manually change the phase and horizontal position to get it to fit right.

Makes me wonder, should I add a border? The C64 and VIC-20 did that, a big fat border around the edges. Why? I suppose it's because older TV's were not as universal, and some edges could be clipped off? Anyways, if I added a small border around the edges of the screen, it would fit inside the monitor still, give me 38-column text, and I believe my living room TV with the VGA-to-HDMI adapter would display it better (it was clipping off the sides last time I tried).

Anyways, the adventure continues. Major victories today! Thanks everyone.

Chad

[sburrow]

Alright, every feature on this board now works! Code, keyboard, audio, SPI EEPROM, and SDcard.

Attached are some pictures of the board and the surgery I did to it. Also attached are some pictures of the monitor and BASIC, with two different possible color schemes.

I also included the revised schematics (up to this point) which includes my surgery done to the board.

And then I'm including my code. Each bank is only 16KB, and the monitor and BASIC are both on Bank1. I'm using Bank2 as just a testing area right now. It is mostly uncommented, I plan on going back and commenting a lot very soon.

Lastly I'm including my SDcard code, which again is just for testing but at least shows the capability.

Now, the goal is to make a better design document, detailing everything on this board. This would also include commenting the code I have in Bank1. After that, I'm going to make a (good) game!

Well, there you have it. The Acolyte Computer is finally done.

I have been here for over a year now, and I want to thank all of you for you help and continued support. In particular, helping boost my morale and give me ideas when things didn't go as planned. I appreciate this community we have here. And of course, thank you for putting up with me

Have a wonderful day!

Chad

EDIT: Changed the VideoROM.cpp file ever so slightly. It now works with my VGA-to-HDMI adapters on the big screen TV!

[fachat]

Congratulations! Great piece of work!

[Paganini]

Awesome!! Not too bodgey at all.

[sburrow]

Thank you both very much! I could not have done it without all of help here though. This is not just my board, this is everyone's board!

I put together a design document, explaining each component on the schematic. It tries to show the overall reasoning, and then get into why specifics were done. I wouldn't call it completely comprehensive, but at least it's better than nothing.

I tried commenting code this morning too, but thought that was boring Oh well, eventually.

Thank you again!

Chad

EDIT: Added a software section to the Design Document.

[sburrow]

Probably the last update for a bit (maybe):

I got Tetris! I probably spent around 4 hours coding this (no comments, so I'm not including it here yet). I tried 2 other times and saw it failing. So, my recommendation is: If it doesn't look like it's working, just start over! And that really helped me.

I want to include the music, or at least sound effects. That will require a bit more testing than my simulator can handle, so that process would be much slower. It would also be cool to make the blocks look a bit better. But overall, it's 99% done.

Up next would be a MUCH more detailed design document.

Thanks everyone!

Chad

[plasmo]

Wow, very cool. Now I really need to work on the emulation of your hardware so I can play Tetris, too.
Bill

[Dr Jefyll]

sburrow wrote:

I got Tetris!

Hooray -- you surely did!

Great to see that screen shot! I think we can firmly say this project has officially graduated off the drawing board and into reality!

-- Jeff

[Paganini]

Bill!

That looks great, Chad! Now you just have to expand your software support. When will I be able to play "Global Thermonuclear War" on it?

[sburrow]

Paganini wrote:

That looks great, Chad! Now you just have to expand your software support. When will I be able to play "Global Thermonuclear War" on it?

Haha, no time soon Was wanting to put Oregon Trail on it too, but my ROM space is quickly drying up.

Dr Jefyll wrote:

Great to see that screen shot! I think we can firmly say this project has officially graduated off the drawing board and into reality!

Thank you Jeff, that means a lot.

plasmo wrote:

Wow, very cool. Now I really need to work on the emulation of your hardware so I can play Tetris, too.

Haha, I can email you my code whenever you want!

So, I got the boxes to be a tiny bit better looking. I then tried doing some sound. I got a simple Tetris theme going, although it sounds "sickly". I got some beeps and boops whenever you complete a line and all that, but I found that they slow down the game WAY too much. The audio is directly manipulated by the 6502, so if you want to play a tune, it must dedicate nearly all processing power to the music. With keyboard interrupts also going, the program starts stuttering the sound, and when it is finally done the next piece is halfway down the field! So, I just removed sound entirely. I'll try again later. I know there are ways to make it work.

Thank you everyone, I appreciate your kind words.

Chad

[sburrow]

Been working with the SD card code this morning. Learning what it can do, etc. Just wanting to show off some stuff.

Attached is my code for drawing a bitmap picture to the screen. It takes about 30 seconds to initialize and draw the whole thing. It's super slow because I use a lot of delays and pumps while reading. Using GIMP and my own C++ code, I can convert any ol' JPG into hex code within a couple of minutes, like I did with Link and Zelda (original here https://wallpaperaccess.com/full/3596270.jpg).

I'm thinking I will use this capability for a slideshow during our upcoming Math Appreciation Day in April 2023. Last year I was limited to 4 pictures because that's all the ROM could store. Now I will have 2GB worth of SDcard memory, plenty of room for pictures. If so, I'll probably tighten the code to make it quicker than 30 seconds to load.

I think the blue/orange combo is really nice. George (gfoot) had used this combo for some of his earlier VGA designs. I think it has a warm feeling and is pretty versatile, not harsh and alien like my (favorite) red/cyan mix I'm so used to. I also chose this because: blue + orange = white, exactly.

Just showing off, that's all. Thanks everyone!

Chad

[sburrow]

Update!

Attached are the latest schematics and some pictures of the board. What a mess! Compare with the earlier bodge wires, and yeah, this is going overboard.

Some improvements today in particular:

1) I connected PHI2 directly to BE, bypassing 3 logic gates. It is working flawlessly. I think one of y'all had suggested it, so I tried it, and it's great. Thank you.

2) I added my RAM expansion, giving it now a full 64KB of RAM and 128KB of ROM. It is tied to the audio-out line, so not always desired, and I have a jumper-connector-thing to select using it or not.

3) I reduced it by one chip! (Don't look at the fact that I actually ADDED a chip to *this* board, ha ha) After the PHI2 = BE thing, I decided to repurpose another gate, shift things around, and now I'm using diode logic and a transistor to help out. And it seems to work great!

4) I clipped the transistors on the color line long ago, and it has worked great. I also adjusted the colors slightly to make make a monochrome screen differentiate between all colors easier. The color change is so slight it's barely noticeable, but behind the scenes it just got more functionality.

5) I've learned a lot, and that's very important.

SDcard is working flawlessly, I have a 4 picture slideshow going right now, been running for hours without any issues.

And that's about it. Just hardware changes. Only small updates to code, making things easier and better. All the same functionality.

Thanks everyone!

Chad

[BigDumbDinosaur]

sburrow wrote:

Attached are the latest schematics and some pictures of the board. What a mess! Compare with the earlier bodge wires, and yeah, this is going overboard.

Red bodge wiring??? That’s not to standard! Those electrons are going to be all confused.

Although I mostly can’t tell blue from green, I have used blue bodge wire since time immemorial (at least since the late 1960s)—it’s actually 30 AWG wire-wrap wire that I use. In fact, at the company where I worked in the 1970s and 1980s, when a prototype had to be patched, the design engineer would issue a “blue wire” ECN. It actually said that at the top of the page.

Kidding aside, glad to see you are making progress.

Incidentally, in your next iteration, you should consider using 74AHC logic in place of the 74HC stuff where possible. 74AHC logic performs at the speed of 74AC, but has the gentle outputs of 74HC. You gain timing headroom without having to deal with the problems that extremely fast edges can cause.

[BigEd]

sburrow wrote:

SDcard is working flawlessly, I have a 4 picture slideshow going right now, been running for hours without any issues.

Good to hear!