Friday, December 4, 2020

Mica Computer 6502 64k

The new hardware prototype board is sort of done, it allows for the extra ram now and its much less messier than it was before.


this as you can see has the SCART lead on the side, for that lovely RGB out, 15khz (50hz PAL) screen
NTSC signals aren’t in yet, as i still haven’t worked out the timing for this yet.

Right now the 8MegaByte isn’t accessible, possibly due the the configuration or my wiring, but we o have access to 4Mb.

The system s runing at 450Mhz, access to SDCARD

This also has a nice feature of a joystick port…… that will read Amiga Mouse, left and right mouse button


As you can see the mouse pointer is there, and the system saying Sidbox 5 computer.

This is Mica.
Running 6502 code, with 64k ram, but do plan to run 256k available ram.
a rom space thinking about 8k or 16k
this rom will contain some functions and so far our testing has worked!

thanks to the work of by Jesper Gravgaard / Rex of Camelot

This helped alot! speeding up debugging the hardare and the computer memory mapping.

So we have our machine that boots up with its own internal rom, (1k so far and thats just for the boot up and logo!! hmm i’ll definetly be doing some stripping down and optimising ofcourse, we got functions and features to pack into an 8k or 16k rom)

Turn on the computer (or switch to Mica mode) runs the bios, we see this…

after a short animation:
this shows up (tho we may change this later)


so when the screen shows, we’re normally used to just slapping your keys and writing the classing
10 print “hello world”
20 goto 20

Well since our rom doesnt come with a BASIC, (I hope I can find one though)
since I need to find a way to get our keyboard to feed this mica! so far only the joystick port is readable!

The work continues.

This machine seems to clock between 1Mhz to 3Mhz depending on whats on the display..

Monday, June 22, 2020

Sidbox 5 - CRT output video

While we’re working on the sidbox 5 hardware, getting to know the new big brother MCU- this chip is fast!!
with the work with DMA and memory transfer faster than id hoped!

With the displays now arriving and the work getting to know the STM32H743 - the hardware is proving to be amazing.

checking out this video

