Foenix IDE

Description of your first forum.
User avatar
grenouye
Posts: 31
Joined: Sat Apr 13, 2019 1:57 pm
Location: Halifax, NS
Contact:

Re: Foenix IDE

Post by grenouye » Thu Nov 14, 2019 2:41 am

Hi everyone,

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.
FoenixIDE-SDCard-Loading.png
FoenixIDE-SDCard-Loading.png (218.12 KiB) Viewed 797 times
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.

Cheers!

Grenouye
frenchguy
Posts: 32
Joined: Tue Oct 01, 2019 11:45 am

Re: Foenix IDE

Post by frenchguy » Thu Nov 14, 2019 9:52 am

Cool! :)
frenchguy
Posts: 32
Joined: Tue Oct 01, 2019 11:45 am

Re: Foenix IDE

Post by frenchguy » Tue Dec 03, 2019 5:21 pm

Quick question: is the Vicky VDMA implemented/supported in the Simulator ?
User avatar
grenouye
Posts: 31
Joined: Sat Apr 13, 2019 1:57 pm
Location: Halifax, NS
Contact:

Re: Foenix IDE

Post by grenouye » Wed Dec 04, 2019 12:31 am

No, the VDMA is not implemented in the IDE/emulator. The VDMA is very basic in the machine at this point (Rev B), it only allows copying a single byte into a 1D or 2D array.

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.

Grenouye
User avatar
grenouye
Posts: 31
Joined: Sat Apr 13, 2019 1:57 pm
Location: Halifax, NS
Contact:

Re: Foenix IDE

Post by grenouye » Wed Dec 04, 2019 2:46 am

As previously stated, the VDMA implementation only took a couple hours to add.
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.

Have fun!

Grenouye
Attachments
FoenixIDE-VDMA.png
FoenixIDE-VDMA.png (25.05 KiB) Viewed 699 times
frenchguy
Posts: 32
Joined: Tue Oct 01, 2019 11:45 am

Re: Foenix IDE

Post by frenchguy » Wed Dec 04, 2019 4:36 am

For the moment, filling a 2D rectangle is exactly what I had in mind! I will test that ASAP in my tiny graphic library 😀
frenchguy
Posts: 32
Joined: Tue Oct 01, 2019 11:45 am

Re: Foenix IDE

Post by frenchguy » Wed Dec 04, 2019 2:09 pm

:o :o :o OMG !!
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!
frenchguy
Posts: 32
Joined: Tue Oct 01, 2019 11:45 am

Re: Foenix IDE

Post by frenchguy » Fri Dec 13, 2019 11:37 pm

Hi,

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;
The pixel is painted at bottom-right corner.

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;
The same kind of weird display appears when I just do 100% C code to light the pixel. For the curious ones :

Code: Select all

((unsigned char *)SCREEN_START)[of]=color
--> that worked fine 2 weeks ago!

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.
User avatar
PJW
Posts: 43
Joined: Wed Apr 24, 2019 12:44 am

Re: Foenix IDE

Post by PJW » Sat Dec 14, 2019 3:33 pm

frenchguy wrote:
Fri Dec 13, 2019 11:37 pm
First, apologize if what I will say is wrong because I'm absolutly bad in assembly...
No need to apologize. Comfort with assembly is pretty rare these days to begin with, and the 65816 is even more limited.
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;
The pixel is painted at bottom-right corner.
I'm not familiar with this assembler syntax, so it's a little hard to suggest something.If you have a listing that includes opcodes, that would be most helpful. Some general things to watch out for:

STA with a simple address can resolve into several opcodes depending on what addressing mode the assembler thinks you want: direct-page (what was zero-page on the 6502), absolute (a 16-bit address), and absolute-long (a 24-bit address). In this case, you could end up with either absolute or absolute-long. If it's absolute, it is going to depend on the value of the data bank register whether or not the store goes to the right location. So if the compiler used an absolute STA, you'd want to make sure the databank register was set to $AF. If it used absolute-long, you don't have to worry about it.

Second, you want to be careful in general about the M and X flags in the status register. They control the size of the accumulator and index registers. When writing to I/O devices, you will usually want the accumulator to be 8-bits, so you're going to want M set (if I remember the meaning of the flags correctly).

The real problem with these is that your compiler/assembler needs to know what the value of the databank register, direct page register, and M and X flags are while it's assembling your code, and it is really easy for the values to get out of sync with the code (for instance: you have a routine that wants the accumulator to be 8-bits, but it calls a routine that switches the accumulator to 16-bits but isn't good about switching it back).

I would say 3/4 of the issues I have had with my code on the 65816 involve my code assuming an incorrect value for the direct page register, databank register, or the M and X flags because I wasn't careful enough about saving and restoring those values in some subroutine.
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;
The issue might be this: X (and Y) is a 16-bit register, so it cannot be 0x4AFFF, the closest it can get is 0xAFFF. So, the effective address of SCREEN_START,X in that case would be 0xB0AFFF, which I think would be somewhere in the middle of the screen.
frenchguy
Posts: 32
Joined: Tue Oct 01, 2019 11:45 am

Re: Foenix IDE

Post by frenchguy » Mon Dec 16, 2019 11:28 am

Thanks for the explanation. I understand better the long adressing mode. Indeed it has something to do with that. In fact the C compiler produced a good assembly for the program that worked, but since it produced something very different, even when the C code is exactly the same. Maybe some configuration or compilation option.. I gonna investigate.
Then, no regression or bug it the simulator :-)
Thanks
Post Reply