Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Hollywood MAL AMIStore App Store A600 Memory

AuthorTopic: AmigaOS 68k development - components, critics, bugs, work-arounds, tips&tricks  (Read 17255 times)

0 Members and 1 Guest are viewing this topic.

Offline kolla

The lower 0xE0 ROM space is now populated by the Vampires, so this option is taken as well.

The Vampires already support 1MB kickstarts, AROS uses 1MB kickstarts, and if there is any trouble regarding addresses, the Vampire products are still supported and the issues can be dealt with in updates. So, I believe your argument is pretty weak.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM460 and Mac minis with MorphOS
 

guest11527

  • Guest
The lower 0xE0 ROM space is now populated by the Vampires, so this option is taken as well.

The Vampires already support 1MB kickstarts, AROS uses 1MB kickstarts, and if there is any trouble regarding addresses,
The vampires use the lower kickstart area to patch in their exec scheduler replacement for the extended register set, and their own AROS image (which comes with the modified scheduler). The original kickstart does not run unmodified on it to my very knowledge. There is some on-the-fly patch addressed to it to make it search the lower 512K area (which is not populated and not in the kick modules search list).

Thus, instead of following good engineering practise and use available extension mechanisms such as autoconf or the F-space ("debug") ROM or a CPU library, the vampire relies on its own mechanisms, which partially populates the E0-area, yes.
 

Offline kolla

Thus, instead of following good engineering practise and use available extension mechanisms such as autoconf or the F-space ("debug") ROM or a CPU library, the vampire relies on its own mechanisms, which partially populates the E0-area, yes.

Good, then I suggest ignoring the Vampire cards and if things break, it will be up to them to fix it - after all, the 68080 has a proper MMU which they control fully, how hard can it be.
« Last Edit: October 31, 2019, 08:15:21 AM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM460 and Mac minis with MorphOS
 

guest11527

  • Guest
Good, then I suggest ignoring the Vampire cards and if things break, it will be up to them to fix it - after all, the 68080 has a proper MMU which they control fully, how hard can it be.
I don't know what you call "proper", and I don't see how the (rather minimal and incompatible to anything instead of proper) MMU has to do anything with the issue. It cannot remap address spaces.

 

Offline kolla

I don't know what you call "proper", and I don't see how the (rather minimal and incompatible to anything instead of proper) MMU has to do anything with the issue. It cannot remap address spaces.
From what I understand, that is the entire job of the "proper MMU" of the 68080 on the Vampire cards - to map addresses around so that AmigaOS (or EmuTOS) finds what it expects at the addresses it expects. For example, with "v3 core", map the entire chipset register address space out to where SAGA is located.

But regardless of this, it should be none of your concerns, and instead a concern for those who keep breaking "the rules".
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM460 and Mac minis with MorphOS
 

Offline DamageX

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 kolla

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

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.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM460 and Mac minis with MorphOS
 

Offline kolla

Everything except the initial hardware diagnostics and the decompressor could be compressed.
Just to elaborate on this - exactly what, in your opinion, can be compressed?
Here is the content of the A1200 CBM OS3.1 40.68 kickstart
Code: [Select]
exec                                    14K
expansion                              2.8K
romboot                                3.8K
graphics.library                       104K
dos.library                             39K
filesystem                              24K
console.device                          15K
layers.library                          13K
scsi.device                             10K
con-handler                             10K
input                                  5.8K
audio.device                           4.3K
card.resource                          3.1K
utility.library                        2.5K
battclock.resource                     2.4K
ramlib                                 1.1K
ramdrive                               1.6K
cia.resource                           1.0K
misc.resource                          236B
wbtask                                 252B
potgo.resource                         376B
filesystem.resource                    472B
disk.resource                          908B
mathffp.library                        1.2K
timer.device                           3.6K
mathieeesingbas.library                3.7K
keymap.library                         3.3K
bootmenu                               5.7K
trackdisk.device                       7.3K
icon.library                           9.2K
ram-handler                            9.2K
shell                                   17K
intuition.library                      112K
gadtools.library                        23K
workbench.library                       70K
battmem.resource                       544B
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM460 and Mac minis with MorphOS
 

guest11527

  • Guest
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.
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).

Thus, it would enlarge the RAM footprint (by approximately 512K), and thus make the kickstart less attractive to use on low-end machines.

3.1.4 requires 1.5MB ram minimum to run it comfortable. (1MB RAM extension plus 512K chipmem). With an additional 512K RAM required for the kickstart, users would already need a 2MB RAM expansion.

I don't consider this a good option.

Offline DamageX

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

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

Offline psxphill

It would also require to include relocation information in the (ROM) based compressed image.

I used skick/mkick for a while, RTB/PAT files for skick/mkick would be nice. Although I'm not sure about the benefits of compressing it into a ROM
 

guest11527

  • Guest
This has nothing to do with a MMU. You cannot run compressed code directly anyhow, so it does not make sense to remap anything to anywhere. As compressed code requires decompression first, and the ROM area would be populated (otherwise compression would not make sense), you need to decompress to RAM, and as you decompress to RAM, you need to relocate as you do not know where the target RAM will be.

This is neither related to SKick, as - again - SKick maps the ROM to RAM, though with relocation information - but mapping a compressed image to some place makes neither sense.

One way or another, this is not a good option. It requires more RAM, not just the decompressor, and as most users use hard disks anyhow, it is much simpler to load the modules missing in ROM from harddisk instead. It also makes the kickstart more flexible.

The kickstart comes with sufficient components to give you access to the system, and - starting with 3.2 - also with sufficient functionality to update many modules from harddisk should the disk contain newer components. There is really no need to spoil RAM for compression that is not needed.

 
The following users thanked this post: Tygre

Offline kolla

That’s of little use when “most user” wants to boot from floppy or ADF, disabling the hard drives to save the little ram there is.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM460 and Mac minis with MorphOS
 

guest11527

  • Guest
That’s of little use when “most user” wants to boot from floppy or ADF, disabling the hard drives to save the little ram there is.
Ah, and you know what "most users want"? If so, my thesis would rather be "most users want the kickstart to be able to boot into games". And for that, you typically neither need a workbench, nor would compressed components in ROM be any helpful. Frankly, if this is all you want, then Kickstart 1.3 is probably your best option.