65c02 Homebrew Computer on breadboard

Custom designed breadboard computer (BBC!) with bespoke programming language, full graphics, sound and SD card storage.

Public Chat
Similar projects worth following
Update May 2022: Real-time clock module added and FAT16 now uses timestamps.

65c02 breadboard computer, fully featured with sound, video, I/O and custom programming language - dflat !

Self hosting and fully featured - just switch on and start programming, like the heyday of UK micros in the early 1980s.

Key features:
Core WDC 65c02 @ 5.36Mhz, 128KB SRAM, 64KB EEPROM, 1KB memory mapped I/O
Video: TMS9918, 16KB SRAM
General I/O: 2 x WDC 65c22 driving AY-3-8910, SD Card SPIO, BBC Micro Keyboard I/F
Serial: 6551 ACIA @ 19200bps
Sound: AY-3-8910 plus Atari joystick interface
Case: Physically hacked BBC Micro case!
Storage: 1GB SD Card with FAT16 filesystem
Programming: dflat - a structured BASIC interpreter with support for video and sound.

Update Q1 2022

I will try to keep this section of the hackaday site going with short updates for any interested folks.  The most recent update is about the real-time clock.

Realtime clock

I wasn't that bothered about adding a realtime clock until I had got to being 'almost complete' with the FAT16 handling. After using the filesystem for a while it becomes obvious that one needs the timestamp on files.  I decided to use a period part from the day, the Dallas DS12887 which was found on most PCs in the early-mid 80s.  The problem is that these units have a built-in battery and they eventually die.. the solution I learnt from research is that some clever folks found that one can cut away the packaging to expose hidden pins that give access to the battery power terminals - and then hack on a button battery such as a CR2032!

The actual biggest pain is the CPU interface - the DS12887 is not directly compatible with the 6502 bus signals, but again after a lot of research, I managed to find the right configuration.

Then came the low level software - OS routines to get and set the time (plus checking if the clock it ok on boot up).  After that I could code the filesystem timestamp handling - both to set and get the time.  It's actually a bit of a pain on an 8 bit only CPU!

In-line assembler 

This now means I have a lot of power when I need it - for example being able to run off interrupts.  I am quite pleased with how I ended up slotting this in to the interpreter.  The interpreter stores all keywords as tokens to speed up execution and tokens are identified by bit 7 being set in the code.  This means 128 tokens maximum - which is fine for BASIC, but as there are at least 56 mnemonics in the 6502, I wouldn't be able to treat them as normal tokens.

My solution was that the inline assembler is a kind of sub-interpreter, invoked by the main interpreter whenever it encounters a '.' (dot) symbol as the first non-whitespace character.  At that point the in-line assembler does the decoding etc.  So 128 token limit side-stepped.

My other problem is how to treat labels and variables.  I decided fundamentally to use the same variable name space as the main code - which is handy because variables can be set in BASIC and then used by the assembler.  This makes for a potentially very powerful macro assembler.

My final problem was resolving address locations.  Some addressing modes of the 6502 are ambiguous such as zero page and absolute - no way to tell which addressing mode you want until the address is known.  But if that address was coming from a variable which could be a forward reference and hence has not been declared yet then what to do?  The solution is to do one pass where you assume everything unknown is zero page, then a second pass with forward references filled.  This may result in some zero page modes becoming absolute - which takes an extra byte.  If this happens then all the forward references are now wrong, until they are reached and the value updated!  The solution is to do a third and final pass which uses the correct values.

Hence the reason this is a 3-pass assembler.

What can I do with this that was not possible in BASIC?  Well aside from the obvious massive speed increase, it would be impossible to do effects like this, which rely on handling interrupts and micro-second precision to change video memory settings.

(Nov 2018) - Enhanced memory map and decoding - 128K RAM and 64K ROM

I'll copy the notes from my schematic by way of an explanation..


My computer uses 16K ROM and 48K ROM (minus addresses mapped to IO), but I have 64K EEPROM and 128K SRAM chips on the breadboard.  The 65c02 can only address 64K through its 16 bit address bus, so the route I will go down is memory banking - the ability to switch out different parts of the total...

Read more »


Latest source, binary and build scripts. A very short readme too.

7-Zip - 241.46 kB - 10/25/2020 at 21:20



New decode logic for 128K RAM and 64K ROM. Note the source files are still for the original decode logic, will replace that in due course.

Portable Network Graphics (PNG) - 31.63 kB - 11/19/2018 at 21:31



Tetris program file as an example of a fairly large dflat app. This program uses sound, graphics and sprites, plus string and numeric array handling. So it shows off a number of the key features. To open this, just use notepad++ or similar.

prg - 14.40 kB - 02/19/2018 at 00:02



The TMS9918 pin out is configured for DRAM, which is hard to come by and use these days. Tom LeMense gave me permission to add this to my project archive. Many thanks to Tom for his work and generosity.

Adobe Portable Document Format - 563.32 kB - 07/04/2018 at 15:59


  • 1 × WDC65c02s Modern 6502 made by Western Design Centre, runs up to 14MHz
  • 1 × TMS9918a Texas Instruments VDP found in the TI99/4a and MSX computers (the 'a' variant)
  • 1 × Micro-SD breakout board by hobbyelectronics Small board with a micro SD slot and SPI pins that can be bit banged through a 6522
  • 1 × W27c512 EEPROM EEPROM - anachronistic for an 80s computer, but essential for productivity!
  • 1 × 128KB SRAM (628128) - For main RAM SRAM is anachronistic for an 80s computer, but DRAM was going to be too painful

