TOS RAM test routine ?

[exxos]

Sorry, then I have no clue what's going on there.

Why are you inhibiting anything if ST-RAM is now permitted?

It doesn't work if you enable or disable the cache all the time. It basically crashes on the desktop eitherway. I don't think you can cache system variables for starters.

The original TF code only allowed caches to be enabled on alt-ram access. I later did significant tests enabling ST-ram instead. Was part of all the frontbench tests I did. Basically the conclusion that it made no odds, at least to frontbench.

Now I am adding in ROM range to enable the caches on access. Though I don't think this is anything to do with caches but simple ROM access speed. I locked it to 8MHz so people could use any old ROM in the ST536. So if I speed it up effectively 16MHz or more, I would assume the RAM tests would be significantly quicker. I'm assuming PAK uses 120ns ROM in 32bit. So probably something like 20MHz x 2 kinda thing. I don't think I can compete with 32bit access, but I should be able to speed it up significantly.

[Badwolf]

Why are you inhibiting anything if ST-RAM is now permitted?

It doesn't work if you enable or disable the cache all the time. It basically crashes on the desktop eitherway. I don't think you can cache system variables for starters.

Either the OS is cache aware or it isn't. If it isn't, then you probably do need to inhibit cache on all ST-RAM and the register block as DMA could happen anywhere, you've got system variables etc.

If it is cache-aware, you shouldn't need to inhibit the cache anywhere.

EmuTOS would be fully cache-aware. I don't know if TOS2.06 is. I've seen conflicting claims.

So I don't think there's a compromise position other than the ROM range itself.

The original TF code only allowed caches to be enabled on alt-ram access. I later did significant tests enabling ST-ram instead. Was part of all the frontbench tests I did. Basically the conclusion that it made no odds, at least to frontbench.

