AMIX installation made easy...no tape drive!

[Matt_H]

Update on the clock issues mentioned in my report:

AMIX is not setting the clock correctly. I booted into the Amiga side yesterday and found the hardware clock set to 3:00AM in 2010:-o. Apparently the "date: bad conversion" error is more serious than I thought.

I rebooted into AMIX today and found the clock set to 5 minutes before midnight yesterday (If that makes sense...). From what I can tell, date is executed (incorrectly) in the AMIX equivalent of the startup-sequence (before the login prompt appears), though I don't know what that file is.

The other possibility is that AMIX is a lot more sensitive to a bad clock battery than AmigaOS is. As mentioned in another thread, my A3000 battery is near-death (keeping an eye on it in case it starts leaking), and I'll be replacing it shortly. Hopefully a few problems will resolve themselves.

[Dalamar]

The file you speak of is /etc/sysinit.  :-)  Not sure what's going on except that the setclk util isnt y2k compliant perhaps.

[Matt_H]

Yeah. I was trying to adjust the clock from sysadm and it kept telling me the date was invalid. Looks like we've got a Y2K problem indeed. :-(

If it's just that one program, though, maybe it could be easily replaced with a fixed one.

[Dalamar]

Found this in a USENET post:

Thank you for suggestions. After replacing the battery and the crystal
and checking that the generator is running when power is off, I found
that clock was running all the time! The problem was in AMIX 2.1, which
has the Y2K bug I feel so stupid! Is this problem documented
somewhere? Is it possible to circumvent the Y2K bug? The faulty program
is the one used for reading the NVRAM clock. I think it is named 'setclk'.

If you look at this post from Commodore and notice the required format for the date command I think it shows they were only expecting 2 digit years:

http://groups.google.com/groups?q=setclk+Amiga&hl=en&lr=&ie=UTF-8&selm=1992Oct3.031754.1826%40mirchi.uucp&rnum=5

I'd say my previous post holds true.  The sysadm utility doesn't accept the date if you try to put it in using that tool.  That's a glaring bug I'm afraid.  Oh well, just don't turn the system off.  :-)

[Failure]

Hmm.  I dunno, my time stays correct between reboots, but I don't turn the thing off (My 3000UX has no battery).  However, if it *is* the setclk utility, take a look in /usr/amiga/src/cmd/setclk  *edit* setclk appears to be the equivalent of hwclock in Linux (ie, hwclock --systohc), so it's certainly the cause of the problem.

I get the "bad date conversion" but again, my time stays correct.  I will reboot the machine in just a minute because now I am curious if it shifts at all.

I got gcc 2.4.5 to compile itself, so I uploaded it as a cpio package to my AMIX site.  Next is 2.95 which I will let go overnight, I don't hold much hope for it compiling all the way but it should at least get farther than it did with...uh...gcc 1.4.0 or whatever it is.  It's so old, the version number is faded.

*badum-ching!*

Thank you, I'll be here all week.  Try the tuna.

[Dalamar]

Excellent.  I'll download that when you upload it.  

The time stays true until it's powered off so I would say that rebooting will definitely show that the clock keeps time.  ;-)

[Failure]

Argh.  I appear to have hit a roadblock compiling gcc 2.95: running into a memory limit.  I only have 8 meg and 30 meg swap, and for some reason it fails on this step:

gcc  -DIN_GCC     -g -O2  -DHAVE_CONFIG_H  -o cc1 toplev.o version.o tree.o print-tree.o stor-layout.o fold-const.o function.o stmt.o except.o expr.o calls.o expmed.o explow.o optabs.o intl.o varasm.o rtl.o print-rtl.o rtlanal.o emit-rtl.o genrtl.o real.o dbxout.o sdbout.o dwarfout.o dwarf2out.o xcoffout.o bitmap.o alias.o gcse.o integrate.o jump.o cse.o loop.o unroll.o flow.o stupid.o combine.o varray.o regclass.o regmove.o local-alloc.o global.o reload.o reload1.o caller-save.o insn-peep.o reorg.o sched.o final.o recog.o reg-stack.o insn-opinit.o insn-recog.o insn-extract.o insn-output.o insn-emit.o lcm.o profile.o insn-attrtab.o m68k.o getpwd.o  convert.o mbchar.o dyn-string.o splay-tree.o graph.o sbitmap.o resource.o hash.o c-parse.o c-lang.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-iterate.o  obstack.o        ../libiberty/libiberty.a
ld: cc1: libelf error:  Memory error: output file space elf_update:
make[1]: *** [cc1] Error 1
make[1]: Leaving directory `/usr/src/gcc-2.95.3/gcc'
make: *** [all-gcc] Error 1

Uh...heh.  Yeah, so I am trying to figure out how to remove the limits (viewable by ulimit -a) so this will work.  This is a bit dangerous since I have such limited memory.  I'd like to buy more ZIPs but they're not on pricewatch :-)  Well if I crash it doing this, is anybody running with 16MB or > 30MB swap?

And I need to reinstall on a bigger drive, I'm running out of HD space too.

*snif* :-(

The good news is, gcc 2.95 is more or less compiled!

*edit* hmm probably need a new thread for this, since it's nothing to do with installation

[Steady]

Have you tried cross-compiling from another system that has more RAM etc?

[Failure]

I have not, but I am planning on doing that as soon as I get as far up the compiler version chain as I can...it's not a trivial process (crossing both arch *and* OS), so I want to avoid doing it more than once.  Reading the docs to do it with 2.4.5 makes me sweat a little but I think I could do it, although I don't want to.  I'd like one of the guys with 16MB to try it first!

If it continues to not work, I'm not sure whether to just stop at 2.4.5, try something less than 2.95.3, or go through the hassle of the cross compiler.

From this post, it clearly continues to fail even after I removed all system limits...

[Dalamar]

I have 16 installed.  :-)  Do you want to put up what you have and let me give it a try?

[Failure]

Yeah I'll do that if my next attempt doesn't work.  I noticed the ld that the system was using isn't GNU, and is also in excess of 14 years old.  So I am compiling the latest GNU binutils, and will try with that...if I am right, it would have failed with 16MB anyway.

[Trev]

Building a Linux or Cygwin m68k-amigaos cross is pretty straightforward, so I can't imagine a Linux or Cygwin m68k-sysv4 cross being much different. And since a sysv4 cross shouldn't require patching the gcc sources. . . . Sounds like a project.

[color=FF0000]EDIT: The m68k*-sysv4 targets were removed quite some time ago, and from what I've read, AMIX doesn't properly support the m68k-elf application binary interface. D'oh![/color]

I've also been toying with adding MMU support to WinUAE. I'm using the uae-8.20 MMU patches as a starting point. The code compiles (good start), but I've still got logic errors to work out. WinUAE's CPU emulation has changed non-trivially since uae-8.20.0. And Toni should be releasing a new source snapshot soon, so there's that to contend with as well.

Trev

[LocalH]

@Trev:
Good luck on your MMU work, it's possible that this might enable the 3000's 1.4 boot ROM to work as well - currently, all I get is a flashing grey or white screen with 020/040, JIT or not, and a solid grey screen with 000/010. The ROM I have is 512KB, I don't know if there's supposed to be bonus code or not.

Also, if I can get my A3000 to recognize it's fast RAM, or get another one, I might attempt to install AMIX using a CD-ROM drive instead of the single- or dual-hard drive methods. I would imagine the main difficulty would be burning the CD in the same raw fashion - perhaps using the cpio file as a bin, and writing a cuesheet for it, will work. As I have no way to burn CDs from my Amiga, I'd be burning the CD on my PC, but if I can get it to burn as a bin/cue, then it might work.

[Trev]

@LocalH

I'd use a native version of cdrtools.

And I don't have a copy of the 1.4 ROM, but I guess that would be the best place to start if my intention is to get AMIX running on WinUAE.

[LocalH]

@Trev:
Well, as I mentioned, I do have a copy of the 1.4 ROM, and it does not work within WinUAE currently. The ROM is a solid 512K and lacks bonus code, unless the 1.4 ROM was relinked and the bonus code is within the first 512K (this is plausible, as the end of the ROM has text dealing with the OS boot screen), and thus the ROM doesn't need to be larger than 512K as the later ROMs with bonus code do.

WinUAE lacks emulation of one or more A3000 hardware components that this particular 1.4 ROM requires, I believe. Since it was dumped with a regular Kickstart dumper, it should reside at $F80000, whether in the physical memory map (as I would likely believe), or via MMU. Without investigating, I am thinking that MMU emulation might allow the ROM to boot. I will try setting up some hardfiles and name them correctly, but I doubt that will work, as even without the HD partitions I should at least see the purple 'insert disk' screen.

[Failure]

It might be useful to note that AMIX doesn't depend on ROM 1.4, but works fine even on 3.1 ROMs.  Not that I'm trying to say getting 1.4 working in WinUAE is pointless, just that it isn't necessary for AMIX.

I played around a little with the UAE MMU patch, but wasn't able to do anything with it.  But I am a really poor programmer so I am pretty sure the hacks I was doing to get the MMU to "work" on 68020 were completely bogus.  IIRC, the MMU in that patch is for 68040 which is simpler than the MMU in the 68030 although I do not know the specifics of it.  There is a thread I started around here somewhere on that topic.

Back to my gcc 2.95.3 problems, GNU binutils won't compile since there is no m68k-cbm-sysv4 target for ld or gas.  So I gave up on that.  Further Usenet searching reveals that the problem really might just be memory, like I originally thought, so I'm gonna put the partially compiled sources online and hopefully Dalamar (with perhaps more than 30MB swap) will have better luck.

I am still having a good time but I wish they made a 300MHz 68030 :-)