Hatari (esp. Mac) Keyboard Configuration

You may have discovered some difficulties using Hatari because the keyboard layout isn't the same as the real thing.  In particular you might need to type forward or backslash, or the underscore key, and these can be placed in the wrong location to the place you were expecting.  The problem I had was the underscore key couldn't be found anywhere which made typing any commands in SMS_QE (ql operating system?/basic) very difficult.

Here's an example keymap.txt file that helped me when my external microsoft USB keyboard was connected (as a US keyboard, with 'British' selected as the keyboard type (!!))..

# UNDERSCORE(dash) (s) or 12
45,12
# equals
61,13
# WORKS: THIS IS THE HASH. 'SDLK_BACKSLASH' (a) or 43
92,43
# The key to the left of number 1 // Some apps might benefit from mapping to 43 (key to the right of return) or to 96 (key to the left of Z)
# Many apps don't do anything with Atari key 96.
96,41
# Test atari key 96, Make the letter z do a 96:
122,96
# The programmers brackets (square and curly). Normal brackets are on shift 9 and 091,26
93,27
# DELETE (d) or 83
127,83
# Insert or 82
277,82
# Home
278,71
# End or ?temporary UNDO?
279,97

Unfortunately the macos seems to intercept the keys to the right of PrtScn/SysRq and is used to alter screen brightness.  Probably something in the System Preferences->Keyboard->Shortcuts->Display will let me fix that (F14 and F15 were mapped to Display/Increase display brightness).

If you don't like those keys doing what I've assigned them to do, then take a look at:

http://www.atarimuseum.com/computers/16bits/STINTERN.htm
or
http://retrospec.sgn.net/users/tomcat/miodrag/Atari_ST/Atari%20ST%20Internals.htm#KEYMAP
in particular the Keyboard Scancode Map.

Some things to note: An atari keyboard has hash to the right of the enter key, and there's an extra key between equals and backspace.  Worth looking at a photo.  Most applications don't use the UNDO key, but HELP is often mapped to something.

The numbers to the right of the comma are the ones that are in the picture, so eg; 30-33 correspond to ASDF.  So if you want to test eg; whether you've found the right key on your keyboard, change the second number to eg; 30 and then see whether pressing that key gets you an 'A' eg; in a 'create desktop icon' / 'install drive' dialog.  There are some characters that you can't use in a folder name that you might want to use when programming.. I haven't found a good 'keyboard test' program, but have used a couple of word processor / note taking accessories that have helped: EdHak's little brother 'Diary' by Craig Harvey.

Finding the meaning of the first number is more of a case of trial and error.  Some of the keys seem to be straightforward ascii, and come from the SDL library that was used to build Hatari.

For reference, this was with Hatari(en) version 1.9.0, ( running on Mac OS 10.11.6 ) which is a bit of an old one, as version 2.0.0 has been available since November 2016.

Hopefully this helps someone..

I've since then removed that US keyboard layout from my mac and re-identified the keyboard as the ISO/European one so have to repeat the process again.  This time round the MS keyboard has hash next to return and all the pictures on the keys do the correct thing on the mac.  So backslash is next to one shift key and forward slash is the one next to the other shift key (confused?)

I tried this again today and it seems to be using the keymap.txt I've shown above.  The only confusion was I thought I'd lost the hash (#) key, but instead shift 3.  So that still means the key to the left of 1 is generating the same scan as key to the left of enter.  2b and 29 in hex is 41 and 43.  So one of the lines:
92,43
96,41

needs changing.  I'll set 92 to A (30) and 96 to Z (44) temporarily... do hatari preferences, select the keymap.txt file again (no reboot)... and the key to the left of 1 is generating a z. but the hash key is still doing backtick.  And the key to the left of z is generating 'A'.. oops.

So 92 needs to be 41. (ie; make our key to the left of 1

and 96 needs to be 96. (ie; make the key to the left of z generate the key to the left of z)

And putting that in makes the key to the left of 1

And then at some point you think you're going mad... so I set key 45 (underscore) to key 43 (the one to the right of enter)
and then both keys generated a forward-slash. (ie; the one next to enter)..
So I checked the config again..
And remapped 35 to 43

Here's the finished config...
# UNDERSCORE(dash) (s) or 12
45,12
# equals
61,13
# to the left of enter(35)
35,43
# between enter and backspace or to the left of 1
92,41
# to the left of z
96,96

Good luck.

addendum: You might find this page useful, it relates SDL keywords to key numbers..
https://www.apt-browse.org/browse/debian/wheezy/main/i386/libsdl1.2-dev/1.2.15-5/file/usr/include/SDL/SDL_keysym.h and seems to map to what I just did...

 SDLK_MINUS  = 45,

 SDLK_EQUALS  = 61,

 SDLK_HASH  = 35,

 SDLK_BACKSLASH  = 92,

 SDLK_BACKQUOTE  = 96,

 SDLK_LEFTBRACKET = 91,
 SDLK_RIGHTBRACKET = 93,

 SDLK_DELETE  = 127,

 SDLK_INSERT  = 277,
 SDLK_HOME  = 278,
 SDLK_END  = 279,

25/26 Years since... the Mega STE

2016 should have been all about the 25th anniversary of an Atari ST released that ran at 16mhz. Except that 1991 was a terrible time to be releasing computers. There was a huge amount of competition, and besides this 5 years earlier, someone had been there, done that and done it properly…

30 Years Ago... 

So, we go back in time to 1986/87.   Apple developed a computer that could run multiple monitors, in colour, at 16mhz, and not be slowed down by ram having to share memory with video or be accessed 16 bits at a time.   This was the Macintosh II (released March 2, 1987)

All about RAM and performance

So you’d think I could just type into google Mac II memory bandwidth and get the answer. Unfortunately not. The simple answer is its got a 16mhz processor that accesses memory in 32 bit chunks (ie; a true 32 internal and 32 external design). Unfortunately the cost was between $6-8000 for a fully functional system (1mb ram, 40mb hdd) possibly reducing to $3000 over time.. So it made sense where a business needed any of these features.

A nice summary of the system (Macword Macintosh II celebrates 25th anniversary)

A clear leader?

So you think that would be the end of it, Apple just need to keep stomping on the competition as this is still better than anything anyone else can produce.   Maybe reduce the price or number of slots, but keep everything else the same.  Moore’s law would let you develop the next generation (eg; 20, 25, 33 mhz) motherboards and cpu’s and sell them at the premium prices, and then advertise lower spec machines that come from the exact same production process.

Project Lower Cost (LC)

But instead they stomped on themselves and went to plenty of effort developing machines that were cheaper and less expandable.  One of these options was the Mac LC, released in October 1990 [introduced 1990.10.15 at $2,400], which had more colour than any Atari Mega STE without graphics card and cost $3000 (including hard drive and monitor).. Even cheaper was the Mac Classic II ($1900, 2mb ram, 40mb hdd), released in October 1991 which had no external monitor options (and resolution was limited to 512x342 in mono) which seems to have better performance than the LC.

A comparable Mega STE?

Realistically, the Mega STE wasn't released with additional graphics options and wasn’t well publicised* at the time of its announcement.  In theory I can claim it could have sold for £629 (no hdd)/£799 (1Mb) or £929 (£1149 including 12" mono monitor) and 48Mb hard drive (2Mb). (Its hard to find advertising for it in 1991 ... It seems to have been announced in 1990, and trickled into existence in 1991 and Atari printed an advert in November 1991)..
So the Mac classic II is probably about 25-30% more expensive for the same config with smaller screen and smaller hard drive.. released within 2 months of one another.
*Prices from 1st choice computers December 1991, Power Computing April 1992.

Next generation CPU

And then there’s the architecture differences.. The Mac LC used a 32 bit processor* on a 16 bit bus, but had separate vram (video memory), and so ran at 16MHz without cache. The Mega STE used a 68000 processor on a 16 bit bus, with a cache. Performance was close but not quite 2x the speed of a normal ST (with the cache enabled. With cache disabled, there was almost no noticeable increase in speed -- ST Review) so it’s hard to tell which one was actually slower from these descriptions..
But the cpu architecture, the separate video ram, will have meant that definitely the LC was faster even with descriptions such as “the 16 MHz 68020 based Macintosh II from 1987, with an identical processor, ran almost twice as fast as the Macintosh LC”

The advantages of the 68020 over 68000 are 32 bit ALU so 32 bit maths happens in less clock cycles and it has an instruction cache, so there is not as often a need to access ram to fetch after each instruction.   And the LC used the 68030 which has a memory management unit (MMU) which is also very important for running programs more reliably.
The consequences of these design choices can be summed up in one chart that shows that 68030 based macs all running at more than 2x the speed of any 68000 8Mhz traditional mac.
Speedometer 3.06 from low end mac [http://lowendmac.com/benchmarks/speedo3.shtml]
Macbench 2 results are more conservative, showing the slowest 2nd generation mac scoring 0.87 vs 0.37 for 8mhz machines. [https://web.archive.org/web/20020209223728/http://macspeedzone.com/archive/Comparison/oldmodels2.html]

Actual Atari Benchmarks

Of course that still leaves a couple of questions about speed which remain unanswered, - is an 8mhz Atari faster than an 8MHz mac and therefore could a 16MHz Atari be faster than a 15.6672MHz mac.  I don't think there's a simple answer to that, but from the architecture design discussed so far, I would say the same code doing cpu bound stuff (raytracing, spreadsheets) etc, you're only going to see the Macs win.
The operating system on the Mega STE might be enhanced for speed (eg; printing over parallel vs serial, text display enhancements like NVDI, potentially careful use of the blitter) but ultimately, its all trying to fight an uphill battle.

That's all for now.  I was going to add a video of someone else's take on the Mega STE and just to say its extremely compatible with existing STE applications and software and they later enhanced it with a new rom: the advanced TOS 2.06 and high density (1.44meg) disk drives.  The other thing the Mega STE has is a vme bus which gives extra graphics options.. which makes it very expandable. ok out!

This video by Dr Steve Bagley gives you a little idea of what they look like.

What do you want for christmas - New Atari Hardware??

Product	Price	Available	Compatible	Shop link?
Atari Falcon	£800	Rare	Many fixed games	st freakz
Firebee	€643	Yes	No: Good for apps.	firebee.org
Suska III-C	€526	Yes	Yes: Incomplete 68030MMU and DSP	shop.inventronik.de
Vampire 500 V2+	$500+	Not sure	Yes: disable it for full compatibility.	apollo-accelerators.com
MIST FPGA computer	€199	Yes	Yes	lotharek.pl
Amiga A1200 Built To Order	£159.95	Limited	No: Needs rom development	amigakit.leamancomputing.com

16/32 systems last chance!!

Just a quick note to mention that if you still have any interest in physical Atari ST STE TT Falcon Jaguar Lynx software, 16/32 systems are about to shut up shop..
More details:
http://www.1632systems.co.uk
http://sales1632.myzen.co.uk/acatalog/ [announcement and online shop]
You've got till this Sunday..

So thanks, Nick H, for all the years of service to the community.

25 years since 1990 - The Atari STE

The Atari STE was an improved model of the Atari ST.  It was widely covered in the consumer Atari magazines and cost a small percentage more for the base model.  It was more easily upgradable than the original ST.  The inclusion of a “blitter" as standard meant that the user interface was faster for GEM applications.

The machine was originally released very late in 1989, and so 1990 was the year when it had its greatest chance to make an impact.

From my reading of various background stories, it seems that Atari made a great deal of effort from an engineering perspective to create a good product with good compatibility with existing hardware.. however of course games developers who had perhaps not felt the need to follow developers guidelines to the letter (and probably not had a chance to test on the latest machines) were caught out by glitches.

My initial impression was that the big causes of these bugs were changes to the ROM that had a bigger impact than expected.  In retrospect it is interesting that just over 12 months later the ROM shipping with TT and Mega STE machines introduced lots of very useful features to the desktop (so it could easily have been more capable but less compatible release).  In addition ROM versions 1.62 which came with the STE was broadly the same as version 1.42 which was released with new Atari ST machines built at the same time.  Compatibility is a huge topic and Atari’s response to the problem was not the most encouraging to potential purchasers:

“If the programmers have written to our specifications then there won't be any problems.”

http://www.stformat.com/features/features-539.html

ST Format suggested there were 30 games with compatibility problems.  The reality was that all STOS based games were broken (Which meant alot of Public Domain / shareware software as well... Later a software program was released which fixed STOS games on a patch per executable).  Having recently looked at trying to run games using an emulator and different ROM versions, it seems very likely that a large portion of compatibility is down to the very specific differences in the ROMs.

So: Assuming you might want to decide which machine to buy in 1990, you’d have a choice between (the STE,) an Amiga, an Atari ST, a PC, Macintosh, Super Famicon, and potentially a Sega Genesis/Megadrive - The Genesis had been released the year earlier in USA and reached Europe in Decembr at the end of 1990 as (games) developers were choosing whether to support Amiga/Atari, Genesis or 4 platforms if you include the STE.  Given the chicken and egg situation in 1990 (no sales of STE machines, existing ST games will usually just work on an STE…) it seems obvious now why 3rd party developers had little incentive to develop STE enhanced games rather than port their existing titles to the Genesis (which might be easy because the games are 68000 based).  Early interviews with people who had developed ST games suggested there was some animosity or anger toward Atari.

So Atari promoted the machine for its ‘serious’ applications.  For a short while, Atari had the Mega ST as a 68000 based machine with a blitter running at 8mhz and the STE, the same thing, for less, in a slightly less ‘business style’ case.  Eventually they finished the Mega STE which had a 2 times faster processor, but this took until the end of the year.  All during 1990 the old ST was still for sale at a slightly reduced price.

Applications enhanced for the STE could benefit from..

- enhanced sound - playback of ‘real’ samples recorded in 8bit stereo at up to 50khz took no processor time.  This was useful for ‘tracker’ based sample playback and ‘quartet’

- faster image/screen draw speed - using the blitter - not just for games, but all applications benefitted.

- extra colours could be used in art programs eg; using 16 shades of grey rather than only 8.

Games developers could relatively easily also make use of

- hardware scrolling, as used in vertical scrollers like pinball dreams.

- Extra joystick ports - for games that need more than 2 players.. although almost nothing ever used this.

In total then (possibly with the exception of audio quality) none of this made games better than those on the Genesis/Megadrive or Amiga - because both of those had better ability to display more than 16 colours and to more easily handle ‘sprites’ (assuming developer kits had good code examples -- Although the blitter helps with sprites, without example code in the development kit, it needed manually programming.)

Compatibility information:

[http://www.atari-forum.com/viewtopic.php?t=14675]

In hindsight, there are a few things that could have been done better, but market forces ultimately played a very big part in giving Atari a hard time.  The Amiga was likely selling at least 2x the number of computers relative to Atari, and the STE didn’t mean Atari had caught up with technical abilities (apart from the continued marginal difference of 7 vs 8mhz)  The continued availability of the ST as well as rumours and more rumours of other serious machines (TT, Mega STE) and game machines during 1990 (eg; discontinued Panther machine that might have been as capable as an Amiga or very close in capabilities to the Jaguar) created a confusing picture for any developers.

Developer kits and ROMs had very few enhancements to allow standards compliant (esp game) software to be written.

The third thing that could have made a difference, was that thing that the genesis had, that Atari didn’t have: A really great unique thing that was as playable and fun as Sonic or Mario.  It looks like Atari weren’t interested in making games. (despite having a really successful arcade business).

In hindsight though looking back over the archives of 1990, the ST impressed me with 

a) the huge back-catalogue of games

b) the variety of software that was released each year,  from in-depth strategy games to puzzle games that is now associated with causal tablet/phone play.

Atari Really Should have:

- Stopped all sales of the (original) ST.  They might have had good reason to continue selling - like excess inventory in warehouses, but the fact that the ROMs got updated (to 1.4 and so made old software break) suggests that it took extra work to keep building these obsolete machines.

- Got to market before christmas 1989 (and got to developers even earlier).

- While waiting for the Mega STE licence/approval, offered STE’s with immediate upgrade to Mega STE when they become available. eg; pay for the Mega STE in installments - half before and the final half on delivery/exchange.

- Offer updated media (or exchange) for any existing software affected by compatibility problems.  If a software house isn’t interested in fixing its stuff, retailers will be returning their products.

“ST Power Pack with 24 really cool games,” says Darryl Still, “The pack itself was a monstrous success, selling millions, but also managed to really hack off the developer and publisher sector, because the end user had no need to buy any more games for some time after their initial purchase.

Hatari - A brief guide (on a mac)

I keep hearing good things about Hatari, especially with respect to faithful emulation.  So finally I have a little chance to try something which to me is new.

So the brief guide:

• Use the latest version of Hatari. I used the official download, which also has mac editions (v1.7.0, released june 2013). Official website.
• Use the standard settings for an ordinary 68000 (8mhz, 2mb, 'more compatible cpu'), lets not get fancy and it complains if the rom won't work with the processor.
• And use a standard official atari rom. I used 1.62 for an ste (because I owned one when I was younger)
• If you have floppy images, use .msa or .st format.  .dsk files are of no use, and getting them converted on a mac is difficult.. alternatively...
• Build a floppy disk using its own utilities.  Leave .img in the file extension even though it complains.  These can be mounted onto a mac using disk utilities. (or mount by right clicking and use disk image mounter)  Use the command prompt and 'open /Volumes/Untitled/' to get a window on the desktop.
• Copy files off the internet onto the mounted disk image.  Expect the mac side to add unnecessary files (with ~ and trash in the name).  These can be deleted using the (mac) terminal eg; cd '/Volumes/Untitled'; rm -rf .Trashes/ ._* .Trashes/ ._.Trashes .fseventsd/
• Unmount the disk using Disk Utilities (or if you see it on the desktop, drag to trash)
• Rename it as .img.st and add back to Hatari (Insert disk 'A').

I tried this with neochrome master.  It worked perfectly with the correct rom.  And I eventually figured out how to right click on a mac.  Neochrome and other games (Turrican) demonstrate how often the atari uses a palette change half way down the screen.  This is why emulation is hard.

More advanced... (hard disk images)

I wanted to use a hard disk image like other emulators -- Mostly I failed, however...
from here: http://atari.8bitchip.info/DiskImgPP1.html there is a smallish (approx 100 meg) download that contains 3 partitions, the first of which contains a few games* to test* your emulator with.
I added the file under Hatari, under Hard Disks, in ACSI HD image, selected the 1GB.img from the rar downloaded, and ticked 'boot from hd'.  When you boot there is a plaintext screen which lets you select which drive is 'C' (leave it as 'C', as D and E were blank for me)
If you choose emutos instead, you don't get this boot screen (even with 'patch TOS for faster boot' deselected), but you can still see drive 'C' and so see if any games work with emutos.  Mostly these games have been 'modified' and have a spectrum 512 opening screen, so unlikely to work with 68040, faster cpu etc.
*Well to be fair its plenty of games, and its a serious project making those games compatible with running from a single hard drive.  And it can take some time to completely finish testing a game... so many thanks to P Putnik.

Playing the games... (aka the keyboard)

I don't have a joystick that I can use with my laptop, so keyboard acting as joystick will have to do.  You need to configure ST Joystick '1', and probably leave ST Joystick '0' unconfigured.  I had trouble getting it to recognise 'left shift' as a button press, so configured 'left control' instead.   I don't know how it decides whether to send a keypress or a joystick press, but the default is to use the arrow keys, so you might want to disable that if you're using a word-processor..

Alternative editions...

I also tried a smaller custom build (http://dhs.nu/hatari/) that lets you change the cpu speed up to 128 mhz (and back down again, without a reset).  The ACSI hard drive mounting still works (it is called 'HD image').  It reported itself as being version 1.2.0 from Feb 2009, with a 4mb filesize.  This one has a smaller screen and even full screen mode isn't very big (Preference: 'Zoom ST-low rez' fixes this).  Obviously, some games are unplayable like this.
And I tried a 1.6.1 version with a Jan 2012 timestamp, (http://jerome.vernet.pagesperso-orange.fr/emulateurs.html) which seemed to have a bug in that you couldn't actually set the ACSI hard drive location, so it just stayed blank in the preference screen.  The existing config still worked, but it was frustrating as this was the first hatari I tried.

And one more thing...

So having understood what worked and didn't, I tried swapping out the acsi and swapping in an img, and swapping out an ste rom for an emutos rom and swapping the 68000 for a 68040, and adding more ram..
and an img I got about half way (no mouse, crashes easily) with was from miniPack.zip but I wonder if there's a better version out there.
So what I'm saying is that the .img format is supported and works.. Its just a case of finding a .img example that works well for my purposes: installing an os that then supports ext2 or some other common compatible large file format.
.. to follow up for next time : http://ragnar76.taurus.uberspace.de/wiki/index.php?title=Paul%27s_guide basically saying which parts of freemint to use for a standard 68000.

Upgrading / Aranym and the miniPack

Upgrading:

Other computing systems get upgraded from time to time.  'New' operating systems to replace the 'outdated' or no longer supported systems.  Almost every year there's a new release of mac os, and slightly less frequently the release of a re-versioned and re-imagined windows.  Android and other mobile phone users complain when they can't immediately get the latest versions of their operating system.

Of course there are a few expectations and hopes we all want from a system upgrade.  Perhaps, most importantly, that it will be 'pain free', that we get to keep all our data, and that our machine can still boot - ie; that we don't turn it into a brick.  The expectation with an aranym system is that I can make a reasonable backup (preferably off site) and then go back to the old setup if everything goes wrong.

So the next expectation is that everything that already worked will still work.. The so-called backward compatibility.  There are no promises with the mainstream operating systems, but they do tend to try fairly hard to not break anything intentionally.  I haven't tried running any windows 3.1 software on windows 7, but I know that mac os 9 software and now power pc software won't be running on Mac OS 10.7 or 10.8.

Our expectation for Gem / emuTos / Freemint is much higher: anything that uses the published interfaces should continue to run.. Otherwise, we call it a bug and hope that there's a patch released.

A final expectation is perhaps the most important for testing new releases.. in that we hope to be able to understand the process, and that it takes few steps, and takes little time, in that it is not such a huge undertaking that we postpone it indefinitely.  I suspect that many windows XP and vista users haven't gone to the latest available option because of the expectation that it is complicated, time consuming and slightly worrying... What will need re-installing from scratch, what software will just disappear.

We have an advantage then, that our upgrades are faster (because the operating system is just the operating system), simpler (because we can just move or rename disk images / edit configs and reboot), and more reliable (well at least simpler to revert if it just doesn't work).

So what am I doing and why... Basically I've been chickening out of upgrading, and the more often I do it, the more easy and quick it becomes, and the more often others do it, the more likely we have more reliable systems, and the more likely we can report problems that happen from one version to the next, so that these problems can be fixed.  By showing how quick and easy and understandable it is, the better.

You can also use the same software if you don't have an existing working setup and just start from scratch.

So here is my plan..

* Download the latest of everything from the following two sites:

Emulator: http://sourceforge.net/projects/aranym/files/aranym/

Image of the os: http://eureka.atari.org/miniPack.zip

 - This image of the os should includes the latest Emutos rom, the latest stable mint release, the latest xaaes (the bit that runs gem programs), and hopefully fvdi (the bit that does fonts and graphics).  

[Unfortunately the miniPacks are not obviously versioned so what you end up with may be more modern than what I get.]

* Backup the old config.  Also note that the old boot disk might be worth backing up.

* Install the 'boot disk' from the miniPack (by copying the image and editing the aranym config to use it).

* I also want to include as much of my previous mint config as possible, so I will be copying my /mint/xxx/mint.cnf over as well:

So here goes:

start: Backup the old config:

 Copy 'config' and '/mint/' folders to a new directory. Zip them up. login to box.net. upload.

 4 meg zip file uploaded 

0h 05m Open the minipack.zip and take a look.

 in Aranym_files rename 'disk.img' to 'miniPack.img'

 Add a folder in the Aranym config area called 'miniPack' and copy all the files over.

 Copy the new config one directory up and 

Edit the Config:

wherever there's a reference to xxx.img add miniPack in front:

[GLOBAL]

EmuTOS = miniPack/etos512k.img

[IDE0]

Present = Yes

IsCDROM = No

ByteSwap = No

ReadOnly = No

Path = miniPack/miniPack.img

Add back 'drive_c' (a folder on my machine) as a hostfs: (so I can fix the mint.cnf how I want it)

[HOSTFS]

E = drive_c

0h 17m Boot to desktop and

(tried with MacAranym present in the miniPack.. failed with the following message:

 FATAL ERROR. You must reboot the system
[update 2012 Oct 11 - there's a new release of MacAranym JIT 0.9.14 and that has probably been bundled with the latest minipack]
)

0h 25m tried with MacAranym fresh download..

 and boots ok.  I noted that there's a problem with the keyboard, but I'll fix that later.

0h 28m Copy over their mint.cnf from the 'C:/mint/' to 'E' so I can edit it on my mac [otherwise use qed].

If you can access drive 'E' then copy anything from the mint folder that you'd like to keep to the 'C' mint folder (if they've left room).

Editing the mint.cnf:

- Take your time over comparing and merging the new file from the .img and the existing from previous configuration.  As I have plenty of references to 'D' then I need to

- Add back drive 'D' ([partition 0] entries) -- see previous posts on how to create a 'D' from scratch.

- copy over ext2.xfs to 'C:/mint/'

And do a proper shutdown before I start up again (to get the aranym config file read properly).

To check this is working how I expect,

In toswin2 select 'start shell'..

0h 40m To fix the keyboard.. open two windows (double click the 'C' drive icon twice):

  C:/mint/

and 

  C:/mint/keyboard/your_choice/ (I chose Britain)

Copy your keyboard.tbl to the C:/mint/ window

 and Reboot (ie; just from the desktop).

.. And we're done ..

Comments on the current releases of the available emulators (as tested on an intel mac os 10.6.8)

MA jit - broken in 9.14

MA MMU - Too slow to consider running for any length of time

MA jit IEEE - 9.13.2 works well. CPU usage high

With thanks to:

http://aranym.org/

François Le Coat (preparer of miniPack) : http://eureka.atari.org/miniPack.zip

Also of interest: (examples of aranym tuned specifically suitable for different tasks such as doing a better falcon emulation)

http://aranym.lutece.net/