Jump to content
IGNORED

Altirra 3.20 released


phaeron

Recommended Posts

3 hours ago, phaeron said:

Already exists: Tools > Options > Display.

 

Altirra already has its own NTSC filter: System > Configure System > Outputs > Video > Artifacting Mode > NTSC/PAL high artifacting (auto-switch).

 

wow. ok thanks guess I overlooked. guess I'm too fresh with the current build of Altirra.

 

thank you

Link to comment
Share on other sites

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

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

  • Major work on compatibility database support. Custom checksums replaced with SHA256, added 50Hz/60Hz tags, tapes can now be matched, fixed a bug where some tags didn't apply properly if a profile switch was involved, fixed broken delete title and quick search in the compat editor, warn on invalid aliases, UI auto-loads the external database on open if source is present, and editor window is resizable.
  • Keyboard fixes: binding to non-ASCII cooked keys, such as those in Latin-1, now works; fixed an issue where changes to a custom keyboard layout didn't necessarily take effect immediately. The keyboard customization UI also warns you if you are assigning a key that conflicts with a keyboard shortcut.
  • Verifier can now flag code accessing non-canonical hardware addresses.
  • Fixed some bugs in the Amdek AMDC configuration UI.
  • Like 6
  • Thanks 2
Link to comment
Share on other sites

2 minutes ago, phaeron said:

Major work on compatibility database support. Custom checksums replaced with SHA256, added 50Hz/60Hz tags, tapes can now be matched, fixed a bug where some tags didn't apply properly if a profile switch was involved, fixed broken delete title and quick search in the compat editor, warn on invalid aliases, UI auto-loads the external database on open if source is present, and editor window is resizable

Ah many thanks Phaeron, I will be using these for the forces of good!

 

For everyone else - I am building a database of all the settings required for out of the box click it to run it compatibility, starting with a union of the collections a8preservation, TOSEC, and homesoft. It will take a while to finish, when I've got it I'll get it circulated so we can add all the variant aliases/checksums that are out there, of which I'm sure there are a ton! I found some of these bugs while poking around the compatibility feature and then a couple of days later, poof they are gone like magic! ?

Link to comment
Share on other sites

8 hours ago, gnusto said:

Ah many thanks Phaeron, I will be using these for the forces of good!

 

For everyone else - I am building a database of all the settings required for out of the box click it to run it compatibility, starting with a union of the collections a8preservation, TOSEC, and homesoft. It will take a while to finish, when I've got it I'll get it circulated so we can add all the variant aliases/checksums that are out there, of which I'm sure there are a ton! I found some of these bugs while poking around the compatibility feature and then a couple of days later, poof they are gone like magic! ?

 

I understand what you want to do but don't waste your time with the TOSEC collection. A project like yours would be the perfect chance to weed out all the unnecessary fake .atr files and antiquated bad stuff that got superseded with better versions. 

 

One of the reasons Atarimania doesn't offer a big zipped collection is that it's just too hard to control the quality of the releases if you don't have strict rules from the very start. 

Link to comment
Share on other sites

8 hours ago, gnusto said:

For everyone else - I am building a database of all the settings required for out of the box click it to run it compatibility, starting with a union of the collections a8preservation, TOSEC, and homesoft.

I strongly agree with @www.atarimania.com's comments.

Regarding a8preservation: Get in contact with @Farb because the database already contains hashes for all our dumps.

Link to comment
Share on other sites

1 hour ago, www.atarimania.com said:

 

One of the reasons Atarimania doesn't offer a big zipped collection is that it's just too hard to control the quality of the releases if you don't have strict rules from the very start. 

 

You know I've chatted with you re this over the years and I totally understand where you are coming from but its also the exact reason why you should offer a pack. You have weeded out so much of the bad stuff so it means you are offering a very clean set which is exactly what folks like me want but don't have the time to do. Once a set leaves you its only affects the downloader and their choice to keep it maintained or not. Technically it has no affect on your stuff unless any dumps sent to you are duff which with Farb and the boys on point is unlikely.

 

You know I love Atarimania and the dedication but getting a quantity of files is a really slow hard process, one day maybe give the mass download a thought..

 

As always, its a friendly request and nothing more..

 

Long live Atarimania...

Link to comment
Share on other sites

