My new project is up!

[mrkotfw]

Looking at the bottom of the Saturn mainboard, the link port's pinout is

    Vcc

Midi RxD

    Midi TxD

Master TxD

    Master RxD

Master SCK

    GND

Slave TxD

    Slave RxD

Slave SCK

    GND

I just soldered wires directly to the corresponding TxD/RxD/SCK pins of a DLP-2232M module. Unfortunately the FT2232 IC uses incompatible pinouts in asynchronous and synchronous serial modes, so you have to decide which one you want to use on channel A. I used synchronous mode because of the faster transfer speed (~1.2Mbit/s vs. ~224Kbit/s), but async is a lot easier to work with.

I'm looking at the data sheet and TXD and RXD (can't find SCK. Is that some clock signal?). TXD and RXD correspond to pin 40 and 39, respectively for channel A. But the description states that it's asynchronous transfer.

But those pin names are for 232 UART mode? I'm unsure on whether I need to change the operating mode.



Also in your pinout of the bottom of the Saturn mainboard, is VCC pin 1, Midi RxD pin 2, and so on?

 

[mrkotfw]

"Enhanced Asynchronous and Synchronous Bit-Bang modes, MPSSE, and MCU Host Bus Emulation modes are enabled using driver commands" -- and this is why you call ftdi_set_bitmode(). That makes sense. So it's still pin 40 and 39, but they're called D0 and D1, respectively for the synchronous bit-bang mode.

OK, so you're using MPSSE mode which is only allowed on ch. A. Not so much the synchronous bit-bang mode (well, MPSSE is synchronous).

This is giving me more information:

http://www.ftdichip.com/Support/Documents/AppNotes/AN_135_MPSSE_Basics.pdf

I'm still unsure how strobe signals work.

 

[antime]

Also in your pinout of the bottom of the Saturn mainboard, is VCC pin 1, Midi RxD pin 2, and so on?

Depends on which direction you're counting from I guess, but yeah.

[attachment=7734:sserial.jpg]

OK, so you're using MPSSE mode which is only allowed on ch. A. Not so much the synchronous bit-bang mode (well, MPSSE is synchronous).