View all 10 components

  • dflat programming

    6502Nerd05/30/2016 at 13:50 0 comments

    I have decided to start a new log dedicated to dflat, the programming language I have built. I'll tidy up the other logs for duplication, but here will be detailed information and demos to show the capabilities.

    I had an initial video of a demo space invaders type game on youtube but decided to replace it with something more extensive and some commentary which I hope helps. This is basically a complete game, takes up around 6500 bytes of source code (which is tokenised to around 4500 bytes in memory). It's extremely rudimentary, but about the quality of type in games found in magazines of the early 80s, so I'm not too embarrassed by the effort. During the programming of this game, I had some strange things occur which I traced back to a couple of serious bugs in dflat around the saving of state when calling a procedure - luckily not too difficult to fix.

    I am still impressed with the speed of dflat. My old Oric-1 would have struggled..

  • Storyboard

    6502Nerd03/29/2016 at 23:27 2 comments

    Ok, so this part is not so much a blog, but a place to throw up the storyboard of my project through photos I have been taking from the beginning to present.

    So I started very basic. I don't have pics of the 6502 in a free run set up, but the following images give a flavour of just how bare-bones it all started..

    Clock and reset circuit, amongst the first thing I built and can be seen in the current set up. What's that tiny vero board on the right with a screw sticking out of it? Well it is my original power supply - stepping down from 9V to 5V. That screw is a heat sink!

    Initial decoding logic - don't even ask me what I was thinking! This has definitely not made it through to the current set up, in fact I never got to using it as realised it had impractical (or at the least worrying) levels of delay due to the number of cascading chips I was using.

    When I got hold of a TMS9918, I tried to work out if it was alive with a little free-run circuit. All it proves is that the TMS is getting power and a valid 10.738Mhz clock signal, so not really that useful with hindsight..

    This next pic looks like quite a jump, and in a sense it was - the main layout is taking shape. I decided to try and organise a central address and databus section around which I could wire up the necessary ICs. This board only has some ROM wired up but with an oscilloscope snooping the CPU address bus, I could verify that a programe was running and therefore, it lives! As can be seen, I am using a Winbond 27E512 (later on I stuck with a 27C512, but same wiring).

    Talking about oscilloscopes, I thought I shoud put up the core tools I used (and still do). First the oscilloscope. I had a 2Mhz bandwidth handheld puppy, but it was inadequate so invested in a USB connected one with dual channels. Without this I definitely would not have got the board running with all the components I have today.

    Next, I have a EEPROM programmer. I did try to go down the authentic route and got myself some EPROMS, programmer and UV eraser! The edit/program/test/erase cycle was depressing so quickly moved on to the BATUPO - I tried some cheap far-East programmers (Top-Win anyone?) but this was and is way more reliable. This is now the most used tool of course as it's all about the software..

    The other thing I needed was a TV capture device. For a while this worked fine, but the delay on this is horrible, so now am using a regular LCD TV (as I have space in the office because we moved to a larger place in Summer 2015). Still, the TV Out was useful initially when office and desk space was at a premium.

    I ran out of USB ports - Programme, Scope, TV Capture. And that didn't leave room for a serial port! So I needed a USB hub.

    My initial board was serial only using the 6526 (from a non-function CBM64) to bit-bang the serial line. I managed to get 9600bps reliably, before deciding to do things more properly and implement a 6551 ACIA. The board in this pic has ROM, RAM, 6502, 6526 all working well, with serial I/O the only means of communication. Even so, there is quite a lot of breadboard building up here, and it is starting to get awkward / delicate in moving it.

    I sent the following picture to my friend (sadly he passed away too young) when I was explaining the basics of what I had got going. The breadboards are now stuck to a plastic chopping board to keep them together! This is very much the current set up, but with sound added and the IO chips are actually 6522 VIAs rather than 6526 PIAs. The original clock and reset circuit is bottom left.

    More recent pics to follow..

  • dflat - a computer language

    6502Nerd12/16/2015 at 19:12 3 comments

    Update September 2016 :

    I've added a token table which describes all the tokens that dflat understands - basically this is the list of statements, commands, functions and operators.

    Core Features

    The core features of dflat are:

    • Integer only maths - just the 4 basic operators, plus comparison, shift and logical OR and AND
    • Line numbers only used by the editor to store program lines in a sequence - no dflat commands directly refer to the line numbers.
    • User defined procedures with parameters which can be made local. This is heavily inspired by the way BBC Basic did things.
    • Simplified variable naming: Every variable has a prefixed type qualifier (e.g. %a is an integer variable). The opportunity with this is to perform easier syntax checking and runtime execution, which it does - sort of.
    • Conditional and looping constructs : IF..THEN..ELSE..ENDIF, REPEAT..UNTIL, WHILE..WEND
    • Array handling of scalar (integer variables) and strings. Integer variables can be 2 dimensional, strings can only have one dimension in addition to the length dimension that every string must have (this approach is inspired by Atari Basic)
    • Execution can start at any procedure invoked from the command line - my own convention is to use "_start()"


    I thought perhaps I should just dump the keywords, functions and operators that dflat supports. Anyone with a memory of BBC, Atari or Oric BASIC will know most of these commands.

    Current list of supported symbols:

    • print, println : prints a sequence to output device, with or without new line
    • def, enddef : define a procedure start and end
    • dim : dimension one or more variables (up to 2 dimensions)
    • repeat, until : repeat a section of code until a condition is true
    • for x,y,z, next : initiate an iterative loop with starting value x, end value y and step size z. Works like a BASIC for loop but the variable cannot be specified in the next keyword
    • if, else, elseif, endif : execute a section of code if a condition is true, else execute another section, else execution another section if another condition is true. Control passes to the next statement after endif.
    • list : list the program
    • load 'x', "file" : load a dflat program named "file" from device 'x', where x==0 means the serial port, and x==1 means the SD card
    • save 'x', "file" : save a dflat program names "file" to device 'x', where x is as above
    • input : take a stream of CR terminated characters and put in a destination variable (e.g. input $a)
    • mode x : change screen to mode x, where x=0 means 40 column text mode and x=1 means 32 column colour mode
    • plot x,y,c : at coordinates x,y plot character c. If c is an integer then plots the byte value, else if c is a string then plots the string from x,y
    • cursor x : Hide the screen cursor (1) or unhide it (0)
    • cls : clear the screen
    • poke a,x, doke a,x : single or double byte write of value x to memory location a
    • peek(a), deek(a) : single or double byte read from memory location a
    • stick(x) : read joystick, and with mask x (to allow only a certain signal to be tested for). The joystick signals are active 0 as follows : bit 7 = fire, bit 6 = left, bit 5 = right, bit 4 = up, bit 3 = down.
    • key(x) : read a key from the input stream synchronously (x=1) or asynchronously (x=0)
    • setvdp reg, val: Set VDP register reg to value val (low control of the VDP is possible with this command)
    • sprite sp, x, y, ch, col : set sprite number sp to position x,y using character pattern ch and colour col
    • spritepos sp, x, y : set sprite number sp to position x,y
    • sound ch,per,vol : set tone channel ch to period per and volume vol. If vol == 0 then channel will use envelope to modulate volume. If ch == 0 then set the period of the noise channel (vol is ignored)
    • play te, ne, env, per: set up the tone and envelope configuration. te = 3 bit number for tone enable, ne = 3 bit number for noise mix with each tone channel, env = 4 bit envelope setting, per = 16 bit period.
    • music ch, oct, note, vol: play music on channel ch, with note (0-11) and octave oct (0-6) and volume vol (0-15)
    • left($a,%x), right($a,%x),...
    Read more »

  • SD Card Interface

    6502Nerd10/17/2015 at 12:46 0 comments

    Latest Update - Optimising SD Card send and get byte routines

    I have been tinkering with the SD card low level routines. It was bugging me that when I wired up the SD card pins, the MISO line was attached to pin 2 Port B of one of my VIAs. MISO stands for Master In Slave Out - i.e. the output from the card, which needs sampling bit by bit to retrieve data serially. In addition the output from my machine to the card (MOSI - Master Out Slave In) was coded rather hamfistedly.

    So I resolved to eliminate this worm in my brain this morning. I swapped the MISO line to pin 7 and moved the CLK line to pin 7. So what? Well know when I read the Port B register, I don't need to do a bit test for the MISO state - the N bit of the 6502 will be automatically set. So I can use this feature to optimise the code.

    Here is the new code to get a byte. The inner loop which is called for each bit is a maximum of 29 clock cycles. The previous code (see further down in this log) is a maximum of 37 clock cycles. So 8 clock cycles per bit doesn't sound like much but this routine is used constantly when reading or writing from the SD Card. The clever bit is the CMP - this is used to do a test subtraction which will set or clear the carry flag which can be used to directly shift in the correct bit without cumberson bitwise tests or operations.

    	lda SD_REG
    	ora #SD_MOSI			; Set MOSI high
    	sta SD_REG
    	ldy #8				; Shift in the 8 bits
    	ora #SD_CLK			; Toggle clock line
    	sta SD_REG			; Low->High
    	lda SD_REG			; Sample SD card lines (MISO is the MSB)
    	eor #SD_CLK			; Toggle clock low
    	sta SD_REG			; High->Low
    	cmp #SD_MISO			; Trial subtract A-MISO, C=1 if A >= MISO else C=0
    	rol tmp_a			; Rotate carry state in to tmp_a
    	dey				; Next bit
    	bne sd_shiftinbit
    	lda tmp_a			; Return response in A

    Here is the new code to send a byte. The inner loop here is 33 clock cycles, the previous code (see old entry further down) is 38 clock cycles. Only 5 clocks per bit - but 8 bits per byte, so 40 clocks saved per byte to send. Sending 10,000 byte saves 400,000 clock cycles which @ 2.68Mhz is 0.15 seconds saved.

    	sta tmp_a		; For shifting out
    	ldy #8			; 8 bits to shift out
    	lda SD_REG		; Load the SD register to A
    	ora #SD_MOSI	        ; And initially set output bit to '1'
    	asl tmp_a		; Unless the bit to transmit is '0'
    	bcs sd_shiftskiplo	; so then EOR the bit back to 0
    	eor #SD_MOSI
    	sta SD_REG		; Save data bit first, it seems, before clocking
    	ora #SD_CLK		; Set CLK bit
    	sta SD_REG
    	eor #SD_CLK		; Reset CLK bit
    	sta SD_REG
    	dey								; Count bits
    	bne sd_shiftoutbit				; Until no more bits to send

    I did some hand timings of saving a large dflat program (Tetris), which is almost 15,000 bytes of code. Using the old routines, the time to save was an average of 8.5 seconds. Using the new routines which take advantage of the rewired MISO line, the average is 7.9 seconds. So I am pleased with this :-)


    I have got my head around FAT16 well enough for basic file handling. The system can now:

    • DIR : Perform a directory listing, showing only files (not anything with special attributes, and ignores Long File Names)
    • Open : Equivalent of the MSDOS 'Type' command - outputs a file to the screen / terminal. I've tested this with 200KB+ files, which shows that the software is correctly iterating through multiple SD card sectors as well as FAT16 clusters.
    • Save : Saves a region of memory under a filename. This shows the software can correctly fine space in the directory table as well as cluster tables to create a new file
    • Del : Deletes a file, which requires marking the file entry in the directory table and then updating the cluster table to mark all used clusters as free

    The good thing about FAT16 of course is that I can transfer files between my homebrew and PC. This means I can assemble a binary on the laptop and then copy it to SD card for loading and running on the homebrew....

    Read more »

  • Sound

    6502Nerd06/14/2015 at 12:58 0 comments

    For my homebrew to have a reasonably complete set of features, I really want some sound output capability. For the retro and nostalgic feel, I chose the AY-3-8910. This is a common sound part from the 80s, and was the sound chip in my very first computer, the Oric-1. It was also used in MSX and some other 80s devices (even in PC sound cards and arcade machines iirc).

    Wiring up an 8910 is fairly straightforward, however it cannot be driven directly off the 6502 address and data bus. The reason is that the 8910 has some bus control lines which are more compatible with the processor family that General Instrument (makers of this part) also used to produce.

    To drive the 2 lines (BDIR, BC1), I have to use some lines from the second 6522. In addition, the data lines also need to be driven off the 6522. This is annoying, because I am having to use 10 of my 16 data lines just to drive the 8910. Also, this is really slow, for example a write sequence looks like this (assuming that X contains the 8910 register to write a value contained in Y:

    • Set Port A (this port is connected to the to the 8910 data bus) to output
    • Write X to Port A (this puts the register address on to the 8910 data bus)
    • Set Port B bit 0 and 1 (these bits are connected to BDIR and BC1 on the 8910) to latch register mode
    • Zero the Port B bits to enable the next command
    • Write Y to Port A (this is the value we want to set the appropriate register to)
    • Set Port B bits to write mode to effect the transfer in to the 8910 register
    • Zero the Port B bits ready for the next command

    So this is a lot of writes just to set a register in the 8910. And several registers need to be set to be able to make a sound! But I have tiny sense of personal achievement that I'm understanding the challenges that the engineers at Tangerine had when they designed the Oric-1 (similar solution).

    One useful thing the 8910 does have 16 I/O ports, so that kind of makes up for having to use the 6522 ports to drive it - although getting data in and out of these ports is slow.

    However, these I/O lines will be good for human interface devices as they are much slower than serial or video access. Hence, I am using the port for the 80's Atari compatible joysticks. These need 5 lines (4 directions plus fire button), so I could add more than one joystick (might be useful). For the moment I have stuck with 1 joystick only.

  • Video Output

    6502Nerd05/24/2015 at 23:29 17 comments

    Update June 2017

    The built in language I have devised (dflat) support VDP capabilities directly such as changing colours, manipulating sprites and setting text vs graphics mode. However it doesn't have any high resolution support and that was ok when I was using the TMS9918, but now that have the TMS9918a variant which supports 256x192 bit map graphics, I thought about how I can access this.

    With ROM space tight, I realised that actually I have the ability to do low level access through the commands 'setvdp', 'vpoke' and 'vpeek' - these access the VDP registers, write to VRAM and read from VRAM respectively.

    So I wrote a short demo program in dflat which uses the low level access to show how high resolution bitmap graphics can be accessed. The result is in the following video:

    Update end-March 2016 : short anecdote..

    I had a little disaster with the video hardware, although it's ended (sort of ok). The hardware has been working very well for a while so I have been focussing on system and programming language software. However the last time I sat down to do some work, the video output seemed to be going haywire. I won't go through the whole story, but the root cause turned out to be my ground (!) line had broken loose from my USB header. The computer would only fire up if connected to the TV (presumably it was using the TV ground), but the video was messed up. Initially I started prodding about the VDP as breadboard connections can come loose. I pulled the VDP out once or twice in the process of troubleshooting, which is when the disaster occurred - one of the IC legs (pin 20) broke off after one too many insertions and removals. I have a TMS9928 but that doesn't give me composite colour out and I really didn't want to make up a new lead (yet). So I had to carefully solder a fly lead from the just visible connection on the IC for pin 20. See below - amazed that it worked. I think the days of this VDP are numbered and I will start making preparations to install the 9928a. The main difference is that the '28 supports RGB output - but also I am not using the 'a' variant of the 9918 so I will also have access to a full bit-mapped graphics mode.

    ** Update : The 9928a proved difficult to interface to a monitor with component input (not sure what I was doing wrong) - so decided to install a 9918a, which is the actual variant used on the Ti994/a and first generation MSX computers. **

    As I have previously mentioned, I really needed to have video output for my homebrew that was 80s in style and capability. I poured over a number of options including:

    • 6845 as per BBC Micro, Amstrad CPC
    • 6847 as per Dragon 32
    • Self generated as per ZX80!

    The 6845 and 47 to me seemed daunting as my knowledge of digital hardware is so basic, so I discounted those.

    I did a fair bit of research in to self generated video - partly inspired by Quinn Dunki's attempt using an AVR. However I didn't have an AVR so was going to use a second W65c02s running at 8MHz - I calculated that I could just about generate a 176 pixel monochrome display if I was very careful with instruction cycle counting. However, I was not sure about the ability to generate the synchronisation signals as this would need something like a 6522 or 6526 and they may not be able to keep up with the display processor. Anyway, to cut a long story short, I decided this option had too many unknowns and I could end up spending a lot of time building something which would not work or ever be expandable.

    In my search I did keep going back to the TMS99xx series of Video Display Processors. These were commonly found in the TI99-4/A and MSX range of micros in the 80s, although Colecovision and other consoles also used it IIRC.

    The great thing about this VDP is that it as separate video memory, which means my main computer has more to RAM to play with. Also, it has some pretty good features considering it was made in the late 70s including up to 32 sprites, 15 colours and multiple display modes (32x24 column text, 40x24 column...

    Read more »

  • Serial Communications

    6502Nerd05/24/2015 at 13:43 3 comments

    Serial Input / Output

    One of the key methods of input and output with my home brew is serial communications to and from my development machine (a modern Windows 10 laptop).

    The serial commmunication protocols I remember from in the 80s and early 90s was RS-232. I naively thought this would be the thing to use now. However, my development machine does not have serial ports - USB is now the only serial methods I have at my disposal.

    A bit of research revealed that direct USB to homebrew connectivity would be difficult (at least for me) to achieve. However, the popularity of kit like Arduino and Raspberry Pi have helped the proliferation of USB to serial cables with built in adapters. I purchased a very cheap one off ebay. It means that when connected to my dev machine, an additional COM port in Windows is available, through which I can use a terminal emulator. On the homebrew side, the cable presents 4 pins : +5V, GND, Serial Out, Serial In. This means I also have the ability to power my homebrew off the 5V supply rather than using my home-made 5V supply (interesting mini-project, but clunky).

    My original serial comms was designed around using the SP pin on each of the two CIAs for input and output. However, it required a fairly software intensive set up to drive and I wasn't happy with the reliability of it. Plus, I wanted to use the CIA lines for other expansion options.

    So I added a CMD 65c51 ACIA. This is a fairly simple to operate serial input/output device, and being part of the MOS family, easy to interface to the 6502. I will keep the rest of this section for historic purposes.

    The software programming of the CIA was simple and it was easy to update the few low level I/O routines. However, it still took me ages to get it working because the ACIA needs a 1.8432Mhz clock. As this is not a muliple of my 21.7MHz, it needed it's own clock circuit.

    So I obtained an appropriate crystal and wired up a 7404 using a circuit diagram off the internet. I checked it with the scope and it looked like the circuit was putting out a clean 1.8432MHz square wave. However the ACIA was not working, no matter what I did. I then noticed some unusual behaviour - for example if my finger touched the crystal, suddenly the ACIA would work and continue to work. Even putting my hand near the ACIA seemed to kick it in to life - very, very weird.

    I put it down to the clock generator circuit. I have not spent any time trying to understand the most analogue part of the home brew which is the clock generators using piezo effects generated by crystals. So I had no idea what to do, but after further searching found an alternative circuit which starts up without requiring the touch of a finger or a magic wave of the hand!!

    Old CIA based Serial

    The two 6526 CIAs in the system provide serial communications. Even though each CIA has a SP pin for serial input or output, the USB to serial adapter I am using has a dedicated pins for send and receive. I wasn't sure how to wire up a single SP to two pins on the serial interface, so I decided to use one 6525 for input and the other for output.

    Serial Input

    I started with designing serial input. The mode of operation is as follows:

    • Set up the CIA so that PB6 acts as a clock, running at Timer A underflow speed and the SP pin is configured for input
    • Connect PB6 to the CNT line which provides the clock for sampling the serial input line
    • Connect the /FLAG pin to the Serial input line. This means I an configure an interrupt to occur if the serial line goes low. The default state of the serial input line is high, with a zero start-bit indicating the start of a transfer.

    The software to run this is fairly simple. In pseudo code it looks like this:

    • Wait for /FLAG to go low (this can be through an interrupt or polling the CIA ICR)
    • Wait 1/2 a bit time - this is to try and sample in the middle of a serial bit
    • Initialise Timer A to 1/2 the bit time required and start in continuous mode, PB6 to toggle Timer A underflow. At this point the CIA is starts...
    Read more »

  • Software Design

    6502Nerd05/16/2015 at 18:11 0 comments


    I have updated my monitor program, with some additional commands and it is more of a command line style rather than single letter commands:


    Directory listing

    LOAD <addr> <file>Load from address <addr> the file <file>
    OPEN <file>Open the file <file> and output to the current output device
    Set memory type to VRAM (V) or normal memory (M) all memory commands
    act on this memory type
    SET <addr> <xx>*
    Set the memory from address <addr> to bytes defined in <xx>. A sequence of

    more than one byte can be written.

    DUMP <addr>
    Dumps 8 byte blocks from address <addr> with an ASCII readout. Enter continues

    the dump for another 8 byte block, any other key stops the dump.

    WATCH <addr>*
    Watches the memory at <addr>, outputting bytes to the output device until any

    key is pressed. More than one address can be watched.

    SECTOR <addr>Load sector <addr> in to memory. Useful for low level inspection of SD cards.

  • Hardware Design

    6502Nerd05/16/2015 at 18:10 0 comments

    In terms of hardware design, I realised that there are not really that many parameters one can play with when using off the shelf components. The point is that things like the 6502, 6526, 6522, 9918 etc. are by design expecting certain inputs and outputs, so they set out some fundamental design constaints.

    The general input, output and interfacing capabilities provided by the 6522s (two of them) and the memory map design are the two most significant areas for creativity.

    NEW Memory Map

    For the old memory map, see that heading.

    The reason for this new section is that I had the old memory map running since basically the beginning, and has served well for more than a couple of years.  So why change it?  Well, a number of reasons:

    • I have a 128K RAM chip and 64K ROM chip
    • Old memory map only addresses 48K of RAM and then minus 4K window for memory mapped IO
    • Old memory map only addresses 16K of ROM
    • Less than 1K of ROM remaining, limiting further ideas for functionality such as extending the interpreter (more hi-res commands, floating point support) and OS (better support for FAT, bigger cards etc.)

    So I went ahead and came up with a new memory map with the following features:

    • Smaller IO window of 1K still supporting 8 devices in 128 byte sections
    • Any write to ROM space will write to the shadow RAM at the same address
    • Ability to disable ROM to get full read and write access to RAM across whole 64K (except IO window of course)
    • Ability to map top 32K of RAM to any 4 positions in RAM, so having access to all 128K
    • Ability to map top 16K ROM access to any 4 positions in ROM, so having access to all 16K

    The way I have done this is to take spare lines from the two 6522s I have, one will be ROM disable, two will be to select the RAM bank and the other two to select the ROM bank.  The actual decode logic is in the downloads.

    I now have plenty of opportunity to expand my project, especially so with the additional ROM space.

    However although the hardware is done, I need to reorganise the software radically for example:

    • One cannot simply change from one ROM bank to another, it would be pulling the rug from underneath the CPU.  It has to be organised so that the CPU is still executing expected code after a switch.  The easiest way to do this is have common switching routines across all ROM banks

    The new decoding logic is available to view in the downloads section.  It will take a while to reorganise the software though e.g.:

    • Create a new common section
    • Determine what banks will have what responsibilities e.g. BIOS, File System, Interpreter, Graphics, Sound, Utilities
    • Rebuild the make file to assemble images in to a 64K ROM (at the moment I am simply copying the same 16K four times, so I have no extra usable ROM space)

    It will take a little thinking through but once implemented, I will have loads of available ROM to fill - should keep me busy with the project for a many more months!

    OLD Memory Map

    The memory map was one of the first and most interesting areas of investigation. The 6502 has a 64KB address range - so all my RAM, ROM and memory-mapped devices need to fit in to that. Being old-school, I wanted to try and put together a map which maximised RAM without overly compromising ROM and memory-mapped device access.

    In the very early incarnations of the homebrew, copied the simplest address decoding approaches I found in other designs:

    • If A15 is zero, then select RAM
    • If A15 is one and A14 is one then select ROM
    • if A15 is one and A14 is zero then select devices

    So this gives 32KB RAM, 16KB ROM and 16KB devices space. I had a board working with this configuration, but it was just to allow me to prove I had wired things up.

    I went for an addressing scheme which would give me 44KB RAM, 4KB devices (8 512 byte IO blocks) and 16KB ROM. It was fun coming up with the decoding logic for this and then working out how to implement this using some NAND and NOT gates.

    SectionTypeAddress RangeDecode rule A15-A12 (binary)
    AROM0xc000 - 0xffffBetween...
    Read more »

  • The Basics

    6502Nerd05/16/2015 at 10:21 0 comments

    Although this is an on-going project, I have been working on it for over a year before publishing anything, so I'll try and capture some of my approach, experiences and lessons learnt to bring this site up to date.

    One thing I have been doing over the life of this project is trying to do it on a shoe-string budget. That's just the way I am - a bit of a tight-arse who likes to think he's got a bargain of some sort! However whilst being budget conscious is great in nearly any setting, it has to be with some level of pragmatic trade off and risking the saying of 'buy cheap, buy twice' coming in to effect. So I learned by trial and error the right budget trade off! I don't know how much I have spent on this hobby, but I am sure it has to be approaching £250-300 by now.

    In the beginning..

    I started off with literally nothing - no components, no tools, no experience. But I did a lot of reading. The internet is fantastic, so many people willing to put their experience and knowledge out there on the web for the rest of us to benefit from. I can't possibly remember or list every resource I have examined, but over the course of this project has been a fantastic well of knowledge.

    Initially I needed to get some kit together. I bought a bunch of basic components (resistors, capacitors, transistors, 555 timers, crytals, LEDs etc.) with some wire (solid core, multi-colour). I also decide to use breadboards to try out my experiments (as they were right at the beginning). I love breadboards, but I'll mention some of the problems I have with them later, they're not all good!

    Despite working in IT professional services - where I often have to spend weeks or months architecting and designing solutions - I spent virtually no time thinking about the design features of my computer (perhaps it was a back-lash to my day job!). I had some key features in mind, some mandatory otherwise it wouldn't be a functional computer, and some that I wanted to make it useful. What useful meant was the ability to program some 1980s style rudimentary video games, complete with sound effects. So the features:

    • It had to have a CPU (!), a 6502 one (see below)
    • It had to have memory (!), but how much I hadn't decided
    • It had to have some IO (!), but for what purposes I hadn't decided
    • It had to have video graphics output. I had homebrews which used small LCD panels or no video at all - this wouldn't for me as I wanted to be able to play video games on it!
    • It had to have sound output output. Again, I had seen homebrews which didn't care much about sound, but I wanted this.


    So, I had some basic electronic components, but no complex ICs like a CPU, memory etc. Looking through a number of existing homebrew sites, I could see a variety of CPUs had been used including 6809, 8080, 68000.

    However fascinating these other projects were, I had already resolved to use the 6502 at the heart of my project. The reason is straightforward nostalgia. My first computer was a 6502 based micro called the Oric-1, bought for £80 in a knock down sale in 1984. I was 13, and knew nothing about computing, but convinced my hard-up parents that I needed one, and this was in the right price bracket (i.e. really, really cheap). But this computer took me from never having written a BASIC program to being able to code assembly in hex (because I couldn't afford an assembler - eventually wrote one for myself). When I grew out of the Oric-1, I got an Atari 800XL in 1985, which was also 6502 based.

    Aside from nostalgia, I could see that with everything else I was going to have to learn to be able to build my own computer, having something I was already familiar with would be a good thing.

    The first one I bought was off ebay (where most of my acquisitions of components etc. were made) - a CMOS based Rockwell model. However, during my investigations, I also found out that a company called the Western Design Center was still producing 6502 CPUs which could operate at much higher clock speeds than the...

    Read more »

View all 10 project logs

Enjoy this project?



Denjhang Liu wrote 01/15/2022 at 10:29 point

Can you provide a schematic diagram?

  Are you sure? yes | no

6502Nerd wrote 02/22/2022 at 09:45 point

Hi and thank you for your interest!  I will add some diagrams to the gallery - I don't really have a full schematic but do have a block view and a detailed view of the address decoding, which is the most important feature here as it also handles the banked ROM/RAM.

Thanks again for looking at my project! :-)

  Are you sure? yes | no

Nate Rivard wrote 02/22/2023 at 16:35 point

I'm looking to integrate a TMS99xx (actually a TMS9128) so do you have a schematic for just this subsystem? Many have said running the 6502 > 2mhz means you are out of spec with VDP data access times.

  Are you sure? yes | no

Gabor wrote 05/19/2021 at 08:57 point

OMG :)

  Are you sure? yes | no

6502Nerd wrote 05/19/2021 at 13:15 point

Haha - thank you!!

This has been a great project for me - everything from designing the hardware to all the software.  Most complex parts were the interpreter (dflat) and the FAT16 file system.

By the way - I saw your 4-bit CPU project.  Fantastic!

  Are you sure? yes | no

Marc Piulachs wrote 06/23/2020 at 13:10 point

Hi, nice project! I have been studying your source code (and trying to learn from it!) , I'm also working on a much simpler design but it uses the same CPU and Graphics (6502+TMS9918) as you so my intention was merging your vdp, graphics code as a starting point, I'm using the most recent version of cc65 and I'm having lots of compilation/porting problems, is your code using an ancient version of the compiler? 

  Are you sure? yes | no

6502Nerd wrote 10/24/2020 at 21:19 point

Hi Marc

Firstly - so sorry this reply is late. I have checked these comments and for some reason only noticed it now. But many thanks for your kind comment :-)

