DEV Community: James

How a CPU really works

James — Fri, 25 Aug 2023 14:54:15 +0000

Let’s go right inside a CPU and watch it execute code at the transistor level!

As a programmer I have often wondered exactly what the CPU is doing when I give it some code. Being a computer science teacher I know all about the fetch-execute cycle and what is supposed to be inside a CPU but what it actually does is glossed over.

https://youtu.be/n4e4KjcyeSE

So I set about finding out using the Visual6502project’s simulation of the Zilog Z80.

This is not an emulator of the chip like you might be used to. This simulates the actual physical layout of the chip down to the wiring and transistors. It’s possible to step through the chip’s sequencing logic and watch parts of it switch on and off. It’s completely fascinating.

And once you figure out what’s going on, it’s possible to watch the CPU work.

This deep dive into the inner workings of the Z80 was inspired by one of my students asking me the innocent question of “how does a CPU work?” and then being persistent in wanting to know what it actually does.

I had no idea and I had to find out.

This video is the result.

Solar battery usage

James — Thu, 24 Aug 2023 20:34:10 +0000

It’s a crappy cloudy day today. There was about enough sunlight to power the house, but not enough to also charge the batteries.

The sharp downward slope just after 5pm is when I cooked tea and then turned the TV on. That also appears to be a thing. The TV doesn’t use much power really, but if I leave it on for six hours, it does.

Here’s the 18th of August. On the 18th of August I managed to completely drain the batteries before midnight.

This was partly due to there being constant cloud cover and it raining non-stop all day and the panels barely making any power. But the slope is still a bit steeper than normal. That’s because we forgot to switch the PS4 off that had done an update and was then in the middle of a game for some reason.

The 23rd of August was an odd day. Also cloudy and overcast, but then the sun came out just long enough to fully charge the batteries again.

The day before was a good one too. Sunny all day to keep the batteries full, then I turned the oven on for a few hours to cook tea and bake a pie.

I think all this means that in Winter when it’s grey and shit for the whole of December I will have enough battery to run the house all day if we’re careful with power. And if the sun comes out for a few hours sometime before mid-day it’ll charge the batteries up again.

I still feel like I want to stick another panel on my shed and have better batteries in there. The panels on the house catch the morning sun, the one on the shed gets the afternoon sun until the house shades the garden. But then as I discovered last winter, the shed panel doesn’t make a lot of power and the AGM batteries don’t have much capacity. Replacing them with lithium iron phosphate would be good, but be expensive.

How trying to make pocket calculators do complex maths accidentally invented modern computing

James — Fri, 11 Aug 2023 19:02:46 +0000

What happens when you set out to build a pocket calculator? Well in this case it turns out you also accidentally invent desktop computers, and spawn a bunch of CPUs that are still being used today.

Follow along as we go through the thoroughly bizarre story of how trying to do complex maths and fit it in our pockets lead directly to the machine you’re using right now to watch this video, which you should totally watch, now. Go on, click it.

Calculators were originally like computers – huge boxes that required care and maintenance and sat firmly on a desk plugged into the wall. Today everyone wants to own a smartphone, back then everyone wanted a pocket calculator.

The story of trying to cram a whole shoebox of electronics into a pocket involves dodgy corporate dealings, people starting their own companies and deciding that while calculators were nice, being able to program them would be even better.

Part of the difficulty of building a calculator is working out how to understand the maths the operators were entering. A basic four function calculator can be thought of as a simple state machine, but once we get to doing scientific functions or longer multi stage formulae. And this is where a technique known as Reverse Polish Notation comes in.

Back then computers were too low powered to cope with parsing text and checking for dumb human things like missing brackets or maths that made no sense. So we had to do that for them.

The history of how the modern computer came to be is pretty interesting. There’s a fascinating explanation onthis website, which was then turned into an equally fascinating book that you should go and read. Here’s a link to the Google Books version, but the real thing is better to read.

Why the 1880 US Census lead to the invention of the computer

James — Fri, 28 Jul 2023 16:44:44 +0000

How did the 1880 US Census and the end of World War 2 lead to the invention of the computer? What was it that kickstarted the Information Age? Come with me as we find out how the need to count everyone in 1800s America directly lead to the modern information age and all the technology we take for granted.

So just how do you count everyone in a large country like the US, and once you’ve gathered all that data, how can a machine be instructed to sort and organise the information so it makes sense to someone?

