@K-L

Quote:

DMA is already enabled on X1000.

What kind of DMA? Video DMA? It certainly can't be drive DMA as the loading looks slow. Compared to videos of the X5000 booting even USB looks swift.

@amigadave

Quote:

I hope that using uboot instead of CFE, will solve the problem that is currently preventing Radeon's Polaris based video cards from working in the X1000.

If UBoot was ported to the X1000, an obvious but untested way to boot OS4, might be using the X5000 bootloader amigaboot.ub.

Another issue, found with HD6000 and HD7000 series Radeon cards, is inability to do a software hard reset. There are known issues with soft rebooting from some cards but there is also an issue when CFE does a card reset that fails to initialise the display. Which is rather strange if it's doing a hard reset from a working hardware state.

@K-L

Quote:

K-L wrote: @billt DMA is already enabled on X1000.

the topic is cfe and not the x1000 in general. of course does the x1000 (os4) use dma.
it was told some years ago that the slow loading of the kickstart files on the x1000 is mainly caused by the non-usage of dma transfer inside cfe.

regards...
michael

_________________
Michael Merkel
(Michael.Merkel@gmx.net Home)
Member of Amiga-Freunde Pfalz, OS4 Welt

@MichaelMerkel

The speed in loading the modules isn't realy that bad. Its the long wait before you get to kickstart loading. The CPU is running at 500Mhz and only switches to CFE ENV controlled CPU speed once the menu appears.

I'd be willing to buy a reasonably priced upgrade if the X1000 got support for Polaris and an option to unlock the CPU so it can run at its 2.0Ghz.

_________________
A1200T 603e 330Mhz - Mediator TX OS4.1 F.E.
CDTV 8MB Fast, OS3.1, SCSI, MicroSD SCSI & CD32 FMV
X5000, X1000, A1XE with OS4.1F.E.

@MichaelMerkel

The reason I brought up the DMA item, was in case there is any firmware bringup required in order to support the "DMA Engine", as described at

https://www.youtube.com/watch?v=70xbiigwobs

As the x1000 is conspiciously absent form the list of machines targetted for DMA Engine support, in case CFE is some part of that exclusion, it would be nice to solve that problem, and have more reason to have x1000 added to this list of supported machines. I do not know that CFE is or contributes to this, but in case it is, then let's remove any obstacles possible to be removed, for any features...

I was not aware that DMA might be affecting boot time, but I am for improving anything else that other people know of about this as well as for DMA Engine...

Last edited by billt on 09-Mar-2020 at 10:31 PM.
Last edited by billt on 09-Mar-2020 at 10:26 PM.

_________________
All glory to the Hypnotoad!

@MichaelMerkel

I don't see lack of DMA as an issue. But using PIO 0 is an issue. Sure it's a good fallback but surely it should be using the best PIO mode it can find. PIO 0 belongs in the retro age of the A1200/A4000 IDE controllers and that's where it should stay. PIO can shift 16MB/s which is a reasonable speed. At that speed the Kickstart could and should load in two seconds flat with overhead.

@Hypex

Quote:

Hypex wrote: @amigadave Quote: I hope that using uboot instead of CFE, will solve the problem that is currently preventing Radeon's Polaris based video cards from working in the X1000. If UBoot was ported to the X1000, an obvious but untested way to boot OS4, might be using the X5000 bootloader amigaboot.ub. Another issue, found with HD6000 and HD7000 series Radeon cards, is inability to do a software hard reset. There are known issues with soft rebooting from some cards but there is also an issue when CFE does a card reset that fails to initialise the display. Which is rather strange if it's doing a hard reset from a working hardware state.

As I have stated in other forum threads, I currently have a Radeon HD 7850 installed in my Windows PC, which I want to upgrade, with the hopes that the HD 7850 will work in my X1000, but there are no guarantees that it will work, from what I have read. Looking for options to purchase as a replacement video card for my Windows PC, I am again thinking of getting a Radeon video card, that perhaps I can again move to the X1000, at some distant future point in time. So, I'm thinking of getting a Polaris based Radeon video card as an upgrade for my current HD 7850, even though I know that Polaris cards don't currently work in the X1000, and that they might never be able to work in the X1000 in the future. By the time my Windows PC needs another video card after this current upgrade I am thinking of, it will be time to replace the entire motherboard, as well as probably a few other components. I'm thinking that my current motherboard and components probably can last me for another 1.5 to 2 years. Hopefully, within that time, A-Eon will have solved the problem that is preventing any Polaris based video cards from working in the X1000, unless their plan is just to abandon support for that model (which I hope is not the case, and they will support my X1000 long into the future).