Yes my code built using the as65 assembler by Kingswood Consulting.  You can download it from this link:

I noticed that the terms actually allow me to freely distribute it along with its accompanying docs - so I am going to update the files with this.

The 6502 syntax is pretty standard I think so the main issue you will face is in the directives and approach to macros.  You can keep porting to cc65 or just use as65 - your choice.

I hope my code base is useful to you - very interested in hearing about your project, maybe you've got it all sorted by now.

Cheers, 6502Nerd

  Are you sure? yes | no

Alexander wrote 03/23/2019 at 00:39 point

Awesome project! I've started to build a homebrew computer about 3 or 4 times but I always get distracted by other projects... I need to just sit down and finish one! Cheers.

  Are you sure? yes | no

6502Nerd wrote 03/25/2019 at 07:12 point

Thanks for your kind comment!  What I did was to start simple then add capabilities. So initially just the bare machine with just serial IO, then added video, sound, SD card and real keyboard over a few months. It's a hobby for me so doesn't really ever gets finished!

  Are you sure? yes | no

villaromba wrote 07/15/2018 at 19:56 point

I have looked through your project and found it very interesting. I have built a number of Z80 (Cp/m) projects but this looks like a welcome change !! Are there circuit diagrams for this project - can't seem to find them ? Many thanks - Colin

  Are you sure? yes | no