In fact, how do we even program computers to sort data? Sorting is a fairly easy thing for people to do, we do it every time we want to play a game using cards. However what process would we take when using a computer?

In this video I go through the history of why it’s necessary to automate this task, the people involved and then look at several sorting algorithms – bubble sort, insertion sort, quick sort and merge sort.

RC2014 Raspberry Pi Pico VGA Terminal Self-Build

James — Wed, 26 Jul 2023 19:39:57 +0000

The RC2014 is a DIY Z80 based computer that talks to the outside world using serial comms. This means you need a serial interface to another computer in order to control it.

Recently I came across thePi Pico VGA Terminal board that does away with all that faff. Now, I could buy it, but in the DIY self-build theme of the device I thought I’d have a go at making my own.

The schematics for the board are available, but some of the markings on it are a bit hard to read. Fortunately the design follows Raspberry Pi’s own example of doing bit-banged VGA on a Pi Pico, so it was easy to figure out what to do.

Although I don’t have the correct resistors, so things look a bit blue. Whatever, you could buy paper white CRTs and amber ones. Well now I’m going to have off-blue. Get that blue light in your eyes at night so you stay awake better while coding. Yes.

I’ve so far prototyped the circuit on a breadboard and nothing got hot or exploded, and I even got a video signal. The next step will be to put all of the components onto a piece of perfboard to make a “proper” expansion board to slot into the RC2014’s backplane.

A future project might be to make some kind of all-in-one case for the RC2014, a keyboard and one of those tiny 10 inch LCDs that are all over Amazon and eBay.

Devlog 01 - Spectrum Next Programming Languages

James — Thu, 18 Feb 2021 12:37:23 +0000

I’m starting an ongoing series where I learn how to write code for the Spectrum Next.

Watch the video

Video is here

How to program a ZX Spectrum Next

In this episode I look at three options for writing code on a Spectrum Next

BASIC
C
Z80 Assembly

And then I explain my setup.

NextBASIC

Like all Spectrums before it, the Next comes with BASIC as standard. This comes in several dialects from the original 48k BASIC to its own NextBASIC. NextBASIC includes a few new features relevant to the extra hardware in the Next.

The really great thing about the Next is that it’s a self-contained system. Plug it in, get the manual and away you go. Nothing else is needed, just like a computer used to be in the 80s. The manual teaches NextBASIC and has plenty of examples to work through.

C

If BASIC is too … err … basic … then C is the next step up. It does require setting up and won’t run off the Next itself - a PC/mac is required. This comes in the form of Z88dk which needs installing onto a computer of your choice to cross-compile a file the Next can load.

Z80 Assembly

There’s a few options if Assembly is your thing. Some rely on a separate machine to cross-assemble the code, but there is also an assembler called Odin that runs on the Next which looks quite promising. I think it’s in development at the moment.

Cross-assembly can be done with SJAsmPlus or Z88dk

My Setup

What I’ve set up is the following

Visual Studio Code with the DeZog extension
CSpect for emulating the Next
Windows Subsystem for Linux with Debian
A custom folder containing a Makefile, VS Code task and other files
Z88dk installed inside WSL

With all that set up I can edit code in VS Code, press F6 to build it and then Ctrl-F5 to make it run in the emulator. All without needing to touch a shell, batch file or manually copy files anywhere.

If I want to test on a real machine I have Nextsync and the Next WiFi module to copy the files into my Next directly. Not having to swap SD cards and unplug things is important to me when doing this.

You do realise  is far simpler, right?

Yes, yes I am quite aware I could just use Windows and its version of Z88dk and everything. I don’t want to though. I like developing in Linux with its sensible shell, tools that work the way the documentation says, and zero reliance on Cygwin.

Grab my code

If you want it, here is a link to my github repo with the build directory inside it. It even includes instructions! Spectrum Next C Starter Project

Quazar Graphic OLED Display - Real Pixels for your RC2014

James — Sat, 06 Feb 2021 17:00:00 +0000

Real Pixels?

One of the main limits with most hobby Z80 based computers is their lack of any video output. Most video output comes in the form of ASCII text sent to a serial console. This is fine if you like text based software or are running an operating system like CP/M. It’s a bit limiting if you want to do more graphical things.

