Learning X68000 programming

[ces]

Hi,

I've been a MSX2 user and developer for years, and I've recently become interested in the X68000, because it seems it has most of the features I missed on the MSX2. However, after some searches, all the programming docs I found are in Japanese (I don't understand Japanese, I just understand English and Spanish).

This seems to be the most complete X68000 forum on the Internet, so I hope I find here answers to these questions:

1- Is there any (complete and 100% functional) emulator that runs on Linux or other Unices?

2- Are there any resources for learning X68000 programming if you don't understand Japanese?

Thanks a lot!!

[virux]

About the docs, this is an extremly important question!

There is a Technical documentation translation project at

http://mijet.eludevisibility.org/X68000%20Technical%20Documents/English%20X68k%20Docs.html

although it's far from complete..

some useful info can be found at

http://datacrystal.romhacking.net/wiki/Sharp_X68000
and
http://www.jcec.co.uk/X68kinfo.html

There is a thread by kamiboy on this forum:
http://nfggames.com/forum2/index.php?topic=5115.0
where he wrote on his findings on the topic - it was an interesting read, but sadly it was pretty rude stopped by a moderator.

kamiboy, is there any news since then? maybe you've already built some early alpha of your game?

All the docs above are pretty much fragmentary and actually I would LOVE to have some links to actual japanese documentation (and then just use google translate)
All I could found that is more or less useful in japanese, is:

X-BASIC reference:
http://ww3.enjoy.ne.jp/~zoomark/ip/xb/xb_frm.html

Human68k commands reference:
http://www.geocities.co.jp/SiliconValley3115/Human68k/Human68k.html

It seems like there is plenty of X68000 programming-releated books (http://retropc.net/x68000/book/x68book.htm) The only problem they're in japanese and it would be nice to have them in electronic form to be able to google translate them

Anyone have some links to share?
Would be great to see a wiki page with programming-releated links some day

[Magic Knight]

I have a copy of "X680x0 Game Programming by GCC" (GCCによるX680x0ゲームプログラミング） if that would be of any use. The disks are missing though.

[virux]

Can you upload it somewhere and post a link?

[ces]

I didn't think in using Google Translate! It's a good idea, I guess the online docs you posted can be translated in English (more or less, I suppose).

Btw, what emulator would you recommend for programming and for using the user interface, and other tools like painting or sprite design? (I mean the main interest won't be playing games). Please consider that I don't know Japanese, so I don't know if there's a working emulator with its menus and docs in English.

Also, is there any emulator which implemented the video digitizer in some way? (the X68000 had a video input and you could digitize video with it)

[virux]

ces, read kamiboy's topic, he mentions using the debug features of the XM6 Pro emulator
If you need the X68000 tools, they are mentioned in same thread - there is some in an HDD image v3 by eidis

[ces]

It's sad that none of the actively developed emus have the source code available. I think the source code would be greatly useful, both for learning how the machine works, and for adding still unsupported features. Both the enhancements of xm6 pro (debugger) and the xm6i (port to wxWidgets) are closed source.

[neko68k]

This is _the_ book.  There is no other that I'd recommend except Outside X68000, which is more hardware oriented(signal timing etc). A pre-built toolchain for windows can be found here along with some hardware data sheets. All the instructions for building your own toolchain(linux etc) and the sources and things and what-not are available here.

My suggestion if you can't read Japanese is to use a quality OCR program like OmniPage to convert the images to text then use Google Translate to get the gist of things. Though Inside X68000 has enough diagrams that it should be fairly clear.

[ces]

Sorry if this is a dumb question, but what's the difference between the "Inside X68000" and "Outside X68000" books?

[NFG]

One deals with code and programming, the other with the hardware, circuits etc.  Hence inside and outside. 

[Magic Knight]

I don't have time to scan this GCC book, if anyone wants it it's 1000 yen.

Those scans of the Inside X68000, was that my book?

[lydux]

I don't have time to scan this GCC book, if anyone wants it it's 1000 yen.

Those scans of the Inside X68000, was that my book?

No, I guess it was a scan found on a old private torrent tracker. The only thing I've done from your books are all Outside X68000 schematics. The book itself is useless (most contents are presentations of various addons boards).
About the GCC book, I guess it talk about the old x680x0 gcc port ? If that's so, it's really outdated.

Again, THE book to read is still "Inside X68000". With few adaptations, all demo codes can be ported to the newer toolchain.

Unfortunatly, yes. We lack of good documentation and there is not so much people interested into x68000 programming. Help welcome ! 

[ces]

Is there detailed documentation on how to access the video digitizer and video overlay? Is it possible to digitize video frames with XBASIC? (In the MSX2 you could digitize video with MSX-BASIC, and also for superimposing graphics over video). Anyway, I'm more interested in knowing how to do it with assembly or C rather than BASIC.

[lydux]

These are no "detailed" documentation for the whole system at all... And absolutly nothing about frame grabbing or superimposition.
I guess you first need the image unit (CZ-6VT1) : http://gamesx.com/wiki/doku.php?id=x68000:cz-6vt1_-_color_image_unit

This is a rare item, and we know almost nothing about it. It seems being able to perform basic image processing, and acting as a video titler. The result can be send back to the x68k.

Next are just assumptions :
According to the x68000 XVI schematics, I can see 4 buffers on the image unit port :
Image unit --> Buffers --> VRAM
Those buffers are enabled via a special CTRC register (address 0xe80481). Writing a "1" the bit 0 of this register will enable the capture.
Then I guess you'll have to read or write the VRAM to perform capture or superimposition.

How would you do it on MSX ?

There is also a write only 5 bits register for controlling the behavior of the device attached to the image unit port. It's done via the system port controller (address 0xe8e005). Any 5 bits value written here will be sent to the device. Various values behavior are dependent on the device attached, so I can't tell more...


So before coding, do you own such device ? 

[ces]

First of all, is the digitizer hardware located in the X68000 or in the "Color Image Unit" device? The X68000 has a NTSC video input... what's that analog input for? If the digitizer isn't located inside the X68000, I'd find it absurd to have an NTSC input.

Second, no I don't own X68000 hardware, but if its video digitizer/superimposer programming details can be known, I'd be happy to implement that in an existing open source emulator. Perhaps many people won't find it a useful feature, but some of us enjoy this kind of geek subjects :-) For me, video digitizing has always been one of the coolest things you can do with a computer.

Regarding your question on how would you do it on an MSX2, I had an NMS8280 (well, and still have it). In BASIC you could configure the digitizer and superimposer with SET VIDEO. Then, for grabbing frames, you used COPY SCREEN. In assembler it was also very easy, it was done through some VDP registers (it is well documented in the MSX2 technical reference book).

Back to the X68000, do you know of several applications that accessed the digitizer? Or there was only one? If there was more than one, there must be some paragraph inside those Japanese books explaining what values you need to write into some I/O ports for grabbing a frame, or for enabling superimpose of graphics on top of the NTSC video input.

The key question here is where was the digitizer and the superimposer: In the X68000 or in the external device. Also, even if the programming details aren't known, maybe it's possible to reverse-engineer it by looking for I/O reads and writes while you use the application for digitizing.

[ces]

Just a quick add-on: Wikipedia says the X68000 has NTSC I/O. But looked at some pictures and I cannot find any NTSC input (nor output). So maybe the NTSC I/O is only in the Color Image Unit.

[parodius]

There's also the CZ-6VS1 :
http://page10.auctions.yahoo.co.jp/jp/auction/m113376614

[lydux]

There is nothing inside the x68000 for digitizing video and no NTSC analog input as well.
The only thing you have is a port named "Image in" for the image color unit.

Regarding your question on how would you do it on an MSX2, I had an NMS8280 (well, and still have it). In BASIC you could configure the digitizer and superimposer with SET VIDEO. Then, for grabbing frames, you used COPY SCREEN. In assembler it was also very easy, it was done through some VDP registers (it is well documented in the MSX2 technical reference book).

Interesting piece of hardware ! The MSX world is big, and I know very few on it (just the base hardware). So, can you point me to some piece of assembler code that perform superimposition or frame grabbing ? Just want to see the idea... It should be same for the x68000.

Back to the X68000, do you know of several applications that accessed the digitizer? Or there was only one? If there was more than one, there must be some paragraph inside those Japanese books explaining what values you need to write into some I/O ports for grabbing a frame, or for enabling superimpose of graphics on top of the NTSC video input.

Unfortunatly no. I've tried to find software reference to this "CZ-6VT1" in order to disassemble it, but with no luck yet.
BIOS and DOS function calls have nothing dealing with the "image in" port. So I guess the CZ-6VT1 comes with a driver or demo disk.
I'll check with "Outside X68000" book later.

As for a linux emulator, someone recently published the source code of px68k which is a port of Keropi for Android. I've modified it in order to get it working on linux for my personnal use. There is no UI, is sometimes unaccurate but maybe it could help you ?

[ces]

There's also the CZ-6VS1 :
http://page10.auctions.yahoo.co.jp/jp/auction/m113376614

What's the difference between the two devices? Btw, those floppies in the picture... what will be their content? If it was possible to get their content...

Does anybody keep a copy of the floppies that shipped with the Color Image Unit? And the manual?

Regarding lydux reply:
Yes, it seems obvious that both the digitizer and superimposer are in the Color Image Unit, and grabbed frames are sent to the X68000 via the digital "image in" port. So the only way for doing video seems to be with such device. Btw, don't any of the painting applications (such as Canvas Pro 68K) have direct access to the digitizer? One of the most famous MSX2 paint apps was VideoGraphics, and it allowed you to not only paint but also digitize video and superimpose graphics over video (only in models with video hardware, of course).

Regarding how you would do it with assembler on a MSX2, I've the details at home, I can tell you later. But I don't think the X68000 will be operated in the same way, because the digitizer is outside of the computer, so I believe it will need some more coding. On the MSX2 it was just a couple of I/O port writes, IIRC.

[ces]

Interesting piece of hardware ! The MSX world is big, and I know very few on it (just the base hardware). So, can you point me to some piece of assembler code that perform superimposition or frame grabbing ? Just want to see the idea... It should be same for the x68000.

As I said, I tend to believe it will be more complex on the X68000 because the video hardware is external, but the way of doing this on the MSX2 was as follows:

1- Set the proper video synchronization. Initially it's set to "computer", but you've to change it to "digitize/superimpose", which is accomplished with either the SET VIDEO command in BASIC, or setting to 0 the S1 bit of the #9 VDP register, and setting to 1 the S2 bit of the same #9 register.

2- I think you need to set to 1 the TP bit of the #8 VDP register, but I'm not sure of that (this is for choosing if you want to superimpose, or just digitize: if superimpose is enabled, all black pixels are displayed as the analog input video signal. It's possible to have superimposition enabled while you're digitizing, although most of the times you wished to do either superimpose or digitize, but not both at the same time.

3- Start the digitizer. This is done with the COPY SCREEN command in BASIC, while on assembler you need to set to 1 the DG bit of the #0 VDP register. When you do that, a new digitized frame is sent to the framebuffer on each vsync retrace. When you set such bit back to 0, you've the last grabbed frame in the framebuffer. I believe you couldn't access the framebuffer while DG=1, for obvious reasons, but I'm not sure.

4- When you finish, set the video synchronization mode back to "computer", set superimpose off in case you enabled it, and the digitizer/superimposer gets disabled (but you can of course use the frames you grabbed, as they're now just graphics).

Also remember that the MSX2 was limited to 256 colors as 3 bits green, 3 bits red, and 2 bits blue (so 3+3+2 without palette, except on 16 color mode, where a palette was available).

This is just a very basic explanation from what I remember, but it's been a long time since I used my NMS8280, so maybe there're unaccuracies in my explanation.

The NMS8280 also has analog controls for adjusting the superimpose mix, making the graphics transparent over video (with a varying degree of transparency), and also for controlling the brightness of the graphics layer. Such analog controls were just analog... you couldn't modify them programmatically.

[lydux]

I don't think it's more complex. Being internal or external means nothing. The "image in" port is directly wired to the VRAM data bus (16 bits), plus 5 bits to the main cpu data bus. It also use one of the CRTC clock, so is already synchronized with it. Once hooked to the x68000, the CZ-6VT1 is a part of the machine.

Also remember that the MSX2 was limited to 256 colors as 3 bits green, 3 bits red, and 2 bits blue (so 3+3+2 without palette, except on 16 color mode, where a palette was available).

...

The NMS8280 also has analog controls for adjusting the superimpose mix, making the graphics transparent over video (with a varying degree of transparency), and also for controlling the brightness of the graphics layer. Such analog controls were just analog... you couldn't modify them programmatically.

It remembers me that we have multiple resolution, layers and colors mode (up to 16bits = 65536 colors). The 5 bits I/O port I told you earlier is probably for this purpose.

3- Start the digitizer. This is done with the COPY SCREEN command in BASIC, while on assembler you need to set to 1 the DG bit of the #0 VDP register. When you do that, a new digitized frame is sent to the framebuffer on each vsync retrace. When you set such bit back to 0, you've the last grabbed frame in the framebuffer. I believe you couldn't access the framebuffer while DG=1, for obvious reasons, but I'm not sure.

Ok, this is what I expected. I'm pretty sure it's the same system here, but unlike MSX, the X68000 has dual port VRAM. You can still access the framebuffer while it's in use by the color unit or drawing. (It's slow, but possible and why you can't on MSX).
In fact, our CRTC register 0xe80481 bit 0 (VI) just act like your VDP's DG bit.
So operation might be something like this :
- Setting the digitizer resolution/color via the I/O port (0xe8e005) according to the current or wanted GFX mode.
- Set the CRTC VI bit to 1 (0xe80481).
- Wait for a VBLANK period. (Or not ! You can still do thing during HSYNC for superimpose).
- A full frame is available into the framebuffer. (Probably GVRAM)
- Set the CRTC VI bit to 0 once you're done.


I don't see any other way of using this stuff.

[ces]

As for a linux emulator, someone recently published the source code of px68k which is a port of Keropi for Android. I've modified it in order to get it working on linux for my personnal use. There is no UI, is sometimes unaccurate but maybe it could help you ?

How does it compare to XM6 2.05 in terms of completeness? The problem with the XM6 source code is that it's Windows-only, and with comments in Japanese. Is px68k able to run the same software as XM6? If affirmative, I'd prefer px68k because Windows isn't my main OS. Does px68k lack the emulation of any chip/component which is correctly emulated on XM6?

About your comments for digitizing, maybe it's that way, but the only way of being sure would be to get a tool that can use the digitizer, and trace it.

[ces]

In fact, our CRTC register 0xe80481 bit 0 (VI) just act like your VDP's DG bit.
So operation might be something like this :
- Setting the digitizer resolution/color via the I/O port (0xe8e005) according to the current or wanted GFX mode.
- Set the CRTC VI bit to 1 (0xe80481).
- Wait for a VBLANK period. (Or not ! You can still do thing during HSYNC for superimpose).
- A full frame is available into the framebuffer. (Probably GVRAM)
- Set the CRTC VI bit to 0 once you're done.


I don't see any other way of using this stuff.

Ok, I found demos with source (in assembler) for digitizing video with the Color Image Unit. I think the original floppies from Sharp are not here because everything seems to be personal work of some users, but there're so many files that I'm not sure if the original floppies and docs will be somewhere. Here it is (look for the files called IMCAP: they're the image capture source code). Also, the IMGIN file shows how to do it with X-BASIC. From that code, do you believe the Image Unit came with drivers? Or the hardware was accessed directly? I believe the later, I don't think this source code needs any driver to work, but I'm new to X68000, so I don't know if I'm missing something:

http://most.bigmoney.biz/g0org/x68tools/hardware/image_unit/

PS: If you go up in that dir hierarchy, you'll see it has code and utils for almost every X68000 gadget (including the 24bit truecolor option, although I didn't find sample code for using the 24bit color mode...) If I had to dig into this, I really need an automated Japanese translator: A program that automatically translates files when I open them. Otherwise, I'm lost...

[NFG]

I lost my color image unit in the floods, but I still have the manual for some reason.  Does anyone want to see it?  My scanner's in Japan, but I'll see what I can do.

[NFG]

Well I scanned it anyway!

http://nfggames.com/x68000/   

^ there's a new folder, documentation.  Inside there is the PDF, loaded with what I hope is useful info.

[ces]

Well I scanned it anyway!

http://nfggames.com/x68000/   

^ there's a new folder, documentation.  Inside there is the PDF, loaded with what I hope is useful info.

Great!! I'll download it when I arrive at my computer site!

Btw, the files IMAGE.FNC and BASIC.CNF mentioned in the manual, are the same files that you can find in the standard C Pro compiler and standard BASIC installation, or are they special versions?

Also, do you remember what was the content of the floppy discs? Just demos? Or were they necessary for programming and/or for using the unit?

Thanks a lot, I didn't translate it yet, but took a look at the drawings and at the imgSample.BAS program, and it seems very easy to use!!

Thanks!!

[lydux]

Great Lawrence ! Trank you. This manual contains all the necessary elements to program it.
With the link found by ces with all these tools, it becames clear to me how it works.

Btw, the files IMAGE.FNC and BASIC.CNF mentioned in the manual, are the same files that you can find in the standard C Pro compiler and standard BASIC installation, or are they special versions?

Just disassembled IMAGE.FNC from C Compiler package, it contains all basic functions prefixed with "img_" the manual is refering to.

On assembler/C side, it's pretty much what I thought. The various value that can be written to I/O port 0xe8e005 are describe on page 26 of the manual and the digitizer start when setting the bit 0 at 0xe80481. The resulting captured frame is available in GVRAM, depending on the color mode selected.
You also need to set the TV output control mode. This can be done via a BIOS function call.

Code from IMCAP.s :

Code Select Expand


IOCS _G_CLR_ON | Clear GVRAM

move.b #0x04, 0xe88e005 | Enter manual configuration mode
move.b #0x08, 0xe88e005 | Reset image
move.b #0x10, 0xe88e005 | ?
move.b #0x00, 0xe88e005 | 65536 colors mode
move.b #0xff, 0xe88e005 | Exit configuration mode

move.l #0x1f, d1 | Normal contrast and superimpose mode
IOCS _TVCTRL | BIOS functions for TV Control settings (d1=mode, refers to iocscall.txt for possible values)

move.w #0x0001, 0xe80481 | Set VI bit in CRTC = start capture


Next, the program wait for a VBLANK period before doing stuff, the frame is in the GVRAM starting at 0xc00000.

[ces]

Well, this is great! I'm still not sure how superimpose works, but frame grabbing is very easy, and I think all the necessary docs for understanding the Color Image Unit are now available!

In my search for more info, I found that the TS-6BGA graphics accelerator is a Cirrus Logic GD-5434. In theory it had 2D acceleration for bitblt operations. Was this board popular? Are there any applications capable of using it? Do you need to add drivers to the OS?

If it was popular, do you have any idea if people programmed it directly in low-level, or through some API? The Cirrus Logic data sheet is available, so low-level would be possible, but I don't know how people used to do it.

And how does it work? I see the video output from the X68000 is plugged as input into the TS-6BGA. Does it mean that this board just adds an extra graphics layer on top of the standard layers? If affirmative, it would be quite unusual: the standard X68000 graphics would be the background, and the new extra layer would be the foreground... it's quite unusual, I don't think it would work that way...

[lydux]

It can clearly be used for overlaying graphic. But I think this board exists for another reason which is historical : during the lifetime of the x68000, there was another computer on japanese market, the PC98 and it seems they were always in search for compatibility between the two computer.
So, some boards were developped. For example, the "Concerto X68K" which embed a NEC V30 cpu, 512KB RAM and PC98 compatible glue logic. It can run true MS-DOS on a x68000.
So, what better compagnion to this board could it be than a true Cirrus Logic VGA+PCM sound board ?

Anyway, what I'm sure of, it's not a common board...

[ces]

It can clearly be used for overlaying graphic. But I think this board exists for another reason which is historical : during the lifetime of the x68000, there was another computer on japanese market, the PC98 and it seems they were always in search for compatibility between the two computer.
So, some boards were developped. For example, the "Concerto X68K" which embed a NEC V30 cpu, 512KB RAM and PC98 compatible glue logic. It can run true MS-DOS on a x68000.
So, what better compagnion to this board could it be than a true Cirrus Logic VGA+PCM sound board ?

Anyway, what I'm sure of, it's not a common board...

Ok, understood. Was there any other board with 2D acceleration? (I mean even if it was an amateur project, because I've seen it was quite popular to build your own hardware enhancements).

The X68000 hardware is great for sprite-based arcades, but some 2D acceleration like the Cirrus would be nice for other graphical uses, and moreover this makes the CPU free for doing other stuff while the gfx is doing its tasks...

So, was this TS-6BGA the only gfx acceleration, or did anybody make another attempt?