Monday, 28 November 2016

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

ProductPriceAvailableCompatibleShop link?
Atari Falcon£800RareMany fixed gamesst freakz
Firebee€643YesNo: Good for apps.firebee.org
Suska III-C€526Yes Yes: Incomplete 68030MMU and DSPshop.inventronik.de
Vampire 500 V2+$500+Not sureYes: disable it for full compatibility.apollo-accelerators.com
MIST FPGA computer€199YesYeslotharek.pl
Amiga A1200 Built To Order£159.95LimitedNo: Needs rom developmentamigakit.leamancomputing.com

Friday, 17 June 2016

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.

Thursday, 31 December 2015

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.
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:

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.

Friday, 27 September 2013

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.

Sunday, 7 October 2012

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:

 - 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:

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)



Friday, 5 October 2012

addendum.. what else was missing.

There was something not quite right about the previous entry.  When I was booting it was still giving me very little on screen, and so I was suspicious that my actual auto folder was being ignored.. In the logs I had a few auto folders but that didn't match my files..
To cut the story short, I'd previously moved mintara.prg sideways and never found it again, and so never configured the system to boot that way.
Adding a couple of lines to the Aranym config file:


Bootstrap = system/mintara.prg
BootstrapArgs = DEBUG_LEVEL=1 BOOT_DELAY=0 MEM_PROT=NO

and finding my existing mintara.prg

meant I was now booting with the right version.. The boot screen displays lots more and asks me about resolutions, except it then crashes with a bus error..  The last line in the logs is something about xaaes img files..
So I renamed the
[boot]/mint/xaaes/img folder,
rebooted and so got to the desktop.

The mouse pointer is still screwy but I'm guessing I'll do a fresh install soon.

Thursday, 4 October 2012

Finally fixed.. Madness!!

So this was all of my own insanity.

The aranym likes to boot from 'C'.
The 'C' drive can be mapped to anywhere in the world, for the purposes of boot.

My aranym config had:

[HOSTFS]
E = drive_c

(leaving nothing set for 'C') because that's how you let the 'gem' (ide0) partitions boot stuff for you.

But that means all my config (stored in drive_c/mint/xxxx/mint.cnf) is ignored..

So to boot with /Users/your-name-here/Documents/Aranym_files/drive_c/auto (local files on the mac side).
do:

[HOSTFS]
C = drive_c
or
[HOSTFS]
C = /Users/your-name-here/Documents/Aranym_files/drive_c

(and also repeat the same thing again for 'E' .. otherwise we end up with a mint conf that refers to stuff on 'E' which also doesn't exist and we get infinte reboots).

and we're back to programming... 

(except I'm running an old xaaes and the mouse pointer is broken..) 

Just out of curiosity, I changed the ByteSwap = No to a Yes..
and got alot more of the following:

pid  11 (desktop): nfs_root
pid  11 (desktop): nfs_root(3) -> ENXIO
pid  11 (desktop): Minix-FS (D): m_root enter
pid  11 (desktop): Minix-FS (D): minix_sanity enter.
pid  11 (desktop): Minix-FS (D): invalid MAGIC in 1.
pid  11 (desktop): Minix-FS (D): minix_sanity leave r = -46
pid  11 (desktop): Minix-FS (D): m_root leave -46
pid  11 (desktop): nfs_root
pid  11 (desktop): nfs_root(3) -> ENXIO
pid  11 (desktop): Minix-FS (D): m_root enter
pid  11 (desktop): Minix-FS (D): minix_sanity enter.
pid  11 (desktop): Minix-FS (D): invalid MAGIC in 1.
pid  11 (desktop): Minix-FS (D): minix_sanity leave r = -46
pid  11 (desktop): Minix-FS (D): m_root leave -46
pid  11 (desktop): nfs_root
pid  11 (desktop): nfs_root(3) -> ENXIO
pid  11 (desktop): Minix-FS (D): m_root enter
pid  11 (desktop): Minix-FS (D): minix_sanity enter.
pid  11 (desktop): Minix-FS (D): invalid MAGIC in 1.
pid  11 (desktop): Minix-FS (D): minix_sanity leave r = -46
pid  11 (desktop): Minix-FS (D): m_root leave -46
pid  11 (desktop): nfs_root
pid  11 (desktop): nfs_root(3) -> ENXIO
pid  11 (desktop): Minix-FS (D): m_root enter
pid  11 (desktop): Minix-FS (D): minix_sanity enter.
pid  11 (desktop): Minix-FS (D): invalid MAGIC in 1.
pid  11 (desktop): Minix-FS (D): minix_sanity leave r = -46
pid  11 (desktop): Minix-FS (D): m_root leave -46
pid  10 (taskbar): nfs_root
pid  10 (taskbar): nfs_root(3) -> ENXIO
pid  10 (taskbar): Minix-FS (D): m_root enter
pid  10 (taskbar): Minix-FS (D): minix_sanity enter.
pid  10 (taskbar): Minix-FS (D): invalid MAGIC in 1.
pid  10 (taskbar): Minix-FS (D): minix_sanity leave r = -46
pid  10 (taskbar): Minix-FS (D): m_root leave -46

and then switched it back to NO.

and still got one...

pid   0 (MiNT): nfs_root
pid   0 (MiNT): nfs_root(3) -> ENXIO
pid   0 (MiNT): Minix-FS (D): m_root enter
pid   0 (MiNT): Minix-FS (D): minix_sanity enter.
pid   0 (MiNT): Minix-FS (D): invalid MAGIC in 1.
pid   0 (MiNT): Minix-FS (D): minix_sanity leave r = -46
pid   0 (MiNT): Minix-FS (D): m_root leave -46
pid   0 (MiNT): Ext2-FS [D]: WARNING: mounting unchecked fs, running e2fsck is recommended
pid   1 (xaloader): run_km(\c\mint\1-17-0\xaaes\xaaes.km) ok (bp 0x6EDC0E0)!

but the file system is working normally (ie; good).  I did eventually find e2fsck, but I'm no expert on specifying the parameters for that..