6502Nerd wrote 07/23/2018 at 21:00 point

Hi Colin,

Apologies for the long delay, summer holidays in the UK and then out of the country on business (no rest for some..).  But I'm delighted you found my project interesting, thanks for taking the time to post.  Although I have not been the best at documenting the details of my project, I have recently with the help of the clever folks on forum redesigned the decode logic to enable the faster clock speed (from 2.68Mhz to 5.36Mhz) and I will put that logic up there.  Together with Tom LeMense's excellent write up on using static RAM with the TMS9918, you will have a large chunk of the design.  However, I will put up a more comprehensive design in the near future (basically when I have a few hours to draw up the diagrams!).  I hope the additional upload of the decode logic helps - please feel free to come back with any more questions, and good luck with your projects :-)

Cheers, Dolo

  Are you sure? yes | no

villaromba wrote 07/24/2018 at 08:05 point

Thanks for reply Dolo. I hope to make a start on this project when things are a bit cooler (I too am in UK!) and look forward to more details in due course. I will also look into sourcing the parts which hopefully are still available.

  Are you sure? yes | no

twitt11 wrote 06/26/2018 at 07:57 point

I cant contribute to this topic because im almost level one hacker but your work fells much satisfying,bravo! I mean the was a link found revelation for me and still i fell bad because ill never have a knowledge to do something like you guys do here. It is soo advanced and the projects are the real eye catcher.

