News:

Forum Updated! 

Main Menu

more gcc insanity!

Started by neozeed, August 29, 2016, 05:02:09 PM

Previous topic - Next topic

kamiboy

Bah, I steer clear of the 68030 machines and other such oddities. I don't want a machine that will have problems running some games. A Compact XVI and a twin tower stock 10mhz is the optimum setup for me. I already have the Compact, all I need is the tower and I am set. I don't really see the point of the extra performance. All the games that interest me run fine on a 10mhz machine, and if not I always have the 16mhz mode on the XVI which I can toggle on and off at will.

neozeed

Are these the optical drives you have in mind?

http://www.vcfed.org/forum/entry.php?568-MD-Data

They look cool

kamiboy

Damn, that SONY drive is damn sexy. Alas that is not the one. That is a spinoff tech based on minidiscs that never really caught on. I am looking to get an MO drive, which was a somewhat successfull portable storage solution post floppies. You can find tons of them for sal on Yahoo.

neko68k

 Playable binary

shoot is bound to Z
and the arrows control the dude
space is use
run is not bound

This will only be playable in emulation for now. 030 with 8MB RAM is required. 100MHz and the smallest view is recommended. No-wait and turbo mode are both pretty great to play. There is a graphical glitch where some pixels are black. Probably something with the CRTC registers. I'll figure it out later. Anyway, enjoy. :D

neozeed

Quote from: neko68k on September 06, 2016, 06:33:57 PM
Playable binary

shoot is bound to Z
and the arrows control the dude
space is use
run is not bound

This will only be playable in emulation for now. 030 with 8MB RAM is required. 100MHz and the smallest view is recommended. No-wait and turbo mode are both pretty great to play. There is a graphical glitch where some pixels are black. Probably something with the CRTC registers. I'll figure it out later. Anyway, enjoy. :D

Wow totally awesome! and you can exit without crashing out!  Super cool job!!!!!!

neko68k

It actually wasn't crashing. It fails to save and restore the text mode palette. I'm not using it anyway so I took it out.

I need to figure out to capture the keyboard inputs so they aren't piped to the shell. Seems like I used to know how to do that... Though I don't think I've ever used BITSNS  before so I dunno.

neozeed

Did you update the source repo?


I'd like to try to use the current io on quake.....

neko68k

It's up now. It was a really dumb small change for the keyboard. The tic timer should be a lot more accurate now. This gives a little speed boost. A better boost was making every other line blank instead of doubling lines for the aspect ratio. That helps a good bit.

I'm trying to get it to draw directly to GVRAM because it's much much faster that way but it seems easier said than done. :/

neozeed

It's broken in some fundamental way but....

Host_Init
Added packfile ./id1/pak0.pak (339 files)
Added packfile ./id1/pak1.pak (85 files)
PackFile: ./id1/pak1.pak : gfx/pop.lmp
Playing registered version.
PackFile: ./id1/pak0.pak : gfx.wad
Console initialized.
Exe: 07:24:58 Sep  8 2016
8.0 megabyte heap
PackFile: ./id1/pak0.pak : gfx/palette.lmp
PackFile: ./id1/pak0.pak : gfx/colormap.lmp
256k surface cache
========Quake Initialized=========
PackFile: ./id1/pak0.pak : quake.rc
execing quake.rc
PackFile: ./id1/pak0.pak : gfx/conback.lmp
PackFile: ./id1/pak0.pak : default.cfg
execing default.cfg
Unknown command "volume"
FindFile: ./id1/config.cfg
execing config.cfg
Unknown command "joystick"
Unknown command "_snd_mixahead"
Unknown command "bgmvolume"
Unknown command "volume"
Unknown command "vid_window_y"
Unknown command "vid_window_x"
Unknown command "block_switch"
Unknown command "vid_windowed_mode"
Unknown command "vid_fullscreen_mode"
Unknown command "_windowed_mouse"
Unknown command "vid_stretch_by_2"
Unknown command "vid_config_y"
Unknown command "vid_config_x"
Unknown command "_vid_default_mode_win"
Unknown command "_vid_default_mode"
Unknown command "_vid_wait_override"
Unknown command "vid_nopageflip"
FindFile: can't find autoexec.cfg
couldn't exec autoexec.cfg
3 demo(s) in loop
Playing demo from demo1.dem.
PackFile: ./id1/pak0.pak : demo1.dem




