Somewhat non sequitur, I have received yet another gentle encouragement from the Forth mailing list to complete the Kestrel computer design concept. So, why is this in the Nostalgia department?

It's because the Jupiter Ace is what inspired me, so many years ago, to try building my own computer in the first place. Well, that and the commercial politics of the PC industry at the time. I originally decided to make it a Super-Ace, with the 65816 processor replacing the Z80A, support for more memory, higher resolution display (VGA, specifically), etc.

The specs kind of grew after that, encompassing all sorts of featuritis.

So, in the interest of finally delivering on a Kestrel concept sometime before I pass on, I thought I should go back to its roots. A 5MHz 65816 with 96K of RAM installed (32K dictionary space, 32K character matrix, and 32K for font bitmaps, each in their own bank). I was toying with the idea of installing a 4th 32K segment, to hold color video attributes. It doesn't seem like it should be that hard to add. A single expansion connector would allow for memory expansion up to somewhere in the vicinity of 15MB if you were so inclined. 64x60 character matrix on a VGA display. Programmable fonts can be used to fake out a 512x480 bitmapped display.

Connectivity to the external world would occur primarily through one or two 65SIB ports and a free 6522 serving parallel I/O to the rest of the world.

Host operating system would be a dialect of ANS Forth.

Sounds interesting, question though, if you have 92Kbytes of RAM already defined in use would you not need more RAM for the user's programs, or did you mean ROM not RAM?

Dimitri

The memory map would be laid out so as to minimize address decoding logic, because when I first conceived of the Kestrel, I was going to build it with discrete logic (and may still do so).



So, three separate 32K RAM regions equals 96K of RAM total. 32K is used for Forth, 32K for the character matrix (4K at any given time, though; the screen would display only 64x60 8x8 characters), and 32K for the character generator.

Since the character matrix RAM data lines directly drives the character generator's address bus (as it does in the Jupiter Ace), it follows that any CPU access to either RAM block will yield snow on the screen. An I/O register or two would be used to prevent this from happening. I was thinking of borrowing the Atari's approach of having registers which, when accessed, brings RDY low until the next HSYNC or VSYNC, depending on the register.

I was kicking around the idea of adding character attribute RAM (another 32K chunk at $030000-$037FFF) allowing each character to have its own foreground and background color, a la PCs in text-mode.

In any event, I'd declare memory space from $040000-$FFFFFF available for external expansion.

Upon further reflection, maybe I misunderstood your question.

As long as the core of Forth exists in ROM, 32K should prove plenty big enough for most applications you'd throw on a 65816 at such slow speeds. That would include things like games, basic text editing, etc.

Forth, characteristically, can be used in two modes of operation. The first is what I call "System/360" mode, where you pre-load all the applications you think you'll need at boot-up, and invoke their words as-needed (just as you'd "load" your applications on a S/360 environment as a separate step prior to invoking them at the shell). The other approach chooses to structure code as a system of overlays, and this is the approach that Chuck Moore uses (in fact, of all his Forth implementations, ColorForth is the first which seems optimized for this mode of use). Interestingly, it's also the approach that the Palm Pilot uses.

So, I think I can get away with 32K for some time to come, as long as I have a fast enough storage device to work with. I was planning on MMC cards for bulk storage, but I might switch to a more generic interface so that I can couple a PC or physical hard-drive as well.

16K seems like a lot to use for I/O. Even with page-by-page decoding, a 4K I/O block can accommodate 16 devices.

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

True; however, my intent was to direct-couple CPU address lines to chip select inputs in an effort to minimize the amount of logic I have to work with.

Well, not to be an advocate for PLDs or anything, but perhaps you could aggregate your logic into a single CPLD and easily gain more fine-grained I/O decoding.

Something that I've often ruminated about is the idea of developing a standardized 65Cxx compatible expansion bus a la PCI, but with less complexity than the latter. I could envision where a CPLD would control this bus in a fashion similar to the way the chipset on an industry standard PC motherboard controls the slots.

Several others have at one time or another written about adapting ISA hardware to the 65Cxx family. I see that as letting the tail wag the dog. Better to develop a 65Cxx-centric interface that would automatically assign interrupts and I/O addresses, etc. Just thinking out loud and not trying to hijack your topic.

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

Makes sense that is what I was confused about as you mentioned it being space for Forth so I was unsure that it also meant space for programs made in Forth.

Dimitri

I don't have CPLD programming technology here yet, and probably won't until after Christmas.



I've tried, and the end result of every simplified bus has always ended up being PCI-like in some capacity. The only way I can think of to simplify PCI is to go back to NuBus-style geographically addressed slots. (BTW, NuBus specs are the simplest bus specifications I've ever read. You might find them interesting.) Simplify it further, and you end up with a 6502/65816-specific bus.



I believe I have a topic on this elsewhere on this forum, but I'm not of a mind to look for it now. I agree -- I definitely want a high-speed expansion system that is CPU independent, multi-master capable, and yet not hostile to the 6502/65816. I was thinking of resurrecting a proper subset of NuBus for my 65816- and Forth-CPU machines.

I believe by "NuBus" you're referring to the IEEE 1196 standard from the late 1980s, which I dimly recall (these days, I "dimly" recall a lot of things—part of being an old geezer, I guess). It anticipated PCI by several years.

IEEE 1196 was intended to be completely system-agnostic, whereas PCI, which an Intel product, isn't. The problem, of course, with an agnostic bus like IEEE 1196 is specialized hardware has to present at both ends of the bus to adapt the expansion hardware to the base system, unavoidably driving up the cost and the complexity. I don't think more cost and complication is what we 65xx hobbyists want for our creations.

What I was ruminating about was a 65Cxx-oriented expansion bus that would require minimal logic on the expansion cards, with the serious logic grunt-work being performed on the motherboard end of the bus by a CPLD or FPGA. It should, in theory, be possible to run the bus synchronously with Ø2, with the CPLD/FPGA inserting wait-states as needed to control a slow card. At the Ø2 clock rates possible with 65Cxx hardware, such an arrangement should be practical.

The IEEE 1196 implementation was for a 32 bit bus, which I think would be overkill with the stuff we tinker with. A 16 bit address and 8 bit data bus should work fine, which would maintain compatibility with a 65C02 system. The bus logic would translate bus addresses to addresses the MPU would understand and vice versa.

As far as interrupts, I/O addresses and such go, these are all details that would have to be worked out in the bus logic, a la PCI. Again, this should be possible with a reasonable number of expansion slots.

This is all out-loud thinking, of course.

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

Actually, it is. The only homage to Intel-specificity is its support for distinct I/O and memory spaces. Considering this thing came from Intel, I'm rather in awe of it. It's a good bus.



The problem is, whose phase-2? I might choose 5MHz, while you might chose 15MHz.

This is why I prefer asynchronous bus handshakes.



I did say a subset of Nubus, did I not? If not, I intended it.



If all you care about is pure I/O expansion, that should suffice; I want memory expansion and DMA as well, though. I also have a desire to equip the system with other CPU types too, not just 65816 (e.g., 32-bit Forth CPUs). I would need the full 24-bit address bus exposed, at the very least.

It sounds to me like what you want is the Apple II bus standard, suitably specified so as to handle higher clock speeds, whereas I'm looking for something a bit more generic. I don't think we'll agree on our respective designs.