That sounds like an interesting setup. I used to use 22v10 GALs, but got frustrated with the lack of I/O/Q pins, so moved to ATF1504AS's as they are how much more and work at 5V (which seems to be a bit uncommon these days as it's all going 3.3V and lower).
What do you use for video/keyboard or is it a serial console-only one? Mine is going to be the latter as my video implementations are not much better than Ben Eaters "worse video card in the world" one - and mostly this is about VIA type I/O at the moment.

_________________
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?

Serial to a "smart" terminal running on my Linux desktop. It understands Acorn MOS VDU commands so can draw lines, etc. There are some extensions I've added and it can do sprites, read the mouse, play BBC Micro sounds too.

The 'host processor' (and ATmega 1284p) is smart enough to recognise either the RubyTerm or an ANSI terminal and do conversions on the fly.

Simple graphics demo (C program on the 65C02): https://www.youtube.com/watch?v=rPGCT0lah4Q

On a real serial terminal: https://www.youtube.com/watch?v=Bg-DcjrJ8g0

I have a "graphics card" planned, but it will be along the lines of something that has a parallel port that you send commands to, so essentially a faster version of my smart serial RubyTerm..

Cheers,

-Gordon

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

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

Gonna jump into this thread a bit late, but I'm in initial design phases of a new SBC project and this directly affects some decisions I need to make.

Let's say I have a somewhat legit need to include at least one slot on my board (and ideally 2 or even 3). This would be (probably) card edge connectors on a four layer board, running at 4 MHz to start but ideally up to 14 or 16 in the future. What would be a good way to go about this? I was thinking of just buffering some of the bus lines to the expansion slots with 245s to keep the busses separated.

The reason for this, btw is primarily related to video. I really want my system to have VGA output at some point, but my last project ended up collapsing due to feature creep, so I am starting simpler. I want a system that by default has a serial console, but which leaves me the ability to build discrete video cards down the road. Thus, the slot(s).

^^ Seconded! Very interested to hear about this too. As I am in the same situation.

Much easier to design something in a modular approach than it is to just throw it all on to one board and hope it all works. At least in the proof of concept stages.

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

_________________
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?

That's the thing though. Building a VGA circuit is a whole field in itself.

I know there was mention of mounting external boards directly from header pins to reduce the path lengths, which is possibly a viable option as far as project separation goes.

In practice, does it make a huge difference? That's a serious question and not meant to come across as a 'smarty pants' type thing. You guys have a hell of a lot of experience under your belts and we are here to learn from the best.

I've read Garth's entire site a bajillionty times but the general takeway I've gotten is just "don't do it", not 'how do to this if you really need to".

Anyway I will start a new thread. I just posted here because it seemed relevant to the conversation and I feel like half the time starting a new thread just gets a "oh go over to this thread where we talked about that" reply.

Hmm, that's an interesting observation. I think it's most likely still worth a new thread, when building a unique new system with your own personal goals and tradeoffs. It wouldn't hurt, though, in that new head post, to note that you have read something or other, and provide links to the things you've read.

That way, whatever the outcome of the thread, it serves nicely when someone else finds it when searching, trying to do something similar.

Oops, okay -- I overlooked that aspect. But FWIW here's a mod that achieves both goals. Variations are possible.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Ok here's the latest and greatest version. I haven't yet sorted the RAM/ROM header pins out, but I'll do that probably over the weekend - along the lines of Garth's memory card pin out and also Jeff's suggestion.

Changes are mostly cleaning things up and making corrections, but here's a few explanatory notes

1) *I've moved the IRQ arbitration out of the ATF1504AS to an AND gate IC (IC2A/2B) allowing for some future expansion if I somehow manage to wangle some I/O into the ROM/RAM card (see below).
2) Lots of corrections as it was a rough design, and also plenty of modifications (and corrections) made thanks to the efforts of BDD.
3) As recommended by BDD, I've moved the banking in to the ATF1504AS and dumped the '573 and also swapped the ATF1504 for the 7ns version
4) Stripped out the RAM/ROM header connections and will be redoing those as stated above
5) Added in a GAL 22V10 to do the I/O and ROM arbitration - see below
6) Added in a proper 10 pin JTAG header with pullups
7) /PH2 renamed to PH1 as recommended by BDD

Memory & I/O decoding

The ATF1504AS deals with latching of the bank address bits in conjunction with PH1 being high, VDA being high, VPA being low. So if PHI1=1 & VDA=1 & VPA=0 then latch data bus.
If the bank is known to be entirely RAM then RAM0_SEL to RAM3_SEL are enabled on the ATF1504AS. I might play with the number of select lines, but at the moment it's 4.
If the bank is known to be the I/O and/or ROM bank (they can both be the same bank. i.e. bank 0) then RAM selects are disabled and IO_BANK and ROM_BANK lines are enabled.
These tell the address GAL to allow the I/O and/or ROM selects to be used based off of A15 to A8 (or possibly down to A5 depending on how many terms it can handle/are used).
*The GAL has 2 extra I/O / ROM lines which can be connected via fly lead. This allows for another seperate bank or two of ROM or VIA to be used on the RAM/ROM card. In the case of VIA then another fly lead can connect to the IRQ expansion headers on IC2A & 2B.
My concern about the above is the speed of the GAL as I think the best one I have is a -15. I might just pop in another ATF1504AS and then jumper the JTAG header.

[edit] * I might run the expansion selects/IRQ lines through the RAM/ROM header as really I doubt they will be used anywhere else which is practical. Trouble is, is the number of pins in the header keeps growing .

Here's the circuit (sorry it's a bit big, but if I shrink it down the text component labels start being unreadable):

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

Thanks for clearing up the VDA / VPA
Sorry I mispoke (mistyped?): I should have said that one of the RAM selects would be enabled out of the pool of 4.
The reason for the GAL is decoding the I/O as there are not enough pins to do it* on the ATF1504AS. Been looking around to find an ATF1504 with a prop delay of 7.5ns along with 84 pins - all seem to be out of stock/discontinued. The only 7.5ns one I can find is 44 pin. - at least in PLCC. So it looks like I'll have to go with the 10ns one (ATF1504AS-10JU84), but I'll keep looking just in case someone has some nos (new old stock).
By the way, those PLCC84 sockets are (naturally) huge .
Decoding lower than A8 was more a possibility - "if I leave the pins connected then I can always see what I can squeeze out of the GAL afterwards" type of thing. Wasn't really fussed. Anyway, GAL is not going to be used now.

* Pins required on the CPLD:
16 for D0-7 (in) & for A16-23 (out) - bank latch
2 for PHI1 & PH2 (in)
1 for RWB (in)
2 for RD & WD (out)
2 for VDA/VDP (in)
8 for A15-A8 (in) - used to determine IO and ROM select lines
3 for VIA0, VIA1 and SER select lines
2 for expansion I/O select lines
4 for RAM select lines
1 for ROM select line
----
41

Additionaly, I can move the IRQ arbitration back in:
1 for OPEN DRAIN (in)
1 for VIA0 (in)
1 for VIA1 (in)
1 for SER (in)
2 for expansion I/O (in)
1 IRQB (out)
----
7

So 48 I/O pins needed which is for the the 84 pin ATF1504AS-10JU84. Hopefully it'll have enough macro cells.