Add reading, parsing, and basic executing of o65 files

See merge request !13

These are technically pointers, so lets type them as such.

This will read the data from the sd card, copy it to the originally
linked address (no relocation), then execute it.

I am lazy and wrote it in C using weird function pointer casting but
this would probably be more efficient if it were to be written in
assembly instead.

The test program simply returns 'A', but that is enough to prove that it
is actually running.

These were used to help understand the o65 file format, but are not
needed and shouldn't have been commited anyway.

These are object files still, which means we do not want to track them.

I had used these to try and help figure out the structure of the o65
file but this is not needed anymore

Prints out the options now too.

Prints out information about the first file found on the SD card, if it
is an o65 file.

This adds a test program which can be loaded and executed by the host.
It simply returns a value in the `a` register.

The linker script is modified so that it will output an o65 file, and
the memory sgments are changed as well. There is no STARTUP segment
defined, so it uses the default `none` crt0, which sets up the stack
and does initialization and deconstruction.

The Makefile is modified to not turn the output into an intel hex file,
and instead keep it as the o65 file.

These can be used to read and parse o65 files.

Read data from a file

See merge request !12

Prints out information about the drive, now inside its own function.

Also changes the read function to take in a 32 bit address instead of a
16 bit one.

Attempts to read the first file on the disk

Adds filesystem info struct and directory entry structs

Prints out all of the parameter blocks for the SD card.

Adds some struct types for the FAT32 file system.

This just includes the information in the parameter blocks, not any
actual files.

Add a simple function which reads a 512 block from the SD card and then
prints it to the console.

The but count should be set to 7 when entering RXDATA. previously it was
not reset or left at 0, which caused the first byte to only have the lsb
set and all other bits to be read incorrectly.

This was probably an off-by-one mistage, with the width set to 10
instead of 9. The width should be 9 since the buffer is 512 bytes.

Add SD Card Controller

See merge request !11

Adds some missing cases, length specifiers.

Adds functions to wait for data to be read, and to read data form the sd
card controller.

After a data read (e.g. CMD17) the data received from the SD card is
stored into a buffer which can be read back one byte at a time by the
CPU through address 5.

There is also a flag which is set when data is received. This can be
checked by reading the CMD register, which doubles as the status
register.

Adds a new memory location for data accesses.

Polls the sd controller until the read flag is set, at which point it
reads 32 bits of data from the controller.

long response codes (such as CID) are not supported in hw or sw.

Read flag is set when the sd controller reads response data in from the
sd card. When the cpu reads from the controller, the flag is reset.

This flag does not trigger an interrupt, it mmust be polled.

These series of commands are enough to read the first 512b block off of
the sd card. The RCA is hard coded to the sd card that I have on hand,
since response codes are not supported

Adds a function to send a command to the sd card.

Also adds the logic required for the bidirectional sd lines and attaches
the controller to the cpu.

The SD card expects data to transition on falling edges and be stable on
rising edges.

Additionally, writes from the CPU were not handled with correct timing.

Now, there is an extra state when writing to the command register so
that the command is properly latched before the CRC is calculated.

Updates the testbench to simulate writes with more correct timings.
Writes take two clock cycles since the cpu runs at half speed.

Sends a few commands which we know the proper checksum for and makes
sure that the bits on the output are correct.

Adds the start of the SD card controller which is capable of sending
commands using the SD protocol.

It is accessed by writing the arguments first and triggered by writing
the command number.

Previously the crc would be reset after 1 clock cycle while the valid
signal was still high. Now the data is preserved in the valid state
until the load signal is asserted.

These are just some values that I found from an example program. This
does not test every possible value.

This module takes in a 40 bit word and generates the 7 bit crc7
appropriate for an SD card.

It does not use any fancy parallel algorithm, it does it 1 bit at a
time.