For aesthetic reasons, I prefer not to use CPLD or similar programmable parts... I know, I know, and perhaps one day... counting lines is something I don't need to do since the rom which is shadowing the video ram is basically one huge unrolled loop and the vertical blanking/sync period just uses a timing line somewhere above $7000 to ensure it doesn't output anything.

Yes, the obvious way to do it is to ignore the UART and use something self-contained, perhaps driven by SPI through the 6522. Using a similar idea with a 40MHz clock (and sixty k of video ram for 800 x 600) would give a 5MHz 6502 for the heavy lifting, though it would need some sort of paging as well.



Neil

Here's the memory map of the main processor (active when phx = 1):

• ram 0000-7fff (of which 4000-7000 is video ram shared with the VIC processor)
• uart a000-afff (lots of repetition)
• via b000-bfff (also lots of repetition)
• eeprom c000-ffff (A14 = phx so main processor sees the top half of the eeprom; the bottom half provides code for the VIC)

And for the VIC processor:

• ram 0000-07ff (4000-47ff in the main processor space)
• i/o 0000-0003 (somewhat repeated) write only sync flip-flops
• eeprom 0800-3fff (0800-3000 is active picture area, 41 bytes per line)

The VIC memory is repeated four times, so that code which lives in a chip at c000 can be executed at 4000 to properly generate the video addresses and still see the stack and the reset vectors.

The decoding is, um, interesting... I think I remembered everything.

• The data, address, and RnW from each processor are tied together; phx controls BE on the main processor and the antiphase phy controls BE on the VIC.
• RnW is enabled only on the later half of each active write by gating with a multiple of the phx signal; E to the VIA is also gated the same way.
• The eeprom controls are n_promOE and n_promCE, tied together since it is never written to. ~WE is tied high.
• The ram controls are n_ramOE, n_ramCE, and n_ramWE; OE is valid when CE is active and WE isn't. Note that the ram OE is valid whenever phy is active (high) to permit reading the video ram data.
• A 245 bidirectional buffer permits the ram to see the data bus; A/B is controlled by RnW (might not need to be gated but for now it is) and the enable input is n_245CE.
• n_blanking is high whenever phy is high and the address is outside 0800 to 3000; this will be latched by the video data latch.
• n_uartCS and n_viaCS are valid only when phx is high.
• n_vsyncCS and n_hsyncCS are at the end of a long chain of decoders but they aren't needed until the end of the cycle so there should be no trouble there. They'll also write to the ram, but as we only use two bytes of ram for the stack that shouldn't be an issue either

Feel free to point out anything I've missed: I think this one has so many interesting options (and guessworks) that I'll break my usual rule and build at least a partial prototype before I commit to PCB.

Neil

Subject to some experimentation on a breadboard, this is probably a sort-of-nearly-almost-complete circuit.

Please feel free to rip it to shreds - but remember my aim is to use currently available non-NOS ttl-type logic.

Neil

And after about four hours of layout... it could use some improvements, I think, but I don't think there's anything to stop it working, if the design is right.

Neil

hmm, some thought about that PCB:

i recommend labeling all ICs and Pin Headers/Connectors on the silkscreen. mainly just to decrease the amount of times you would need to check the schematic when assembling, or when plugging stuff into connectors. (for chips like the VIA, it might be worth labeling each pin on the pin headers, PA0-PA7, PB0-PB7, etc)
i'd also recommend having multiple GND and Vcc pins on pin headers, as i sometimes found myself running short of those when connecting modules to my SBC's VIA IO pins.
Another thing, i would move the SMD decoupling caps to the center of their respective IC's footprint, as they easily fit below DIP sockets and save some space on the PCB. if you want to save more space you could move the bottom 12 ICs closer together, then move U7 down to the 12 ICs, so you can then put U19 next to U14, which then allows you to move the entire right egde of the board further left, making the PCB a tiny bit smaller which may save some money.

and lastly (this is more aesthetic), i would remove the silkscreen text for the mounting holes and replace the corners with rounded ones (i've come to love rounded PCBs). also i'd move all connectors (PS/2 and VGA) to the same edge of the board, so when you have everything plugged in you don't have cables going in every direction.

It is indeed a lot for me to take in! Hence, I haven't commented on it. Sorry. It's also become my rule to prototype/bodge before printing, but sometimes you just gotta try.

As for the board, I echo what Proxy says about the silkscreen. You have room, fill it up with all kinds of (useless) information! I put a full Bill of Materials on the board itself now, label EACH pin, include a short description of operations, and even doodle some pictures on there

I hadn't ever thought of rounded board edges, hm!

I would also say Proxy is right in putting all the cable connectors on one side. BUT, that doesn't mean it's right in every application. I see you have "input" on one side, and "output" on the other side. That could also work too, depending on your bench/desk setup. I have a very very cramped workdesk, I literally use a nightstand and a plastic kiddy chair for everything, so putting all the cables on one side is good for me to get them out of the way.

Looks good! Don't be afraid to make mistakes, and don't be afraid to fix those mistakes with surgery!

Chad

Thanks. Added labels are just something I haven't got around to yet; there will be some before it goes for printing.

Size is a standard Eurocard: 160 x 100mm which is a size I like; you're right, it could be smaller but the post from China will cost more than the circuit board anyway, so I'll keep that as it is. I may add a second minidin-6 so I can get perhaps enthusiastic with a PS/2 mouse at a later date. Not a fan of installing things under things; I find I tend to forget them. But it's a point to bear in mind...

But round corners? Nay, nay, and thrice nay! Not my cup of tea at all unless I'm trying to fit something into an Altoids tin

As for script on circuit boards: I have a commercial product out there wherein the inquisitive will find:
My name is Ozymandias, King of Kings,
Look upon my works, oh ye mighty, and despair...

Neil

You can hook up a keyboard and mouse to a single Mini-DIN-6 connector. You'd need a Keyboard/Mouse splitter, and of course the circuitry to run the additional pins into the VIA, but I always was one to consolidate parts on the board. Up to you, just a reminder that it exists

Chad

Yeah, I've seen the alternate wiring. Still just an idea at the moment. It's not like I'm short of a convenient space.

Neil

Rats, I just realised the video output will be inverted. Slight rethink is in order...

Neil

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

There's always one

Anyway, it's an easy fix and tidies up another bit that was missing an and gate and so got two nands in series instead...

Neil