Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: Cosmos Amiga on February 15, 2016, 03:15:50 PM
-
I added a second socket on my CD32 with few components to make 2 eeproms available
==> http://leblogdecosmos.blogspot.fr/2016/02/cd32-kick-39-i.html
1 MB Kickstart 3.1 on now two eeproms works fine !
But, 2 MB failed... Zero boot, nothing...
==> http://leblogdecosmos.blogspot.fr/2016/02/cd32-kick-39-ii.html
I built a new 2 MB Kickstart like this :
- $00A80000 (512 KB) = icon.library_46.4.418
- $00B00000 (512 KB) = workbench.library_45.132
- $00E00000 (512 KB) = RomStartCD32 / checkdisk_37.21 / cdstrap_40.13 / cdui.library_40.20...
- $00F80000 (512 KB) = exec_40.9(CD32) / audio.device_37.1 / battclock.resource_39.3 / battmem.resource_39.2...
Where is my mistake ?
Any ideas ?
Thanks,
-
Your icon.library is outdated, I'm on 46.4.420 :D
-
Where is my mistake ?
Any ideas ?
Thanks,
Did you verify that all the components which you put into ROM are actually designed to run out of read-only memory? I'm not entirely sure that workbench.library V45 will run properly in this context. The same goes for icon.library.
Also worth checking is the order in which the components are initialized by exec (in "exec/resident.i", the "RT_PRI" field), as well as if the flags in the Resident structure are set up properly for the task (the "RT_FLAGS" field).
If you can build a 2 MByte ROM image in memory, perform the same kind of ROM tag scan which the exec cold start code does, can you verify that all components are found, have the proper priorities and the appropriate flags set?
As for the memory ranges you are using I believe that these will work correctly with the CD32 exec.
-
Did you verify that all the components which you put into ROM are actually designed to run out of read-only memory? I'm not entirely sure that workbench.library V45 will run properly in this context. The same goes for icon.library.
Also worth checking is the order in which the components are initialized by exec (in "exec/resident.i", the "RT_PRI" field), as well as if the flags in the Resident structure are set up properly for the task (the "RT_FLAGS" field).
If you can build a 2 MByte ROM image in memory, perform the same kind of ROM tag scan which the exec cold start code does, can you verify that all components are found, have the proper priorities and the appropriate flags set?
As for the memory ranges you are using I believe that these will work correctly with the CD32 exec.
All libraries are romable, and used since a very long time into $E0 and/or $F8 : the issue is elsewhere...
Maybe the four 512 KB blocs are in a incorrect order ?
I repeat : when I build the 1 MB CD32 Kickstart 3.1 on TWO eeproms ($E0 & $F8), all is fine, the console start and run nicely...
For the 2 MB Kickstart, I begin with $A0, $B8, $E0 and then $F8. I guess the issue is here, because I use 4 blocs now and not 2 anymore...
-
Maybe the four 512 KB blocs are in a incorrect order ?
Maybe, try doubling up your working 1mb 3.1 and see what happens. Hex edit some strings that you see early on at boot to figure out what goes where. If you can then boot to some form of monitor then you can view memory.
-
Interesting. Never looked closely at a CD32, I had no idea they only had a single ROM chip, but space for a second. Sorry I can't help with your question, but thanks for helping me learn something new! :) Any performance improvement going from 16-bit to 32-bit?
-
Interesting. Never looked closely at a CD32, I had no idea they only had a single ROM chip, but space for a second. Sorry I can't help with your question, but thanks for helping me learn something new! :) Any performance improvement going from 16-bit to 32-bit?
CD32 has a single 16 bit rom, but the schematic shows you how to hook up a second rom so it works in 32bit mode. Apparently in 16bit mode it's not laid out the same as any other Amiga 16bit rom because high and low words are stored separately.
http://eab.abime.net/showthread.php?t=71509
The thread appears to show that my idea wouldn't work as it would see the same modules in both.
Probably best way would be to hack together a small boot rom that purely sets up a screen and dumps out hex from various addresses and see if you can get that to run.
-
CD32 has a single 16 bit rom, but the schematic shows you how to hook up a second rom so it works in 32bit mode. Apparently in 16bit mode it's not laid out the same as any other Amiga 16bit rom because high and low words are stored separately.
http://eab.abime.net/showthread.php?t=71509
The thread appears to show that my idea wouldn't work as it would see the same modules in both.
Probably best way would be to hack together a small boot rom that purely sets up a screen and dumps out hex from various addresses and see if you can get that to run.
I use $B0 who is for the FMV module : when I plug it, the FMV's eprom is read...
Maybe the problem is $A8 (extended Rom CD1200)...
-
All libraries are romable, and used since a very long time into $E0 and/or $F8 : the issue is elsewhere...
Maybe the four 512 KB blocs are in a incorrect order ?
The order should not matter. If I remember correctly, the exec coldstart code scans a list of memory spaces for resident tags, i.e. what's defined in "exec/resident.i" and each of these goes into a list, sorted by priority. This means that no matter in which memory space a resident tag is found, the priority defines when it is initialized.
Once the resident tag list is assembled, first the components which precede expansion.library are initialized (that's usually just exec.library, if I remember correctly), then the rest are initialized one after another until eventually something tickles dos.library, kicking off the user-visible part of the system boot process.
The CD32 ROM checks the following areas for resident tags, in this specific order:
0x00F80000 - 0x00FFFFFE (512K Kickstart ROM)
0x00E00000 - 0x00E7FFFE (CD32 ROM)
0x00A80000 - 0x00B7FFFE (CD32 FMV ROM)
0x00F00000 - 0x00F7FFFE (diagnostic cartridge)
Note that only the CD32-specific Kickstart ROM looks into the CD32 ROM and FMV ROM address spaces. The desktop Kickstart ROM only checks the Kickstart ROM space and the diagnostic cartridge areas.
-
The order should not matter. If I remember correctly, the exec coldstart code scans a list of memory spaces for resident tags, i.e. what's defined in "exec/resident.i" and each of these goes into a list, sorted by priority. This means that no matter in which memory space a resident tag is found, the priority defines when it is initialized.
Once the resident tag list is assembled, first the components which precede expansion.library are initialized (that's usually just exec.library, if I remember correctly), then the rest are initialized one after another until eventually something tickles dos.library, kicking off the user-visible part of the system boot process.
The CD32 ROM checks the following areas for resident tags, in this specific order:
0x00F80000 - 0x00FFFFFE (512K Kickstart ROM)
0x00E00000 - 0x00E7FFFE (CD32 ROM)
0x00A80000 - 0x00B7FFFE (CD32 FMV ROM)
0x00F00000 - 0x00F7FFFE (diagnostic cartridge)
Note that only the CD32-specific Kickstart ROM looks into the CD32 ROM and FMV ROM address spaces. The desktop Kickstart ROM only checks the Kickstart ROM space and the diagnostic cartridge areas.
I understand what you write !
My main problem is : the exec don't start with my rom build !
Zero, nada, quedalle, nein, no, nothing at power on...
-
I understand what you write !
My main problem is : the exec don't start with my rom build !
Zero, nada, quedalle, nein, no, nothing at power on...
So, can you pinpoint where it gets stuck, exactly? You already have an 1 MByte ROM image in working order. What could you put into the FMV ROM space that is as simple as it could be and still show if that ROM is being used? Could you create a resident tag that calls kprintf(), etc. or toggles the LED?
If decoding of the FMV ROM space is wonky then exec shouldn't be able to find a proper resident tag in the first place. If accessing the FMV ROM space itself bombs then you should be able to test for that by removing the FMV ROM area from the exec scan list (it's very close to the beginning of the Kickstart ROM) and check what happens. Either remove it or make the space shorter that is being scanned. The original FMV ROM was supposed to be rather short in the first place, so scanning the entire ROM space is probably not necessary, maybe it wasn't even ever tested.
-
I do some testing on my 1200 this time, and if my understanding is good I guess the 2 eproms U6A/U6B are limited by hardware to 1 MB maximum...
$A8 seems mirrored to $E0...
:(
-
I guess Cosmos has been so busy building 2 MB Kickstart's he forgot to update this thread: :D
http://leblogdecosmos.blogspot.com/2017/07/kickstart-2-mo-a1200.html
http://leblogdecosmos.blogspot.com/2017/07/kickstart-2-mo-cd32.html
http://leblogdecosmos.blogspot.com/2017/07/kickstart-2-mo-a600.html