Update (June 2018) - Clock speed doubled - now running @ 5.36Mhz
The clock circuit of my project used a 21.7727Mhz master crystal, which is fed through a 4 bit counter to output the right clock speed for various devices:
- 10.7Mhz for the TM9918
- 2.68Mhz for the 6502 and peripheral chips (6522, 6551)
- 1.34Mhz for the AY-38-8910 and BBC Keyboard matrix hardware strobe
I also have a 5.36Mhz clock available, but in previous attempts at trying this, I end up with a blank screen an/or frozen machine. This led me to believe that my RAM was not fast enough to keep up with the demand at 5.36Mhz.
So I tried swapping out the 70ns RAM chip with a very fast 15ns RAM chip. I also made some software adjustments, mainly putting in extra NOP instructions to delay the speed at which the TMS9918 was being driven and the BBC keyboard was being strobed. To cut a long story short, it turns out that the 15ns chip is glitchy, but the 70ns chip works fine once the software reflects the faster CPU cycles.
I also got a huge amount of insight from the expert folks over at the 6502 forum - turns out my assumptions on the activities of the 6502 across one clock cycle are incorrect, but still my current design does work without any issues - but it's not optimal and I will sort this out in due course.
So I'm mega pleased. I would never have dreamt of a 5.36Mhz 6502 back in the early 80s. The BBC Micro was the fastest 6502 micro around running at 2Mhz, followed by the Atari 8 bits at 1.79Mhz. My machine is more than 2.5 times faster clocked than the BBC, and with the tokenising BASIC interpreter I built (dflat), a serious amount of power is available to write interesting programs :-)
Update (Oct 2017) - Improvements to dflat
I thought I had made a more recent post than last December - time flies! So I haven't been able to spend as much time as I would have liked, but in the last few weeks have built a few improvements to dflat:
- Better handling of parameters. Until now, a parameter passed to a procedure would change the global value of the variable. For example a procedure called _def which takes a parameter %x, i.e. def_sub(%x). When _sub is invoked, the value of %x is overwritten with the parameter, i.e. _sub(1) loads %x with 1. However this is undesirable as it creates side-effects which must be carefully avoided by the programmer. So I have corrected that now - every variable in a definition used to pass parameters is now automatically a local unless preceded by '&' in the definition, which reverts to the previous behaviour and allows procedures to pass back values through shared variables.
- Enabling procedures to act as 'true' functions. Until now, passing back values from a procedure is through parameters as described above. This means a procedure doesn't actually return a value like a real function. I have now added this feature. A procedure can use the 'return' keyword to return an integer value, and the rest of dflat allows this procedure to be used as a true function in expressions.
- Added high resolution drawing. I wasn't sure there was enough room in the 16KB ROM, but I have also added the ability to set the Graphics Mode II (256x192 pixel screen), be able to address individual pixels (using the 'point' command) and draw lines (using the 'line') command. This makes possible games like (for example) missile command and lunar lander in dflat! :-)
- Removed the basic monitor, as I always found myself going straight in to dflat. If I need to check memory I can always use peek! This freed up around 750 bytes of valuable ROM space. Now I can think of even more stuff to put in to dflat! :-)
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...Read more »