Jump to content
phaeron

Altirra 3.90 released

Recommended Posts

I'm looking forward to using this on RetoArch, as their resident 8-bit emulator doesn't work very well. 

Share this post


Link to post
Share on other sites
2 hours ago, S1500 said:

I'm looking forward to using this on RetoArch, as their resident 8-bit emulator doesn't work very well. 

 

Not sure where you hear that one.  Also RetroArch ports of computer emulators ( and in some cases console emulators ) tend to muck things up.  The joystick / keyboard interface leaves a lot to be desired and they don't always expose all of the emulator options in the interface.  Even when they do it's not the most organized.

 

Still regardless it would be kind of nice to see.  Atari800 for retroarch is barely functional.

 

Share this post


Link to post
Share on other sites

Phearon,

Any chance we will see Fujinet emulated in the future?

 

Share this post


Link to post
Share on other sites

You realise this is like asking 'can you write or incorporate an ESP32/8266 emulator/simulator to run in parallel and interact with Altirra'?
 

Share this post


Link to post
Share on other sites
1 hour ago, Shannon said:

 

Not sure where you hear that one.  Also RetroArch ports of computer emulators ( and in some cases console emulators ) tend to muck things up.  The joystick / keyboard interface leaves a lot to be desired and they don't always expose all of the emulator options in the interface.  Even when they do it's not the most organized.

 

Still regardless it would be kind of nice to see.  Atari800 for retroarch is barely functional.

 

Wouldn't making Altirra retroarch-compatible also reduce its functionality and versatility? What's good for the goose is good for the gander.

 

Share this post


Link to post
Share on other sites

Retroarch's Atari 8-bit emulation is good for everything 'standard'. It only shows its weaknesses for things like U1MB, VBXE, Rapidus emulation. I admit it could do with being updated to use the current mainline atari800 engine as it's lagging behind quite a long way now (2014). 

 

barely functional is an unfair description and just shows up your lack of ability to set it up correctly. 

Share this post


Link to post
Share on other sites
3 hours ago, Mr Robot said:

Retroarch's Atari 8-bit emulation is good for everything 'standard'. It only shows its weaknesses for things like U1MB, VBXE, Rapidus emulation. I admit it could do with being updated to use the current mainline atari800 engine as it's lagging behind quite a long way now (2014). 

 

barely functional is an unfair description and just shows up your lack of ability to set it up correctly. 

 

I am very familiar with the atari8000 emulator.  I maintain and compile the xbox version and I can tell you setting it up in retroarch and especially using keyboard based games is a PITA in retroarch.  My xbox version is certainly easier to set up on a game by game basis.  So I think you are very wrong in your assessments.  I am mostly referring to running retroarch on a console based system which mainly relies on controllers and use of keyboards is not that common.  A lot of the internal atari800 functionality is not even accessible from the standard retro-arch option menu.  I have gotten many titles to run just fine on it.   But not as many as I'm able to get running on the xbox version or a PC build of Atari800.  The retroarch version is far more difficult to set-up than it needs to be.  Try running a BIN image without a CART header on it and see just how far you get.  No "true" analog support for 5200 games.  I could make a whole list of things it makes far more difficult than they need to be.  This goes for pretty much every computer based emulator in retroarch.

 

Edited by Shannon

Share this post


Link to post
Share on other sites

for 3.90:

 

I was loading very fast (an atr image). However, one game (I think it was pinic) crashed and one of the things that the emulator suggested was to slow down the loading (or something like that).

 

How can I enable it back?

 

So it loads fast (but not warp speed, as that makes everything fast)

Share this post


Link to post
Share on other sites
26 minutes ago, Blues76 said:

for 3.90:

 

I was loading very fast (an atr image). However, one game (I think it was pinic) crashed and one of the things that the emulator suggested was to slow down the loading (or something like that).

 

How can I enable it back?

 

So it loads fast (but not warp speed, as that makes everything fast)

Configure System > Acceleration > SIO D Patch, or Configure System > Disk > Accurate sector timing.

  • Thanks 1

Share this post


Link to post
Share on other sites
12 hours ago, Shannon said:

 

I am very familiar with the atari8000 emulator.  I maintain and compile the xbox version and I can tell you setting it up in retroarch and especially using keyboard based games is a PITA in retroarch.  My xbox version is certainly easier to set up on a game by game basis.  So I think you are very wrong in your assessments.  I am mostly referring to running retroarch on a console based system which mainly relies on controllers and use of keyboards is not that common.  A lot of the internal atari800 functionality is not even accessible from the standard retro-arch option menu.  I have gotten many titles to run just fine on it.   But not as many as I'm able to get running on the xbox version or a PC build of Atari800.  The retroarch version is far more difficult to set-up than it needs to be.  Try running a BIN image without a CART header on it and see just how far you get.  No "true" analog support for 5200 games.  I could make a whole list of things it makes far more difficult than they need to be.  This goes for pretty much every computer based emulator in retroarch.

 

So what you're saying is you are getting unsatisfactory emulation for ALL emulated computers in retroarch when you emulate them on a system with no keyboard, especially for keyboard based games? Maybe plug a keyboard in! How would Altirra being in retroarch improve that in any way?

 