the Necropolis
PackFile: ./id1/pak0.pak : maps/e1m3.bsp
PackFile: ./id1/pak0.pak : progs/player.mdl
PackFile: ./id1/pak0.pak : progs/eyes.mdl
PackFile: ./id1/pak0.pak : progs/h_player.mdl
PackFile: ./id1/pak0.pak : progs/gib1.mdl
PackFile: ./id1/pak0.pak : progs/gib2.mdl
PackFile: ./id1/pak0.pak : progs/gib3.mdl
PackFile: ./id1/pak0.pak : progs/s_bubble.spr
PackFile: ./id1/pak0.pak : progs/s_explod.spr
PackFile: ./id1/pak0.pak : progs/v_axe.mdl
PackFile: ./id1/pak0.pak : progs/v_shot.mdl
PackFile: ./id1/pak0.pak : progs/v_nail.mdl
PackFile: ./id1/pak0.pak : progs/v_rock.mdl
PackFile: ./id1/pak0.pak : progs/v_shot2.mdl
PackFile: ./id1/pak0.pak : progs/v_nail2.mdl
PackFile: ./id1/pak0.pak : progs/v_rock2.mdl
PackFile: ./id1/pak0.pak : progs/bolt.mdl
PackFile: ./id1/pak0.pak : progs/bolt2.mdl
PackFile: ./id1/pak0.pak : progs/bolt3.mdl
PackFile: ./id1/pak0.pak : progs/lavaball.mdl
PackFile: ./id1/pak0.pak : progs/missile.mdl
PackFile: ./id1/pak0.pak : progs/grenade.mdl
PackFile: ./id1/pak0.pak : progs/spike.mdl
PackFile: ./id1/pak0.pak : progs/s_spike.mdl
PackFile: ./id1/pak0.pak : progs/backpack.mdl
PackFile: ./id1/pak0.pak : progs/zom_gib.mdl
PackFile: ./id1/pak0.pak : progs/v_light.mdl
PackFile: ./id1/pak0.pak : progs/flame2.mdl
PackFile: ./id1/pak0.pak : progs/flame.mdl
PackFile: ./id1/pak0.pak : progs/zombie.mdl
PackFile: ./id1/pak0.pak : progs/h_zombie.mdl
PackFile: ./id1/pak0.pak : progs/w_g_key.mdl
PackFile: ./id1/pak0.pak : progs/ogre.mdl
PackFile: ./id1/pak0.pak : progs/h_ogre.mdl
PackFile: ./id1/pak0.pak : progs/wizard.mdl
PackFile: ./id1/pak0.pak : progs/h_wizard.mdl
PackFile: ./id1/pak0.pak : progs/w_spike.mdl
PackFile: ./id1/pak0.pak : progs/demon.mdl
PackFile: ./id1/pak0.pak : progs/h_demon.mdl
PackFile: ./id1/pak0.pak : progs/g_nail.mdl
PackFile: ./id1/pak0.pak : maps/b_shell1.bsp
PackFile: ./id1/pak0.pak : maps/b_bh25.bsp
PackFile: ./id1/pak0.pak : maps/b_bh10.bsp
PackFile: ./id1/pak0.pak : progs/g_shot.mdl
PackFile: ./id1/pak0.pak : maps/b_shell0.bsp
PackFile: ./id1/pak0.pak : maps/b_rock0.bsp
PackFile: ./id1/pak0.pak : maps/b_nail1.bsp
PackFile: ./id1/pak0.pak : progs/armor.mdl
PackFile: ./id1/pak0.pak : maps/b_nail0.bsp
PackFile: ./id1/pak0.pak : maps/b_rock1.bsp
PackFile: ./id1/pak0.pak : progs/g_rock.mdl
PackFile: ./id1/pak0.pak : progs/invisibl.mdl
Sys_Error: Globals are missaligned


For some reason it barfs on a native compile with -m68881 ...  -msoft-float seems OK, although I guess since none of this is real it really doesn't matter.

corpsicle

Yes! 68000 and 68882 support plz! ^_^;;;;;

neko68k

#90
@neozeed
I got all the colors to work. Some sick TVRAM hacks. You should have a look.


neozeed

Quote from: neko68k on September 08, 2016, 04:54:06 PM
@neozeed
I got all the colors to work. Some sick TVRAM hacks. You should have a look.



Damn, that's pretty amazing!  I never thought it'd make it past the null version, but you've taken it that last mile!

Totally awesome!

All kinds of other 68000 based systems had DooM, I wondered why the x68000 didn't have one.  Even the 68000 based Jaguar had one.  Still it's pretty great to see!

neko68k

I dunno why it never happened in the old days. It seems like the scene was really drying up between 96 and 99. It may have just not been lucrative or maybe too unknown.