Do any of you have suggestions on which Radeon Polaris based video card to get, or is this idea of mine crazy, and I should just get the best rated video card within my $250 to $300 upper limit, and forget ever trying to migrate another video card to my X1000 from my Windows PC?

_________________
Amiga! The computer that inspired so many, to accomplish so much, but has ended up in the hands of . . . . . . . . . .

@Hypex

If DMA access is available, it should be used.
Although I agree, in part, it's still quite functional, many CPU cycles are taken away just with disk access limiting anything with high bandwidth requirements like, encode/decode in video or even multi-track audio.

Suffice to say, I hate PIO modes in AMIGA. Serious limitation that pushed me to PC for my audio work.

https://en.wikipedia.org/wiki/Programmed_input%E2%80%93output

The PIO modes require a great deal of CPU overhead to configure a data transaction and transfer the data. Because of this inefficiency, the DMA (and eventually UDMA) interface was created to increase performance. The simple digital logic required to implement a PIO transfer still makes this transfer method useful today, especially if high transfer rates are not required like in embedded systems, or with FPGA chips where PIO mode can be used without significant performance loss.

....

A PIO Mode 5 was proposed with operation at 22 MB/s, but was never implemented on hard disks because CPUs of the time would have been crippled waiting for the hard disk at the proposed PIO 5 timings, and the DMA standard ultimately obviated it. While no hard drives were ever manufactured to support this mode, some motherboard manufacturers preemptively provided BIOS support for it. PIO Mode 5 can be used with CompactFlash cards connected to IDE via CF-to-IDE adapters.

Last edited by SHADES on 31-Mar-2020 at 12:52 AM.

_________________
It's not the question that's the problem, it's the problem that's the question.

I concur with what has been mentioned already but one thing has not been mentioned yet.


Please, please, please reinstate the ability of the CFE variable keymap_swapaltamiga

In the official AmigaOne X1000 Firmware and Booting Guide (CFE) the keymap_swapaltamiga variable is mentioned on page 12.


At some point the keymap_swapaltamiga boot variable was removed and the key swapping only done after OS4 has loaded in Input Prefs. Why is anyone's guess and IMHO a bad idea to wait until this point.
The key cap positions are physically swapped on the keyboard and thus are a hardware issue, not an OS issue, so should be set by CFE as they used to be. I think maybe it used to be on by default. I do not mind which way it is as long as you can set it to swap keys if you require.

Only after the OS has loaded can you use the keys next to the space bars as Amiga keys which leads to problems if you want to do a soft reboot BEFORE IPrefs has loaded. If for some reason the OS has failed to load you want to boot to the early start up menu and not endup doing a hard reboot instead of a soft one. The atrocious time it takes to load the X1000 from scratch, results in this being a most unattractive occurence!

Same if you are using Linux, despite having physically swapped key caps the ones next to the space bar are treated as ALT not Amiga keys, which when you are used to getting what it says on the key you pressed rather inconvenient.

For consistancy it is best the swap is done in CFE and not the OS Input option. Then they will always be seen as swapped and not just after OS4 has loaded. I am sure nearly all Amiga users are not so stupid to set the swap in BOTH the cfe and the system prefs which of course would set the keys back again!

For those silly enough to do it in both ways - the CFE variable can be read from the OS and the swap already shown in the Input prefs option if it is already done. That would however involve a rewrite of the Input prefs.

If the X1000 gets left behind with support then how long for the x5000 ?

_________________
A1/G4 1GHZ

OS4.1 latest update.
1ghz Radeon Club3d 9250
Usb/Dma fixed.

@amigadave

Quote:

As I have stated in other forum threads, I currently have a Radeon HD 7850 installed in my Windows PC, which I want to upgrade, with the hopes that the HD 7850 will work in my X1000, but there are no guarantees that it will work, from what I have read. Looking for options to purchase as a replacement video card for my Windows PC, I am again thinking of getting a Radeon video card, that perhaps I can again move to the X1000, at some distant future point in time. So, I'm thinking of getting a Polaris based Radeon video card as an upgrade for my current HD 7850, even though I know that Polaris cards don't currently work in the X1000, and that they might never be able to work in the X1000 in the future

The 7850 looks a bit touch and go. It is on the supported list but only select models. If the following list is current.

http://hdrlab.org.nz/projects/amiga-os-4-projects/radeonhd-driver/radeonhd-driver-hardware-compatibility/

Quote:

By the time my Windows PC needs another video card after this current upgrade I am thinking of, it will be time to replace the entire motherboard, as well as probably a few other components. I'm thinking that my current motherboard and components probably can last me for another 1.5 to 2 years. Hopefully, within that time, A-Eon will have solved the problem that is preventing any Polaris based video cards from working in the X1000, unless their plan is just to abandon support for that model (which I hope is not the case, and they will support my X1000 long into the future).

