6502 Homebrew Computer

My own design 6502 based computer with full graphics, sound and storage capabilities for a dose of 80s nostalgia!

Similar projects worth following
Update June 2017: High res graphics by poking the VDP directly!

A 6502 homebrew microcomputer, fully featured with sound, video, I/O and a self-developed built in programming language. The machine is fully self sufficient with on-board mass storage - just switch on and start programming it, like the heyday of UK micros in the early 1980s.

Key features:
Core WDC 65c02 @ 2.68Mhz, 44KB SRAM, 16KB EEPROM, 8x0.5KB memory mapped I/O
Video: TMS9918, 16KB SRAM
General I/O: 2 x WDC 6522 driving AY-3-8910, SD Card SPIO, BBC Micro Keyboard I/F
Serial: 6551 ACIA @ 19200bps
Sound: AY-3-8910, 5 I/O lines used for Atari compatible 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.

Latest update (Dec 2016) - Tetris game in dflat!

I felt the need to do something more sophisticated than the Invaders game in dflat, so have attempted a decent implementation of Tetris. The screenshot below shows the game - I am quite pleased with it, as it uses only my custom dflat interpreter. I am using sprites, sound, user defined graphics and a multi-colour palette to give the game a nice look and feel. In addition, to optimise for performance of scrolling the game map when a line is completed, I am using fairly intense string handling to maintain the game map rather than the original 20x10 integer array. Whilst developing this game, I decided to add timer functions to dflat, to help with timing various animations in the game loop - a beneft to building one's own computer language!

Invaders retro game done!

I've been a bit busy with work, but have managed to create a small and simple space invaders type game entirely in dflat. It takes me right back to around 1984 when I learnt to program from magazine listings! Also, I have added a couple of videos with commentary on youtube - one on the hardware (see below) and one on dflat (see dflat log).

First for a bit of context (back to around late 2014)

I guess I have always been interested in the lower level details of computers and their operations. As a kid of the 80s in the UK, getting to know the inner workings of my old Oric-1 and Atari 800XL entailed learning 6502 assembly and the I/O chips (including sound and video).

Then I had to grow up. I went to University, and went in to the world of work. My first couple of jobs were low-level (sort of), building software for embedded systems using a mixture of C, C++ and Assembly.

But for almost 20 years, I have been designing, architecting and consulting around distributed business systems. So I went completely away from the low level, working at the business outcome level - which is great in many, many ways.

However I still had a passion for being able to wield the computer at its lowest levels. By the 2010s I started to gain a desire to build my own computer - (almost) the ultimate expression of this. I did some research and found not only loads of homebrew computer enthusiasts, but even homebrew processor enthusiasts. But as is often the way, life and work took over and I put it to one side.

Then 2014..

Around late 2013, the desire to build my own computer hadn't gone away, and I had continued my research and looking longingly at other enthusiasts' efforts. Finally, I resolved to stop pondering and actually get on with it. I needed a hobby that would work around a demanding job and home life, so this would be something I could let progress as my time allowed.

Current State (April 2016)

As of the last update, my home brew has the following features:

  • 65c02 at 2.68Mhz
  • 2 x WDC6522 at 2.68Mhz
  • 1 x TMS9918 at 10.7Mhz
  • 1 x AY-3-8910 at 1.34Mhz
  • 1 x HM628128 128K SRAM 70ns (using only 44K)
  • 1 x W27C512 64K EEPROM 45ns (using only 16K)
  • Serial I/O using 6551 ACIA
  • Atari compatible joystick port using 8910 port lines
  • SD card interface using CIA port lines
  • Original BBC Micro keyboard integration through a 6526 CIA
  • Original BBC Micro case

I had a number of initial goals:

  • Serial, SD, Screen and Keyboard with a common I/O approach : Done
  • Basic operating system mainly focussed on I/O and interrupts : Done
  • Built-in interpreted language with editor to enable machine to be standalone : Done
  • Built-in mass storage to not rely on a host PC for input/output and mass storage : Done
  • Output to a standard LCD TV : Done

So what is left.. I have achieved most of the things I wanted and feel quite pleased with it's current position. However there are some more things I want to do:

  • Simple banked RAM - use 6526 I/O line(s) to make better use of 128K SRAM
  • Simple banked ROM - use 6526 I/O line(s) to make better use of the 64K ROM
  • Write some demo games using my built in dflat language!

I have had a think about banked memory for RAM and ROM and decided they are not M but H in difficulty. I need...

Read more »

All source files and assembly listing for my project. You are free to use any of the source for your own not-for-profit purpose as long as you credit me please.

x-zip-compressed - 219.78 kB - 05/30/2016 at 14:00



Assembly listing output of these files.

lst - 634.06 kB - 05/30/2016 at 13:59



TMS9918 handler

Assembler Source File - 12.49 kB - 05/30/2016 at 13:59



Higher level graphics handling - primarily to drive screen I/O

Assembler Source File - 11.80 kB - 05/30/2016 at 13:59



Fonts data

Assembler Source File - 16.58 kB - 05/30/2016 at 13:59


View all 42 files

  • 1 × WDC65c02s Modern 6502 made by Western Design Centre, runs up to 14MHz
  • 1 × TMS9918 Texas Instruments VDP found in the TI99 and MSX computers (the 'a' variant)
  • 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
  • 1 × 32KB SRAM (62256) - For video RAM Needed by the TMS9918/9928 - but extrs logic needed as these chips expect DRAM

View all 9 components

  • dflat programming

    Dolo05/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

    Dolo03/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

    Dolo12/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

    Dolo10/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

    Dolo06/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

    Dolo05/24/2015 at 23:29 11 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

    Dolo05/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

    Dolo05/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

    Dolo05/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, 6525, 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 6526s (two of them) and the memory map design are the two most significant areas for creativity.

    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 1111 - 1100
    BIO Blocks0xb000 - 0xbfff1011 only
    CRAM0x0000 - 0xafffBetween 1010 - 0000
    The decoding of these address line (A15 to A12 for the section select, A11 to A09 for the IO block select) needs also to take in to account the chip select lines available. Doing this would hopefully reduce the complexity of the decoding a little. I am using a W27C512 for ROM, 628128 for RAM and a 74xx138 3 to 8 decoder for the IO block select. These chips have the following select lines:
    • ROM : /CE, /OE
    • IO BLOCK (74xx138) : /E1, /E2, E3
    • RAM : /CS1, CS2

    In addition to the A15-A12 lines, the additional signals are also needed from the 6502:

    • PHI2 (this is low when the 6502 has control of the data and address lines)
    • R/W (this is high when performing a read, else it is a write)

    The analysis I did resulted in the following table, which showed that I need 3 NOT and 6 NAND gates to implement the decode (plus the direct use of A14 which doesn't need a gate). I am sure someone can do better than, this but hey this is is my first custom memory map decoder, and it seems to work, so I'm happy - but any suggestions would be interesting. Note that Gate #1 Input A did have Phi2, but this is wrong, I don't need Phi2 to supply the RMO and IO decoder select - this is why my 6522 didn't work as I was not allowing devices to be selected until Phi2 was already high, whereas most 65xx family devices need the chip select to be activated before Phi2 goes high. Gate #6 is still correct - RAM must not be selected when Phi2 is low incase of inadvertent writes before address lines have become valid.

    Gate #TypeInput AInput BOutput
    1NAND+5VA15ROM /OE, IO /E1
    4NOTGate #3IO E3
    6NANDPhi2Gate #5RAM /CS1
    7NANDA15Gate #2
    8NOTGate #7
    9NANDGate #8Gate #4RAM CS2

    In addition, A14 feeds directly to /E2 for the IO decoder, and in addition to the chip select lines for RAM, the 6502 R/W line feeds directly to the /WE line (i.e. low for write, high for read).

    Device Selection

    As mentioned, the /E1, E2 and E3 outputs enable the 74xx138 decoder. This basically then takes A11, A10, A09 as inputs and selects one of 8 outputs (active low). So therefore I have 8 addressable devices I can select. This should be plenty, as I can't think of more than 8 different devices:

    • Block 0 (0xb000) : 1st 6522 VIA
    • Block 1 (0xb200) : 2nd 6522 VIA
    • Block 2 (0xb400) : TMS9918 VDP
    • Block 3 (0xb600) : 6551 ACIA (planned - low priority as I already have functional serial I/O)

    I had hoped to make...

    Read more »

  • The Basics

    Dolo05/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?



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

Schematics available?  Thanks!

  Are you sure? yes | no

Dolo 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

Dolo 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

Dolo 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

Dolo 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

Dolo 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

Dolo 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

Dolo 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

esot.eric 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

Dolo 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

Dolo 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

Dolo 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

Dolo 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

K Johansen 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

Dolo 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

K Johansen 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

Dolo 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