Compiling higan v101 under Debian Stretch

While writing Super Turrican MSU i used a modded version of higan v094 back then. byuu was not sleeping and i'm pretty sure he doesn't uses Debian as higan v101 can't be compiled out of the box.  Change the following line of GNUmakefile.

flags += -I. -I.. -O3
to
flags += -I. -I.. -O3 -I/usr/include/gtk-2.0/ -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include/ -I/usr/include/pango-1.0/ -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/atk-1.0/

higan should now compile but still not runnable as the manifest.bml is missing.

run make install once as a normal user. your home directory is set up.

Super Turrican MSU v0.3 now with NTSC support

Some people asked for the US NTSC version of Super Turrican MSU...

You people are crazy!
The game was made in germany. It has to be played in 50 Hz! D:
Factor 5 did a bad job on having both versions consistent in manner of speed. It almost feels like the only difference between them is that the US version has the SEIKA logo.
This is why i conclude here that the US version is a little bit more difficult but also more fast paced if you like that. On my TV set the 60 Hz video signal is more crisp but this is not the version i've grown up with...
I'll stick to PAL.

Anyway, you asked for it:

Download Super Turrican MSU v0.3

I will remove v0.2 in a few days or weeks from Dropbox as it won't be needed anymore. Version 0.3 contains the PAL version as well so don't bother loading the old one.


I only play tested the NTSC port once. I had to rewrite some of the code to get it right. The program code of Super Turrican is compressed on the cart. But hacking compressed code in an algorithm i don't know is tedious. I had to work around this time making the NTSC version behave different.
Especially the title screen is buggy as the cursor won't show up by itself. But apart from that the US version is fully playable and hasn't shown signs of failure during my playthrough.....

Please keep in mind that even the original version of Super Turrican can crash on 1chip SNES models and i'm not able to debug that. The SPC is prone to hang himself in this game.

Turrican Soundtrack Anthology:
The music in this game is an altered version of the Turrican Soundtrack Anthology made by Chris Hülsbeck. If you like the Soundtrack you can buy it from his bandcamp site in lossless FLAC and MP3. There are 4 albums to get, containing not only the arranged Soundtrack for Super Turrican but also for the other games as well. If you are confused by the sheer amounts of music Chris has made there is also website especially for the Turrican Soundtrack albums.

Super Turrican MSU V0.2 released!

>>>Update: Go check out this post for Version 0.3.

I'm happy to announce that my Super Turrican MSU Hack will now be released. Chris Hülsbeck gave me permission to publish the soundtrack with the hack which was the crucial part in the end.

You can download the hack here.

Download Super Turrican MSU Hack

Keep in mind that you need a sd2snes or the emulator higan to run this hack! Currently only the PAL version is supported!
 

The package only contains the soundtrack for the MSU chip and an .ips patch file. You need to get the ROM by yourself.
You are only allowed to apply this patch if you are in possession of the original.
For this you need the .sfc file of your game. Either read it back from the cartdrige or ….. help yourself in other ways.

Download JIPS or another ips patcher to apply the patch. It's very important you got the right ROM. To be sure the correct file has the md5sum of 90c9fe8386a7f69de475c58bb8de01f7.
If you patched your .sfc file put it together with the rest of the files inside the package into a directory on your sd2snes.

The package contains a README.txt which will explain the process in more detail.

That's all!


The music in this game is an altered version of the Turrican Soundtrack Anthology made by Chris Hülsbeck. If you like the Soundtrack you can buy it from his bandcamp site in lossless FLAC and MP3. There are 4 albums to get, containing not only the arranged Soundtrack for Super Turrican but also for the other games as well.


---> Very important note <---
The game has one major bug which was kinda amplified with my hack (at least i feel so). The usage of the blue laser weapon can lead to a hickup of the SPC on some SNES devices. If this happens you can hear a strange and loud noise that sounds like "frfrfrfr". At this point the game still runs but you are unable to get to the next level as the main CPU is not capable of talking to the SPC anymore.
Even a reset of the SNES doesn't restore a healthy state sometimes.
You need to cut the power of your SNES for seconds to make it runnable again.
I'm not yet sure how this happens and it kinda flaws the whole hack. The only bright side is that this flaw is actually part of the original game.

Please help me investigate. Test the game and report issues. This flaw never happened to me on the emulator higan i used to develop the hack which is a major fallback. I'm not capable of debug this issue at this state. Just try to stay away from the blue laser.

