doxDev

$7dc

2012-01-02T01:40:00.000+01:00

There was not much progress in 2011. I've been lately very busy with my work projects ( this and this one). But at least i've prepared a TO-DO list for 2012 ;) :

1. VEGA ( Olympia, 1982 )

I have recently got Vega PCB. Special thanks to Mark Frisbee for help.

Unfortunately board has few faults ( no sound, gfx glitches ) and inverted colors (like early Nintendo boards). Theres a couple solutions for the latter problem. I have decided to mod the pcb a bit and invert the digital signals before the DAC (made of resistors). Here's a video from attract mode:

So, next step is to emulate the game :)

2. TIME ATTACKER ( Shonan, 1980 )

Currently i'm making schematics of video section. It's similar to classic Pong discrete logic, but a bit more complicated (game has Z80 cpu). TA is a breakout clone, with special add-ons like oil zones and moving enemies ( btw : background color - blue or black - is selectable with a jumper on board ):

3. WHEELS & FIRE ( TCH, 199? )

Not much about this one. I'm in the middle of MAME driver rewrite process (based on game sources i got from the author).

Let's play tennis!

2011-05-23T02:23:00.000+02:00

Here's few pics from Reality Tennis by TCH (pcb recently acquired by Dumping Union ). Game runs on blitter-based hardware, similar to Wheels&Fire, but more simple. Current emulation status: game playable with few gfx glitches and without sound.

More great news - i have recently contacted Antonio 'Peluko' Carrillo - programmer and game designer of both Reality Tennis and Wheels & Fire. He has provided tons of usefull info about the w&f hardware and the game code. The first, big improvement is (a bit buggy) sound emulation.
I'm going to rewrite the whole video hw emulation of w&f, and disable all hacks & precalculated zoom tables. Quite challenging, but worth the effort.

Ok. Back to tennis:

Seibooooo

2011-01-16T17:38:00.002+01:00

After a (12 months) break updated my other blog.

If i could turn back time....

2010-12-31T14:17:00.013+01:00

I fixed a couple of video/sound issues in Chouji Meikyuu Legion emulation:
- added SFX,
- fixed video priorities (no more garbage gfx over the playfield),
- simulated protection in"legion" set, so the functionality is now close to the other ("legiono" - possibly a bootleg) set,

Legion was _almost_ playable before. It's still not perfect (broken test mode, missing various text strings here and there ) but imo more enjoyable.

Game has really unique (as for 80s) feature - 'time warp' bombs. How it works? Try it yourself ;)

Here's a couple of shots from the game:

Busy.. busy.. busy ...

2010-09-29T23:37:00.017+02:00

Something VERY special!
Purchased by Dumping Union. Donators:

Cananas, Mr. Do, S. Brown, J. Bijl,ranger_lennier, F. Xerri, Gor, Kevin Eshbach, Smitdogg, Guru, Tormod

Another game from '80s - 'Super Wing' (thx wulfman) .
Preliminary screenshots:

Also this. Bought it few weeks ago:

It's set of boards from THIS machine.

Interesting mix of hardware ( adp.c + artmagic.c ):

- JAMMA pcb with 68k + tms34010 + oki(sound) "Made In Belgium". All eproms/pals has A&Mxxxxx stickers = art&magic
- adp/merkur cpu board - 68k + eproms + nvrams, eproms labelled "shooting star"
- adp/merkur i/o + sound board - 68681 + ym2149
- "gewehrcontroller" pcb (gun controller) with 80c31 ram and rom
- few smaller pcbs with triacs, resistors and other analog components
Not emulated yet.. no screenshots ( just black screen .. due to protection)

Wheels & Fire

2010-06-23T21:05:00.000+02:00

After looong break i'm looking again at Wheels & Fire from TCH.
Game is running on custom, blitter based hardware (sprites + framebuffer layer with linescroll feature, and sprite-to-framebuffer rendering mode ).
I have made a lot of changes/improvements lately, but there's still a lot to do:
- proper image scaling - quite weird (close to hardware, i think) way to draw scaled images. for more details pls scroll down to the end of this post.
- framebuffer (various problems)
- sound - not emulated yet (2nd 68k + samples)

