After all the helpful tips here in the forum, I've come up with a first parts list for the Übersquirrel Mark I, code named "Blue Maiden", a 65816 machine that I'm going to try to run with 3 V instead of 5 V to use more modern and larger chips. The idea is to primary run a still to be written 16-bit version of Forth ("Liara Forth") but to be flexible enough to boot other things with the swap of an SD card. Note there is still lots of hand-waving involved.

Core parts:

CPU: W65816-S6PG-14 (duh) I already have the DIP version here.

RAM: AS7C316096A 2 Mb SRAM 48 pin TSOP. Starts at Bank 0, glue logic magic maps ROM into lower 8 Kb.

ROM: AT27BV256 32 Kb PLCC 32 pin OTP. Use only 8 Kb, but with possible option (reprogram glue CPLD, jumpers?) to expand it to 16 or 32 Kb. Note this is one-time programmable only, but at less than three euros a chip, we can live with that; I'll just have to test the code in an emulator a lot. Contains boot routine, which loads OS to Bank 1 from SD card / mass storage (see below) or fails to a small monitor routine, and then only handles interrupts.

Clock can: 8 MHz or as fast as it will go with testing.

Glue Logic: ATF2500C-20PU Atmel CPLD 20 ns 24 pins in 40 pin DIP. This is the really hand-wavy part of the design, with a big label "stuff happens here" on it.

I/O:

I/O: XR68C192CJ DUART 44-pin PLCC. This has an additional 8-pin output to drive a LCD screen, see below. No use for the 7-pin (sic) input I can think of yet. Gets its own 3.6 MHz clock can so we can fool around with the system clock.

NHD-0420DZ-NSW-BBW LCD Display 20 x 4 with parallel input, hitched to the DUART. There is also a SPI version that could be attached to the 65SPI, but we have the DUART output port sitting around anyway and can put the SPI lines to other uses. Note this is a 5 V part, will have to figure out how to attach it. If it's too much trouble in the end, this can go.

6522 VIA for later expansion, all outputs/inputs go to sockets. Already have the DIP version here.

65SPI 44 pin PLCC for the peripherals, see next section.

SPI peripherals (8 lines available)

Mass Storage: S70FL01GS 128 MB Serial Flash RAM SPI. Get two of these (using four SPI lines) for total of 256 MB.

SD card sockets. Two of them, because life was always better with two floppies back in the day. One SPI line each. Since my "real" computers have SD card access, I should be able to write code there, stick the card in this computer and boot without all the messy EEROM stuff I'm doing now.

Real Time Clock. Haven't settled on the exact make yet. One SPI line.

One SPI line left for expansion, led out to a socket.

Case/outside:

I found a nice glass dome at during a trip to the furniture store with a big hole for warmth at the top to hold the computer. It's probably hard to judge the scale here, but it should fit one eurocard easily: The cables would come in through the back/bottom, possibly with a shield on the back. Not sure yet, but my desk is all dark wood, so I'd try to make it fit in. (Yes, I bought two domes for when this one breaks. You learn to buy spares when you have kids and a cat in the house.)

You'll notice there is nothing here for graphics except for the LCD screen, which will be more an indicator if included at all. While experimenting with the ÜSq Mark Zero, I learned that for some reason I have no interest at all in graphics, and so everything will be via DUART to a "terminal" (my old white plastic MacBook, which is expendable if I fry everything).

So that's the idea so far. I'd be most grateful for any feedback and suggestions. Will try to get a schematic in the next weeks, but probably won't happen before May. Back to the garden ...

(Oh, about the names: I like blue/white LCDs. Also, the "Tali" in Tali Forth has pretty much become a reference to Tali'Zorah vas Normandy, so at some point I started thinking of the "better, more advanced" 16-bit Forth as "Liara" Forth after Liara T'Soni, who of course is an Asari and therefore blue. If none of this makes any sense to you because you haven't spent hundreds of hours of your life playing Mass Effect, the summary is it's a horrible video game joke.)

"Under the Dome", eh?

For initial experimentation, see if you can acquire a couple of 27C256 erasable EPROMs. The ones I use are AMD parts rated for 55ns, and are functional on a 12.5 MHz Ø2 clock. Once your firmware is copacetic you can burn it into the OTPs and bump up Ø2 somewhat.