I hope you guys will hack those 80 world leading bastards one day and for sure make an irreversible damage to them.  :)

  Are you sure? yes | no

6502Nerd wrote 07/04/2018 at 15:58 point

Hi there - thanks for the compliment, much appreciated.  I did not have any knowledge or experience of building my own computer before I started this and I could never have done by myself.  But with all the information available and generous help and sharing of knowledgeable people, it is possible to build a simple computer for example a 6502 CPU with some ROM, RAM and serial input/output chip quite quickly.  And it is not too costly either.  From there, you will have the knowledge and confidence to build out further.  Good luck with your journey, we all have to start somewhere :-)

  Are you sure? yes | no

KD9KCK wrote 02/14/2018 at 03:06 point

Any updated Source for dflat?

  Are you sure? yes | no

6502Nerd wrote 02/18/2018 at 00:05 point

Hey there, have had a busy week at work hence the delay, but thanks for your interest.  I will upload updated source soon after a couple more tweaks.

It is greatly enhanced since that time for example supporting functions, recursion, better order of precedence, high resolution commands, some small performance optimisations.

Are you looking to use dflat in a project or for learning purposes?  Most of dflat is fairly machine independent, but when it comes to things like graphics, sound and keyboard then of course it is quite specific.

  Are you sure? yes | no

