trinity-11 / foenixide Goto Github PK

View Code? Open in Web Editor NEW

45.0 45.0 13.0 28.17 MB

Development and Debugging Suite for the C256 Foenix Family of Computers

License: GNU General Public License v3.0

C# 84.31% HTML 13.07% Assembly 2.55% Batchfile 0.01% Shell 0.03% BASIC 0.04%

foenixide's People

Contributors

Stargazers

Watchers

Forkers

bzuidgeest dwsjason aniou marcellodash scttgs0 shoulderrats clandrew marnuba cptnroughnight fredsa polluks mu0n dws14159

foenixide's Issues

Kernel Null on start up when WatchUpdateTimer_Tick runs

Some times when I start up the FoenixIDE, it immediately throws a kernel null error. It happens before the select kernel dialog appears. I found a little work around, though I think it is just a case of the timer starting before a kernel is chosen successfully. My work around is:

C:\git\FoenixIDE\Main\UI\WatchForm.cs
private void WatchUpdateTimer_Tick(object sender, EventArgs e)
{
if (kernel == null) return; //avoid null kernel error in foreach loop below._

foreach (KeyValuePair<int, WatchedMemory> kvp in kernel.WatchList)

Unable to reliably run compiled code in Foenix IDE

I think there is a bug in the current version of Foenix IDE 0.5.5.7, but I do not know enough of the internals to speculate what might be causing it. Below, I will describe a scenario that I run through. The usage below is pieced together from a combination of the c256 wiki and youtube videos.

// System setup

On Windows, I have the wdc compiler installed to c:\wdc.

This is the code I am running: https://pastebin.com/RZApyKRP

The pastebin above shows (1) source of the fxloader.asm; (2) a main.c which is taken from the wiki; (3) a build script b.bat.

// Use-case

These are the steps I follow,
(1) In windows cmd, run b.bat. This produces main.hex
(2) Start a fresh instance of Foenix IDE 0.5.5.7, which has "Settings > Autorun Emulator" enabled.
(3) Press enter to go to the FMX repl/prompt.
(4) In the Foenix IDE Debug window, press pause
(5) In the Foenix IDE Display window, use "File > Open Hex File" and select the main.hex just created
(6) In the Foenix IDE Debug window, enter 010000 to the jump address and press jump
(7) In the Foenix IDE Debug, press run.

What I expect to happen:
(1) I should get the letters HELLO printed out on the display.
(2) Uncertainty about what should happen after the C code finishes (see note below, "Further query")

What happens on my system:
(1) After I press run (once), it does not keep running but pauses again.
(2) If I press Run a second time, it keeps running. In both cases, I see nothing show to the display.
(3) When I press "Reset > Restart" in the Foenix IDE, the display changes, and I see HELLO in red at the top, with the vertical parts of the border gone. At this point, the debug system pauses again.

Further query: after the C program is finished, should the user be returned to a working REPL? I read somewhere that if you finish an assembly program with BRK/BRK, then this happens. What would need to happen in the C sample program that would deliver the same result?

Wrong NativeWidth leads to "horizontally fat pixels"

Cause and Symptoms

In Main/Display/Gpu.cs (https://github.com/Trinity-11/FoenixIDE/blob/master/Main/Display/Gpu.cs)
there exists two public int constants: NativeWidth and NativeHeight which are set to 768 and 480 respectively.

However, every Foenix machines has only ever needed this set of possible resolutions:
640x480
640x400
800x600
1024x768
(source: Stefany Allaire herself!)

The result leads to horizontally stretched images such as this test pattern where the screen is filled with the lower case letter l. You will see that some columns of the letter l are slightly wider than others:
(this is under scaling 2.0x) - click on the image thumbnail to see the 100% real state of it

If you change NativeWidth from 768 to the correct 640, you get this image where every letter is perfectly identical (this should be the desired end result) - click on the image thumbnail to see the 100% real state of it

Testing it under Livingworlds.pgz, we get the incorrect 768x480 stretched version:

Followed by the correct 640x480 version:

LDA/LDX/LDY doesn't set N for 16-bit values

Looks like LDA, LDX and LDY doesn't set N flag when highest bit of 16-bit value is set.
They works properly in 8-bit mode, though.

I tried immediate and direct modes.

clc
xce
setaxl
lda #%1000_0000_0000_0000        ; N = 0, should be 1
ldx #%1000_0000_0000_0000        ; N = 0, should be 1
ldy #%1000_0000_0000_0000        ; same as above

XBA (0xEB) opcode not implemented

Hi,
following code causes FoenixIDE emulator crash with error: "System.NotImplementedException: ExecuteMisc() opcode not implemented: EB"

XBA description

             CLC
	     XCE
             setal
             lda #$1234
             xba

(SD Card Emulation) File storage error while accessing files with more than 3 letters in the extension

the current sd card functionality doesn't seem to support file extensions above 3 letters
I tried to load Enersto's dice roller basic program:
https://ptb.discord.com/channels/691915291721990194/988706842685345793/1165093964601372704
here, it fails to load the dice20b.bspr file

after editing that line and changing the file extension to 3 letters only, it loads fine

Here are the settings I'm using in the sd card emulation dialog:

open hex file w/o zeroing resets cpu state

Currently reading hex file with "File -> open w/o zeroing" resets CPU state:

In my opinion preserving registers, flags etc. will be useful during testing code snippets - and if reset is needed, there is even option for that.

F256, Boot To Flash or RAM?

The first group of developmental F256JRs had a software setting for whether the F256 boots in Flash or RAM mode and the rest of the mini ITX versions of the JR had a hardware jumper. The F256K returned to a software setting for the boot mode. Any plans for a setting in the IDE's Upload Tool for the boot mode when it comes to the F256?

debugger doesn't show some mnemonics

Hi,
looks like debugger doesn't show some mnemonics, see:

corresponding .lst file:

.030074	a5 e9		lda $e9					lda MY_ROW
.030076	1a		inc a					inc a
.030077	1a		inc a					inc a
.030078	c5 13		cmp $13					cmp LINES_VISIBLE   	 ; we are at or over last line?
.03007a	b0 5e		bcs $0300da				bcs string_done    		 ; A >= LINES_VISIBLE
.03007c	85 e9		sta $e9					sta MY_ROW

BIT command requires small correction

Hi,
BIT command is somewhat irregular and surprising, when comes to flag setting. According to manuals there is a difference in modes (immediate and others) and only Z flag is set from result - N and V are set from argument (but not in Immediate case). See: http://www.6502.org/tutorials/65c816opcodes.html#6.1.2.2

Following code should works for me:

        public void ExecuteBIT(byte instruction, AddressModes addressMode, int signature)
        {
            int data = GetValue(addressMode, signature, cpu.A.Width);
            int result = cpu.A.Value & data;
            cpu.Flags.SetZ(cpu.A.Value & data);
            if (addressMode != AddressModes.Immediate)
            {
                if (cpu.A.Width == 2)
                {
                    cpu.Flags.oVerflow = (data & 0x4000) == 0x4000;
                    cpu.Flags.Negative = (data & 0x8000) == 0x8000;
                }
                else 
                { 
                    cpu.Flags.oVerflow = (data & 0x40) == 0x40;
                    cpu.Flags.Negative = (data & 0x80) == 0x80;
                }
            }
        }

ExecuteLDX and ExecuteLDY function incorrect

In file operations.cs there is a bug with ExecuteLDX and ExecuteLDY. They set N and Z based on the A register and not the X or Y register respectively. This is different from aniou's earlier issue.

public void ExecuteLDX(byte instruction, AddressModes addressMode, int signature)
{
int val = GetValue(addressMode, signature, cpu.X.Width);
cpu.X.Value = val;
cpu.Flags.SetNZ(cpu.A);
}

    public void ExecuteLDY(byte instruction, AddressModes addressMode, int signature)
    {
        int val = GetValue(addressMode, signature, cpu.Y.Width);
        cpu.Y.Value = val;
        **cpu.Flags.SetNZ(cpu.A);**
    }

Should be:

public void ExecuteLDX(byte instruction, AddressModes addressMode, int signature)
{
int val = GetValue(addressMode, signature, cpu.X.Width);
cpu.X.Value = val;
cpu.Flags.SetNZ(cpu.X);
}

    public void ExecuteLDY(byte instruction, AddressModes addressMode, int signature)
    {
        int val = GetValue(addressMode, signature, cpu.Y.Width);
        cpu.Y.Value = val;
        **cpu.Flags.SetNZ(cpu.Y);**
    }

I found this by comparing the execution to the WDC simulator/debugger.

p.s. ( I also noted this on the discord )

Resolution choices under Settings | View Scaling menu are not correct

The resolution choices shown are 640x480 and 640x400. The 640x400 resolution only applies to the F256.
The resolution should obey the Master Control Register (MCR). For FMX, the resolution of 800x600 should be available, only when the H bit is set.

A table should be build, based on the different boards, e.g.

            |   Rev B   |   Rev C |  Rev U | Rev U+ | Rev F256Jr |  Rev F256Jr (816) | Rev F256K | Rev F256K (816) |  
640x480     |    X      |     X   |    X   |     X  |     X      |        X          |    X      |       X         | 
640x400     |           |         |        |        |     X      |        X          |    X      |       X         | 
800x600     |           |     X   |        |        |            |                   |           |                 |

We need to confirm what the actual modes are.

Incorrect multipication results in BASIC

In the IDE, this works:

z=1
z=-z
print z

returns -1.

If I use this,

z=1
z=z*-1
print z

returns 65535.
The Foenix FMX correctly returns -1.

Installer produces a shortcut in Start menu which doesn't work

To reproduce: install the IDE with "Just for me", or for all users.
Look the produced link:
For just me, the target file is e.g. "C:\Users\Vincent\AppData\Roaming\Microsoft\Windows\Start Menu\Programs"
For all users, the target file is .e.g "C:\ProgramData\Microsoft\Windows\Start Menu\Programs"

But it seems it should point to the actual exe.

(SD Card emulation) Endless looping directory listing

Using the new feature for SD card in the menu Tools/SD Card, using these default settings:

(Enabled SD Card: checked, A folder inside my host PC is selected. Capacity: 64 MB, Cluster: 512, Type: FAT32)

I get an odd behavior whenever I try to list the directory. This happens in both dos and in superbasic. The directory will endlessly loop back from the beginning as it lists the file. This happens only when you reach 15 items or more present in the chosen directory. You can break the loop in DOS by hitting CTRL-C, but you can't do likewise in superbasic (it just silently continues to list its endless loop and ignores your break command keystroke).

This is a screencap after such a break issued while the bug is happening in dos:

Incorrect F256 math coprocessor registers

The math coprocessor registers for the F256 are not the same as on the C256FMX/U.

; Unsigned Multiplier In A (16Bits), In B (16Bits), Answer (32Bits)
UNSIGNED_MULT_A_LO  = $DE00
UNSIGNED_MULT_A_HI  = $DE01
UNSIGNED_MULT_B_LO  = $DE02
UNSIGNED_MULT_B_HI  = $DE03
UNSIGNED_MULT_AL_LO = $DE10
UNSIGNED_MULT_AL_HI = $DE11
UNSIGNED_MULT_AH_LO = $DE12
UNSIGNED_MULT_AH_HI = $DE13

; Unsigned Divide Denominator A (16Bits), Numerator B (16Bits),
; Quotient (16Bits), Remainder (16Bits)
UNSIGNED_DIV_DEM_LO = $DE04
UNSIGNED_DIV_DEM_HI = $DE05
UNSIGNED_DIV_NUM_LO = $DE06
UNSIGNED_DIV_NUM_HI = $DE07
UNSIGNED_DIV_QUO_LO = $DE14
UNSIGNED_DIV_QUO_HI = $DE15
UNSIGNED_DIV_REM_LO = $DE16
UNSIGNED_DIV_REM_HI = $DE17

UNSIGNED_ADD_AL_LO = $DE08
UNSIGNED_ADD_AL_HI = $DE09
UNSIGNED_ADD_AH_LO = $DE0A
UNSIGNED_ADD_AH_HI = $DE0B
UNSIGNED_ADD_BL_LO = $DE0C
UNSIGNED_ADD_BL_HI = $DE0D
UNSIGNED_ADD_BH_LO = $DE0E
UNSIGNED_ADD_BH_HI = $DE0F
UNSIGNED_SUM_AL_LO = $DE18
UNSIGNED_SUM_AL_HI = $DE19
UNSIGNED_SUM_AH_LO = $DE1A
UNSIGNED_SUM_AH_HI = $DE1B

Executing on Linux via Mono crashes with SIGABRT

Trying both the standalone version 7.0.0 bundled with Mono that was provided to me back in January on the Foenix Retro Systems Discord, or the current release crashes.

The application launches and I can see the UI for a few seconds, then it suddenly crashes.

System is Arch based x86_64 on a Ryzen 7840HS powered laptop currently running Linux 6.8.1. Mono is version 6.12.0. DE is Plasma 6.0.2 on Wayland.

I've attached the mono_crash file, and below is the output when launched from CLI.

mono_crash.8153863cb.1.json

Any help figuring out how to get this to run would be greatly appreciated!!

=================================================================
Native Crash Reporting
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

=================================================================
Native stacktrace:
=================================================================
0x63178d71af19 - mono :
0x63178d6c4437 - mono :
0x63178d7098e5 - mono :
0x40bd67ef - Unknown

=================================================================
Telemetry Dumper:
=================================================================
Pkilling 0x140243284002496x from 0x140243584680064x
Pkilling 0x140243525174976x from 0x140243584680064x
Pkilling 0x140243369985728x from 0x140243584680064x
Pkilling 0x140243292391104x from 0x140243584680064x
Pkilling 0x140243378374336x from 0x140243584680064x
Pkilling 0x140243397248704x from 0x140243584680064x
Pkilling 0x140243386762944x from 0x140243584680064x
Pkilling 0x140243405637312x from 0x140243584680064x
Pkilling 0x140243288196800x from 0x140243584680064x
Pkilling 0x140243374180032x from 0x140243584680064x
Pkilling 0x140243422414528x from 0x140243584680064x
Pkilling 0x140243393054400x from 0x140243584680064x
Pkilling 0x140243296585408x from 0x140243584680064x
Pkilling 0x140243382568640x from 0x140243584680064x
Entering thread summarizer pause from 0x140243584680064x
Finished thread summarizer pause from 0x140243584680064x.
Failed to create breadcrumb file (null)/crash_hash_0x81538879d

Waiting for dumping threads to resume

=================================================================
External Debugger Dump:
=================================================================
[New LWP 74754]
[New LWP 74755]
[New LWP 74756]
[New LWP 74757]
[New LWP 74766]
[New LWP 74767]
[New LWP 74768]
[New LWP 74769]
[New LWP 74770]
[New LWP 74771]
[New LWP 74772]
[New LWP 74773]
[New LWP 74774]
[New LWP 74775]
[New LWP 74776]

This GDB supports auto-downloading debuginfo from the following URLs:
<https://debuginfod.archlinux.org>
Enable debuginfod for this session? (y or [n]) [answered N; input not from terminal]
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
warning: File "/usr/bin/mono-sgen-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /usr/bin/mono-sgen-gdb.py
line to your configuration file "/home/dieter/.config/gdb/gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/dieter/.config/gdb/gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
info "(gdb)Auto-loading safe path"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
0x00007f8d011b2ec7 in wait4 () from /usr/lib/libc.so.6
Id   Target Id                                           Frame
* 1    Thread 0x7f8d010c0080 (LWP 74753) "mono"            0x00007f8d011b2ec7 in wait4 () from /usr/lib/libc.so.6
2    Thread 0x7f8d002006c0 (LWP 74754) "SGen worker"     0x00007f8d01148ebe in ?? () from /usr/lib/libc.so.6
3    Thread 0x7f8cfd8006c0 (LWP 74755) "Finalizer"       0x00007f8d01148ebe in ?? () from /usr/lib/libc.so.6
4    Thread 0x7f8cf76006c0 (LWP 74756) "mono"            0x00007f8d01148ebe in ?? () from /usr/lib/libc.so.6
5    Thread 0x7f8cf66006c0 (LWP 74757) "mono"            0x00007f8d01148ebe in ?? () from /usr/lib/libc.so.6
6    Thread 0x7f8cf5e006c0 (LWP 74766) "mono"            0x0000000040b7a43d in ?? ()
7    Thread 0x7f8cf5a006c0 (LWP 74767) "Timer-Scheduler" 0x00007f8d01148ebe in ?? () from /usr/lib/libc.so.6
8    Thread 0x7f8cf54006c0 (LWP 74768) "Timer-Scheduler" 0x00007f8d01148ebe in ?? () from /usr/lib/libc.so.6
9    Thread 0x7f8cf50006c0 (LWP 74769) "Thread Pool Wor" 0x00007f8d01148ebe in ?? () from /usr/lib/libc.so.6
10   Thread 0x7f8cf4c006c0 (LWP 74770) "Thread Pool Wor" 0x00007f8d01148ebe in ?? () from /usr/lib/libc.so.6
11   Thread 0x7f8cf48006c0 (LWP 74771) "Thread Pool Wor" 0x00007f8d01148ebe in ?? () from /usr/lib/libc.so.6
12   Thread 0x7f8cf44006c0 (LWP 74772) "Thread Pool Wor" 0x00007f8d01148ebe in ?? () from /usr/lib/libc.so.6
13   Thread 0x7f8cefe006c0 (LWP 74773) "Thread Pool Wor" 0x00007f8d01148ebe in ?? () from /usr/lib/libc.so.6
14   Thread 0x7f8cefa006c0 (LWP 74774) "Thread Pool Wor" 0x00007f8d01148ebe in ?? () from /usr/lib/libc.so.6
15   Thread 0x7f8cef6006c0 (LWP 74775) "Thread Pool Wor" 0x00007f8d01148ebe in ?? () from /usr/lib/libc.so.6
16   Thread 0x7f8cef2006c0 (LWP 74776) "Thread Pool Wor" 0x00007f8d01148ebe in ?? () from /usr/lib/libc.so.6

Thread 16 (Thread 0x7f8cef2006c0 (LWP 74776) "Thread Pool Wor"):
#0  0x00007f8d01148ebe in ??? () at /usr/lib/libc.so.6
#1  0x00007f8d0115425b in ??? () at /usr/lib/libc.so.6
#2  0x000063178d92a2bd in ??? ()
#3  0x000063178d8d3b11 in ??? ()
#4  0x00007f8d0114c55a in ??? () at /usr/lib/libc.so.6
#5  0x00007f8d011c9a3c in ??? () at /usr/lib/libc.so.6

Thread 15 (Thread 0x7f8cef6006c0 (LWP 74775) "Thread Pool Wor"):
#0  0x00007f8d01148ebe in ??? () at /usr/lib/libc.so.6
#1  0x00007f8d0115425b in ??? () at /usr/lib/libc.so.6
#2  0x000063178d92a2bd in ??? ()
#3  0x000063178d8d3b11 in ??? ()
#4  0x00007f8d0114c55a in ??? () at /usr/lib/libc.so.6
#5  0x00007f8d011c9a3c in ??? () at /usr/lib/libc.so.6

Thread 14 (Thread 0x7f8cefa006c0 (LWP 74774) "Thread Pool Wor"):
#0  0x00007f8d01148ebe in ??? () at /usr/lib/libc.so.6
#1  0x00007f8d0115425b in ??? () at /usr/lib/libc.so.6
#2  0x000063178d92a2bd in ??? ()
#3  0x000063178d8d3b11 in ??? ()
#4  0x00007f8d0114c55a in ??? () at /usr/lib/libc.so.6
#5  0x00007f8d011c9a3c in ??? () at /usr/lib/libc.so.6

Thread 13 (Thread 0x7f8cefe006c0 (LWP 74773) "Thread Pool Wor"):
#0  0x00007f8d01148ebe in ??? () at /usr/lib/libc.so.6
#1  0x00007f8d0115425b in ??? () at /usr/lib/libc.so.6
#2  0x000063178d92a2bd in ??? ()
#3  0x000063178d8d3b11 in ??? ()
#4  0x00007f8d0114c55a in ??? () at /usr/lib/libc.so.6
#5  0x00007f8d011c9a3c in ??? () at /usr/lib/libc.so.6

Thread 12 (Thread 0x7f8cf44006c0 (LWP 74772) "Thread Pool Wor"):
#0  0x00007f8d01148ebe in ??? () at /usr/lib/libc.so.6
#1  0x00007f8d0115425b in ??? () at /usr/lib/libc.so.6
#2  0x000063178d92a2bd in ??? ()
#3  0x000063178d8d3b11 in ??? ()
#4  0x00007f8d0114c55a in ??? () at /usr/lib/libc.so.6
#5  0x00007f8d011c9a3c in ??? () at /usr/lib/libc.so.6

Thread 11 (Thread 0x7f8cf48006c0 (LWP 74771) "Thread Pool Wor"):
#0  0x00007f8d01148ebe in ??? () at /usr/lib/libc.so.6
#1  0x00007f8d0115425b in ??? () at /usr/lib/libc.so.6
#2  0x000063178d92a2bd in ??? ()
#3  0x000063178d8d3b11 in ??? ()
#4  0x00007f8d0114c55a in ??? () at /usr/lib/libc.so.6
#5  0x00007f8d011c9a3c in ??? () at /usr/lib/libc.so.6

Thread 10 (Thread 0x7f8cf4c006c0 (LWP 74770) "Thread Pool Wor"):
#0  0x00007f8d01148ebe in ??? () at /usr/lib/libc.so.6
#1  0x00007f8d0115425b in ??? () at /usr/lib/libc.so.6
#2  0x000063178d92a2bd in ??? ()
#3  0x000063178d8d3b11 in ??? ()
#4  0x00007f8d0114c55a in ??? () at /usr/lib/libc.so.6
#5  0x00007f8d011c9a3c in ??? () at /usr/lib/libc.so.6

Thread 9 (Thread 0x7f8cf50006c0 (LWP 74769) "Thread Pool Wor"):
#0  0x00007f8d01148ebe in ??? () at /usr/lib/libc.so.6
#1  0x00007f8d0115425b in ??? () at /usr/lib/libc.so.6
#2  0x000063178d92a2bd in ??? ()
#3  0x000063178d8d3b11 in ??? ()
#4  0x00007f8d0114c55a in ??? () at /usr/lib/libc.so.6
#5  0x00007f8d011c9a3c in ??? () at /usr/lib/libc.so.6

Thread 8 (Thread 0x7f8cf54006c0 (LWP 74768) "Timer-Scheduler"):
#0  0x00007f8d01148ebe in ??? () at /usr/lib/libc.so.6
#1  0x00007f8d0114ba65 in pthread_cond_timedwait () at /usr/lib/libc.so.6
#2  0x000063178d98f7a0 in ??? ()
#3  0x000063178d999536 in ??? ()
#4  0x000063178d92b339 in ??? ()
#5  0x000063178d8d3b11 in ??? ()
#6  0x00007f8d0114c55a in ??? () at /usr/lib/libc.so.6
#7  0x00007f8d011c9a3c in ??? () at /usr/lib/libc.so.6

Thread 7 (Thread 0x7f8cf5a006c0 (LWP 74767) "Timer-Scheduler"):
#0  0x00007f8d01148ebe in ??? () at /usr/lib/libc.so.6
#1  0x00007f8d0114b750 in pthread_cond_wait () at /usr/lib/libc.so.6
#2  0x000063178d98f7fe in ??? ()
#3  0x000063178d9b3827 in ??? ()
#4  0x000063178d8ea0f8 in ??? ()
#5  0x000063178d9b3462 in ??? ()
#6  0x000063178d869adf in ??? ()
#7  0x0000000040bce082 in ??? ()
#8  0x00007f8d00678370 in ??? ()
#9  0x00007f8d00678468 in ??? ()
#10 0x00007f8d006782a0 in ??? ()
#11 0x0000000000000000 in ??? ()

Thread 6 (Thread 0x7f8cf5e006c0 (LWP 74766) "mono"):
#0  0x0000000040b7a43d in ??? ()
#1  0x00000000003e007d in ??? ()
#2  0x00007f8d005c17c0 in ??? ()
#3  0x00007f8cf7b442b0 in ??? ()
#4  0x0000000040bc0540 in ??? ()
#5  0x00007f8d00675a50 in ??? ()
#6  0x00007f8cf5dffb00 in ??? ()
#7  0x00007f8d00675be8 in ??? ()
#8  0x00007f8d006759d0 in ??? ()
#9  0x00007f8d00675aa0 in ??? ()
#10 0x00007f8d005c17c0 in ??? ()
#11 0x0000000000000000 in ??? ()

Thread 5 (Thread 0x7f8cf66006c0 (LWP 74757) "mono"):
#0  0x00007f8d01148ebe in ??? () at /usr/lib/libc.so.6
#1  0x00007f8d0114ba65 in pthread_cond_timedwait () at /usr/lib/libc.so.6
#2  0x000063178d98f7a0 in ??? ()
#3  0x000063178d999536 in ??? ()
#4  0x000063178d85e7e9 in ??? ()
#5  0x0000000040b2cd7d in ??? ()
#6  0x00007f8d0074b050 in ??? ()
#7  0x0000000000000001 in ??? ()
#8  0x00007f8d0074b438 in ??? ()
#9  0x0000000000000000 in ??? ()

Thread 4 (Thread 0x7f8cf76006c0 (LWP 74756) "mono"):
#0  0x00007f8d01148ebe in ??? () at /usr/lib/libc.so.6
#1  0x00007f8d0114b750 in pthread_cond_wait () at /usr/lib/libc.so.6
#2  0x000063178d98f7fe in ??? ()
#3  0x000063178d9b3827 in ??? ()
#4  0x000063178d8ea0f8 in ??? ()
#5  0x000063178d9b3462 in ??? ()
#6  0x000063178d869adf in ??? ()
#7  0x0000000040bce082 in ??? ()
#8  0x00007f8d0073e5f8 in ??? ()
#9  0x00007f8d006a0c00 in ??? ()
#10 0x00007f8d007b9588 in ??? ()
#11 0x0000000000000000 in ??? ()

Thread 3 (Thread 0x7f8cfd8006c0 (LWP 74755) "Finalizer"):
#0  0x00007f8d01148ebe in ??? () at /usr/lib/libc.so.6
#1  0x00007f8d01154470 in ??? () at /usr/lib/libc.so.6
#2  0x000063178d91f6a6 in ??? ()
#3  0x000063178d8d3b11 in ??? ()
#4  0x00007f8d0114c55a in ??? () at /usr/lib/libc.so.6
#5  0x00007f8d011c9a3c in ??? () at /usr/lib/libc.so.6

Thread 2 (Thread 0x7f8d002006c0 (LWP 74754) "SGen worker"):
#0  0x00007f8d01148ebe in ??? () at /usr/lib/libc.so.6
#1  0x00007f8d0114b750 in pthread_cond_wait () at /usr/lib/libc.so.6
#2  0x000063178d97b855 in ??? ()
#3  0x00007f8d0114c55a in ??? () at /usr/lib/libc.so.6
#4  0x00007f8d011c9a3c in ??? () at /usr/lib/libc.so.6

Thread 1 (Thread 0x7f8d010c0080 (LWP 74753) "mono"):
#0  0x00007f8d011b2ec7 in wait4 () at /usr/lib/libc.so.6
#1  0x000063178d71b1a6 in ??? ()
#2  0x000063178d6c4437 in ??? ()
#3  0x000063178d7098e5 in ??? ()
#4  0x0000000040bd67ef in ??? ()
#5  0x0000000000000008 in ??? ()
#6  0x0000000000000008 in ??? ()
#7  0x0000000000000180 in ??? ()
#8  0x0000000000000280 in ??? ()
#9  0x00000000000001e0 in ??? ()
#10 0x0000000000000000 in ??? ()
[Inferior 1 (process 74753) detached]

=================================================================
Basic Fault Address Reporting
=================================================================
Memory around native instruction pointer (0x40bd67ef):0x40bd67df  8b 85 b8 fe ff ff 48 03 c1 48 63 8d 48 fe ffff  ......H..Hc.H...
0x40bd67ef  89 08 48 63 85 78 fe ff ff ff c0 89 85 78 fe ff  ..Hc.x.......x..
0x40bd67ff  ff 48 63 85 48 ff ff ff 39 85 78 fe ff ff 0f 8c  .Hc.H...9.x.....
0x40bd680f  55 ff ff ff 49 8b c5 83 e0 04 83 f8 04 74 10 41  U...I........t.A

=================================================================
Managed Stacktrace:
=================================================================
at FoenixIDE.Display.Gpu:Gpu_Paint <0x00c5f>
at System.Windows.Forms.Control:OnPaint <0x0008f>
at System.Windows.Forms.Control:WmPaint <0x0019b>
at System.Windows.Forms.Control:WndProc <0x00253>
at System.Windows.Forms.ScrollableControl:WndProc <0x00033>
at System.Windows.Forms.ContainerControl:WndProc <0x00073>
at System.Windows.Forms.UserControl:WndProc <0x00083>
at ControlWindowTarget:OnMessage <0x0003c>
at ControlNativeWindow:WndProc <0x00052>
at System.Windows.Forms.NativeWindow:WndProc <0x0037b>
at <Module>:runtime_invoke_intptr_intptr_int_intptr_intptr <0x000a9>
at <unknown> <0xffffffff>
at System.Reflection.RuntimeMethodInfo:InternalInvoke <0x000ad>
at System.Reflection.RuntimeMethodInfo:Invoke <0x0010a>
at System.Reflection.MethodBase:Invoke <0x00047>
at System.Delegate:DynamicInvokeImpl <0x00271>
at System.MulticastDelegate:DynamicInvokeImpl <0x00049>
at System.Delegate:DynamicInvoke <0x00036>
at System.Windows.Forms.XplatUIDriverSupport:ExecutionCallback <0x0005a>
at System.Windows.Forms.XplatUIDriverSupport:ExecuteClientMessage <0x00083>
at System.Windows.Forms.XplatUIX11:GetMessage <0x04507>
at System.Windows.Forms.XplatUI:GetMessage <0x00064>
at System.Windows.Forms.Application:RunLoop <0x00aab>
at System.Windows.Forms.Application:Run <0x0007f>
at System.Windows.Forms.Application:Run <0x0004f>
at FoenixIDE.Program:Main <0x0014f>
at <Module>:runtime_invoke_void_object <0x00091>
=================================================================
fish: Job 1, 'mono FoenixIDE.exe' terminated by signal SIGABRT (Abort)

╭─dieter@elitebook in ~/Downloads/FoenixIDE as 🧙 took 2s
[⚡] ×

Unable to flash my FMX RevC4 with a new kernel

I tried to flash the latest kernel to my FMX RevC4 board but am now getting a black screen.

Problem 1: Selecting a kernel.hex in the uploader prevents me from checking the 'flash' checkbox. So I had to select a .bin file, then check it, then select the .hex file before flashing would take effect.

Problem 2: Stefanie's video says the kernel should be 512k but the kernel.hex shows up as nearly 4Mb. Does the provided kernel.hex in the IDE repo work on the real FMX board? If not, where is the kernel that came with my device?

Problem 3: It was unclear what destination address I should set when I perform a flash. The online docs say 38:0000 but Stefanie's video says to leave it as 00:0000. Which is correct?

After several attempts, I now get a black screen on boot. At one point, I was able to go back to the kernel found in the separate kernel repository but have not been able to do that again. Can you describe the process you use to flash your FMX board with the latest kernel? Did I overwrite something important in a different location or can I restore my board to a working state? Thanks.

File open error

There is a full path in gameformdesigner.cs in line 92, this should be a relative path like; this.CodeTextBox.DescriptionFile = @".\Resources\foenix-game-generator-syntax.xml"; also the resource file should have a property to be copied if newer so that it is included when running debugging.

incomprehensible behavior of Direct Page register?

Recently I played a little around passing arguments via stack and I found behaviour that embarrasses me. It is possible that root cause comes from my lack of experience, but bahvior is different between FoenixIDE and c256emu, so I decide to fill this issue.

All that I want was a trick with setting DirectPage register to current stack position and got values from stack using direct-page LDA commands (as LDA 10, LDA 8 etc). Below is heavily-annotated source of my sample program, that loads at $03:0000

.cpu "65816"			
.include "macros_inc.asm"

			* = $030000
		
			CLC					; clear the carry flag
			XCE					; move carry to emulation flag.
			setaxl
			
                        pea #$1234          ; first argument
			tsc                 ; pointer to first argument 
			inc a
			pha                 ; address of first pointer to stack
			pea #$4567          ; second argument
			pea #$89ab          ; third argument
			jsr test           
			
		
 
 test		phd                 ; presere Direct on stack / FoenixIDE: 0000 rdaum/c256emu: pointer
			tsc                 ; current stack position
			inc a               
			tcd                 ; stack position to direct register

			; D points to one past our return address, so we may now refer
			; to our inputs via direct page references.

			; at this moment stack on FoenixIDE looks like (c256emu is almost the same)
			; FEFF 12
			; FEFE 34 - first value
			; FEFD FE  
			; FEFC FE - stack pointer
			; FEFB 45
			; FEFA 67 - second value
			; FEF9 89
			; FEF8 AB - third value
			; FEF7 00
			; FEF6 13 - return addr 
			; FEF5 00
			; FEF4 00 - Direct Reg preserve ($fef4 on c256emu)
			; Direct Register = $FEF4
			; DBR             = $00
			
                                ; expect and got on rdaum/c256emu | GOT val on FoenixIDE:
                        lda 10     ; expect $1234 | GOT $1234                         
			lda 8       ; expect stack pointer (example $fef2) | GOT $fefe
			lda 6       ; expect $4567 | GOT $0013 - return pointer 
			lda 4       ; expect $89ab | GOT $0000 ??? 
			lda 2       ; expect return pointer (example $0012) | GOT $0013
			lda 0       ; expect Direct reg ($fef4) | GOT $0000 - but see below

					
			lda #$9988
			sta 10
			lda #$7766
			sta 8
			lda #$5544
			sta 6
			lda #$3322
			sta 4
			lda #$11aa
			sta 2
			lda #$bbcc
			sta 0

			; at this moment stack on FoenixIDE looks like (
                        ; c256emu was consistent with lda/sta sequence)
			; look at fefb, fefa, fef9, fef8 - 
			; FEFF 99
			; FEFE 88
			; FEFD 77
			; FEFC 66
			; FEFB 45 - should be 55 like in c256emu?
			; FEFA 67 - should be 44 ... ?
			; FEF9 89 - should be 33 ... ?
			; FEF8 AB - should be 22 ... ?
			; FEF7 11
			; FEF6 aa
			; FEF5 bb
			; FEF4 cc
			; Direct Register = $FEF4
			; DBR             = $00


                        lda 10              ; expect $9988 - ok
			lda 8               ; expect $7766 - ok
			lda 6               ; expect $5544 GOT $11aa in FoenixIDE
			lda 4               ; expect $3322 GOT $bbcc  ...
			lda 2               ; expect $11aa GOT $11aa  ...
			lda 0               ; expect $bbcc GOT $bbcc  ...
			
            brk

TAX, TAY, TSX and others should set N and Z flags

According to manual and available docs: http://www.6502.org/tutorials/65c816opcodes.html#6.10.1 TAX, TAY, TSX, TXA, TXY, TYA and TYX should set NZ flags (depending of X/M flags and direction of transfer).

Lack of that prevents my port of of816 Forth, fresh hex file here from working - after cursory correction of TAY behavior all problems were gone.

Unfortunately, I don't have a production-ready code at this moment, so no patch provided.

Discrepency on JSR/RTS handling

The emulator seems to be pushing the incorrect address to the stack on a JSR, compared to the hardware. JSR is supposed to push the address of the last byte of the JSR instruction. When RTS executes, it pulls the address off the stack and starts executing the next byte. That is, if the address $1234 was pushed by JSR, RTS will start executing the opcode at $1235.

It appear that RTS in the emulator is starting execution at the address pushed on the stack ($1234) in the example above. JSR seems to be pushing a consistent value, so they work together.

Most code should be fine with this, but there will be some programs that push their own return values to the stack and use RTS to jump to them. These will fail on the emulator.

I'm attaching sample code that shows the discrepancy between the hardware and the emulator. The hardware will print "X" and break to the monitor. The emulator will just break to the monitor.

By the way, I have not tested if this is an issue with JSL/RTL.

;;;
;;; Example of issue with JSR/RTS
;;;

.cpu "65816"

FK_PUTC             = $190018 ; Print a character to the currently selected channel

;
; Bank 0 Code Segment, including bootup and variables
;

* = $001000

START       CLC
            XCE

            REP #$30
            .al
            .xl

            LDA #<>PROC         ; Push PROC as a return address.
            PHA                 ; Execution should continue at PROC+1
            RTS

lock        NOP
            BRA lock

PROC        BRK                 ; Emulator will execute this BRK
            
            SEP #$20            ; Hardware will skip the BRK and start here
            .as
            LDA #'X'
            JSL FK_PUTC         ; ... and print an "X"

            BRK


* = $00FFFC 

VRESET      .word <>START

Uploader packet size should be readjusted lower for F256 family

For F256K and F256Jr modes, from Stefany:

when there is a transfer being done, the read and write packets needs to be smaller, because the internal memory to receive and send them packets are smaller. I believe that in bigger machine the Rx/Tx buffer is 8K, but in the F256x line it is only 2K... So some changes would required to support that.