I've been wanting to do this for years. You made the breakthrough on building and running it. I figured it'd be pretty quick work to get an unoptimized version running. I was right. :)

kamiboy

#93
DOOM was a big deal in the west, not Japan. if the X68000 had been sold in the west a version of DOOM would have been all but guaranteed.

I suppose the PC-98 got DOOM because the machine was so close to IBM PC's that porting it took almost no effort, and so even with very few sales it would still net a profit.

neozeed

Quote from: kamiboy on September 09, 2016, 12:00:11 AM
DOOM was a big deal in the west, not Japan. if the X68000 had been sold in the west a version of DOOM would have been all but guaranteed.

I suppose the PC-98 got DOOM because the machine was so close to IBM PC's that porting it took almost no effort, and so even with very few sales it would still net a profit.

I suppose when you think about 1993, the year the x68030 came out, it was a new-ish machine for the timeframe of when DooM launched.  But the cost of licensing & porting may have simply been too much.   Sad to say but Intel cleaned Motorola's clock, and the 88000 & PowerPC just couldn't compete.  On the PC side, with the launch of Windows 95, it was pretty much over for the PC-98 as well.

I have a PC-98, I haven't been messing with it as much as I should, but I did finally buy a floppy drive, and a pack of diskettes, and I got DooM to install! .. it crashes the second you press any key.  Another platform I know next to nothing about hardware wise...

neozeed

Quote from: neko68k on September 08, 2016, 11:56:42 PM
I dunno why it never happened in the old days. It seems like the scene was really drying up between 96 and 99. It may have just not been lucrative or maybe too unknown.

I've been wanting to do this for years. You made the breakthrough on building and running it. I figured it'd be pretty quick work to get an unoptimized version running. I was right. :)

Ever since I ported Quake 2 to MS-DOS, I've been wanting to do something off the wall... I'll have to write about it, although in the 80/20 rule, you really did 80% of the work, lol


neko68k

Quake 2 for DOS huh? I didn't know that was you. Great work.

I just pushed an update to the key handling. Pretty much everything of value is mapped. Fn-keys, all the alphanumeric, some symbols(+, -, <, >), basically everything needed to play the game properly. Reduced the number of loops there too, so that's nice. I might add the other three XFn keys and the two OPT keys later... I'm sick of staring at tables of numbers for tonight.

kamiboy

Most important thing for DOOM control wise is joypad support. I hate the fact that it is not easily playable using a controller in DOS. I hate playing anything using a keyboard. If you want easy joypad support I an upload the code I wrote for my game project.

It will be hard to map all essential functions of the game to two buttons, but if interaction and strafing is mapped to button A, and shooting to button B while running is toggled on all the time by default that should suffice for the most part.

neozeed

Quote from: neko68k on September 09, 2016, 12:50:18 PM
Quake 2 for DOS huh? I didn't know that was you. Great work.

I just pushed an update to the key handling. Pretty much everything of value is mapped. Fn-keys, all the alphanumeric, some symbols(+, -, <, >), basically everything needed to play the game properly. Reduced the number of loops there too, so that's nice. I might add the other three XFn keys and the two OPT keys later... I'm sick of staring at tables of numbers for tonight.

Cool, I'll get off my butt and merge later tonight or tomorrow.

First it was Quake 1 for MS-DOS & OS/2 were my babies... Then after some asking I did QuakeWorld, I never played it before as I hate online games, since I suck and never got involved.  Oddly enough I had QuakeWorld running on the first shot, since it's basically Quake as far as the system support stuff is involved.  Mara'akate has been after me for some time to do Quake II, but I just kept putting it off until all those servers in the Netherlands shuttered basically killing off QuakeWorld.  If I can be bothered to find one of those Vodoo cards, maybe Quake 3 could be a possibility.  I may want to see how a software GL may or may not handle it, now that we live in the era of 3Ghz processors maybe it's practical.

But just like all the others, I just seem to get the ball rolling, and others that know a shit tonne more about the platform fill in the gaps, which TBH is totally fine by me.  I'm just happy to have kicked that rock off in motion.

I should verify it with Linux or SunOS in Qemu, but I built a stock GCC 1.42 i386-sysv -> m68k-3b1 cross compiler, and it messes up the endian order too.  I guess points for consistency.  At least with DooM, it's a single file that is trivial to churn out some assembly, although I guess since I have to run the assembler, and linker under emulation, I could just run the compiler as well, maybe save the pre-processor and driver as native executables.  I need to play more with some 68881 stuff and some better test programs to know if this thing is actually doing anything worth a damn.  The default target for the x68000 is a stock 68000 with no FPU.  I don't get why there is the exception with the straight x68000 with more RAM.  I may have to re-build a compiler that simply cannot generate any 68010 or higher instructions, and force the assembler as well, in case it's getting cute somewhere.

