Welcome, Guest. Please login or register.

Author Topic: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks  (Read 47508 times)

Description:

0 Members and 2 Guests are viewing this topic.

Offline DamageX

  • Sr. Member
  • ****
  • Join Date: Jun 2005
  • Posts: 339
    • Show all replies
    • http://www.hyakushiki.net/
I'm not up to speed on everything so I could be talking nonsense, but what about making a compressed ROM image which is able to fit more stuff. The kickstart on '030+ systems is often copied to fastRAM anyway.
 

Offline DamageX

  • Sr. Member
  • ****
  • Join Date: Jun 2005
  • Posts: 339
    • Show all replies
    • http://www.hyakushiki.net/
I'm not up to speed on everything so I could be talking nonsense, but what about making a compressed ROM image which is able to fit more stuff. The kickstart on '030+ systems is often copied to fastRAM anyway.
I believe your first observation is the most accurate one :) At best, only parts of the kickstart can be compressed, and you would also need a decompressor and validator in place... it quickly grows bigger than what you gain.
Everything except the initial hardware diagnostics and the decompressor could be compressed. Decompressor is easily less than 1KB. BTW, this is how PC BIOS ROMs have been since the mid '90s.
 

Offline DamageX

  • Sr. Member
  • ****
  • Join Date: Jun 2005
  • Posts: 339
    • Show all replies
    • http://www.hyakushiki.net/
Yes, they even use Lha from what I recall. However, the Amiga kickstart, is not the equivalent of a BIOS, and when did you last see a BIOS that was 512kB? :)
Um... today? 512KB BIOS is common on 200x era PCs.
Quote
What I suggest is to keep the Amiga kickstart small yet functional - strip the "user interface" parts (shell, workbench.library and icon.library) to their bare minimums, enough to boot and work with legacy floppies. They can be replaced with feature rich on-disk variants when booting off hard drives.
This is also not a bad idea. In your list graphics.library and intuition are the biggest chunks, and their only use before booting is what, the early startup menu where you get to pick between NTSC/PAL, etc.?
 

Offline DamageX

  • Sr. Member
  • ****
  • Join Date: Jun 2005
  • Posts: 339
    • Show all replies
    • http://www.hyakushiki.net/
First, this not only requires compressing the binaries. It would also require to include relocation information in the (ROM) based compressed image. It also means that the data needs to be decompressed to some place since it could no longer run from ROM (as it does now).
Yes, decompressing (the whole thing, or close to it, in one big block) to somewhere. That's what I was hinting at when I mentioned the practice of relocating ROM to fastram via the MMU.

I don't know how feasible it is to run everything from a nonstandard memory region (ie. not using the MMU to remap it to the ROM area). I'm guessing your suggestion of relocs is based on the fact that fastRAM uses different addresses depending on the hardware setup? How far along in the boot process do you have to get before accelerator/expansion card RAM configuration is known?

Obviously, lack of RAM and/or MMU (and maybe decompression time) would preclude this type of build from being used with low-end machines. But users of low-end setups probably have a shorter wishlist of functionality they want to have added into kickstart. I don't know if you already have separate variants of the ROM for different machines, or one for ECS and one for AGA or what...