I am installing my Pi into an STM case with original keyboard, I will route the HDMI and usb cables etc to the back of the case to make it look as authentic as possible, then I will be running Beepi on it Probably (most likely) far superior to a Firebee :):)
Falcon CT60e 060 - 256mb ram - Phantom bus and DSP accelerated // Atari TT - Thunder and Storm IDE 64mb ram - Lightning VME - USB LAN - ATI Mach64 2mb
Faucon2001 wrote:You can’t read real floppies directly from an usb floppy drive with BeePi. It won’t work. BeePi can only deal with disk image.
I haven't tried using Hatari with USB floppy drives, but I've used it with real floppy drives (many years ago). As long as kernel provides the floppy content as a device file, Hatari should be able to use it. Isn't BeePi kernel compiled with USB floppy support?
(USB devices can be finicky, so having a generic driver for USB floppies doesn't yet necessarily guarantee that given device can be accessed.)
PS. I don't know what device files USB floppies get, and does that need some "udev" magic to work (device files for real floppy drives were earlier named simply as /dev/fd<idx>, nowadays they seem to be in /dev/fd/<idx> files).
If USB floppies are intended to be used with Hatari, one doesn't want to enable any kind of auto-mounting for them, only enable support for having the USB floppy device file present. User may also need to be in some specific group so that Hatari can access such device.
The problem with automount is that if same disk content is being modified both as raw device (by emulator), and as mounted file system (by host OS), corruption is sure to happen. Only single thing should mount the same device at the time (whether it's Hatari or Linux).
You would need some mount rules that don't mount USB floppies, if user wants to access them directly from Hatari (as floppy image instead of GEMDOS HD drive directory).
I do have a NEC UF0002 USB floppy drive which is one of the few that can read TOS formatted 720k disks.
And while i can access itunder /dev/sdb as a regular user from userland hatari simply ignores it if i try to configure it.
But even if it worked it would likely not be the experience you'd expect. These floppies do internal buffering and they prefetch and cache data. The drive would read and write data just as it likes and you wouldn't have the impression of the ST accessing it as a real ST would do. Just plaugging the drive in already makes it seek forth and back reading stuff without the PC even accessing it.
It works OK: it seems to be the best emulated ST available now.
The RPi is set @ 1440x1080/50 Hz
Problems, questions or lacks of my knowledge I found :
Hatari has some problems with audio (RPi 3B @1300, RPi3B+@1400, audio on jack) - it is sometimes distorted as if the emulator wasn't fast enough.
Old demos - Readme.prg, LSD.PRG have this behavior (started as ST with TOS 1.4). The STE demos using DMA audio seem to have no audio problems.
Sometimes (Revenge of DOH) using UK TOS helps with audio quality. It seems Revenge of DOH starts with 60 Hz when TOS is US.
The aranym Atari (what is the emulated machine in this case? 68040 and ? ) doesn't display a wallpaper when I change (increase) the screen resolution and I didn't find where it keeps the wallpaper and where it can be set.
Is there any way to set RPI startup to Hatari instead of Aranym?
In Hataris floppy menu /dev/sdb is not mentioned and the floppy a entry is empty.
If there are no warnings in Hatari output, I'm wondering whether you checked right config file. It's nowadays in ~/.config/hatari/hatari.cfg instead of earlier ~/.hatari/hatari.cfg (or even earlier ~/.hatari.cfg).
You could try specifying it directly from the command line:
$ hatari --log-level debug /dev/sdb
INFO : Image '/dev/sdb' not found
Hatari v2.1.0 - the Atari ST, STE, TT and Falcon emulator.
Hatari is free software licensed under the GNU General Public License.
Usage:
hatari [options] [disk image name]
Try option "-h" or "--help" to display more information.
Error: Not a disk image, Atari program or directory (/dev/sdb)
pik33 wrote:
The aranym Atari (what is the emulated machine in this case? 68040 and ? ) doesn't display a wallpaper when I change (increase) the screen resolution and I didn't find where it keeps the wallpaper and where it can be set.
Change wallpaper : open an image with zview, fullscreen F10, and press ctrl+alt+: to change Mint Wallpaper. You can use Smurf to scale it to the right resolution.
And the floppy actually does something. When i starup hatari this way the floppy spins for a few seconds. But TOS claims that no floppy disk is inserted.
I can even create a folder. But it's newer written back ....
Edit: it is written back once i close hatari. Also it seems that hatari reads the entire disk at startup and then newer accesses it again. So this doesn't give any retro feeling ....
MasterOfGizmo wrote:I can even create a folder. But it's newer written back ....
Edit: it is written back once i close hatari. Also it seems that hatari reads the entire disk at startup and then newer accesses it again. So this doesn't give any retro feeling ....
You don't need to close Hatari. Just eject the disk (image) to access its contents outside of (emulated) Atari. Same as on real HW.
The reason why Hatari reads whole floppy disk content when it's mounted and updates the image contents when it's unmounted, is because:
* they're easier to handle that way (more so when they're gzip compressed)
* there's nothing to guarantee that image contents would be internally consistent when you try to read it from host before eject (e.g. adding a file to a floppy touches FAT, directory entry and actual file data, sectors for these 3 are all in different places on disk, and you might access it in between these updates)
pik33 wrote:
Hatari has some problems with audio (RPi 3B @1300, RPi3B+@1400, audio on jack) - it is sometimes distorted as if the emulator wasn't fast enough.
Old demos - Readme.prg, LSD.PRG have this behavior (started as ST with TOS 1.4). The STE demos using DMA audio seem to have no audio problems.
Sometimes (Revenge of DOH) using UK TOS helps with audio quality. It seems Revenge of DOH starts with 60 Hz when TOS is US.
It's very well possible that PI isn't fast enough for Hatari emulation with the options you're using, and with the SDL version used in RPi. But there may also be some other process taking CPU while Hatari is running, have you checked that?
I can check the performance if you give pointers to the demos where you see the difference. While DMA causes much less emulation work than interrupt heavy ST sound, there may be also some other differences on what hardware the demos use and how much.
And the floppy actually does something. When i startup hatari this way the floppy spins for a few seconds. But TOS claims that no floppy disk is inserted.
The hatari can access the contents. So reading basically works.
Ah, now I see. I checked the sources, and Hatari uses filename extension to determine the floppy format (ST, ST.GZ, MSA, STX, IPF, ST/ZIP). Device file name doesn't have correct extension.
I commited few info messages about that to Hatari repository.
I found a solution to the sound problem in old demos: TOS 1.02
The lesson learned: old demo->old TOS
I also managed to change the start script to make Hatari start immediately after boot. Now there is 6 seconds from power switch to the classic ST desktop - who needs an FPGA implementation if the RPi can do its job?