KD9KCK wrote 02/18/2018 at 00:26 point

Thanks for replying. I was sort of looking at if for both learning and a project.  Been designing my own CPU and was thinking dflat might be nicer to port then say writing a C compile.   Also the graphic stuff interests me too. (Want to see how it’s actually done.)

  Are you sure? yes | no

6502Nerd wrote 02/18/2018 at 15:49 point

If it is for a combination of using and learning, then let me tidy things up a bit in terms of comments - I haven't followed my own advice on comments and it can be hard to follow in some places.

Wow, you have built your own CPU - cool! So you will need to translate the 65c02 assembly to your machine language?  This will be very interesting depending on the differences between your CPU and the 65c02 (e.g. number of registers, addressing modes, variety of instructions).  Due to the comparative lack of registers (say compared to a Z80), the 65c02 isn't very code dense - meaning it can take more instructions than on a CPU with more complex instructions.

The core of dflat, without the machine specific stuff like I/O and graphics should run on any 65c02 without much modification - subject of course to setting up the zero page variables and required storage for language specific stacks etc.  The specific stuff for graphics, sound and I/O are generally coded in separate files - but at some point a dflat command e.g. 'sprite' does need to call hardware specific routines.

I'll post the update source later today - feel free to use (just mention me!) and if you have queries do ask!  Let's see your project too - sounds very cool :-)

  Are you sure? yes | no

George I Fomitchev wrote 08/15/2016 at 07:12 point

how much time it took you to make?

  Are you sure? yes | no

6502Nerd wrote 10/25/2017 at 11:32 point

Hi George - sorry for more than a year to reply to this comment, but if it doesn't help you perhaps it will help others!

The main activities were the initial learning and research, then building up the hardware, and then building out the software.  By far the longest time is has been the software.

I started this project sometime in late 2014 - so now it has been 3 years elapsed.  However this is a hobby, so not full time of course.  Sometimes only a couple of hours a week and sometimes much more.  I would guess that in the 150 weeks I have spent probably an average of 2 hours per week is fair.

So 300 hours!  The software has got to be around 200 hours of this as I built an entire programming language from scratch.

If this was a full time job, I could have completed in only 8-9 months.  But it has been very enjoyable.

  Are you sure? yes | no

unbonnevie wrote 03/19/2016 at 02:03 point

Schematics available?  Thanks!

  Are you sure? yes | no

6502Nerd wrote 03/21/2016 at 22:35 point

Hi and thanks for the skull.  I've been distracted with other things for a few days so not been on here for a while.  I don't have schematics as such but I have kept a document with details of all the components and connections, will tidy it up a bit and put on here at the next opportunity.

  Are you sure? yes | no

unbonnevie wrote 03/28/2016 at 05:15 point

That would be great.  My main interest is to see how you write the driver for the TMS9918 (VDP) chip.  I found on the net there is a schematic of interfacing the TMS9918 with a 32KB SRAM chip.  Thanks.

  Are you sure? yes | no

6502Nerd wrote 03/29/2016 at 08:01 point

Hi - if it's the VDP information you're after, then perhaps the video log will help you:

Also, on the 6502 forum, there is this discussion on interfacing the 6502 and 9918:

Hope that helps - there should be enough in there for you to connect up a 9918 to SRAM and get decoding and bus wiring to drive it with a 6502 (assuming that's the CPU you're using).

  Are you sure? yes | no

lezanderson wrote 11/24/2015 at 11:21 point

Awesome !!! Great project

Most Video Chips back in the eighties were quite bad, the 6847 being pretty dreadful even by the 1980s standard., using a TMS9918 for Video ?? perhaps the  V99x8 for video or even a V9990  might make more sense and still givie a very 80s Retro Feel !

  Are you sure? yes | no

6502Nerd wrote 11/26/2015 at 18:01 point

Hey lezanderson.  Thanks for your comments.  I think I may have bought some kits from you from ebay?  So they have made it in my computer - the RAM and ROM are from those kits I bought!  So I'm using the TMS9918.  I will write a simple game to show it all off and with sound soon.  Still writing the OS components at the moment.

  Are you sure? yes | no

lezanderson wrote 11/27/2015 at 09:54 point

Sounds even More Awesome !!

If you need any help sourcing ICs let me know !

  Are you sure? yes | no

6502Nerd wrote 11/15/2015 at 13:30 point

I am trying to replace the 6526 PIAs with faster 6522 VIAs.  The main control lines (Clock, R/W, /CS, /RES) are in the same place.  The only other difference is that the 6522 has another Chip Select active high - this is just tied to +5V.  So using my monitor programme to inspect memory, I can read the 6526 register file, but the 6522 returns the high byte of the address bus?  This makes no sense to me - literally have a 6526 and a 6522 plugged in at the same time - the 6526 seems to be responding, the 6522 just returns this weird data.  What am I doing wrong - any ideas?

