Now for something a little different. I was first exposed to computers back in the late 1970s and early 1980s. Suffice it to say, placing my hands on the keyboard of an Apple //+ was a watershed moment which pretty much set the course of my life from that point on. The heart of the Apple // was the 6502 microprocessor. I learned to program on that chip, along with millions of other people. It was the chip that brought computers and video games to hundreds of millions of homes and schools, and I think it’s safe to say that it sparked a revolution. The world was ready for personal computers, but all the contemporary CPU offerings (notably from Intel, AMD, and TI) were very expensive. The 6502 offered all the power of the others, for 1/10th of the price. You could find 6502s in the entire Apple // line (except the GS), the Commodore 64, the Vic-20, the Atari computers (except the ST), the BBC Micro & Acorn, the Atari 2600, the Nintendo Entertainment System, and many others. If you used a personal computer or played a videogame in the 1970s, 1980s, or early 1990s, there’s a very good chance it had a 6502 in it. It was arguably the first RISC chip, and the first to do pipelining. It has a clean, elegant instruction set and gets much more done with a clock cycle than anything else of the era.
I finally decided that I wanted to pick up a naked 6502 of my very own, and see if I can get it to do something. Unlike my other projects, I don’t have a destination in mind here. This is the hacking equivalent of walking to the bus station with my credit card and seeing what happens. I’m calling this project Veronica, and I’m going to let her tell me what she wants to be. So let’s get rolling and see where we end up!
One more thing- I am by no means an expert on CPUs or how to build with them. I’m learning as I go here, so feel free to speak up in the comments below if you see something I’m doing wrong!
So…chip acquired. Now what?
Well, the first thing to do with a CPU is see if we can bring it up and get it to execute some instructions. At their core (pardon the pun), CPUs are really very simple beasts. They do basic arithmetic, they branch and jump to different lines of code, and they move bits to and from memory. That’s it. Everything else is just layers of tricks to make them faster.
The first thing a CPU needs to run is a clock. I picked up a surplus crystal oscillator to handle this. The data sheet for it is really sketchy, so I put it on the breadboard by itself and played around with the pins to make sure I knew how to hook it up properly.
I’m starting with 1Mhz, just to be safe, and it seems to me that being able to single-step the execution would be useful. Here’s what I came up with to do all of that:
On the left half of the schematic, there’s a 555 timer configured to generate a single-shot 2ms pulse on the rising edge of a button press. This is roughly equivalent to 500kHz, which is comfortably above the recommended minimum clock speed of the 6502 (which I believe is 100Khz?). On the right is a standard 1Mhz crystal oscillator. The toggle switch in the middle chooses between them, and also acts as a run/stop switch for the CPU. When in “single-step” mode, the CPU is paused, and clocks are read from the manual button press. When in “run” mode, the 555 timer is ignored, and the crystal’s pulse train is fed directly to the CPU.
Notice that I’m switching the power sources of both clocks, not the clock signals themselves. It’s important to keep the clock signal as physically close to the CPU is possible, and I want to run potentially long wires to a switch and back. With this arrangement, both clocks can sit right next to the CPU, but the switch can be located anywhere that is convenient. I also have a 3.6Mhz oscillator that I may try putting in there, to see how Veronica performs on that.
Note: Since building this, I’ve learned that the clock input needs to be held high while the CPU is stopped to prevent internal data loss. I’ll be reworking my single-stepping clock circuit to achieve this. For this simple test, though, it works fine as shown.
Once we have a clock, the CPU will need to execute some code. According to the datasheet, When the CPU powers on, it goes through a reset sequence, then fetches an address from memory location $FFFC (called the Restart Vector). This location is the very top of memory, and the chip is internally hardwired to fetch an address from there after a reset. This address is put into the program counter, and the CPU starts fetching and executing instructions from there. Note than I’m using ‘$’ to indicate hexadecimal numbers, which was the custom at the time (before the C language took over the world, with its ‘0x’ prefix).
But wait- we don’t have any memory! Well, we can get by without any for now. The CPU is putting address values out, and expecting to get values back in on the data lines. We can just hard-wire those data lines with some fake bytes, and the CPU won’t know the difference. A good place to start is $EA, which is the 6502 op-code for NOP (no operation). A NOP does nothing except cause the CPU to advance to the next line of code. So if we hardwire the data lines to $EA, what will happen? On reset, the CPU will think it’s fetching a two byte address from $FFFC, and will get $EAEA back. It will then start executing code from memory location $EAEA. Every fetch cycle, the CPU will ask for the next instruction, and will get $EA (NOP). It will execute that, and continue until it gets to the end of “memory”, at which point it resets and does it all again. This process is called a Free Run.
Here’s what the circuit looks like to do that:
On the left is a reset circuit, which consists of a push button, and an RC network. The RC network holds the reset line active for about 50ms, to make sure the reset “takes”.
Note that, per the datasheet, if we were using the NMOS version, we would need pull-up resistors on the IRQ, NMI, and RDY lines. The CMOS version (65C02) sets these pins to high-impedence for us, so we can let them float. Any of those three signal inputs, if not tied off properly, could set off cause chains of events in the CPU that we don’t want to deal with right now. Refer to the datasheet if you’d like to know what all these signals do.
On the right, you can see that the Data lines are all hard coded to +5V or ground, to force 1s and 0s, respectively. As explained above, that bit pattern (11101010) is $EA. No matter what data the CPU requests from the RAM (which isn’t really there), it will get $EA back. Sneaky! Lastly, you can see I have a 16-bit bus connecting the address lines to my HexOut module. This is just so I can see what addresses the CPU is looking for in memory. That tells us a lot about what the CPU is doing.
We don’t need resistors on the Data lines because, per the datasheet, they have tri-state buffers built in.
The Eagle symbol for the 65C02 that you see in the schematic is one I made myself. I couldn’t get any of the 6502 Eagle libraries available online to work, so I made this one. If you’d like a copy, here’s the current version of it. It uses a 40-pin DIP package (also included in the library).
So, now we have a clock circuit, and a CPU set up to free run. Here’s what it all looks like on the breadboard:
The main breadboard holds the 6502, the fast clock, and the reset circuit. The smaller board has the toggle for choosing clocks, and the 555 circuit for single-stepping the CPU. You’ll also see JuiceBridge making an appearance here, and of course HexOut is coming in very handy.
That’s fine and dandy, but this thread is useless without video, am I right? Pictures don’t do it justice, so let’s watch the process unfold. In the first video, you see me turn on the power, at which point the CPU is in a junk state. I’m holding reset for one clock cycle, then advancing the clock step by step. You can see the CPU go through its reset process, which results in various junk appearing on the address lines. After seven clocks (per the datasheet), I hesitate so you can see the CPU start looking at bytes $FFFC and $FFFD in memory. That’s when it’s ready to start executing code, and needs to know where to find some. Of course, it gets $EAEA, so you see it jump to that address, and attempt to execute. From then on, it’s getting NOPs, and on every second clock you see it fetch from the next address. The in-between clocks are when it is executing the NOP that it fetched. It repeats fetching and executing NOP after NOP after NOP until it runs off the end of the 64k of addressable memory (which isn’t actually there).
In this second video, I unleash our girl at 1MHz. Obviously, the addresses are now going by too fast to see much, but I can hold Reset to halt it and see where it is in memory at that moment (after which, it resets).
What’s next for Veronica? Well, she needs some real memory, I suppose…
46 thoughts on “Veronica”
looks awesome, I can’t wait to see what you come up with for this baby 🙂
One correction – The Commodore 64 used the 6510 processor, the 6502 was only used in the Commodore VIC-20.
Yep, you are correct, sir. And I believe at least one of the other devices I mentioned used the 6504. They’re all minor variants of the same beastie though, so I feel comfortable lumping them together. I least I drew the line at 65C816 devices like the Apple //GS and Super Nintendo. Those are just tarted-up 6502s, really, but even I have standards for pedantry.
The disk drive of the C64 did use a 6502. That thing was an entire computer by itself more or less. I used one and used that as the basis for the 6502 computer ‘brain’ in my Bender project. All it does is play samples triggered by a remote. Very simple stuff. I always wanted to build another with my spare chips and get it to do something more useful. Haven’t thought of anything yet though!
It’s explained here:
Nice build, Simon! Thanks for mentioning the 1541 disk drive. The C-64 was practically a multi-core machine when you factor in all the peripherals that had their own CPUs. Anyone remember the demos that ran entirely on the drive? Cool stuff.
Haha! And have you seen the recent hack to run Linux on the WD harddrive? Same stuff all over again!
Commodore used 6502 in all their floppy disk drives as a drive controller. One of the sneaky tricks of the day was to “upload” replacement firmware into ram. This is how most of the bitcopy software worked used for pirating copy protected disks.
Also useful for making your harddrive perform music (yes.. long before youtube, floppies were making music)
Essentially, all commodore peripherals were 6502s. The drives, printers, plotters… anything that attached to the serial daisychain port (another cool C= trick.. before scsi and firewire!)
One thing I always wanted to do was to turn the 1541 drive itself into a sort of mini pc, with some sort of input and display device. Would have looked sweet with a 20×2 LCD in the front of the case. My thoughts were a sort of stand alone data logger, writing to the disk, which is then readable later by the C64/128.
Hey wow, this brings back some memories 🙂 I learned to code on a 6502 Oric Atmos back when I was a kid, straight up assembly code. If you find this interesting, have you discovered the crazy fun you can have with FPGAs?
I haven’t dived into FPGAs yet, but they are on my short list of things to try! So many projects, so little time…
I found your project neat because I did a similar project with a 6502 a couple years ago (see the link I put under “website” with this comment). You’re welcome to email me at dennis.ferron (at) gmail.com.
To add RAM to your 6502, you can pull a cache RAM chip from an old 386 or 486 motherboard; they’re 32K or 64K at 8 bits, perfect for 8 bit micros and since it’s static, you don’t need to refresh it. (It is difficult – but not impossible – to find a variant of these chips for sale on, say, digikey. You’d have to try a lot of different P/N’s.)
Using a microcontroller you can program RAM directly, and then you don’t need a ROM chip, which simplifies the wiring and memory decoding. For my Prop6502 Laptop project I used a hack to steal part of the bus cycle from the 6502. There is a fraction of a millisecond where the 6502 data lines go tristate between cycles, and the microcontroller gets in there and reads or writes to the RAM so fast the 6502 doesn’t notice anything happened. As if stealing its bus weren’t mean enough, I also make the 6502 do the work of addressing the RAM for me, to save on microcontroller pins. By intercepting the read of what was in RAM and feeding the 6502 fake NOPs instead (yes I lie to it too, poor thing) the CPU will output sequential addresses as it tries to fetch each instruction. By resetting the 6502 I know it has started the addressing at 0. The combination of these 3 things – making the CPU address RAM sequentially, a known start address, and the ability to cut in and read/write different things to RAM than what the CPU thinks it’s doing, I can load a program into RAM without a 6502 bootloader and thus not need a ROM chip. It’s all in the project docs and code if you’re interested.
There are a few quirks to the 6502 that aren’t well explained in the documentation. For instance if you change the sync (single stepping) inputs at the wrong clock phase the 6502 will hard lock up (or at least the Rockwell version I was using would do that). Feel free to email me with a question if you run into something that doesn’t seem to make sense while trying to expand the project you’ve got here – chances are I ran into the same difficulty.
If I do another project like this in the future I would definitely use an FPGA; I haven’t learned how to use one yet but with the number of I/O lines you need for this kind of project the FPGA just makes a lot more sense.
That’s a really clever way to solve that problem- well done! There’s a lot of great ideas in your post, so thanks for sharing. I may indeed hit you up for assistance if I get stuck along the way.
I`m really pleased to see this project, and will be watching this closely for updates (already bookmarked you), I think I`v seen almost every SBC and homebrew computer that the internet has to offer, and to encounter a new project is great!
I think you`re really going to have a lot of fun with this 🙂
sometimes it`s a headache sure, but when you solve it, there`s not a feeling like it!
the above poster is quite right, the Cache ram chips from an old mother board are a great source of these large capacity static rams, also you can get Very cheaply some EEPROMS that you can also program manually on breadboard just like RAM but you don`t need any power backup for them, or a UV eraser, my ZED project uses them as the OS and program area, I use the Atmel 28c64, it`s only 8K x8 but that`s plenty enough in machine code for most things.
if you wanted to keep it simple, you could also make Diode ROMs (ideal for only a few bytes of code to get something working).
Best of luck with Veronica (not that you`ll need it).
Keep up the good work!!! 😉
Sweet, old school action! Kudos… there were a lot of 6502 “trainers” back in the 70’s , might give a lead what to do next. 2k static memory and a hex loader?
What i nice project i hope it will turns out well! If you like reading about the old commodore microprocessors, back when they were developed, and all the fun little details about the persons who made them, i highly recommend a book called “On The Edge the spectacular rise and fall of commodore” it follows Chuck Peddle in the time of the 6502 and beyond. You can read a sample of it here: http://www.amazon.com/Commodore-Company-Edge-Brian-Bagnall/dp/0973864966/ref=sr_1_2?ie=UTF8&qid=1322779464&sr=8-2
That is a great read, for sure. Much of the background information in the article comes from there, in fact. Anyone who hasn’t read it, I’ll second this recommendation.
“Note that, per the datasheet, if we were using the NMOS version, we would need pull-up resistors on the IRQ, NMI, and RDY lines. The CMOS version (65C02) sets these pins to high-impedence for us, so we can let them float.”
Those lines should never be allowed to float, as spurious activity may occur due to circuit noise — IRQ is particularly vulnerable to noise, since it’s a level-sensitive input. Pull them up to Vcc with 3.3 K metal film resistors to be on the safe side.
For little more than what you paid on eBay for the obsolete Rockwell parts, you can get the genuine WDC part (available from Jameco, etc.), which has a fully static core and thus can be halted by stopping the clock at any convenient time without regard for the clock’s state.. Also, although not germane to your project, the WDC part is capable of running at 20 MHz.
Aside from all that, glad to see you are tinkering with the 65xx. It has been a long time since I did any professional development for the 65xx family, but I still fool around with the W65C816S, the 16 bit cousin of the W65C02S. Please stop by 6502.org some time.
That’s interesting that you should mention that- I looked at the one Jameco sells, and passed on it because they list it as 1MHz. I liked the idea of going a little faster, plus the eBay ones were actually about 10x cheaper. Is the Jameco site incorrect in the speed? I may pick one up after all, if so. Regarding the signal lines floating, the data sheet says explicitly that they can be left floating. Nevertheless, I would tie them off in any permanent project, since it’s good practice in any case. Belt and suspenders, like a good engineer. Thanks for your tips! 🙂
What you probably saw on the Jameco site were the 65C02 “pulls” they have advertised since time immemorial—mostly 1 and 2 MHz parts of various origins. The actual WDC stuff can be found at http://www.jameco.com/webapp/wcs/stores/servlet/StoreCatalogDrillDownView?langId=-1&storeId=10001&catalogId=10001&freeText=W65C02S&search_type=jamecoall (lists 65xx support silicon as well as MPUs). The PDIP version of the W65C02S is Jameco part number 2143638. However, you may find it more interesting to monkey around with the more versatile W65C816S, part number 2143662 (PDIP) or part number 2143671 (PLCC44, recommended if you wish to crank up the clock speed into double digits).
You can start out with the ‘816 running at a slow clock rate in emulation mode, in which it mostly behaves like a ‘C02. Once you get comfortable with it, switch to native mode to access to 16 bit loads and stores, as well as other useful features. If you decide to build an ‘816 unit be sure to account for the MPU’s VDA and VPA outputs, which are essential to error-free bus access.
My first-design SBC is powered by the PLCC44 version of the ‘816, and has been tested at speeds as high as 12.5 MHz, using 74AC glue logic. Although WDC officially rates the ‘C02 and ‘816 at 14 MHz, either can be run at 20 MHz on 5 volts, and it may be possible to run the ‘C02 even faster.
Very cool- thanks for the info! I had no idea there was a modern 20Mhz version of the 6502. That’s definitely going on my shopping list.
Oh, and thanks for mentioning the 65C816. I have fond memories of that chip from my days programming an Apple iigs. 😀
Interesting you mentioned the IIgs. Apple ran the ‘816 at a relatively slow clock rate because of a lack of supporting silicon at the time of the machine’s development. Most of the glue logic was still 74LS, which would not been able to stay with the ‘816 if the throttle had been fully opened, so to speak. Also, rumor had it Apple didn’t want the IIgs out-performing the Mac, which it might have done if the MPU could have been clocked at 20 MHZ. 🙂
BTW, I got quite the chuckle out of your Dish-O-Tron 6000. Nothing like the genuine Rube Goldberg approach to providing the latest in modern home conveniences. Me, I use a much less technical approach: I wedge a dish towel in the door to tell me to empty the dishwasher. However, I applaud your imagination in solving a problem routinely confronted in virtually every modern household. Now, if you could figure out something about monitoring for raised toilet seats…
Just to maybe stoke your interest in monkeying more with a homebrew computer, here are a couple of pictures of my hack job ‘816 SBC:
Assembled unit, complete with circuit patch leads: http://bcstechnology.net/sbc/images/scsi.d/ha_on_poctv.jpeg
My “Y’all Approved” test rig, with SCSI hard disk sitting on top of a cable: http://bcstechnology.net/sbc/images/scsi.d/scsi_test_rig.jpeg
The POST screen from the little contraption: http://bcstechnology.net/sbc/images/scsi.d/enum03.jpeg
Very cool stuff. Yah, the iigs was a troubled machine, but it’s still my favorite of all time. Not only did they (allegedly) slow it down to prevent competing with the Mac, but the bus was limited to 1Mhz for compatibility with the Mega II (the Apple //e on a chip that handled backward compatibility). Accessing the otherwise formidable graphics hardware at 1Mhz would have been a deal killer if not for a few very clever demo scene folks like FTA, Delta Brothers, and Brutal Deluxe how knew how to circumvent that. Relocateable stack… 2.8MHz stack access… video memory…some very tricky push/pop code… You can guess the rest. 🙂
Oh, and regarding the Dish-O-Tron, I get a lot of teasing about it, but in all honesty I think it’s the most useful thing I’ve ever built. I’m so hopelessly forgetful, and it’s completely hands-off, automatic, and reliable. I know at a glance whether to reach for the cupboard or the machine for a clean glass, and where to put the dirty plate (machine or sink?). I just never have to think about it, and that’s what good technology should do, in my mind. But yes, it’s also deeply silly. 😉
BTW, I decided to do what you did and put up a website devoted to my 65C816 contraption.
In the video you see the CPU pushing status register and return address to stack ($01fa,$01f9,$01fa8) before reading the reset vector from $fffc.
Note: tri-state == high-impedance == pin in input state.
If there is no external or internal pull-up or pull-down, the pin floats. It depends on the chip design, the individual chip (due to minute differences in production) and the current static electricity field if the pin flips high or low. Input pins may float and be high in thousands of chips, then comes one lot of chips and wintertime and your design starts to behave oddly.
Thanks for all the great information. I suspected those three addresses were important, because they always show up during the reset sequence. I hadn’t gotten around to looking up what they were yet. 🙂
I misunderstood what the high-impedance state meant. I appreciate the correction. If I understand you correctly, it’s still okay to use the buffers this way to prevent bus contention, but I got my semantics wrong on “floating” and if it ever comes up, I should not count on those pins being in a particular state.
Thanks again- very helpful comment!
I think I have fallen in love with Veronica. Want one, Want one, Want one. I’m gonna start with a Hex out design of my own. Lcd + pic + a hex keypad for input as well. Then I’ll start on a Veronica clone. I have some info on homebrew computers. I’ll start going through it and if I find any info that may be of help I’ll pass it along. I think I may have some info for clock circuits, fixed timebase, variable time base, single step type stuff. I’ll check. Anyway, great site, great project. Will follow you as you progress. Thanks.
Thanks Rob! That’s so nice of you to say. Regarding HexOut, one of the other commenters here has a really nice single-board version of it that I hope he shares the schematic for. He sent me a picture of it, and it’s terrific. Very simple and elegant design.
For a single-step clock, I would recommend Woz’s circuit for the Apple I. It’s elegant and has nice features. There’s a schematic of it in the Apple I manual (page 12):
My single-step clock was fine for a while, but now that I have memory and stuff, it is no longer working well. Hopefully I’m past needing a single-step any more, but if I need one again, I’ll be grafting Woz’s circuit onto Veronica (and I’ll write it up, of course).
ah, i see the problem here. you’re using an iPad. get rid of it.
this is actually a pretty cool project. i’ve been working on something similar myself, but i haven’t touched it for a few weeks. i used a 6502, built a circuit around it with 32 KB SRAM and an 8 KB EEPROM.
i built a simple parallel port out of a couple 74LS373 chips, and wrote system monitor firmware for the EEPROM that did I/O access through the parallel interface. i wired it into a 486 laptop and wrote some simple code to print what the 6502 sent out to it, and sent the 6502 my keyboard strokes.
i then added some more addressing logic, and modded the EhBASIC source code to work via my parallel I/O. bam, instant full-fledged BASIC interpreter running on it. you should look into doing something like that, it is actually very easy.
sorry for triple-posting, i forgot to say.. my 32 KB of SRAM came from an old 486 motherboard. it was a cache chip.
What kind of pin connectors did you use for the ribbon cables? I have a similar project with a Z80 and I am using loose jumpers. I have some rainbow ribbon cable and I think that would be much easier but I haven’t found the right connector for 16 wires.
The cables you see in these photos are purchased pre-assembled on eBay. They are 8-wire, with female connectors on each end with 0.1″ spacing. For breadboard connections, I stick 0.1″ snappable headers in them to convert them to male. There seem to various fly-by-night sellers that make them. In later posts, you’ll see I switched to rainbow-colored ones which have a more compact connector (also from eBay). The rainbow ones you’ll see later are especially nice because the connectors have a footprint the same size as a row of eight pins on a breadboard. Thus, you can pack them up to four deep on the same set of breadboard connections. The seller I got them from is no longer on eBay as far as I can tell, but more pop up all the time.
Honestly, just stripping a good length off each wire in the ribbon and tinning them works fine also. If the wire is a large enough gauge (say, 20 or 22), you can stick them right in the holes like header pins. The tinning makes them stiff enough. You’ll see me doing that in later posts as well.
^— Sorry, that’s me. Logged into my test account by mistake. 🙂
Thanks for the quick reply Quinn!
The fact that you got them on ebay makes me feel slightly better because I couldn’t find any on jameco.com
I’ve thought about doing the same thing but the connector looks sweet. I have to tell you, your project really inspired me! Your PCB etching post really helped me work out the kinks in Eagle as well.
I think the best way to give you props is in 6502 assembler…
Haha, thanks, and you’re welcome! Buying connectors and cables for basic prototyping is surprisingly difficult. There are thousands of kinds of connectors and headers on the big supplier’s sites. Took me a while to find stuff I liked. Jameco is one of my favored sites, though- they’re a little more targeted at hobbyists. Finding stuff on Mouser or DigiKey can be a serious research project. I’m also a big fan of local surplus shops, if you have those in your area. It’s nice to get your hands on what you’re buying, and they’re always really cheap because it’s stuff nobody wants. I’ve bought a lot of connectors and cabling at those places.
So, what kind of documentation did you use to get this off the ground? Did you have some sort of reference for the wiring and support ICs? It doesn’t seem too complicated, just very specific. Did you model Veronica after anything in particular?
I ask because I have been on the fence about continuing my Z80 project or starting a 6502 one. Both have nostalgic value to me, but I am experienced in writing 6502 software (mostly NES Roms).
I know this is an advanced type of project, but I would like to understand the general circuitry more and how the CPU communicates with the memory, etc.
I didn’t have much electronics background when I started. I did some tinkering when I was little, and learned some basic digital logic (flip-flops, address decoding, etc) as part of my Computer Science education, so I was starting basic. I worked my way through Charles Platt’s book (http://www.amazon.com/Make-Electronics-Discovery-Charles-Platt/dp/0596153740), then moved on to the various single board computer tutorial sites. The site 6502.org has some great ones, and I like http://mysite.du.edu/~jcalvert/tech/6504.htm in particular. This one http://wilsonminesco.com/6502primer/65tutor_intro.html is also excellent. As for the chips themselves, the datasheets are your friend. I spend hours reading those. The MOS 6502 manual is also a great resource. Along the way, I’ve picked some important related concepts like decoupling capacitors, coping with noise, signal integrity issues, and so forth. Much of it has been trial-by-fire, such as when I spent six months getting a 20MHz design to run on a breadboard without realizing how foolish that is. 🙂
Thanks for the resources! I look forward to seeing more hacks from you. I’m going to scout out some 6502s online.
Hi! What a cool project! I have a question:
I noticed, your binary NOP command, 11101010, is fed to the data bus in a way that looks backwards: d7 gets the first “1” (tied high), d0 gets the last “0” (tied low).. Am I correct?
I’m building a similar circuit to test a 68B09E, and am wondering if that’s how these 8 bits like their addresses? I couldn’t find this info in the data sheet. Thanks!!!
Hi Jason! I’m not sure what you mean about it being backwards- D7 is the most significant bit, and D0 is the least significant bit.
Thanks for your reply!
I guess I was thinking the databus would be read incrementing n+1, starting at D0) so that to get a free run with the NOP instruction, I’d wire it so that:
1 1 1 0 1 0 1 0
D0 D1 D2 D3 D4 D5 D6 D7
But, if I understand what D7 being most significant bit means (so it starts there?), the computer reads from D7 to D0? Like this:
1 1 1 0 1 0 1 0
D7 D6 D5 D4 D3 D2 D1 D0
Is this correct?
Well, this is parallel data, so there’s no “start” or “end”. The highest numbered bus line (D7 in this case) is the most significant, which means it has the most effect on the value (2^7 in this case).
Hey, thanks for your help- you got me to finally understand how to wire the data bus, and it works! Here is the result:
using one simple NAND ic…how can i build siimple 6502 based proto also using only one
rom ic for auto boot into FFFD & FFFC…beginning with address 0000 extending to the
capability of sram ic (2048 x 8 in this case)?
Comments are closed.