Here's few pics from the game:

W&F video hardware supports image scaling. For each image(sprite) to draw, there's a couple of parameters sent to the blitter:
- screen cooridnates of image rectangle ( top left ad bottom right corners) _after_ scale transform applied,
- source image cooridnates (only the upper-left corner, no info about the source dimensions),
- two sets (for x and y scale) of magic parameters : data1 (5 bit), data2 (5 bit), four flags ( double/half scale , zero/nonzero params (maybe they are just the MSB of the data1/data2))
Magic ;) parameters are packed into 5 bytes. They are essential to udnerestand how the hw works and how the scaling is done. So far it's just pure magic ;) Params are copied from a lookup table addressed by the scale factor (0-400%):

X Scale Table:

7	6	5	4	3	2	1	0
-	-	-	A	B	C	D	E
-	-	-	F	G	H	I	J
-	-	-	-	-	-	-	-
-	-	-	K	-	L	-	M
-	-	-	-	-	-	-	N

Y Scale Table:

7	6	5	4	3	2	1	0
-	A	-	-	-	-	-	-
D	E	-	-	-	-	-	-
B	C	-	F	G	H	I	J
-	-	K	-	L	-	M	-
-	-	-	-	-	-	N	-

BITS ABCDE = DATA1 (0-31)
BITS FGHIJ = DATA2 (0-31)
BIT K - ( scale > 200% ) ? 1 : 0
BIT L - ( DATA2 != 0) ? 1 : 0
BIT M - ( DATA1 != 0) ? 1 : 0
BIT N - ( scale < 50% ) ? 1 : 0

Both (x and y) tables contians exactly the same data, just shuffled arround to easielly pack (by OR-ing) into 5 bytes and send to blitter. For now i'm uisng lookup table to determine the scale factor (based on the above params). Works pretty well, but the goal is to underestand how the data is interpreted by video hw and emulate it properly.

