Page 3 of 4

Re: Installing alt-ram assembly problem

Posted: 03 Apr 2020 17:54
by exxos
terriblefire wrote: 03 Apr 2020 17:51 I hacked up the monSTer code to do this job. There was some unobvious bits. I'll see if i can find the code.
monster had this...

Code: Select all

maddalt:
	move.l	d1,-(sp)		; Size
	move.l	d0,-(sp)		; Addr
	move.w	#20,-(sp)		; Maddalt
	trap	#1			; GEMDOS
	lea		10(sp),sp
	rts
Though I am not sure if replacing D1,D0 with a actual value works...

Even this doesn't seem to work...

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

EDIT:
I think it is working in part.. but it seems "bugged" like the hisoft line somehow :roll:

Re: Installing alt-ram assembly problem

Posted: 03 Apr 2020 18:14
by PhilC
It's hard to offer advice with such a small section of the code.

Its not knowing what's already on the stack and what's in the data registers at that time.

(Not pretending to be an expert)

Re: Installing alt-ram assembly problem

Posted: 04 Apr 2020 00:27
by terriblefire
I never understood how it was supposed to work anyway? How does ST software use ALT-RAM?

Re: Installing alt-ram assembly problem

Posted: 04 Apr 2020 01:13
by exxos
terriblefire wrote: 04 Apr 2020 00:27 I never understood how it was supposed to work anyway? How does ST software use ALT-RAM?
There's a program called prgflags which let's you chose if the software is loaded to alt-ram or not.

https://www.exxosforum.co.uk/forum/viewt ... ?f=25&t=54

Re: Installing alt-ram assembly problem

Posted: 04 Apr 2020 14:33
by terriblefire
I found this gem in my code?

Code: Select all

long maddalt(long addr, long size); /* PureC Maddalt is broken */
I'll attach my code entirely here in a moment..
M_ALTRAM_from_laptop.zip

Re: Installing alt-ram assembly problem

Posted: 04 Apr 2020 14:42
by exxos
Thanks, it seems to be a TOS problem...

Re: Installing alt-ram assembly problem

Posted: 04 Apr 2020 17:22
by mfro
No TOS problem for me. Out of curiosity, I just wrote a little program that adds the 256 Bytes behind screen memory as alternate RAM.
This works just fine (although a little useless). Mxalloc(-1L, 1) shows the memory correctly and it can be accessed using Mxalloc(128, 1).

Tested with TOS 2.06 on Hatari.

Code: Select all

#include <stdio.h>
#include <tos.h>

int main(int argc, char *argv[])
{
	long res;
	void *free;

	void *start = (char *) Logbase() + 32000L;
	
	free = Mxalloc(-1L, 1);
	printf("%ld Bytes Alternate RAM free\n", free);
	res = Maddalt(&start, 256);
	free = Mxalloc(-1L, 1);
	printf("%ld Bytes Alternate RAM free\n", free);
	return 0;
}
grab0001.png
Yes, Pure C's Maddalt() binding is broken, but you can make it work if you pass the address of a variable that holds the memory block address to add instead.

Re: Installing alt-ram assembly problem

Posted: 04 Apr 2020 18:05
by exxos
Its the same problem with EMUTOS, 104,206, its accessing the altram area for 2 cycles on boot then it screws up.. I don't know how emulators or other versions of TOS behave. All I know is I have to keep alt-ram disabled until the desktop is up. Then it all works fine.

Re: Installing alt-ram assembly problem

Posted: 04 Apr 2020 18:11
by terriblefire
exxos wrote: 04 Apr 2020 18:05 Its the same problem with EMUTOS, 104,206, its accessing the altram area for 2 cycles on boot then it screws up.. I don't know how emulators or other versions of TOS behave. All I know is I have to keep alt-ram disabled until the desktop is up. Then it all works fine.
Wonder if disk buffers accidentally get allocated alt ram or some other such device?

Re: Installing alt-ram assembly problem

Posted: 04 Apr 2020 18:16
by exxos
terriblefire wrote: 04 Apr 2020 18:11 Wonder if disk buffers accidentally get allocated alt ram or some other such device?
DMA does get screwed up.. but its odd.. Because there is only one Incorrect icon in a directory list on the floppy...

But video gets trashed totally, I just get a totally blank screen all the time, unless something crashes and I then can actually see bombs.. So it is like screen memory is getting allocated somewhere it should not be... I mean sysinfo would tell me that, but I cannot see the screen to check that :lol: :roll: