Hello everyone!

For the past week or so, I have been making modifications to my Acolyte board design (last revision here viewtopic.php?f=4&t=7096). This new plan will be using the 65816 processor!

W65C816 running at 6.29 MHz, with 32KB RAM (expandable), 64KB Video RAM, 30 KB ROM, and 2KB I/O space. VGA graphics with 640x240 4-color mode or 160x240 256-color mode. Along with the usual PS/2 Keyboard and Genesis controller input, SD card support, audio tape data input, 1-voice square wave audio output, etc.

This can also run in 6502 emulation mode with full capability, minus access to half of the Video RAM. It should also support a drop-in 65C02 replacement, acting similar to emulation mode.

I started by stepping up the speed from the Acolyte's 3.14 MHz to 6.29 MHz, which allows for more color depth. My 70ns ROM is the slowest component and limiting factor, BUT I think I discovered that if I leave /CS low and use /OE to access it, it only takes 35ns instead! Similar with the RAM, but from 55ns to 30ns.

But stepping up the speed also means I needed to double my video memory from 32KB to 64KB, which just so happens to be a full bank on the 65816. And that's how this plan got started.

Just a warning, I have barely even seen any '816 assembly, and know little about the true capabilities. I see how it operates from a hardware perspective and have read Garth's and BDD's info on it, but I have yet to get my hands dirty. PHI2 qualifications are a big deal in the logic, since I'm running video AND banking during the low cycle, and RAM/ROM/VIA access during the high cycle.

If you are wanting to take a look, I included the schematics, and an idea of my memory map. There are quite a few 'screwy logic' things going on, but I believe it should work as expected. I will of course be quadruple checking everything, in particular the timing, before even designing a board for it.

Thoughts? I know some of y'all are '816 fans, wondering if you see something obvious that I missed.

Just a proposal at this point, nothing solid. Thanks everyone!

Chad

Very interesting! I was about to make my own thread about a 65816 SBC i've been planning.
Though i'm too scared to put VGA on the same board as the rest of the System (more parts = more ways things can go wrong), so i'm planning on just having an expansion port specifically for a Video Card. plus it keeps the board size and price down.

I think your design is pretty clean so far. backwards compatible in Emulation Mode, but with more capabilities in Native Mode.

from what i can see in the Schematic, you basically mapped the whole 512kB RAM into Memory: $000000 - $07FFFF, and then just "assigned" Bank 1 to be used as VRAM.
Personally I would've used a seperate IC for the actual VRAM so that when the CPU is accessing regular System RAM it wouldn't need to go through those transceivers and share bandwidth with the Video Circuit.
In Theory that could also allow you to run the CPU at ~12.5MHz and only slow down to ~6.25MHz when accessing VRAM specifically. (ie Clock Stretching)
something like this:

obvious downside being that it adds a second RAM IC, but atleast it frees up 64kB of System RAM.

I'd like to see what you have planned, compare notes, etc. I've been using BDD's POC schematics at times, making sure I have the right idea here and there.

This design is fairly close to my last design, so the VGA side isn't terribly innovative.



I had that in my Acolyte design, along with a separate ROM chip for the VGA timing. But wow, those big chips take up a lot of space! It was very easy to share the RAM, but the big challenge was sharing the ROM. THAT requires some fancy quirkiness to get just right. A small "crowning" achievement in glue logic design I'm happy to replace a big chip with a 'little' chip.



Haha! I would love to see that one day But that would definitely force me to use SMT parts, which I'm not in the market for currently.

Thanks Proxy, I appreciate the feedback!

Chad

why would that require SMT parts? what i described it basically just your current system except when accessing VRAM a signal goes to a 1 bit MUX to switch between the 2 clock speeds.
the rest of your system could be able to handle the speed without any PLDs, CPLDs, etc

Maybe I missed something: You were talking 12 MHz. TWELVE. I'm happy with 3 MHz, this whole 6 MHz thing is risky business for a guy like me. TWELVE?! I would expect that would need 25ns SRAM at minimum, which (as far as I've been seeing) is generally only in SMT.

