6502.org

Blue wire, my friend. Use enough of it and you can turn a VIC-20 into a DEC VAX.

I don't recall seeing a complete schematic for your unit, but I suspect the clock stretching thing wouldn't be all that difficult to set up. As I earlier said, I'm working on something for my POC V1.2 unit to test someone else's clock stretching theory.
WR on the FT240X is an active high signal. Says so in the data sheet.

Not quite like that.

For now, I'd suggest forgetting and ignoring the overflow flag. It's not quite what you think.

What you want to think about is the carry flag.

Add 1 to $FF and you get $00 with the carry set. (the 9th bit).

Then you can branch carry set or clear (BCS, BCC) without needing an explicit test.

And note about the explicit test - if you load A with 0 (or it, or any register or memory becomes zero) then the Z flag will be automatically set. That's the key thing to clever 6502 code - the condition flags are automatic based on the last result - Zero or Carry are the 2 you'll use most. So simply:
Go back to the V (overflow) flag when you really want to do 2s compliment arithmetic.

-Gordon

Specifically, overflow occurs when signed arithmetic results in a "carry" from bit 6 to bit 7. In signed arithmetic, integers range from $00 to $7F in the positive direction, and $FF to $80 in the negative direction. Here's some contrived code to illustrate the principle:
Two things:

1. Hexadecimal values in standards-based 6502 assembly language are notated as $nn or $nnnn. 0xNN is C notation. Even x86 assembly language doesn't use that—it uses NNh to indicate hex.
2. Immediate register loads are indicated to the assembler with # preceding the value to be loaded. Hence your first instruction would be written as LDX #$FF.

Loading .A with $00 automatically sets Z, so the CMP #$00 is unnecessary.
Incrementing or decrementing a register has no effect on the V flag. The only arithmetic instructions that affect it are ADC and SBC.

