Altirra 3.90 released

[Mclaneinc]

If you set the input to an XBox360  controller they get mapped to the shoulder buttons.. Should work with any directinput Joystick..Works the same on my PS4 controller as it does on my 360 one..

 

I don't think(?) it's user editable though..  Just hardwired by Avery..

Edited September 12, 2021 by Mclaneinc

[.mad.]

Thanks buddy!

That showed me the way.

I knew it must be possible with the 100's of options available. ;)

 

Add mapping "Console" to your favourite controller.

It even has an option to map the space bar. :D

[Mclaneinc]

5 minutes ago, .mad. said:

Thanks buddy!

That showed me the way.

I knew it must be possible with the 100's of options available.

 

Add mapping "Console" to your favourite controller.

It even has an option to map the space bar.

No probs, one I didn't know about in the Input mapping... One of those little secret add on's that Avery does..

 

That would have been handy for the Gamepack I was part of...Thankfully the Xbox360 mapping was present back then...Did most things.. Turbo on the pad being dead handy

 

[phaeron]

10 hours ago, RetroCoder said:

I'm trying to use the ##TRACE command in the debugger but can't figure out how to get the accumulator printed

##TRACE "x=%d y=%d" x y

goes and dumps the x and y registers

What is the command to dump the accumulator value?

 

Is there a manual that describes this kind of information?

This is a quirk of the default expression evaluation settings, which allows you to specify lone hex addresses without a prefix ('mixed' radix). 'a' is therefore 10. You either need to use @a or (a) to force the full expression evaluator and select the accumulator.

[.mad.]

It's not an option i like to use, but running CAS files in fullscreen mode doesn't work from the command-line.

it always reverts back to window mode.

 

ATR, ROM, XEX, BAS files run without any problems in fullscreen.

so it probably has something to do with the Tape control dialog box.

 

just passing on the info. ;)

[phaeron]

7 hours ago, .mad. said:

It's not an option i like to use, but running CAS files in fullscreen mode doesn't work from the command-line.

it always reverts back to window mode.

 

ATR, ROM, XEX, BAS files run without any problems in fullscreen.

so it probably has something to do with the Tape control dialog box.

 

just passing on the info.

This happens because there is no exclusive full-screen implementation of the progress window, so when it appears it forces the display out of full screen mode, unfortunately. The only workaround for now is to use borderless mode.

[Faicuai]

Ok,

 

Been performing some over-due tests with Altirra 3.31 (I use it often, I really like it) on both emulator and actual 800 HW. Here's a couple of unexpected "booboos":