** Update - see main pages. I had messed up selection logic, it is a wonder anything worked.  I was using Phi2 as an input to IO decoding, and this is not appropriate.  Only need Phi2 input for RAM chip select.  Most 65XX ICs have a Phi2 input anyway to ensure they do not content for the bus when the 6502 has it. Luckily it was a simple change to the logic **

  Are you sure? yes | no

Terry Raymond wrote 11/04/2015 at 23:28 point

Hey Im trying to approximate some MOS chips namely the Commodore Sid chip revisions:

6581R4, 6582, 8580R5  I have heard this is next to impossible with the older MOS chip manufacturing is extremely expensive, but how could I go about this with FPGA?

What all chip programmers would be needed etc.  BTW im new to FPGA.

There are other CBM MOS chips I would like to emulate:

4164 C=64 Motherboard Ram chips

REC REU Memory controller: CSG design was more of a square IC, these were used in the

Commdore brand of REU's (memory expander cartridges)  1750, 1764 etc.

MOS 1351 Mouse controller IC, keep in mind this somehow worked in conjunction somehow with the SID oscillator or the X or Y something in the SID?

The MOS packages as you know cannot be made anymore because of the high costs

of chip runs:  Whatever the amounts of runs MOS or CSG did like for instance a run of

SID chips would cost a Million dollars, yikes.

Anyway I have need of these chips with a possible business bulding hardware for the

C=64 and C=128 line of 8-bit computers and it requires these chips, as far as building a very

high quality of Hardware, but the chips are very rare.  The Sid chips could be pulled but

the 1351 is very rare these days.

Anyhow I really need some advice and where I could start, there isn't much open source

for C=64  and C=128 chips.

I would be open to any help or suggestions or any open source for FPGA?

doing open source is better you don't steal anybodys work that way, so as not to copy the

original chip mask.

Thanks all.


  Are you sure? yes | no

Howard Jones wrote 11/05/2015 at 12:06 point

Googling 'FPGA C64' brings up quite a few different projects! For example there is a working C64 core for the MiST FPGA host. My C64 mouse was an analog device with carbon tracks on the rollers, like a potentiometer - it plugged into the joystick port, and the analog inputs went to the SID, I believe. That must have been fairly standard, because I can remember using it with Art Studio...

  Are you sure? yes | no

Hacker404 wrote 11/06/2015 at 08:33 point

The Commadore SID is a difficult one. Here are the problems that I see- 

1) These chips have analog filers. I was going to use single bit digital conversion for this but that is a complex solution. 

2) The original spec that you will find on the net was different to what was actually manufactured. 

3) The manufacture then changed to a different spec that is unknown. 

4) There were bugs in the design and some programmers utilised the effects of these bugs so they now have to be included in any new design. 

We have Bil Herd ( bherd )here on HAD and he was on the original design team for the C64 and some other machines. You may ask him for some guidance.

I was going to give the SID a go but I need some specs or better still - an actual real SID chip (not some junk from China) to map out a specification for it. 

My plan of attack was to use single bit D to A conversion to drive an external capacitor and then use LVDS to detect the analog result and then back to single bit conversion for the rest of the digital stages. This would save a lot of complex external analog components but emulating analog circuits in a digital system is not the easiest of tasks.

  Are you sure? yes | no

Terry Raymond wrote 11/06/2015 at 21:48 point

Hey do you need a 6581R4AR?  I  may have an extra.  I may even have a dead 8580 SID do you live in the US I can send them to you?  The 1351 controller is what I need lots of info and the know how to 

figure it out.  i chatted with Bil Herd the other day but all he mentionec is that if one is using FPGA you

can only imitate MOS.  Can you use PLD I think Bil mentioned its the best for MOS.

My only other problem is getting certain tools etc What would I need?

Bil helped me to a certain extent but with FPGA Im lost, I know that FPGA will fill all the details for you but Im not sure how to startout in the code etc, or any other  parameters.  Im still learning the software and its 

confusing.  Maybe I can ask Bil how. 

Thank you

  Are you sure? yes | no

Hacker404 wrote 11/06/2015 at 23:09 point

I don't have a C64 or any of the parts. My retro computer is an Amstrad CPC6128 and I have a project to clone a TRS-80. 

The mouse controller should be simple as it's all digital. 

Most of the stuff for the C64 that *can easily* be done in FPGA, is probably out there already. 

The SID chips are different. FPGA contains ONLY logic circuits but the SID chips had both logic and analog circuits. So to work in FPGA you need to emulate an analog circuit with logic. Most people today would find this very hard to do because you need a very sound understanding (including complex math) of how analog works. Older people like me understand analog well because that is where we started. So writing a (state driven) parallel processing DSP in VHDL is do-able.

Unfortunately knowing how to make it is of no use without knowing what it *is* and that is the first challenge. There is no 'correct' specification for the SID that I can find so it would have to be reverse engineered. lol and that creates the next challenge - making the mixed analog / digital equipment to reverse engineer the chips signal. I have the experience and knowledge to do this but it's still a big effort and I am not really a fan of the SID. 

I did (a browser session of) research the history. Bil Herd has been asked about the SID many times and he has given short answers as you would expect as a response to a relatively simple question. I personally don't think Bil has access to the specification that went off to the manufacturer as that was more the area for the technicians and not the engineers like Bil. 

I did find an interview with the designer of the SID and from that I learnt why there is so much mystery. He made a last minute change to the specification just prior to it going off to the manufacturers. I think the mod was to phase synchronise the sound channels.

So while I have some of the 'missing skills' to make a modern SID a reality - I can't take it on alone. I already have a number of projects on the go and due to my current health there is no guarantee that I will complete any of them.

Of course the whole SID doesn't have to be exclusively done in FPGA. You could use external analog filters or even go with a mixed signal System on a Chip (SoC) like the Cypress 4100 / 4200 SoC's that have a inbuilt processor (M0). 

As for learning VHDL - well I recently started in VHDL so I am no expert but I do know the process to get going and I will write a page about that (if I find time) and put it on my profile - and link to it here. 

Oh - I am in Australia living with the spiders ,crocodiles, sharks, snakes and all manner of things that kill lol. 

Some after thoughts - 

The imitation SID (fake) from China is a digital only chip with no filters so it sounds like sh!t lol. 

Here is a you tube and if you read the comments you will find that even the emulators can't 'emulate' the filters on the SID. The video shows just how good some people are at using the genuine SID with filters.

PS: Skip to about half way in the video for the good stuff. 

PPS: Most of this rant is about the filters. You will already find VHDL out there to emulate the SID but that is without the analog filters. I also saw a replacement done with a micro-controller (virtual peripheral) but it didn't support filters at least at that stage - perhaps I should go a check up.

  Are you sure? yes | no

6502Nerd wrote 11/07/2015 at 18:04 point

Hi.  Your plans are incredible, although I really don't know much about FPGA or indeed the micro-hardware level description of CBM chips.   But I see that Howard Jones has made a reply.  Good luck with your endeavour, look forward to seeing it fly sometime!

  Are you sure? yes | no

6502Nerd wrote 10/25/2015 at 10:33 point

