Feature request - pistorm support

[mja65]

Handy tool!

Just wondering if pistorm support is something you have or would consider? There are other ways of doing it but would be handy if it was all on one place!

[larsonmars]

I do not own a PiStorm and I do not know a way to find out if you have one in your system. I guess there is probably an entry in the expansion list, as it it has an RTG feature, but maybe there is an easier way, such as a dedicated address.

You say there are existing ways. If you could point me to it and would be willing to test it, I could consider adding support. Otherwise, this will have to wait until I have time to add general RTG support, which also involves iterating the expansions list.

[Tallguy58]

You could try this to detect PiStorm...

https://aminet.net/util/sys/SniffEmu.lha

Regards,
Alexander.

[mja65]

First, my apologies for not responding earlier. It wasn't until I saw someone else had responded that I realised I hadn't done so.

Unfortunately I lack the skills to tell you how to detect Pistorm at a programming level. The best I can do is point you to the source code for EMu68 Info which does (among other things) identify the pistorm, pi etc.

It's an example of the other tool I mention where consolidation into a single tool would be useful. However, if it's too difficult (and by that I mean I am not able to give you clear enough information, rather than you not being able to do!), fair enough.

I am definitely able to test.

https://github.com/flype44/Emu68Contribs/tree/e551c26a03919347930fcac0ad0fc97b6f88c0cd/Emu68Info

[larsonmars]

For me, it is primarily a matter of having enough spare time. Anyway, first I have to look at @0xecc0-devices great PR for the OS-independent CPU detection. Then, we can have a look at this. @mja65, if you can test for me this will be of great help already.

[mja65]

First, I completely understand re the spare time! Hopefully goes without saying, particularly given my delayed response!

Happy to do whatever testing is needed - not sure if you mean in relation to the latest PR or for when you get to looking at it from a pistorm perspective, but if it's for the PR I would need a compiled version, as I lack the skills to compile that myself

[0xecc0-devices]

a detection of uae, musashi and emu68 is in general possible. I wrote a routine that distinguishes between uae, musashi and emu68 (based on the tool that @Tallguy58 pointed to). It currently only fills a bitfield based on the emulator found. It does the trick on uae, I'm not able to test musashi or emu68.

an implementation that could be incoorperated into sysvars could look like this:

(just ignore opening the dos.library, it's a leftover from writing and trying my macro definitions)

;*******************************************************************
;* constants
;*******************************************************************

emu68_mid equ $6d73

musashi_mid equ $7db
musashi_interaction_pid equ $6b
musashi_rtg_pid equ $6b

uae_mid equ $7db
uae_snd_mid equ $1966
uae_snd_pid equ $02

;*******************************************************************
;* includes
;*******************************************************************

  include "funcdef.i"
  ; macro defintions mostly to improve readability
  include "macros.i"

  include "exec/execbase.i"
  include "exec/exec_lib.i"
  include "libraries/dos.i"
  include "libraries/dos_lib.i"
  include "libraries/expansion.i"
  include "libraries/expansionbase.i"
  include "libraries/configvars.i"
  include "lvo/expansion_lib.i"

;*******************************************************************
;* bitfield defintions for the lazy
;*******************************************************************

  BITDEF EMU,UAE,0
  BITDEF EMU,MUSASHI,1
  BITDEF EMU,EMU68,2

  section "code",code
	pushregisters

	; open dos.library
	clear d0
	lea.l .doslibrary(pc),a1
	exec OpenLibrary
	tst.l d0
	beq.w .error_dos
	move.l d0,.dosbase

	; open expansion.library
	clear d0
	lea.l .expansionlibrary(pc),a1
	exec OpenLibrary
	tst.l d0
	beq.w .close_dos
	move.l d0,.expansionbase

	; find common uae or musashi devices
	cleara a0
	move.l .expansionbase,a6

.nextuaeormusashi
	move.l #uae_mid,d0
	moveq #-1,d1
	jsr .findexpansions(pc)
	tst.l d0
	beq.s .notuaeormusashi

	cmp.b #musashi_rtg_pid,d2
	beq.s .musashi
	; if it's not musashi rtg assume uae
	ori #EMUF_UAE,.emulation
	bra.s .nextuaeormusashi

.musashi
	; if it's musashi rtg, it can't be uae
	ori #EMUF_MUSASHI,.emulation
	andi #EMUF_MUSASHI,.emulation
.notuaeormusashi

	; find uae sound device
	cleara a0
	move.l #uae_snd_mid,d0
	moveq #uae_snd_pid,d1

	jsr .findexpansions(pc)
	tst.l d0
	beq.s .notuaesnd
	ori #EMUF_UAE,.emulation
.notuaesnd

	; find emu68 devices
	cleara a0
	move.l #emu68_mid,d0
	moveq #-1,d1

	jsr .findexpansions(pc)
	tst.l d0
	beq.s .notemu68
	ori #EMUF_EMU68,.emulation
.notemu68

.close_expansion
	move.l .expansionbase,a1
	exec CloseLibrary
.close_dos
	move.l .dosbase,a1
	exec CloseLibrary
.error_dos
.exit
	popregisters
	rts

.findexpansions
	exp.q FindConfigDev
	tst.l d0
	beq.s .fe_exit
	movea.l d0,a0
	; cd_Rom, er_Manufacturer and er_Product
	; from libraries/configvars.i and libraries/configregs.i
	move.w cd_Rom+er_Manufacturer(a0),d1
	move.b cd_Rom+er_Product(a0),d2
.fe_exit
	rts

.doslibrary:
	; macro defined in libraries/dos.i
	DOSNAME
.expansionlibrary:
	; macro defined in libraries/expansion.i
	EXPANSIONNAME

	section "data",data
.dosbase:
	ds.l 1
.expansionbase:
	ds.l 1
.emulation:
	dc.b 1
	cnop 0,2

[0xecc0-devices]

@mja65 find an experimental release of sysvars 0.20 with added UAE/Musashi/Emu68 detection. You can read out the emulation type from the $Emu environment variable.
Tested with UAE only. Feedback appreciated.

[0xecc0-devices]

@mja65 I just released an experimental sysvars v0.21 which fixes closing the expansion.library after detection of the emulation environment.
Probably v0.20 would still work, but libraries should be closed properly after opening them.

Again feedback is appreciated.

[Tallguy58]

@mja65 I tested your 0.21 version on my Amiga 600 with Apollo MantiCore (Vampire) v4 accelerator and crashed with the error message...


This is a part of my startup-sequence....

Thank you...

[mja65]

@Tallguy58 I raised the issue, but I am not the author.

The tag on the post reminded me to check (so not all bad!) and unfortunately I am getting exactly the same crash and error. This is a Pistorm-ed Amiga 1200 (Emu68) running 3.2.3.

[0xecc0-devices]

@mja65 @Tallguy58
can you please try the attached 0.21b? I disabled CPU and FPU detection there but not the emulation detection just to narrow down the problem.

[link removed]

EDIT: never mind...I just tried on my A1200 with TF1260 and it crashes, too. When I run the version without emulation detection, it doesn't crash. I'll rework the detection code and come up with a fixed version tested on my real machine.

[0xecc0-devices]

@mja65 @Tallguy58
new version which doesn't crash on a real Amiga 1200 TF1260 and UAE emulated machines anymore. Emulation detection now should work. I need to refactor the emulation detection for a proper release though.

sysvars_0.21b.zip

feedback appreciated.

[mja65]

Seems to work here! Nice work!

[Tallguy58]

I have different results.
Works well in WinUAE...

Does not work well on my Amiga 600 MantiCore v4...

Here is my startup-sequence.
It looks like the ENV: handler has been deleted.

Thank you,
Alexander. ☹️

[0xecc0-devices]

@Tallguy58 could you please boot without startup-sequence, run sysvars manually and get the Emu, CPU and FPU env variable manually?