I found the Quazar Graphic OLED Display, a plug in board for the RC2014 with a small 128x32 pixel OLED display on it. By using a fairly straight forward set of assembly routines it’s possible to send image data to the screen.

Video

I liked it so much I made two videos about it. Watch them here!

First video

Second video

How the Quazar OLED Display works

The display has fairly simple electronics that interface the OLED to the Z80 bus, with it having an I/O port assigned to it by some jumpers. The board came pre-assembled so all I had to do was plug it into a spare slot on my RC2014 backplane.

The rest was done in software using a mixture of Z80 assembly language and C. For the C programming I used the popular cross-compiler for Z80 Z88dk

Grab the source code

You can get the source code for this from my Github repo. There’s not much to it and all the assembly code came straight from the excellent manual provided with the OLED display.

How To Program The Quazar Graphic OLED Display

Step 1 - Draw some pictures

I used a combination of Paint.NET and Irfanview to draw and convert the images. All I did was set the canvas size to be 128x32 pixels and draw in solid black and white. Irfanview was used to convert the image into PBM so that I could use a bit of C to convert that into source.

You can do anything you like to convert pixels into source code, but the screen expects its pixels in a specific and slightly weird format. Each byte of image data represents an 8 pixel column on the display, with the display being made up from four rows of these 8 columns, with 128 columns per row. There’s a diagram in the manual, stare at it for a while until it makes sense.

Step 2 - Write the code

In my github repo is a Z80 assembly file containing the rudimentary API based off the manual’s source. It takes a 512 byte array and sends it to the screen as image data. If you got all your bits in the correct order, an image appears. If not, a garbled mess does.

Optimised Z80 - Conway's Life Improved

James — Sun, 22 Nov 2020 14:33:07 +0000

Or, how to optimise your code so it runs better…

Intro

A while back I started learning Z80 assembly language and decided to create a version of Conway’s Life. The code I wrote worked, but it wasn’t that efficient with the simulation being measured in seconds per frame rather than frames per second.

This is an explanation of what I did to make it run faster. Well it’s not, it’s actually an explanation of how to optimise code and my Life code is an example.

Watch the video!

YouTube Link

Grab the code!

The source code and compiled binary can be obtained from my Github Repo here. Feel free to copy it and make modifications. If you fix or improve it, let me know!

Don’t prematurely optimise

Make it work first

It’s more important to have a working algorithm than one that’s perfect. Optimisation tends to create less readable code and less readable code is harder to debug. Make the code work first so that while optimising it you can more easily spot things that break.

Make it work better later

Once you have a working algorithm, maybe it needs rewriting as you now understand the problem better. It might feel like you wasted time making the first version, but without it you wouldn’t be here. Programming is an iterative process and every program is different and full of unique challenges that get very implementation specific.

You can’t polish a turd

but you can roll it in glitter to make it look prettier. It’s still a turd though.

A bad algorithm will always be a bad algorithm no matter how many clever tricks you use. In my case I went about writing Life as if it were a 2D grid because that’s how I was visualising it. Computers don’t store data as 2D grids, to them it’s all just one long list of data. Accessing data as a grid requres X,Y co-ordinates and that involves multiplication.

The Z80 can’t do multiplication by itself, you have to write code and that code involves loops. Without realising I was trading off readability of my code with execution speed. Nobody but me reads my code, but others will run it.

What I did wasn’t wrong or bad practise though. It’s far more important to make a working program than a fast one to begin with. People will notice a slow algorithm but put up with it however if the program doesn’t work properly they’ll soon complain.

Other people can help

I sort of knew that I needed to change the algorithm but couldn’t work out how. It wasn’t until someone left a comment on my video that I had an idea. They didn’t completely explain a better algorithm but they did give me a different way to tackle the problem. A way that didn’t involve any multiplication by the Z80.

Prototype, focus on the algorithm

Debugging code can be hard, you need to separate syntax and logic errors caused by trying to write the algorithm from the errors caused by programming the computer. Figure out the algorithm first - the general way you want to instruct the computer to perform your task. Don’t get bogged down in which variables or loops you need. Get the overall idea clear.

Once you have a working algorithm the process of programming the computer is much more straight forward.

I wrote a version of the code using Python on my PC where debugging is easier. It let me work out the general form of the algorithm separated from the specifics of instructing a Z80 CPU to do the task.

Don’t over generalise