RED = data1 (0-31), WHITE = data2 (0-31)
Ranges 25-50% and 50-100% (as well as 100-200% and 200-400%) contains very similiar data, and the first one has special ("half") bitflag set (same for 200-400% - there's another bitflag set("double")). Probably for change the video hw (fpga based) pixel counter/clock.

Both data1 and data2 are mysterious for now. There's few ideas about them:
- fixed point 5.5 (src pixel delta/step?)
- pair of step + oveflow for src pixel "counter"
- floating point num (5 bit mantissa, 5 bit exponent)

A couple of examples ( scale factor - data1 - data2 - bit M - bit L) :

Any ideas ?

It's full of stars! - Vega, part3

2010-03-12T11:56:00.008+01:00

I was wrong - there's no "type 3" sprite. It's just a background layer made of 16 different 32x32 pixel tiles. Tilemap (128x8 cells (4096x256 pixels), animated (flashing stars and texts) ) is hardcoded inside one of eproms used as a lookup. Here's a screenshot from game - shows only the most boring part of bg - stars: Game is not playable (yet) so i can't see other levels / backgrounds. These images are ripped directly from the tilemap (wrong colros, as usually ;) : There's also an interesting hw feature - background can be stretched horizontally (in fact - vertically (div scnaline clock by 2), because screen is rotated by 90 deg). It's probably used (only?) to display the planet surface:

25 light-years away from home - Vega, part 2

2010-03-10T15:08:00.013+01:00

The good news - i have got scans of vega schematics (big thanks to Kold666)
The bad news - hardware is quite old (early 80s .. possibly 1982 or 1983) (read: unique and complicated) and schems are buggy as hell.

The biggest problem so far - no reference images/screenshots/flyer pics. Nothing. I have no f***ing idea about the real game.

So any info will be greatly appreciated.

Schems are as mysterious as the pcb pics i got - no info about the major ICs.
But looking at pinout i have identifed all of them as:

- i8035 (mcu)
- AY 3-8910 (sound)
- PPI 8255 (i/o)
- INS 8154 (i/o + ram)
- DP 8350 (crt controller)

AY is used only for generating sfx. Afaik there's no music. Sound chip is connected in unusual way - AY data lines are tied to address bus and AY address/data write selection is connected to mcu R/W line. So, writing any data to address NNN within range mapped to AY - results in setting AY address register to value NNN. Reading from address MMM store MMM in AY data register. Weird, isn't ?

Graphics hardware consist of four different "blocks":

- text layer - 1bpp fonts with hardcoded (PROM) color for each character. Bullets and some type of enemies are made of characters on text layer.
- four "type1" sprites - simple format, 32x32 pixels, horizontal flip, direct color (1r1g1b + extra unknown bit). Used mainly for enemies (spaseships)
- single "type2" sprite , used for player's ship/explosion only- 32x64 object made of 32x4 slices.
- single (?) "type3" sprite - not emulated yet. Quite big (possibly 64x64) obejcts (planets, asteroids) with special 2kb lookup table.

So far, the most complicated to emulate was the type 2 player sprite. It's auto-animated (based on vblank counter). There's also a 256x4 PROM used as a lookup table , connected in a bit weird way :

Here's some (test/temporary) formula i'm using to draw the sprite:

And now few fresh screenshots. Sprite positions (type1 and type2 (last pic)) and colors may be wrong:

Vega

2010-02-16T18:11:00.007+01:00

Tym razem na warsztacie VEGA (włoskiej produkcji - Olympia). Początki są obiecujące - na razie działa tylko Text Layer (prawdopodobnie na kontrolerze crt DP8350). Całością steruje CPU Intel 8035. Reszta hardware nieznana (na jednym z niewielu dostępnych zdjęć PCB większość istotnych IC ma starte oznaczenia ): Kilka wstępnych screenów:

Więcej kulek ...

2010-02-12T22:57:00.006+01:00

Pachifever jest już grywalne. Kilka informacji o hardware: - CPU - TMS9995 - VIDEO - TMS9928 - AUDIO - SN76496 + MSM5205 (nie mam potwierdzenia co do powyższych informacji (oprócz MSM) więc to tylko przypuszczenia). Gra korzysta z tradycyjnego (mechanicznego) kontrolera Pachinko i trochę kłopotu sprawiło podpięcie sterowania. Brakujący ROM zawiera - prawdopodobnie - część efektów dźwiękowych oraz dane potrzebne do ich odtwarzania. Skutkiem tego jest - niestety - brak sfx :( Kilka nowych screenów:

Fever

2010-02-08T00:47:00.008+01:00

Postępy w emulacji Pachinko Fever (a może Pachifever lub Fever 777?). Ciekawy hardware na bazie TMS9900 (jeden z pierwszych 16 bitowych CPU). Niestety, to prawdopodobnie zły dump - dwa obrazy ROM-ów są identyczne :(

La Girl...

2009-12-02T01:13:00.005+01:00

Tym razem dump z zasobów Guru - koreańska przeróbka Play Girls (kopia Taito L-System hardware zrobiona na trzech układach TPC1020 (FPGA Texasa)) . Zmieniono tytuł i wsadzono nową grafikę tła - soft anime (dlaczego nie tentacles z 'La Blue Girl' ?). Grywalność bez zmian ...

Kolejna gra ze SNESa w wersji arcade.

2009-12-01T01:13:00.008+01:00

Pojawił się nowy dump (sygnowany przez Volkera Hann & Team Europe) gry działającej na pirackim hardware konsoli Super Nintendo. Prawdopodobnie to jedna z pierwszych gier przerobionych w ten sposób - brak skomplikowanych zabezpieczeń i wymyślnego szyfrowania. Twórcy hardware przemieszali jedynie linie szyny danych ROM - "bruteforce" (8! permutacji do przetestowania ) i po krzyku. Z ciekawostek - tekst (copyright) znajdujący się na początku ROMu został lekko zmieniony - poniżej wersja ocenzurowana. Gra o której piszę to Iron znana na platformie SNES jako Iron Commando. Zmieniono screen tytułowy, dołożono obsługę coin slotów oraz DSW. I.. to tyle :)

オセロ

2009-06-04T11:29:00.009+02:00

Another game made by Success. And yes - another Othello. This time from 1984 running on a bit weird hardware (only 20% of pcb is filled with ICs): - two Z80 (main and audio) - two AY-8910 - D7751C Nec MCU (sample player ??) - HD46505SP Crt controller (6x16 pix tiles in 16 colors) Few preliminary pics (colors are wrong): PCB pics courtesy of Stefan Lindberg:

Parent Jack

2009-03-29T20:23:00.006+02:00

A few improvements to Parent Jack driver. Game runs on Taito H System hardware.

More Culture, Please ...

2009-03-08T20:10:00.005+01:00

I'm still alive. Just busy (work, real life).... A tiny update - small fix to "Jibun wo Migaku Culture School Mahjong Hen" driver - colors!.

Back to '80

2009-02-09T16:15:00.010+01:00

Guess what was my first computer ? Yeah, Speccy.. gazillion years ago. I have used it to play (cool) games and coding (not so cool) programs. In early '90 i have got my first 16 bit machine - Amiga. But ZX Spectrum is still my fav machine ;) Also, i can call myself "sunday speccy coder". Once a year i'm trying to make something fun for small demo party - Raww Orgy . Made so far three 256 bytes intros. Here are some brief info about them. Full videos are available in "My Videos" section: Brainwasher (2nd at Raww Orgy 2009) - weird intro.It displays (and plays) own code (as data) on the screen... In fact it's trying to take control of your brain ;) RGB (5th at Raww Orgy 2009) - three rgb balls jumping on screen. Border is (or rather - should be) synced with the background. Blister Sisters (6th at Raww Orgy 2008) - last year entry. Three blobs flying around. There's also special feature - terrible long precalc time at start (perfect for make a coffee) ;)

Super Othello.. again.

2009-01-20T21:49:00.004+01:00

Oh no! Another Super Othello WIP screenshots? Someone probably remember the screenshots i have published a couple of months ago on my old Mame WIP page. Everythign was almost ok. But due to weird behaviour of the sub cpu (the system consist of three cpus : main Z80, sub 6809 and sound z80) game wasn't playable. I have decided to take another look at the pcb. It was a good idea, because finally i've found what was wrong / missing. Game is now playble with full sound (ym2203 music / sfx + m5205 voices).

The art of rippping.

2008-12-07T01:28:00.009+01:00

New board arrived. "Spinkick" by Seojin/Heasung (notice the big epoxy block with "HEC" logo). PCB is 'almost' working, but there's no way to insert coin(s) and start the game (probably one of the input buffer chips is broken... very common).

And yes, it's rip-off of the Sega's "Free Kick" game, running on really weird korean hardware based on MSX2 home computer ( plus additional sound cpu (Z80) and extra logic to handle a bit different (than in MSX2) rom banking ). Game ROMs contains hacked MSX2 bios - they removed all (c) texts, blanked font area and added few mods here and there to skip boot sequence. Also, for some unknown reason, Yamaha v9938 VDP is hidden in big and heavy epoxy block. Probably to make a fake impression of being orginal, not stolen piece of hardware.
So .. what's the point of use MSX2 as the base ? I have NO idea... Imho it's way easier to start from scratch and design own, simple hardware (vdp, cpu, roms, rams) than modify msx one. Bios is used only at boot time (it req some sick logic chips (8255 + demultiplexers and buffers) to handle the msx "slot" memory banking scheme) - game is directly accessing the VDP and banked roms.
After a bit of pcb tracing and with help from #msxdev guys i got this:

Two different versions of the title screen.

WTF? Blind Superman ?

Meow!

2008-11-07T17:34:00.014+01:00

Finally, after long break i'm working again on one of my old "afterwork" projects - a Gameboy Mono (DMG) game. The gfx (made by Adam ) is almost done. Also audio part (by ne7 ) is completed. The most important element - code - is (still ... ) missing. Only the basic skeleton is done.
A couple of level "rooms" :

And a first gameplay video:

More M.A.M.E. wip

2008-10-09T02:37:00.009+02:00

I have finally figured out what was wrong with the gfx emulation in Sonic Blast Man 2 - OAM address wasn't correctly restored. RB pointed me to some interesting hardware docs with explanation of this behaviour. It was already implemented in the snes driver, but with major flaw. In fact - instead saved OAM address - the current one was restored (so ... there was no difference between old and new). After fixing the bug, game is fully playable.
Few weeks ago f205v has found "Little Robin" pcb for sale. Game is not working in MAME (video hardware is only partially emulated) - so i have decided to buy it. PCB arrived few days ago. Spanish pcb, with korean labels, found in Itally.

I'll try to run some trojan/test code on it. There's chance to make this weird 'Snow Bros' rip-off playable.

Btw, i'm still looking for the pcb of another unemulated TCH game - 'Wheels & Fire'. As well as other, undumped/unemulated arcade games from Spain.

Few pics from the game:

My monitor has some problems with displaying game gfx. There's weird gradient on the bg as well as missing blue color component here and there. Also the SYNC signals generated by PCB are out of range a bit.
There's also video from attract/gameplay in the My Videos section

Sonic Blast Man.

2008-09-27T00:23:00.011+02:00

Few words about an arcade bootleg game called 'Sonic Blast Man 2 Special Turbo'. The game is a slighty modified copy of Taito's 'Sonic Blast Man 2'. It runs on hardware ( custom chinese, not the NSS ) "borrowed" from Super Nintendo home console. Just few eproms, rams, three custom QFP chips (there's also another, odler version of the hw, with 6 of them) and Lattice PLD - to handle the most annoying part, protection. So... What's the point to encrypt/protect pirate game? To hide the 'real' (in fact - stolen ) game code and data? Or maybe to annoy other bootlegers? No idea. Kold666 already dumped the ROMs while ago. Unfortunately the pcb is no longer available for additional testing or analysis. The data encryption is not as simple as in other arcade SNES hacks (Killer Instinct, Final Fight 2). But with great help from Andreas Naive it's finally broken. Also the in-game protection checks are now gone (took me a couple of hours to find what's going on and crack them). Ok. So... how the protection works ? 1. Encryption. Four hardcoded lookup tables (16,16,64 and 48 bytes) are used to get the real data. Plus some extra bitswaps and bit negations at the end - or more fun. 2.Boot code relocation. Original boot code (at $8000) is erased. There's also *special* message ;) New boot code (and the custom coinage / game control stuff) is placed around $7xxx and MUST be visible there in memory map. In genuine snes console this area is marked as 'reserved', and afaik - not accessible. Also - like in the other arcade SNES bootlegs - ROM header contains fake boot vector. 3.Read-and-compare checks. Few ( seven iirc ) data test in $6xxxxxx area (red mark = jmp executed when protection check fails). 4. Read-read-compare ;) check. Just opposite to the above - two consecutive reads (almost , with 3 nop-s between) from the same address (in $7xxxxx range) must give different results. Otherwise - boom! 5. Few more mods - special data (including JAMMA coin inputs and DSW) reads in $7xxxxx area and usual game modifications (removed copyrights, etc). Here are few screens from the MAME. Glitchy gfx ( mostly sprites ) is caused by bad emulation of the SNES hardware in MAME - the original SNES version of Sonic Blast Man 2 looks almost identical in MESS (has the same gfx problems).