Just a quick post to let you know that I've started implementing the SD card emulation. While this is pretty straight forward on the surface, the IDE needs to convert paths and file names to be FAT compatible. So, the new version of the IDE now allows you to pick a path that the emulated SD card will start from (the root).
In the picture below, my path is pointing to my RAD files, on my local disk drive. The C256 Tracker reads the SD Card root to retrieve the list of files and folders. The Windows filename is mapped to the name provided as an 8.3 filename. In the image, you will notice that several files are named PAYBAC~1, PAYBAC~2, etc. The IDE does this to ensure each file name is unique. When the file is called from the SD card code, the IDE will reuse the mapping to retrieve the correct file. I have yet to implement the next function: allowing the files to be read. This should be ready in a couple weeks (I'm away for work next week).
Anyway, update your IDE and use the SDOS.asm from the kernel library to exploit this new feature.
I was waiting to see how this feature was going to evolve (in the FPGA) until I implemented the emulation of it.
If you see a need for this (the single byte copy), let me know and I will do it. It should be pretty quick.
The only capability supported in 1D and 2D fill of a single byte. When/if the FPGA for Vicky is updated, then I'll update the code too.
I've also found a bug in the bitmap display of the GPU. So this is also fixed.
I've attached a screenshot of Stef's Jumpman Senior page (which she had added 1D and 2D copy code). The 2D rectangle changes colour with the SOF interrupt, but it's only copied once. This effect is called LUT cycling.
The Foenix IDE version 0.2.6.2 can be gotten from Github.
I'll tag the release accordingly.
- FoenixIDE-VDMA.png (25.05 KiB) Viewed 71 times
I have just finished to implement and test a rectangle filling function using the VDMA and it's... amazing!! ("à la" Apple keynote, lol). Drawing 300 filled rectangles is almost instantaneous in the simulator. I will post a short video when I will have time.
That sounds very good for the hardware version!
First, apologize if what I will say is wrong because I'm absolutly bad in assembly...
Since several days I am chasing a strange bug that appeared in my test app written in C.
But I don't know why, because I have checked and re-checked my code and I do not see what could be wrong, I even have not changed code in the specific part where the bug appears.
It is about strange display in bitmap mode. Pixels are not drawn at the right place when the adress is greater than a certain amount.
Then I have tried something in inlined assembly in my C code. I want to light a pixel at the bottom-right corner (that should be B4AFFF).
When I test this following code, it works (given that %%color is a byte, and %%SCREEN_END is a #define with B4AFFF). it's inlined assembly, the compiler will replace %%xxxx with the values:
Code: Select all
longi on;lda %%color;sta >$%%SCREEN_END;
But with the following (given that %%of is 0x4AFFF and %%SCREEN_START a #define of B00000) displays the pixel not in right place at all.
Code: Select all
longi on;lda %%color;ldx %%of;sta >$%%SCREEN_START,x;
Code: Select all
((unsigned char *)SCREEN_START)[of]=color
Then i wonder if there is not a regression in the simulator assembly ?
PS: if I directly change B4AFFF in the memory map in the simulator, the pixel is well drawn at bottom -right corner.