Starting with my first SBC Project, Plans and Confusions

[BigDumbDinosaur]

Proxy wrote:

I've been procastinating by mostly gaming but also by making this:

soffice.bin_2020-04-03_19-22-19.png

it should be kinda self explanatory. (i tried to avoid using too many or any colors. so it's mostly black/gray/white)

What's with all the 'X'es in the column and row headings?

Quote:

the only thing holding me back from ordering all the stuff is fear that i somehow still missed something... and i don't know how to work against that.

Fixing layout mistakes is why bodge wire was invented.

[Proxy]

Chromatix wrote:

Interesting instruction tables. In the one for transfers, don't forget the stack as a memory addressing mode.

I would try structuring the opcode table with a different grouping of bits, which better reflects the way opcodes are internally decoded by the 6502. Broadly speaking there is an aaabbbcc pattern, which gets confused if you make the table "square" with an xxxxyyyy pattern. I think it makes sense to have rows with the aaa000cc bits, and columns with 000bbb00 bits.

the site i linked before actually has those tables like that, and while it is kinda neat to look at... it's much less convenient, harder to understand/use (especailly if you're new to the CPU), and much less compact (you would need to scroll a lot to actually use it).
there is a reason this xxxxyyyy way of ordering Opcodes is so common with 8 bit CPUs (including the 6502, as said even the offical datasheet does it like this (page 10)). it's just that good.

BigDumbDinosaur wrote:

What's with all the 'X'es in the column and row headings?

the X basically means "don't care", its common to have the top be the low nibble of the opcode, and the side the high nibble.
other sites like these just use a 0 to represent the same thing, which i could do as well....
for example "AND zpg", you go to the left and it says "2X", you go to the top and it says "X5",
then you just add them together in your head:

Code: Select all

  2X
  X5
= 25

there you go that's the opcode. (in hex of course)

BigDumbDinosaur wrote:

Fixing layout mistakes is why bodge wire was invented.

yea that is true, but cutting PCB traces is hard when you don't got an exacto knife.

[BigDumbDinosaur]

Proxy wrote:

BigDumbDinosaur wrote:

What's with all the 'X'es in the column and row headings?

the X basically means "don't care", its common to have the top be the low nibble of the opcode, and the side the high nibble.

I know how to read an opcode table. It's the first time I've ever seen that sort of representation. Just about every opcode table I've perused in the last 50-odd years that refers to byte-size opcodes has a single digit in the headings. The opcode tables in the 65C02 and 65C816 data sheets are a good example.

Quote:

BigDumbDinosaur wrote:

Fixing layout mistakes is why bodge wire was invented.

yea that is true, but cutting PCB traces is hard when you don't got an exacto knife.

In the past when I had to make an emergency patch to a PCB I would use the corner of a small blade screwdriver to sever a trace. It wasn't quite as refined as using an X-Acto knife but did the job.

[Proxy]

BigDumbDinosaur wrote:

I know how to read an opcode table. It's the first time I've ever seen that sort of representation. Just about every opcode table I've perused in the last 50-odd years that refers to byte-size opcodes has a single digit in the headings. The opcode tables in the 65C02 and 65C816 data sheets are a good example.

well but then how would you know what is the upper nibble and what the lower nibble of the opcode?
i guess a good way would be something like this?

[cbscpe]

Nice project, I was just reading through and I learned something very useful, especially about the FT240X. This one will definitively go into my next 6502 project. No UART (buggy 65C51) required. Although I might have to add an interrupt controller.

Here some information about those mysterious special purpose input signals of the ATF1504 and other good to know things I always keep in mind when using CPLDs.

A CPLD is like a collection of GALs. The ATF1504 may be looked as four "40V16 GALs" (meaning you have a GAL with 40 inputs and 16 outputs, analog to the notation of 16V8 or 22V10). They are called "Blocks". However in the case of the CPLD you may use all inputs and outputs at the same time. Not like a 22V10 where using more than 12 inputs reduces the number of available outputs. In addition the internal GALs have some feedback logic. That is signals generated in a Block can bee feed back to the same block without using one of your 40 inputs. The 40 inputs selected from all possible signals using an input matrix attached to each block. You can see a report of the inputs selected by each block in the fitter report. This is called FAN-IN and is a limitation you cannot exceed. On the other hand no all outputs of the macrocells of a block are connected to a PIN. In the case of a ATF1504 in PLCC-44 or TQFP-44 eight macrocells are connected to PINs. This connection is not configurable (contrary to other CPLDs which also have an output matrix). So you need to be careful which pin is used as output for complex equations. I will come back to this later.

Also very important to know is that each macrocell has only five product terms. In a GAL22V10 you have between 8 to 16 product terms per output logic macro cell. If you need more product terms for an output you can either borrow product terms for the macrocell "above" from the same block. This requires that the macrocell above is not allocated to an output and is not in a different block. E.g. MC17 cannot borrow product terms from MC16. Also you can borrow product terms only for one equations.

