@ChrisH

I used "GGGG" and every unit is enabled in DMA mode.

_________________

@thread

If you think about it for a moment, the old Prefs/U-Boot program couldn't possibly run on a Sam. It talks at a very low level to the SRAM on the XE and µA1 boards through the VIA 686B Southbridge.

I don't know how the Sam is designed, but it sure as hell doesn't use a VIA 686B and probably uses a different SRAM also.

_________________
cheers
tony

Hyperion Support Forum: http://forum.hyperion-entertainment.biz/index.php

@tonyw

Just found this. Why isn't UBoot doing things the "proper" way and using the API to read the NVRAM? Isn't the API cross platform? It should be, as there should be a higher level API for these things, then going into a lower level driver or using the HAL. Customising OS programs this way is no way to keep the OS cross platform.

It also explains why UBoot didn't work on a Sam when I tested it.

@Hypex
Quote:

It also explains why UBoot didn't work on a Sam when I tested it.

Some of the UBOOT variables that work with A1/µA1 do nothing on SAM and possibly vice-versa. I changed the background color on my µA1 by setting "vga_bg_color 1" but setting that variable on my SAM does nothing. It's listed in Ranger/BIOS Tab but has no effect.

_________________
X1000 with 2GB memory & OS4.1FE

@m3x

Quote:

Prefs/Uboot has been dropped on OS4.1 for Sam. You can use c:nvgetvar and c:nvsetvar from a shell to get/set Uboot vars. Anywa

When I do that in a shell I get:

2.OS4.1:C> idetool -u sil3114ide.device 0
idetool : device sil3114ide.device doesn't support command, aborting
2.OS4.1:C>

_________________
SAM 460 with 2GB or RAM, 1000GB HD, 4 port SATA, DVDRW drive and Radeon HD 4650 GFX card.

@sicky

The device name should be sii3114ide.device not Sil3114ide.device.

_________________
A1000; A1200; A1500; Sam440ep; AmigaOne X1000

@elginseam

Quote:

The device name should be sii3114ide.device not Sil3114ide.device.

Oops!

_________________
SAM 460 with 2GB or RAM, 1000GB HD, 4 port SATA, DVDRW drive and Radeon HD 4650 GFX card.

@Hypex

I think you mean "why didn't UBoot do thibngs the proper way..."

U-Boot was a temporary fix only, unique to the SRAM on the XE boards. It was replaced by the "nvgetvar" and "nvsetvar" commands which use your common API.

Maybe someday someone with nothing better to do will write a new UBoot/CFE editor that just uses nvgetvar/nvsetvar.

_________________
cheers
tony

Hyperion Support Forum: http://forum.hyperion-entertainment.biz/index.php

@tonyw

Yes I probably did mean that.

I have used nonvolatile.library on my A1 to grab vars and this works. I don't know if the same API works for the Sam. But since NVGetVar/SetVar does work on both it should be universal.

Quote:

U-Boot was a temporary fix only, unique to the SRAM on the XE boards. It was replaced by the "nvgetvar" and "nvsetvar" commands which use your common API.

Replaced !?

I'm sorry but replacing a GUI preferences program with old fashioned CLI commands is going backwards! Expecting new and old users alike to know what to type is unacceptable. I have a friend with a Sam and every time I use it I rememnber the DMA isn't activated. I go to do it but always give up because I have to locate what to do and type some cryptic crap in.

My friend is not a programming tech head like a lot of Amiga users and wouldn't easily set this up himself.

Quote:

Maybe someday someone with nothing better to do will write a new UBoot/CFE editor that just uses nvgetvar/nvsetvar.

Well I would but I would rather code a clean program that doesn't rely on CLI commands. Is it even possible to set DMA by sending commands directly to the device driver? No one seems to know much about this in the Amiga world.

Quote:

by Hypex on 19-Sep-2011 14:07:32 @tonyw Just found this. Why isn't UBoot doing things the "proper" way and using the API to read the NVRAM? Isn't the API cross platform? It should be, as there should be a higher level API for these things, then going into a lower level driver or using the HAL. Customising OS programs this way is no way to keep the OS cross platform. It also explains why UBoot didn't work on a Sam when I tested it.

Uboot traditionally used direct hardware access for efficiency, but modern systems encourage API usage; however, legacy compatibility and performance considerations can lead to deviations from the "proper" way of doing things in software development. Cross-platform APIs should exist, yet they might not always be utilized due to various factors such as existing ecosystems or specific hardware requirements that necessitate lower-level access for optimal functionality.