Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A600 Memory

AuthorTopic: KickWork  (Read 9606 times)

0 Members and 1 Guest are viewing this topic.

Offline yorgle

KickWork
« 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...
 

Offline hardlink

Re: KickWork
« Reply #1 on: November 27, 2007, 06:43:24 PM »
Quote

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 :)
 

Offline yorgle

Re: KickWork
« Reply #2 on: November 27, 2007, 08:22:29 PM »
Quote

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)
 

Offline da9000

Re: KickWork
« Reply #3 on: November 28, 2007, 04:14:29 AM »
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?

 

Offline yorgle

Re: KickWork
« Reply #4 on: November 28, 2007, 05:22:23 AM »
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.
 

Offline da9000

Re: KickWork
« Reply #5 on: November 28, 2007, 05:32:37 AM »
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?
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
  • Total likes: 0
    • http://www.iki.fi/sintonen/
Re: KickWork
« Reply #6 on: November 28, 2007, 07:49:00 AM »
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.
 

Offline da9000

Re: KickWork
« Reply #7 on: November 28, 2007, 08:49:20 AM »
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! :-)
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
  • Total likes: 0
    • http://www.iki.fi/sintonen/
Re: KickWork
« Reply #8 on: November 28, 2007, 09:02:48 PM »
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:

(I don't have a A1000 so I had to use UAE for testing)
 

Offline yorgle

Re: KickWork
« Reply #9 on: November 28, 2007, 10:00:02 PM »
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.
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
  • Total likes: 0
    • http://www.iki.fi/sintonen/
Re: KickWork
« Reply #10 on: November 28, 2007, 10:27:10 PM »
http://www.iki.fi/sintonen/temp/mkkickwork.exe (amigaos m68k)

usage is quite simple:
Code: [Select]
.> 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.

 

Offline yorgle

Re: KickWork
« Reply #11 on: November 28, 2007, 10:40:13 PM »
Yeah. I'd love to see the source and a description of the theory; how it works and such.

Nifty!
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
  • Total likes: 0
    • http://www.iki.fi/sintonen/
Re: KickWork
« Reply #12 on: November 28, 2007, 11:37:38 PM »
 

Offline da9000

Re: KickWork
« Reply #13 on: November 29, 2007, 01:01:06 AM »
Quote

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
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
  • Total likes: 0
    • http://www.iki.fi/sintonen/
Re: KickWork
« Reply #14 on: November 29, 2007, 09:42:01 AM »
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.