2 hours ago, Farb said:

It also has the information for every dump we track with the settings necessary to run it properly in Altirra.

That would be a great DB to have, if you don't mind. I can use it to build out the Altirra native one (which is what I'm already doing).

 

As for ignoring TOSEC, it's a good point. I rarely use them myself, in fact almost never. My general preference progression is a8preservation->CSS Cracks->Homesoft->"my own stuff"->Atarimania for the rare ones. In a perfect world to me we get everything available into a8preservation and on top of that we have the homebrews, but it will take a while.

 

However a lot of people have TOSEC that don't have other stuff. It doesn't seem harmful to start tagging some of their hashes, for those games that need it. One good thing about TOSEC is they have excellent naming meta data. Year/version/developer/specific OS or BASIC dependencies + loading guidance, for instance CLOAD+RUN versus RUN"C:. The TOSEC authors understood that the strongest chance for metadata to survive is put it in the name, and i'd agree with that.

 

One thing I am NOT trying to do here is create a new collection. Quite the opposite. I want it to be painless for people to drop in for instance a later version of the a8preservation collection and not have it be disruptive. The Altirra approach of tagging by hash is excellent for this, but I will probably also bundle everything up under a front end eventually, and for that you want to *not* change names, much as I would personally like to - the Homesoft collection for instance is so great for convenience, but has a lot of misses on naming accuracy, and no metadata. Still Altirra tags to the rescue for that!

 

Overall though I would say I have three goals:

- Be as accurate to the original A8 experience as possible. So obviously heavily favoring a8preservation with the tags, but sadly not everything is available there.

- Be as complete as possible to the games category, so when somebody new to a8 emulation (or hardware) wants to relive that one game from childhood, it's there.

- To make it as painless and easy as possible given the two goals above. One click and you're in. With the Altirra DB fully populated, this seems like an achievable reality.

 

Once I get it off the ground I would look forward to people contributing tags for every variant under the sun of a given title, and no need to filter collections or version we don't particular like. It doesn't take away from using the accurate versions, to also have the inaccurate ones at least tagged to be able to run.

Link to comment
Share on other sites

I just did a cursory query and for the stuff I've marked up so far (I'm into the "E"s which is over 1000 count) there are only a handful of TOSEC. Mostly for BASIC magazine programs that are in ATR form for TOSEC. Since Altirra loads .bas files directly (thanks Phaeron!) I can switch all those out for Atarimania copies anyway and be higher quality in less space, although for the emulated side space isn't much of a consideration.

 

I might rename those, if nobody objects, particularly Atarimania =). So for instance "1040_Terminator.zip" would become "1040 Terminator (1988)(April 1988 - Vol. 6 No. 12 )(US)[BASIC].zip". I am a fiend for preserving meta data.

Link to comment
Share on other sites

  • 3 weeks later...

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

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

  • Fixes regression where images mounted from within a zip file weren't being remounted after an emulator restart.
  • Debugger 'ib' command wasn't actually issuing intended reads with side effects in non-coprocessor targets.
  • Debugger now recognizes the 6809 RTI instruction as a subroutine ender in the .dumpdsm command.
  • Percom RFD ROM revisions are now recognized by the firmware scan (with thanks to Nezgar for the endless disk drive research).
  • Support for switching to dark theme in the help file.

Now for what I've actually been working on for a while: initial support for custom devices. It is now possible to implement some types of devices, including cartridges and SIO devices, with just a text editor without having to modify the emulator. There's a built-in small scripting language for behavior like bank-switching, and the ability to connect to an external server to do more complex logic or external interactions.

 

For instance, this .atdevice file emulates enough of an 810 to boot a single density disk on D1:

