mizapf

The "sharp output" is without any filters, the default filter slightly blurs the pixels. You can achieve that in possibly several ways by the command line; one that works for me is "-bgfx_screen_chains unfiltered". The default is "default".

error.log is created by the option "-log". The "-oslog" outputs the same content to the console.

The general problem with all software emulations is that you cannot achieve the inherent parallelism of hardware. Where you connect some circuits in parallel to a bus, you have a for loop in software.

I knew we put that down somewhere: https://www.ninerpedia.org/wiki/GRAM_Kracker_format

Then inherited by the Geneve GPL mode cartridge loader ...?

ff: More files to load 09: ROM space 2000: 8192 bytes long 6000: Start address (hex) The file size is 8192 bytes plus these 6 bytes. ff: More files to load (00: last file) 06: GROM space, GROM 6 (05: GROM 5, 04: GROM 4) 2000: 8192 bytes long a000: Start address in GROM space (hex) (8000, 6000)

Yes, you could save on "Ignored". Like in the Unix world, no news is good news, so any kind of message is a warning or an error. But this is a great and long-awaited enhancement. Can't tell you how many times I misspelled the directory name when using CD. (I'm currently watching my Farscape Bluray box, so as a shorter exclamation I'd suggest "Frell", "Yotz", or "Dren". )

Updating is always a good idea except in cases when it breaks something. (And I'll warn against that, promised. 🙂 ) No new features right now; as I said, the summer break is coming, guess I'll find some more time then.

Double density is just a different encoding of the data which reduces the flow changes of FM recording (single density), so the cell size may be half as big as the single density cell size. From the physical point of view of the drive, there is no difference. High density, however, uses a different magnetic force for recording and requires a suitable recording medium (high density floppy disks). This is the reason why high density disks don't usually work with double density drives.

OK, this worked as promised. I edited the tipi.config file by setting "NATIVE_TEXT_DIRS=MDOS.". All text files in the MDOS folder (which was created by git) are now shown as DIS/VAR 80. Using the git command should be the easiest way to pull the GeneveOS sources. The only left issue is that MDOS shows a subdirectory "/git" on DIR which is of course the .git subdirectory on the TIPI. Maybe you could add a feature that allows to hide that subdirectory from the TIPI directory display (if that is not already possible - I'm getting cautious about what I may have missed in the descriptions).

Ah, OK. Sorry, I did not follow the thread - will try when I return to my system in a few days. Thanks for the pointer.

This is slightly uncomfortable, as they do not show up as DIS/VAR 80 files on the TIPI drive when you access them from the Geneve. I suppose you don't use a header for direct editing on the PC.

One of the most hilarious flicks in that series was the German version of "Tie Chao Ren" (German Title "Roboter der Sterne", engl. "robots from the stars"): https://www.imdb.com/title/tt0365808/ with an absurd, confusing story; effects like from a 10-year-old playing with his plastic robot toy; and utterly cheesy dialogs, as the German dubbing team neither understood the Japanese text nor had any other hints, so they invented the dialog from scratch.

The tipi should already contain the git command. Try this on the tipi: $ cd ~/tipi_disk $ git clone https://github.com/BeeryMiller/MDOS This creates an MDOS subdirectory that you can read with the Geneve and TIPI support. However, I noticed that all text files are visible as "DIS/FIX128". Is that intended? Or are they lacking a TIFILES header?

Have a look here: https://ftp.whtech.com/user groups/Lima/library/0003.DSK This disk contains more files, but seems to have those files listed above. (Found with TIImageTool. 🙂 )

Does it work reliably now? In our last message exchange you seemed to be successful.

When you use the MFM harddisk emulation in MAME (with the HFDC), it takes some seconds until the harddisk completes its spin-up. I think you can see it when you enable logging (-oslog or -log). My problem is that in the real system I would fire up the harddrive some seconds before turning on the rest of the system, but I cannot do that in MAME.

The fun thing about this TV series (which I know well, too) is that while you watch the movie, you get some joking overlay comments from the two hosts of the show. If I remember correctly, Oliver Kalkofe was inspired by the German release of Mystery Science Theatre 3000 and then launched this series of "Worst Movies of All Times" with his colleague Peter Rütten. It's absolutely hilarious. Ah, there is a Wikipedia entry: https://en.wikipedia.org/wiki/SchleFaZ

The MAME emulation of the PIO is the simplest one possible, that is, output to a file only. I never touched it, unlike the serial output.

I don't have the Audio gate trick, but the Dragon's Lair demo does have sound, also the Spaceballs video etc.

I have some issues with building the current release on Raspberry Pi. The GCC has been failing for quite a number of releases by now, but now Clang also fails to compile. This occurs since an update in a 3rd party library (LZMA). It is not MAME-specific; maybe someone here has an idea: Compiling 3rdparty/bx/src/dtoa.cpp... ../../../../../3rdparty/lzma/C/7zCrc.c:158:1: error: unknown architecture 'armv8-a+crc' in the 'target' attribute string; 'target' attribute ignored [-Werror,-Wignored-attributes] ATTRIB_CRC ^ ../../../../../3rdparty/lzma/C/7zCrc.c:89:58: note: expanded from macro 'ATTRIB_CRC' #define ATTRIB_CRC __attribute__((__target__("arch=armv8-a+crc")))

Yes, here: http://www.mizapf.eu/files/genevetipi_boot.webm (updated TIPI software to 3.17)

Right, nothing new (release 0.255). Sorry, I've had a lot to do in the last months, summer holidays will be coming soon.

The floppy drives 3 and 4 are not connected by default. Also, you have to make sure that you use a controller that supports four drives. mame ti99_4a -ioport:peb -ioport:peb:slot8 hfdc -ioport:peb:slot8:hfdc:f3 525dd -ioport:peb:slot8:hfdc:f4 525dd [further options] If you want 80 track drives, you have to use 35dd (3.5" drives, not the 5.25" as given here). While this is working, I rarely use more than one floppy drive. I don't see any particular advantage of using so many drives, as you can easily create emulation configurations with suitably mounted floppies.

I did not try that yet. Will report.