6502.org

No, but it does decode the entirety of the 24 bit address bus, as well as the read/write enables etc. properly. Which is half the battle with the '816 anyway. (The '816 data sheet has an example circuit to decipher the control lines outside of the address line if you're looking for that.)

And while it does not utilize more than 64K, it's decoding the banks properly (if perhaps hamfistedly) with the big NOR gate.

But the decode logic is one of the reasons I'm drawn toward the W65C265SXB, because it does decode large chunks of the 16MB space. It has other issues, but getting a 1MB+ system up with some rudimentary I/O is (seems) pretty simple.

If the circuit tools didn't completely vex me, I'd lay something out.

The banking of the Flash chip makes it easy for you to try to do development and prototyping on the board as is. The flash can be programmed on board, by the CPU, so you could readily create a simple driver that takes a serial download to one of the other flash banks.

But as a spec circuit, you can just eliminate all of that.

The suggestion isn't to use the system as is, but as a reference design to study and pick and choose as you will.

At the risk of rambling on in this thread too much ...

One of the reasons for through-hole is that I have a few friends here who have expressed interest in what I'm doing - and I know they can't handle the SMT soldering and there's only so-much I want to do for them anyway... The main problem area is memory - right now the biggest DIL 15ns SRAM I can find on mouser/farnell/rs is 32Kx8, I'm only looking at 128KB to start with though so 4 chips, however that nice Garth Wilson has an interesting solution on his site which I may contact him in the future about..

Programmable devices - 22v10's fine by me. Bigger? not so sure. It's partly my own personal knowledge and time to learn and partly wanting to at least try to keep a retro feel about it

Video - When I suggested it was hard, I was really meaning hard to remain truly authentic retro.

For now, I put together something based on just about everyone else's ATmega projects when I looked about a year back - from colour (Quinn Dunki's Veronica) to the Arduino "TVout" and came up with a 320x240 pixel compost video monochrome solution that's coded entirely in C on a 16Mhz ATmega1280. (Demo here: https://youtu.be/09zhGUbVxdU )

Other stuff I'll ramble about later..

Cheers,

-Gordon

Actually, RAM in POC V1.1 is 52K ($000000-$00CFFF). I deliberately omitted the bank bits latch so I wouldn't overwhelm myself with complexity if the design had failed to work.

Below is part of the schematic for my POC V2.2 design. This is the MPU interface, which includes the hardware needed to generate the bank bits. V2.2 will have 1 MB of RAM, so address lines A16-A19 are generated.
The bank bits latch is a 74ACT573. It sees an inverted clock (Ø1, identified as PHI1 on the schematic) that is derived from the clock generator flip-flop (U1, left side of page). That way I avoid the prop time penalty of an inverter in clocking the bank latch's LE input.

This schematic also includes a data bus transceiver, which is really being used as a level converter. However, it also assures the data bus is vacated by other devices in the system during Ø2 low. Along with that, this schematic illustrates how to generate read/write signals for silicon that has separate /RD and /WD control inputs.
No delay is needed in latching if you use sufficiently fast silicon, which is where the 74ACT573 gets into the picture. It's worst-case response to the LE input is 11ns. By the time the MPU switches the data bus from bank bits mode to data mode the '573 will have already closed its latches and captured the bank bits.
Both Digi-Key and Mouser have plenty of through-hole logic in stock. However, big SRAMs are only available in SMT. You can get a 512KB, 5 volt SRAM in SOJ36, which can be manually soldered.

BTW, you may have noticed that I did not use any 65xx I/O silicon in my designs. I didn't have a need for the 65C22 when I designed POC V1 (still don't), and the 65C51 is defective and grossly inferior to modern UARTs.

The Atari used custom chips for its video.

The VIC and VIC-II are custom chips.

Only the Apple II hacked it's graphics out of old hamster wheels and staples.

And then, of course, there's the ZX-80/81 which simply made faustian bargains to get its graphics to work by wiring up spare change appropriately.

The II GS used a custom ASIC for it video.

Those are all "retro", so I don't see how introducing something like a Parallax is some great breach of etiquette.

If I've learned anything on these forums, graphics is hard. VGA is very expensive (and thus not suited well to slow 8 bit machines).