part of me wants to get musashi running as the 68000 emulation core in run68, the other half wants to spend more time, and break down Quake1/QuakeWorld with GCC 1.40 / EMX to get a known 'good' state and try again.  I don't think MAME has x68030 emulation, to say tell it you have a 68040 running at 200Mhz or something crazy assuming the ROMS dont go mad.

neozeed

Quote from: kamiboy on September 09, 2016, 08:57:57 PM
Most important thing for DOOM control wise is joypad support. I hate the fact that it is not easily playable using a controller in DOS. I hate playing anything using a keyboard. If you want easy joypad support I an upload the code I wrote for my game project.

It will be hard to map all essential functions of the game to two buttons, but if interaction and strafing is mapped to button A, and shooting to button B while running is toggled on all the time by default that should suffice for the most part.

I absolutely detest controllers and DooM, but for the sake of people who do like them, plus a nice 'skeleton' to show how to program them, I'm 100% all in on that!

I'm guessing you would have to slap the keyboard for weapon change, or give up strafing which means basically dying a lot in DooM.  It's been forever since I played DooM on the 32x, or any other console, but I don't recall it being "fun" although I bought it simply for the novelty aspect.

kamiboy

There is a way to do use more than two buttons on the X68000. If you use a FM Towns pad certain games will recognise the start button, but I think it is just toggling both A and B buttons at the same time for start, so not sure. It works in Akumajo.

In any regard, yes, for only two buttons using the keyboard for weapon change is necessary. But you do that rarely enough that it is not a big issue. But some people either do not have a keyboard for their X68000 or do not have one hooked up all the time, so thinking of joypad support is important.

I'll upload my code when I get home.

neozeed

Quote from: kamiboy on September 09, 2016, 09:34:03 PM
There is a way to do use more than two buttons on the X68000. If you use a FM Towns pad certain games will recognise the start button, but I think it is just toggling both A and B buttons at the same time for start, so not sure. It works in Akumajo.

In any regard, yes, for only two buttons using the keyboard for weapon change is necessary. But you do that rarely enough that it is not a big issue. But some people either do not have a keyboard for their X68000 or do not have one hooked up all the time, so thinking of joypad support is important.

I'll upload my code when I get home.

Maybe a second joy pad?  Or a combination like hold a+b and up / down to cycle?

Now that we have stuff building I may take another stab with the sharp compiler, but if it's still giving errors on the combined sources.... Yuck.

kamiboy

Here is the pad code. Should be easy enough to figure out how it works from the code, but feel free to ask if any qustions should crop up.

neozeed

Quote from: kamiboy on September 10, 2016, 01:03:14 AM
Here is the pad code. Should be easy enough to figure out how it works from the code, but feel free to ask if any qustions should crop up.

cool, it looks sane enough.  I was also thinking with the genesis, there was A/B/C + start.  Or if you had the 6 button controller, which really is 7 buttons..

http://www.digitpress.com/library/manuals/32x/doom.pdf

This is going to feel a little clunky no matter what I guess....

corpsicle

"Most important thing for DOOM control wise is joypad support"

*cry*

kamiboy

Well, in my eyes nothing is more clunky than playing on a keyboard. Can you tell that I am not a PC gamer yet? Pasocoms do not count, of course, because on there any game worth its salt has joypad support.

neozeed

I just found out I have to be on the road this weekend. Sigh.

I merged the code, and did a build.  It's all up on the sourceforge pages now.  I went ahead and hit the publish button on my blog as well..  Neko68k did a fantastic job with the port! 

I'll try to do something with the joy pad, I'll have to pick one up to make sure it's doing the right thing if even in emulation.

It's so cool not just watching, but playing.

I think the access libc call for detecting the wads is not working right, I'll have to get a bunch more wads and try it.  Also the freedoom levels, except m1e1 won't play on vanilla do it just needs replacing.

Quake built with gcc 1.40 fails on NT in the apparent same place as the x68000....   Very strange.   I can't get djgpp 1.3 to link it correctly..  But it would be interesting to verify.  It's based on gcc 1.38.

neko68k

Nice writeup. I'm taking a weekend break. I'll get back to it on Monday. Here's the general plan.