Don't get me wrong, 12 MHz would make a very beautiful image, and I certainly have the RAM available now with the 65816. But gosh, that is just very fast!

Maybe one day Thank you Proxy.

Chad

i've gotten too used to high speeds. a system with the CPU speed being below 10MHz feel like it's "crawling" instead of "running" to me. sorry about that

My 65C02 SBC (version 1) ran fine up to 16MHz and i barely had any idea what i was doing in terms of PCB layout and routing. version 2 runs at a casual 20MHz.
true, you're using discrete logic ICs instead of PLDs like i did in my version 1, but those had a 15ns pin to pin delay and i had 2 in series for IO Decoding, so a worst possible delay of 30ns when accessing IO, and a worst possible delay 15ns for RAM/ROM.
and despite that it still worked with the 70ns FLASH chips i use (though at >16MHz i did need 1 wait state). so i doubt the 55ns SRAM would be a problem.

so why not try your design at 12MHz? sometimes your own system can surprise you with it's capabilities.
if you want to try it but also be on the safe site in case it doesn't work, you could try having a jumper to manually select if you want the constant 6.25MHz, or the 12.5MHz with the clock stretching whenever VRAM (or ROM) gets accessed.

LOL, it looks like I'm not the only one here who has had a bout of VGA fever, lately!

http://forum.6502.org/viewtopic.php?f=4&t=7211

Hi Chad,



WD65C02s are specced up to 14Mhz. I have my system running at 8Mhz; I don't know if it can go faster, because 8Mhz is my fastest oscillator. Anyway, that's with normal SRAM (75NS I think). I have some 15ns SRAM that I got from Mouser. It wasn't too expensive: https://www.mouser.com/c/semiconductors/memory-ics/sram/?access%20time=15%20ns&mounting%20style=Through%20Hole

I haven't done anything with it yet; it's PDIP28, but the narrow (300mil) form factor, so it doesn't work with the RC6502. I'm planning to use it for video ram when I start making my CRT controller card.

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

Well, it seems y'all are all for the higher speeds



Wow! Well, I'm happy you feel at home with the higher speeds Proxy. I like your '816 design, thanks for posting that on another topic. Because you are using the CPLD, you are able to get everything much closer on the board, and I'm sure that also helps a lot.



That will make one of us I guess I'm not in it for the speed really, just the features. I am (personally) more interested in VGA, keyboards, and joysticks than maxing out the 14 MHz spec. I always figure that if these guys in the 80's had 1 MHz C64's and were able to make splendid games, so can I.

So, a small update, and then a question/poll:

I've been toying around with it a bit, robbing Peter to pay Paul, trying to maximize the 'features' side of things without adding any extra chips. Or at least minimally adding. I think I have about 26 chips on board right now, only 4 of which are 'big chips'. My typical Acolyte boards have 6 big chips, so that is an improvement in my eyes.

By manipulating the VIA pins a bit, I basically have 4 spare pins left. I went on the search as to how to implement 'color palettes', perhaps I can get 16 colors on screen at once, but from a palette of 256, or 256 colors out of a palette of 4096, etc. What I am finding is that these palettes are designed for when incoming timely data is much less than the desired output data.

Say I have only 4 data bits being converted into color. That means 16 colors. BUT if I have 4 palette data bits added, I could route 4 + 4 bits into, say, two RAM/ROMs and I could yield 8 + 8 color bits, substantially increasing the color depth. In this example, you would still only have 16 colors, but from a selection of 256 colors, from a possible combination of 65536 colors! That is, if I'm understanding this correctly.

What you *don't* want to do with palette bits is say 4 data + 4 palette = 8 color bits = 256 colors. Yes and no. Those palette bits would then become a 'shade' or 'hue' for the entire screen. Like, the whole screen is red, and you are just changing variations of that red color. Neat, but not practical. The only way this would be useful is if I have interrupts on H-BLANK or V-BLANK and manually change the palette bits as I go, which would indeed give me a lot of colors, but I would essentially be 'racing the beam'.

