As we are all aware (or not), we do not have the CFE source code for the X1000 that includes the changes from PA-Semi and Hyperion. However, we do have the full CFE source code prior to those specific changes. Combined with Ghidra for PowerPC decompilation and various disassembly tools-plus the knowledge I gained working on the PA6T network driver regarding CFE binaries and its API-it is now possible to create CFE patches even without the original source code.
All patches done on "cfe_2012_june_08.lha" version, on the boot you should have: "Build Date: Fri Jun 8 16:04:49 CEST 2012 (hfrieden@jumpgate)"
or check it from CFE promt:
CFE> d 0x7FDC4028 .
Note that x1000's CFE firmware is the property of A-EON/Trevor, so I cannot distribute a ready-to-use patched version of x1000's CFE myself (right? or can i?). But what I can distribute later for the brave is a tool to patch your own CFE. Of course, I will test everything on my own hardware first; I currently have a hardware programmer, so I can wipe and re-flash at any time without risk.
That is for later, though. Currently, I am making all patches "real-time," meaning you don’t need to re-flash anything. They reside only in the current CFE memory and will be gone after a reboot or power-off.
What is the practical use of this in its current form ?
You can add them to CFE and have them run at boot, or manually load them via TFTP. The real goal is to verify that they fix existing issues without introducing new ones. Once everything is stable enough, I will start experimenting with my own flash to make them permanent.
In other words: any X1000 user can play with these now without fear. However, if you "burn and die," I take no responsibility. You should know what you are doing.
Running the patches
Patches should be executed using the boot -elf -noints xxxxxx.elf command. Both flags are necessary (without -noints, the system will simply reboot after a few seconds). You can run patches in any way you wish - just one per session, or all 3 at once (the hooks are placed at different addresses and do not interfere with each other), like:
or if you have no CF card, you can simply put the patches on your Amiga FFS BOOT partition alongside your amigaboot.of, and run them from there. These patches are built in a way that will not crash even if run from CFE's AmigaFS, which lacks (or has a broken/unimplemented) seek() implementation, so this will work too:
To make them run automatically (all patches, or just one - which will likely be keycon for most of us), change your STARTUP label from just set pmu -astate=a4; menu to:
- Added probing for Channel 1, so SATA ports 3 and 1 now work. - Fixed detection of "slave" devices even if no "master" is present. - Devices on any port will now be detected. You can have Port 0 (Ch0) and Port 3 (Ch1), or Port 2 (Ch0) and Port 1 (Ch1) working together, etc.
Patch #2: Keyboard/Console (keycon.elf)
- Key repeat - Holding a key now auto-repeats (500ms delay, ~33/sec repeat) - Home/End keys - Jump to beginning/end of line - Delete key - Forward delete with repeat - VESA cross-line backspace - Backspace at column 0 now wraps to end of previous line (was moving cursor off-screen to pixel x=-8) - VESA cross-line left arrow - Left arrow at column 0 also wraps to previous line - VESA ghost character fix - Up/Down history no longer leaves remnants of longer commands (VGA's writechar didn't implement it originally)
Patch #3: External commands (cmds.elf)
- "cls" - clear the screen - "version" - returns the CFE version.
Maybe there is a way to change the astate? 200Mhz more can be nice and my procesor temp is always low at around 40 degree Celsius so temp wise ist see no Problem.
Maybe there is a way to change the astate? 200Mhz more can be nice and my procesor temp is always low at around 40 degree Celsius so temp wise ist see no Problem.
Yes, but you probably mean set it right once computer boots, and cfe only starts to load things up to speed up whole CFE booting process? Or you mean to change state when we already have CFE loaded till the prompt/menu ?
Why i ask it's because for now we do real-time patches, mean we need environment of CFE from where we run them. So we already in loaded CFE, where we already can do "set pmu -astate=a4" which as far as i understand (seeing linux's cpu_freq.c and cfe's disassembly) doing exactly that, set it to 1.8ghz
So probably what you mean is to set it to 1800 right at the beginning of reading date from EEPROM so to have 1800 for whole process till menu, which can only be done by permanent patches later, not by real time one.
Ah okay. I thought it is possible to use modes A5 and A6. From what i understand, they’ve been removed in linux, but maybe its possible to add them. I have no idea.
*/We support 5(A0-A4) power states excluding turbo(A5-A6) modes */
Ah okay. I thought it is possible to use modes A5 and A6. From what i understand, they’ve been removed in linux, but maybe its possible to add them. I have no idea.
@TerasOfME And now about this A5/A6 thing, i find out how bypass it easy:
CFE> set pmu -astate=a0
CFE> set astate 4 -speed=2000
CFE> set pmu -astate=a4
CFE> show pmu
By some reasons we can't set to 5 or to 6 (probably that what they removed, simple you can't use number more than 4), but you simple can set to any of those any value you need, i tried 1900 and 2000, and they both works, there we go:
(press open in new tab for full size):
In other words there maybe worth to patch to have 5 and 6 be 1900 and 2000 or something, just to avoid typing it all manually, but for while being it all can be added right in STARTUP, like:
set pmu -astate=a0; set astate 4 -speed=2000; set pmu -astate=a4; menu
Through i do not know how stable it all and how hot it all, but from what i understand, for the 1200, 1600 and 1800 (i.e. a2, a3 and a4) we have 1:1 the same voltage , and only less for a0 (500 mhz) and a1 (800 mhz). So, everything which we set above to a4, will be of the same voltage (so it shouldn't be hot or anything), just with bigger frequency.
And as i read in the Elektra's uboot code (pre-Nemo board), you can't set more than this voltage programmable, so to not burn it. What mean that we can test any value until we hit a wall with stability, maybe even 2200 will be ok , who know. 2000 seems fine, but that all need tests of course, especially if it indeed no voltage increase.
EDIT: ok, found:
2600mhz - freeze 2500mhz - freeze 2400mhz - exception (MCE 0x200) 2300mhz - back to CFE prompt OK, but calling "menu" -> freeze 2200mhz - much better, can start OS, but once workbench loads all sorts of freezes 2100mhz - amigaos runs fine, inside run Spencer game and play for a few minutes.
So, our safe limit is 2100. Which is also good enough, just ~16% for free from nothing. Of course that need more stress tests, but even if it will be "just" 2000 in end, that not bad too imho. Need to test some real life apps to measure if it real gain, and not just numbers.
EDIT2: Actually, Sysmon's RAgemem benchmark on my 2100 over stock 1800 x1000 shows now +13-17% everywhere. Same as sortbench : +17% everywhere. And same as SDL Bench.. Quite cool !
Edited by kas1e on 2026/4/1 22:32:29 Edited by kas1e on 2026/4/1 22:42:21 Edited by kas1e on 2026/4/1 22:44:20 Edited by kas1e on 2026/4/1 22:49:00
P.S.: Edit: sata.elf I don't now. I have only started it and don't look further into it.
Edited by TearsOfMe on 2026/4/2 11:06:46 Edited by TearsOfMe on 2026/4/2 11:08:15 Edited by TearsOfMe on 2026/4/2 15:24:51 Edited by TearsOfMe on 2026/4/2 16:27:08
cmds.elf: works nice ( I have the same CFE version "Build Date: Fri Jun 8 16:04:49 CEST 2012 (hfrieden@jumpgate)" help is much more useful than original - btw are there any way how pause help listing on screen?
keycon.elf: it is very nice upgrade - especially cross-line backspace I love
sata.elf: not works for me or I made something wrong. Patch booted OK ( command status = 0 ), But I not seen disks on ide0.2 and 0.3 - they are not in show devices and dir command returns: Could not init file system: Insufficient memory. Dir with 0.0 worked normally. Note: On sb600sata.device:3 I have HDD with another bootable ffs partition with amigaboot.of
Overclocking: you are The KING! Thanks, really easy if we know what to do. Brilliant advice!
P.S. After 30 minutes of 100% CPU load with Tower57 temperature is 52°C, Nice!
Edited by sailor on 2026/4/2 16:19:43
AmigaOS3: Amiga 1200 AmigaOS4: Micro A1-C, AmigaOne XE, Pegasos II, Sam440ep, Sam440ep-flex, AmigaOne X1000 MorphOS: Efika 5200b, Pegasos I, Pegasos II, Powerbook, Mac Mini, iMac, Powermac Quad
@Breed You can play with no fear, they reflash nothing, they all just "in memory" patches, so once reboot they gone. But i understand the fear of course :)
@Sailor Test for example without patch just on port 2 one hdd, or on port 3: without patch they didnt detected, with patch should. I tried myself just 2 disks at once in any port, but didnt tried 3 at once.. try plz if 2 and 3 ports works with patch when single (and didnt without). Also just 2 disks anywhere with and without. And then again 3. All with show devices, so we will know when/where it go wrong. Maybe issue just with 3 devices at once and show device think that only 1 master amd 1 slave can be emulated on channel0 (second channel wasnt enabled in cfe at all before)
As for paging/pause : yes added yesterday, just not as good as i wish, but will be in next upload.
@K-L Hold on for some days i trying to fix radeonrx in cfe, have good progress already! But, you will need serial cable anyway , so once you poweron with radeonrx and gpio10 jumper will bring you to serial, you will be in needs to do load of fix (which you place to your ffs partition before) and once it will work add it to STARTUP permanently like "set pmu -astate=a4; boot -elf -noints -fs=amigafs ide0.0:radeonrx.elf; menu". I hope to deal with as chances high: i found why and where issue come, and i am able to test my radeonrx in x1000 already (gpiov10 jumper + serial + vga commands from cfe).
2600mhz - freeze 2500mhz - freeze 2400mhz - exception (MCE 0x200) 2300mhz - back to CFE prompt OK, but calling "menu" -> freeze 2200mhz - much better, can start OS, but once workbench loads all sorts of freezes 2100mhz - amigaos runs fine, inside run Spencer game and play for a few minutes.
So, our safe limit is 2100. Which is also good enough, just ~16% for free from nothing. Of course that need more stress tests, but even if it will be "just" 2000 in end, that not bad too imho. Need to test some real life apps to measure if it real gain, and not just numbers.
EDIT2: Actually, Sysmon's RAgemem benchmark on my 2100 over stock 1800 x1000 shows now +13-17% everywhere. Same as sortbench : +17% everywhere. And same as SDL Bench.. Quite cool !
I confirm: My X1000 with AmigaOS is stable @2100 MHz, tested with several games and 30' at CPU load 100%. Linux ( DebianSid) freezes @2100, and is stable@2000 MHz. Maybe because it uses both cores?
AmigaOS3: Amiga 1200 AmigaOS4: Micro A1-C, AmigaOne XE, Pegasos II, Sam440ep, Sam440ep-flex, AmigaOne X1000 MorphOS: Efika 5200b, Pegasos I, Pegasos II, Powerbook, Mac Mini, iMac, Powermac Quad
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
