emutos / emutos Goto Github PK

We're reaching out to ask if it's alright with you for us to include the emutos-amiga.rom as an integrated replacement ROM within vAmiga. Would that be okay for you?

vAmigaWeb
On the web-assembly PWA version of vAmiga, directly runnable at https://vamigaweb.github.io , we also aim to offer users the option to install emutos-amiga.rom with just a button click, similar to how we currently provide AROS kickstart replacement ROMs

We would be delighted if this is fine for you! 😀

currently we implement the .st floppy image format compatibility so that we can drag .st files into it.

native built for macOS
https://dirkwhoffmann.github.io/vAmiga/

PWA enabled for ipad, android, windows and all the others
https://vamigaweb.github.io/doc

During testing of an old serial printer I determined that the serial interface driver doesn't honour the X-ON/X-OFF flow control method.

How to test:
(1) Using XCONTROL Model CPX set baud rate etc. and flow control as X-ON/X-OFF.
(2) Select "Modem" as the printer output.
(3) Connect printer which uses X-ON/X-OFF flow control and not hardware flow control.

Print document larger than the printer's buffer.

This test works under TOS 1.04 but not EmuTOS 1.0

The demo Systematic Error by Imagina does not run when using EmuTos 0.9.9 (not sure if it ever ran) configured as a STe. The demo runs fine with TOS 1.62.

"Detected double bus/address error"

What can I do to help investigate this futher?

The 192KB works like a charm 🥰
But the 256K crash, even when trying from PRG.
It works only if configured as "STEroids" (The overclocked version of STe)

I think it would be a nice improvement for TOS apps to run correctly in 640x200 resolutions. Meaning no longer stretching the UI so much as it's incorrect for the tall pixels. At the very least allow for swapping some elements for more tuned icons, window decorations, lines, borders, etc.

Icons are too tall, windows and dialogs look horrible with thicker lines on top due to tall pixels, fonts look terrible and don't correctly render, etc.

Hi,

I have 2 G_IMAGE in my RSC (of color 9 (dark gray)) which appears red when the blitter is active.
The G_IMAGE are displayed by objc_draw() (In their form)

Blitter active

Blitter off

Tested with snapshot 2017-07-10 and 2017-08-24 (Hatari (mega) STe / Falcon)

(Sorry for web translation)

Select floppy icon (B for example) doesn't select drive B in format floppy dialog when opened the first time.

Checked latest version of EmuTOS 1.0/1.0.1 and noticed that XBoot III cannot auto launch programs. Program supposed to be launched right after programs in AUTO folder. On TOS 2.06 it works as expected. Checked it on 520ST+ with Cloudy/Lighting ST.

This line in amiga.c finds the end of a static buffer to append a character to it:

A better way would be to store the pointer somewhere along with the buffer itself.

Hello,

neither emutos.prg nor emutos floppy can be started from emutos cart (1.2 and 1.1.1 tested). The image is loaded, but instead of initialization, everything is reset back to emutos from cart.
Loading of TOS2.6 using seltos utility is possible, though.

To EmuTOS team: I tested only 4 programs myself with EmuTOS 0.9.9 192K v.
3 of them had issues. Clearly, some compatibility issues. I even wrote message from Sourceforge to project leader, what was sent to him as e-mail, I guess. So far, no any response. (3 days.).
I will try here - since on AF is not possible to talk normally. And yes, this is my last attempt. I have better things in my life to do. Just want to finish things as much possible, and to try as much has sense.

So, issue 1 is that false detection of key release. Overlong mess at AF about it. It is clear that docs are not enough detailed - no word about what exactly should return in d0 after calling that Ikbdsys vector function.
Issue 2 : Video player: That txt at page with incompatible SW, what says about my code searching some pattern - clearly prejudice. You seen couple of such, so assumed that is. And yes, it is at that place - that is last attempt to do the job, if regular way fails.
And regular way fails with EmuTOS because it uses total unusual, non standard way how hard disk driver and it's loading at boot work. Complaining on lack of space in ROM, then adding there hard disk driver ?
OK, but then make it as option, leaving option to use autoboot driver on disk. Don't see that it is possible. I assumed that some disk utils will not work, so checked. Indeed CHKDSK3 (Atari SW) has problems with absolute sector access. And that is dangerous situation. Some data corruption can happen if someone tries to edit sector on drive, and it goes on wrong place.

