Hi Ken,

What you are proposing certainly looks interesting, and I'm sure I will learn a lot from it.

I just read about Wozniak's Sweet-16 approach to software development for the 6502 based Apple II, and that's quite a clever achievement. It's amazing though that from the software point of view alone, the concept is so simple that possibly many members of this forum could actually implement the same just as easily. I suppose that Wozniak was just the person with the right skills, in the right place, at the right time... and why not, with the right partner: the other Steve... They both made history.

About the "Digital" logic simulator, I have briefly had a look at the github repo and it looks to me that it's written in Java, but apparently packaged as a windows only app, which is a pity, unless I'm missing something. One of the strengths of Logisim was that it was multi-platform. According to the Digital manual it's interesting that it seems to be able to generate JEDEC files for the GAL16v8 (and presumably the modern ATF equivalents), but I'm unsure about how far this capability goes, specially compared with WinCUPL .

Please, can you elaborate a bit further about what "4 bit slice" means. I suppose this is obvious by other forum members, but I have researched the internet and didn't find anything conclusive. Do you mean an ALU of some kind, or a full processor? Is the concept of 'slice' something FPGA related? (Sorry for that, I'm not English native and mostly a software guy, still have everything to learn about hardware design and related vocabulary. You can just pm me if you don't feel the need to post this here. Thanks in advance

[Edit: corrected typo "Wozniak"]

> the concept is so simple that possibly many members of this forum could actually implement the same just as easily

Simple, but powerful, and perhaps novel. (Probably novel, but things are sometimes independently invented.) I think there's still something worth celebrating when something useful and simple is invented or discovered, even if in hindsight it seems obvious. And it's worth celebrating when it's reinvented or rediscovered, I think, because there's the same spark of creativity in either case. "Ah, yes, how wonderful, that's called the Pythagorean theorem."

Hi Joan,

Regarding "Digital" my understanding from the Installation notes was that it would run on any platform:



More information here: https://github.com/hneemann/Digital

The term Bitslice refers to the way in which the overall architecture has been partitioned, mostly as a convenient method of simplifying the physical design.

The best place to start with this idea is with the ALU. For logical operations such as AND, OR, XOR these could be done using huge logic gate structures, say with 2 x 16 inputs, but since the bitwise logical operations can be done in isolation with no inputs other than the two bits being operated on (eg A3 and B3) then for convenience we can produce a 16-bit logic unit that consists of four identical 4-bit units placed side by side.

If we want to do addition, we would invariably start with a 4 bit adder (eg 74xx283) and build up the logic to support 4-bit addition feeding it with 4-bits from the accumulator and 4 bits from the data bus, with only the CarryOut signal being passed on to the next stage to the left.

You might wish to have a look at Dieter Muller's excellent article on ALU design to get a better idea of what I am proposing. http://www.6502.org/users/dieter/a1/a1_4.htm

So my intended ALU is based on Dieter's design, built as a 4-bit wide modular design. As the module contains only 5 or 6 ICs it is very manageable to build and test.

Now extending this idea further, we can identify the other logic entities that need to be closely connected to the ALU. This includes the accumulator, the program counter and the register file. Again these devices are generally available as 4-bit wide TTL devices 74xx173 for the accumulator and other registers, 74xx161 for the program counter, and 74xx670 for a small 4-bit wide x 4 word register file. Again these devices use mostly "local" signals, with only control and carry signals being shared with adjacent modules. Again this makes of a simpler practical design.

Historically the PDP-8 was a bitslice design - consisting of twelve 1-bit slices, placed on 12 adjacent pcbs. Each slice held 1-bit of ALU, memory address register, memory buffer and program counter. If there was a fault on the machine, a single pcb slice could be exchanged for a working one.

I have set up a repository for my "Digital" sketches - which as the project progresses will document the various aspects of the design https://github.com/monsonite/Suite-16

Finally, onto Wozniak's "Sweet-16". Yes I agree, he was in the right place at the right time - and with a problem of performing 16-bit operations, on what was essentially a fairly resource limited 8-bit processor. Creating a 16-bit virtual machine, created an additional layer of abstraction, which made the task of programming easier. It's very similar to what Marcel has implemented on the Gigatron with his vCPU.

What I liked about the architecture, is that it extends from an "accumulator" machine, to an "accumulator plus 15 registers" machine. Whilst operations are still centred on the accumulator, the other operand can be locally available register, rather than an operand supplied from memory. This means that there is less requirement for memory accesses, and the overall speed of processing should be faster, with less memory access.

The architecture does not permit true register to register operations eg. ADD R5,R6 (as the MSP430 and almost all modern processors do) All operations have to go through the accumulator R0. However the register used as the 2nd operand can be defined as 4 bits within the 8-bit instruction width, and this leads to much simpler decoding, fewer ICs and a more efficient use of 8-bit memory for instructions. It also makes the assembly language a lot simpler to read with the ALU operation coded in the upper 4 bits and the register coded in the lower 4 bits.

There's a good article on Sweet-16 over on the 6502.org

http://www.6502.org/source/interpreters/sweet16.htm

I'm going to use the Sweet-16 instruction set as a guide, but not rigidly adhere to all the same operations. As usual it will be a trade-off between useful instructions and hardware complexity. I'd like to introduce some compare, right-shift, and INC, DEC operations, and reduce some of the conditional branches, to leave space for set and clear carry. ( A bit like the "operate" instructions on the PDP-8).

Suite-16 is a work in progress, but the basics are just starting to come together. The project has been intended as a "brain-stretching" exercise, which will get me more involved over the next year in logic simulation, verilog and FPGAs, TTL breadboarding and software development.

regards


Ken

Edit: Corrected the wrong link to Sweet-16

Interesting! I'd always (mistakenly) associated the term with the 4 bit wide 2900 (doubtless because that's where I first heard it). (Edit: I see there were a fair few bitslice chip offerings.)

Joan,

Wikipedia has an entry under "Bit-Slicing" which explains it well and has examples of historical cpus that have used the technique.

https://en.wikipedia.org/wiki/Bit_slicing

I have estimated that my design will have approximately 64 ICs in the ALU, registers and memory addressing section, and perhaps another 16 in the control and memory section. Being able to build four identical "ALU" slice boards with just 16 ICs each, makes the design a whole lot simpler, and hopefully avoids a rats-nest of wiring.

Whilst I would like to make something like an MSP430, my reservation is that the amount of logic to allow fully orthogonal register to register operations would be over ambitious, and probably result in the design never being built. By restricting the design to "accumulator-register" I feel more confident that it is within my capabilities for this first project. When I get to be more adventurous, I can put TTL to one side, and move into the possibilities offered by FPGA design.

(Oh, also EDSAC-2, from 1958, about which there's a nice design paper - see this post)

Hi Ken,
Thanks for your comprehensive reply and links.
One of the most interesting aspects to me about the Sweet-16 is that, to a great extent, native 6502 instructions can be mixed with Sweet-16 code. The start of Sweet-16 code is 'signaled' by a special subroutine call, the following bytes correspond to Sweet-16 code. There's a Sweet-16 instruction to return execution to the normal 6502 code which just follows the Sweet-16 code. Isn't that clever?. But of course this is pretty easy to do because it's only a matter to set the Sweet-16 Program Counter to the contents of the 6502 Stack Pointer at the starting call, and load the 6502 stack with the Sweet-16 PC just before returning from sweet. Which results in the best of both worlds, 8 bit native 6502 architecture intermixed with powerful 16 bit instructions.

A nice thing about the escape mechanism is that the original sweet-16 doesn't have to have quite all of the machinery an instruction set would usually have. I think. So any sweet 16 hardware CPU might well need to extend things a bit, for convenience.

This is an interesting point. When I started to look and define my own 16 bit instruction set, I initially wanted to keep it as reduced as possible while keeping as much orthogonality as possible. However, things turned out that this was not possible unless I allowed variable instruction lengths, or reduced the set to a really small number of instructions with many limitations. One key point to decide is whether 8 bit arithmetic, or at least 8 bit memory access, should be supported or not on a 16 bit architecture. That alone increases the number of required instructions by not a meaningless amount, specially if unsigned and signed arithmetic for less-than-one-word sized data is considered as well. Next, there's the subject of finding the right set of addressing modes, and make them fit in the smaller as possible encoding space. I found that many hobbyist or conceptual/academic instruction sets just avoid operations with operands smaller than a word for simplicity reasons. Ultimately, it all depends on what you want to do with the instruction set.

So yes, my understanding is also that the Sweet-16 in its original conception is a design that is able to overlook the above constraints by "escaping" to native 6502 code when required