Sadly enough it's also possible to get this problem in more rare occassions with other weapons as well. I could only assume that the soundeffect playback routine has a bug that i still don't understand.

Now as it turns out this happens only on 1chip SNES and newer revisions. I will investigate!

Super Turrican - MSU Hack

Last year i got myself a sd2snes flash card and soon figured out that there is a feature called MSU. It's a soundchip which is capable of playing raw wave files from an sd card just by writing in a register which song number to play.

Now we have a wide variety of MSU patches available which make games like Mega Man X and Super Mario World use it to play their background music.
It's kinda something the Mega Drive got with the MegaCD but with sd cards instead.

Last year after meeting Chris Hülsbeck, i thought.... Super Turrican really is in need for a MSU hack but there wasn't any.
I've read about higane which is an emulator capable of simulating the MSU (or invented it in the first place???) and got the source code of it.
Using the integrated tracer and a few mods i've disassembled the functions of Super Turrican in charge for SPC control and replaced them with my own. Luckily there was enough space left on the ROM to place them.

Now whenever the game says "play song X" i analyze this call using a table and in case there is a wave file for that song on the sd card it is played. Otherwise the original process continues and the song is played using the SPC.

Some gameplay footage can be found on YouTube.

I really like to publish the whole package here.... stay tuned.

I love / hate the Amiga 1200

If i would try to name a system from my collection which wasted the most of my life time AND money with hassle it would be the Amiga 1200.

It don't even remember when i bought my first Amiga 1200. I guess it was 2010 - 2011. But i do remember it was one of the late revision 1D4 motherboards with pc floppy drives... urgh. This thing couldn't even load usual amiga software as the floppy didn't have a RDY signal.

I didn't knew that when buying but i didn't even care as soon as i knew. This Amiga 1200 was intended for hard drive operation. Soon after getting the system i got myself a compact flash adapter with a 4GB card and the "ACA1230" turbo card from individual computers.
The collection was after a while completed with an "EtherLink III" PCMCIA card for file transfer over an FTP server running on the Amiga.

Anyway. This particular ASSHOLE of an Amiga had an issue with it's Bustiming. As soon as the ACA1230 was inserted and running the system started to glitch up after 5 minutes or so. I've talked to the designer of the ACA1230 but even with tipps i was just unable to fix this thing. After experimenting with different capacitor setups to fix the clock i bought another one.
This time it was a standard Commodore A1200 again with revision 1D4. It worked like a charm. I didn't had to fix anything. The ACA1230 was running and i was happy. But there was one litte problem from the start. Crossdos which is the driver to mount MSDOS formatted floppy drives never worked on this machine. The floppy started spinning and never stopped. I thought "well, let it be. I have a LAN card".

Another thing which bothered me were digital sound glitches. At this day i was pretty sure that Paula, the custom chip responsible for floppy reading and writing and sound output might have some issues. Especially on the game Z-Out...


This day on 30th August it happened. I turned the machine on and *sssshshshshshs*. It was a sound of a transistor burning to hell or at least i thought. I opened it and there was ... nothing. I turned it on again and the machine booted. Workbench appeared but there was something missing. No floppy was read and no sound. Oh god, Paula finally died.

So i bought myself a replacement from old-stock and a plcc 52 socket and finally some capacitor replacements which is recommended for old SMD Amigas. I desoldered Paula using a temperature controlled heat gun and fitted the new replacement chip. Sound was working again but no floppy whatsover. As it turned out the Amiga didn't make the burning sound itself. It had to be the floppy drive as a replacement fixed the issue. Floppy reading worked again but was kinda flawed. The whole system was very unstable and crashed very often or didn't even considered to boot kickstart.

I gave up again.... and bought another one.
After these years prices for Amiga 1200 units exploded. I bought my first two for 130€ each.
Now i got one with replaced capacitors without power supply and a housing that was very dirty for 270€. It even had Kickstart 3.0.

So i took all parts and made one system out of the best of all 3.
The machine booted... Yes :-)
ACA1230 in. The machine booted..... Yeees !! :-D
I started the WHDload version of Apidya and played. 5 minutes into the game crashed..... FUUUUUUUU  D:

As it turned out the new board had timing issues as well. Even though it was a revision 1D1 which i read was about one of the best. So i followed the suggestions made on this site here. As it turned out ACA1230 needs a fix on every FU**ING revision. Jens Schönfeld, what have you done? D:
So i placed 22pf on E121C and E122C and it .... seems to work.
I played Apidya for quite some minutes. Maybe an hour or so. Even at world 4 the system was running stable.