Each macrocell has many configuration option. You can use product terms for boolean logic only, or in case you configure the macrocell as a register you can use product terms for clock, output enable, input, asynchoronous set and reset.

The global signals have the advantage that they do not consume any product term in a macrocell when they are used as a single input (e.g. not part of an equition for the .ar .oe or .ck input of a macorcell) and they do also not consume any input of the input matrix (do not count for the FAN-In signal). In other words using global signals can save a lot of product terms.

Global clocks are special as a registered macrocell has can also have a .ce (clock enable input) when the .ck (clock) input uses a global clock. This is often need in sychronous logic.

Statemachines can use any clock input. There is no need to use a global clock. However when you use a global clock you save a product term which may result that even large statemachines fit into the CPLD without feedback signals or borrowing product terms from the macrocell above.

As an example if you build a multiplexor with a tri-state output you can multiplex 5 input signals of you use a global output enable without using product terms for other macrocells. Else you can only multiplex 4 signals. You can always multiplex more signals, but that will use additional macrocells.

CPLD also support bidirectional pins. In this case you must refer to the .io extension of the pin-name, else it will use the internal value of the output of the macrocell (the tristate buffer comes after the output).

Peter

[cjs]

BigDumbDinosaur wrote:

Proxy wrote:

the X basically means "don't care"...

I know how to read an opcode table. :D It's the first time I've ever seen that sort of representation. Just about every opcode table I've perused in the last 50-odd years that refers to byte-size opcodes has a single digit in the headings.

I've seen the 'Ax' and 'x3' labels in other opcode tables (oxyron's for example), and I very much like it when they do that. It lets me immediately see which direction to read it in, which is handy because I certainly will never memorize the particular (and differing) directions for the various tables I use from time to time. So Proxy, I recommend you keep doing that!

[Chromatix]

If you'll excuse the colour coding, the attached is what happens when you do as I suggested. Large parts of the opcode map start to look organised.

[Proxy]

Chromatix wrote:

If you'll excuse the colour coding, the attached is what happens when you do as I suggested. Large parts of the opcode map start to look organised.

while yes the opcodes are ordered, the numbers are now scrambled, making it harder to actually read....
just stick to the standard Opcode matrix/table that has been used from the start... it's common, and it works across different CPUs.

though i guess it's useful for finding what hex value a specific instruction has,
while the regular opcode table is more useful to find what instruction matches a given hex value.

so they kinda complete eachother...

[Chromatix]

Maybe this one is a bit easier to read, with extra header rows where the last digit changes:

[Proxy]

Chromatix wrote:

Maybe this one is a bit easier to read, with extra header rows where the last digit changes:

not bad, but i got a much beetter idea

basically you just have the 8 bit opcode split into 3 parts... so all you need is a table with 3 axes!
this means in order to properly display all opcodes and numbers in a ordered way you need a 3 Dimensional Table/Matrix, easy as that.

[BigDumbDinosaur]

cjs wrote:

BigDumbDinosaur wrote:

Proxy wrote:

the X basically means "don't care"...

I know how to read an opcode table. It's the first time I've ever seen that sort of representation. Just about every opcode table I've perused in the last 50-odd years that refers to byte-size opcodes has a single digit in the headings.

I've seen the 'Ax' and 'x3' labels in other opcode tables (oxyron's for example), and I very much like it when they do that. It lets me immediately see which direction to read it in, which is handy because I certainly will never memorize the particular (and differing) directions for the various tables I use from time to time. So Proxy, I recommend you keep doing that!

I have never seen such a thing in any official microprocessor data sheet and find it unnecessary and somewhat distracting. As long as I've been working with this stuff, convention has been like that seen on page 22 of the 65C02 data sheet.

[cjs]

BigDumbDinosaur wrote:

As long as I've been working with this stuff, convention has been like that seen on page 22 of the 65C02 data sheet.

But surely you must be glad that the original data sheet convention for the instruction table (used not only by MOS/Commodore for the 6502, but by Motorola for the 6800, among others) wasn't forced on Rockwell and WDC, so that you can have this format you like, too, right?

I personally find it a bit weird that in this format one looks at the numbers on the right to get the left-hand digit, and then the column of numbers on the left to get the right-hand digit. I'm sure you get used to it if you use it regularly don't use tables that are the other way around.

Chromatix wrote:

If you'll excuse the colour coding, the attached is what happens when you do as I suggested. Large parts of the opcode map start to look organised.

That really does bring out the opcode organization. Nice work.

In some recent Apple II hacking using the Autostart ROM (i.e., no mini-assembler) I've found it convenient to do hand-assembly from time to time. For that I came up with this table, which makes it (for me) easy to quickly find the opcode for the particular instruction and addressing mode I have in mind. (Warning: this has not yet been throughly proofread. I welcome corrections.)

Code: Select all

JSR  RTS  JMP (JMP)      BRK  RTI       NOP
20₆  60₆  4C₃  6C₅       00₇  40₆       EA₂

