Jump to content
IGNORED

Altirra 1.7 released


phaeron

Recommended Posts

Can anyone confirm that these are final images or that they work on real hardware?

 

Well, I've taken YAKF image from AtariOnline news, so it must be the the latest one.

As for Bomb Jake I've found it in the "Bomb Jake" package on sources.atari.pl, so I'm pretty sure it's also correct one.

But to make sure, maybe it would be also good to contact Vega to confirm it.

 

Could someone contact him please, until it's known if said carts work on a real PAL Atari and what configuration it needs (ie does it needs some hardware mod to work or is it a bog standard as produced Atari) then Phaeron has no easy way to figure out what can or cannot be done.

 

Cheers..

 

They definitely work on PAL ATARI. Guaranteed :-)

 

A PAL un-moddified as from the shop machine?

Link to comment
Share on other sites

Seeing as I just bought a new PC with Windows 7, I figured I've give Altirra 1.7 a go... and I was a little more than impressed.

 

I wanted to explore the MyIDE emulation to familiarize myself with that adapter and evaluate whether or not I want to buy one for my actual Atari system. I set everything up and was able to get to FDISK2 and set up the emulated hard drive, and then into the image manager. It seemed to allow me to copy ATRs to the HD, but when I went to boot the image, it would just warmstart the emulator. What am I missing here? If I can't get it working in emulation, there's no point in me purchasing a MyIDE interface. Is MyIDE emulation still buggy?

Link to comment
Share on other sites

Also, how do you specify paths with the H: drive? For example, with Action! in A8W, I would type PATH>FILENAME.EXT to load or save a file. The ">" character is used to designate the path(s). Thanks.

 

Altirra doesn't support subdirectories through H:. Actually, I didn't know an emulator supported that. I'd be reluctant to put that in without some safeguards, because I'd like not to be the first person to enable an Atari program to 0wn a Windows box, at least not without permission.

 

I have been using the subdirectories support through A8W for a long while now without any issue. And since A8W is also open source, I guess you can take a look at those codes as a reference for a tested and proven method.

Link to comment
Share on other sites

The Bomb Jake Corina cartridge works on all stock PAL Atari's

 

I wasn't doubting that, but it was more of whether the cartridge image was actually of the final game and not a pre-release version. I noticed that the splash screen didn't match the 1.5 disk version on the website. Anyway, I'll just debug this the hard way when I get the chance, as it's probably a subtle timing problem in the emulator.

Link to comment
Share on other sites

Seeing as I just bought a new PC with Windows 7, I figured I've give Altirra 1.7 a go... and I was a little more than impressed.

 

I wanted to explore the MyIDE emulation to familiarize myself with that adapter and evaluate whether or not I want to buy one for my actual Atari system. I set everything up and was able to get to FDISK2 and set up the emulated hard drive, and then into the image manager. It seemed to allow me to copy ATRs to the HD, but when I went to boot the image, it would just warmstart the emulator. What am I missing here? If I can't get it working in emulation, there's no point in me purchasing a MyIDE interface. Is MyIDE emulation still buggy?

 

I should caution that I actually don't own a MyIDE interface and added emulation support for it blind, so it's possible there are issues in the emulation that make it harder than usual to boot an image partition; it's not necessarily fair to evaluate MyIDE just based on Altirra's emulation of it. However, I have done this with the MyIDE 4.5 firmware. It sounds like you have the IDE emulation and firmware running, so it's likely a settings issue. Check in FDISK that the partition is assigned to D1: and that image booting is enabled. Also, be aware of the warmstart (F5) vs. soft-restart (Ctrl+Shift+\) issue with soft-loaded firmware, if you're using the cartridge firmware; that's not a problem if you use the ROM kernel version instead.

Link to comment
Share on other sites

The Bomb Jake Corina cartridge works on all stock PAL Atari's

 

I wasn't doubting that, but it was more of whether the cartridge image was actually of the final game and not a pre-release version. I noticed that the splash screen didn't match the 1.5 disk version on the website. Anyway, I'll just debug this the hard way when I get the chance, as it's probably a subtle timing problem in the emulator.

Hi, with the released game, it was renamed to Bomb Jake and had a new loading / title screen created fot it. Other than the nessasary changes for Corina including the additional high score saving it is the same as the 1.5 file version. I'll have a look at the cartridge image that was mentioned just in case it wasn't a wip image.

 

p.s. the sound issue is much improved with your v1.8 test4, great work. thanks.

Edited by Tezz
Link to comment
Share on other sites

  • 3 weeks later...

OK, a bit offtopic, because it's almost 1.8 version.

 

One of my extreme tests - triangle wave sound.

 

I've noticed some glitches but comparing to other emulators the wave it much more listenable...

 

triang1.zip

 

...and the "wow-effect" is gone, woohooo!

 

The music comes from C64 Druid game.

 

Oh, and change file extension from .ZIP to .RAR as it was packed using RAR for better compression....

Edited by miker
Link to comment
Share on other sites

  • 2 weeks later...

Avery, here's the final cart image for Bomb Jake attached, it works on both real PAL and NTSC machines.