We programmers love abstracting problems out to their most general form, it means two unrelated problems can often be solved with the same technique, or it makes something difficult easier to understand. “It’s just a 2D grid and we go around the grid looking at neighbouring squares” is easy to imagine and the same code can work for every square on the grid. Even those tricky corner and edge cases - we just need a bit of logic to recognise we’re in one of those situations.

Specific problems require their own specific solutions

That’s where my thinking was going wrong. I was trying to treat every grid on the board the same. Instead of doing this I should have been looking for patterns. The grid is split into nine distinct areas - amusingly the same nine areas a GUI window or layout is split into.

Four corners, each of which is different
Top and bottom rows
Left and right edges
The middle

The middle is the easiest place to code up and is what most Life implementations focus on. You take a square on the grid and then calculate the eight surrounding cells to work out how many neighbours exist. We’re still thinking in 2D here, but recognising the middle is different is an important step.

The four corners are special and each needs its own specific logic and there’s no way to generalise this. However it’s only four corners.

The edges also need their own specific logic, but this can be more generalised and applies to long runs of cells so there’s potential for more optimisation later.

Cheat if you can

The Z80 can’t multiply, but if we think about what I’m trying to achieve we realise it’s not necessary. The Life board is n x m cells in size and I choose that size based on the size of the terminal window. The user can’t change it.

Constants and the pre-processor are your friends

Since the number of cells never changes, I know it in advance. This means I can make use of constants when referring to the total number of cells. And since my assembler has a preprocessor that can do arithmetic using my PC, I can hard code many values.

For example the top-right cell is at index 79 in the list of cells because I made the grid 80x25 in size. This also means the bottom right corner is index (80 x 25)-1 which is multiplication, but if I make the assembler do it it can just insert 1999 in the code for me.

; Defines to avoid having to do any actual maths in the simulation
middleRowLength EQU ScreenWidth*(ScreenHeight-1)

CellA EQU 0
CellB EQU ScreenWidth-1
CellC EQU ScreenSize-ScreenWidth
CellD EQU ScreenSize-1

I used this everywhere. The code is full of hardcoded values and constants which is something we’re sort of taught not to do as the code shouldn’t be full of “magic numbers” that make things work. Except these numbers aren’t “magic” and they’re all labelled with descriptive names. It’s not really 80x25 it’s really ScreenWidth x ScreenHeight.

; Start at x-((width*2)-1) (3)
ld hl,de
ld bc,(ScreenWidth*2)-1 ; Assembler macro
sbc hl,bc
ld bc,(currentGrid)
add hl,bc   
ld a,(hl) ; Add to A

Remove redundant code

After getting a decent algorithm sorted out, and code that works you can now start to look at ways to simplify the code. Algorithms are quite high level ways of thinking, and turning them into working code can often involve more steps. The Z80 has limited registers and deals with 8 bit numbers natively. I needed a 16 bit counter but there aren’t any built in instructions for comparing 16 bit numbers so I needed to write my own.

These types of specific situations are where you can optimise further.

Reorganise the instructions

Sometimes changing the order of instructions can make it easier to compute. When calculating the neighbours in the grid my original 2D thinking had me working from the top left neighbour and then across each row, calculating the index each time based on the centre.

After typing this out several times it soon became obvious to me that a better way would be to compute the top left neighbour and then simply incrementally move through the list to reach each neighbour. Some calculation is required to find the top left neighbour but every one after that is merely incrementing our position in the list or adding on a constant number of cells to reach the next row.

ld hl,de
; Get contents of Cell x-width-1
ld bc,ScreenWidth
sbc hl,bc ; x-width
dec hl ; -1
ld bc,(currentGrid)
add hl,bc : ld a,(hl) ; Add to A

; Get contents of Cell x-width
inc hl : add a,(hl) ; Add to A

; Get contents of Cell x-width+1
inc hl : add a,(hl) ; Add to A

Doing this not only made the code easier to follow, but I removed hundreds of instructions in the process.

Apply the dark arts last

There does become a point where your algorithm is optimised but there’s still room for improvement. This is where the dark and dirty tricks specific to your system can be used. Tread carefully, the performance gains made here are likely to be small and are best used when trying to hit a specific code size or tight execution limits.

Optimisations of this nature are prone to undoing themselves or being blown away by new code that’s added later.

Instructions have side effects