Another way to add more colors (without the 12 MHz speed) is to access my RAM twice while PHI2 is low. I do believe this is technically possible with the 6 MHz. The idea is that I latch two pixel's worth of data where I normally only latch one. Then I display one but high-Z the other, after a set time I switch them (probably using an SR-Latch). The issue then is the banks in which video memory reside are in two separate locations, and I cannot just write 'sequential' pixels as I would have to hop back and forth all the time. Not terrible, but not ideal.

That would be similar if I used two RAM chips for video output, two different (disconnected) banks essentially, and a lot of wasted space (and more big chips!).

[ All of this would be easier if they still offered smaller RAM/ROM chips like they had back in the day, mix and match for greater flexibility. ]

And perhaps I'm just misunderstanding?

So my question/poll for any of you: Is it worth it? I can get 256 colors at 160x240, which is pretty darn good in my eyes. That is perfectly serviceable for video games. On the flip side, I still have 640x240 with 4 colors, near essential if you want to do anything like programming or text editing.

But the temptation of having 320x240 with 256 colors allures me. Y'all all say to go for 12 MHz, but I'm not budging. Without a CPLD to help, 12 MHz is just too much for this TTL-based video circuit. I couldn't get the chips close enough together, for one thing. And because my board is so big, going to a 4-layer board would be massively expensive. Basically it would be too many moving parts that are far away from one another at such a high speed.

Thoughts? Reflections? Thanks for the feedback!

Chad

A updated revision! Attached are schematics.

So, in my quest to get a higher resolution 256 color mode... I think I did it. I added a second RAM chip (which I was going to have as expansion anyways) so that I get 16 bits of color information each clock cycle, and I split them up into 8 bits and 8 bits, creating two pixels where there was only one before! Finally I now have 320x240 resolution with 256 colors.

That was the easy part. The hard part was now compensating for if that extra RAM chip was not installed. I have tried to put as many options as possible on the board. 65816 swapped out for a 6502, one RAM chip or two, extra shift registers for more color in 'text' mode, expansion slots, GPIO pins, etc.

The new memory map is something like:

6502 Emulation Mode
$00.0000-$00.7FFF = 32KB RAM (28KB is Video RAM)
$00.8000-$00.9FFF = 8KB I/O (VIA duplicated on $9000-$9FFF)
$00.A000-$00.FFFF = 24KB ROM

65816 Native Mode
Bank $00 and $01 are duplicates from above, except the RAM is not Video RAM anymore and both 32KB of RAM are unique.
Bank $02 and $03 are Video RAM (from $1000-$FFFF each)
Banks $04 to $0F are extra RAM (if applicable from installed chips)
Banks $10 to $FF are open for expansion

The 'screwy logic' is back for sure, and I'm using some very interesting techniques to latch data at exactly the right time. Because I'm trying to allow for chips not being present on the board, I had to add a ton of pull-down resistors to the video circuit. The result is pretty close to what I'm wanting, but I might want to adjust a few values here and there.

This is still running at 6.29 MHz, and I won't be changing that any time soon. I realized that even if I stepped my speed up, the way I access Video RAM will not allow me to draw or clear the screen any quicker. Because it is a 1:1 ratio of CPU clock cycle to Video clock cycle, the video side of things will never seen an improvement on speed. Of course the calculations behind the video can go faster, but I'm not at all worried about those. If my video isn't any more optimized by higher speeds, I'm not very interested.

At this point the board is becoming fairly large. I gotta stop with the new features! Before I get anything printed, I'm going to make an emulator/simulator for this thing, and see if I'm happy with it.

Just an update. Thanks everyone!

Chad

Zowie, that is some schematic!

You seem to really like VGA. I kind of assumed that it was more or less impossible using (shall we say) "period appropriate" hardware, thanks to the 25 MHz pixel clock, but that doesn't seem to be stopping you! Is it easier than I think it is?

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

Yeppers! I know every square inch of that thing. I lay in bed thinking about it, and OOPS I made a logic error, get out of bed, just to switch a inverter gate around.



Ever since I got my "Half - A - Pi" board working some months ago (here viewtopic.php?f=4&t=7030, you can skip to the end to see the results) I knew I could do VGA every time with 74' logic. My particular trick, to limit chip count, is to use a ROM with all of the sync/reset signals hard coded. It literally saves 10 chips at least, if not more. Another boon has been the 74HC590, which is an 8-bit counter with tri-state, perfect for taking the VGA side on and off of the address bus. You can get the same effect with a lot of '161s and '245s, but the '590 simplifies it down a ton. Ben Eater's "Worst Video Card" was inspirational, and although he uses a lot of 8-input NAND gates instead, the same principle applies. I had a lot of help getting here though, in particular Garth Wilson (GARTHWILSON), Bill Shen (plasmo), and George Foot (gfoot) helped get me to where I am today.

My answer to your question: It is MUCH easier than we often consider. As long as you are careful with your timing, that is. I'm living proof that it is easier than it seems, because I'm not a professional in the least. I, like you, started pursuing composite video first, thinking that must be easier since it's older or whatever. Nope, I can't understand it! I mean, I think I could get a black and white signal, but colorburst completely alludes me. VGA is basically 'discrete' which helps a lot (in my eyes).

Thanks Paganini!

Chad

Thanks Chad! That's a lot to mull over. I will take a look at the Apple II thread you posted.

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

I got scared away by the 6.29 MHz.

I was doing some small modifications, trying to get my logic timing shorter. At 6.29 MHz, I have only 80ns to get everything done in a half-clock cycle. And... I couldn't reach it safely. Possible, but really cutting it close. Too close.

As I am not using a CPLD to speed up my logic, going through multiple gates really starts to cumulate the delay. With all the features I'm wanting, it is just not looking possible/probable.

So, attached are updated schematics for 3.14 MHz, and a different memory map. It would have VGA modes of: 640x240 2-color and 160x240 16-colors. I know this is far less than what I had been planning, but what I had been planning would have probably been DOA. The 3.14 MHz speed is safe, and has been accomplished many times now. This still runs the '816 and supports a 65C02 drop in replacement.

Sometimes we have to face defeat head-on. And without a CPLD, slower is safer.

I don't think I'll have much time for more of this in the near future, life circumstances and all that. So I can't promise updates on this project for a while. We'll see!

Thanks everyone!

Chad

Hope you do get something going - I'd like to have an '816 system with retro-style VGA (The Foenix and spin-offs do exist though, but many $$$!)

One thing I always have a concern for is just how many cpu cycles are needed for a modern video display (without some form of accelerator hardware that is). There is a reason things like blitters and sprite overlays came about in hardware - mostly due to the limit of pixel poking...

Even this more modest 640x240x1 bit per pixel needs just under 20KBytes of RAM and to clear that using the '816 block move instructions at 7 cycles per byte will need: 640*240/8 * 7 cycles = 134400 or at 3.14Mhz = 43mS. That's also your software scroll time too, so about 23 lines per second. Plotting a pixel for points, lines, circles, etc. is now a read/modify/write operation, further increasing the cycles needed - on the plus side, if you restrict your character set to 8 pixels wide, and keep them aligned to a whole byte boundary then printing characters can be done in a tight loop of N lines of 1 byte at a time and be relatively fast.

After doing my 320x240 pixel composite video (with an ATmega) I more or less abandoned direct on-board video for my projects but I'm always keen to see what ideas others have.

Would be you able to take the video to 320x240x4 bits per pixel? (QVGA size) That'll take your RAM up to 38.5KB - at the expense of 40 column text rather than 80, but it's more in-line with "traditional" display sizes of the era... Of-course more RAM to clear, slower to scroll, etc. but there's always a trade-off!

(Although the BBC Micro does have a 640x256x1 mode)

Cheers,

-Gordon

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