Is this it? Do i finally possess a stable A1200 ?

On thing can be said for sure. At the moment i can't trust any A1200 any more. I thought about buying the Indivision.. but i guess i will wait some time...
I never had these issues with my Amiga 500. But i never really upgraded that one. It had a slow mem expansion and thats it. Turbo cards seem to cause quite some issues and show how flawed the late models of Commodore were.

I've kinda lost faith which needs to be restored now. I now have a graveyard of Amiga 1200 hardware around. I feel bad for it. Maybe i can fix them somehow but it showed to be quite difficult.


I just wanted to talk this from my heart.

Slamy STM32 Floppy Controller - Part 1

Motivation

Back then i had quite some struggle getting old games to work again. My dad once brought me to an Amiga distributor and i was allowed to buy a game. I chose "Enchanted Land" a disk which years after that refuses to load.

I remember that i got my first way around issues like that sometimes after that. There was a program called "Amiga Explorer" allowing me to write ADF files using a windows tool with the same name and a server running on my Amiga 500 communicating over the RS232 port.
This way i could play some of my games again but.... i had to work with sometimes faulty cracked version.

At that time i also read about the Catweasel controller, a PCI card with a flexible floppy controller design allowing a more easier way to write disks back in a direct way from the PC.

That was about 10 years ago....

An half year ago or so i read about Kryoflux. This powerful device which is mostly designed to preserve dying floppy media for future generations also had writing capabilities.
The price was not that high but i didn't knew if it would suit my needs as i had mostly the intent of writing images back.
Also i was very interested in the techniques used around that time so a new tinkering project was on its way.

Atari ST - ISO sectors and MFM stuff (starting from 2016-02-07)

During February 2016 i decided to give it a go and started at the hardware design.
During 2014 I did make a floppy controller with an FPGA to write Atari ST compatible disks so i had already some knowledge on that matter. As FPGA development is rather tedious and modern controllers have become very fast i decided to go for an ARM instead.

My choice fell on the very cheap STM32F4 discovery board. It costed about 12€ and is equipped with an STM32 clocked at 168 MHz. What a beast !!!
Another very important feature was the integrated debugging and flash circuit and a USB OTG controller for getting image data from a PC.

I ported my original C code running on the plasma mips softcore from opencores to the STM32 and implemented the MFM decoder using the integrated timer.
For USB communication i used the stack of https://github.com/MaJerle. It's a modifed version of the OTG driver coming with the STM32F4 examples which luckily ran quite nice. (The original library from STM just refused to work)

And after some tinkering i was able to decode MFM and to parse the ISO floppy format making me able to read Atari ST and MS DOS disks in DD and HD. This page helped me a lot. Everything you need to know about MFM and ISO sectors.

So what comes next after reading? Writing of course! I've developed a linux driver to transfer image data from *.ST images to the controller which writes it track for track.
My Atari 1040STFM was quite happy about the result and played cracked versions of some games without problems.

Coming that far i decided to go for Amiga disks. The MFM used on my most beloved machine was quite different. Instead of encoding 8 bits to 16 MFM bits it used an odd and even way. When encoding 32 bits it first encoded the 16 odd bits and then the 16 even bits. Quite a hassle but possibly a style which had a better performance on the floppy controller design in the custom chips.

After basic writing of ADF files which are a binary representation of a standard Amiga DOS disk i finally went for the main goal.

Amiga IPF files (starting from 2016-03-06)

Original versions of amiga games usually come with a certain copy protection. Some use very long tracks with a reduced bitrate to get more data on a track than usual. An amiga couldn't write that. Turrican 1 and 2 are protected that way.
Others were protected using a varying bitrate. Speedlock is a protection which used that technique.
The ADF format is only capable of storing the payload data. No meta information is saved.
For everything else IPF files are used.
Soon i've discovered that http://fengestad.no/libfs-capsimage/ was all i needed. The capsimage library is a closed source manager for IPF track data which i decided to use.
What it basically does is giving back the raw MFM tracks and also with bitrate information for every MFM byte if specified by the image.
It took a few weeks of debugging and analyzing but it worked in the end. Writing back Turrican 1 and 2 (Long tracks) and Rodland (Speedlock) was possible using my so called "Slamy STM32 Floppy Controller".

This success gave me an amazing motivation and i went further.
I realized this wasn't a normal floppy controller anymore. This was called a floppy tracer, an industrial device to write mastered disks ! >:-)


To be continued.... Amstrad CPC and C64