Feature request: Kickstart tools

[roc-eab]

Hi Keir,

First of all, thanks for the great ATK that I have been using it since its initial releases. Moreover, I ended up with a CD32 re-capped by you :-)

I know it is not essential, however some kind of kickstart tool would be handy especially for self-built (or homebrew) roms. I seem to recall some code to process roms in the repository (byteswapping? doubling?) however I might be wrong.

I am not sure which of them would be feasible, however as some ideas you may consider checksum validation, showing the KS modules versions, analysing multiple roms on 27C800 or 27C160s, etc.

This I believe is not easy when booting from the DF0, however when luanching from the DH0 a grabkick that would be capable to save elsewhere (DH0/DF0?) might help.

Finally, you may consider showing the kickstart version in the initial screen. I know this is readily is available in the initial amiga screen, again this is just for completeness of the screen where you can see the 680x0, AGA/ECS PAC/NTSC and 50/60Hz:-)

Once again, just some ideas. ATK is already very good as it is now!

Thank you for your consideration and keep up the good work.

[fook42]

analysing multiple roms on 27C800 or 27C160s, etc.

this may not be possible, as only one kickstart-image is visible (at $F80000) at one time... the others are not accessible, as their "switch"-line is not tied to any CPU address-line. BTW: grabkick is not needed at all, to have access to the kickstart-memory ... this can be done directly, without the need to dump an image.

[roc-eab]

Hi Fook,

Thanks for the clarification about the kickstart multiple roms. This is clearly not feasible.

Just consider that a list of ideas regarding the kickstart, should you guys find any value in the proposals.

My most wanted would be the (probably) easiest one: To have the KS release in the initial screen, to summurise specs at a glance. Moreover, while for 2.x and newer, the precise release is visible in the initial screen, this is less easy to identify for 1.x where subreleases should be retrieved elsewhere because they all show 1.1 or 1.2. Finally, there are two version of the 34.005 (one for A500/2000 and one for the A3000). The latter with CRC E0F37258 is the one which supports up to 2 MB of chip and have a valid checksum.

Once again, just a wish-list :-)

[fook42]

created a small patch for the kickstart-version display.. looks like this on the main menu. would that be sufficient? or do you mean to have a complete analysation of the kickstart-structure (module versions, checksum, etc?)

this implementation only displays the version of the rom-image at $F80000, not any soft-kicked kickstart...

[keirf]

It's taking a bunch of status-line real estate for not a whole lot of use. I don't know. The line will probably overflow if presented with a "68060EC/LC Rev x" which significantly widens space taken for CPU report.

Otoh maybe we make a second line of status stuff.

[keirf]

Or go the whole hog with full module report, and put it all under a sub menu (F1 Memory, Kickstart and then a submenu of that?)

[fook42]

Lets recap what ATK is used for: to have a tool, that gives information on the computer when we can not look inside and when we dont know which machine it is at all. for example having an A500-box on the desk, but not knowing if its an A500 rev3, rev5, A500+, A500 with/out RTC, big fat Agnus or not, working ports(mouse,serial,rgb...) , diskdrives, ... stuff like that seems important to me. And of course, there is a lot to find out about the kickstart-rom, which is also "just another chip inside" .. like the mentioned differences on the version - thus displaying the version of used kickstart is giving a valuable information.

Analyzing the kickstart in total will need a lot of code and extra menus or screens (think of all the texts on modules, versions, kickstart-memorys, reset-vectors(?maybe needed for softkicked kickstarts) etc...) - but will this help you to determine, whether your machine is healthy or not? and if you know, for example, that you're having an scsi.device of version 39.x .. inside your kickstart 3.0 .. can you change this ? - you may exchange kick 3.0 with 3.1 or whatever, but the details on the build-in modules are not easily under our control, i guess.

[keirf]

Well version is displayed on the boot screen of the Amiga. From v1.2 at least (and 1.0/1.1 would be notable by absence of version number, and are exceedingly rare). And the full version number is also displayed from v2.0 onwards. It's not really very hidden.

But you could kick it down onto a second status line, and see how that looks. We lose the blank line above 'Help: Reset' but that doesn't matter. We could also then decode the Kickstart major to the user-friendly number. eg 'ROM 40.070 (v3.1)'

[roc-eab]

Thanks both for the quick consideration !

Something like "ROM 40.070 (v3.1)" would be just great :-) But then again, up to you where and how to place it.

[fook42]

my proposal is implemented (see above) and looks like this:

[roc-eab]

Superb. Many thanks!

[keirf]

Well ok. It does take up a line to tell you something the boot screen already tells you though.

[fook42]

got your point and i can agree to skip/not include this additional display of a more or less redundant information...

but not due to the reason of "taking up a line" of the main screen. the output of build-time is also not giving any information about the computer it runs on at all and neither about the version of ATK as it lacks the commit-id... ;-)

[keirf]

You're right the build time is pretty pointless, especially for proper releases. I do like to tag interim builds somehow. I suppose commit-id would be better though... So: version number for proper releases, 32-bit prefix of commit-id for interim builds? eg. "Amiga Test Kit [7c3498cf] - by Keir Fraser"? Or some other decoration?

I could identify proper releases by looking for a testkit-vN tag. I suppose I will need some script fu to pull this stuff out....

[fook42]

:-) keir.. you're overengineering it .. g leave the version numer in the top row as it is - noone else would ever have a look at the commit-ids; as long as you're releasing proper versions of ATK from time to time, it wont be necessary to use a odd commit inbetween, i guess.

[keirf]

This is cleaned up (maintaining your commit history) and committed to master.