The FT240 datasheet shows 27 ohm resistors between the USB connector and USBDM/USBDP pins of the FT240 chip, and also a 100nF bypass capacitor from 3V3OUT to ground and 3V3OUT, VCCIO and RESET# connected together.

Yea the last 2 times i used the FT240X i did have those 27 Ohm Resistors like the datasheet says, but i really didn't know where to fit them in here. i guess i can move the whole chip down a bit to fit them right under the 47pF Caps.
And i don't think i ever used the bypass cap for the 3.3V output, i'll see if i can squeeze that in there anyway but it would massively increase the size of that trace. hmm.

also the datasheet says that RESET# can be left unconnected if not needed, and i didn't wanted to bother with an extra trace.

I'd suggest switching to SMD for the R's and C's - not only do they take up less board space, but you can put components on both sides of the board.

Some more suggestions:

You could increase performance and maximum clock speed by permanently grounding the CS lines of the RAM and Flash devices and using OE and WE lines to control access instead. So instead of CS_RAM0, CS_RAM1, CS_ROM, OE_MEM and WE_MEM you would have OE_RAM0, OE_RAM1, WE_RAM0, WE_RAM1, OE_ROM. Also, if you connect the memory devices directly to the CPU data bus instead of routing them through the CPLD that would shave off the CPLD propagation delay on memory accesses.
Why not connect up the A16, A17 and A18 lines of the Flash? The 65816 isn't short of address space and it seems a shame to waste most of the Flash.
Also, why not connect up the Flash WE signal? The ability to reprogram the flash in situ can be useful. You have a spare CPLD pin (pin which could be used for the purpose.
If you can get hold of an AX100 version of the ATF1508 that would give you an extra 16 I/O pins to play with. The downside would be having to solder a fiddly 100 pin TQFP package.
(nit pick) why is the FT240 WR signal labelled WR_RD instead of FT_WR ?

i already mentioned that i didn't wanted to go with SMT for the passives because it would double the cost of the board if i let JLC solder them for me, and i didn't want to bother soldering such small parts myself.
maybe for a "micro version" someday where every part is SMT and it runs at 3.3V or something.


how exactly would that help with performance? does asserting CS take longer than OE/WE?


honestly i didn't do that because i wasn't sure about how the Data Bus would behave when directly hooked up to devices. I don't want to accidentally cause damage to the CPU because the FLASH took too long to let go of the Bus before the CPU started driving it with the Bank Address again...
even WDC's Datasheet recommends a transceiver between the CPU and the rest of the system.


it would just be a waste of space on the memory map that could be used for RAM expansions in the future, even 16kB of Flash is way more than i'll ever need.
these chips are really cheap so i don't mind leaving a massive part of one of them unused.


I don't really see the usefulness in that, ideally i'd program the Flash only a few times until i got a serial bootloader working and then never have to touch it again. that's how i did it on my 65C02 SBC as well.


it was already nerve wracking enough to solder on a TQFP-100 FPGA once, and if the PCB is irreparably broken somehow i would loose that chip, so no thanks i'll stick with PLCC.
plus i got like 10 of those PLCC ones for like 30 EUR total, which was an absolute steal, so i'm gonna make use them.


because i'm dumb, i genuinely didn't notice that... nice find!

also you made me realize that i was forgetting a signal on the expansion connector, specifically the CPU's RW signal... which is pretty important.
i'll also rename the CS_VRAM to CS_EXT and just map that to address $100000 and above, since that saves me having to route VDA and VPA all the way over there.

For SRAM and Flash devices the access time runs from the point where the address is valid and the chip select is asserted. If you use CS to control access, once the CPU outputs a valid address it must propagate through the decoding logic before CS is asserted, so the time before valid data is output is equal to the access time plus the propagation delay time through the decoding logic.
If you wire CS as permanently asserted the memory access time starts as soon as the CPU outputs valid data. Generally the time from OE asserted to data out valid is significantly less than the access time. So you save yourself the propagation delay of the decoding logic.
Another way to look at it is the propagation of the address through the decoding logic occurs in parallel with the first part of the memory access time.
The downside of this scheme is increased power consumption, because the logic circuits in the memory devices are switching every time the CPU address changes, even if that device isn't being accessed.

hmm, looking at the datasheet of the SST39SF0x0, the "Chip Enable Access Time" (70ns) and "Output Enable Access Time" (35ns) do have a pretty sizable difference.
so let me see if i understood tthis whole thing correctly.

current logic:

• CPU outputs a valid addres, and the CLK goes high.
• OE_MEM is asserted almost immedately (literally just CPU's R/W AND'd with the CLK)
• the CS_ROM signal takes a bit longer due to the more complex decoding logic
• after CS_ROM is asserted the Flash takes (at most) 70ns before having valid data at it's output
• at the falling edge the CPU can finally read the data

your idea:

• CPU outputs a valid addres, and the CLK goes high.
• the OE_ROM signal gets asserted after a while due to the more complex decoding logic (same exact logic that was used for CS_ROM before)
• after OE_ROM is asserted the Flash takes (at most) 35ns before having valid data at it's output
• at the falling edge the CPU can finally read the data

though i really doubt this would be useful for the SRAM since the difference between "Chip Enable Access Time" (10ns) and "Output Enable Access Time" (5ns) is too small to really matter, but due to lack of pins i would have to do this to both the Flash and SRAM.

also how much of a power consumption increase could this be? i already had a few problems with my 65C02 SBC where inserting the video card (powered by a ATF1508) would drop the voltage on the board down to ~4.6V.
I could probably use one of those USB Y-splitter cables to get more current, but ideally i'd just use a normal cable...

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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

There are 3 independent timing conditions which determine when the output data becomes valid:
1. The address lines must be valid for at least t_AVDV
2. The chip select line(s) must be asserted for at least t_CSDV
3. The output enable line must be asserted for at least t_OEDV

The output is guaranteed to be valid only after all three conditions are met.
The first two timing specifications (t_AVDV and t_CSDV) are usually equal to the "headline" access time - for your Flash device that is 70ns and for your SRAM it is 10ns.
The last timing spec (t_OEDV) is faster - 35ns for your Flash and 5ns for your SRAM.

If CS is decoded from the address, condition 1 always occurs before condition 2 since the address has to propagate through the decoding logic to generate CS. The most you can save using my idea is this propagation delay time.
Thinking about it a bit more, it's probably not going to help here since (part of) the address also goes through the CPLD. The CPLD propagation delay time breaks down into input delay + internal delay + output delay. Both the bank address bits and the CS signal are subject to input + output delay and the only difference will be some additional internal delay for the CS signal, which is likely to be a few ns at best.

Yes, missed that. The 816 wants 80% VDD for a logic 1. Scratch this idea then.

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

It's true the RAM, ROM etc in a transceiver-equipped '816 system will see a floating data bus during Ø2 low, but that's exactly the same circumstance experienced by RAM & ROM on 6502 and 65C02 systems.

-- Jeff

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

well Frick. guess i'll have to squeeze a 74AHCT245 somewhere in there. atleast that would free up 6 pins (frees 8 but uses 2) on the CPLD as i no longer need the MD Bus to come from the CPLD.


awww, but i like the convenience of both power and data in the same connector.
isn't it electrically possible to add the barrel jack as an optional secondary power connector in parallel to the USB Port instead of completely replacing it?
but how would a circuit for something like that even look like? just a few diodes from both power inputs towards the power switch?
also i'll need to add some 5V Regulators, this AZ1117CH2-5.0TRG1 seems good, output current of 0.8A should be enough.


funnily enough, the idea would've used the same exact amount of CPLD pins as the current design (3 CS signals + 1 OE signal + 1 WE signal -> 3 OE signals + 2 WE signals). but i still see your point.
hmm, now that i think about it CS for anything cannot be asserted while Ø2 is low because all of them require the bank address, which is only latched and valid after Ø2 went high.

either way i need to re-order some stuff on the PCB to fit everything again

EDIT: wait what about the control signals that come from the CPLD and go to the CPU (SYS_CLK and IRQ_CPU)? On my 65c02 SBC I had the CPLD generate the RDY signal and that worked perfectly fine even up to 20MHz and while the board voltage was down to ~4.6V, so I assume that should be fine here too, right?

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