Yes, I don't think the bit-bang modes can be applied. Do keep in mind that there's no particular reason to use the FTDI chips except that there's readily available modules you can use. For example, if you can be bothered to write the software it shouldn't be too hard to find a suitable microcontroller with both USB and a few configurable serial ports (ideally you'd want two async/sync for the SH2s and one plain UART for the SCSP serial port).

 

[mrkotfw]

Depends on which direction you're counting from I guess, but yeah.

[attachment=7734:sserial.jpg]

Yes, I don't think the bit-bang modes can be applied. Do keep in mind that there's no particular reason to use the FTDI chips except that there's readily available modules you can use. For example, if you can be bothered to write the software it shouldn't be too hard to find a suitable microcontroller with both USB and a few configurable serial ports (ideally you'd want two async/sync for the SH2s and one plain UART for the SCSP serial port).

Thanks for the picture. That greatly helps. So I'll be focusing on just using the Master CPU.

Which pin corresponds to the SCK pin? The SCSP UART? UART for the SCSP serial port? Would that be specifically for the Midi pins?

I have an Arduino that I can use, but seeing as you already have this, I'm going to go ahead with this anyway. It's only $35 USD. That and I hate the development environment in the Arduino.

I'm going through the docs and it somewhat makes sense, but what do these values represent?

SendBuf[0] = TCK_DIVISOR;

SendBuf[1] = 0x05;

SendBuf[2] = 0x00;

SendBuf[3] = SET_BITS_LOW;

SendBuf[4] = 0x08;

SendBuf[5] = 0x0b;

 

[antime]

Which pin corresponds to the SCK pin? The SCSP UART? UART for the SCSP serial port? Would that be specifically for the Midi pins?

The SCK pin is the synchronous serial port clock pin. The MIDI transmit/receive pins are connected to the SCSP serial port (AFAIK uses the standard 31250 bps data rate). In synchronous mode, the SH2 serial port is essentially an SPI port without a chip select line. To get high transfer speeds you must use an external clock.

That and I hate the development environment in the Arduino.

You can just use AVR Studio or any other C environment, and just take advantage of the Arduino bootloader for uploading your code. I've used Arduino Mini boards for a couple projects but I've never used the Arduino environment.

I'm going through the docs and it somewhat makes sense, but what do these values represent?

The TCK_DIVISOR command sets the serial port clock rate. SET_BITS_LOW sets the direction and value of the first 8 pins of the port. This document describes the various commands. Please note that libftdi uses different names than FTDI's D2XX driver for some things. There are also some bugs in my code where I've used a macro with the wrong name but right value which can be a bit misleading when reading the code.

I'm still unsure how strobe signals work.

Strobes are control lines for an interface. They're used to tell connected hardware things like when they should read or write the data lines, who is driving the lines and so on.

 

[Chilly Willy]

I have a question about where the Saturn should compile for. In the linker scripts I've seen, they start the text section at $6004000, with the Master SH2 stack at the same address going down to $6002000 where the Slave SH2 stack is. However, in the docs I was reading through today, the Slave SH2 stack for CDs is at $6001000 down to $6000D00, the Master SH2 stack is from $6002000 down to $6001000, and the starting point for the text section should be $6002000. Is the discrepency to do with ARP loading instead of CD loading or something? Should we make two different linker scripts for CDs and otherwise?

 

[antime]

The boot rom will load the CD IP block to 0x6002000, the first read address can be any workram-H location above 0x6002000+IP SIZE. When loading via cartridge, any address over 0x6002000 is fine, 0x6004000/0x6010000 are just conventions. 0x6002000/0x60010000 are also just the default stack pointers, they can be configured either in the IP or during runtime.

Just use some default values, it's easy enough to customize the linker script for your particular needs. You could also define some overlay sections for loading code into locked SH2 cache.

 

[Chilly Willy]

The boot rom will load the CD IP block to 0x6002000, the first read address can be any workram-H location above 0x6002000+IP SIZE. When loading via cartridge, any address over 0x6002000 is fine, 0x6004000/0x6010000 are just conventions. 0x6002000/0x60010000 are also just the default stack pointers, they can be configured either in the IP or during runtime.

Just use some default values, it's easy enough to customize the linker script for your particular needs. You could also define some overlay sections for loading code into locked SH2 cache.

Okay, just checking that it wasn't the defaults changed and I didn't see it in the docs. I suppose if your app needed even more stack space, you might change the stack and start addresses even higher.

 

[mrkotfw]

Alright, I have my nice environment going (very conveniently placed next to me). I'm going to be using the Data-Link for now. I'll be rewriting the tool since it apparently doesn't work on my Linux machine.

 

[cafe-alpha]

Alright, I have my nice environment going (very conveniently placed next to me). I'm going to be using the Data-Link for now. I'll be rewriting the tool since it apparently doesn't work on my Linux machine.

Last year, I made an USB DataLink send/receive tool for Windows, and you can find the source code for it here or in the attached files. (this is Q&D source code, sorry)

[attachment=7735:usbdl_src.zip]

You may have to re-write some code in order to make it working under Linux, but it should be faster than writing everything from scratch

Hope it helps.

 

[mrkotfw]

Chilly Willy, there is documentation on the Sega Saturn SCR image format. So I'm planning on supporting that instead of say JPG/PNG/TIFF.

Is there any 3D formats low on parsing that describe models?

 

[mrkotfw]

Last year, I made an USB DataLink send/receive tool for Windows, and you can find the source code for it here or in the attached files. (this is Q&D source code, sorry)

[attachment=7735:usbdl_src.zip]

You may have to re-write some code in order to make it working under Linux, but it should be faster than writing everything from scratch

Hope it helps.

Hey, thanks! Q&D source code?

Oh, it's GPL'd. No worries.

 

[cafe-alpha]

Hey, thanks! Q&D source code?

Oh, it's GPL'd. No worries.

Since some other modules (RS-code computation library) I am using for my project are GPL licensed, I was forced to GPL all my sources.

But as stuff inside usbdl_src.zip doesn't uses third party GPL source, you can consider that usbdl_src's contents is WTFPL licensed

(Well, I don't know if it legal to re-license my own sources, but do whatever you want with them.)

 

[mrkotfw]

Since some other modules (RS-code computation library) I am using for my project are GPL licensed, I was forced to GPL all my sources.

But as stuff inside usbdl_src.zip doesn't uses third party GPL source, you can consider that usbdl_src's contents is WTFPL licensed

(Well, I don't know if it legal to re-license my own sources, but do whatever you want with them.)

I took a look at your code and it looks pretty much the same my satupload. I'll most likely take some ideas here and there. Again, many thanks!

 

[Chilly Willy]

Chilly Willy, there is documentation on the Sega Saturn SCR image format. So I'm planning on supporting that instead of say JPG/PNG/TIFF.

You mean SEGA2D format files?

You'll have current converters people can use? No one is going to use an old proprietary format for an old console, so you better have a converter that works on new systems on formats people use, like JPG/PNG/TIFF/BMP.

Is there any 3D formats low on parsing that describe models?

All the ones I've seen are about the same. Like my comment above, you'll want something people use TODAY, or a good new converter than runs on all platforms.

MDL (Quake 1) or MD2 (Quake 2) format is probably about the level you want for the Saturn. Maybe MD3 with some restrictions above what MD3 specifies, like total vertices.

If you are sticking to SEGA2D format, I suppose you might stick to SEGA3D format... those are in doc #ST-124-R1-091394.

 

[mrkotfw]

You mean SEGA2D format files?

You'll have current converters people can use? No one is going to use an old proprietary format for an old console, so you better have a converter that works on new systems on formats people use, like JPG/PNG/TIFF/BMP.

But of course I'll be writing a (JPEG/PNG/TIFF/BMP)2SCR converter

That won't be an issue. Really what attracts me to that format is the ability to have metadata already built-in. It can specify certain parameters for a background, say tile size and such which is great.

All the ones I've seen are about the same. Like my comment above, you'll want something people use TODAY, or a good new converter than runs on all platforms.

MDL (Quake 1) or MD2 (Quake 2) format is probably about the level you want for the Saturn. Maybe MD3 with some restrictions above what MD3 specifies, like total vertices.

If you are sticking to SEGA2D format, I suppose you might stick to SEGA3D format... those are in doc #ST-124-R1-091394.

Thanks! I'll also definitely look into the MD2/3 formats. I'm sure there are a lot of converters for those as well.

Ah yes, and that is the same doc for the SEGA2D format.

Edit: http://openarena.wikia.com/wiki/MD3_format

 

[mrkotfw]

Actually, using the SEGA2D format is an excellent idea since the converter can couple, say a PNG with a meta-data text-file and use that to output the SCR.

One thing that has always bothered me is the lack of map editors. That's something that I've always been far too lazy to fix.

 

[Chilly Willy]

Actually, using the SEGA2D format is an excellent idea since the converter can couple, say a PNG with a meta-data text-file and use that to output the SCR.

One thing that has always bothered me is the lack of map editors. That's something that I've always been far too lazy to fix.

We might think about a converter for the output from something like Tiled or Mappy. Tiled is available for Windows, OSX, and linux. It's still worked on, with the most recent update being in Feb. That's what I have installed on my system... I'm looking to use it for a game I want to work on later this year.

http://www.mapeditor.org/

Should have put these in the last post:

MDL: http://tfc.duke.free.fr/coding/mdl-specs-en.html

MD2: http://tfc.duke.free.fr/coding/md2-specs-en.html

MD5 (Doom 3): http://tfc.duke.free.fr/coding/md5-specs-en.html

Lots of good stuff on the root page: http://tfc.duke.free.fr/

The thing about newer model formats like MD3 and MD5 is people assume they are used on newer hardware and games, so models tend to be BIG. "Low poly" models in MD3/MD5 format tend to be "merely" a few thousand vertices. If you look for examples of MDL or MD2, you find models done for Quake/Q2, so they are much more reasonable in how big they are.

 

[mrkotfw]

We might think about a converter for the output from something like Tiled or Mappy. Tiled is available for Windows, OSX, and linux. It's still worked on, with the most recent update being in Feb. That's what I have installed on my system... I'm looking to use it for a game I want to work on later this year.

http://www.mapeditor.org/

Should have put these in the last post:

MDL: http://tfc.duke.free.fr/coding/mdl-specs-en.html

MD2: http://tfc.duke.free.fr/coding/md2-specs-en.html

MD5 (Doom 3): http://tfc.duke.free.fr/coding/md5-specs-en.html

Lots of good stuff on the root page: http://tfc.duke.free.fr/

The thing about newer model formats like MD3 and MD5 is people assume they are used on newer hardware and games, so models tend to be BIG. "Low poly" models in MD3/MD5 format tend to be "merely" a few thousand vertices. If you look for examples of MDL or MD2, you find models done for Quake/Q2, so they are much more reasonable in how big they are.

Thanks. I'm really going to have to see how SEGA3D or MD2 will fit. The major advantage to MD2 is that it works under Blender and such. The other problem is its endianess (not really an issue) and the fact that it uses triangles. Another thing is the texture coordinates. On the Saturn, we're only concerned with specifying some ID (e.g. the command table) and its location in VRAM.

Okay, Tiled is just awesome.

Here's my idea:

A tmx2raw with a user supplied meta-data file V that describes the VDP2 parameters will produce a Saturn specific map file F.

The SEGA2D will take the same meta-data file V and the map F as well as the tile-set and produce the final result.

If the SEGA2D is bitmap, it'll simply take in the meta-data file and the texture.

The meta-data file will be written by hand.

So you can imagine something like:

$ sega2d nbg0.xml nbg0.png nbg0.map

Will produce nbg0.scr which could be later linked into the binary.

The reason why I made a clear distinction is that I don't want to write the SEGA2D converter specifically for Tiled. tmx2raw will be specific to Tiled and not a part of libyaul. This goes with the same philosophy of libyaul. I don't want it to be some "game" library. I want it to be a generic and flexible backend for any use. Whether it would be a technical demo, an emulator, or even a game.

Just throwing some ideas around. I'm documenting this and adding it to my TODO list (it's growing very large!)

 

[Chilly Willy]

Thanks. I'm really going to have to see how SEGA3D or MD2 will fit. The major advantage to MD2 is that it works under Blender and such. The other problem is its endianess (not really an issue) and the fact that it uses triangles. Another thing is the texture coordinates. On the Saturn, we're only concerned with specifying some ID (e.g. the command table) and its location in VRAM.

Yeah, it doesn't quite fit the Saturn like it should - quads and BE would be better, but I don't think you'll find that on any BIG format as they're all for PC graphics.

Okay, Tiled is just awesome.

Yes, it's the bee's knees.

Here's my idea:

A tmx2raw with a user supplied meta-data file V that describes the VDP2 parameters will produce a Saturn specific map file F.

The SEGA2D will take the same meta-data file V and the map F as well as the tile-set and produce the final result.

If the SEGA2D is bitmap, it'll simply take in the meta-data file and the texture.

The meta-data file will be written by hand.

So you can imagine something like:

$ sega2d nbg0.xml nbg0.png nbg0.map

Will produce nbg0.scr which could be later linked into the binary.

The reason why I made a clear distinction is that I don't want to write the SEGA2D converter specifically for Tiled. tmx2raw will be specific to Tiled and not a part of libyaul. This goes with the same philosophy of libyaul. I don't want it to be some "game" library. I want it to be a generic and flexible backend for any use. Whether it would be a technical demo, an emulator, or even a game.

That makes a lot of sense. The converter for images should not be related to Tiled because it should take any image from anywhere. On the flip side, the converter for tiled maps should be part of tiled so that if you use tiled, you can use it, and if you don't, you never have to concern yourself with it at all.