One common task in my code was to accumulate a count of now many live neighbours each cell had. Each cell has eight neighbours. There are 2000 cells on the grid. This accumulation code runs 18,000 times per tick of the simulation.

One step in this is to clear out the accumulator and reset several CPU flags.

Originally I was using the fairly straight forward process of

ld a,0 ; load 0 into the accumulator
or a ; this resets the carry flag

These two instructions take up 7 and 4 cycles respectively so 11 in total. This is nothing really, the Z80 has instructions that by themselves use 23 cycles.

However we can do better. The code after I clear the accumulator works out if the top left neighbour is alive and then adds 1 to the accumulator if it is, which is why it needs to be zero.

Except it doesn’t need to add because if this is the first value to go into the accumulator then I can directly load the result using ld a,1. The load instruction does take 7 cycles compared to the 4 of an add however before using add I first had to reset the accumulator to zero by loading 0 into it. So I can save the 4 cycles of the add instruction by removing it entirely.

Now there is an even more shorter way of doing this. It turns out xor a will both reset the accumulator to zero and clear the flags using only four cycles. So I could use this with the original add instruction and save three more cycles.

Assembly programming is full of these kinds of thoughts, at the start cycle counting sounds like some mystical dark art that few comprehend. After a while it becomes just another thing to think about and consider.

Don’t over optimise

While running my code I noticed odd behaviour cropping up when the simulation was running. I got what could only be described as screen tearing, presumably because the serial link between the RC2014 and my PC couldn’t keep up with the data being generated and something was overflowing.

There is a point in optimisation where the benefits gained are either so small it becomes an academic exercise, or other bottlenecks appear - some of which can’t be overcome.

Summary

Overall I managed to take code that was very inefficient and slow and re-write parts of it so that they now ran “too quickly”. This gave me some spare cycle time in which I could add a nice border to the screen.

What’s pleasing to see is that the simulation runs in constant time regardless of how many live or dead cells exist. A full screen of cells doesn’t slow the simulation down because every cell is being computed regardless of whether it is alive or not.

I’m sure there’s an even better algorithm out there that takes this observation into account and only looks at the live cells. Again though, there is a point in this where if the simulation runs too quickly it becomes unwatchable and needs slowing down to be pleasant to look at.

Bbc Micro Mega Upgrade

James — Sat, 24 Oct 2020 20:19:41 +0000

I had a simple ambition of running DOS on my BBC Micro by using a Raspberry Pi Zero as a co-processor. This turned into the project that would never end!

Watch the video!

Watch on YouTube

Intro

The Internet contains several videos and explanations of how it’s possible to make a BBC Micro run DOS by using a Raspberry Pi as a co-processor, running something called PiTubeDirect which makes the Pi emulate several different CPUs in such a way a BBC Micro can use them as a second processor.

Setting up a Gotek floppy emulator

This is quite a straight forward upgrade. You buy a Gotek that’s been configured for use on the BBC Micro using FlashFloppy. Then plug the Gotek into the bottom of the BBC Micro into its disk drive connector. That’s it.

I decided to house mine inside the casing of a real BBC Micro 5.25” floppy drive for a more authentic look.

After doing this the drive worked fine, but it could only read single and double sided disks. This is OK if all you want to do is run regular BBC Micro games and software. I wanted to run more exotic things stored using ADFS and other formats the BBC doesn’t natively understand.

Upgrading the floppy controller

To make the BBC understand higher capacity disks the disk controller chip needs upgrading. This is a moderately invasive upgrade which saw me completely destroying a poor little logic IC while trying to remove it. The existing floppy controller chip gets removed and replaced with a board containing a newer 1770 controller chip.

I then discovered I needed to also upgrade the ROM in the BBC to support ADFS…

Burning EPROMS

This is where I actually learnt something. I have an EPROM writer, I found a random EPROM that I’d harvested long ago off a graphics card and figured it was a simple job to just write the ADFS ROM image onto that chip and stick it in the BBC.

Not quite. I learnt that the chip I had was actually a one-time programmable ROM so couldn’t be overwritten. Not to fear, I just figured I’d re-use the ROM that was making my old MMC “drive” for the BBC work. That had a little UV-erase window meaning it was an actual EPROM so all I needed to do was shine UV light on the window and wipe the chip.

