nfg.forums

But my dev setup uses an XM6 emulator to test my latest code changes.

It is orders of magnitude faster than having to do with the actual X68000.

And I was hoping there was a way to debug X68000 projects using modern debugging techniques that can interrupt and step through code, inspect elements etc.

Well, I suppose I already knew it was too much to ask for.

You can still use the serial port of the X68000 to connect to a PC via a serial-to-usb cable (like those: https://www.amazon.fr/Convertisseur-DB25-Adaptateur-RS232-C%C3%A2ble-communiquer-Programmation/dp/B07KYSQBKX) and use a terminal program on the PC (be sure to set the flow control to 'none').

To send data from the X68000 via the serial port, use something like this:

    ; stop bits = 1 bit
    ; parity = none
    ; bit length = 8
    ; baud rate = 38400
    move.w  #%0100110010001001,d1
    moveq   #_SET232C,d0
    trap    #15
    ; send a byte
    move.b  #'O',d1
    moveq   #_OUT232C,d0
    trap    #15


A question regarding debugging. Back about 12 years ago when Lydux released his X68000 dev tools I started to code a game project. I made great progress after a few months of intense work, but somehow lost interest and abandoned it.

Recently I've been going back to it to try and remember how my WIP game engine even worked, fix bugs and perhaps even continue the project.

One thing I remember really missing back in the day was the ability to do proper debugging. I know an X68000 version of GDB version was part of the Lydux dev tools, but it was alas rather useless.

I don't really have any experience using GDB, and it has been a while since I did that sort of debugging, but if I remember right the X68000 has a funky support for debugging.

I seem to recall reading that you could boot an X68000 up in a certain mode, then connect it via some sort of cable (serial I think) to another X68000, it could function as a GDB monitor for code running on the other machine.

Now, for this to be useful one would need to be able connect two X68000 emulators to eachother and boot one in GDB monitor mode.

Or perhaps there is much smarter way of doing debugging that I am not familiar with. With large projects using printf() debugging quickly becomes infeasible, specially on the X68000 when one has game graphics on the screen at the same time.

Have you gotten far enough with your projects to come up with a neat debugging solution yet?

@MAZter

Don't you DL and play Wolf3d on FMT.
f**k you.

yes please, feel free

Thanks BBC, he released  new version for FM Towns Marty in March, looks great!

Quote from: incrediblehark on August 04, 2024, 11:45:44 AMWhat is your setup? does your X68k have 2MB internal before installing the etarikashikoshi board? Is your switch.x set up correctly?

To all: I apologize for the slow progress on my v3 image, it is still being worked on but my free time this summer has been sparse. I hope it will be worth the wait!

Seriously though, take your time! We are all very appreciative of the effort you put into these!

Quote from: DanHero on August 05, 2024, 09:28:33 PMHi, I tried both, so I have no Idea at this point

My setup is X68000 Super 10 MB ram thanks to the Etarikashikoshi on BlueSCSi v2

Have you updated your BlueSCSI V2 with the latest firmware?

https://github.com/BlueSCSI/BlueSCSI-v2/releases/tag/v2024.05.21

Is your BlueSCSI V2 internal or external?

Check for errors in the Log file in your memory, it updates at every reboot.

In the switch.x settings you have set:
BOOT: STD
SCSI_ID: 7

Have you replaced the battery of your X68000 Super?

You can reset the SRAM to default values on X68000 Super, by holding down the CLR key, immediately after turning on the computer, when the confirmation message appears press Y.

Remove your Etarikashikoshi and try without, the game will boot up to character selection, it won't go further with only 2MB, but you can try the FM Sound.

Hi, I tried both, so I have no Idea at this point

My setup is X68000 Super 10 MB ram thanks to the Etarikashikoshi on BlueSCSi v2

SOLVED

I found a guy on facebook that kindly pointed me to the solution. On the PCB there is the upper-right zone with some welds; pressing the first two solved the problem. Probably a weld has deteriorated over the years, accentuated by the stresses caused by the dirt I cleaned during the first analysis. I will have to make a new one at this point.