So, I have a few of the things listed here decided on I believe, since I have a CNC, I'd like to go the PCB route, I'd also like to go for 5v, since I've worked with a lot of 5v devices already (does 5v give better clock stability as well?) For surface mount, I can solder by hand and I have a hot air kit and can source solder paste if needed (I've been wanting to build a paste dispenser for a while anyway), I realize I'll probably need to build a reflow oven to do it as well, but adafruit (I believe) had a pretty neat hack for a toaster oven based reflow oven that I might try. Ultimately, I'd like to stick with THT as much as possible though, for both the look and the ease of use (and easier to find sockets)

A slight deviation, but something yo might be very do-able with CNC milled PCBs is ... Manhattan Style builds. There are some real beautys out there. Proper Hipster.

https://hackaday.com/tag/manhattan-style/

Enjoy,

-Gordon

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

I don't mind the hijack when it's useful info. Ofc, I'd like to stay away from a high power "video processor" I would like to run something like a GPU chip, but I'd like it to be closer to the 6502 in power as far as graphics are concerned, maybe with the ability to stream pixels in bursts to save cycles.



I've not dealt with FPGAs much, or anything like them either, until yesterday I didn't even really know what a CPLD was, I'm hoping to get an elegant solution that's all true hardware, rather than programmed hardware, that I can run 6502 assembly on with just simple driver code to run each device. I realize that my goal may be a fantasy, but I'd like to at least give it a go and see what I can do with it.

heh, that's interesting, but a bit too ugly for me, especially for something that is sort of a gift, I think I like the bare PC board style with components on it more, although I do like finished PCBs as well (and I may get OSHPark to make me a PCB if this gets complicated enough)

There is a static ram chip that has an on-board video generator.

http://www.vlsi.fi/fileadmin/datasheets/vs23s010.pdf

It has 128KB of RAM and on-board composite video output (PAL/NTSC)

You can interface it via an 8-bit parallel bus or via SPI.

I'm not sure how easy they are to get hold of though, but there is at least one project using it that I've seen on the web. I didn't find out about it until relatively recently though, else I'd have considered it for my design, although I might still have a look if I can get hold of one as I have a 6522 basically doing nothing other than blinkenlights here.

Edit to add link to site: under €6: https://webstore.vlsi.fi/epages/vlsi.sf ... D=13893093

Cheers,

-Gordon

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

Is it possible to get small LCDs that can be fed with composite video? Also, would it be possible to "mock" sprite memory by some means of directing this chip to pull sprites from a particular peripheral (mass storage, EEPROM, maybe even RAM)?

EDIT: reading it says it has an internal bitter, for tile graphics and scrolling, this seems to be EXACTLY what I'm looking for, just the video output is composite, and I'd rather it be something digital (for feeding an LCD)

EDIT 2: AHA!: https://www.adafruit.com/product/913

Yes. Look for the ones aimed at car/van reversing cameras for example.

The chip seems to have an on-board block-move facility, so perhaps that could be used to move pre-loaded images or sprites into the main framebuffer memory

-Gordon

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

Thanks, I posted too quickly before properly googling, check my edits, I think they contain what I need

Honestly, what difference does it make? How powerful the "graphics chip" is?

As long as you can get your "vintage style" graphics out, does it really matter how many transistors are inside that little black chip? or card? or whatever?

Do you know how many transistors are in a 6847? Inside of an ANTIC/GTIA chip set? (The Atari Graphic chips.) Do you care? Isn't that the whole point of ICs? Black boxes that Do Stuff We Want?

Because the whole quandary here is that the vintage chips are simply very hard to get (not to mention they may not run with the clock speed we want from a modern processor, etc.). You can get C64 quality graphics, head on over to eBay and buy some C64 graphics chips and wire it up. That's what they do: pretty graphics for 6502s.

I don't like the modern solutions simply because they don't offer that "authentic" memory mapped experience of graphics. Grab buffers of ram, shove data in to them, poke some byte, and colors show up. Sending "draw circle" or "move sprite" over a "serial" port just isn't the same thing to me. But if someone could wire up a modern ANYTHING to RAM to replicate that kind of environment, then hallelujah.

I want a video subsystem, not a smart terminal. I can get those.

Nobody seems to blink about using a modern UART vs one from 1980.

It's more because the point of this is to learn the basid hardware with simple opcodes and setups, rather than writing a custom solution that runs on a powerful chip like any of the raspbery pies. It's like putting a modern I4 turbo engine that makes 240hp into an old muscle car that originally had a naturally aspirated V8 that made 200hp, sure the i4 is more efficient, probably easier to install (smaller) and has all the goodies of new style engines, but you're not going to learn anything about what the car originally was, or meet the challenges needed to build it to the way it originally was. I'm not looking for something that emulates a C64 either, I want the project to be something that I've designed and built, and I think it's more fun to work with bare metal here rather than software.

The post above for the SRAM based video controller is probably what I'll be going with for video, it's pretty much perfect in every way, and it's a "black box that does what I want"

I strongly recommend you start out by building a basic machine along the lines of what Garth has described in his primer. It's the concept of learning how to take off and land a Piper Cub before stepping into the cockpit of a 747 and heading for Hong Kong. Building the basic unit will not cost much in parts and will give you the opportunity to get familiar with digital circuitry, an area in which you said you don't have much background. If you attempt to build your "dream machine" right from the start you run the strong risk that the unit will be DOA and you will be unable to troubleshoot it due to insufficient experience.

Also, you will need to learn how to program in 6502 assembly language. A good way to get started is by running a simulator, such as the Kowalski assembler/simulator, and referring to the Eyes and Lichty programming manual. Also, a number of the members here are assembly language experts and can offer advice and help as you learn the ropes.

As for the oscilloscope, you can live without one for now. A good logic probe and a digital multimeter are enough to do most troubleshooting. The 'scope will become useful when you build your game machine and have to sort out timing issues that may arise.

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

I actually found out that my fiancee has a nice scope but it's not here right now, hopefully it will help in the future.

I completely understand what you're saying though, and I believe I will take the route of building a basic computer first, with a small text display to do some testing with, hell, I could possibly leave a pin header for adding a daughtercard that would manage the video aspect.

