more gcc insanity!

[neozeed]

I was busy with work today but I did find an hour to play some more, and re-do the source from DOSdoom as a reference, and now it loads up without crashing on XM6 in 68030 mode with 12MB of ram! .... From there it'll complain about the Demo being from a different game.

No video, no keyboard even! .... I had to remove the supervisor code otherwise it just locks.

I need to play more with the compiler to figure out why I can't directly call MALLOC, I don't like having to hex edit the object files, but I did make it so now I only have to edit a single file (missing.o)

[neko68k]

i_system.c won't build for me and I'm not really sure what you were trying to do there. This bunch of stuff exists at file scope and, well, it doesn't make sense

Code Select Expand


/* */
/* I_GetTime */
/* returns time in 1/70th second tics */

from toplev.c  / GCC 1.42
#ifdef __human68k__
  return ONTIME ()* 10000;
#else
#ifdef USG
  times (&tms);
  return (tms.tms_utime + tms.tms_stime) * (1000000 / HZ);


[edit]
I mean, I can comment that out. Just not sure if you were meaning to do something there or if its just leftovers.

[neozeed]

i_system.c won't build for me and I'm not really sure what you were trying to do there. This bunch of stuff exists at file scope and, well, it doesn't make sense

Code Select Expand


/* */
/* I_GetTime */
/* returns time in 1/70th second tics */

from toplev.c  / GCC 1.42
#ifdef __human68k__
  return ONTIME ()* 10000;
#else
#ifdef USG
  times (&tms);
  return (tms.tms_utime + tms.tms_stime) * (1000000 / HZ);


[edit]
I mean, I can comment that out. Just not sure if you were meaning to do something there or if its just leftovers.

I meant to put that block in comments....   I was re-diffing my changes to GCC, when I saw in toplev.c how the x68000 port of GCC figures out how much time it spent doing something, which for the sake of quickly porting I don't care about, but I saw the ONTIME  system call, so I wanted to remember it.... which seemed like a good plan, but I didn't wrap it in /*** ****/ .....

Also I just re-diffed gcc 1.42 vs 1.30 x68000 which really is 1.42, and I was thinking of putting all the errors and warnings back in English.......  Yeah i know that won't win me any fans.

[neko68k]

That'd sure be nice. I'm trying to get it built with my gcc2 toolchain. I'll keep you posted.

[neko68k]

Bus error...

And GDB runs out of memory trying to load a debug build




[edit]
it looks like i_main.o never winds up in the final binary. If I make sure it gets linked(not part of doom.a) with doom.x I get 'undefined reference to ___main'. I've tried all kinds of combinations of stuff and I don't really know what to do at this point.

[neozeed]

[edit]
it looks like i_main.o never winds up in the final binary. If I make sure it gets linked(not part of doom.a) with doom.x I get 'undefined reference to ___main'. I've tried all kinds of combinations of stuff and I don't really know what to do at this point.

Is this building with GCC 2?

is it the 2.4 thing or the 2.9?

I'm wondering if 1.30/1.42 works with GDB?

Also where did you get your GDB from?  And what libraries are you linking against?  I tried that lib32 thing, but it bombs out at various places, I had best luck with the SHAPR/Hudson includes/libs although there are certainly some corruption in the headders.. possibly the libs too.  I should copy them myself out of the disk images to see if the images are actually corrupt.  Otherwise I'll have to see if I can yahoo a copy of SHARP/Hudson C compiler.... for something less than $100 USD.

[neko68k]

Yeah gcc2. It reports 2.6.3. It might not be the most recent. I remember is being a bit of a mess to put together in the first place. I can't remember where I got my libs from anymore. I'm fairly certain I've linked against them before. I did try it with the XC libs and had the same result. 1.30/1.42 isn't working for me right now. I haven't really investigated the issue. What versions of HAR and HLK are you using? I'd like to try using the same and see if it matters.

I think GDB will probably work with the 1.30/1.42. There are two different versions here. 43 works well but it doesn't tell you what method the crash happened in. 060 tells you what method crashed but it has some issues with crashing itself. Kind of a mixed bag :/

[neko68k]

Fixed my 030 problem. You cant use the XM6i memory option and boot human68k. Only for NetBSD.

Anyway. Your build goes a lot further in 030 mode. It hangs the machine completely after the ST_Init: line. The CPU actually stops.