That's the issue. I read it's because of the modern UEFI firmware on cards. Somehow something called CFE isn't able to EFI. Which I thought were the same in the early days.

However, even the info on Rx is light. No mention on the HDR site nor Radeon wiki.

http://wiki.amiga.org/index.php?title=RadeonHD

Did see some info in this AW news post. But it should be available on the standard sites. Too many sites to update in the Amiga world.

https://amigaworld.net/modules/news/article.php?storyid=8282

@SHADES

Quote:

If DMA access is available, it should be used. Although I agree, in part, it's still quite functional, many CPU cycles are taken away just with disk access limiting anything with high bandwidth requirements like, encode/decode in video or even multi-track audio.

I've watched old PCs boot Linux and been amazed at how fast it loads in the kernel and ramdisk. I don't know if it's using a PIO mode. But it easily puts my XE to shame. Both the XE and X1000 boot using PIO0 from what I can tell. However, once the Kickstart loads and AmighaOS is in memory then it would activate and boot off DMA. So from Workbench DMA should be fine. Apart from needing to check firmware settings to enable it. Strange given the firmware doesn't appear to use it.

Quote:

Suffice to say, I hate PIO modes in AMIGA. Serious limitation that pushed me to PC for my audio work.

Oh. In most cases PIO should have only affected IDE hardware. But SCSI was expensive and being phased out by IDE. Unfortunate as SCSI implied DMA and good speeds. But the IDE implementation on the Amiga was inferior. They sacrificed a good working controller for a lesser one because it was cheap. And even now I still haven't seen IDE on the Amiga catch up to 30 year old Amiga SCSI standards. Still using PIO from what I can tell.

Except on AmigaOne hardware where the IDE drivers support UDMA on IDE/SATA cards.

@BillE

Quote:

Please, please, please reinstate the ability of the CFE variable keymap_swapaltamiga

Hang on. I have that variable in my CFE. And it is set!

What if you try putting it back in CFE? It should work.

I use a Mac keyboard on my X1000 and am aware of this issue. But I am able to hard reset from Kickstart. As well as hard and soft reboot from OS4.

Quote:

For consistancy it is best the swap is done in CFE and not the OS Input option. Then they will always be seen as swapped and not just after OS4 has loaded. I am sure nearly all Amiga users are not so stupid to set the swap in BOTH the cfe and the system prefs which of course would set the keys back again!

I need to check my settings but I don't know if it would do that. I see your logic in that it would swap the keys, and doing so twice would swap back, but I'm not aware of it working that way. To my knowledge, CFE would read it, then swap keys. After booting, OS4 would read it, but having destroyed all trace of CFE it would read it fresh and apply it. That's my take.

@Hypex

Quote:

Hypex wrote: @BillE Quote: Please, please, please reinstate the ability of the CFE variable keymap_swapaltamiga Hang on. I have that variable in my CFE. And it is set! What if you try putting it back in CFE? It should work.

doesn't work here
Quote:

I use a Mac keyboard on my X1000 and am aware of this issue. But I am able to hard reset from Kickstart. As well as hard and soft reboot from OS4.

That's not fair, the mac keyboards already have the keys on the correct position!! ;)
I now suppose the variable does not work for you either, else the two keys would be swapped..

Quote:

To my knowledge, CFE would read it, then swap keys. After booting, OS4 would read it, but having destroyed all trace of CFE it would read it fresh and apply it. That's my take.

The thing is, if the variable does not work, and you boot with no startup-sequence, you end up in a shell with the keys swapped. Alt as Amiga and Amiga as Alt. Contrary to your normal experience when the System has fully booted.

Assuming you solved what you came for in that shell environment, you have to remember that CTRL-Amiga-Amiga will reset the machine (starting from CFE again with long boot times), while CTRL-Alt-Alt will reset the OS. Normally, when thes system has fully booted it is the other way around.
Of course I assume the "Swap Alt/Amiga Keys" option is set in Input preferences.

And for everyone booting linux, the keyboard label will say "alt" but it is the meta key intead.

oh, and for everyone who wants to boot linux and has a KVM connected to the X1000.. well he'd better have some spare room and get the second keyboard everytime he wants to boot linux, because KVM and AmigaOne X1000 are not friends.