In this video - I am demonstrating the power of the chip.
its producing a pretty stable video output, with RGB, no shading.. meaning it can only display up to 8 diferent colours (we’re thinking about a 16bit data output through one of the PORTS on the STM32, if we can do that then we’ll be able to get 65k colours using a resistor ladder network (or just a dedicated dac system) the only problem I am facing, IS the sort of wobbling scanlines due to the interupts the chip seems to be doing in the background - I HAVE tried to turn many of these off. But when I did, I broke the main code and things just stopped working.

ANYWAY for now, I am demonstrating the chips real time processing, and a nice little suprise!

the CHIP runs DMA to produce the video blanking pulses, and 3 SPI bit streams via DMA.
This means the chip is transfering this information independently to the CPU, and only feeding back an IRQ to the CPU When the SYNC pulses are finished.

the CPU is NOT held up while the CRT is getting its data.. the only thing the CPU MUST do is listen out for the end of the SYNC pulse sequences, and restart it - the TV and the PVM and the massively picking BVM both sync up perfectly to the pulses.

SO I started off a bit of music, basically a WAVE file that is streamed off the SDCARD.
the sdcard uses again a DMA to stream the audio buffer, and only interupts the CPU half way the DMA stream and at the end of the DMA stream, to tell the cpu “please fetch a bit more music”

now the crazy part is.. THIS was happening WHILE the CRT image was still being produced!

so we ran the asteroids program which is independent software in ram else where, and the interupt settings where not reset.. as a result the game still used the video memory and the crt still produced its image… and the music was still getting its music! all with IRQ, DMA, and SPI with PWM! the CPU is hardly doing anything!!

STM32H743 IS going to make the sidbox some sort of magic in a box!………………… AT LEAST i really hope so

Sunday, May 17, 2020

A working DMA AUDIO output

sidboxv5begin.png The project begins to take life now; While its taken me a LONG time and most of my hair is still present!
I still have a long way to go, but I do have something that is causing us some excitement!

While working on the SDCARD (which now appears to be fully working now) I wanted to see if I could get the SDCARD to stream some audio.

At first I did this the old way as the Sidbox 4 does this, uses an interupt with a read and write audio buffer positions. While this works really well on the Sidbox 4 OS, this chip has 400Mhz and a few DMA channels, one of which is a DAC.

I can setup an audio buffer, and have that memory transferred at 441khz to the DAC, leaving the CPU free to do something else! The issue I got with this though is the DMA seems to collide a bit while using the FatFS (but thats just a current bug for now)

So the while it plays it just choses to put the new data in to the audio buffer

To Get this to work I had to wire up the following.

Note that this has NO Card Select! I was confused by this, but I found that I had to find away to tie the CS to 3.3v, the SDMMC1 port onthe STM32 takes care of everything else.


So Now I have the SDCARD playing 8Bit Wav Files at 44100Hz and its done via the DMA,
all the CPU has to do when called via an interupt is to fetch another 1k of audio and stuff it in to the audio buffer.

Wednesday, May 13, 2020

SDCARD - Nucleoboard

nucleo.jpg The Nucleo-H743ZI2 - How much did I just bite off!!! Been at this problem for almost 2 weeks now, the SDCARD reader, VIA the SPI and SDMMC1 while they both worked with the example code, but those example code had other parts i didn’t need. So removing the parts that were’nt relevent to me my project, I ended up breaking the code.

IT was clearly required to create a whole new project - Now I’ve done this multiple times and each time the sodding FatFS didn’t work!

After I Found the debug infomation and actually a HUGE amount of info from a Facebook user by the name of Jeff, lent me his code for the sdcard, it wasn’t completed and didn’t work for what I needed, HOWEVER It did point me to the directions of the missing commands!

In the file

__weak uint8_t BSP_SD_Init(void)
  uint8_t sd_state = MSD_OK;
  /* Check if the SD card is plugged in the slot */
  //if (BSP_SD_IsDetected() != SD_PRESENT)
  /* HAL SD initialization */
  sd_state = HAL_SD_Init(&hsd1);

  return sd_state;

what I did was the comment the check to see if the card was inserted, while I will put this in later, i just wanted to know if the card worked.

The SDCard has 2.2K resistor pull-ups, connected to MOSI, and MISO - the MX IDE calls these, SDMMC1_CMD (mosi), SDMMC1_DO (miso).

on the Nucleoboard there are red, green and a yellow.

#define GREEN_PIN                                GPIO_PIN_0
#define GREEN_GPIO_PORT                          GPIOB

#define YELLOW_PIN                                GPIO_PIN_1
#define YELLOW_GPIO_PORT                          GPIOE

#define RED_PIN                                GPIO_PIN_14
#define RED_GPIO_PORT                          GPIOB

void PrepUserOI(){


	GPIO_InitTypeDef GPIO_InitStruct = {0};
	GPIO_InitStruct.Pin = GPIO_PIN_1;
	GPIO_InitStruct.Pull = GPIO_NOPULL;
	HAL_GPIO_Init(GPIOE, &GPIO_InitStruct);

	GPIO_InitStruct.Pin = GPIO_PIN_0;
	GPIO_InitStruct.Pull = GPIO_NOPULL;
	HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

	GPIO_InitStruct.Pin = GPIO_PIN_14;
	GPIO_InitStruct.Pull = GPIO_NOPULL;
	HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

inside the main file
the annoypart was to tell the system to START the sd_init();
sadly i couldn’t find this in the information documenations normally provided by ST.

here is how I got it working

 /* Initialize all configured peripherals */
  char res;
  //res = disk_initialize(0);
	res = BSP_SD_Init();
	if (res == FR_OK) {
		res = disk_initialize(0);
		if (res == FR_OK) {
			res = f_mount(&fs, "0:/", 0);
			if (res == FR_OK) {
				strcpy(buffer, "Hello world, this is a test");
				if (f_open(&fil, "hello world test file.txt", FA_CREATE_ALWAYS | FA_WRITE)
						== FR_OK) {

					f_write(&fil, buffer, sizeof(buffer), &bytes);




the code uploaded and begin to run, and instead of the yellow pulse range of around 200khz, i got the fill 12Mhz and some Blue pulses (this is the Data to the SDcard - MOSI)


with this I made a backup of this as the whole ordeal was awful!

BUT I concluded that while messy, the IDE and MX did do a good job of filling in the SDMMC1 and paring up to the SDCARD FatFS 0.12C

I have included the download of this project (its only for the Fat32 access)
CubeIDE GCC - C (not C++) Download Source

I’ll write up a more detailed what I found, how I figured out how to get this system to work!