Hello, Guest the thread was called953 times and contains 8 replays

last post from mega65 at the

6502 Assembler debugging - help needed (bored at home ?)

  • Hi everybody,

    while most of us are atm working from/at home, we (The MEGA65 team) is using this time to work even more on the MEGA65.

    (So while this COVID-19 crisis is a disadvantage for most, it does support our project, we are running on full steam !!!)

    OK, now to the main point, why we have created this thread:

    We are looking for some 6502/6510 assembler geeks here in forum64.

    We have some bugs in our Hypervisor which is based on 6502 assembly code.

    Paul will provide some further information, and of course we would support as much as possibl.

    we just don't have the time atm to tackle this by ourselves and we thought, that this might be a nice task, to work on from home.

    Apart from this, we have some big news coming up soon.

  • Paul will give more details soon.

  • Howdy folks,

    the particular task is to track down some problems we encounter from time to time with the file handle and related code for the FAT 32 file system. I suspect that there is some memory corruption happening somewhere. I could investigate it myself, but we will all get our MEGA65's sooner if I am able to concentrate on the VHDL stuff that is harder to find people to work one -- hence the reason for the call out.

    What I have done is modify monitor_load so that it can be used to query the hypervisor file handle tables in memory. At the moment we don't have a tool for debugging this in the emulator or in a stand-alone hypervisor simulator. The latter would be great if it could be done, as we could then run a pile of automated tests on the hypervisor, e.g., particular sequences of opening, closing and reading files etc, and verifying that the file handle table is exactly as expected after each action. If created, such a program should be a simple portable POSIX C program, or perhaps python would be ok as well, so that we can easily incorporate it into the existing build system.

    If anyone has any questions, please shoot away!



  • Hello,

    Sure. It is in https://github.com/mega65/mega65-core

    more specifically, the Hypervisor programme, which is built from src/hyppo via:

    make bin/HICKUP.M65

    The hypervisor implements a bunch of calls in src/hyppo/dos.asm, e.g., trap_dos_opendir that are listed in dos_and_process_trap_table. These work on a set of four file descriptor structures in the dos_file_descriptors structure which is declared in main.asm. Just above its declaration, there is a description of what each byte offset in each of the 16 byte long descriptors does.

    It is best to track the unstable branch for examining this, as I have created some helpful tools on that branch, in particular monitor_load with the -X option, which shows a report of the current state of the file descriptors. This requires a change in the unstable branch of the VHDL if running against real hardware, so that the hypervisor memory is in the address space at all times (normally the CS line for it is disabled when not in hypervisor mode).

    As I mentioned in an earlier message, it would be great to have a 4510 simulator that could run the HICKUP.M65 file, and probe it with a bunch of simulated calls, and map the changes made to the hypervisor memory by each, so that we can have automatic regression and comformance testing of the hypervisor. It doesnt need to be a particularly fast simulator. In the simplest form, the simulator would be given memory setup information, the HICKUP.M65 file name (or better, the source files, to symbolically do the emulation, with scope for better debug output, but that might be too hard), and the trap to call. It would then simulate the CPU until the hypervisor returned from the call, and report the changes to hypervisor memory.

    If you are interested in helping, let me know, and I would be willing to help you tackle this.