As I said I wish they would update the atari800 core to the latest version of atari800, it has custom key mapping for most of the common keys now and there are 5200 cart types supported that were recently added. I agree the 5200 emulation doesn't emulate the controllers well, that is a problem with atari800 and the retroarch implementation, and again, without a 10 digit keypad its not ever going to be good. If Altirra were converted to libretro the dev who did it would have to do a better job than they did of atari800 and from past experience, that is unlikely. the libretro devs seem to do the minimum to get a core working and then leave it, just the fact the atari800 core is six years old tells you that.

 

Running a BIN image on Altirra does a similar thing to atari800, it asks for the correct cart type before launch. Short answer, don't use non-CAR images, you only have to convert them once. I've posted almost complete collections of CAR images on AA in the past, have a look in the Ultimate Cart threads or the AVGCART threads, they are in there somewhere.

 

If you press Y in the atari800 core you get a virtual keyboard, pressing F1 on that will get you the full atari800 menus. Yes, again sloppy programming from team libretro do you really think they would implement all the options in Altirra if they ported it given what they did here?!

 

Your issues mostly seem to be with libretro not atari800

 

This is off topic, I'm happy to continue the discussion if you like but either make a new thread or take it to PM. 

 

Share this post


Link to post
Share on other sites

Nah that's ok.  I'll stop the discussion.  No need to continue.  I know about the dysfunctional virtual keyboard.  Anywho it functions well enough. I'm just saying that after using several computer based emulators ( Atari 800, Atari St, Amiga, C64) that retroarch could be far better.  That is all.

Share this post


Link to post
Share on other sites
13 minutes ago, Shannon said:

Nah that's ok.  I'll stop the discussion.  No need to continue.  I know about the dysfunctional virtual keyboard.  Anywho it functions well enough. I'm just saying that after using several computer based emulators ( Atari 800, Atari St, Amiga, C64) that retroarch could be far better.  That is all.

I am not a libretro fan, I think it was a nice idea, badly done, that has had the unfortunate side effects of stealing credit from the emulator authors and disincentivizing and stifling emulator development.

 

They should have developed the library and then encouraged the emulator authors to support it as a build target, instead they forked all these open source emulators, hacked them up to work with the library and left them.

 

  • Like 1

Share this post


Link to post
Share on other sites

While I use Retroarch for some stuff I'd hate to see Altirra 'hacked' to fit the running profile of Retroarch, Avery has spent a long time optimising it for the way he wants it to work, crobarring it on to a new engine would sure as hell break stuff. Add the fact that Avery has no wish to get involved in other peoples ports and sure as eggs are eggs he would be the most important person to have on board.

 

Sounds like a non starter to me..

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, Shannon said:

Nah that's ok.  I'll stop the discussion.  No need to continue.  I know about the dysfunctional virtual keyboard.  Anywho it functions well enough. I'm just saying that after using several computer based emulators ( Atari 800, Atari St, Amiga, C64) that retroarch could be far better.  That is all.

By "computer based emulators" do you mean individual dedicated emulators?

 

Share this post


Link to post
Share on other sites
4 hours ago, Mr Robot said:

I am not a libretro fan, I think it was a nice idea, badly done, that has had the unfortunate side effects of stealing credit from the emulator authors and disincentivizing and stifling emulator development.

 

They should have developed the library and then encouraged the emulator authors to support it as a build target, instead they forked all these open source emulators, hacked them up to work with the library and left them.

 

 

I feel the same way.  I think it was a great idea.  I'm not to thrilled with the implementation.  Believe it or not they don't hack up the emulators too bad.  They usually take the "main" emulation loop code and pull that into it's own file and hack that to work with retroarch.  But the way the "wedge" some things in is counter productive.  It's biggest advantage is multiple platform ability.

 

3 hours ago, Keatah said:

By "computer based emulators" do you mean individual dedicated emulators?

 

No I'm referring to computer based emulators imported/modified to work with retroarch/retrolib.

 

Share this post


Link to post
Share on other sites

A minor issue in the debugger in 65C816 mode:

 

obraz.png.40cd0681dfc3a9a6e4d9a2fcb9e7bced.png

 

I guess that the separator after JSR (abs,X) is superfluous.

 

EDIT: but there probably should be one after RTL:

 

obraz.png.0856610814de6d0f4ecebaffa8581b28.png

Edited by drac030

Share this post


Link to post
Share on other sites
8 hours ago, drac030 said:

A minor issue in the debugger in 65C816 mode:

 

obraz.png.40cd0681dfc3a9a6e4d9a2fcb9e7bced.png

 

I guess that the separator after JSR (abs,X) is superfluous.

 

EDIT: but there probably should be one after RTL:

 

obraz.png.0856610814de6d0f4ecebaffa8581b28.png

Ah yeah, that's not right. I'll remove the end-block flag from indexed JSR and add it to RTL in the disasm tables.

Share this post


Link to post
Share on other sites

http://www.virtualdub.org/beta/Altirra-4.00-test22.zip