{
    "//": [
        "Basic 810-compatible disk drive emulation. Place additions.atr or",
        "another single-density disk image next to this file."
    ],

    "name": "Sample disk drive device",

    "segments": {
        "disk": {
            "source": "additions.atr",
            "source_offset": 16,
            "size": 92160
        },

        "status": {
            "size": 4,
            "init_pattern": [ 0, 0, 224, 0 ]
        }
    },

    "sio_devices": [
        {
            "device_id": "$31",
            "commands": [
                {
                    "id": "$50",
                    "script": [
                        "if ($aux <= 0 || $aux > 720)",
                        "    $sio.nak();",
                        "else {",
                        "    $sio.ack();",
                        "    $sio.recv_frame(128);",
                        "    disk.copy(($aux - 1)*128, $sio_frame, 0, 128);",
                        "    $sio.complete();",
                        "}"
                    ]
                },
                {
                    "id": "$52",
                    "script": [
                        "if ($aux <= 0 || $aux > 720)",
                        "    $sio.nak();",
                        "else {",
                        "    $sio.ack();",
                        "    $sio.complete();",
                        "    $sio.send_frame(disk, ($aux - 1)*128, 128);",
                        "}"
                    ]
                },
                { "id": "$53", "auto_transfer": { "mode": "read", "segment": "status", "offset": 0, "length": 4 } },
                { "id": "$57", "copy_from": "$50" }
            ]
        }
    ]
}

 

The full specification is in the help file. There are also samples included for an R-Time 8, a RespeQt-compatible SIO clock, a 64K SpartaDOS X cartridge, a SuperCharger 3D cartridge, and an 820 printer which prints the output to a Python-based server. Fair warning, my Python is pretty bad, and the deviceserver could use some more refactoring (its API predates the scripting engine).

 

This is intended to help with prototyping or one-off devices where it doesn't make sense to integrate into the emulator yet. For instance, a while ago someone wanted help with implementing an SIO protocol for a device being made so that a flasher could be tested. I couldn't help out with this because it would have had to be written in C++ and it wasn't something I could ship. With this, the protocol could be implemented in a quick .atdevice file for a one-off. Similarly, if we end up with a mystery cartridge, this'll make it possible to quickly try a bunch of banking methods that may not be implemented yet.

 

 

  • Like 14
  • Thanks 1
Link to comment
Share on other sites

Whilst I do not have the skills to take advantage of this new scripting side I can see the amazing importance and opportunity for the dev's on here, this is probably one of the most important advances in Altirra ever..

 

A sandbox proto environment allowing proof of concept....Well done that man...

Edited by Mclaneinc
Link to comment
Share on other sites

12 hours ago, phaeron said:

The full specification is in the help file. There are also samples included for an R-Time 8, a RespeQt-compatible SIO clock, a 64K SpartaDOS X cartridge, a SuperCharger 3D cartridge, and an 820 printer which prints the output to a Python-based server.

Great idea!

I was looking for a way to emulate a resistor-based dongle and gave it a try, but fail miserrably.

 

Unfortunately I cannot find the additional examples in the help file, only an 8k cart and an 810 drive.

 

This is what I try:

Mclaneinc pointed me in the right direction.

 

 

This is the error message I receive:

Error on line 9: Control item was not an object.

 

 

Edited by DjayBee
Link to comment
Share on other sites

57 minutes ago, DrVenkman said:

The joystick dongle emulator (I hereby dub “the dongulator” ;) ) will be great for using with stuff like an uncracked copy of PAPERCLIP. 

Not sure if you mean the one in devices or the one Djbee wants to make, the one in devices has been there a long time....Does that make the Long Donsulator?

Link to comment
Share on other sites

3 hours ago, Mclaneinc said:

Ps: There's a joy port dongle device in devices but not sure of its criteria.

Yes, but it is only capable of returning weird joystick positions (like up and down at the same time).

 

1 hour ago, DrVenkman said:

The joystick dongle emulator (I hereby dub “the dongulator” ;) ) will be great for using with stuff like an uncracked copy of PAPERCLIP. 

It depends on what Paperclip needs. The only program which uses a different sort of dongle I analyzed so far is Keywriter-1 from Amazon Systems. It verifies that PADDLE(0) is between 40 and 80.

 

The below code works for OS-B, but fails for XL-OS because of the memory test during reset. I have not found out how to check a certain memory location to detect "after boot" from inside the device script.

 

{
  "name": "Keywriter-1 Dongle",

  "memory_layers": {
    "POT0": {
      "name": "POKEY Paddle 0",
      "address": "$200",
      "size": "$100",
      "control":[
        { "address": "$270", "size": 1, "mode": "r", "data": 60
        }
      ]
    }
  }
}

 

Keywriter-1 (1982)(Amazon Systems)(GB)[BASIC][req dongle].atr

  • Thanks 1
Link to comment
Share on other sites

The custom device isn't really made for interception like this, but it can be made to work. What you need is a trigger to enable the RAM overlay only after the OS has completed initialization. The easiest way to do this is with a peekaboo cartridge whose init code banks out the cart and enables the overlay (attached).

 

Better would be to use an actual controller, but I don't have that interface piped out to custom devices yet.

 

keywriter1.zip

  • Like 3
Link to comment
Share on other sites

20 hours ago, phaeron said:

The easiest way to do this is with a peekaboo cartridge whose init code banks out the cart and enables the overlay (attached).

Thanks for your help. :)

Since Keywriter needs BASIC, it did not work as designed and I ended up with different implementations for XL/XE and 400/800.

  • For XLs and XEs I added to your cart-code "enable-BASIC using PORTB and JMP ($BFFE)".
    Therefore booting has to be done without BASIC.
  • For 400/800 I could only get my version to work.

keywriter1.zip

Link to comment
Share on other sites

I found a method which works on all OSs.

The RAM test writes only $00 and $FF and the paddles use only $00-$E4.

The below code allows $00 and $FF to be written to PADDL0 which passes the RAM test on XL/XE. All other values are replaced with 60 which passes the protection.

 

@DrVenkman If someone documents the behaviour of the Paperclip dongle, we might be able to construct something similar. But then it seems that custom devices cannot overlay PIA's address range at $D30x.

{
  "name": "Keyword-1 Dongle",

  "variables": {
    "val": "int"
  },

  "memory_layers": {
    "PADDL0": {
      "name": "POKEY Paddle 0",
      "address": "$200",
      "size": "$100",
      "control":[
        { "address": "$270", "size": 1, "mode": "r", "variable": "val" },
        { "address": "$270", "size": 1, "mode": "w", "script": [
          "if (($value == 0) || ($value == $FF))",
            "val = $value;",
          "else",
            "val = 60;"
          ]
        }
      ]
    }
  }
}

 

End of thread-hijacking - back to useful stuff

;)

  • Like 2
Link to comment
Share on other sites

I wouldn't say that exercising a feature I just added is off-topic. This should help:

 

http://www.virtualdub.org/beta/Altirra-3.90-test24.zip

http://www.virtualdub.org/beta/Altirra-3.90-test24-src.zip

  • Rewrote JSON parsing code for tighter validation -- unexpected object members are now an error to catch typos.
  • Cart_mode for memory layers can now be "auto" based on address range.
  • Offset is now optional for SIO auto_transfers.
  • Added "vblank" script event.
  • Added controller port support.

Check circlepaddles.atdevice for a controller port example -- you can now drive the controller inputs rather than trying to fudge the memory accesses. Again, not really an intended use, but if you were crazy enough you could try to write a TASBot with this.

 

It's correct that you can't overlay hardware registers -- the memory layer priority is hardcoded at cartridge right now. I'll probably add support for relative priority between layers, but I haven't decided whether to allow the full freedom for changing layer priorities yet. Some of the priority stacks in the emulator can get pretty complex when you have a bunch of devices installed (130XE + Rapidus + U1MB + BlackBox + SDX + R-Time 8).

 

  • Like 7
  • Thanks 2
Link to comment
Share on other sites

On 11/30/2019 at 11:38 AM, Mclaneinc said:

Retroarch and Mednafen are simply not fun to use unless you put a lot of effort in to it, out of the box they are a nightmare..Its simply the case, I don't want to have to spend a lot of time trying to learn how to get the thing going. Its an emulator, not 3DS Max...

I found Retroarch super easy to set up.    Mednafen on the other hand, is a configuration nightmare with all the options.   And then the interface makes it super easy to "accidentally" remap your controls so you can't use the thing properly

 

On 12/1/2019 at 8:24 AM, Mclaneinc said:

The thing that worries me in these cores that are used all have to fit in to a universal front end that runs the said cores, with so many techniques of emulation I do wonder if some features have to be trimmed or limited to suit the engine.

You don't have to use the Retroarch front-end at all.   I integrated all the retroarch emulators I cared about into my favorite front end, and it works just like any other emulator.   The only thing I use the retroarch front-end for is downloading emulators and updates.

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...