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


Fixing layout mistakes is why bodge wire was invented.

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

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.



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:

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



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

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.


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.

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

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?

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

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!

_________________
Curt J. Sampson - github.com/0cjs

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...

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.

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.

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

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.


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.)

_________________
Curt J. Sampson - github.com/0cjs

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.

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

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

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.