1. B-Graph (PIE module, showing any of the included pie-chart samples on disk #2, Waterloo or Population) fails to fill-draw properly, clearly running out of pie boundaries in what it seems all directions. Confirmed as well on 800 / Incognito. The problem appears to be directly related to the FP-pack, as AltOS 3.31 flashed on RAMROD (with original FP in-place) shows no problems. Altirra Basic Extensions (with its own FP code) displays them correctly.
2. Rolling-crash (real HW) or just a crash (emulator) when attempting to launch Bit3 FullView 80 from Basic RevC, with M=USR(54818). No problems with  original OS/b, though. I am currently running original Bit3 code on extra set of Intel QD2732A-200ns which we can poke at-will in the event we find an offending / illegal call in the original Bit3 code, so we can test it and publish a revised ROM for it.

As a side note, thanks once again for Altirra-OS... its under-the-hood performance improvements and optimizations are a real joy when revisiting older, OS-dependent titles that I grew up with.

 

 

[phaeron]

4 hours ago, Faicuai said:

Been performing some over-due tests with Altirra 3.31 (I use it often, I really like it) on both emulator and actual 800 HW. Here's a couple of unexpected "booboos":

1. B-Graph (PIE module, showing any of the included pie-chart samples on disk #2, Waterloo or Population) fails to fill-draw properly, clearly running out of pie boundaries in what it seems all directions. Confirmed as well on 800 / Incognito. The problem appears to be directly related to the FP-pack, as AltOS 3.31 flashed on RAMROD (with original FP in-place) shows no problems. Altirra Basic Extensions (with its own FP code) displays them correctly.
2. Rolling-crash (real HW) or just a crash (emulator) when attempting to launch Bit3 FullView 80 from Basic RevC, with M=USR(54818). No problems with  original OS/b, though. I am currently running original Bit3 code on extra set of Intel QD2732A-200ns which we can poke at-will in the event we find an offending / illegal call in the original Bit3 code, so we can test it and publish a revised ROM for it.

The first one is caused by FDIV overwriting FLPTR -- it looks like the BASIC compiler that was used expects this to be preserved. I think I can address this, but it will probably wait until post 4.00 release.

 

The second one is indeed caused by the Bit 3 firmware directly calling hardcoded addresses within OS-B. A couple of the calls are just hardcoded entries to the E:, S:, and K: GET BYTE handlers and can be re-routed through the defined resident handler tables. The trickier ones are the direct calls into internal routines which don't necessarily have equivalents within AltirraOS. One is to just after the S: open handler and one is to the key click routine within K:. The key click routine might be revectorable to the bell routine, but the call within S: open skips an AND into ICAX1Z that may be significant. There is no equivalent address for that since the AltirraOS S: open routine is completely different. There's enough space in the Bit3 ROM banks though that it may be possible just to fix it the right way to call through the S: open handler entry point and replicate the bell routine.

[Faicuai]

16 hours ago, phaeron said:

The second one is indeed caused by the Bit 3 firmware directly calling hardcoded addresses within OS-B

 

Thanks for those accurate forensics!! ?

 

Just what I thought it would be happening... although I did not imagine it would be so convoluted as jumping directly to specific instructions within OS handlers' code (not even entry points).

 

You would think that they ran out of ROM space, but it seems you've found some left in-there, which is GOOD, because it seems worthwhile attempting to straighten that spaghetti under a proper call-model for compatibility with Alt-OS (which BTW paves the way for you to freely shuffle around the OS code itself throughout its 1future iterations).

 

Having said that, the "parachute" call landing somewhere in S: code seems concerning. In any case, and for whatever it's worth, I have here an extra Bit3 solely for testing purposes and several EPROMs to burn, at will. Maybe in that extra rom space, we can add few LDA/CMPs for console-keys test (SELECT, etc,), right before calling S: so DMA can be toggled right from the start of the session, as well. That and other smaller things  I could do (well) on my own once I get a better hold of the disassembled ROM (which I currently don't have, unfortunately).

 

Q: any chance of a simultaneous double-screen view of ANTIC and Bit3/XEP/1090 outputs in Altirra? Or is this too complicated to implement, today? Based on real-life usage, that would be a killer feature, like no other out-there!

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.00-test42.zip
https://www.virtualdub.org/beta/Altirra-4.00-test42-src.7z

• Fixes held keys not being re-registered in raw key mode when keyboard debounce mode is re-enabled while keyboard scan is already enabled. This fixes the Rapidus menu being harder to enter with the Inverse key in raw key mode than it should have been (full scan mode was fine).
• Fixed a regression in the initial state of SKCTL bit 4 due to some cassette changes.
• Improved the output of the .pokey debugger command.
• Added verifier modes for detecting stack wrapping and the native 816 stack being placed into page zero.

9 hours ago, Faicuai said:

Q: any chance of a simultaneous double-screen view of ANTIC and Bit3/XEP/1090 outputs in Altirra? Or is this too complicated to implement, today? Based on real-life usage, that would be a killer feature, like no other out-there!

Not for 4.00. The emulation itself can handle it, but the front end isn't up to displaying simultaneous outputs yet.

[xxl]

is there any way for this program to write to the (cassete tape control menu) as wave?

magnet.obx

[.mad.]

8 hours ago, phaeron said:

https://www.virtualdub.org/beta/Altirra-4.00-test42.zip
Fixes held keys not being re-registered in raw key mode when keyboard debounce mode is re-enabled while keyboard scan is already enabled. This fixes the Rapidus menu being harder to enter with the Inverse key in raw key mode than it should have been (full scan mode was fine).

 

That update just fixed Action Biker (Disk and XEX) from being unable to start [SPACE BAR].?

Tape version always worked though...

 

just seen these typos in debug .help file.

.savestate   Save simulation satte

.loadstate   Load simulation satte

[phaeron]

5 hours ago, xxl said:

is there any way for this program to write to the (cassete tape control menu) as wave?

magnet.obx 34.2 kB · 3 downloads

No, not currently. Writing raw bits to tape via SKCTL bit 7 isn't implemented yet and there is also no support yet for recording whether regions in the tape image are turbo or not, which would be needed to resynthesize the waveform. Right now, the decoder dual-decodes all tape regions to both FSK and raw/turbo, so it doesn't keep track of which regions are primarily FSK-encoded or not.

 

[oo7]

@phaeron What are the chances of a libretro core release one day?

 

I mean it can never replace the stand alone Altirra, but It would be nice for anyone using RetroArch with all their favorite games in there. 

 

[Mclaneinc]

I don't know what the conditions on using the source code are, but it's happily been supplied. Avery publicly has always maintained that the Windows environment was his only battleground, so I can't imagine that will change. Also with Retroarch being multiplatform, I don't know what is expected of the dev re releasing cores for all the systems. To be fair, I don't know how the core system works on Retroarch even though I do use it myself on Windows.

 

I think there's a A800 core for it, it's still a great emulator, if it's just playing the games that's wanted then A800 is pretty wonderful for it..

 

The only emulator I don't use for the Atari is MAME, to be honest I stopped updating it around 2 years ago as it's just bloatware, incorporating parts of pinball machines etc etc and when it comes to the computers it uses that horrible system software method, so you can't easily use disks or roms from other stand-alone emulators..

Edited September 23, 2021 by Mclaneinc

[oo7]

9 minutes ago, Mclaneinc said:

I don't know what the conditions on using the source code are, but it's happily been supplied. Avery publicly has always maintained that the Windows environment was his only battleground, so I can't imagine that will change. Also with Retroarch being multiplatform, I don't know what is expected of the dev re releasing cores for all the systems. To be fair, I don't know how the core system works on Retroarch even though I do use it myself on Windows.

 

I think there's a A800 core for it, it's still a great emulator, if it's just playing the games that's wanted then A800 is pretty wonderful for it..

 

The only emulator I don't use for the Atari is MAME, to be honest I stopped updating it around 2 years ago as it's just bloatware, incorporating parts of pinball machines etc etc and when it comes to the computers it uses that horrible system software method, so you can't easily use disks or roms from other stand-alone emulators..

there is a800 core yes.

 

libretro has different core compiles per os.

 

 

I was thinking target x86 and x64 windows core.

 

Anyway just saying it would be nice.

 

 

[Mclaneinc]

Oh, not trying to put you off asking, Avery is the boss, whatever way the emulator goes is all his doing.... He did a prototype arm core in the past so who knows (well he does )

 

As for just the two cores, that's why I said about what retroarch expects from the dev, must you do cores for all the systems it supports??

 

I like Retroarch to a degree as the all-in-one but I more often use the stand-alone stuff as it's normally more featured / better. Would I like a core for Altirra, yeah, why not but as Avery works in the industry which is ALWAYS demanding, the fact he gives us Altirra in what free time he has is simply amazing... Very generous of him and all for free, he won't take donations of money for a few reasons, but if he needs a certain bit of hardware he would accept that towards forwarding the emulator.

 

As you say, it would be nice but in the meantime keep enjoying the goodness that is Altirra..

 

Take care,

 

Paul..

[oo7]

8 minutes ago, Mclaneinc said:

Oh, not trying to put you off asking, Avery is the boss, whatever way the emulator goes is all his doing.... He did a prototype arm core in the past so who knows (well he does )

 

As for just the two cores, that's why I said about what retroarch expects from the dev, must you do cores for all the systems it supports??

 

I like Retroarch to a degree as the all-in-one but I more often use the stand-alone stuff as it's normally more featured / better. Would I like a core for Altirra, yeah, why not but as Avery works in the industry which is ALWAYS demanding, the fact he gives us Altirra in what free time he has is simply amazing... Very generous of him and all for free, he won't take donations of money for a few reasons, but if he needs a certain bit of hardware he would accept that towards forwarding the emulator.

 

As you say, it would be nice but in the meantime keep enjoying the goodness that is Altirra..

 

Take care,

 

Paul..

I get what you mean.

 

 

I myself to be honest would still use the full blown Altirra. I was just thinking if it was simple it would be cool to have in the RetroArch pile lol (love the shaders on retroarch thats what got me thinking at first, then simplicity for games only for ppl like my sis)

 

 

[Mclaneinc]

I totally get and agree with what you say, a LOT of people also like the shaders, very fun and there's some support for them on Altirra but not many. Avery seems to focus on the getting it working like the real machine rather than the fancy eye candy. I asked many years ago for a sprite and font ripper, more for others to be able to do it easily as I can do it directly, but it never made Avery's famous to do list and I appreciate why.

 

I know people love to use the real machines, but there's so much emulation can give, and Altirra does it in spades..

[phaeron]

7 hours ago, oo7 said:

@phaeron What are the chances of a libretro core release one day?

 

I mean it can never replace the stand alone Altirra, but It would be nice for anyone using RetroArch with all their favorite games in there.

To answer directly -- sorry, unlikely to happen. RetroArch overlaps heavily with a lot of front end UI code that Altirra already has and works in tandem with the emulation core, and I don't have the time or inclination to maintain two separate builds with different front ends.

 

[oo7]

2 hours ago, phaeron said:

To answer directly -- sorry, unlikely to happen. RetroArch overlaps heavily with a lot of front end UI code that Altirra already has and works in tandem with the emulation core, and I don't have the time or inclination to maintain two separate builds with different front ends.

 

No need to say sorry. I am forever great full to have Altirra as is already. Thanks for taking the time to reply.

 

I only asked in case it was a simple task for you. 

[Mclaneinc]

The old rule in life, if you don't ask, you don't get...Always worth an ask...

[oo7]

So, the few shaders we have here.

 

were they made for altirra or are just compatible? What is their origin?

[Mclaneinc]

As far as I remember, nothing was made especially for Altirra, it's just a case that what shader support is built in to Altirra, it supports them. Avery did a explanation in to what Altirra supports coding wise a while back but I'm afraid I'm not a massive fan of shaders (some yes, not all) so I can't remember the details.

 

Where they came from, probable off shoots of numerous emulators out there..

 

Knowing that Avery strives to have Altirra work like the real hardware with things like shaders just being requested items I guess they were added for people to code their own and not as an author based support item.

 

You would have to ask him if that is the case, I have no clue

[oo7]

4 hours ago, Mclaneinc said:

As far as I remember, nothing was made especially for Altirra, it's just a case that what shader support is built in to Altirra, it supports them. Avery did a explanation in to what Altirra supports coding wise a while back but I'm afraid I'm not a massive fan of shaders (some yes, not all) so I can't remember the details.

 

Where they came from, probable off shoots of numerous emulators out there..

 

Knowing that Avery strives to have Altirra work like the real hardware with things like shaders just being requested items I guess they were added for people to code their own and not as an author based support item.

 

You would have to ask him if that is the case, I have no clue

Just dawned on my to check the help file. The shaders are based on RetroArch CGP.

 

However when I throw any of the common library cgp shaders at Altirra they all fail.

 

Guess I have some learning to do or something lol.