Hello everyone!

The time has finally come for me to show to you my latest single board computer: The Acolyte '816 Computer

This is a 4" x 4" four-layer board with a mix of surface mount and through-hole components. I used solder paste and a skillet for the QFP packages (the 65816, the 6522, and the XC9572XL CPLD). Those were the easy ones! The rest are mostly SOIC packages which I soldered by hand. The two 512KB RAM chips are SOJ and that was much harder than I thought! I made as many components through-hole as possible so that my 5 yo daughter was able to help solder them for me. She did all of the capacitors, the DIP socket, and some of the resistors. She let me finish up the connectors myself

The '816 runs at 12.5 MHz, half of the 25.175 MHz VGA clock speed. Thus the video is active on PHI2-low and the processor is active on PHI2-high, just like all of my previous Acolyte builds. The problem here was to capture the '816s bank addresses during PHI2-low, as well as letting the VIA be selected on the rising edge of PHI2. The solution was a bunch of '245 transceivers!

This SBC is capable of displaying 64 colors at 320x240 or mono at 640x240, at the same time side by side. The way this is done is by dedicating the upper two bits simply to black and white, while leaving the lower 6 bits for color. For example, 0xC0 produces white for text, while 0x3F produces white for color. The text and color both seem pretty crisp, even on a 'smart' TV with a VGA-to-HDMI adapter (though these pictures are blurry it seems). Using the CPLD, it is also capable of hardware vertical scrolling, allowing for better use of the 80-column text and perhaps in some types of video games.

It also is a "ROM-less" design. Right now I am storing 512 bytes of bootloader code on the PIC16F886, which spoon-feeds the '816 upon startup. After that, the '816 can take over, or the PIC can continue to spoon-feed data from the SD card. The PIC's databus is connected directly to the VIA, so after boot the '816 can still talk to the PIC at any moment.

Some of the peripherals I chose were the PS/2 Keyboard and Mouse, on separate ports now. It also includes a 3.5 mm audio jack for 1-voice square wave audio from the VIA's T1 timer, two ports for Sega Genesis controllers, and a 6-pin connector for an FTDI USB adapter (which came in REALLY handy when debugging the PIC!). This machine is meant to have two-player video games, but also things like text editors and paint programs. All of this is powered by a 5V USB wall-wart.

The github page with all of my (old) code and schematics is here: https://github.com/stevenchadburrow/Acolyte816 BUT, that code is old now, and I have had to make a few bodge wires to fix some misconceptions I had when designing it. The current code is quite scattered, but I plan on sharing it soon enough. It's running well and seems stable when I leave it running for long periods of time, but there is still SO much left to do. Many hardware capabilities have not yet been fully implemented, and my bootloading process needs a ton of help.

I want to thank all of you for helping me get to this point, and beyond. Although this SBC is still a work in progress, I consider this my "masterpiece", but by the classical definition. That is, I present to y'all this work in hopes that you accept me as a peer, no longer simply a novice. I do not think I have yet obtained the wisdom and rank that many of you all hold, but I do feel that I have now "leveled up", in a way.

So, thank you. Because without y'all being here for me, I wouldn't have reached this point.

I'll be updating this topic as I have more developments to show!

Chad

Sorry for all your wasted efforts, but you were no longer a novice long times ago. By tackling video logic first, you've bypassed the algebra and went directly to differential equations and very successfully, by all accounts.

SOJ components are much easier to solder if you have longer finger pads where solder tip can preheat before applying the solder.

Great job, a masterpiece, indeed.
Bill

Excellent work, I've always especially liked the way you compete your designs into well-rounded devices with a broad set of functionality. And as Bill said, you are way beyond novice!

The way you do the graphics and text in one data stream is interesting too, I thought about something like that once. Does it overlay the high resolution text on the graphics colour? Did you consider instead making the text layer multiply the graphics layer, to allow text of any colour on a black background, instead of white text on a coloured background?

Haha that's funny Thank you Bill.



Thank you George.

Both you and Bill have been absolutely fundamental to my learning and growth.



I don't know about multiplying or adding, but they actually *can* be utilized at the same time. So, theoretically I can have (brightly) colored text, and theoretically I have access to 128 colors. But what happens is the voltage levels on the video circuit exceed the 0.7V maximum, I think reaching to 1.0V. Still, the VGA-to-HDMI adapter doesn't seem to care much, and it actually makes the color pixels look dimmer without the added brightness coming from the 'text' bits.

Though I don't think that answers your question I guess my best answer is that I can put them together to get high resolution color, but there are some limitations to it.

Chad

It is a good thing you are teaching your daughter how to solder. She won't be holding solder gun like this when she grows up.

Nice work!

And that picture: owwwww.

_________________
Machine room: http://www.floodgap.com/etc/machines.html

Nicely done, Chad: functionally similar in many ways to my Neo/STM design. The 816 gives you the option to handle a lot more contiguous video memory than my 6502, and the faster speed (12.5 vs 2.5) should give you enough grunt to move stuff around in there.

Congratulations.

Neil

Very nice Chad - well done, and thanks for sharing!

Well done - looks very nice.



If I calculate it right, the video RAM at 320x240 = 76,800 bytes, or a bank and a bit.

The '816 block move instructions work at 7 cycles per byte and can't do a bank wrap, so...

Clearing the screen in a single bank - write 0 to byte 0, them move from 0 to 1 for 65535 bytes will take 65535 * 7 cycles, so 458745 cycles or (if I did my sums right) 37ms per 64K plus the extra in the next bank, so maybe pushing 25 screen clears per second. I think that's OK.

Can be speeded up (x2 and a bit) with 240 consecutive STA line0,y ; STA line1,y ; STA line2,y and so on... at the expense of RAM.