[edit]

Fixed my gcc toolchain too. Had to do some finagling with the makefile and your batch files but I can build a working executable now.



[editedit]

Oh yeah, I almost forgot. I don't have any problems using whatever malloc I have hooked up. I can't remember if its malloc() or _dos_malloc()/MALLOC() but with my setup it doesn't complain about it.

[neozeed]

I'm using HAS 3.09  it says..
X68k High-speed Assembler v3.09 Copyright 1990-94 by Y.Nakamura

The linker I'm using is actually the hlk301
X68k SILK Hi-Speed Linker v3.01 Copyright 1989-94 SALT

Code Select Expand

03/11/1987  12:00 PM             4,352 AR.X
28/07/1994  11:24 PM            52,614 has.x
24/07/1994  10:18 PM            28,486 hlk301.x
24/07/1994  10:18 PM            28,486 LK.X

I noticed that both GDBs actually runs much better in 68000 mode.. they do take FOREVER to load symbols, even running with no waiting. I'd hate to do this on real hardware!

Code Select Expand

GDB for X680x0 (Human68k) version 0.90
based on GDB 4.4, Copyright 1991 Free Software Foundation, Inc...
(gdb) r

Starting program: C:/crusg/doom.x
                            DOOM Registered Startup v1.10                           
V_Init: allocate screens.
M_LoadDefaults: Load system defaults.
Z_Init: Init zone memory allocation daemon.
W_Init: Init WADfiles.
adding ./doom.wad
===========================================================================
                 Commercial product - do not distribute!
         Please report software piracy to the SPA: 1-800-388-PIR8
===========================================================================
M_Init: Init miscellaneous info.
R_Init: Init DOOM refresh daemon - [                          ].....
InitTextures
InitFlats............
InitSprites
InitColormaps
R_InitData
R_InitPointToAngle
R_InitTables
R_InitPlanes
R_InitLightTables
R_InitSkyMap
R_InitTranslationsTables
P_Init: Init Playloop state.


Exceptional Abort by address error
By Memory Access of 0x13ae77
  at 0x13cc04 <R_InitSpriteDefs+194>:  move.l (a0),-16(fp)

system status = I/N=I R/W=R FC=1

0x13cc06 in R_InitSpriteDefs
    ()
(gdb) quit

The program is running.  Quit anyway? (y or n)

So now I have a location that makes the 68000 unhappy, meanwhile switching to 030 mode, and it runs fine. :\

I started taking some assembly files from libc32, and I think I'm actually able to enter supervisor mode now, as I did get the text mode to jump.  I'm still 1000000% uncertain how to do anything graphic wise on the x68000.

I'm going to update a binary package of my cross build tools for Windows.  run68k isn't perfect but it is doing a great job of at least running HAS/HLK on Windows.

Here is the binary package of what I'm using to cross compile.

https://sourceforge.net/projects/gcc-1-30-x68000/files/x68000-gcc130.7z/download

[neko68k]

Awww shit

https://youtu.be/WHrFUizISPs

[neozeed]

Awww shit

https://youtu.be/WHrFUizISPs

WOW... ok now you gotta give me a diff or something... !!!!!!!!!!!!!!!!!!

[kamiboy]

Holy balls, you actually have something being drawn on screen? That is phenomenal, congrats.

Fixing up the graphics should be easy enough.

[neozeed]

Holy balls, you actually have something being drawn on screen? That is phenomenal, congrats.

Fixing up the graphics should be easy enough.

I sure hope so!  I'm going crazy here to see what the deal was/is....

[neko68k]

I'm not really sure if you want to merge this with your repo. I am using different libs, using the batch files a little differently, different linker/archiver/assembler versions than you... It works a treat on the emulation with my HDS. I'm happy to share that image if you'd like a copy. It will probably need some small path changes in autoexec.bat and you'll need to enable some emulation options(I think just Nereid 16MB RAM).

Repo

As far as work to be done is concerned:

• The palette is wrong, I haven't checked its format yet but I have some macros handy that'll convert various formats to the x68000 5551 format.
• The actual in-game display is wrong. It looks like it's writing to a different sized buffer that doesn't like being copied directly to screens[0]. For example, copying a 320x200 buffer to 512x512. There are a couple of #defines in doomdef.h for this but they dont seem to have an effect on the actual raycasting side of things. Menus and the HUD and stuff should work though
• The keyboard isn't hooked up at all. This should be pretty easy.
• MIDI is probably possible. I thought a long time ago about this... It is possible to convert the Doom music to regular MIDI files and there are drivers that'll just play those with a load to ram and calling a user trap.
• Sound will probably be a mess. It'll be necessary to mix effects(if theres even enough headroom for more than one sample) then convert them to IMA ADPCM and DMA the result to the MSM.

[neko68k]

Fixes:

• Palette is sort of working. It's grayscale and I don't know why. It's probably something simple.
• In-game display has been fixed.

Problems:

• Transparent color... Probably easy to work around.
• Everything else.

[kamiboy]

What sort of frame rate are you getting? More than 1fps?

[neozeed]

I'd love a HD image or even a zip..  Sourceforge let's you host files..
-edit

I found patch level 30 of gcc 2.6 something

http://www.kyagroup.com/soft/gcc/

There is some source/patch fragments to a 2.95 .... does x68000/HumanDOS have anything like long filename support?  I'm really a total n00b at this kind of thing.

It's great looking at all the source changes you have in there, I am missing like... everyhthing.

I also found some more library stuff..

http://shq.dyndns.org/x68pub/x68tools/UNIX/GCC/c_pack.zip

along with patches to the gcc 1.30 thing!

So much more work to do........

[neozeed]

What sort of frame rate are you getting? More than 1fps?

It's wAy way way way ahead of the game to even go down that road, but the Atari Jaguar DooM has a bunch of assembly optimizations... and it's 68000 based as well... but first step is to basically get it kind of running before looking at the i386 optimizations and borrowing the equivalents from the Jaguar.  I know it's going to be fun going from GAS syntax to HAS.....

[neozeed]

neko68k if you can upload the libs & includes you use at least... it'll help me a bunch.... for some reason when I try the lib32 stuff I found, it doesn't malloc memory... sigh back to square one for me. 

[kamiboy]

Human68k does support longer file names than the traditional 8.3. I cannot remember how long though. If I remember correctly there is a hard limit a few characters longer than 8, but not too many.

[neozeed]

Human68k does support longer file names than the traditional 8.3. I cannot remember how long though. If I remember correctly there is a hard limit a few characters longer than 8, but not too many.

Oh nice.

Well.. I tried and failed miserably to get GCC 2.95 running.. the later builds just don't work and crash.  The older ones can't seem to find my include path, or lib path.. or temp path on top of that.  Ill have to wait for neko to upload a disk image, or even a zip of his GCC setup with setup scipts so I can make heads or tails of it.... There is a source patch to the first release of GCC 2.95 that does patch into the source cleanly so I have some hope of being able to build a cross compiler, in the style of how I did GCC 1.30 to at least get GCC native, and use the assembler/llinker via run68....

So close... so far away.

[kamiboy]

So close that I can taste the shores of hell on my tongue. It taste like Cacodemon.

From Wiki:

Human68K does not support the VFAT long filenames standard of modern Windows systems, but it supports 18.3 character filenames instead of the 8.3 character filenames allowed in the FAT filesystem. Human68K is case sensitive and allows lower case and Shift JIS encoded Kanji characters in filenames, both of which cause serious problems when a DOS system tries to read such a directory. If a X68000 user restricts himself to use only filenames according to the 8.3 characters scheme of DOS, using only Latin upper case characters, then a disk written on the X68000 is fully compatible with other Japanese standard platforms like e.g. the NEC PC-9800, the Fujitsu FMR and FM Towns computers. The Japanese standard disk format used by the X68000 is: 77 tracks, 2 heads, 8 sectors, 1024 bytes per sector, 360 rpm (1232 KiB).

[neozeed]

So close that I can taste the shores of hell on my tongue. It taste like Cacodemon.

From Wiki:

Human68K does not support the VFAT long filenames standard of modern Windows systems, but it supports 18.3 character filenames instead of the 8.3 character filenames allowed in the FAT filesystem. Human68K is case sensitive and allows lower case and Shift JIS encoded Kanji characters in filenames, both of which cause serious problems when a DOS system tries to read such a directory. If a X68000 user restricts himself to use only filenames according to the 8.3 characters scheme of DOS, using only Latin upper case characters, then a disk written on the X68000 is fully compatible with other Japanese standard platforms like e.g. the NEC PC-9800, the Fujitsu FMR and FM Towns computers. The Japanese standard disk format used by the X68000 is: 77 tracks, 2 heads, 8 sectors, 1024 bytes per sector, 360 rpm (1232 KiB).

Oh crap. CaSe SeNSiTiVe?  Ugh.  that may explain some weirdness I've seen, but it still doesn't help my memory issues................  18.3 well that's a nice change!

[neko68k]

Ok, so...

Yeah it does longish filenames. There is a program that allows more, TwentyOne. It allows, unsurprisingly, 21 characters. It also allows things like 'dot' files, i.e '.dashrc'. That wiki article is a little off. It isn't case sensitive by default though TwentyOne is able to enable that feature.

I do know about all the stuff on the shq mirror. It is mirrored locally. The link above takes you to that mirror. A lot of my toolchain stuff came out of there.

Speaking of my stuff, here is my HDS. You'll need to boot this from SCSI0. The autoexec.bat will need to be slightly modified. All lines that refer to h:\temp may be need to be different depending on how many other drives you have set up. You can see what drive it was assigned by the driver by paying attention during boot. Theres probably an option to specify one but I never bothered.

Also in the emulator you will need to enable Nereid with 16MB of ram. The temp directory goes in a RAMdisk in Nereid RAM.

This project is in a:\proj\x68000-doom. That source is old though, I build on a host disk with WINDRV. It's much faster. There is a binary that works in a:\proj\x68000-doom\x68k There's a whole pile of other stuff on that disk.

As for performance, right now it _might_ be barely playable at 100MHz. I'm hooking up keyboard today so I'll let you know.

[neko68k]

It moves! Very slow. This is 100MHz. It runs pretty well with VM turbo mode enabled.

https://www.youtube.com/watch?v=GpD0ucnUIkI

[neozeed]

Very interesting we are both on GCC 1.30/1.42 ...

Code Select Expand

gcc version 1.30 Tool#2(X680x0) patchlevel 5
gcc_cpp -+-s:131072 -v -undef -D__GNUC__ -Dmc68000 -Dhuman68k -DHUMAN68K -DMARIKO_CC -Dmariko_cc -D__mc68000__ -D__human68k__ -D__HUMAN68K__ -D__MARIKO_CC__ -D__mariko_cc__ hi.c e:\temp\hi.cpp
gcc_cc1 -+-s:131072 e:\temp\hi.cpp -quiet -dumpbase hi.c -fhuman -version -o e:\temp\hi.s
has -e -w -u -i a:\USR\INCLUDE e:\temp\hi.s -o hi.o
a:\usr\bin\hlk.r -v hi.o a:\USR\LIB\libc.a a:\USR\LIB\libgnu.a


And I think the key bits are here:

Code Select Expand


SET include=a:\USR\INCLUDE
SET GCC_AS=a:\usr\bin\has060.x
SET GCC_LINK=a:\usr\bin\hlk.r
SET lib=a:\USR\LIB

SET HAS=-m 68030 -u -w -i a:\usr\include
SET SILK=-x -l
SET GCC_OPTION=LFIOAMP


I found patch set 4 & 5, Ill have to see if I can apply them, and integrate these build settings into my stuff.  I have a makefile that can build and link without any manual steps too.. I have to run today, but Ill get something done.  It was incredible to fire doom.x though..!

mine freaks out doom.wad vs DOOM.WAD ... sigh.  But yeah I could rebuild your project files with my makefile thing and got a working EXE so that works at least.

Super awesome on the video and keyboard stuff!  We can port other far more impractical stuff!

Was there ever anything like wattcp for x68000?

[neko68k]

TCP/IP is basically BSD sockets. It should be dead easy to get it working. https://argrath.ub32.org/x680x0/internet.html

[kamiboy]

Huzzah, it lives! But at what cost? Single digit frame rate at 100mhz is quite dire. Maybe a god level coder could optimize it to be playable on a high end 68030, but it will always be nothing more than a novelty.

Hopefully the work you did on the build toolchain can benifit future game development on the X68000 in the future.

[neozeed]

Huzzah, it lives! But at what cost? Single digit frame rate at 100mhz is quite dire. Maybe a god level coder could optimize it to be playable on a high end 68030, but it will always be nothing more than a novelty.

Hopefully the work you did on the build toolchain can benifit future game development on the X68000 in the future.

Yes hopefully...   I need to purge the disk image as mine just hopelessly gives me corrupt results, instead of a native binary that "works" ....  It's very interesting to see its actually gcc 1.42 hiding as 1.30 but compiled by 2.6 .... 

Once I get something more reproducible it'll open a little more options, but gcc 1.42 is crazy old... the source patches for 2.95 don't give a directory that can actually compile some key stuff is left out.  I'm no gcc expert by any stretch,  but I think the c preprocessor from 2.x can work on 1.x so maybe we won't have to lean on uncrustify for converting c++ comments to k&r style.

Actually I was amazed to see the null version run on emulation,  but with neko68k filling in some of the much needed x68000 bits it makes the platform much more accessible!

[kamiboy]

I don't know much about build tools, or GCC in general. But what advantages would your build environment provide over the one by Lydux which is based on a newer version of GCC?

I assume you cannot compile doom using Lydux's toolchain, but why? I do remember him talking about his standard C library implementations being buggy, and incomplete, so that might be it?

[neozeed]

I don't know much about build tools, or GCC in general. But what advantages would your build environment provide over the one by Lydux which is based on a newer version of GCC?

I assume you cannot compile doom using Lydux's toolchain, but why? I do remember him talking about his standard C library implementations being buggy, and incomplete, so that might be it?

Well the Lydux libraries leave a LOT to be desired... mostly that they don't work.  I tried to fix some time functions, and it ended up just becoming a mess.  I had tried to do a 'null' doom to see what it would do, and even putting a printf 'hi' in the start of main didn't work.  There is other fundamental issues going on in there.  Also the Lydux tool can't use the x68000 object format so you can't just switch to a different libc, if the issue was even revolving around libc.  Sure there was some native GCC versions to the x68000 but I never could make heads or tails of them.

So switching gears I went to find out how the native stuff worked, and here we are.

The Lydux tools died, and with no debugging at all it's impossible to say what on earth is going on.  There could be a whole host of issues, and I'm not even sure where to begin.  But with a native compiler and thanks to run68 being able to run the assembler and linker on Windows (they are coded in assembly, so porting to C would take effort...) is a big help.  It's easier to deal with crashes, and memory corruption when you fire up the emulator to run a single process (a-la run68 to assemble  or link only), where running the toolchain in an emulator like xm6 suffers the same problems as trying to write software on MS-DOS, which is an unstable environment + unstable testing + unstable tools means lots of issues.  SO for me, being able to compile outside of the emulator is a MASSIVE boon.



So yeah, the only issue I have is with m_fixed.c, which as my host CPU is little endian, but the 68000 is big endian.  And I took the source dump for GCC as is, so it doesn't know it needs to swap bit field operations to work.. So you end up with this:

Code Select Expand

#-       .dc.l $00000000,$40f00000
#+       .dc.l $40f00000,$00000000

But otherwise, it's so much faster, and easier to edit with native tools, and not worry about having to reboot the VM constantly to compile and test, only to test so it's much nicer. ...  Not to mention it's nice to compare what is going on with a native vs cross build, which is how I found the issue with m_fixed .....

I'm amazed to see the system stuff Neko68 has put in, I never expected to actually be able to see anything on the screen!

[kamiboy]

By the way, I tried to copy your doom.x from the other thread over to my Compact for testing on actual hardware. Alas I fiund out that the SCSI CD drive I bought cannot read CD-RW discs, so no dice. I have no other easy way of getting big files over to my machine since it uses an internal CF.

If you still want it tested I could try burning a CD-R. I really need a better way to transfer files...

[neko68k]

By the way, I tried to copy your doom.x from the other thread over to my Compact for testing on actual hardware. Alas I fiund out that the SCSI CD drive I bought cannot read CD-RW discs, so no dice. I have no other easy way of getting big files over to my machine since it uses an internal CF.

If you still want it tested I could try burning a CD-R. I really need a better way to transfer files...

There really isn't much to test. It runs like a dog. There are some minor visual issues. The keyboard doesn't work that great as it is. It's based on a very very old version of doom too which kinda stinks.

Ultimately it will require an 030 bare minimum in low detail mode. It'll never be playable on, say, an XVI. Even a Red Zone might not hack it.

I'm starting to work on porting over optimizations from adoom for the Amiga. It should make a huge difference. I'd also like to port all these changes forward to something like chocolate doom, but that's for later.

[neozeed]

I totally missed that gcc2 was on your disk along with gcc .... the first thing I found is that in the bin directory there is a copy of g2as & g2lk that are too old, renaming (or deleting them) lets the ones in the \usr\bin fall next into the path and they seem better......

But yeah, no ___main to link to.

[neozeed]

By the way, I tried to copy your doom.x from the other thread over to my Compact for testing on actual hardware. Alas I fiund out that the SCSI CD drive I bought cannot read CD-RW discs, so no dice. I have no other easy way of getting big files over to my machine since it uses an internal CF.

If you still want it tested I could try burning a CD-R. I really need a better way to transfer files...

I wouldn't go through that much hassle, it really isn't worth it.  I was just more so curious to see what it would do on real hardware as it crashes on xm6 in x68000 mode, but runs on x68030 mode.  My idle curiosity isn't worth a CDR.

What did kids use back in the day? terminal programs, null modems? sneakernet?

I think something like this [ur=http://www.ebay.com/itm/TCP-IP-Converter-Module-Serial-RS232-to-Ethernet-Networking-Over-LAN-or-WAN-/262215910700l]http://www.ebay.com/itm/TCP-IP-Converter-Module-Serial-RS232-to-Ethernet-Networking-Over-LAN-or-WAN-/262215910700[/url] may be something to look into... if I read it right, it'll let you basically telnet from a serial program.  You could enjoy all those dozens of Internet BBS's and transfer files that way if you have a terminal program with something like zmodem support.

[neko68k]

For file transfer there are a couple of options other than disks. There is direct serial null modem where you could use TeraTerm on a windows machine and muterm on the x68000 and just zmodem stuff to the x68000. Another option is serial null modem with a PPP server on the other side. That'll get you TCP/IP and all that good stuff. My HDS is set up to support internet with Nereid ethernet emulation. Turn that on in the options and follow those instructions and you can get real internet access inside the emulator

Yeah my disk is a little crufty in places. It's old and I haven't done anything with the native compilers in years.

[kamiboy]

Back in the day the kids used floppies. My solution though was the SCSI CD drive I imported from Japan. maybe there is a brand that will read CD-RW disks, but it is a bit too pricy to experiment.

Perhaps I should invest in a SCSI MO drive. I have been fascinated with the technology ever since I found out that those MO disks from the Resident Evil series were not just some made-up piece of tech, but actually existed in Japan.

[neozeed]

I've never seen one of those mo disks.  I used to have a next cube, but the drive never worked.  I always wanted the mo disks from the matrix, but I never did research what it's was....

I can't find anyone who will decap my x68000 I may just take an iron to it and hope for the best.  I took it apart which was a mission in its how right.  It's crazy how many places fix phones or old shitty xbox 360's but nobody will touched my x68000...

[kamiboy]

I always thought the disk from Matrix was just a mini-disc, but I supposed it could have been an MO. They are basically the same technology.

Those NeXT machines sure were sexy, the addition of something as exotic as an MO drive only made them sexier in my opinion.

As for your X68000, recapping them yourself is not that hard. You won't find anyone who can solder at the places you mentioned, you need to find an old school repair person, one who worked in 90's tech, they'll know what is what.

[neozeed]

I always thought the disk from Matrix was just a mini-disc, but I supposed it could have been an MO. They are basically the same technology.

Those NeXT machines sure were sexy, the addition of something as exotic as an MO drive only made them sexier in my opinion.

As for your X68000, recapping them yourself is not that hard. You won't find anyone who can solder at the places you mentioned, you need to find an old school repair person, one who worked in 90's tech, they'll know what is what.

You know, it should be crazy easy, there is so many people in Hong Kong that used to make stuff like this, but for whatever reason I can't find anyone.  I can find people who want to work with new stuff like crazy, but old stuff? no way.  If anything I'd imagine it should be so much easier to repair 1980's electronics, but as soon as I pull out this x68000 I get the immediate NO NONONONONONONO1!!!

Maybe they have a bad reputation?

I see an x68030 on yahoo auctions, but 700 USD seems a bit steep...   But I guess that is the pinnacle short of one of the 3 68060 machines.