TOS RAM test routine ?

[Darklord]

Doesn't pak have 32bit ROM ?? What speed chips is it using ?

I'm not sure about what speed the chips are. Here's the only
thing I could find from the manual that (might) apply:

Screenshot_20221213_192045.png (121 KiB) Viewed 2679 times

Screenshot_20221213_190815.png (96.72 KiB) Viewed 2679 times

Screenshot_20221213_190553.png (99.37 KiB) Viewed 2679 times

Sorry I couldn't be more helpful...

[exxos]

Sorry I couldn't be more helpful...

It actually says 120ns in the first image But yeah 32bit ROM . Bet it would be even faster if it had 50ns ROMs and a firmware tweak.

[Darklord]

It actually says 120ns in the first image But yeah 32bit ROM . Bet it would be even faster if it had 50ns ROMs and a firmware tweak.

I'd be perfectly willing to try that out!

[Badwolf]

@Badwolf A bit of light reading https://mikro.naprvyraz.sk/docs/Coding/ ... ie/MMU.TXT

Have read it. More than once. Feels like when I got to the third general relativity lecture by about half way down!

BW

[exxos]

Have read it. More than once. Feels like when I got to the third general relativity lecture by about half way down!

Yeah seems to give lots of examples of things what not to do

[sporniket]

As a first read about MMU, it is a bit dry indeed (and no pictures !).

http://marc.retronik.fr/motorola/68K/68 ... 86_9p].pdf "MEMORY MANAGEMENT UNITS FOR 68000 ARCHITECTURES" is a good primer (link because it's a 8 MB pdf). Then the datasheets of MMU MC68451, and especially the PMMU MC68851 make the text more palatable.

(edit : fixed link with square bracket that wreak havoc on bbcode )

[dml]

So I do basically the same sort of thing in BadMooD - I can provide source for the MMU module in that. However I didn't create that module for relocating stuff into ROM it was mainly used to shadow/mirror bits of memory elsewhere and change the caching attributes.

Looks like MAPROM has something similar to that module, although simpler looking, using some macros. By 'simpler' I mean it looks like a table. My own module consists of a set of functions used to create tables.


The MMU is a 'tree' structure built from page tables (arrays of page info entries). Each entry in the table has info & flags for the target address for a given page (being e.g. 8kb per page). The location of the entry in the tree itself infers the source location of memory being mapped. e.g. a page entry says 'this logical memory region should use that physical ram address'

So its a bit of a PITA to understand the details from the reference info and make a tree like this but with some decent macros/functions and a basic understanding of whats going on, it is not so hard.

The part which needs a lot of care is the fact the MMU tree must serve the whole system not just the changes you want to make. There is a single hardware pointer to the MMU tree and that tree must describe everything at once. If you get some of it wrong or leave some area of memory untreated in the tree, TOS will misbehave in exciting ways.

This means you also need some understanding of the existing tree and what it has set up for TOS, before you make a new one which does mostly the same thing.

[frank.lukas]

Fastram bar only ...

PAK030/50Mhz 64MB = 24s
PAK020/40Mhz 64MB = 35s
TF536 /50Mhz 64MB = 4m40s

... the ST Ram test bar is faster on the PAK Atari ST than on the TF536 Atari ST.


Atari TT 32Mhz 256MB = 2m20s

... the PAK machines are already faster than the Atari TT.

64MB Fastram DFB1 = 30s

[Rustynutt]

Use my fixcrc program to fix that.

Stephen, will your fixcrc work on a TOS 4.04 image?
Link?
Thanks

[stephen_usher]

I don't see why not. I would imagine that Atari didn't change the CRC test merely for TOS 4.x when they'd used it for all previous versions.