Were you using MAPROM? MAPROM also inhibits caches for ST-RAM (even on the Falcon, which is why I don't use it).

BTW, MAPROM can genuinely inhibit caches for certain ranges as it uses the PMMU to do it. CIIN is fallable.

Now I am adding in ROM range to enable the caches on access. Though I don't think this is anything to do with caches but simple ROM access speed. I locked it to 8MHz so people could use any old ROM in the ST536. So if I speed it up effectively 16MHz or more, I would assume the RAM tests would be significantly quicker. I'm assuming PAK uses 120ns ROM in 32bit. So probably something like 20MHz x 2 kinda thing. I don't think I can compete with 32bit access, but I should be able to speed it up significantly.

ROM access speed would obviously help, but I'd be surprised if the instruction cache didn't also help. I'd be surprised if the test routines are so expansive as to constantly cache-miss.

BW

[exxos]

Were you using MAPROM? MAPROM also inhibits caches for ST-RAM (even on the Falcon, which is why I don't use it).

BTW, MAPROM can genuinely inhibit caches for certain ranges as it uses the PMMU to do it. CIIN is fallable.

But this all depends on the version of MAPROM. Originally MAPROM Inhibited everything but TTRam IIRC (maybe up to 1.8 ish) , but when @agranlund and I was doing the STram cache stuff, it had to be patched into MAPROM and the firmware of the ST536. I don't know what versions they were anymore. Maybe when V2.0(ish) came out. Also there was extensive tests with what it was caching in lower RAM. I found problems with what he had originally, but that could have been a side-effect of other issues we was dealing with at the time. But AFAIK, it was left at 4k lower RAM cache. where the MMU relocated some of the lower RAM to TTram. I think originally had 32K..

IIRC @agranlund Changed the way MAPROM compiles so I cannot compile my own versions any more. I think he basically put switches in the code for all this stuff. But this was going back a while ,so don't exactly remember everything now. Really more testing needs to be done but I really need my own custom build of MAPROM for the ST536. Everyone else might be better using around 1.8ish. But again I don't know about the relocation block sizes across the versions. He may not have even released those variants I used officially.

It could be why you are having troubles with various versions of MAPROM. I think he might of removed early versions from github as well. I also think he may have not correctly labelled up the changes for various versions as well. I think it was more of a "compile what you want" type of release than a "download and run it" type of release. I don't know what state MAPROM was left in on github unfortunately. Indeed there should be multiple versions of whatever the current version is so people can just download and run whatever they need to for whatever reason they want to run it for.

[exxos]

55ns ROM with ST536 TOS and now get 58seconds TTram speed!

GB6 shows ROM access as 323%. On the STE 32MHz booster it was 309%. So I think that is the maximum speed I can coach out of a 16bit 55ns ROM.

Turning off DataCache in GB6 gives 350%. Turning on instruction cache did not seem to do anything. So maybe more beneficial to turn the caches off during RAM tests :roll:

Indeed if there was 2 ROMs on the ST536 , it would be 32 bit mode and be more like 30 seconds on TTram speed test. When I created the ST536 I did briefly toy with the idea of adding 2x ROMS. But at the time I did not see any point because MAPROM came along and loaded ROM into TTram anyway. It would just add more work and expense for no real gain. It begs the question if I should do 2 ROMs on the STE536 variant now :roll:

So mystery solved I guess.

:dizzy:


EDIT: Nope, with just instruction cache on, took a few seconds longer to do TTram test. :roll:

Here are the 2 test ST536 TOS's.

ST536_Ctest.zip

[Badwolf]

But this all depends on the version of MAPROM. Originally MAPROM Inhibited everything but TTRam IIRC (maybe up to 1.8 ish) , but when @agranlund and I was doing the STram cache stuff, it had to be patched into MAPROM and the firmware of the ST536. I don't know what versions they were anymore. Maybe when V2.0(ish) came out. Also there was extensive tests with what it was caching in lower RAM. I found problems with what he had originally, but that could have been a side-effect of other issues we was dealing with at the time. But AFAIK, it was left at 4k lower RAM cache. where the MMU relocated some of the lower RAM to TTram. I think originally had 32K..

Yes, there are various versions of MAPROM. The last assembler-only version was 2.2 which handles reboots properly but blocks STRAM caching.

My point being if any MAPROM is in play, the hardware cache-inhibit can only hinder things.

Also trying to measure the effectiveness of hardware cache settings with GB6 whilst running MAPROM is unlikely to be fruitful.

It could be why you are having troubles with various versions of MAPROM. I think he might of removed early versions from github as well.

No, the old assembly-only versions are still there. Perhaps not built, though. The newer C version is much more easily edited, but doesn't quite work for me (it doesn't work properly on reboot).

Separate issue, but connected: if you're not going to use MAPROM or EmuTOS, you probably need to inhibit cache for ST-RAM & the registers. If you plan to use MAPROM or EmuTOS, then you can probably disable the cache inhibit entirely (ok, maybe the register range, depends what TOS2 does early doors before MAPROM launches).

Of course this is only relevant for *this* problem (before you run FASTRAM or MAPROM) if you're hardware disabling cache for the ROM range. Which you seem to be if the code you quoted above is an 'allow' list.

BW

[exxos]

I think overall providing there is space left in the ROM, and if someone could help me with a "port" FASTROM.PRG. Then just copy TOS into TTRAM on boot up and not bother with any external programs at all.

Cannot remember now if MAPROM does anything else. But as TTram is setup in ST536 TOS, having a built in TOS relocation would pretty much polish the whole thing off I think anyway. I think with so many versions of MAPROM that has just become way too confusing to keep track of it all.

I assume I can "almost" just drop this code in.

Code: Select all

;----------------------------------------------
	; check rom size and start address
	; a3 = rom address
	; d3 = rom size
	;----------------------------------------------
	move.l	$4f2,a0				; a0 = _sysbase
	move.w	2(a0),d2
	move.l	#$30000,d3			; d3 = 192Kb (Tos 1.xx)
	cmp.w	#$200,d2
	bcs		.romSizeOK
	move.l	#$40000,d3			; d3 = 256Kb (Tos 2.xx)
	cmp.w	#$300,d2	
	bcs		.romSizeOK
	move.l	#$80000,d3			; d3 = 512Kb (Tos 3.xx / 4.xx)
.romSizeOK:
	move.l	8(a0),a3			; a3 = TOS start addr
	cmp.l	#$e00000,a3
	beq		.romAddrOK
	cmp.l	#$fc0000,a3
	beq		.romAddrOK
	moveq.l	#0,d3				; zero size to indicate unsupported rom
.romAddrOK:
	move.w	d2,gTosVersion
	move.l	d3,gTosSize
	move.l	a3,gTosAddr



	;----------------------------------------------
	; allocate ram for rom + mmu tables
	;----------------------------------------------
	move.l	#0,d4
	IFNE 	OPT_RELO_RAM
	move.l	#$800,d4			; EmuTOS = 2Kb
	cmp.l	#'ETOS',$2c(a0)
	beq		.ramSizeOK
	move.l	#$800,d4			; Default = 2Kb
	cmp.w	#$206,d2
	bne		.ramSizeOK
	move.l	#$800,d4			; TOS2.06 = 8Kb
.ramSizeOK:
	ENDC
	move.w	d4,gMapRamSize

	IFEQ	OPT_RELO_ROM
	move.l	#0,d3
	ENDC

	move.l	#$8000,d0			; 32Kb for alignment
	add.l	#$2000,d0			;  8Kb for tables
	add.l	d3,d0				; rom size
	add.l	d4,d0				; ram size
	bsr		AllocateFastRam
	tst.l	d0					; memory allocated?
	beq		MainSUDone
	add.l 	#$7FFF,d0			; align to 32k pages
	and.l 	#$FFFF8000,d0
	move.l	d0,a4				; a4 = memory for rom + ram
	add.l	d3,d0				
	add.l	d4,d0
	move.l	d0,a6				; a6 = MMU table base address
	move.l	d0,a5				;
	add.l	#256,a5				; a5 = memory for extra tables


	; disable mmu
	move.l	#$0,gMMU030_TC
	dc.l	$f0394000,gMMU030_TC


	;----------------------------------------------
	; prepare default mmu table at address d0
	;----------------------------------------------
	bsr		MMU030_Install			; configure default MMU table as TT/Falcon
	tst.l	d0
	beq		MainSUDone
	or.w	#FLAG_MMU,gResultFlags
	move.l	#COOKIE_PMMU,d0			; Write 'PMMU' cookie
	move.l	a6,d1
	bsr 	CK_WriteJar

	IFEQ	OPT_RELO_ROM+OPT_RELO_RAM
	rts
	ENDC


	; disable mmu
	move.l	#0,gMMU030_TC
	dc.l	$f0394000,gMMU030_TC
	dc.l	$f0002400					; pflusha
	bsr		CPU_CacheClear

	;----------------------------------------------
	; map rom to fastram
	;----------------------------------------------
	IFNE	OPT_RELO_ROM
	bsr		Relocate_Rom
	tst.w	d0
	beq		.reloRomDone
	or.w	#FLAG_RELO_ROM,gResultFlags
.reloRomDone:
	ENDC

	;----------------------------------------------
	; map lowram to fastram
	;----------------------------------------------
	IFNE 	OPT_RELO_RAM
	tst.w	gMapRamSize
	beq		.reloRamDone
	bsr		Relocate_Ram
	tst.w	d0
	beq		.reloRamDone
	or.w	#FLAG_RELO_RAM,gResultFlags
.reloRamDone:
	ENDC

	;----------------------------------------------
	; activate new mmu tables with 4k pagesize

	;----------------------------------------------
	move.l	#$80b04449,gMMU030_TC		; enable, 2k pages, IS=0, TIA=4, TIB=4, TIC=4, TID=8
	dc.l	$f0394000,gMMU030_TC		; pmove addr,tc	
	dc.l	$f0002400					; pflusha
	bsr		CPU_CacheClear

MainSUDone:
	rts

EDIT:

https://github.com/agranlund/tftools/tree/master/src

So annoyingly FASTROM.PRG be written in C. The original "old" MAPROM is in assembler but would have to be seriously stripped down to the bare minimum as I only have about 6K left in the ROM :(

Hopefully @agranlund Can sort this out when he returns.

[exxos]

...and thus ends my assembly knowledge :( Obviously just trying to dump MAPROM into ROS isn't liked.

Capture.PNG

EDIT:

Ahhh got it down to 66 errors. It doesn't like the ';' for comments for some reason.

[exxos]

Dammit! still 22 errors :(

Capture.PNG

EDIT:

Seems MAPROM had used the name "copy" twice for different routines :shrug: Also the compiler doesn't like variables which start the same. Like "fastram" and "fastram2" it doesn't like. So had to rename to "FR" instead :roll:

So 20 errors to go :roll:

[exxos]

18 errors and no idea what it doesn't like now.

It is difficult to tell because I know the startup.s file is fine, it is somewhere in the MAPROM code which is going nuts. So the line numbers don't seem to tally up to anything sensible :roll:

Capture.PNG

[exxos]

So 2 errors in this code...

Code: Select all

	IFEQ	OPT_RELO_ROM+OPT_RELO_RAM
	rts
	ENDC

"Illegal expression" :shrug:

I wonder if this is some sort of compiler compatibility troubles or it is trying to compile for the 68000 not 68030 :shrug:

EDIT:

Oh some sort of compiler switch then really..

The instructions in the block will be parsed and assembled if and only if value equals 0. You can also write ENDIF as a synonym for ENDC.

I guess I could probably remove them for now... 16 errors now :roll:

I assume it is the '+' part of the statement which is causing the problem as similar functions pass elsewhere in the code :shrug: