Installing alt-ram assembly problem

[czietz]

hmm ok, so more work is needed for monster then... don't get it..

The link to EmuTOS that I posted shows how Monster wants to be initialized before you can call Maddalt. If it's unclear: Is Jo Even Skarstein (joska) a member of your forum? He coded that and could surely explain what needs to be done.

but mostly I am doing this in Hatari anyway. So using maddalt should declare the RAM in Hatari ?

Hatari does not exactly emulate alt-RAM like the Monster has. It can emulate either ST-RAM below 16 MB or (when using a CPU >= 68020) TT-RAM above 16 MB.

[exxos]

I was just using monster as its the only alt-ram card I have. I'm not really looking to do a driver for it...

So I can't test GB6 on that then without messing about with it even more. I can't use Hatari then to emulate it either.. so its possible my code does work and I am being screwed up by monster and Hatari :roll: I guess I could try TT-ram area. but think GB6 updates will have to wait until I can get a simple alt-ram card made.

I tried dumping alt-ram at 16MB area, but still doesn't work :(

Code: Select all

	move.l	#$400000,-(sp)	; Size
	move.l	#$1600000,-(sp)	; Addr
	move.w	#20,-(sp)		; Maddalt
	trap	#1				; GEMDOS
 	lea		10(sp),sp
 	

[rpineau]

Like I said above: If you're not running the Monster alt-RAM "driver", you cannot simply use Maddalt. You have to do what the driver does: enable Monster alt-RAM first.

hmm ok, so more work is needed for monster then... don't get it.. but mostly I am doing this in Hatari anyway. So using maddalt should declare the RAM in Hatari ?

No, maddalt allows you to tell the system there are some ram at a certain address (of a certain size). So calling maddalt in Hatari doesn't add any actual ram and as soon as you try to read/write to the location you get a bus error.
Now if you do have actual AltRAM in a machine, and there is a CPLD doing the decoding and DTACK for it, you can use maddalt to declare it.
The Monster "driver" does a few more things like adding a buffer for DMA I/O and adding it to the cookie jar as well as relocating and expanding the cookie jar.

[exxos]

I thought to poke data into the 4MB area to see if something is there before trying to declare alt-ram... though it gets more complicated if it happens on a falcon with 14MB RAM is it would poke the data and try to declare alt-ram in ST-RAM area.. so I need to figure out a way to avoid those issues as well :roll: Probably only allow the menu option when run on a 68000 etc.

EDIT:

I tried poking into 4MB mark in basic, there seems to be no way to trap this error, and I just get two bombs :(

So I think this really needs someone who knows what they are doing with assembly, and you can program this up properly for me..

[rpineau]

you need to add your own bus error handler to trap it (and if it's not a bus error in what you're trying to test still call the standard system bus error routine).
This is not trivial (that pretty much how the TOS detect RAM on boot).

[exxos]

Does anyone know to program such a thing in asm ?

Probably the way to go is for GB6 to send a number to the asm routine (it passes variables over with other stuff anyway and even returned values) which would be a RAM address to test.

Basically just passing "4" for 4MB area and asm routine would just test a address there to see if something reports back or not. So it will either cause a bus error and asm code recovers and reports back to GB6 "0" for RAM not found. Or reports "1" for RAM found at that address. Then if GB6 send "5" to the asm routine, it tests RAM at 5MB mark etc etc.

This way, GB6 can control which address ranges to check for, be it 4-12MB ST-RAM area and 16MB+ area for 020 CPU. GB6 can effectively can work out where the alt-ram is in the memory map and declare alt-ram at what address ranges the asm reports as valid.


A more automated way, would be GB6 calls the ASM routine and it automatically checks all the normal alt-ram locations and reports back to GB6 the address ranges found. But I think that would actually make things more complicated overall. I mean there is no need to check 16MB ranges on a 68000, so the CPU type would have to be passed over to asm as well, whereas GB6 code only really needs to be able to test RAM locations without crashing :)

[terriblefire]

If you're doing this on the TF534 then you should be able to Maddalt

http://toshyp.atari.org/en/00500c.html

The RAM is present, the system just needs to know about it.

[exxos]

Its a general driver, but if the RAM isn't there, Hisoftbasic crashes because of bus error.

I already tried on the 534 last week.. https://www.exxosforum.co.uk/forum/viewt ... =40#p23319

[exxos]

So can one of the ASM guys code up how I can do this ?

x& = Maddalt&(4194304,2097152)


I should be able to copy/paste into my GB6 asm routines.. I think I got devpac to compile it all properly.. at least nothing broke in GB6 when I did.. so I just need the code to install alt-ram like above...


It would be something like this ?

Code: Select all

	move.l	$200000,-(sp)	; Size
	move.l	$400000,-(sp)	; Addr
	move.w	#20,-(sp)		; Maddalt
	trap	#1				; GEMDOS
	lea		10(sp),sp
	rts

[terriblefire]

It would be something like this ?

Code: Select all

	move.l	$200000,-(sp)	; Size
	move.l	$400000,-(sp)	; Addr
	move.w	#20,-(sp)		; Maddalt
	trap	#1				; GEMDOS
	lea		10(sp),sp
	rts

I hacked up the monSTer code to do this job. There was some unobvious bits. I'll see if i can find the code.