This will have to be changed, some things like the VGA connector will
not work because they will interfere with the cpu adapter.
It may be worth thinking about making these smaller and not including
the ethernet for example, since that will not come for a while.
The only things we really need to start are the SD card and serial port.
Don't have the FPGA on the shield, just have it be a board that plugs
into the FPGA.
Don't mind the component and footprint choices yet, I still need to
figure out exactly which parts to use.
Split the project into two parts, the adapter will connect the cpu
directly to the FPGA, and the shield will house all of the peripherals.
I will get the adapter first so that I can get things like sdram
working first, and then make the shield with things like SD card, USB,
maybe even ethernet and VGA. Basically anthing since it's connected to
an FPGA.
I think that previously, I had not actually commited any of this to git.
This adds all of the new effinix stuff that I had been working on for
months.
The gist of all of this is that the intel fpga is expensive and does not
exist, whereas the effinix ones are not as expensive and more existant.
This redoes the project to use the dev board, as well as a custom board
that I may or may not make.
Now that we are adding our own target we can compile our own toolchain
instead of using the stock one. This does mean that there isn't really a
purpose to using the alpine cc65 image though
Now that the ROM is just a bootloader and the kernel is stored on the SD
card, we do not need to be constantly changing the ROM.
Disabling the memory editor dramatically reduces compilation time which
will be useful when implementing FPGA features in the future.
Instead of using the bootsector to load a bootloader, just put the
bootloader in the ROM and call it a day. It looks for a file on the SD
card in the root directory named `kernel.bin` and loads it into memory.
This is not a perfect solution, as the kernel will grow larger and the
kernel load address will have to change. At this point I could add back
the bootloader, but that is for later.
Also the bootloader is just a copy of the kernel, so that can be trimmed
down a lot.
I forgot that the CI still uses the stock cc65 which doesn't support my
target. The kernel doesn't really need this target though, only the user
programs.
Kernel is now compiled and linked into a raw binary instead of intel
hex. This raw binary can be loaded into the correct address by the
bootloader.
I wanted this to be an o65 file, but ld65 kept complaining about it.
Honestly though having this be a straight binary makes it easier to
load, but we can't relocate it.
The boot environment will read the boot sector from the sd card, verify
that it has the boot signature at the end, then jump to the start of it.
From there, there should be a bootloader written to the boot segment
that can handle the rest.
It might be tight to fit everything into the boot sector but do remember
that you do not have to initialize or select the sd card, and those
functions take up a lot of space.