Except I didn’t have a UV erasing box. So while one was on order from Amazon I thought I’d try and use something else. If you read about people erasing UV-EPROMS using those UV nail polish hardening lights, they must be doing something I couldn’t work out because 20 minutes of being shone with UV light did nothing to the data on the chip. I even tried the laser from my laser engraver as that looked somewhat UV. That didn’t do anything either. It didn’t even damage the chip…

The eraser turned up and I put the chip inside it for 20 minutes, which I soon learned was 15 minutes too long. Sure, the chip was now empty but also damaged and unable to be programmed. EPROMS of the correct type are hard to come by and I didn’t want to buy some from eBay and wait for them to arrive.

I had a look around my house at all the obsolete tech I own, and found an old JAMMA arcade board covered in EPROMS. One of those was extracted and after five minutes of UV exposure was blank enough to be written to, but not so blank it was damaged.

Success

And so finally, after a chain of endless and arbitrary upgrades that would make even Microsoft annoyed I had a working BBC Micro with a Gotek drive, new disk controller chip and a Raspberry Pi Co-processor.

My BBC can now boot CP/M, and also boot DOS. It’s pretty cool and something I’ll be exploring later on.

How I Became a better Computer Science teacher

James — Fri, 18 Sep 2020 18:10:16 +0000

I set out to make a simple game using sprites for my BBC Micro. It turned into an unexpected learning opportunity for me.

Watch the video!

My day job

During the day I teach kids computer science, and when we get to the tricky parts I often tell them to keep persevering and that they’ll eventually figure it out. I try to reassure them that it’s OK if you feel frustrated or that the challenge feels too difficult but it’s on purpose. Most of this is just me saying words to make my kids not quit, as I slowly adjust the difficulty of my lessons to match their abilities. Yes, lessons are scaled to match people’s abilities just like an RPG.

Little did I realise my own assembly programming attempt was about to get a full on experience of this, but without there being some benevolent teacher trying to slowly guide me towards eventual success. In my version success wasn’t guaranteed.

What I wanted to do

So I decided that it would be fun to make a small game for my BBC Micro. Previously I'd figured out how to make sprites work and foolishly thought it'd be a simple job to make a game. Except drawing and moving sprites on a BBC Micro is hard. The machine isn’t designed to do this. It’s designed to draw characters to the screen at specific locations, or to use built in routines for drawing lines and shapes. Directly pushing data into the screen RAM isn’t documented or encouraged.

I was fairly confident I could figure this all out though; other games exist so I knew it was possible. And with 30 years of Google results and countless PDFs of old programming books to look through I decided this would be more a test of my information finding skills than anything.

I found a way to draw sprites

After a short amount of searching I came across an old book that showed how to plot sprites to the screen and move them. They moved at a decent speed and the code looked reusable. All it did was copy pixel data to the screen at the correct offset. I decided it looked quite easy to follow and I was confident I would be able to adapt it to my needs.

But it didn't work

I quickly discovered it had limitations - no screen erasing so sprites left trails or copies of themselves all over the screen. Moving the sprites quickly caused screen tearing and was visually unpleasant.

So I had to find a new way

Some better code was found on the stardot forum, but it was long, complex and I had to reverse engineer it to make sense of what was going on. Even worse, there wasn’t a demo program I could run and the code was written for an old assembler that didn’t seem to work properly any more.

Great, I either had a useful piece of code, or something that wouldn’t work. I wouldn’t know until it was running, but I couldn’t run it because I couldn’t assemble it so my only option was to reverse engineer the code and try to understand the algorithm behind it.

The new way didn't work

I had to write all the code before being able to try it out, and the first run didn’t work! Neither did the many many attempts after that. At first it just crashed, then after a lot of debugging it drew garbage on the screen but the garbage looked consistent. I had no idea what the screen should look like when the code ran as I didn’t even have a screenshot to look at.

Eventually I realised the code was probably working, but something was wrong with the image data. Finding out what was wrong took some logical deduction. I could see something on the screen in distinct areas, moving in predictable patterns so I decided the code was probably running correctly, but the image data was either corrupt or loaded wrong.

I fixed the problems

The image data came from a file created from a sprite editor, and after finding the documentation for that sprite editor’s file format I worked out how to load in the images correctly. I even wrote a little converter script to do it for me at compile time.

And it worked!