As the 68C192 is architecturally similar to the Phillips/NXP 26C92, the 16 bit driver that I developed for the latter should be adaptable to your unit. I have not studied the 68C192 in sufficient detail to identify any differences, other than the 16-deep FIFOs, which are like those of the NXP 28L92. However, since EXAR claims complete compatibility with the NXP 68692, which device is approximately the Motorola bus equivalent of the 26C92, I suspect the driver will run with little to no alteration. If you can use my driver you can save yourself a considerable amount of time in your firmware development.


You will need IP0 and IP1 if you wish to set up hardware handshaking to your serial devices. Software (Xon/Xoff) handshaking is generally unreliable above 9600 bps and should not be used. IP0 would be connected as CTSa and IP1 would be connected as CTSb. To complete the hookup, connect OP0 as RTSa and OP1 as RTSb. With this arrangement, you will have full bi-directional hardware handshaking, allowing you to run the UART channels as fast as you wish, subject of course to whether your system can process the data flow rate.

I would use a 65C22 to drive the LCD display, as manipulating its I/O bits is less work than doing the same with the UARTs OPx pins.

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

Almost forgot! You may find it useful to generate a jiffy IRQ in your system for timekeeping purposes. The counter/timer (C/T) in the 68C192 can be put to work for that purpose, as it is slaved from the 3.6864 MHz X1 clock that you will have to provide to the UART. One version of my driver includes the necessary code to set up the C/T for a 100 Hz jiffy IRQ, as well an interrupt handler to drive a software clock. Unlike using a timer in the 65C22 for this purpose, changes to Ø2 will not affect the IRQ rate in this configuration.

Speaking of the X1 clock, I recommend that you derive it from a can oscillator, not a crystal.

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

Thanks for the suggestions! I'll be sure to stea- ah, study your code. The idea so far is to first get a breadboarded 65816 working with "normal" 5V 32k RAM and 8K ROM -- stuff I have here already -- to get hands-on experience with the new addressing requirements, and to get the UART code working. Might include the 65SPI for further testing, if I can find the patience .
I was wondering about that, though more because there is 6522 code all over the place. Will change the design. I'm still somewhat on the fence with the LCD, seems a headache with 3V/5V and lots of code for something that will mainly be pretty. Will have to think about that some more.

Thanks again!

See attached. The source is written to be assembled in the Kowalski simulator's assembler but should be readily adaptable to another assembler with at least the same level of capability. The file ASSEMBLE_DRIVER.asm will assemble the mess and should be your reference for how to incorporate the code into your firmware.


As it won't be your primary display, I'd set the LCD aside and concentrate on getting a working and stable design in place. You can always add the bells, whistles and blinkenlights later on.

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

"Pretty" is nice -- and you're bound to learn something setting it up. But I agree with BDD that it's a feature that should maybe be left for later.

I don't think I ever mentioned my KK computer has a hookup for an LCD I'd managed to acquire. This was back in the days of the Radio Shack TRS-80 Model 100, and any sort of LCD was quite a novelty. Mine took a lot of effort to get working, much more than a modern one like yours with the controller built in. Anyway, like a few other significant KK features, it ended up never really being used.

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

BUMP! How's this project coming along?

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

Thank you for asking! I've been busy in the garden the last couple of weeks: We've expanded the veggie patch (14 m² now, though with 4 m² fallow at any given time) and moved about 3 m³ of soil in the processes (which I'm getting too old for). In other words, I haven't gotten jack done with the Übersquirrel, which is usually what happens in Summer.

Now that all that is finished (cover crops growing nicely, only some corn ("maize" for the Brits here) and carrots left to harvest) and the weather has finally turned rainy again, I'm planing on getting the Crude emulator to Alpha (aka "everything does something, even if it is the wrong thing") in this month, since for somewhat complex reasons I have three weeks of vacation while the kids are in school and my wife is busy working. I have learned the hard way that I need to get sub-projects to some kind of milestone or they will just sit that way on the hard drive for ever while I'm off chasing the next fun thing.

At the moment, I'm adding the stack system to the emulator.

After that I'll start ordering the parts and tools I'll be needing to get a 3V system to Free Run, which should teach me the 65816's pins as a first step. I've committed to try 3V instead of 5V, because the memory chips etc. that are available are so much larger. After Free Run, I'll try to get RAM and some form of ROM attached (still thinking about that), which will involve sub-projects like figuring which EEPROM to use for now. This will be the time to figure out CPLD or such for the glue logic, which involves more new stuff. This will be fun.

As an aside: Since joining the 6502 crowd here, I have learned that I tend towards getting all excited about software and have to force myself back to hardware-land if I want to ever actually build a machine. I have realized by now that the reason is probably that I tend to work in iterations, which is the way I write in my day-job as well: Get a first draft done, even it is is (to paraphrase Hemingway) crap, and then to make multiple passes over it. This definitely does not work with hardware, where everything needs to work perfectly before you flip the switch, or else you see the magic smoke. This is probably good mental discipline for me, but there is a reason I didn't end up designing space probes for Nasa .

I was warned off of this part (was it you, BDD? Cannot remember) as apparently the programmer is quite expensive. Do you have such a programmer? If so, can you advise which one?

Yep, that was me. The ATF2500 is just an overgrown GAL and is only supported by one or two programmers. Atmel's ATF150x series is a better choice and excepting the ATF1500, can be programmed via JTAG.

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

This one looks good: ATF1504AS
It's not only 5V, but is PLCC44 so can be used with the (rare and expensive) PLCC wire wrap sockets from RS

If you have enough real-estate on your circuit and prefer less expensive DIP wire wrap sockets you could as well use this

http://forum.6502.org/viewtopic.php?f=10&t=3276#p37947

TQFP-44 0.8mm pitch is very easy to solder by hand. I even use the normal soldering iron that I use for DIP, the only thing you need to respect is that flux is your best friend and solder wick can be used to remove hick-ups.

That's the animal that will be in POC V2. You should be able to build some pretty fancy logic with 64 macrocells.

Here's a suggestion that should make it easier for you to come up with a design that will fit the CPLD. Leave most of your PIN statements in your design file "blank," meaning without numbers. The only pins that have to be committed to a particular circuit (aside from Vcc and Gnd) are:

Code:

Pin  1 — Active low reset; also connected to RWB on your MPU.
Pin  7 — JTAG TDI signal.
Pin 13 — JTAG TMS signal.
Pin 32 — JTAG TCK signal.
Pin 38 — JTAG TDO signal.
Pin 43 — Ø2 clock signal, also connected to Ø2 on the MPU (pin 37).

Your PIN assignments for the above would be:

Code:

pin  1    = RESB;                                 /* system reset              */
pin 43    = PHI2;                                 /* system clock              */

Note that no mention of the JTAG pins should be made in the design file. The compiler will understand that to mean that those pins have been reserved for JTAG purposes and will not attempt to use them.

"Uncommitted" PIN assignments are of the general form:

Code:

pin       = RWB;                                  /* read/write                */
pin       = VPA;                                  /* valid instruction address */
pin       = VDA;                                  /* valid data address        */

Note the absence of pin numbers. When your design successfully compiles, pin numbers will be assigned during the fit phase and the assignments will be listed in the .fit file that will be generated by the fitter. In my particular case, .fit reported:

Code:

                                 R    P
                        R  V  A  E V  H  G  A  A
                  W  R  O  C  1  S P  I  N  1  1
                  D  D  M  C  2  B B  2  D  1  0
               ____________________________________
              /   6  5  4  3  2  1 44 43 42 41 40  \
         TDI |  7                                39 | A9
          D2 |  8                                38 | TDO
          D1 |  9                                37 | A8
         GND | 10                                36 |
          D0 | 11                                35 | VCC
         IO0 | 12            ATF1504             34 | VDA
         TMS | 13          44-Lead PLCC          33 | VPA
         RAM | 14                                32 | TCK
         VCC | 15                                31 | A18
         RDY | 16                                30 | GND
         IO1 | 17                                29 | A16
             |   18 19 20 21 22 23 24 25 26 27 28   |
              \____________________________________/
                 I  A  I  I  G  V  A  A  A  R  R
                 O  1  O  O  N  C  1  1  1  W  S
                 3  7  2  4  D  C  3  4  5  B  T

In addition to the above, I included the following PROPERTY statements in my design file:

Code:

property   atmel {cascade_logic=on};
property   atmel {logic_doubling=on};
property   atmel {output_fast=on};
property   atmel {pin_keep=off};
property   atmel {preassign=keep};
property   atmel {security=off};
property   atmel {xor_synthesis=on};

Lastly, the correct DEVICE to use is:

Code:

Device      f1504ispplcc44;

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

That ATF1504 looks lost on that board. Clever design.

I have not tried manually soldering the TQFP package but having acquired a gently used Proctor-Silex commercial grade toaster-oven, am eventually going to get the hang of reflow soldering.

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

So, when is it going to be up and running?

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