Moderator: Moderator Team
Wow, you are completely correct. I will have to investigate, I see all keypad keys are mapped so no clue what's going on there. Thanks for reporting it!AnachronyX wrote: Sat Apr 06, 2024 7:53 pmThe only thing, what's wrong are numpad keys (rotation left and right doesn't work right).
According to this page on project wiki https://wiki.scummvm.org/index.php?titl ... e_Beholder the DOS version uses shortened file extension to *.FNT. Maybe the sources could be compiled slightly modified to obtain the same result. But I have no idea how difficult it could be.mikro wrote: Mon Apr 08, 2024 8:28 am Seeing that those are long names, could it be that you run it from TOS FAT which can't handle more than 8+3 filenames? (Hatari does a nice job of translating its GEMDOS drive filenames into TOS 8+3 but in case of ScummVM it doesn't work so nicely so you have to use FreeMiNT/MagiC for such cases)
Here's my list of games that work OK in (emulated) 32Mhz Falcon:AnachronyX wrote: Mon Apr 08, 2024 8:23 pm I tried DOS version of The Legend of Kyrandia with FluidSynth in Hatari enabled and it work nearly flawlessly, better than any other game I tried
It's awesome that the Atari port is part of the official upstream. Not sure why AmigaOS3 isn't on there, as Novacoder's port is quite excellent. Nice! I need to try yours out. I need to get a newer set up working for my CT60e+SV setup going. Too much of the shenanigans that were tweaked for easymint... but definitely intend on trying out the new release very soon!mikro wrote: Sat Apr 20, 2024 9:02 pm NovaCoder's port is now way slower than ours if I may say so -- it uses forced fullscreen double-buffering in comparison to Atari's rectangle-based triple-buffering. And as a bonus, it converts 16-bit GUI into 8-bit + C2P on the fly. This takes its toll.
Anyway, the main reason is that he chose to stick with older ScummVM (2.3.0 at this moment) for speed reasons (nah...) so that's why. There was some other Amiga guy who left the scene/porting for some drama reasons and he also chose to use some ancient version... I'd love to have one shared m68k backend, that would be pretty awesome (I wouldn't be alone for all that work!)
Here's how: https://github.com/mfro0/fb_videomikro wrote: Sat Dec 30, 2023 4:40 pm ... P.P.P.S. FireBee users are still stuck with the SDL version, mostly due to its non-working video XBIOS. If somebody shows me a working fullscreen 320x240 / 640x480 screen with 8-bit chunky pixels+palette, I'm in...
Oh, that's really nice stuff, thanks!
1. So assuming I keep the FB register writes, can I take values from TOS4 (HHT, VFT etc) and omit the calculations?The example uses an extract of umc (a video mode calculator) and is more of a general showcase on how to set any video mode the FireBee is capable of.
3. I find this very surprising, 320x240 is nothing but double pixels/lines, there's no reason why any of the modeline parameters should drastically change, especially those affecting frequency, polarity etc. Maybe you can try to calculate 640x480 modeline and set Videl registers for 320x240?The code does fine with 640x480 (8 bit chunky as requested), 320x240 does work as well, but my monitor hardly syncs on it.
Ultima engine is disabled in Miro's versions, for good reasons: https://www.atari-forum.com/viewtopic.p ... 52#p455352leech wrote: Sat Apr 20, 2024 7:54 pm What's amusing to me, is this will actually allow Ultima VI to be played with VGA graphics on an Atari.
I don't think so. The FireBee has 5 possible video (pixel) clock sources: 4 fixed clocks (13, 17, 25 and 33 MHz) and one freely programmable clock (being the most universal clock source, obviously). The code is using the latter with the included modeline calculator.mikro wrote: Tue Apr 23, 2024 7:13 pm ...
1. So assuming I keep the FB register writes, can I take values from TOS4 (HHT, VFT etc) and omit the calculations?
I assume because it's not Falcon compatible? My fVDI driver, for now, is 16 bit only, so for that there isn't a problem.
2. Why isn't this part of EmuTOS? ScummVM currently just calls VsetMode(BPS8 / BPS8C) (Videl / SuperVidel = chunky 8-bit) and that's how I envision my work for the FireBee as well.
I didn't yet find (again, I still need to check the HDL more thoroughfully) a way to activate double lines for the FireBee mode.3. I find this very surprising, 320x240 is nothing but double pixels/lines, there's no reason why any of the modeline parameters should drastically change, especially those affecting frequency, polarity etc. Maybe you can try to calculate 640x480 modeline and set Videl registers for 320x240?The code does fine with 640x480 (8 bit chunky as requested), 320x240 does work as well, but my monitor hardly syncs on it.
Boo! No value? Literally would be the only way to play Ultima VI on an Atari with VGA graphics. The native version was an EGA only port. Though yes, Ultima 1 is not available on the ST. Though, neither is the VGA upgrade of Ultima IV. VIII definitely doesn't run yet on any Atari computer, though could through ScummVM.Eero Tamminen wrote: Tue Apr 23, 2024 7:49 pmUltima engine is disabled in Miro's versions, for good reasons: https://www.atari-forum.com/viewtopic.p ... 52#p455352leech wrote: Sat Apr 20, 2024 7:54 pm What's amusing to me, is this will actually allow Ultima VI to be played with VGA graphics on an Atari.
(Ultima-1 support could be included after this is fixed: https://bugs.scummvm.org/ticket/14790)
I.e. you would need to use Keith's complete SDL version, which in upstream downloads page is a Coldfire build: https://www.scummvm.org/downloads/
The Ultima ports are not very well suited for retro hardware. Despite their original requirement of 320x200@256c, their implementations require 16-bit highcolor, huge asset data files and most likely are not very well optimised.leech wrote: Tue Apr 23, 2024 10:25 pmBoo! No value? Literally would be the only way to play Ultima VI on an Atari with VGA graphics. The native version was an EGA only port. Though yes, Ultima 1 is not available on the ST. Though, neither is the VGA upgrade of Ultima IV. VIII definitely doesn't run yet on any Atari computer, though could through ScummVM.
All true for a stock Falcon, or maybe even one with a faster 030. But an 060 build with a SuperVidel or the Vampire/Apollo Core with EmuTOS would open up the requirements quite a bit.mikro wrote: Wed Apr 24, 2024 7:19 amThe Ultima ports are not very well suited for retro hardware. Despite their original requirement of 320x200@256c, their implementations require 16-bit highcolor, huge asset data files and most likely are not very well optimised.leech wrote: Tue Apr 23, 2024 10:25 pmBoo! No value? Literally would be the only way to play Ultima VI on an Atari with VGA graphics. The native version was an EGA only port. Though yes, Ultima 1 is not available on the ST. Though, neither is the VGA upgrade of Ultima IV. VIII definitely doesn't run yet on any Atari computer, though could through ScummVM.
ScummVM as is on Atari already supports more engines than it should, opening the can of worms with 16-bit graphics would result in yet another flood of bug reports / performance request improvements etc... I think I have stated it somewhere in the dev thread, if it were me, ScummVM would be just SCUMM, Revolution and Gob engines, so everything else is just a bonus.
Awesome. Scummvm is definitely a great way to bring more games to a platform, and getting the Atari build to be official is amazing. I'll keep chipping away at getting my Falcon set up to where I want it to be, and start doing some testing.mikro wrote: Wed Apr 24, 2024 10:11 am Everything is pushed upstream, scripts to build are in backends/platform/atari. The change to support 16-bit games is not complex (both for UI and engines), you could even skip the UI part if supplied the name as a command line parameter.
As for the overhead, well, it depends on the person who is doing the reverse engineering. Some prefer nearly 1:1 port, some prefer reimplementation in a more modern way, adding bloat. Discworld and Lucasarts games run just great, when the DSP mixer will be done I'm sure they will run on stock Falcon (well, with some TT RAM...) fluently.
That would be fantastic. I'll still try and get around to testing the stuff it currently supports. After all, there should still be all the Leisure Suit Larry games that I need to 'experience'. (I still remember playing part 3(?) on the ST and it asking 'adult' questions to be able to play the game... I just happen to be a smart enough kid to be able to answer them!)mikro wrote: Wed Apr 24, 2024 4:57 pm Btw, I'm not completely against adding 16-bit support. Before I start considering it, one other thing should happen and that's adding support for dynamically loaded engines (it's already there, just needs an Atari implementation). That way it wouldn't matter whether we support 20 or 200 engines, as the base scummvm.ttp will be just 4-5 megs. In the present state, adding 16-bit games would be like 80 MB executable.