3 ATARI running
Francois LE COAT
Here is a recent recorded video.
Three ATARI machines are running simultaneously : Hatari 2.5, ARAnyM 1.1.0 and AtariX 0.3, under TOS 4.04, freeMiNT+XaAES and MagiC.
All is launched with macOS 10.14.6 Mojave on my 27" iMac. The ATARI are playing Eureka 2.12 GEM software, and describe 2D and 3D curves.
In video : <https://www.youtube.com/watch?v=-wXwVaekjmg>
Hatari is quite slow (with a Falcon030+882), because it's "cycle accurate". So it can play Eureka 2.12 only for 2D curves with TOS 4.04.
ArariX is faster because it emulates a Motorola 68020, and can play Eureka 2.12 for 3D surfaces. It runs in 256 color mode with MagiC.
ARAnyM is the fastest ATARI virtual machine (with Motorola 68060). But the appl_tplay() and appl_trecord() system calls are not supported with freeMiNT+XaAES yet. So I played it live with Eureka 2.12.
I hope you'll appreciate...
ATARIstically yours =)
--
François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
https://eureka.atari.org/
Thorsten Otto
On Sonntag, 20. Oktober 2024 15:45:47 CEST Francois LE COAT wrote:
> Here is a recent recorded video.
:thumbs-up: ;)
>But the appl_tplay() and appl_trecord() system calls are not supported with freeMiNT+XaAES yet.
Hm, yes. Dunno whether it is easily possible to implement them in a way that is compatible with single-tos (it relies on certain values to be written to the buffer). But beside Eureka, there are not many applications using it.
Francois LE COAT
Thorsten Otto writes:
Francois LE COAT wrote:
> Here is a recent recorded video.
:thumbs-up: ;)
>But the appl_tplay() and appl_trecord() system calls are not supported with freeMiNT+XaAES yet.
Hm, yes. Dunno whether it is easily possible to implement them in a way that is compatible with single-tos (it relies on certain values to be written to the buffer). But beside Eureka, there are not many applications using it.
All of this is perfectible!
Best regards,
Thorsten Otto
On Sonntag, 20. Oktober 2024 16:31:07 CEST Francois LE COAT wrote:
> Oh yes, but MyAES[1] from Olivier Landemarre, that is an alternative to
> XaAES, implements those system calls. So I know it can be done :-)
Maybe. MagiC also implements it, but actually the way events are handled there is quite similar to SingleTOS. In XaAES, the whole event system is completely different, and there is no such thing as a fork queue (where events are recorded before being sent to applications) any longer. I took a brief look, and currently have no idea how to easily intercept recording of events.
Francois LE COAT
Thorsten Otto writes:
TOS (and EmuTOS) does it, MagiC, MyAES. This kind of GEM recording of events was always available on ATARI computers. That's why I use it.
Thorsten Otto
On Sonntag, 3. November 2024 17:15:17 CET Francois LE COAT wrote:
> TOS (and EmuTOS) does it, MagiC, MyAES. This kind of GEM recording of events
> was always available on ATARI computers. That's why I use it.
That is perfectly legal, and we could considered it a bug that XaAES does not implement it. But as already mentioned, it seems to be not so easy now, given the current way events are handled. But feel free to open an issue in the freemint repo.
Francois LE COAT
Thorsten Otto writes:
https://www.naprvyraz.sk/mint/200304/msg00059.html on freeMiNT list in 2003.
and it was submitted to freeMiNT bugtracker...
http://sparemint.org/bugtracker/login_page.php
I can't report an issue anymore, because I'm not having a GitHub account. Sorry...
Regards,
Miro Kropáček
That is perfectly legal, and we could considered it a bug that XaAES does not implement it. But as already mentioned, it seems to be not so easy now, given the current way events are handled. But feel free to open an issue in the freemint repo.
Roger Burrows
gemaplib.c. Basically it disconnects the VDI from the mouse (via standard VDI
calls) and draws the mouse itself. IIRC, the AES does not use any hidden
knowledge about the VDI to do this. However, I'm not sure that EmuTOS's
approach would work in a multi-tasking environment.
Roger
Francois LE COAT
Roger Burrows writes:
> Miro Kropácek wrote:
>>> That is perfectly legal, and we could considered it a bug that XaAES does
>>> not implement it. But as already mentioned, it seems to be not so easy
>> now,
>>> given the current way events are handled. But feel free to open an issue
>> in
>>> the freemint repo.
>>>
>> This gives even further reasoning why it is not so easy to replicate on a
>> system with separate AES and VDI components:
>> https://mikro.naprvyraz.sk/mint/200304/msg00023.html
> If you want to see how EmuTOS handles this, take a look at ap_tplay() in
> gemaplib.c. Basically it disconnects the VDI from the mouse (via standard VDI
> calls) and draws the mouse itself. IIRC, the AES does not use any hidden
> knowledge about the VDI to do this. However, I'm not sure that EmuTOS's
> approach would work in a multi-tasking environment.
implemented in EmuTOS.
I verified it with the `RECORD.ACC` accessory that works together with
Eureka 2.12. And because an
accessory is running in parallel under TOS or EmuTOS, the solution to
implement it should be close in
XaAES, tough freeMiNT+XaAES is a fully multi-tasking operating system.
Best regards,
Thorsten Otto
On Montag, 4. November 2024 00:40:09 CET 'Roger Burrows' via ARAnyM wrote:
> However, I'm not sure that EmuTOS's
> approach would work in a multi-tasking environment.
Well multi-tasking is one thing, but this is not the main problem (it works in MagiC for example, in almost the same way as in TOS/EmuTOS)
The main problem with XaAES is, that there is not a simple queue like the FPD structure where events are stored.
BTW, i think it is documented that recording can be aborted by pressing control-backslash. However both TOS and EmuTOS do this by comparing the keycode to 0x2b1c (0x2b for being the scancode, and 0x1c the ascii code). But this only works for us-keyboard layouts, on other layouts it is impossible to produce such a key, since backslash is located elsewhere and the key at 0x2b has a different ascii code.
Francois LE COAT
Thorsten Otto writes:
> BTW, i think it is documented that recording can be aborted by
> pressing control-backslash. However both TOS and EmuTOS do this by
> comparing the keycode to 0x2b1c (0x2b for being the scancode, and 0x1c
> the ascii code). But this only works for us-keyboard layouts, on other
> layouts it is impossible to produce such a key, since backslash is
> located elsewhere and the key at 0x2b has a different ascii code.
recording and playing of GEM events, is not used.
I didn't even know about pressing "control-backslash" to stop.
What I'm doing with the `RECORD.ACC` accessory, that works together with
Eureka 2.12, is waiting the "SPACE BAR" press.
If you press it, Eureka 2.12 stops buffering GEM events after the buffer
end, otherwise it continue with a larger buffer until its end.
Because Eureka 2.12 and `RECORD.ACC` are launched in parallel, the
"SPACE BAR" pressing can be detected, during recording or playing the
event buffer.
Remember that application (Eureka 2.12) and accessories ('RECORD.ACC')
are running in parallel, even with mono-task TOS and EmuTOS.
Best regards,
Roger Burrows
>
> BTW, i think it is documented that recording can be aborted by pressing
> control-backslash. However both TOS and EmuTOS do this by comparing the
> keycode to 0x2b1c (0x2b for being the scancode, and 0x1c the ascii code). But
> this only works for us-keyboard layouts, on other layouts it is impossible to
> produce such a key, since backslash is located elsewhere and the key at 0x2b
> has a different ascii code.
>
EmuTOS mailing list. At a quick glance it could be a bit messy, particularly
for multi-language ROMs, but not difficult. But I suspect the real-life
usefulness might be small.
Roger
Francois LE COAT
Roger Burrows writes:
... Well, I'm using appl_tplay() and appl_trecord() system calls in my
Eureka 2.12 GEM software. But with a different way to stop recording and
playing GEM events.
Best regards,