As far as assembly goes, I'm not entirely new to it, I've played around with a few emulators (there's one online somewhere written in javascript) and it seems to be fairly simple. I've done quite a bit of forth-like stack programming before, and in fact wrote a "scripting" language that ran off op codes and operands for a previous project. I'll definitely be using the resources to help master it, but I'm more comfortable with the programming aspect of this than anything else (it's my day job). The one thing that will be a bit weird, is programming the EEPROM with the bootup program, I'm thinking I'll use an arduino with a shield that can write the EEPROM, and build some interface to write out opcodes on my computer, program the EEPROM, then drop it into the board, taking care to make sure the boot up addresses, (FFFC-FFFE I think?) are set to point to the correct location of the program.

I do appreciate the grounding though, sometimes I tend to fly too close to the sun.

However, even with starting out small, I would like to still look into the SRAM video controller that was pointed out earlier, I've been reading the data sheet and it seems fairly simple, but I've not made it to the reference implementation circuits yet, so we'll see

Yeah, I haven't gotten into color, partly because my applications have little use for color, and I don't want the complexity. I'll leave that for the game enthusiasts.


Daryl's 65SPI IC shifts a byte in and one out (SPI goes both directions simultaneously) in 16 clocks. You'll probably need that much time just to handle each byte during the process anyway; so it wouldn't be slowing you down. He is re-working the design for a newer CPLD since the old one became unavailable. I still have several here I could let go of. The 6522 has a synchronous serial port that's just as fast, although not bidirectional. A few people have used it for one of the SPI modes. I'd have to sharpen my pencil to see what tricks (if any) there might be to using it for SPI.


The monochrome graphics LCD I've used, and another I plan to use, take a command to tell which dot row and column to start with in its internal memory. In this one, it wraps IIRC, so you would have to re-draw just the one row or column that wrapped around to the other side or end. I know I've seen other ones though that have an internal memory that's larger than the screen, so there's a certain amount of panning you can do without re-drawing anything.


Yes, just change the bytes you want to, and take advantage of the rest already being what you want.


You can often get free dual-trace, triggered CRT oscilloscopes that businesses or schools are getting rid of, in the range of 20-100MHz. Do yourself a favor and get a decent scope. One of these will be way better than most of the cheap new digital ones like the worthless DSO Nano you hook to your computer, and certainly better than the scope from the 1950's. Just be sure to get a decent pair of 10x probes with it, and take care of them. Good probes are not cheap. There's a lot more there than meets the eye. (The 6502 primer's section on basic workbench equipment discusses this.)


You're welcome. It was written to answer a lot of questions and problems that kept coming up over and over in the early years of the forum. It does get frequent small updates. The whole site probably has a thousand links, and I definitely can't check them all every week; so if you find that one has gone dead, please let me know.


It's mostly unrelated. If anything, a lower voltage may cause less trouble, because parts are the fastest at their maximum voltage, producing faster edge rates that are more likely to cause ringing and double triggering, and also responding more quickly to it and being less forgiving.


There are of course thru-hole sockets for PLCCs. Remember also that if you need additional parts or connections on the other side from a DIP, you can forgo the holes and just put pads down on the board to solder the DIP to, holding it on with solder fillets. That should be fairly easy to unsolder too, using solder wick.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

On 5V vs 3.3V:

Generally CMOS logic runs faster at higher voltages, including the currently-produced WDC 6502 and 65816, and the 74-series logic chips to go with them. WDC specifies their CPUs to 14MHz at 5V, but only 8MHz at 3.3V. System designers, however, think less in terms of MHz and more in terms of nanoseconds; fewer nanoseconds elapse before signals become valid at the higher voltages.

Some chips and peripheral devices, however, are not 5V-tolerant - including the Raspberry Pi - and are likely to "let the magic smoke out" if even briefly subjected to 5V signals. Conversely, some devices are designed for 5V only and won't work reliably at 3.3V (though some do actually still work, even though it's out of official spec). To bridge the gap, you will need to use a level shifting interface. Not a complete disaster, but a complication. Read your datasheets for things like SRAM chips and display modules with that in mind.

On a related note, avoid 74LS series logic in current designs, and note also that 74HC is less than optimal these days (though it's cheap and is fine for slow logic). Prefer 74AHC where available, or 74AC if the specific chip you want isn't in 74AHC. The 74AHCT family can be used to correctly interpret TTL (as opposed to CMOS) signals which don't go to the positive rail quickly enough, such as the output of 74LS series logic.


I did some mental arithmetic based on what I remember of the BBC Micro's video system. This is capable of producing a PAL-compatible 640x256x1b 50Hz signal from a 16MHz dot clock (Mode 0), by reading 8 pixels worth of data into the Video ULA during the Phi1 phase of the 2MHz 6502 cycle, during which the CPU doesn't "see" the bus. (The ULA was an early, mask-programmed version of what we would now call a PLD.) This offers a useful baseline for video timings, from which we can extrapolate. Many other classic micros used an odd-looking CPU frequency, because the same oscillator was used to drive the CPU and the NTSC or PAL colourburst carrier; the BBC Micro separated these concerns.

Keeping the same 16MHz dot clock and assuming 8-pixel-square characters, you could implement a "text and attribute" 80x32 mode in 5KB, which is relatively affordable. This would require fetching one byte full of character data and another byte full of colour data (4 bits each of foreground and background colour index) per 8 pixels, which you could easily squeeze into the Phi1 phase of a 4MHz CPU, or with a bit more difficulty into an 8MHz cycle (a 55ns SRAM should just about be able to keep up, if you have fast glue logic). You'd need to buffer these results so that they were presented to the character ROM and the CLUT synchronously with the leading edge of the relevant character cell. The CLUT would be a small RAM with 4-bit address and as many bits as you like of width, directly driving RGB DACs; you could update it during any blanking interval. Put the output of the character ROM in a shift register, clock that at 16MHz, and use each shifted bit to switch which half of the colour attribute is presented to the CLUT.

You can then add flexibility in the system by offering per-scanline programmable display address, character-ROM row number, pixel shift-register divider, scanout delay and length. Your text is now capable of being moved with pixel granularity, scaled up both vertically and horizontally, or simply skipped to free up a bit more RAM. If your character ROM can be put in a pass-through mode, you can go the other way and provide unique pixel data in each scanline, giving you a H/V-scrollable bitmap graphics mode with some colour capability - but consuming as much as 40KB RAM at full size and resolution.

Food for thought…

BitWise mentioned the original Gameduino, which has VGA output on it. However, there is also the Gameduino 2/3, which come with a built-in display. It is interfaced over SPI, though, which may complicate things.