Issue 3 - the best case: I made some simple, AES call based demo. 3KB only. OK, let's try with EmuTOS, after tried with all reg. TOS versions.
There were 2 problems: bad color of ball for slide and not moving mouse cursor during slide.
First one: I thought that it is bad palette in low res, but it is rather bad Icon color implementation. See later more ...
Second is bad implementation of Appl_play AES call.
And here we are at sheer essence of problems: bad documentation.
In my ProfiBuch stays that 1 record is 6 bytes for Appl_play, and my handwritten correction from some 10 years ago that it is 8 bytes. Error #1 - found while testing that 3K proggie.
There is other error: Icon color related - Error #2 .... But I tested my SW, and I seen that color is bad, so I corrected until got desired color. With Appl_play was no problem, since I had good literature - mine handwriting :-)
So, EmuTOS team made OS, but did not test many things - like that Appl_play AES call, and many other, I guess. Blindly relying on docs is mistake too. And Atari ST docs are really full with mistakes.
That's what I have as bug report. I hope that we can talk as normal people about all problems.

PP

This gentle RFE is about having the EmuTOS hard disk driver as standalone driver as part of the build process, similarly to EmuCon.
The EmuTOS hard disk driver has a bunch of nice of nice features like full XDHI support and TOS/DOS partitions.
Having this driver available would allow to create ready to use to use disk images for the FreeMiNT project, similar to what ST Mint is doing, which could be used on real hardware, without requiring users to replace their TOS Roms with EmuTOS.
Alternatively the option to use EmuTOS as a FreeMiNT loader would cover this need.

Traders hangs on startup when being run with EmuTOS (192KB)

Screenshot:

Links to download the game: https://www.atarilegend.com/menusets/143?page=2&fbclid=IwAR1KvI07J3GnZlszGPd5k4DZ2Q18D3zv0glrEiWdhzKCM2uoAJ5CyeG00mQ#menudisk-3102

It woks with TOS 1.62.

I have the latest version of emutos as well as the latest version of ExtenDOS.

When running EMUTOS it loads perfectly but does not allow to use ExtenDOS to see my IDE DVD-RW drive. my standard TOS 2.06 works fine and sees it, so i know there are no issues with the hardware.

Does EMUTOS not work with ExtenDOS?

Would it be possible to put EmuCON in a GEM window as an accessory?

I built revision f1444e2 using make 192 and loaded the ROM up in Hatari. I tried two configurations:

• ST, 256K RAM, 68000 CPU @ 8MHz
• MegaST, 2MB RAM, 68000 CPU @ 8 MHz

The EmuTOS splash screen shows up just fine, but it crashes immediately after that:

I also tried the other two ROM sizes -- both the 256k (STE) and 512k (TT) ROMs run just fine without crashing on startup. I am also able to build and run the 192k ROM from 0_9_9-branch at revision be3a7a0 without any apparent problems.

Why doesn't emutos-1024k-1.1.1 support atari-tt mode?
When i plug etos1024k.img rom in hatari i get "This TOS version does not work in tt/Falcon mode.
==> Switching to STE mode now."

attached is a gdos test program and a simple assign.sys,
correct output with TOS2.06 is:

3 screen fonts loaded
font 1, 6x6 system font, id = 1
font 2, Swiss, id = 2
font 3, Dutch, id = 14
font 4, Typewriter, id = 15

and with emutos, the corersponding output is:

3 screen fonts loaded
font 1, 6x6 system font, id = 1
font 2, 8x8 system font, id = 1
font 3, 8x16 system font, id = 1
font 4, Swiss, id = 2

testgdos.c.txt

assign.sys.txt

Looking in the file vdi_text.c, in function vdi_vqt_name(), the loop is counting individual fonts. It should be counting only font families, ie fonts with distinctive font ids, as is done in vdi_vst_load_fonts().

Also, comparing these 2 functions, I would expect vdi_vqt_name() to depend on the workstation, using vwk->loaded_fonts as a base for the fontchain, and then not needing a double loop. OTOH, I don't know this code, so perhaps I am missing something.

Hi all.

I see that currect state of a project allows to build Vamipre V2 version of EmuTOS.

V2 accelerators already have EmuTOS in their cores. So, I think, there should be a way to update EmuTOS in V2 without erasing Amiga Kickstart image.

Do anyone knows how to do it?