Now I had a working sprite routine! It didn’t flicker, could cope with several sprites at once and even had a nice way to program the sprite behaviours. This wasn’t some quickly hacked together piece of code, it was a well created mini sprite engine! All I had to do was add it to my program, draw some new sprites, put it together to show off and check it functioned as I wanted.

Then it broke again, and I had no idea why

And I hit yet another major problem - somewhere along the way I’d broken it. Now sprites didn’t draw correctly at the top of the screen. Had I done all this work, only to meet a dead end that I couldn’t solve? I’d done nothing to the sprite code but tidy it up and try to draw the sprites at a different location. It still worked, but there were some strange drawing artefacts happening.

Crashing code is easy to fix, it stops at a specific point, finding that point is easy and the code is usually crashing due to bad data. Incorrect code is harder to fix, you have to look for clues. All I knew was the sprites went weird at the top of the screen, but worked fine everywhere else.

Frustrated debugging ensues

I spent many hours trying to debug this. Was my rewriting of the code wrong? Was the algorithm faulty in the first place? Was it the emulator? I had no idea. All I could do was systematically try different ideas as I thought of them, looking for patterns.

One pattern I noticed was to do with how many sprites I was drawing. If I drew one, there was no problem with it, but adding any more caused varying amounts of display artefacts to appear.

Breakthrough!

I had an idea! What happens if I change the timer value so that the timer interrupt fires more frequently? If my code is taking longer to run than the demo code, it makes sense the timer should have a shorter delay. Chasing the beam is timing dependent and if my code runs inconsistently, the tearing comes back. I have to use trial and error to find values for the timer that work properly. I’m calling it beam chasing, rather than beam racing because we’re always behind and trying to catch up to it. The amount of lag is the spare time we can use for doing our code. It’s not quite Atari 2600 levels of spewing out pixels exactly as the beam scans the screen.

Success!

And success! It worked! I’m sure I will need to come back and edit this timer value later and there will be a limit to how much processing can be squeezed in between each frame.

This code is really cool, I’m making a 2MHz CPU calculate and move data in the time it takes the CRT’s electron gun to go from the bottom of the screen back to the top. This is totally the kind of thing I was trying to learn.

And I learnt a valuable lesson

I learnt that given enough time and a bit of intuition, I can usually solve most problems. I’ve also had some very useful experience of what my students go through when I put something on the board and say “all you have to do is …”. It’s easy when you know the answer. Finding the answer is difficult and frustrating. And now I've had a good feeling of that frustration that comes with being so stuck you have no clue where to look or even how to work things out.

I'll use this at work, and will make efforts to explain my thought processes to my students so they can understand how to figure out their own problems.

Bbc Micro - Computer Literacy 1980s

James — Mon, 10 Aug 2020 13:27:38 +0000

Now I’ve gained an understanding of assembly programming, let’s look at how they tried to teach us computer science in the 1980s…

Watch the video!

Visit my YouTube Channel To see It

Intro

I’m a programmer and the computer itself has always been a black box that I was insulated against, writing my code in a higher level language like C. I didn’t need to know about registers, or care much about where my code was being put in RAM.

I’ve always had a deep fascination with how things work at a low level though, and that’s what we’re looking at in these videos.

I’m trying to present technical information, but in a straightforward way - just like a 1980s computer manual. Nothing is dumbed down, but instead explained clearly enough that most people should be able to follow it.

You can get so much more out of a machine if you start trying to write code on it. It stops being a passive device like a TV, and instead becomes something you are in control of.

Z80 vs 6502

In the 80s there were two main competing CPUs. The Z80 made by Zilog, used in the ZX Spectrum line of machines and the 6502 made by MOS Technology used in things like the Apple2 and C64.

The Computer Literacy Project

Back in the early 80s the BBC started something called The Computer Literacy Project; a series of TV programs and literature with the aim of teaching the British public all about these new-fangled computers that were predicted to slowly take over their lives.

To do this they needed a computer specifically for the purpose and after some fussing and debate the BBC Micro from Acorn was the end result. Documentaries have been created about this and are worth finding and watching.

As a kid who grew up in the 80s I had no idea this was going on, I just thought computers were cool and that they were a thing people just used, like cars or TVs.

The BBC Micro is solidly built from beige and black plastic with real keys. You can see the machine was clearly designed to withstand ten year olds hammering away on it in classrooms. And hammer away on them we did. Schools would often have at least one, possibly an entire room with maybe as many as twenty! Hey, it’s the 1980s remember, we were still getting used to colour TV. Having an “interactive TV” was pure science fiction.