Ah, yes I have seen the F18A project as part of my research a year or two ago.  It's very clever indeed, but agree it's too expensive.  One of my goals was trying to use old parts and cheap components - not necessarily representative of the age (SRAM was not commonplace in the early 80s, and neither really was CMOS).  I don't know much about CPLD, I must look in to it at some point.  However, I did make some investigations in to using a second 65c02 running at 8Mhz to do video - it's tight but I think a basic 176 pixel wide display could have been achievable (monochrome though).  I have a multi-input TV and even though it's second-hand and fairly old, it has PC and TV inputs.

Good luck with the TRS-80 and Z80 machines you're building - keep at it!

  Are you sure? yes | no

Hacker404 wrote 10/24/2015 at 01:00 point

BBC = Bread Board Computer lol 

I am wondering if that 9918 will run fast enough for a VGA output. 

I am making a retro computer as well (taking forever) but for the one I am making I decided to only use currently available chips so Video is the hardest part and I am doing it on CPLD with VHDL. That is not a solution in itself as I do really need some 'standard' for the Video interface.

So I wondering how good is the interface that is presented by the 9918. Maybe I could see if it has been duplicated in HDL.

The 6845 is actually a bit easier to use but not as good as the 9918 but in any case as you wanted to separate the (S)RAM so the obvious choice is a 9918.

  Are you sure? yes | no

6502Nerd wrote 10/25/2015 at 00:02 point

Hi - lol, yes great alternative name for BBC!!

I don't think the 9918 will be fast enough for VGA - the 9918 outputs a line frequency around 15KHz, IIRC VGA is more like 31.5KHz.  The master clock for the 9918 is already at 21.477Mhz, which seems really high for a 1970's part already, not convinced it has the bandwidth to go double.

Yes video is really hard as modern components have so many pins and run so fast - so it wasn't an option for me using breadboard.

The 9918 interface is really straightforward.  Essentially there is just an 8 bit CPU interface, a mode indicator, and then the read/write lines (two lines one for read, one for write!).  The mode is really just tied to A0 of the 6502, and the read and write lines are decoded appropriately from the 6503 R/W line.

The following link should have the original TI documentation:

There is another programmers manual that can be found if you search which is more software orientated, although the above manual does cover software programming to an extent.

I found the 6845 a little daunting and I only had a 1MHz part.  I wanted to get the 6502 to zip along faster than 1Mhz, but couldn't think how to interface different clock speeds on the same bus.  Also, the TMS9918 generates all the timing signals as well as colour burst etc. - so I felt it was much simpler to use (sort of - needed to have glue for using SRAM and a 6502 host CPU).  Plus of course it has hardware sprites - a little voice in my head is saying this could be great for a graphical OS one day ;-)

Hope that helps, let me know how you get on!

  Are you sure? yes | no

Hacker404 wrote 10/25/2015 at 00:56 point

I had a look around for a FPGA implementation of the 9918 and found a couple. 

This hardware is interesting ...

as the hardware just plugs in where a normal 9918 would and the output is VGA - 

so it's more or less bread board friendly. Unfortunately the chosen FPGA is over kill and expensive. The same/similar chip is used for the GameDuino (first version) and that is probably a lot better and has more sprites etc but the GameDuino is SPI interface. Perhaps I should see if the GameDuino is open source and convert it to parallel interface. 

I am still looking as I haven't seen actual VHDL and I want to know what the smallest chip it will fit in (hopefully just a larger CPLD) along with external SRAM. 

Agreed, one the hardest aspects of this sort of prototyping is dealing with non-breadboard friendly parts. I have been using adaptors and breakouts and now I am moving to wire wrap. 

  Are you sure? yes | no

Eric Hertz wrote 06/28/2015 at 20:56 point

I love how it's now inside a regular computer-case, but is a bunch of solderless-breadboards inside!

  Are you sure? yes | no

6502Nerd wrote 06/28/2015 at 22:20 point

I needed a case to keep all those breadboards and dodgy wiring safe! Yeah I like that I used a case of a computer that I coveted in the early 80s. The BBC micro was a premium machine of the time in the UK.

  Are you sure? yes | no

6502Nerd wrote 06/28/2015 at 15:15 point

New pictures of homebrew in the BBC case.  With the case closed of course it looks like a BBC.  But, my homebrew is faster (2.68MHz vs 2MHz) and has more memory (44KB RAM, 16KB VRAM, 16KB ROM)!  So better than a BBC?  No of course not - BBC hardware and engineering was pretty amazing, loads of respect to the Acorn guys in Cambridge.  Still, pleased with the hardware - but there are many miles left in my journey.  I will focus more on software for a while, although I think I really do need to add some kind of mass storage (I think SD card).

  Are you sure? yes | no

6502Nerd wrote 06/24/2015 at 21:00 point

Reaching a kind of milestone... I am in the process of gutting out the internal bits of the BBC Micro case (I need to cut away the plastic dividers between where the PSU and main board are located).  Can't believe how thick the plastic is - this beast was seriously engineered, no wonder I could never afford one.  Anyway, even after modding the case, I have realised that the configuration of the breadboards of my homebrew mean I can't just drop it in.  So now I have to move the sound and acia mini-breadboards.  Sounds simple, but I stuck them all down on a plastic chopping board!!!  I sometimes out-do myself when it comes to kludges, but at the time without a case I needed a firm base for the circuits.

So, I will have to unstick the small breadboards and move them around.  This means all the connections will have to be re-done as they will have to be different lengths - and I'm running out of wire!

WIll post again when the BBC case is home to my home brew...

  Are you sure? yes | no

6502Nerd wrote 06/16/2015 at 20:12 point

I'm quite excited - I bought a non-working BBC Micro off ebay.  I want to reuse the keyboard and case (the BBC case is sizeable - should be able to take my bread-board contraption with ease!).  I hooked up the keyboard and checked it out with the oscilloscope and it seems to work fine (the '7' key is a bit temperamental though).  As an aside, the BBC keyboard is a brilliant design with a combination of hardware interrupt and software polling to read keys.  Great engineering, I now see why the BBC cost £400 when I was a kid - way, way out of my price league!!

  Are you sure? yes | no

KJoh wrote 05/15/2015 at 08:59 point

thanks.  You have a lot to do, enough to fill a book

  Are you sure? yes | no

6502Nerd wrote 05/18/2015 at 10:14 point

Hi.  Yes, I do have a lot to do - even to bring this project up to date with everything I've done so far.  At the moment, I am kind of brain-dumping (I have already added a few logs) - but any suggestions for which areas would be of interest to cover would be helpful.

  Are you sure? yes | no

KJoh wrote 05/13/2015 at 21:38 point

your comment "a passion for being able to wield the computer at its lowest levels." Totally resonated with me.  Good luck with your project.  So, when you say you're next steps include an OS are we talking about some kind of Apple II or CP/M port?  Maybe a dumb question

  Are you sure? yes | no

6502Nerd wrote 05/14/2015 at 08:51 point

Thanks the encouragement, and your question is not dumb at all ! At the moment there is no O/S - literally boots up, clears RAM and VRAM then jumps in to the monitor program.  All the low level I/O has just been hacked together - no elegance or consistency.  I did this just to make sure all the bits were working.  I want to learn from the ground up - so no porting, although will look at other O/S features and techniques.  I will keep it *really* simple though - just make some baby steps that I can build on!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates