User avatar
Overmann

Posted Sun Apr 05, 2020 1:09 am

Hi guys,

I made the "mistake" of upgrading my A3000 with an A3660. I thought I wanted it to be as fast as possible, knowing it would break Kickstart 1.4's dualboot. Now, 040/060 supposedly doesn't work with kickstart 1.4 (and dualbooting 1.3 and X.X) since it loads the kickstart from disk (HDD) and uses instructions illegal to the 040/060 to do so. But surely there is no "IT CAN'T BE DONE" in the Amiga world?

Has anyone here had any luck with doing something like that, or do I simply have to buy an A4000 to stick my 060 in? :P

User avatar
McTrinsic

Posted Sun Apr 05, 2020 5:54 am

Try the MMUlib documentation.
That where I would start.
It should give you an idea about the option you have with different 0x0.libs.

User avatar
Christian

Posted Mon Apr 27, 2020 9:44 pm

Try this - I haven’t with 1.4 ROMs but am curious:

Rename the boot partitions (WB_2.x and WB_1.3) using HDToolbox. Make a backup first, just in case.
Create a new partition DH0 with the highest boot priority. Install a program to load a kickstart (don’t know what works with the 060 - I haven’t finished building my A3660 l), similar to SetCPU (68020+68851/68030 only) or Set040 (68040 only? Or is the 68060 MMU close enough).
Anyway you get the idea. You can create a startup sequence (use 1.3 or 1.4 CLI commands - 2.0 commands tend to crash under 1.4) that asks you which OS you want to boot. You then run the Kickstart loading program to load 1.3, 2.0,3.1, whatever. Check in the startup-sequence what OS is running, reassign c:, devs:, SYS:, l:, etc to the appropriate partition and execute the startup-sequence on that partition.

The above assumes that 1.4 does not crash with the 68060 (quite possible) and you may have to click the hidden gadget on the 1.4 Kickstart selection screen to get this going.

The part below is verified working - one of my A2000s is doing exactly this:

The above still works with minor variations if you have Kickstart 3.1.4 installed. (I.e no need to rename partition a to defeat 1.4’s autobooting, no need to use 1.3 or 1.4 CLI commands, 3.1 or 3.1.4 will do)
Always boot from the 3.1/3.1.4 partition, load other kickstart as needed, reboot, detect other Kickstart version is running and then reassign/transfer to the correct partition If needed using CLI commands.
Btw the 68040 is not really supported under 1.3 and for the 68060 (assuming full with FPU and MMU), you’d need to patch the other Kickstart so that it knows what to do with the FPU stack frame. If you get 1.3 working with a full 68060: let us know.
Last edited by Christian on Thu Apr 30, 2020 11:48 pm, edited 1 time in total.

User avatar
A10001986
1986

Posted Wed Apr 29, 2020 3:50 am

If your target is to create a machine as unstable as possible, why not go for 1.1 instead of 1.3, ie the whole nine yards? ;)

Seriously, 1.3 and 060 is not something you can use in any meaningful way (my guess is it won't even boot), and I predict that as good as none of the pre-2.0 software, especially games or intros, won't work either.

PS: I never had any machine with 1.4 ROMS. How is 1.3 on the A3000 supposed to work at all, there is no scsi.device in 1.3, so no hd... floppy only?

User avatar
intric8
Seattle, WA, USA

Posted Wed Apr 29, 2020 7:22 pm

I never had any machine with 1.4 ROMS. How is 1.3 on the A3000 supposed to work at all, there is no scsi.device in 1.3, so no hd... floppy only?
It absolutely supports scsi out of the box, as shipped from the factory. It has scsi chips right on the motherboard and a scsi cable to hook up your drives.
IMG_7387.jpg

Apologies if I'm misunderstanding your question.

User avatar
A10001986
1986

Posted Wed Apr 29, 2020 10:23 pm

Of course it has the hardware, but where is the scsi.device driver, which is lacking in 1.3?

The 1.4 ROM loads the 1.3 image from the harddrive, puts it somewhere in RAM, sets up the MMU to think it's running at $f80000 (or $fc0000). Is that a generic 1.3 image, or a special one with an additional scsi.device?

How big is that 1.3 image file, 256k or 512k?

Or does the 1.4 ROM also function like the ROMs on other scsi devices (GVP, etc) and adds an auto-config device to the chain, in whose initialization the scsi.device is added?

User avatar
intric8
Seattle, WA, USA

Posted Thu Apr 30, 2020 7:35 am

From Christian:
A3000Bonus is added to the kickstart image which is bigger than 256KB. That has the A3000 SCSI and motherboard configuration code.

User avatar
Christian

Posted Thu Apr 30, 2020 11:53 pm

Both the SuperKickstart disks and the SuperKickstart images in devs: have the A3000bonus added - i.e. the superkickstarts are bigger than 256K (for 1.3) and bigger than 512K (for 2.0). The A3000bonus is different for 1.3 compared to 2.0, probably to add the SCSI device. I am not in front of my SuperKickstart A3000, but will check this in the next few days.

Btw. it is possible to extract the 2.0 A3000bonus and add it to an A3000 3.1 ROM (and presumably 3.1.4 ROM) image and place that in the WB_2.x:devs folder, replacing the 2.0 SuperKickstart. That way you get (with 1.4 boot roms) a dual boot 1.3/3.1 (or 3.1.4) A3000.

User avatar
Overmann

Posted Wed May 20, 2020 8:18 am

I am kind of annoyed that I gave up on 1.4 so quickly. I spent about a week trying to get 1.3 installed and eventually just gave up, installed 3.1.4 roms and went full boring with 3.1.4. Having 1.3 and 3.1.4 dualboot on kS1.4 would have been magic. I've since invested in A3660 and an RTG-card, none of which work in 1.3 (at least not A3660, I've learned), so I've kind of left the 1.3-dream in the dust.

I have the IDE/RAM-solution in my A500, and after some chip-upgrades in my A1000, so I'll hopefully be happy with those solutions, but the extra speed of the A3000 would make it a fantastic 1.3-machine. Perhaps I just need to get another A3000? :P

EDIT:
Christain's suggestion passed me by completely. I'll have to give it a closer read.

User avatar
McTrinsic

Posted Wed May 20, 2020 12:15 pm

You might try to also use Softkick or similar to use 1.3.

With a softkick setup you could try to set up a dualboot system.

That way you can think about what to do with the software/OS.

You need to plan that anyway.





Return to “Hardware”