I need to write a key mapping program. It isn't quite mapped 1:1 for some of the additional keys on the X68k keyboard and it can make changing the keys in doomrc kind of unclear. I'd like to just fix it up in Doom and get rid of the translation table and the ASCII table. It isn't really necessary now that I know how it all works internally and this is never getting pushed upstream so who needs all that portability cruft.

I'm still interested in porting over Amiga optimizations. Someone on IRC suggested I check out Doom Attack. The source is much less unruly than ADoom. It'll take some work to get it all going but it will help a lot. Still 030 minimum but probably not some nonexistent 100MHz machine.

I'll also take a look at getting joystick going. Hooking that up should be easy, even for the MD controllers.The controls for 2 button will be less than ideal though. I guess while I'm in there I can do mouse also though that'll have to be tested on hardware. The mouse emulation is a little weird and mouse in Doom is a little weird too :)

I dunno about the WAD stuff. It runs the first 3 episodes of the Ultimate DooM WAD for me. Of course, ep 4 is missing because it isn't supported and I haven't check but I expect the Doom 2 IWAD won't work either. 1.10 is a very old version of Doom. I haven't tried any PWAD's yet.

It's really unfortunate that low detail mode is totally broken. That seems to net a huge performance increase. Maybe it'll get working with the Amiga stuff.

I need to do some digging/testing to find out why the first element of each row of the palette is either black or invisible. I don't think my image loader has this problem. They switch to one or the other with the intensity bit but it isn't really making sense why it's not drawing the color. While I was working on it, at one time some purple color ended up in color 0 and that actually got drawn on the screen. ~shrug~ That TVRAM hack is cool and it was a good learning experience but it's slow and I think it's unnecessary.

kamiboy

For the Sprite palette the first entry of each palette row not being a colour, but see through is normal. That is how that palette works. I am not sure which palette you are using, but it might function the same.

neko68k

I'm using GVRAM. I need to check but I'm fairly certain that the image viewing stuff I wrote previously doesn't have this issue and I have seen for sure that it worked like I want it to, if minimally, when I was porting the palette stuff in Doom.

neko68k

Fixed GVRAM colors. GVRAM0 and GVRAM1 must be enabled in vidcon register 2. Pushed the update to my repo.


*vidcon_r2 = 0x23;

neko68k


neozeed

I have zero knowledge of programming the YM2151 ... is it general MIDI?

Anyways I found...
Qmus2mid.c

in https://www.doomworld.com/3ddownloads/ports/middoomv.zip

It's an early port that apparently can play the MUS files in the wads as MIDI.  I haven'b built it or tried just yet.  Just bored on the train.  8)

kamiboy

My understanding of sound hardware might leave a lot to be desired but even I can answer that. An FM module is NOT midi, they are completely different things. Midi plays back ROM samples, but an FM module is basically a programable sound generator. You configure the registers for a given channel to produce a certain kind of synth sound, then you somehow you tell the FM to generate the programmed sound on said channel.

If you want to use midi with DOOM you will need to send General Midi commands to an external midi module. The way that works on an X68000 is through the use of a midi interface card, such as the official CZ-6BM1. You would either have to figure out hot to program that baby yourself, or find out how to use a third party library such as Z-Music, which I imagine will make things a LOT easier.

I do not remember whether the original DOS version of DOOM had GM, GS or LA midi support or not. If it did then you can make that work on the X68000 and the music will sound 100% accurate to the DOS version of that soundtrack. If not then my guess is it will sound pretty terrible.

One day in the far future I will have to look at all this audio stuff as well. But sound hardware is a scary big black box for me right now, so I avoid it.

kamiboy

Ok, I just read a bit about the DOOM MUS files and it seems that they are basically just midi files. I assume they are GM, which means the best way to play them on an X68000 is as I described, through an external midi module through a interface card. Try to figure out how Z-music works for midi playback, or better yet put music on the back burner and focus on other things.

neko68k

I was planning on converting mus 2 mid then using an existing music driver. I hadn't decided on which driver but I guess zmusic is as good as any. The MIDI card doesn't really look that tough to program on it's own though. You set up a timer and push midi commands to a register and it buffers some number of them and processes them based on the timer. There are some details in Outside X68000.

Networking almost works, btw. It kind of seems like the network stack on the X68 is a little too limited to pull it off. I still have some things to try but that plan might be dead in the water :(

neozeed

I reverted a tonne of stuff back to English for GCC.  No binaries yet, I need to hammer the rest, although I did change quite a bit, there is still so many more it seems.....

neko68k



kamiboy

We are doomed.

Single digit FPS even at 40mhz. Damn, no wonder Intel CPU architecture took over the computing world. At 40mhz DOOM would run buttery smooth on even 386.