I asked Vega about Yie Another Kung Fu which I've attached the latest cart image build also, it's not yet working on a real PAL machine however.

 

@phaeron

Any chance for correct support of Bomb Jake and (possibly later, when Vega makes final version) Yie Another Kung Fu cartridges?

Link to comment
Share on other sites

Alright, slight update. I still don't know what's needed to match behavior on a real machine, but I figured out why it works in the Atari++ 1.55 emulator that's included with it. It looks like there's a bug in Atari++ where a narrow width playfield doesn't steal the correct number of refresh cycles for an IR mode 4 line when only character data is being fetched, because it seems to only check if the first DMA cycle is occupied. This results in eight less DMA cycles than there should be, and thus the DLI handler is able to execute in time. The cartridge works fine in Altirra if I turn off refresh cycles, but that's not exactly a viable fix.

Link to comment
Share on other sites

Looks like the drag and drop feature does work, I think i was trying to drag a 7zip file across instead (perhaps you could add 7zip format as well as rar format phaeron)

 

 

What made you think it didn't work?

 

The only issue I found was with using Directory Opus as my Explorer replacement but after chatting with the Opus people one of them found a bug in the Altirra sources and passed it onto Phaeron who fixed it.

 

Phaeron mentioned in the blog a while back about a problem with doing rar support etc, can't remember what it was tho.

 

Oh a thing or two with the zip support, if a zip file comes up as an unknown type then its most likely got one of those torrent nfo files etc encoded in the zip which breaks the support, just rezip the file, and it does not support multiple files from a zip (unless phaeron has updated the support) so disk one and two need separate zips.

Link to comment
Share on other sites

Alright, slight update. I still don't know what's needed to match behavior on a real machine, but I figured out why it works in the Atari++ 1.55 emulator that's included with it. It looks like there's a bug in Atari++ where a narrow width playfield doesn't steal the correct number of refresh cycles for an IR mode 4 line when only character data is being fetched, because it seems to only check if the first DMA cycle is occupied. This results in eight less DMA cycles than there should be, and thus the DLI handler is able to execute in time. The cartridge works fine in Altirra if I turn off refresh cycles, but that's not exactly a viable fix.

Any chance what this bug is, i.e. care to make a bug report? (Besides, I'm at 1.58 now. (-:)

 

Thanks,

Thomas

Link to comment
Share on other sites

1.55 is the version that was modified for Corina support and included with the Bomb Jake source. However, 1.58 still has the bug.

 

Here is the output of Atari++ 1.58's "t.s cpu" command on a narrow width IR mode 2 line, on a second or subsequent scanline:

 

CPU cycles stolen:

::::::::::::i:iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii::::::::::||||||
   ^

 

Notice the homogeneous DMA pattern in the middle, where the refresh cycles should be. Here is Altirra's DMA pattern output, for comparison:

 

Altirra> .dma
                                                                                                   1         1   
         1         2         3         4         5         6         7         8         9         0         1   
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123
.D.......................R...CRC.CRC.CRC.CRC.CRC.CRC.CRC.CRC.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C.C......................

Legend: (M)issile (P)layer (D)isplayList (R)efresh Play(F)ield (C)haracter

 

(The bogus display list cycle is a reporting artifact.)

 

In Atari++'s case, the second through ninth refresh cycles appear to be missing. I checked the source, and it looks like this code in Antic::Modeline() is what positions the refresh cycles:

     // In case we block memory refresh, move it one cycle to the back.
     if (Cpu->isBusy(mem.FirstCycle))
mem.FirstCycle++;
     if (Cpu->isBusy(mem.FirstCycle))
mem.FirstCycle++;
     // If still busy, allocate first available slot
     if (Cpu->isBusy(mem.FirstCycle)) {
mem.NumCycles  = 1;
mem.FirstCycle = lastref;
     }

 

This check needs to be done for each refresh cycle, because narrow playfields can start DMA after the first refresh cycle, and also some low resolution modes can occlude only some of the cycles. My info says that this can also happen for: horizontally scrolled narrow IR modes 2-5 with HSCROL >= 10, and horizontally scrolled narrow or normal IR modes 8-9 with HSCROL=2 or 3. As the CGIA manual hints, there are also rare cases in which ANTIC does exactly two refresh cycles, instead of the usual one or nine; this happens on the first scanline of narrow IR modes 2-5, either without scrolling or with HSCROL >= 12.

 

I have DMA charts in my reference manual (note that in this version, cycles are numbered with missile DMA is at cycle 0):

http://www.virtualdub.org/downloads/Altirra%20Hardware%20Reference%20Manual.pdf

 

You can cross-check it against Bennet's ANTIC timings chart:

http://www.atariage.com/forums/topic/125225-dma-cycle-stealing-tablechart/

 

The Acid800 V0.4 test I posted in the other thread now programmatically checks narrow and normal width playfield DMA patterns, although currently it does not check horizontal scrolling. The standalone version is antic_dmapattern.xex. Unfortunately, there seems to be a problem with RANDOM that prevents this test from running on Atari++ 1.58.

http://www.atariage.com/forums/topic/171296-acid800-an-atari-test-suite/page__view__findpost__p__2125599

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