If someone knows about a KVM-switch which works properly with the X1000, please post the model here.
By properly I mean:
- it does not prevent the X1000 from booting
- the keyboard is recognized and can be used in CFE
- the switching does not crash the USB stack when switching
- the mouse and keyboard are correctly working in the early-start-up screen (the mouse will not just move on direction, horizontally or vertically)
- the multimedia keys code of the keyboard are sent correctly
- it works with ISO 105 keys keyboards too, and not only with 104 ANSI US keyboards.

There are some feature this KVM needs to have.
- It should not cost as much as a computer itself, there are KVM switches for 700EUR.
and some more features it would be nice to have.
- it supports audio switching too.
What is also nice to have,

@Amigo1

Quote:

That's not fair, the mac keyboards already have the keys on the correct position!! ;)I now suppose the variable does not work for you either, else the two keys would be swapped..

I wasn't aware Mac keyboards worked okay. I've had trouble with it before. Now I look at it the Logo keys are in the right spot relative to a real Amiga keyboard.

However, they don't fully work under AmigaOS, as there is no Insert key and PrtSc to act as help. The Help key on a Mac is actually insert. How do Mac people insert things? And IIRC Home is where PrtSc should be. I can't recall if I can bring up the ESS. Then again OS4 is currently broken in the mouse routine as it doesn't detect mouse buttons.

So checking my variable it is set to off.

Quote:

Of course I assume the "Swap Alt/Amiga Keys" option is set in Input preferences.

Mine is off.

Quote:

And for everyone booting linux, the keyboard label will say "alt" but it is the meta key intead.

I would have thought Linux would have a driver to find this out. But I really would have thought this would be standardised into a set of codes. I mean, how can the keyboard not know what key is being pressed? They should have defined a set of Logo and Alt key codes when they came up with this USB standard. They've had long enough. And if they have, why do we have these problems. Something hasn't been well thought out.

So at the heart this isn't a CFE issue but an OS issue in the case of resets. But, not working as it should in CFE would also be annoying.

I wonder if a Kickstart module can be made up, that fixes this, so ESS resets work correctly?

@Hypex

Quote:

What if you try putting it back in CFE? It should work.

I have trid setting it to ON, Y On, 1 and it makes no difference. At some point it has become user defined rather than being a reserved keyword that swaps keys.

Quote:

I use a Mac keyboard on my X1000 and am aware of this issue. But I am able to hard reset from Kickstart. As well as hard and soft reboot from OS4.

Well, as has already been said, the Mac keys don't need swapping as it by default the same as an Amiga keyboard. It is with a PC keyboard where the alt and amiga keys have been physically relocated that this variable is needed to work.

Using prefs fixes them to be correct if running OS4 and Iprefs has run, otherwise the keys are still recognised as a PC keyboard with the keys NOT swapped.

@Amigo1

Quote:

The thing is, if the variable does not work, and you boot with no startup-sequence, you end up in a shell with the keys swapped. Alt as Amiga and Amiga as Alt. Contrary to your normal experience when the System has fully booted. Assuming you solved what you came for in that shell environment, you have to remember that CTRL-Amiga-Amiga will reset the machine (starting from CFE again with long boot times), while CTRL-Alt-Alt will reset the OS. Normally, when thes system has fully booted it is the other way around. Of course I assume the "Swap Alt/Amiga Keys" option is set in Input preferences.

Exactly, and I *always* forget. So instead of quickly rebooting into the OS I end up booting from scratch which unfortunately takes ages and is something you do not want to do unless you really have to. hen that variable did work I never had such problems. I just did not use the OS prefs to swap keys as I did not need to.

@Hypex
Quote:

I wonder if a Kickstart module can be made up, that fixes this, so ESS resets work correctly?

Good point. That would certainly help for the ESM and booting without a Startup-sequence. It still leaves the keys for Linux set up the wrong way though if not done at the CFE stage.

@Amigo1

Quote:

- the mouse and keyboard are correctly working in the early-start-up screen (the mouse will not just move on direction, horizontally or vertically)

I have had that too, vertical movement only and never used a KVM switch. I think it was caused and then corrected by using the latest bootmouse.usbfd in kickstart. That may not be necessarily a KVM issue.

@BillE

Quote:

I have trid setting it to ON, Y On, 1 and it makes no difference. At some point it has become user defined rather than being a reserved keyword that swaps keys.

I can confirm the variable has been removed. It's listed in Documentation/Libs/keymap_lib.readme.

The "keymap_swapaltamiga" firmware variable has been removed and replaced
with an equivalent user Input preferences option.

keymap.library 53.8, Input 53.5 and IPrefs 53.23 are required.

I've submtited a bug report about this situation. There were some related ones but as this relates directly to keymap_swapaltamiga I felt a new one was needed.

Quote:

Exactly, and I *always* forget. So instead of quickly rebooting into the OS I end up booting from scratch which unfortunately takes ages and is something you do not want to do unless you really have to.

In cases where the user needs to reset, they can and have pressed the wrong reset combo, meaning they need to remember the keys are wrong before making a mistake. Two wrongs don't make a right.

Quote:

Good point. That would certainly help for the ESM and booting without a Startup-sequence. It still leaves the keys for Linux set up the wrong way though if not done at the CFE stage.

It must have been read before by keymap.library during reset routine. I just wrote and tested a small program that reads said variable with nonvolatile.library. It worked for me so if this isn't offically fixed then a work around should be possible.

As to Linux I'm not sure as I have used different keyboards with it over the years. One had no right Windows key. I just checked the PS/2 keyboard I've been using with my A1/XE for years, that has Alt next to space, and have had no problems in either AmigaOS or Linux that I can recall.

Given Linux would usually work with PC keyboards how would this be a problem? The only major problem I recall having in Linux was an Ubuntu 9.04 installer I hacked together, where the Debian key layout check thought it was an Amiga, because the machine name "amigaone" has "amiga" in it and it remapped the keys!

In any case this should be solved on the boot args. If not then it can be on the desktop, but that is not global.

@Hypex

Quote:

Hypex wrote: @BillE Quote: I've submtited a bug report about this situation. There were some related ones but as this relates directly to keymap_swapaltamiga I felt a new one was needed. [quote]Exactly, and I *always* forget. So instead of quickly rebooting into the OS I end up booting from scratch which unfortunately takes ages and is something you do not want to do unless you really have to. In cases where the user needs to reset, they can and have pressed the wrong reset combo, meaning they need to remember the keys are wrong before making a mistake. Two wrongs don't make a right.

In this particular case, I don‘t agree with you.
I can image a big discussion could be made about this, but to keep things short, it is an AmigaOne computer, built to run AmigaOS and it should do so with some more consistency.

I am fairly sure, you would agree with us some more if a similar situation was the case:
imagine who ever feels responsible for this hardware would expect the user to remember that in UBoot you need to press respectively the letter "T", "M", "O", "W" and "X" to make "P", "R", "I", "N", "T" appear on the screen. In an early shell, you need to press respectively "W, F, T, I, S" to make the letters "P", "R", "I", "N", "T" appear on screen. And once the OS has booted, another random set -which I am too lazy to type now- to make the same letters "P", "R", "I", "N", "T", appear on screen.

Would you still say: "Hey, the users need to remember the keys before they press them!" and maybe also add "Good memory is fun! Remember when computing was fun? Amiga will improve your memory!"?

Granted, if I had the money to build and market such a hardware, I would let a group of smart engineers work on this. And tell them to put even more confusing and complicated inconsistencies in the system. Just for the fun of it. And maybe scream something mildly insulting at the end users once they complain: "You idiots with short-term and long-term memory loss you, you peasants!"

Last edited by Amigo1 on 10-Apr-2020 at 08:50 AM.

@Amigo1

Quote:

In this particular case, I don?t agree with you.

They dont need to remember the keys are wrong before making a mistake? Or two wrongs do make a right?

Quote:

I can image a big discussion could be made about this, but to keep things short, it is an AmigaOne computer, built to run AmigaOS and it should do so with some more consistency.

I can understand that. And can already see the excuses of firmware isn't AmigaOS so we don't care.

Quote:

I am fairly sure, you would agree with us some more if a similar situation was the case:

I am fairly sure quoting myself out of context has caused confusion.

Quote:

Would you still say: "Hey, the users need to remember the keys before they press them!" and maybe also add "Good memory is fun! Remember when computing was fun? Amiga will improve your memory!"?

No I wouldn't, that would be so annoying!

Quote:

Granted, if I had the money to build and market such a hardware, I would let a group of smart engineers work on this. And tell them to put even more confusing and complicated inconsistencies in the system. Just for the fun of it. And maybe scream something mildly insulting at the end users once they complain: "You idiots with short-term and long-term memory loss you, you peasants!"

That would make me go postal and want to write a nasty letter!

In the particular case you disagreed with me, on exactly what I don't know, was part of my bug report. Just a bit of sarcasm from me. But I can see I caused confusion as I pasted it without context.

The last few days I've been doing some tests. While activating key swap works fine on Workbench, I could not get it working otherwise. I've tested loading it as a Kickstart module. It loads fine and sets the key swap fine but it makes no difference. I also tested from a boot shell and also saw no difference. So I don't know what the keymap.library was doing before because the function to swap keys is right in there. But it doesn't do anything!

Last edited by Hypex on 13-Apr-2020 at 06:38 PM.