I think the code to do stuff like line-drawing will need to be carefully coded too - especially in 640x240 mode. It's all read/modify/write too. Not the end of the world, but should still be fast.

Want to port RubyOS:BCPL to it:

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

that's a pretty clean looking board! (ignoring the botch wires, those are inevitable with new designs )



that's the main reason i went with 320x200, by simply cutting off a few lines at the top and the bottom of the screen you can lower it's memory footprint to 64000B which fits into a single 64k bank with 1.5kB to spare. of course you loose some vertical screen space, but it could be worth it if it helps with drawing speed.

doing some math, using MVP/MVN @ 12.5MHz on the 64000 Bytes would take ~35.84ms giving you 27.9 FPS, completely ignoring any other proecessing that would need to happen inbetween frames.

doing some more math (which isn't really relavent but i thought was cool) if you were to do 400x300 @ 4bpp (using 800x600 and doubling pixels and lines) it would only take up 60000 Bytes while also being a higher resolution, in exchange for having a lot fewer colors. the 40MHz pixel clock would be divided down to a 20MHz CPU clock, in which case using MVP/MVN would take only 21ms to copy a whole frame, which results in 47.6 FPS.

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

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

Ah I see, you're combining them in various combinations through resistor adders. I guess in effect the text bits act a bit like intensity bits in 16-colour VGA palette, pulling the colour up towards white or down towards black. I think this would still mean you're restricted to having the text background colour be the "dark" version of the text foreground colour. But as it's all done with passives it will be quite compact, and it means you actually have 128 colours, not 64, as there are light and dark versions of all the colours!

I had a look at your schematics and I have attached a summary of how your "red" output works:

On the electrical front, if I've got this circuit right, I'd be a bit concerned at the 3.3V input to the 74AHCT08, if that label name is accurate; and also the loading on its outputs, as it's often going to be driving 5V through 480 ohms one way or the other, when one gate is outputting high and the other low; that's 10mA. I haven't checked the specs but it feels quite high.

I'm pleased to see that you're not suffering from glitches between pairs of pixels with this setup - when I tried something like this I found that at the point the latch (your 74AHCT273) is reloaded, it was hard to get the multiplexing (done by your AND gates here) to switch at exactly the right time - so I avoid that sort of system at the moment. It looks like you've managed that well though.

On the whole I think your circuit is performing an additive blend, and there are going to be some interesting effects on brightness from the various combinations of highs and lows. It also means you can set or clear both high bits together to brighten or darken the graphics colour, effectively getting an intensity bit like with 16-colour VGA.

Going back to what I was suggesting in my last post, an equivalent would be to replace R3 and R4 with low-voltage-drop diodes, so that these signals can pull the "graphics" colour down to (almost) black, or let it remain at whatever colour it's meant to be - this is what I meant by "multiplying" the text layer with the graphics layer. I don't know whether you'd prefer the result or not, but I think it would give richer options for text colour, with the constraint that the text background would now always need to be black, and you'd be back to just 64 colours, rather than 128, as you'd no longer have the bright and dark versions of them.

Apologies if that doesn't make much sense - I'm in a bit of a hurry - but happy to elaborate or discuss more later!

i am still kinda waiting for the perfect project to try my 2-pass DMAC concept on.
i think i already talked about it in some other topic... but to quickly recap (without taking the thread too off topic) the overall goal is to use an IDT720x FIFO together with a CPLD to implement a DMAC with less logic than something more conventional would take. so it has an address register, a byte count register, and a control register.

you set the direction of the copying, either read from memory into FIFO or vise versa, and depending on the mode the address register acts as either a source or destination address, saving some logic as you don't need 2 seperate registers/counters.
plus there is no fear of potentially corrupting data by having a byte overwritten before it was copied. downsides are that it takes a bit more work from the CPU as it needs to run both the read and write pass manually, plus you're limited to the size of the FIFO in terms of how much data you can copy at once.
i think this idea would be more useful with a "rectangular mode" where instead of a single byte counter you specify width and height and have it copy rectangles of bytes. in which case the 1kB version (IDT7202) could hold a single 32x32 pixel large square (@ 8 bits per pixel), or multiple smaller ones since you can do multiple read/write passes in a row. plus you could mix linear/rectangular modes between reading and writing to convert between having sprites and character on screen, and having them layed out linearly in normal memory for the CPU to work on more efficiently.

but overall when you start to want things like conditional writing to handle transparency, or work on sub-byte values (ie actually blitting), you kinda start to get into FPGA territory.
which is not necessarily a bad thing, the MachXO2-640HC for example costs a bit more than a new ATF1508AS (mouser), and has likely more than enough pins and logic to implement a decently capable VGA controller with built-in hardware acceleration for things like sprites, scrolling, and a simple DMAC with rectangular copying.

anyways, sorry if this went a bit off the rails.

Thank you everyone. I'm still not out of the woods yet though! Having problems interfacing with the PIC still, and some of my bodges are so delicate that I've had to resolder them three times already! To me, the PIC is acting weird sometimes, just plain looney-land, so I'm constantly starting back at simple code and trying to add tiny pieces along the way. It is a constant battle. I was able to revert back to my fallback system monitor, but the SD card image stuff I just cannot replicate at this time! Once the PIC is done loading the bootloader code, the '816 does great, but when it asks the PIC for additional data it acts sporadically it seems. I had MANY issues like this along the way, mainly databus contention. Here I wonder if it's some PIC register not cleared or something, IDK. Arg.



OH! Now that makes sense! Hm, that is an interesting proposition! And, I would simply replace these resistors with diodes, which would be very simple to do on the board. Hm, cool idea George, I'll be considering that (once things are less PIC-ky, har har).

Thanks again everyone!

Chad