What I have not seen (and I've not looked strongly for it) is something like the Parallax using shared memory to where the screen is memory mapped vs treated as a slave device that's streamed though either a serial or parallel protocol.

My weak hope is at best using a terminal that supports ReGIS and getting graphics that way, other than that it's 16 color ANSI terminal glory.

It's probably worth taking a step back and considering what you *really* need your display to do.

If you're trying to make a retro-style game system with full-motion, full-colour graphics, then yes you're going to need a full-bore video output that's compatible with an existing TV or other external display. I recommend looking into what a VRAM chip and a 6845 can do for you in that respect. A slightly cheaty option might be to obtain an old ISA-based PC graphics card, and drive that. ISA is basically an extension of the i8086/i8088 bus. But most people wanting to make games these days will go for newer and far more capable hardware (like a Raspberry Pi), unless they're trying to directly recreate some older machine.

More commonly, when people say "I want video output", what they really mean is "I want high-resolution graphics", and the refresh rate matters much less. In that case, you can look at LCDs and e-Ink displays, which can commonly be driven over SPI, and have their own internal memories and refresh circuitry so that there is very little parasitic load on the host computer. Some e-Ink displays are very slow to refresh when driven in the documented manner, but there are usually ways to greatly speed that up so that real-time refreshing of a timer display or other status information can be done sensibly, or you can use it as an interactive terminal without any real difficulty. A downside to many of these displays is that they're monochrome or support only very limited colour, but a bit of searching might reveal more capable options, such as: https://learn.adafruit.com/adafruit-3-5 ... -breakout/ which has both SPI and 8-bit interfaces.

Yet another option is to use hardcopy as an output, as many early computers did. You should probably also fit a low-capability status display, such as a 40x4 character LCD, to keep your running costs down when the high-resolution output isn't needed. With that done, you can attach a thermal receipt printer over a serial port, like this one: https://www.adafruit.com/product/2751 - that gives you a 384-pixel-wide strip of continuous graphics output; 50% more vertical pixels than will fit on a non-interlaced TV screen, if you turn the paper sideways. Or you could get an old dot-matrix or inkjet printer (depending on your tolerance for noise) and attach it via parallel port.

Is your meaning that the 6845 or 6847 or 9918 chips are no longer being made? (One can presumably still get them, but not new.) Would FPGA remakes be acceptable? Perhaps the "truly authentic retro" is a very personal equation as to what feels authentic, which is different for each of us.

Edit: this project uses a 9918 and might be of interest. It looks pretty retro to me!

Yea, everyone has a different idea what they want.

That's a nice display, but that LCD is 460K of data. How many "Seconds per frame" would that be to send full frames on a 2Mhz 6502?

We see how difficult it is getting an 80x25 display of just text on a display from a small micro. (I tried looking at some Apple 80 col card schematics, and the ones I saw seem to be all RAM, so I dunno exactly what/how they do what they do.)
Do an AIM-65 clone.

Wire up your own keyboard, tack on the LCD, and you have your handy printer. Does anyone know if you can just stream ascii to a modern USB printer and just get pages of text like the old days? I honestly have no idea how that works and, naturally, there are no printer programming manuals any more. It's all black boxed by drivers.

In the old days, we has PCL and Postscript for printers. PCL printers (i.e. random HP laser printers) you could just dump text and Form Feeds and get pages. If you wanted more, the magic escape sequences would give you full control. Postscript, you had to always send it a Postscript program to layout the page.

Just curious if the modern ink jet/laser printers still worked that way. "cat text.file > /dev/usb-with-printer" would work or not.

Anyway, distraction...

I think a lot of the cheap printers now are like winmodems inside - they only accept bitmaps, generally in some goofy proprietary compressed format, on the assumption that the host PC can do a better job of rendering in typical "modern" use cases. I haven't kept track of how well CUPS keeps up with that, but that would be your first point of reference. There's also the more immediate problem of simply attaching a USB slave device to an 8-bit micro.

Receipt printers, though, still seem to implement recognisable standards from the old days, probably for mutual compatibility with existing POS terminals. For the same reason, many of them are still available with serial and parallel interfaces, as well as newer options like USB, bluetooth, Ethernet.

You can still get replacement ink cartridges for ancient Canon bubblejets and Epson dot-matrixes, because they just keep working, and *they* still have interfaces that are convenient for hacking on.
I calculate 307,200 bytes if you send 16-bit RGB565 pixels, and it'll accept writes at up to 20MHz with timings that seem convenient for the 65xx bus. Yes, that'll take a while to refresh if you drive it naively, but it does support hardware scrolling - so for a terminal-type application, you won't need to redraw the entire screen every time, and it'll be fast enough for interactive typing. There are probably also hardware tricks you can pull to expand one CPU byte write into a complete 18-bit pixel or eight, by interposing a CLUT, if speed is sufficiently important; it can almost certainly be driven much faster by acceleration hardware than by the CPU itself.

Going to stop thinking out loud here. Thanks for the feedback so-far though.

But to wrap this up for now:

I'm happy with my current video solution. I described it as hard - which to me means 2 things - one is hard to get old chips without resorting to e.g. ebay an so on. The other is that it's "hard" in that getting the balance between sticking a Pi on it, using a parallax/fpga or a raft of ttl vs. what I actually need and the "rerto" feel I want. That's is a tricky thing to resolve.

I'm not trying to make a game system, although I might code up/port a few older games for it.

Thanks for the other display suggestions - I have experience of many over the years e.g. SPI https://youtu.be/tlJ4NnV3RJY character LCD displays https://projects.drogon.net/raspberry-p ... d-library/ and some parallel access LCD displays, to lamps and switches, so safe to say I'm very comfortable with many ways forward and happy with my current choice.

Yes, I would like 1080p full colour, but the practicalities of that on an 8/16 bit micro simply don't justify it.

Did someone say noise and dot-matrix? Once upon a time I wrote some code to dump Apple II hires images to a Paper Tiger dot matrix printer. Loudest printer I've ever used )-:

The first "micro" I used was the Apple II - in 1978. (Prior to that; HP9830A with a 1-line LED display + thermal printer, then TTY33 + dial-up BASIC to the local computing centre) So maybe it's those early Apple II memories I'm after (even though today I own several Apple IIs and a //c - never got a //gs though) I have designed and built several 6502 systems in the past too - while doing research at university in the early to mid 80's. I used them as "microcontrollers" to do factory automation & robotics which was my research area.

So I cobbled together a new 65c02 system recently but before putting the real effort into it (pcb + software) I thought about the '816 and here I am. It's a better match for the software system I want to implement on it, but presenting its own, different challenges which I think I now have a good grasp of and now have outlined a plan for the 816 system which I'll write up in another thread soon.

Cheers,

-Gordon