Real hardware UAE state file loader

[Toni Wilen]

Good idea, nocache parameter added
It is by design to support mismatched CPU = restore is still processed correctly but loaded program may or may not work.

- Nocache disables caches just before jumping to restored program (=caches are still in use when decompressing etc.)
- Added pal and ntsc parameters to force pal or ntsc, overriding statefile's BEAMCON0 value (if ECS or AGA).
- Some improvements to audio state restore, (long) sample that was playing when saving should now restore almost accurately.
- NTSC mode restore was not as accurate as PAL mode restore.

[Toni Wilen]

v0.7:

- ACA1221 map rom is now supported (including most ACA123x variants that have same map rom hardware).
- Some misc updates.

ACA1221 support was last missing piece in my "need to have" list. Official release will be tomorrow or sunday unless some new bug(s) are found.

[jbl007]

Cool.
Could you also add a "nowait" parameter to remove the the need to press the enter key? Reason: Some games load entirely to RAM at the beginning, no need to change/access the disk.

[Ragnarok]

Savestates have to be created in Winuae or is it possible in real HW too?

[Toni Wilen]

Originally Posted by Ragnarok

Savestates have to be created in Winuae or is it possible in real HW too?

Problem is that custom chips have many write-only registers.

Without extra hardware: It is impossible to make reliable state files.

Action Replay like hardware that snoops CPU writes to custom registers: possible but because copper can modify custom chips, it enables software tricks that makes creating working state impossible. Technically hardware that can also snoop copper writes is possible but required signals (RGA) are not available in edge connector.

It is relatively easy to restore state if all required information is available than to create state.

Originally Posted by jbl007

Cool.
Could you also add a "nowait" parameter to remove the the need to press the enter key? Reason: Some games load entirely to RAM at the beginning, no need to change/access the disk.

Done. (I had plans for this already but forgot..)

[mark_k]

Are you interested in adding map ROM support for GVP A1230? I don't have the actual hardware but can type up some notes on how I think it works...

[Toni Wilen]

Originally Posted by mark_k

Are you interested in adding map ROM support for GVP A1230? I don't have the actual hardware but can type up some notes on how I think it works...

68030 (vs 68020) is technically unsupported but probably almost always works unless program is very timing sensitive. 68020 boards first.

Perhaps later. Map ROM support almost always require real hardware testing, there can be some unexpected side-effects.. I have GVP A530 but it probably is different?

Hmm.. maprom-all-in-one..

[mark_k]

The A530 probably doesn't support hardware ROM remapping. (What is the value in byte register at board+$8001?)

Another possibility for the future could be to copy the MMU-using ROM remapping code from SetCPU...

[Toni Wilen]

Originally Posted by mark_k

The A530 probably doesn't support hardware ROM remapping. (What is the value in byte register at board+$8001?)

I'll check later but UAE has 0xc0 (without scsi) and 0xd0 (with scsi). I think non-scsi variant ID came from linux or netbsd driver.

Another possibility for the future could be to copy the MMU-using ROM remapping code from SetCPU...

Nah, I would not use external programs but create full MMU table manually (I already wrote similar MMU code for m68k AROS) because MMU can be also used to create fake $c00000 RAM and "hide" expansion hardware features etc..

[Toni Wilen]

First official version is now out, also available from aminet.

[Toni Wilen]

v1.1 beta #1:

- GVP MapROM support added. GVP A530 and most A2000 and A3000 GVP boards.
- Blizzard 1230 MKI/II/III/IV, 1240, 1260 MapROM support added.
- Switch off all floppy drive motors before memory decompression.
- Fixed crash if 68020 or 68030 statefile was loaded and CPU was 68040 or 68060. (Surprisingly many AGA statefiles work fine if CPU is 68040/060)
- Fixed uncompressed statefile support.
- Compatibility improved.

http://www.winuae.net/files/b/ussload.zip

About maprom support: GVP A530 and Blizzard 1260 confirmed by me. Other models still need confirming.

[Toni Wilen]

Beta #2:

- ACA1233n MapROM support, in both 68030 and 68EC020 modes.
- ACA123x 128M model MapROM support fixed (v1.0)
- ACA500/ACA500plus MapROM support fixed (beta 1)

[Toni Wilen]

Version bump to 2.0. MMU support!

http://www.winuae.net/files/b/ussload.zip

If system has MMU (Full 68030, 68040 or 68060), any fully or partially missing memory is MMU remapped. You have statefile that requires slow ram or fast ram but your accelerator only has 32-bit fast RAM? Not a problem anymore! MMU is also used for KS maprom.

Even missing Chip RAM is remapped (with a warning message) but it rarely works for obvious reasons.. (I left it in because there may be shovelware "AGA" ports that "require" 2M chip but only uses first 512k/1M of Chip RAM for stuff that chipset DMA uses)

Other changes:
- Kickstart image is also loaded from current directory if DEVS:Kickstart is missing.
- nommu command line option to disable MMU use. (Final version may not have automatic MMU enable, at least when CPU is 68030 because there is no reliable way to detect if CPU is 68030 or 68EC030)

[mark_k]

Nice work with the MMU support.

I wonder, in one very specific case could MMU remapping of chip RAM actually work?
- A500/B2000 with ECS Agnus, 512KB chip + 512KB slow RAM
- 68020/30 accelerator w/MMU
If you use MMU to remap $C00000 slow RAM to $080000, would that effectively give 1MB chip RAM?

[Toni Wilen]

Originally Posted by mark_k

Nice work with the MMU support.

I wonder, in one very specific case could MMU remapping of chip RAM actually work?
- A500/B2000 with ECS Agnus, 512KB chip + 512KB slow RAM
- 68020/30 accelerator w/MMU
If you use MMU to remap $C00000 slow RAM to $080000, would that effectively give 1MB chip RAM?

Yeah, I think it should work. I'll test this later (With ACA500plus + A1200 68030 accelerator + 0.5M chip + 0.5M slow config)

[Toni Wilen]

Beta #2

http://www.winuae.net/files/b/ussload.zip

- Added $080000->$c00000 MMU mapping if 512k/ecs and $c00000 RAM exists. Unfortunately I can't test this because my A1200 accelerators (that work with ACA500plus) are icomp variants and they have onboard $c00000 which makes it impossible to access trapdoor RAM and Blizzard 1260 won't work with ACA500plus without TTR tricks that are not MMU remapping comptible. (WinUAE won't also work, this chip ram mirror feature only works in very specific configurations)
- If KS 1.x: detect 030 and 040 (KS 1.x only detects up to 68020). Detect also 060 if pre-v45. This enables correct MMU setup, even if KS ROM does not detect later CPU models.
- GVP MapROM rejects Z2 RAM that is not accelerator onboard. (If system has GVP accelerator with onboard Z2 RAM but also has another Z2 RAM board)
- 68030 MMU is not enabled anymore by default (use mmu command line parameter), there are too many 68EC030 boards.

Note: Use without startup-sequence (especially if 68040+). Do not load any MMU libraries.

[Toni Wilen]

Beta 3:

I think all planned features are now mostly implemented.

- FPU state file support.
- Can also load 68040 and 68060 statefiles but MMU registers are not restored.
- Pause mode. If enabled, ussload waits for left mouse button after state is restored and DMA (except audio) is enabled.
- 68040/060 MMU autodetection.

- nofloppy command line parameter added (do not initialize/seek floppy drives)

[Toni Wilen]

Still more features, sorry

- Memory allocation rewritten, uses less memory and supports more different memory configurations, MMU mode works in chip ram only systems (if for some weird reason someone has 68030+ board without fast ram..) and more.
- HRTMon support (keep NMI vector if installed standard HRTMon is detected, option to set other exception vectors too. Bus error is also set automatically, useful when debugging MMU mode access faults).

Final 2.0 soon.

EDIT: Does anyone have following real hardware config:

- A500 + 68030 (not 68EC030) or higher CPU accelerator (directly connected, not A1200 accelerator + ACA500 or ACA500plus)
- ECS Agnus
- 512k chip ram + 512k trapdoor ram (NOT 1M chip!)

[Leander]

Sorry if I write on a six months old topic, but only now have I noticed this wonderful tool by Toni, whom I always thank for the passion, commitment and results achieved in the development of his programs
One question: when I load a statefile from WinUAE, if the ADF file is not present in the same path where it was when I saved the statefile, after selecting an option the game crashes or the emulator asks me to insert the ADF; USSLOAD can
load games only with the USS file without the related ADF file? If not, how can I insert the corresponding ADF into an real hardware Amiga (or WinUAE emulated hardware, too)?
Thanks in advance for your reply and see you soon!

[Toni Wilen]

Yes, simply insert correct floppy(ies) when ussload asks to press return.
Ussload can't magically insert or emulate disks.