BigEd wrote:
Welcome! You've got some interesting background experience there.
Indeed, you do raise a lot of questions. With a bit of luck, each one will be answered. But if not, feel free to re-ask something which is unanswered or which you are still unsure of. Better, I think, not to keep re-editing a post, because that will invalidate replies and will not get the attention of people who have already read it.
You might find that you do have a mega-thread for progress on your project but you have other mini-threads for specific questions. That's fine.
You are trying to do quite a lot in a first PCB project. I'd recommend planning on making two or even three revisions, and make the first revision simple. You need to learn the tools and the approaches.
All the refinements you propose are fine, but each one is adding difficulty - in decision-making, in learning, in doing, and in testing.
For example
- with a simpler coarser memory map you have simpler decoding and can use logic chips instead of GALs
- with a slower clock you can run every chip at the same speed and remove clock stretching
You've already made some good simplifications
- not too many peripherals
- using just a fraction of a larger memory chip
This is already a lot? the desigtn is already a lot simplier than what i originalled planned with the FPGA.
And I agree with BillO, GALs are just better than discrete logic ICs in basically every way.
i used discrete Logic ICs when i first did a Z80 breadboard build, but quickly switched to GALs and never looked back.
I could be more lazy with the IO Decoding so it could fit into the same GAL as the Memory decoding. but i don't know... it would leave copies of the same devices in the Memory map unless i fully decode the addresses.
drogon wrote:
Just following on from what Ed has said... I used just one GAL in my 6502 SBC, however I have 64K RAM (2 x 32KB RAM chips) and just one page at $FExx decoded for IO. I could have split that region into 2 with another address line if needed, but all I have is a single 65C22 VIA. (I just took A8:15 into it). I run with no wait states.
I vertically mounted the RAM chips - stacked one on top of the other and just brought out the CE pin on the top one.
I've no experience of KiCAD, but it's what I plan to migrate to when I find enough time to get up to speed on it. I currently use Fritzing - mostly due to the inertia of having used it for the past 8 years. I'd not recommend it for starting something new.
I started my 6502 SBC on breadboard - then stripboard, then PCB.
I like that little USB chip. Food for thought! There are many DIL carriers you can get for mounting surface mount chips on which might make it easier for the main PCB.
Sounds like another good project though - do keep us updated on it!
Cheers,
-Gordon
Thanks i'll try to pull this one through. I'm not very good at finishing projects, but that's mostly due to me not asking for help and getting stuck on something.
and yea i was thinking about using an adapter and then just sucket the thing onto the Board.
BigDumbDinosaur wrote:
Proxy wrote:
words
I concur with Ed's suggestion that you go with a coarser memory map and use discrete logic instead of GALs. As this is your first 65C02 build you don't want to get very complicated. A simple memory map that can be configured with a handful of gates will make hardware debugging quite a bit easier. For example:
Code:
$0000-$BFFF RAM
$C000-$CFFF I/O
$D000-$FFFF ROM
The above can be established with a circuit such as the following:
The above will give you plenty of contiguous RAM (48KB), as well as plenty of contiguous ROM (12KB). Furthermore, there are no more than two gate delays between any chip select and the address bus, which will allow the circuit to run as fast as your ROM will allow. Obviously, you can use anything you want—it's merely a suggestion to get you started.
Speaking of ROM speed, adding wait-state circuitry to the above is easy—Jeff's circuit that you linked to should work fine. You'd trigger a wait-state when the ROM's chip select is asserted. However, I recommend you not do wait-stating in your first build. The idea is to build something that won't overwhelm your ability to troubleshoot should it not work properly on the first try.
Along with building the hardware, you will need to write some basic firmware to make it go. A book we recommend around here for anyone learning the 6502 assembly language is
Programming the 65816 Including the 6502, 65C02, and 65802 by David Eyes and Ron Lichty. This tome starts out with the basics and gradually works you into writing and testing small programs. Key concepts are explained and there is a detail write-up on every instruction. I highly recommend you get a copy and keep it handy.
Quote:
one thing i noticed about the FT240X is that the datasheet says that it reacts to the falling edge of the WE signal...
The /WE behavior is common. Which brings up an important point.
In a 6502 system the Ø2 clock is what regulates bus activities. You should not write to RAM or I/O while Ø2 is low, as the data bus is not guaranteed to be stable during that time. Therefore /WE must be qualified by Ø2. My example circuit includes a read/write generator for use with the RAM and ROM you are wishing to use.
as said before, i think GALs are perfectly fine.
about the Wait states, yea it's understandable to not have too much at the start. but it just seemed like a waste to me, which is why i wanted to go with the full High speed CPU and such from the start.
i just do it as a second revision a bit later i guess.
so an 6 or 8MHz Clock should be slow enough for the ROM, right?
speaking of which i never liked having much ROM anyways, 8kB is already more than i would've put in originally. plus i doubt my programs would be large enough at the start to even fill
that up
as my original idea was: have 1-4kB of ROM, and the rest RAM, the ROM would only contain a simple memory clear function and bootloader that loads a program over serial into RAM and then runs it.
pros:
- The Program is running in fast RAM instead of slower ROM
- I don't have to constantly take the ROM out of the Computer, program it, and put it back to do changes to a program
- Changing the program is as easy as pressing the reset button on the Computer and dragging/dropping a different BIN file into RealTerm
I got a PDF of the book you said. i hope it will be helpful of some 65C02 quirks. i already worked with assembly as said, so i'm not completely new to it.
to get better with a CPU i always just write the same functions for that CPU. for example printing a string to Serial, converting a String to an Integer, etc.
since i also did this for my Custom CPUs which are based on the 6502 and 65816 it shouldn't be that hard to get used to the 65C02.
about the Clock thing, yea i should use the Clock as well in the decoding. i'll try to adjust my circuits...
but i'm still not sure about the Memory map. i mean i could use the complete bottom byte for IO, which would rob me of 256 bytes of RAM instead of just 8. but would make the Decoding a lot easier, as i could handle the top and bottom half of the address bus in 2 seperate GALs. (can't do it in one as there are not enough pins on the GAL)
BillO wrote:
I don't usually disagree with BDD and Ed, but I'm a dyed-in-the-wool fan of GALs and wholeheartedly support your use of them.
They are:
- FAST
- re-programmable, allowing you to fix problems with, or update, your logic easily.
- reduce chip count (I think you can do all you need with just one)
- allow for flexibility in PCB layout
- cheap
- simple to use
- easy to find - even old Lattice ones are abundantly available
I see no downside to them and I'm not sure what Ed and BDD have against them. To me, they are a lot more pleasant to use than wiring up 3 or 4 (or more) 74XXXX chips and their cumulative PD - especially if you got something a bit wrong.
I like that USB solution too. I'll have to look into that one.
Oh, and welcome...
same, GALs are dope and i'll definitely use them as it means less hassle with the PCB and wiring.
Dr Jefyll wrote:
BigDumbDinosaur wrote:
You should not write to RAM or I/O while Ø2 is low, as the data bus is not guaranteed to be stable during that time.
Right, and this rule doesn't seem to be followed in the circuit in the lead post.
Also, I have doubts about the snippet shown below.
- Isn't CS_ROM an active-low signal? Also,
- be aware that RDY means what it says; ie, the high (True) state means "go ahead." (High doesn't mean "do a wait state.")
-- Jeff
It's the same exact circuit you showed. this is just the power up state, if you look a bit more closely, as soon as PH2 is set to 1 the output will also be set to 1 and stay there until the CS_ROM or IO_EN get set low.
so it would only pull the RDY pin low for half a clock cycle.
and yea i did some readjustments for the Decoding:
i somewhat kept the Map of the orginal post, but i can easily change the decoding by just reporgramming the GALs even after the computer is built.
RAM: 0x0000 - 0xDEFF (55.75kB)
IO: 0xDF00 - 0xDFFF (256 Devices, only 2 used at the time, the FT240X and the Status of it)
ROM: 0xE000 - 0xFFFF (8kB, should be enough for this one, though as said i can always adjust these numbers even after the PCB is made)
and yea i can just leave out the RDY Circuit and use a slower CPU.
This should be better, even though it's almost the same thing.
DerTrueForce wrote:
That's a thing worth noting: Some of the members here are colour-blind, and these people are some of the more experienced members, so it's best to post schematics and such in monochrome.
oh sorry i didn't know that, i just use Logisim because it's convenient and allows me to directly test the circuit as well.
i tried to edit the image to have a higher contrast, but it also made the text a bit less readable.
I asked the Dev of "Logisim Evo HC" to add color controls for the program, which should make it useable for basically all colorblind people. though it will take some time for him to actually add it.
Login
Register
FAQ
Search