http://www.virtualdub.org/beta/Altirra-4.00-test22-src.zip

  • SIDE 3 fixes: red/green LEDs split apart, flash chip changed to MX29LV640ET to match production run, SD writes now supported, banking and cartridge hardware registers updated, many cartridge emulation bugs fixed, push button and SDX switch behavior fixed, SD writes are now supported, RTC month fixed, HD sector indicator hooked up.
  • Added /reset:devices command-line switch to reset only the device tree.
  • Virt-FAT32 device now handles empty directories, zero byte files, and symlinks to files.
  • Fixed disassembler end-block flags for RTL and JSR (abs,X) opcodes.
  • Added .pagesums command to aid in comparing memory states.

 

  • Like 10
  • Thanks 5

Share this post


Link to post
Share on other sites

I made an attempt at configuring the Rapidus emulation under Altirra. First of all, the setup is rather painful, if anyone is interested, here is the file which one should attach as "Rapidus Flash firmware" in the Firmware manager:

 

rapidus_flash.zip

 

It contains the actual Rapidus Configuration menu v.1.2 and the Rapidus OS.

 

I have not played much with this, but I already noticed that the mcr register ($FF0080) does not work as expected:

 

1) clearing bit 3 enables Fast RAM at $C000-$FFFF regardless of PORTB.0 - it should only affect RAM in this area, not ROMs.

2) clearing bit 1 enables Fast RAM at $4000-$7FFF, again, regardless of PORTB bits controlling the Ext RAM - while it should only affect the base memory, and switching in the Ext RAM should also switch this area to "slow" read/write mode.

3) setting bit 2 makes external cartridges (like SDX) visible for CPU in $8000-$BFFF, but it should also make this memory slow (1.77 MHz), whereas it seems that it is still accelerated. This applies to the rest of the RAM bits: on the real Rapidus Fast read mode uses the Fast RAM as write-through cache for the motherboard's RAM (data is read from Fast RAM, but written to both Fast RAM and Atari RAM), and No-speedup mode both reads and writes the Atari RAM in slow mode.

 

Edited by drac030
  • Like 2

Share this post


Link to post
Share on other sites

http://www.virtualdub.org/beta/Altirra-4.00-test23.zip

http://www.virtualdub.org/beta/Altirra-4.00-test23-src.zip

  • Fix for an alignment bug in the stereo mixing code that manifested with VS2019 16.8 (these builds are using an older version).
  • Fix for an uninitialized memory crash in the virtual DOS 2 image mounting code.

 

19 hours ago, drac030 said:

I have not played much with this, but I already noticed that the mcr register ($FF0080) does not work as expected:

 

1) clearing bit 3 enables Fast RAM at $C000-$FFFF regardless of PORTB.0 - it should only affect RAM in this area, not ROMs.

2) clearing bit 1 enables Fast RAM at $4000-$7FFF, again, regardless of PORTB bits controlling the Ext RAM - while it should only affect the base memory, and switching in the Ext RAM should also switch this area to "slow" read/write mode.

3) setting bit 2 makes external cartridges (like SDX) visible for CPU in $8000-$BFFF, but it should also make this memory slow (1.77 MHz), whereas it seems that it is still accelerated. This applies to the rest of the RAM bits: on the real Rapidus Fast read mode uses the Fast RAM as write-through cache for the motherboard's RAM (data is read from Fast RAM, but written to both Fast RAM and Atari RAM), and No-speedup mode both reads and writes the Atari RAM in slow mode.

Thanks, there's not much detail on the registers so I have had to guess at some of it. I assume bit 3 is overridden by OS select regardless of whether RapidOS is enabled or not?

 

As for #3, do you have cartridge shadowing enabled in CPU options? It should be disabled for the desired behavior.

 

  • Like 4
  • Thanks 2

Share this post


Link to post
Share on other sites
10 minutes ago, phaeron said:

Thanks, there's not much detail on the registers so I have had to guess at some of it. I assume bit 3 is overridden by OS select regardless of whether RapidOS is enabled or not?

It is a bit more complicated, I will send you a PDF with the register listing via PM (alas the description is in Polish).

 

11 minutes ago, phaeron said:

As for #3, do you have cartridge shadowing enabled in CPU options? It should be disabled for the desired behavior.

Just checked, no, the cartridge shadowing is not enabled, also I did not mean the ROMs, but rather the RAM area at $8000-$BFFF which should be slow, when bit 2 = 1.

Share this post


Link to post
Share on other sites

Any plans to include a FujiNet? Or an N: - device? I got plans for A8-software but do not plan to buy any hardware anytime soon ...

Share this post


Link to post
Share on other sites
6 hours ago, atarixle said:

Any plans to include a FujiNet? Or an N: - device? I got plans for A8-software but do not plan to buy any hardware anytime soon ...

Sorry, no current plans. FujiNet is a bit big in scope to implement.

Share this post


Link to post
Share on other sites

Not a problem ... I guess I can code working around the lack of Hardware / N:

 

All I need is to have access to files using the full long filename of the host file system (H: device). I think this is the current behaviour of Altirra.

 

I want to open files named like H:http##atarixle.ddns.net#index.php - this allowes me to use the web directly from the Atari Software.

Edited by atarixle

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...