Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: yorgle on November 27, 2007, 06:18:02 PM
-
Just wondering if anyone else out there has ever used the "KickWork" disk?
We picked it up from "Amigo" in Farmingdale (I think) NY (Long Island) back around 1987-1988 or so.
It is a boot floppy for the Amiga 1000 that is modified to also have a Workbench disk image on the same disk. That is, 256k is used for the Kickstart image, then around 600k for workbench disk space. It let you just have one floppy that you never had to remove from DF0.
I believe we had it for 1.1 and then got the 1.2 version later...
-
yorgle wrote:
Just wondering if anyone else out there has ever used the "KickWork" disk?
Yes, I have. KickWork was a critical item in using an A1000 as an embedded controller, where there was no human to swap out the KS for the WB disk. There was a hard disk, but it was non-autoboot, so I think the drivers had to go in the 'Expansion' drawer of the WB section of the disk. It worked great for over 13 years; at boot, the A1000 saw the floppy as KS, then magically saw the same floppy as WB, and then after WB loaded the startup-sequence handed things over to the hard disk.
I am thinking about putting ethernet software on a KickWork and running my A1000 (with an ethernet board on an expansion) as a 'diskless' network workstation :)
-
hardlink wrote:
I am thinking about putting ethernet software on a KickWork and running my A1000 (with an ethernet board on an expansion) as a 'diskless' network workstation :)
Neat!
I was never able to afford an ethernet board for my A1000, sadly. The most i've tried with it recently was to get a 4 gig hard disk working with it, but after 25 hours of formatting, i gave up on it (Data Flyer 1000)
-
How does KickWork manage the "split pesonality" thing? Is it a modified Kickstart that is smart enough to detect this specific disk format? Does the disk show as an NDOS disk on WB?
-
The disk just shows up as a standard disk when it was booted by itself. If you boot with a different kickstart, the disk is a non-dos, but not NDOS disk. I want to say that it appears as though it is a KICK disk, but I can't remember. I'll dig up the ADF and check it out.
What I believe it did was that it patched the disk handler in the Kick image, and added hooks for disks with a certain signature to start at a different cylinder on the disk.
just a guess though. i haven't compared kick roms or anything yet.
-
Makes sense, what you say about the patched disk-handler. Thanks for the explanation.
As for "is a non-dos, but not NDOS disk": is there a difference? I thought NDOS=non-DOS, right?
-
The easiest solution for this would be to patch the trackdisk.device to spoof normal KS 1.x bootblock instead of the KICK-block. Then you'd just need to mark the area used by the kickstart ROM as "used" in the bitmap.
-
OK, this makes a lot of sense. If I got it right: change the trackdisk.device in the KickWork ROM so that it returns a normal bootable disk block, so that WB thinks the disk is normal. At the same time mark the on-disk bitmap so that the ROM file blocks appear as used (which they are). Love hacky stuff like this! :-)
-
I wrote some nice tool to create combined A1000 kick + bootable floppy, imaginatively called "mkkickwork". Once the program has created the .adf you still need to populate the disk with the system files (and you can't fit them all, obviously, I threw out Prefs, narrator/translator/say and FastFileSystem).
Anyway, it works:
(http://www.iki.fi/sintonen/pics/mkkickwork.png)
(I don't have a A1000 so I had to use UAE for testing)
-
Damn! nice work!
I'd love to try that out on my own Ami. Can I try out that tool? (pm me) I realize that you can't just hand over the kickwork disk, since it's copyrighted and such.
Hmm... That with a combination of Skick/2.0 rom on the disk itself would be a single floppy solution to get you from a barebones A1000 up to 2.04.
Yeah... I like 2.04 more than 3.0... i'm crazy. then again, I prefer the look of 1.3 or 1.4 on my Ami.
-
http://www.iki.fi/sintonen/temp/mkkickwork.exe (amigaos m68k)
usage is quite simple:
.> mkkickwork path:to/kick13.rom kickwork.adf
You obviously need the KS ROM in a file, but that shouldn't be a problem (and it can be extracted from the existing kick floppy if really necessary). The program writes ADF file, which you can then write to a real amiga floppy by using your favorite ADF-write tool.
The generated floppy is bootable (on A1000 only, with default options;-)), but doesn't contain any system files. It does boot but doesn't do anything else than sit in the CLI prompt. You probably want to copy in some extra files there to make it usable.
I'll prolly put the source code for the tool up soonish.
-
Yeah. I'd love to see the source and a description of the theory; how it works and such.
Nifty!
-
source: http://www.iki.fi/sintonen/src/mkkickwork/
-
Piru wrote:
bootable floppy, imaginatively called "mkkickwork". Once the
Hahaha, definitely a (vowel-hating?) coder ;)
Sounds awesome, Piru! I'll give it a try as well!
Cheers
PS. Since we're on this thread (of thought), and SKick was mentioned would anyone mind giving a few dirty details on how SKick does its job? Thanks
-
Some words on how it works:
Basically the app writes a patched ROM image to the KICK floppy disk. The patch catches the OS reading the floppy bootblock (first two blocks) and if 'KICK' identifier is located it instead returns a valid bootblock. This allows the OS to idenfity the disk as bootable OFS (DOS\0), rather than df0:KICK.
The application loads the kickstart and then scans it for the locations to patch. If it finds the needed locations it then inserts the abovementioned trackdisk.device patch. Finally the program writes out a OFS disk image (.adf) containing first the KICK block + the KS ROM to allow A1000 bootstrap ROM to load the KS ROM, and then OFS rootblock + bitmap block with the area for the KS ROM pre-allocated.
The trackdisk.device CMD_READ patch itself is some really tight m68k assembly since I didn't want to overwrite any functional code inside the KS ROM. Currently it fits exactly over the copyright notice inside the KS ROM image beginning (type hex some kick1.2 or kick1.3 image to see the text it overwrites). The patch works by hooking the trackdisk.device/CMD_READ command which is used to read blocks off disk (check trackdisk.doc autodoc CMD_READ for details). At boot the KS ROM bootstrap uses CMD_READ to read the floppy beginning to see if it is bootable, so once we make sure that proper bootblock is returned it'll automagically work.
Later the KS ROM also uses CMD_READ to identify the filesystem of a inserted floppy (you get dfx:KICK if you insert KICK floppy using unpatched KS ROM). The patch naturally catches this CMD_READ aswell and again provides the required identification (DOS\0 to indicate OFS filesystem).
The program isn't really that complicated, the real magic went into figuring out how to patch the trackdisk.device CMD_READ. Once that was sorted out the rest was pretty straight-forward.
Finally, I really have no clue how the original KickWork works. It might do something similar, but for verification I'd need to take a look at ADF of such KickWork floppy.
-
Ok, I took a look at the original KickWork now. It has series of patches to the Kickstart ROM. The patches are tied to specific KS ROM version (meaning you need separate disks for every ROM).
The patches are:
strap:
- Modify code so that it accepts other than DOS\0 as bootable device (allows booting from KICK disk).
- Modify palette of the "insert floppy" display.
- Modify the "insert floppy" gfx slightly.
Workbench:
- Change workbench titlebar from "Workbench release 1.x." to "AMIGO KickWork 1.x. " (x being the KS rom revision).
- Modify Workbench so that it accepts other than DOS\0 floppies as DOS one (allows KICK disk with proper filesystem to work).
Finally new ROM checksum is poked in.
So in short it takes a different route, but functions pretty similar way. My patch doesn't do all those fancy visual modifications though, it tries to keep the ROM as unmodified as possible.
The floppy itself gets modified during the installation process (bootblock DOS\0 gets replaces with KICK). I'd guess the area where it writes the KS ROM is preallocated in the disk bitmap.
Finally there is one bootblock patch that seemingly does nothing: It replaces author's name "Loew" with "Loew" (no change). I'd guess this is a simple check to make sure the copyright notice hasn't been modified.
-
Awesome work Piru.
-
I see someone finally figured out the patches I made to create Kickwork 1.x for the Amiga 1000. I think analyzing KickWork 2.0.4 and KickWork 3.0 would be much more of a challenge. Since Amigo Business Computers is no longer in the Amiga business, I sell KickWork and other Amiga products on my own now.
Rudolph R. Loew
rloew@hotmail.com
-
Welcome to Amiga.org first time poster R. R. Loew!
KickWork was/is a great idea, but I was not aware that there was a 2.0.4 and 3.0 version. Can you tell us a little more about them and what prices you charge for them.
Also, what other Amiga products do you offer?
Again, welcome.
-
koaftder wrote:
Awesome work Piru.
Agreed!
What an amazing thread! First, that Piru can grok out the KickWork method from over 20 years ago. I thought KickWork was Amiga Nostalgia - then, the real author (I hope) shows up! Amd Amig-o Business Computers is still in business, sans Amig-a. They used to offer some hardware products - we almost bought a, if I rembember, GPIB controller Zorro card off them once. Of course, we did but KickWork from them - and I'm looking for it right now ...
-
Thank you for making it, Rudolph. We used it extensively on our A1000... it made it a lot more convenient to use... I'd be willing to bet that it let the eject mechanism in our DF0 live a few extra years. ;)
My dad and I drove up to Amigo a few times to get various software, hardware and just look at the computers. :)
Unfortunately, I had moved away from Long Island when I went to college before 1.3 came out, and then I had a hard drive, so I never picked up KickWork 1.3 or newer.
I seem to remember getting KickWork 1.1 as well, but that could be my poor memory.
And yeah, cheers for the excellent analysis and such, Piru!
-
Kickwork 2.0.4 and 3.0 are similar to Kickwork 1.x but install Kickstart 2.0.4 or 3.0 on an Amiga 1000. Due to the larger Kickstart image, half is stored in the normal protected RAM and half is stored in user RAM. There are three version of each, one for each of the three memory configurations supported.
Amigo Business Computers never promoted KickWork 2.0.4 or 3.0.
The price is $30 for an E-Mailed Disk Image. Retail packaging is not available for these or KickWork 1.x.
I have developed hundreds of Programs for the Amiga. Most are diagnostic or development tools. A few of the more interesting ones are listed below. Contact me if you are interested in a specific type of program.
XFILE: Advanced file management program with numerous List/Copy/Move/Delete/Execute options.
MERGEUNIQ: Merges files and removes duplicate lines/blocks.
TRACKDISK41: SCSI Disk drive for >4GB Drives without requiring "New Style Driver" support.
Networking File System with Auto Detect Option available in Proprietary Ethernet (AMIGO Ethernet), TCP/IP over Ethernet, Serial Port, Parallel Port, Modem, ARCNET, or Joystick Port (Beta). Auto Detect finds accessible drives over entire network including heterogenous ones.
Large Hard Drive Patches for X-SURF IDE/Ethernet Card.
-
Excellent thread!
@Piru:
Thank you for the in-depth explanations and reverse engineering!
Only a small question: when you say "The application loads the kickstart and then scans it for the locations to patch.", do you scan certain fixed locations (so it only works on certain Kickstart versions), or some other form of heuristic (so the program will work with other Kickstart versions) ?
@Mr. Loew:
Glad to have you here and hear from you. I'd be curious to know if Kickwork or any other of your software is still being used by businesses/corporations, and if so what sectors/industries?
-
I can answer the question Piru was asked. Each version of KickWork was designed to work with one version of Kickstart. Only two versions were sold by Amigo Business Conputers, KickWork 1.2 and KickWork 1.3.
As far as business use is concerned, KickWork was probably used mostly by individuals. A number of businesses purchased Amigo Ethernet to network their Amigas. I created some customized versions to work with the Scala authoring package to network their creation and presentation stations. I do not know how many Amiga based systems are still out there. I do know that Scala has migrated to the PC platform and is still selling software.
-
@Mr. Loew:
Thanks for the info!
As for the question to Piru, I meant it for his version of the software - that's what he was describing, if I understood correctly.
-
@da9000
when you say "The application loads the kickstart and then scans it for the locations to patch.", do you scan certain fixed locations (so it only works on certain Kickstart versions), or some other form of heuristic (so the program will work with other Kickstart versions) ?
My software indeed has heuristics to scan for the locations to patch (newtdread and oldtdreadptr pointers).
It has worked with all KS 1.x I've tried so far. It'll probably work with early KS 0.x betas, too.
-
If I may ask:
do you search for "byte patterns" or instruction fingerprints if you like, which span a few bytes before, including, and after the target location?
In other words,if the hypothetical byte stream is:
39 b3
50 34
25 64 <-- target
14 8a
9f ff
Would you be searching for "35 25 64 14" ?
Also, do you start searching from a certain approximate location, or do you search the entire ROM (from start for example)?
Just curious what's a more effective method.
-
@da9000
static __inline u_int32_t rl(const u_int8_t *p)
{
return (u_int32_t) ((p[0] << 24) | (p[1] << 16) | (p[2] << 8) | p[3]);
}
static __inline int romptr(u_int32_t p)
{
return p >= ROMSTART && p < ROMEND;
}
for (i = 8; i < 512; i += 2)
{
static const u_int8_t header[] =
"\xff\xff\xff\xff\x0d\x0a\x0a" "AMIGA ROM Operating System";
u_int8_t * const p = (u_int8_t *) rom + i;
if (!memcmp(p, header, sizeof(header) - 1))
{
newtdread = p;
if (verbose > 1)
{
fprintf(stderr, "0x%06x: Patch position\n",
(u_int8_t *) newtdread - (u_int8_t *) rom + ROMSTART);
}
break;
}
}
for (i = 8; i < ROMSIZE - 40; i += 2)
{
u_int8_t * const p = (u_int8_t *) rom + i;
u_int32_t p1, p2;
p1 = rl(p);
p2 = rl(p + 8);
if (romptr(p1) && romptr(p2) &&
rl(p + 4) == p1 && rl(p + 12) == p2 &&
romptr(rl(p + 16)) && romptr(rl(p + 20)) &&
rl(p + 24) == p1 && rl(p + 28) == p1 && rl(p + 32) == p1)
{
const u_int8_t *func = (u_int8_t *) rom + p2 - ROMSTART;
if (rl(func) == 0x48E70038 && rl(func + 4) == 0x26690018)
{
oldtdreadptr = p + 8;
if (verbose > 1)
{
fprintf(stderr, "0x%06x: trackdisk.device CMD_READ function ptr\n",
(u_int8_t *) oldtdreadptr - (u_int8_t *) rom + ROMSTART);
}
break;
}
}
}
Efficiency does not matter here. The code is executed once when creating the disk.
The first loop finds the strings at the beginning of the ROM (it's quite pointless since in fact I think the strings are always at the same offset for all pre-2.0 ROMs). This is where the patch code will be placed.
The second loop is more magic, it locates the jumptable entry for the trackdisk.device CMD_READ command. There it looks for certain combination of pointers, and also has some code matching for the beginning of the actual cmd_read routine. The magical pattern is:
ptr1 ; CMD_INVALID
ptr1 ; CMD_RESET
ptr2 ; CMD_READ
ptr2 ; CMD_WRITE
ptr3 ; CMD_UPDATE
ptr4 ; CMD_CLEAR
ptr1 ; CMD_STOP
ptr1 ; CMD_START
ptr1 ; CMD_FLUSH
Once the code finds this pattern of pointers it then checks the code pointed by ptr2. It checks for:
ptr2:
movem.l a2-a4,-(sp)
move.l (IO_UNIT,a1),a3
Those are the first two instructions of the cmd_read routine (actually read/write.. as you can see both CMD_READ and CMD_WRITE point to the same routine, the routines are so similar it helped to reduce the codesize to combine them).
Once this jumptable entry is located it is changed to point to the first pointer (where we've copied the patch code to). The patch code is adjusted to jsr to the original cmd_read(write) routine.
Obviously this isn't the only way to patch the trackdisk.device, there are several other ways to do it aswell. One would been by patching the trackdisk.device BEGINIO vector for example. However, in my case I had very little storage left for my patch so to simplify the patchcode I had to locate the patch to as close to actual read operation as possible. Patching BEGINIO would have required for the patch routine to perform further checking to make sure it is a CMD_READ operation.
-
Cool stuff! I love technical analyses! I need to do some refreshing on jump-tables and libraries.
Almost all made sense, so just a couple of questions:
1)
For the life of me I can't decode your acronym for rl() :-). I can see it reverses the order of the bytes (swizzling?). Why is it necessary?
EDIT: a guess: ReverseLong? Can't be! You'd ditch u_int32_t for long!??! :-D
2)
I see the "magic pattern" code:
if (romptr(p1) && romptr(p2) &&
rl(p + 4) == p1 && rl(p + 12) == p2 &&
romptr(rl(p + 16)) && romptr(rl(p + 20)) &&
rl(p + 24) == p1 && rl(p + 28) == p1 && rl(p + 32) == p1)
but where do you check for ptr3 and ptr4?
romptr(rl(p + 16)) and the call afterwards are only checking bounds, right?
-
@da9000
rl()
It's big endian 32bit integer read, I did it this way so that the source is endian safe (it works with any endianity, say for example x86). The rl() comes from "read long", wl() is short from "write long".
where do you check for ptr3 and ptr4?
romptr(rl(p + 16)) and the call afterwards are only checking bounds, right?
Bounds checking of ptr3 and ptr4 is enough, I just check that they're pointers to ROM.
-
Ah, having not seen the wl(), I was lead down the wrong path of guessing. Doh! I assume you're want endianess safety because you're a UAE user?
As for ptr3/ptr4: gotcha. Smart and tricky ;-)
-
@da9000
I assume you're want endianess safety because you're a UAE user?
Nah, I wanted the code to be nice. Locking your code to certain endianess is quite stupid.
I wrote the app on my peg2 running MorphOS, but tested it using WinUAE (afaik E-UAE doesn't do A1000 emulation).
-
Doh! Bad assumption again! Forgot you're a MorphOS dev, and that means PPC! But good point on the WinUAE vs E-UAE and A1000 emu.
Double doh! Just realized you posted a link to the source! Now I can see the bitmap setting code and trackdisk replacement code. Cool stuff - sweet code!
Anyways, you're right about not doing it properly and endian agnostic to begin with (especially with networking code :-))
EDIT:
Since I've got some of your attention on this thread, Piru, if you have a little time (if not, that's ok), would you mind checking my very last post, and very last questions for you on this older thread: http://www.amiga.org/forums/showthread.php?t=26716
I'd love to hear from you on it (again, only if you have time, if not, no prob). Thanks
-
I want to test this on WinUAE, is it possible? (Kickstart)
Whats the -b switch do exactly?
-edit-
I guess I needed to update to the latest WinUAE, there is an option of A1000. BUT I need 1000 bootstrap ROMs? How do I get them? I own THREE FLIPPING Amiga 1000 computers so I think I am legal here...
-
so, Piru, could you do it for KS2+ ?
-
@orange
A1000 only has 256KB WOM.
-
@TjLaZer
Whats the -b switch do exactly?
From the program help page:
create DOS bootable floppy rather than A1000 kickstart disk
Basically it makes a normal DOS floppy you can use on any amiga. You can then fill it with whatever files you need. Once done, you can make it KICK-floppy by just writing the first 512 bytes with 'KICK' + zeros.
-
@Piru
A1000 only has 256KB WOM.
that hasn't stopped rloew doing it ;-)
could you use for eg. fast ram on A590?
-
@orange
that hasn't stopped rloew doing it
That requires either 512KB WOM hack + modified A1000 bootstrap, or skick kind of hack for the 2nd half of the ROM.
This is out of scope for mkkickwork.
-
Piru,
I got to test your KickWork and it works great! I make a disk with stripped out WB 1.3 on it, works a treat...
-
@TjLaZer
Oi! Nice to hear it works on the real thing, too :-)
-
I used the second longword to identify the disk for twinkick.
If i remember correctly there was also a pd-series with a "kickwork" disk with a different (bad) technic.
The disk must be "writeable" and the kickstart changed the bootblock entry for a short time.
After a reset ist writes DOS in it and after booting the WB there was a tool inside the WB startup-sequence writing KICK on the BB.
crazy way ... i think its on an IG1000 Disk.
-
I believe that PD verision was called "KickBench".
Seeing the poor design of KickBench prompted me to write KickWork.
KickBench clearly was not reliable for unattended operation since a power failure between the writes would disable the disk.
-
I plan on trying to use PowerPacker to pack the whole WB disk so it will fit on KickWork!!!! Woot!!!
-
Haha I am such a nerd. I spent this evening Imploding all the exe files from my Workbench 1.3.3 disk to my KickWork disk! I now have a full WB 1.3.3 KickWork disk! It rocks!!! ;)
-
I have gotten the KickWork to write a boot image using kickstart rom v 1.3 to a disk that does boot on my Amiga 1000. It boots kickstart then ends at a shell type screen and it does not recognize any commands I have tried at the shell prompt.
When I boot to my regular WB 1.3 and try to copy any files to the boot disk I created it will not allow me to double click to open the disk icon, it just flashes. When I right clicked on the icon and checked info from the tool bar it gives a 'not a dos disk" message. I tried Kickwork with the -b option which made the disk image but when I tried to boot it asks me for a kickstart disk.
I am also still fairly new at the Amiga and I am not sure what files I would need to copy over from my WB 1.3 disk to the Kickwork disk to get Workbench up and running even if I could get the files on there.
Any tips or links to detailed instructions would be great. I have googled for detailed info but have not found much.
If any kind soul can make an .ADF of a full working A1000 disk image that boots all the way to Workbench 1.3 and e-mail to me at mrnukem at gmail.com that would be even better. I use Amiga Explorer to transfer images over.
Thank you
-
Send me a PM... ;)
-
Pm Sent. Thank you!
-
It was tricky but if you did the KickWork disk right you should have a Kickstart disk with free space of about ~500k or so. You have to kick from this disk for the disk to be visible in WB. If you use any other kickstart the disk will show up as a Kick disk and you cannot open it up in WB. I was able to copy all the files from my WB 1.3.3 disk to the Kickwork disk. But to get them all to fit I had to Implode them and compact all the executable files. I was able to get 99% of the disk to fit! I did leave out some stuff like keymaps, and other small stuff that is not needed...
-
Thanks TjLaZer for the help. Your solution got me up and running!
-
Hi,
Don't know what all the fuss is about, KickWork or KickBench
was written back in 1985 -86, I still have my original. I
believe one of the fred fish disks had instructions on how
to make it.
This was probably made before you all knew what the Amiga
1000 was.
smerf
-
Hi,
Don't know what all the fuss is about, KickWork or KickBench
was written back in 1985 -86, I still have my original. I
believe one of the fred fish disks had instructions on how
to make it.
This was probably made before you all knew what the Amiga
1000 was.
smerf
Once wasn't good enough had to quote this one twice, if the
amiga org sysop is still awake, please delete this post.
-
Hi,
@rloew,
===========================================================
Seeing the poor design of KickBench
==========================================================
Worked great for me for 5 to 6 years
To tell you the truth could never get KickWork to Work
Must have been made for a special A1000.
kickbench worked first time everytime, even had it to start
up my supra hard drive and my modem at different times to
download programs.
Now lets see where did I place KickWork, oh yes in the
kick trash drawer.
smerf
-
There's no fuss. KickBench was just implemented in a silly way: Writing the disk all the time, when in fact there was no need for that.
But hey if KickBench did the work for you, no problem.
-
Hi,
@Piru,
Dog gone it
You stole the fire from me again, you know the smerf loves
to troll, I can't have any fun here.
smerf
-
; Kickwork 3.1
; ------------
; OS3.1 rework by Ratte
; optimized by StingRay
; based on Piru´s Kickwork1.3
start:
bsr.b patch ; Kickwork-Magic ->
lsr.l #2,d2 ; Org.Code from
clr.b $60(a0,d2.w) ; $2457d6/$fc57d6
rts ; back to OS3.1
patch:
tst.w $6a(a3) ; TDU_TRACK
bne.w end ; Track 00 ?
cmp.b #$1,$69(a3) ; TDU_SECTOR
bhi.b end ; Sector 00 or 01?
tst.b $69(a3) ; Check for
beq.b sector00 ; Sector 00
sector01:
lea $78(a3),a0 ; TDU_DATA
move.l (a0),a0 ; BUFFER-POINTER
lea bb_data(pc),a1
move.l a0,d0 ; save a0
lea -$200(a0),a0
cmpm.l (a1)+,(a0)+
bne.b end
cmpm.l (a1)+,(a0)+
bne.b end
cmpm.l (a1)+,(a0)+
bne.b end
move.l d0,a0 ; restore a0
move.l a0,a1
cmp.l #$11114ef9,(A1)+ ; Sector 01 KickHeader ?
bne.b end ; If not EXIT
cmp.l #$00fc00d2,(a1)+ ; Sector 01 KickHeader ?
bne.b end ; If not EXIT
cmp.l #$0000ffff,(a1) ; Sector 01 KickHeader ?
bne.b end ; If not EXIT
moveq #128-1,d0 ; Fill Sector 01
loop1: clr.l (a0)+ ; with
dbf d0,loop1 ; zeros
bra.b end ; leave patch
sector00:
lea $78(a3),a0 ; TDU_DATA
move.l (a0),a0 ; BUFFER-POINTER
move.l a0,a1
cmp.l #"KICK",(a1)+ ; KICK-Disk ?
bne.b end ; If not EXIT
cmp.l #"WORK",(a1)+ ; KICKWORK-Disk ?
bne.b end ; If not EXIT
tst.l (a1) ; Triple-Check
bne.b end ; If not EXIT
moveq #$17,d0
lea bb_data(pc),a1
loop2:
move.l (a1)+,(a0)+ ; Copy OS2.x Bootblock
dbf d0,loop2 ; to the buffer
moveq #$67,d0 ; and fill
loop3:
clr.l (a0)+ ; the rest
dbf d0,loop3 ; with zeros
end:
move.l d4,a0 ; Restore A0
rts
bb_data: ; OS2.x Bootblock
dc.l $444f5300
dc.l $e33d0e73
dc.l $00000370
dc.l $43fa003e
dc.l $70254eae
dc.l $fdd84a80
dc.l $670c2240
dc.l $08e90006
dc.l $00224eae
dc.l $fe6243fa
dc.l $00184eae
dc.l $ffa04a80
dc.l $670a2040
dc.l $20680016
dc.l $70004e75
dc.l $70ff4e75
dc.l $646f732e
dc.l $6c696272
dc.l $61727900
dc.l $65787061
dc.l $6e73696f
dc.l $6e2e6c69
dc.l $62726172
dc.l $79000000
-
You got it to work with Kick 3.1? That would be nice but impractical since the ROM is 512kb.
-
Yeah but... A1000 booting to Kick3.1 would be nice...
... What next, Kick3.1 and Workbench 3.1 on the A1000? :lol:
-
DBAlex wrote:
Yeah but... A1000 booting to Kick3.1 would be nice...
... What next, Kick3.1 and Workbench 3.1 on the A1000? :lol:
yes.
i made twinkick (kick3.1) many years ago.
but kickwork3.1 with a "256kb" rom is real funstuff.
-
TjLaZer wrote:
You got it to work with Kick 3.1? That would be nice but impractical since the ROM is 512kb.
251 kb + 3 kb for decruncher and resetlogic
hmmm ... there are 2kb space for funstuff :-D
-
Its done !!
With many many help ...
... today my A1000 booted from a KickWork3.1 disk.
Kickstart3.1 inside a 256KB WOM.
scsi / card / carddisk overwritten with $FF
(useless on an A1000)
trackdisk enhanced with kickwork
crunched with lzma = 251KB
dc.w $1111 ; ROM-Header
jmp $00fc00d2
dc.l $0000ffff
dc.w $0028 ; OS-Version
dc.w $003f ; OS-Revision
dc.w $ffff ; there is no exec.lib
dc.w $ffff ; version/revision
dc.l $ffffffff
dc.b 0 ; ROM-Text
dc.b "AMIGA WOM Operating System ",0
dc.b " ",0
dc.b " ",0
dc.b " ",0
dc.b " ",0
dc.l $ffffffff
dc.l $ffffffff
dc.l $ffffffff
dc.l $ffffffff
dc.l $ffffffff
dc.l $ffffffff
dc.l $ffffffff
dc.l $ffffffff
dc.l $ffffffff
dc.l $ffffffff
dc.l $ffffffff
dc.l $ffffffff
dc.l $ffffffff
dc.l $ffffffff
dc.l $ffffffff
dc.l $ffffffff
dc.l $ffff4e70 ; RESET command
code:
lea.l $400,a7 ; temp.stack
clr.b $00bfe001 ; against trashed register
move.b #$03,$00bfe201 ; overlay and power-led
lea.l $00dff000,a4 ; chipset base address
move.w #$7fff,d0 ; clear all pattern
move.w d0,(a4,$009a) ; disable all interrupts
move.w d0,(a4,$009c) ; clear all interrupts
move.w d0,(a4,$0096) ; disable all dma
move.w #$0174,(a4,$0032) ; init ser-port 9600 baud
move.w #$0200,(a4,$0100) ; init display
move.w #$0000,(a4,$0110) ; init display
move.w #$0111,(a4,$0180) ; init display
memtest:
lea.l $00200000,a0 ; expansionmem-base
move.l (a0),d1 ; store memory
move.l #"KICK",(a0)
cmp.l #"KICK",(a0)
bne autoconfig
move.l #"WORK",(a0)
cmp.l #"WORK",(a0)
bne autoconfig
move.l d1,(a0) ; restore memory
bra good_hardware
autoconfig:
move.b #$20,$00e80048 ; activate the
move.b #$00,$00e8004a ; first expansion
move.l (a0),d1 ; store memory
move.l #"KICK",(a0)
cmp.l #"KICK",(a0)
bne bad_hardware
move.l #"WORK",(a0)
cmp.l #"WORK",(a0)
bne bad_hardware
move.l d1,(a0) ; restore memory
good_hardware:
bsr checksum
not.l d5
beq ready_to_go
bsr decrunch
lea.l $00200000,a0
bsr checksum
not.l d5
beq ready_to_go
bad_hardware:
move.w #$0f00,(a4,$0180) ; red screen
moveq #10,d1
moveq #-1,d0
pled_on:
bset.b #$0001,$00bfe001 ; power-led on
dbf d0,pled_on
lsr #2,d0
pled_off:
bclr.b #$0001,$00bfe001 ; power-led off
dbf d0,pled_off
dbf d1,pled_on
move.l #$00015000,d0
reset:
move.w #$0000,(a4,0$180) ; black screen
subq.l #1,d0
bgt.b reset
move.w #$4000,(a4,$009a)
lea.l $00f80002,a0
reset
jmp (a0) ; restart
ready_to_go:
jmp $00200002
checksum:
move.l #524288/4,d1 ; checksumtest for
moveq #0,d5 ; $200000-$27ffff
checksum_loop:
add.l (a0)+,d5
bcc checksum_test
addq.l #1,d5
checksum_test:
subq.l #1,d1
bne checksum_loop
rts
decrunch:
.
.
.
-
Sorry to bring up the Thread from the Dead, but I thought I'd let everyone know that Piru has very, very, very kindly recompiled (or possibly hex edited, unsure which) mkkickwork.exe to remove a requirement it had on OS2.04+
I used it natively on my 1000 to create a kickwork disk. Beautiful! Prior to the patch that Piru wrote last night (a few hours after I PM'd him on here saying that it was failing on KS1.3 with fstat: I/O error) he had fixed it and replied.
It now works on KS1.3. My 1000 now kickstarts, boots and transfers to the hard drive with one disk. I owe this man a beer!
-
I can't get twinkick to work. It says "ABORT! Missing OS1.3 (V34.5) data!"
I used GrabKick to snag amy 1.3 kickstart on my A1000, and it created a file called "kick34005" which I renamed to "KICK13.ROM".
Any idea what's wrong?
-
1. uppercase letters are important "KICK13.ROM"
- seems to be OK -
2. the romfile must be an 100% image of a v34.5 a500/a2000-kickstart
- no a1000 betas or modified kickstarts (config patch for memory or pal-patches etc.)
try to save your romimage from a a500 with real 1.3 ROM
-
Ratte wrote:
1. uppercase letters are important "KICK13.ROM"
- seems to be OK -
2. the romfile must be an 100% image of a v34.5 a500/a2000-kickstart
- no a1000 betas or modified kickstarts (config patch for memory or pal-patches etc.)
try to save your romimage from a a500 with real 1.3 ROM
I named it all upercase KICK.ROM.
I don't have an A500, and my A2000 is Kickstart version 40.63 ;-(
-
Another "bringing this thread back from the dead" post.
Just an interesting and expected finding, but thought I'd list it anyway..
I just got an AE High Density floppy drive a bit ago..
Was playing with it, and got it working on my Amiga 1000.
I was using a standard WB boot disk for this, as my KickWork disk was a bit full. ;-)
(In that, I'd use the Kickwork to kickstart, but then ejected it and put in copy of a standard WB disk to install the AEHD drivers..)
OK, so I made a copy of my kickwork disk and cleared a bit of space to make room for the drivers..
And it doesn't work. No shock.
Everything seems fine, until I load DEVS:AETD.device, which is what patches trackdisk device.
When I do that, I lose my kickwork boot partition.
(Starts telling me to insert KickWork, which is still there..)
So, these 2 patches to trackdisk seem to not like eachother..
Just an interesting find..
desiv
-
Poof! Bringing back this old thread :-)
Hoping to get my A1000 up & running in my office soon and a quick search of possibly booting kickstart 3.1 on it led me here.
I've got an 8mb board ordered from kipper so looks like some old school fun soon:)
-
I use a Kickwork disk on my A1000 currently, and it also loads the drivers for my IDE and RAM card and then transfers control to my IDE drive to finish the boot from the CF(IDE) card.
Works great.
I don't use kickwork to boot anything other than 1.3 tho.
If you're looking for 3.1, that's going to be something that (I think) only ratte has done.
desiv
-
@ desiv
sounds good. I have always enjoyed (& still do) booting my A1000 with both kickstart & workbench disks but kickwork booting up wb3.1 is just so darn cool:D
btw, what IDE controller and CF card do you use/recommend ?