oh so i used the wrong flag... well damn, i'm used to carry and overflow being interchangeable.
yea sorry, i'm used to that because that's what my assembler uses. (it's a good assembler (constants, global and local labels, #include so you can split your program into multiple files, etc), i can post more details if anyone is interested)
so i'm also gonna keep using that because i like how clean it is.
"0x" for Hexadecimal, "0b" for Binary, and nothing for Decimal.
it's just so nice without the use of special characters that would require me to press SHIFT+something.
ok good.

the program now works after changing the V flag to the C flag.
finally i got some code working. and it runs perfectly at 1MHz and even seems to work at 10MHz without a RDY Circuit! which is good news
and my poor terminal program can barely keep up with all the "Hello World!"s filling it.


I'm very thankful for the help i got here with my project. even if a lot of issues were caused by my own stupidity, but hey mistakes happen. and this will definitely not be the last project i'll post about on here.
now it's time to get a bit more into the programming, gonna do the basic functions first. stuff like reading a string from the FT240X, writing a string to it, etc.
that usually gets me used to a CPU/Syntax as i already know exactly how those functions are supposed to work. luckly it isn't my first time using assembly.

There are several books that can help you with learning the 6502 assembly language, foremost of which is Programming the 65816, Including the 6502, 65C02, and 65802 by David Eyes and Ron Lichty. That will help you get familiar with the 6502 "idiom." For example, since the 6502 family automatically sets and clears status register flags according to the most recent load, arithmetic or logical operation, succinct code can be written that exploits that feature, especially in loops, in which counting backward is common.

yea the flags are really the only confusing part about the CPU (plus some other oddities). especially since non-arithmetic instructions can change them as well.
I've actually designed a custom CPU based on the 65C02, but i only looked at the instructions and basic functions, stuff like interrupts, and flags i did completely from scratch... so i never learned how those work in the original hardware.

luckly the NESdev.com provides a complete PDF of the book so i don't need to buy anything.

anyways i'll still want to do a second revision of the board to make some things better.
like having a power switch so i don't have to unplug the board to turn it off.
having a seperate Reset for the USB chip and the rest of the system. (so that resetting the system doesn't reset the USB connection, which otherwise gets annoying as it has to reconnect to the PC)
maybe replacing the GALs with a CPLD to save some space
I need to think about what else could be done. but those are some ideas i had.

Regarding the flags: handling them well is, in my experience, core to how good your assembly code will be. I find obelisk's 6502 instruction set reference quite useful since it gives the details of exactly what flags are modified by each instruction, helping me to choose carefully what instructions I'm using based on what they set or don't set. But for quicker reference, I've also created a table of flags listing all the instructions that affect each one.
Well, certainly bikeshedding here, but I find using one character rather than two to be more clean. Either way, it's two keystrokes, one in the number row and one in the bottom row, so there doesn't seem to be any difference there.

INC, INX, INY, DEC, DEX, DEY only affect the Z and N flags. This can be frustrating if you want to be clever with your loop termination conditions, but once you know the idioms it can actually be useful, since it allows you to preserve the Carry flag between iterations of a loop. In general, N and Z are affected by any instruction which changes A, X, Y or performs an operation directly on memory.

The only instructions which affect the V flag are: ADC, SBC, PLP, RTI, CLV - and the /SO signal input (there's no SEV instruction). It's the least-used flag on the 6502, only really useful for error handling during signed arithmetic, and when was the last time you saw a program which did that? (The C language doesn't make it easy.) Hence the secondary use as an external hardware input; /SO is normally tied high, hence unused.

Carry is used not only by ADC and SBC, but also by CMP and the shift and rotate instructions. It is preserved by loads, increments, decrements, and bitwise logical operations (other than shifts and rotates). Some routines also use it as an error flag on exit, as it's easy to set and test explicitly.

Adaptability and flexibility is the key in my book, and, really, life's too short to point out (or worry about) minutia like 0x vs. $ vs nnH vs & vs. #x and whatever else might exist in the systems and languages we use.

For those not aware, while $ may well be the convention in the MOS world, but &num is the convention in Acorn/BBC Micro world.

-Gordon

Agreed! Of course you have to use the conventions which your assembler uses, but we shouldn't find it any barrier that one person illustrates with &FA and another with $FA.

ok because noone asked i'm still gonan talk about the assembler i use, just because i feel like it deserves some praise.

I never really found a good 6502/65C02 assembler. the 6502.org's tool page isn't really that great for finding one, especially since it doesn't seem very updated (some sites on there don't exist anymore for example).

basically all assemblers listed are either mainly for some specific platform, cost money/require a key, run on very old Operating systems (ie DOS), or are bound to some specific emulator (which can be useful in cases)

so i opted for an Assembler i already knew... because i used for custom CPUs.
CustomASM
It supports global and local labels, bit slicing, constants, and probably more i can't think of right now. it has a full feature list on the Github.
it's a Universal Assembler, which means you need to define the instruction set and names of instructions yourself.
and that is exactly what i did for the 6502 and 65C02.

though technically i did 2 seperate CPU files for both the 6502 and 65C02.
CS (Classic Syntax), which is something like this: ZS (Z80 Syntax), which is something like this: (and probably easier to remember than 3 letter acronyms, atleast for me) another great thing about it is that it doesn't come with some predefined IDE, you can use whatever Text Editor you want.
though i would REALLY recommend Notepad++, it's such an overall amazing text editor.
it even supports custom highlight, which is perfect for an Assembler.
example:

No Custom Highlighting: Custom Highlighting (made it myself to fit my dark background): overall CustomASM nice to use and probably a much better option than a lot of the existing ones, atleast for starters i think.
you literally just drag your ASM files onto the EXE and it assembles them, or you use the command line if you want some debugging info.

Interesting. That's one I've not seen before - at least I don't think I've seen it - possibly because in the past I've looked specifically for 6502/65816 specific assemblers and taking the path of least resistance went for something that "just worked" ...

My ever lasting to-do list includes writing an assembler for my Ruby 816 platform - one that runs natively on it... But until then I'm using ca65 from the cc65 suite as it ticks all those boxes (free, and I use Linux and a text editor and Makefiles although I think there are ports to MS Win, etc.)

Cheers,

-Gordon

Alright, i think i'm done with version 2 of my Board.
what i did:

* Fixes the Reset button and removed the connection to the USB Chip. there is not really a reason to ever reset the FT240X and it's annoying that resetting the System also resets it. (it's annoying because that disconnects it from the PC for a short time)
* changed the placement of the USB connector and the size of the PCB, now it's slightly smaller than before.
* Added a power switch, just a standard 3 pin Slide switch. It's connected in such a way that disabling the power connects all Vcc connections to GND. (with the obvious exception of the USB Port and the USB Chip). it's to prevent the power pins of all ICs and such from being floating while not switched on. not sure if needed.

This is how i hooked up the power switch. I don't know if the switch can technically be on both positions (i doubt it) so i don't know if i should add a resistor between it and GND. Other than that i don't think i changed much. i tried to keep as much of the original design as i could because i know it works.

lastly, i found out Kicad has a Raytracing feature for the 3D viewer... took a minute to caluclate but doesn't look that bad. even got reflections on the board. This has nothing to do with the design, i just found it interesting.

let me know if there are any other changes i should probably do before ordering the boards.

You should be very careful about separating the power planes of the USB interface and the rest of the board. If the USB chip drives a high logic level into any logic whose power is not only removed but grounded, you can expect that signal to short through the protection diodes of whatever logic is connected to it. Does the USB chip interpret its selection signals as active-low?