exxos's Atari, Amiga & retro forum

agranlund wrote: 11 Sep 2025 11:03
ET4000AX cards come in several different configurations and you'll need a hardware variation that fits the T8 or possibly T3 category for the pixel clock required by that resolution. I'm not entirely sure what models are what but there is some info here:
https://silicon-heaven.org/atari/nova/TT030/ET4000/


The open source driver is at the moment limited to the usual SVGA resolutions which pre-dates the widescreen stuff. Ie; 640x480, 1024x768, 1280x1024 etc. For sure something to look at later on, at least for getting a custom resolution of 1280x720 working.

Ah, good to know. Mine is 100% identical to the W82C490 model, which is T8. That picture could be of my card (it isn't).

@Atarian Computing , MagiC appears to still work.
Setup is not super straight forward but I can share some pointers if/when someone else wants to use MagiC.

This is NOVA + NVDI5 + MagiC + Thing.
(desktop background enabled by lp's Thing plugin, which requires NVDI5)

I'm about to start... where do I start from?
:D

My doubt is: how do I format it with Atari drivers? On Amiga I would have used FS-UAE, but on Atari? Is there a ready HD image?

@agranlundCould I see a photo of how you mounted the byteswap adapter?

@luciodra this is how I mounted the adapter.

The side that shows faces the bottom of the motherboard. The "smoother" side of the pcb faces the top.
If you have connectors with a key'ed slot then they all face the bottom of the motherboard, same as the connector itself on the motherboard (if you're using a keye'ed boxheader rather just a pinheader)

luciodra wrote: 11 Sep 2025 20:46 My doubt is: how do I format it with Atari drivers? On Amiga I would have used FS-UAE, but on Atari? Is there a ready HD image?

I don't have a ready made image but my procedure was like this:

- Copy HDDriver, launch HDDRIVER.PRG, run HDDRUTIL.APP
- partition the drive.
- made the first partition a TOS partition of 250 or so bytes.
- didn't use any fancy Tos/Win compatibility options
- did not tick the "byteswap" option.
- made a couple of additional larger TOS partitions
- made a large FAT32 partition (usable in MiNT and MagiC, but not in EmuTOS)

Keep in mind that your disk can now no longer be used on a PC.

I used HDDriver 11.something because that's what I had since before,
I'm sure any other Atari compatible driver+utility would work too.
Your driver of choice is irrelevant when running EmuTOS/MiNT as its only used by MagiC.
(EmuTOS ignores 3rd party drivers found in the bootsector and uses it's own instead)

Basically set the disk up the same way you would if you partitioned a _bootable_ IDE drive on an Atari running Atari TOS -- ie; you're choosing between bootable or PC compatible. never both (*unless you have an intelligent auto-byteswap adapter).
EmuTOS is special in that it's the only OS that allows booting IDE drives that were also partitioned to be compatible with PC.


How to copy the stuff?

I use the utilities included on the rom disk.
parserve.tos if you have a ParCP device connected to the parallel port
ymodem.tos for serialport transfer (pick Y-modem protocol when sending using CoolTerm)

If the disk is blank/unreadable from the get-go:
- use the romdisk utils to copy to the ram disk (M:) and run them from the ram disk

When you already have a readable disk of some sort
- use the romdisk util to copy to somewhere on your disk and run them from there

At this point you're now booting to a blank disk.
Use the romdisk utilities to transfer files and populate your disk
Could be a good idea to aim for getting uIP over fairly early so you can do faster transfers over the network


You could probably also set up your disk using Hatari and simply burn the image.
Sounds like it might be easier/quicker but I have not experience in doing so.

Installing MagiC

Some your-mileage-may-vary here since I'm not sure I followed these exact steps myself -- I already had an old MagiC installation from my ST that I for the most part copied files from, but replaced MAGIC.RAM with the one specific for Raven.
But hopefully it helps to point out some of the pitfalls I saw.


Get a binary snapshot from here:
https://tho-otto.de/snapshots/magicmac/

-- Installing the kernel

copy /en/mraven.ram -> C:\MAGIC.RAM
copy /en/auto/magxboot.prg -> C:\AUTO\MAGXBOOT.PRG
copy /en/gemsys/mfa2.sys -> C:\GEMSYS\MFA2.SYS
copy /en/gemsys/off002.osd -> C:\GEMSYS\OFF002.OSD

This alone should allow you to boot the kernel but without a desktop.
You'll end up with a blank desktop and a file selector and not much to do, but it's still a good way to verify that everything is ok up to this point.

I would start with minimal stuff in the auto folder for now, and in the interest of doing things one at a time I would disable NOVA for now until things are up and running.

Basically, auto programs in this order:
rvbios.prg
xboot.prg
magxboot.prg

You absolutely want xboot there so you have an option to disable magxboot.prg and get into EmuTOS


-- Installing the environment and default desktop

Now, I've been using the files from my old official MagiC6 installation.
At first I tried using only the stuff from those new recompiled binary snapshots but got weird errors and failure to launch the desktop in particular together with NOVA. So I don't trust it and mostly used files from my copy of an official MagiC6 release.
Specifically, "en/gemsys/magic/xtension" seemed to be the root of those problems -- most likely the .SLB Files.
Again, your mileage may vary.

Either way, you want to end up with this:

C:\MAGX.INF
C:\GEMSYS\MAGIC
C:\GEMSYS\GEMDESK
C:\GEMSYS\HOME
C:\GEMSYS\GEMSCRAP

An example MAGX.INF can be found in "/en/extras"
HOME and GEMSCRAP are basically empty folders.

You can *probably* use "en/gemsys/gemdesk" but since you'll *probably* need to get C:\GEMSYS\MAGIC from a "real" MagiC release anyway you may as well get that stuff from there too?


-- Configuring the environment

edit C:\MAGX.INF according to your preferences
- change the #_DEV parameter to 1 0
- I got rid of A:\ from the PATH
- comment out, change or remove the #_ACC line if you want acc's loaded from the normal place rather than having copies in a special folder for MagiC
- any other customisations you may want to make

(I didn't use the one that came with /en/extras as I already had my old customised version from the MagiC installation on the ST)

-- NOVA screen resolutions

When you're able to get into a mono 640x480 MagiC desktop I would enable NOVA.
The auto order would look like this. Any other programs you may have should normally go _after_ magxboot.prg.

rvbios.prg
xboot.prg
magxboot.prg
rvnova.prg

If you use NVDI then it should go immediately after rvnova.prg.
You'd also have to do whatever else you that needs to be done in general for NOVA and NVDI to coexist peacefully (removing/renaming of NVDI screen driver files in c:\gemsys etc).

Now enjoy near-instant boot to a multitasking operating system :)
The drawbacks are of course that it's not as widely used as MiNT, and it's no longer in development, so information can be harder to come by in comparison.

Thank you, there is work to be done... First of all, some welding to review. What I don't understand is: are the Fat partitions usable with the adapter? Because I could start from there to copy the files and run tests. I thought that with the adapter I could only use the Tos partitions.

luciodra wrote: 12 Sep 2025 11:29 Thank you, there is work to be done... First of all, some welding to review. What I don't understand is: are the Fat partitions usable with the adapter? Because I could start from there to copy the files and run tests. I thought that with the adapter I could only use the Tos partitions.

With EmuTOS, you can pretty much use whatever you want. Big-endian, little-endian, TOS, DOS, TOS/DOS dual-custom-hddriver-invention.. it doesn't care and basically works with just about anything you can throw at it (I hope they add FAT32 filesystem support some day, that would be really neat)

In that respect, the adapter wont really change anything or require you to change anything, to use your existing drive in EmuTOS (and MiNT loaded from EmuTOS)

The thing that the adapter brings is opening the door for being able to use non-EmuTOS operating systems (or Atari software that directly speaks to the IDE hardware instead of going through EmuTOS, but those are far and few between)


Atari TOS, and also MagiC, being much older doesn't have fully featured drivers built in. The only thing they are capable of is loading 3rd party drivers off the bootsector of a disc, and they are quite picky doing so assuming an Atari style IDE interface. And then those external drivers themselves are usually more picky / less advanced compared to EmuTOS's built-in driver. They usually expect things to be the Atari way.


Unfortunately Atari decided to wire up the IDE port differently compared to how PC (and Amiga) did it.
(I followed the "standard" PC/Amiga way on Raven which is hindsight was a mistake, but I never counted on wanting to use non-EmuTOS stuff then, hence the need for the byteswap adapter to make it wired up exactly the same as a real Atari)

And even if a 3rd party driver itself would support Intel IDE interface, that doesn't guarantee that the OS's extremely minimal IDE code is able to load that driver off the bootsector to launch it..
(this is why HDDrivers PC-compatibility options will render an IDE drive non-bootable under Atari TOS - sure, the driver will make the disk work in TOS, but TOS itself is not able to load and start the driver from such disk in the first place)