Project Logs

Collapse

• dflat programming

  6502Nerd • 05/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

  6502Nerd • 03/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

  6502Nerd • 12/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()"

  Keywords

  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

  6502Nerd • 10/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.
  

  sd_getbyte
  	phy
  
  	lda SD_REG
  	ora #SD_MOSI			; Set MOSI high
  	sta SD_REG
  	
  	ldy #8				; Shift in the 8 bits
  sd_shiftinbit
  	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
  	
  	ply
  
  	rts
  

  
  

  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.
  

  sd_sendbyte
  	pha
  	phy
  
  	sta tmp_a		; For shifting out
  	ldy #8			; 8 bits to shift out
  	lda SD_REG		; Load the SD register to A
  sd_shiftoutbit
  	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
  sd_shiftskiplo
  	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
  
  	ply
  	pla
  
  	rts
  

  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

  6502Nerd • 06/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

  6502Nerd • 05/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

  6502Nerd • 05/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

  6502Nerd • 05/16/2015 at 18:11 • 0 comments

  Monitor

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

  Command	Description
  DIR	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
  MEMTYPE V | M	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

  6502Nerd • 05/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.

  Section	Type	Address Range	Decode rule A15-A12 (binary)
  A	ROM	0xc000 - 0xffff	Between...

  Read more »

• The Basics

  6502Nerd • 05/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 www.6502.org 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.

  CPU
  

  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