BEQ  BNE  BMI  BPL  BCS  BCC  BVS  BVC
F0₂₊ D0₂₊ 30₂₊ 10₂₊ B0₂₊ 90₂₊ 70₂₊ 50₂₊

CLC  SEC  CLV  CLI  SEI  CLD  SED
18₂  38₂  B8₂  58₂  78₂  D8₂  F8₂

TAX  TXA  TAY  TYA  TSX  TXS       PHA  PLA  PHP  PLP
AA₂  8A₂  A8₂  98₂  BA₂  9A₂       48₃  68₃  08₄  28₄

                               zp  addr zp,X  aaaa,X
INX  DEX  INY  DEY        INC  E6₅  EE₆  F6₆    FE₆
E8₂  CA₂  C8₂  88₂        DEC  C6₅  CE₆  D6₆    DE₆

        #nn     zp     addr    zp,X   aaaa,X  aaaa,Y  (zp,X)  (zp),Y
LDA     A9₂     A5₂     AD₃     B5₄     BD₄₊    B9₄₊    A1₆     B1₅₊
STA             85₃     8D₄     95₄     9D₅     99₅     81₆     91₆
LDX     A2₂     A6₃     AE₄     B6₄y            BE₄₊
STX             86₃     8E₄     96₄y
LDY     A0₂     A4₃     AC₄     B4₄     BC₄₊
STY             84₃     8C₄     94₄

        #nn     zp     addr    zp,X   aaaa,X  aaaa,Y  (zp,X)  (zp),Y
ADC     69₂     65₃     6D₄     75₄     7D₄₊    79₄₊    61₆     71₅₊
SBC     E9₂     E5₃     ED₄     F5₄     FD₄₊    F9₄₊    E1₆     F1₅₊
CMP     C9₂     C5₃     CD₄     D5₄     DD₄₊    D9₄₊    C1₆     D1₅₊
CPX     E0₂     E4₃     EC₄
CPX     C0₂     C4₃     CC₄

        #nn     zp     addr    zp,X   aaaa,X  aaaa,Y  (zp,X)  (zp),Y
ORA     09₂     05₃     0D₄     15₄     1D₄₊    19₄₊    01₆     11₅₊
AND     29₂     25₃     2D₄     35₄     3D₄₊    39₄₊    21₆     31₅₊
EOR     49₂     45₃     4D₄     55₄     5D₄₊    59₄₊    41₆     51₅₊
BIT             24₃     2C₄
ASL     0A₂     06₅     0E₆     16₆     1E₇
LSR     4A₂     46₅     4E₆     56₆     5E₇
ROL     2A₂     26₅     2E₆     36₆     3E₇
ROR     6A₂     66₅     6E₆     76₆     7E₇

[Proxy]

My PCBs have arrived but i think the parts from Mouser are gonna take a while.
So until i got the parts, the project is gonna be put on ice.

This doesn't mean i want to be inactive though.

for example i have already designed a "very simple" VGA circuit that fits onto a 5 EUR FPGA (a Lattice LCMXO2-640HC-4TG100C to be exact, though i was unable to test it on real hardware yet).
the idea behind it was to have a simple and cheap way of getting VGA video for any 6502 based computer without requiring people to design their own chip, or download GBs of FPGA software and learn Verilog and stuff.
I know others have done the same, but i think more choices = better for everyone.

another thing i also want to do is making my own expanded 6502 for future projects.
my main problem with that is that the status register is just confusing me really hard and i'm not 100% sure on what to put in it.
but I'll put that in it's own thread, not here.
I assume the "Emulation and Simulation" sub-forum would be the fitting place for that?

.

anyways, thanks for everyone here helping me out so far, i hope my future projects will be as interesting and useful for others as i somewhat hope they are.
i'll be back on this thread once i got my stuff.

[drogon]

Proxy wrote:

my main problem with that is that the status register is just confusing me really hard and i'm not 100% sure on what to put in it.
but I'll put that in it's own thread, not here.
I assume the "Emulation and Simulation" sub-forum would be the fitting place for that?

Maybe Programming? viewforum.php?f=2

The status register is just a bit of the chip that is almost fully automatic. Every time you do a load or arithmetic or logic operation the status register is automatically updated although the choice of mnemonics can be confusing to newcomers - check for zero is the same as check for equal (BEQ) or not zero (BNE). Some assemblers duplicate mnemonics or if using a macro assembler you can define your own, so you could define BZE to be BEQ and BNZ to be BNE and so on. (the ca65 'generic' macro package does this for example)

The automatic update of the status register saves you doing explicit checks in a lot of cases. It's also why you may see loops counting down to zero than up to a number too - when you decrement a register and it hits zero, then the zero flag is automatically set, so you don't need an explicit compare, so you save both clock cycles and code space.

-Gordon

[Chromatix]

Tell you what, when I get a spare moment I'll post a thread in the Programming section, to discuss the status register in detail.