X68000 IOCS & DOS documentation project.

[FedericoTech]

Hi everyone.

I'm fairly new with the X68000. I must say that I haven't even seen one for real. Only in the Internet and through emulators.

With some documentation I found here an there I managed to do some programs and I thought that the best services I can do for the community is to document the library in a way that anyone can understand because the info that is available is scarce and in Japanese.

This is a great endeavour. I have spent hundreds of hours researching the machine and doing small examples. You can find them in my github https://github.com/FedericoTech/X68KTutorials

Any help is welcome.

[kamiboy]

Cheers, you are doing gods work. These kinds of endeavors come into being and vanish off of the internet with slow regularity. A github is a good idea for posterity.

Had a quick look at the repository, and that is some useful stuff, especially the sound and music examples, I hope to make use of them some time.

I would say some crucial things that are missing, or that perhaps I couldn't quickly locate at s cursory glance, is stuff to do with the crt raster routines, which is crucial for development of game engine loops, and examples on how to use DMA memory transfers.

[FedericoTech]

Hi Kamiboy,

DMA doesn't have its own sample yet but it is in one called Sonic.

In that example I load the tiles of several characters, set the sprites and update the tiles with the three DMA modes (instead of rotating the tiles in the sprite, just because) and I use the vsync_disp to keep the count of frames.

I have another call Raster where I animate the Sonic sprite and I use the vsync_disp raster to draw it twice reusing the sprites in the same frame.

In RasterIm I load two full screen 8bit-deth images and I use the crtcras and vsync_disp rasters to update the scroll and the palette so that I can simulate the Sonic 2's slit screen.

FPCube is a 3d cube savescreen where I do fixed point arithmetic to calculate the vertices.

Backgrouds is not very appealing yet but demonstrates the use of "text" backgrounds.

RayCast. It's a Doom-like labyrinth. quite slow because it still uses floating point. I'm working on the fixed pint version.

Tetris68 is... Tetris. It doesn't use sprites nor graphic planes but only backgrounds.

I'm currently investigating Resident programs and multiprocessing. I managed to do that but I'm just looking for a clean way to exit the program without having to restart the computer xD.

[FedericoTech]

Hi,

I have been working in a demo on how to create a program that makes use of multi processing.
I have been battling with an issue for which the program would leave the session in an unstable state but not it's solved so soon I will publish a well documented demo.

[kroustibat]

Hello Frederico,

Amazing work !!! thanks for this. So wish i had enough time to dig into those examples....

[FedericoTech]

Hi, I wrote this article about programming resident programs in Human68k https://federicotech.wordpress.com/2023/12/16/x68000-programming-chapter-trs-programs/

[Edward]

Hi, Federico. Thanks for the effort.

[FedericoTech]

Hi there,

I've been researching how backgrounds work and I have been working on a script to convert assets into X68000 format so it makes easy to work with tiles.

Here is a taste:
 

You can find the source code of this demo at https://github.com/FedericoTech/X68KTutorials/tree/main/MarioKart
It's still in development though.

[kamiboy]

Jawsome, I had to make similar routines for my long abandoned game project for the X68000. A zip file of how far I got, which was far enough to have a sprite running around a custom level, is uploaded here somewhere long ago. I really should've uploaded it to github for posterity.

[FedericoTech]

Here is another demo I did some time ago:



It's a playable Tetris.

you can find the source code and executable at https://github.com/FedericoTech/X68KTutorials/tree/main/Tetris68

[FedericoTech]

I wanted to share another demo:



It's a 3D cube that moves across the screen. I use the drawing planes and scroll to do double buffering so that you don't see how the image draws each frame.

you can find the source code and the executable at https://github.com/FedericoTech/X68KTutorials/tree/main/FPCube

[kamiboy]

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?

[hitchhikr]

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:

Code Select Expand

    ; 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


[kamiboy]

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.

[kamiboy]

Somewhere around here you mentioned that you have a patched version of the lydux GCC that fixes memory boundry issue, your own version of newlib with fixed and perhaps other updates to the 2012 lydux toolchain hosted here on the forums.

Could I trouble you to share these here, so I can just copy them over my lydux toolchain files and have an updated toolchain?

[neko68k]

It might be a bit of work to get your old stuff moved over but there is a new way out of Japan to do all the compiling and such that maintains support with old libraries. It's similar-ish to how we did it with the DooM port but way more refined. My understanding is it's possible to hook this up to gdb and probably do whatever you want in vscode or similar.

FWIW I've done a whole lot of remote debugging over serial with db.x and it's very doable but it's not the most fun thing in world.

xdev68k
gdbserver-x68k

[kamiboy]

Apropos newlib. In my attempts to try and build the updated Lydux toolchain for Windows I found out I had found and made some simple fixes for libdos here: https://nfggames.com/forum2/index.php?topic=6002.0

A file with updated libdos files are attached in that thread. You may want to take gander and perhaps include them in your version  Federico.