As it was designed to be an educational machine for people to experiment with, it featured many things other micros of the time lacked.

BBC Micro Specifications

For the time the machine had a modest but capable set of specs. Due to internal design, the 2MHz CPU could quite easily keep pace with Z80 machines running at twice the speed.

The main fun though was found in the number of expansion ports on the BBC. You see your typical micro of the time had the usual sprinkling of video, I/O and controller ports. Something to get data in and out, a way to see what the machine was doing and some kind of extension of the CPU’s bus for extra hardware.

The BBC had these and more. Having just one I/O port wasn’t enough, they added three. One of those was designed so other CPUs could be connected to the machine, another operated very much like the GPIO pins on a raspberry pi.

And if that wasn’t enough, users were encouraged to open the thing up and swap out ROM chips to add extra functionality. In a time when floppy disks didn’t hold much data, and load times were slow, putting software on physical ROM chips was popular. The BBC took it to the next level though and sold commercial software in this way, requiring users to open the machine and install the chips themselves.

Back in the 80s you weren’t an “end user” with restricted privileges or a “technical user”. You just used the machine, and if it required programming, or opening up, well that’s what you just did. After telling you how to plug the machine in, the first thing the manual gets new users doing is experimenting with commands to see what happens.

Conway's Life in Z80 Assembly

James — Mon, 27 Jul 2020 12:48:03 +0000

After the fun of writing the Zombies game in Z80, I had a go at writing a version of Conway’s Life in Z80.

Watch the video!

Grab the code!

The source code and compiled binary can be obtained from my Github Repo here. Feel free to copy it and make modifications. If you fix or improve it, let me know!

Life? What is Life?

Life is a type of program called a cellular automaton which is just a fancy way of saying it’s a simulation. In this simulation there are small units called cells, and each cell can be either alive or dead. Their state is dictated by a set of rules, and their neighbouring cells. The rules are really simple

A cell with 2 or 3 neighbours remains alive if it already is
A cell with 2 neighbours comes back alive if it’s dead
A cell with anything else dies off, or stays dead

From these simple rules you can get incredibly fascinating patterns, and it’s a great example of something called emergent behaviour

DEV Community: James

How a CPU really works

Related posts:

Solar battery usage

Related posts:

How trying to make pocket calculators do complex maths accidentally invented modern computing

Related posts:

Why the 1880 US Census lead to the invention of the computer

Related posts:

RC2014 Raspberry Pi Pico VGA Terminal Self-Build

Related posts:

Devlog 01 - Spectrum Next Programming Languages

Watch the video

How to program a ZX Spectrum Next

NextBASIC

C

Z80 Assembly

My Setup

You do realise  is far simpler, right?

Grab my code

Quazar Graphic OLED Display - Real Pixels for your RC2014

Real Pixels?

Video

How the Quazar OLED Display works

Grab the source code

How To Program The Quazar Graphic OLED Display

Step 1 - Draw some pictures

Step 2 - Write the code

Optimised Z80 - Conway's Life Improved

Intro

Watch the video!

Grab the code!

Don’t prematurely optimise

Make it work first

Make it work better later

You can’t polish a turd

Other people can help

Prototype, focus on the algorithm

Don’t over generalise

Specific problems require their own specific solutions

Cheat if you can

Constants and the pre-processor are your friends

Remove redundant code

Reorganise the instructions

Apply the dark arts last

Instructions have side effects

Don’t over optimise

Summary

Bbc Micro Mega Upgrade

Watch the video!

Intro

Setting up a Gotek floppy emulator

Upgrading the floppy controller

Burning EPROMS

Success

How I Became a better Computer Science teacher

Watch the video!

My day job

What I wanted to do

I found a way to draw sprites

But it didn't work

So I had to find a new way

The new way didn't work

I fixed the problems

And it worked!

Then it broke again, and I had no idea why

Frustrated debugging ensues

Breakthrough!

Success!

And I learnt a valuable lesson

Bbc Micro - Computer Literacy 1980s

Watch the video!

Intro

Z80 vs 6502

The Computer Literacy Project

BBC Micro Specifications

Conway's Life in Z80 Assembly

Watch the video!

Grab the code!

Life? What is Life?