Altirra 2.70 released

[Mclaneinc]

Small (ish) and possibly useless idea, how about a screen on Altirra that does a hardware info breakdown of what is attached, locations being used, ram config etc etc so the programmers on here could have a direct reference built in rather than needing to gather the info bit by bit or loading external diagnostic roms all on one page..

 

Even driver versions if possible?

 

Daft idea?

 

You know me, full of idea's, mostly rubbish

[Shannon]

 

If you are using the image disks to flash carts in Altirra and then saving out .car/.bin images to use with other emulators, it should work. If you are trying to boot the image disks in Atari800[Win], then it won't work; AFAIK the only Atari800-derived emulator that supports AtariMax cart flashing is a specially modified version of A8WP.

 

I'm saving them out to .car/.bin images to use in other emulators. However when I try to load them in other emulators I just get a blue boot screen with the white cursor and it sits there. So far it has only been the 8mbit images. I'll have to see if I have an image disk with a 1mbit image.

 

Update:

 

Ok. It's the 8mbit images that seem to be giving me problems.. I've tried both old and new formats.

 

Update 2:

 

Disregard everything I said. Apparently the SIO patch needed to be disabled on these particular images for them to work. Oddly they work fine with Altirra with the patch. So Altirra must be smarter.

 

Thanks for you help.

Edited August 22, 2016 by Shannon

[Keatah]

Something like an "emulated machine" status and configuration report.

[morelenmir]

Small (ish) and possibly useless idea, how about a screen on Altirra that does a hardware info breakdown of what is attached, locations being used, ram config etc etc so the programmers on here could have a direct reference built in rather than needing to gather the info bit by bit or loading external diagnostic roms all on one page..

 

Even driver versions if possible?

 

Daft idea?

 

You know me, full of idea's, mostly rubbish

 

Absolutely not daft at all Paul!!! I asked for much the same thing a good few months back - basically in my case to make it easier when you are submitting a potential bug report and need to list the machine configuration and peripherals currently under emulation; copy and paste. Closely related to this would be some kind of display - maybe in overlay like an FPS counter - that would relate the current SIO transfer rate. Hopefully Phaeron will have a crack at one of these when he gets a moment for an entirely new feature.

 

One suggestion that has occurred to me recently is to make the Disk Drive dialogue box modeless so it can remain open while you run the machine. This would make it considerably less tedious if you are creating and swapping disks frequently. Most usefully it would let you stay constantly in track of what disk is current in which drive number - something I forget all the time. Ideally it would be a separate, dockable window paine like the printer display so you could attach it to some part of the screen and always have instant access. For an idea how this might work, the Spectrum emulator 'Spectaculator' does this very well for the current tape image and microdrive status. However just being modeless would be a big help.

Edited August 22, 2016 by morelenmir

[Mclaneinc]

I like the idea of the disk drive window as well but I wonder about the focus between windows causing hiccups?

 

But I'm no genius

[+DrVenkman]

I like the idea of the disk drive window as well but I wonder about the focus between windows causing hiccups?

 

But I'm no genius

That's how Atari800MacX works in OS X - a separate little Media window that shows at a glance disk drive status and the name of any disks mounted, same for .CAS files loaded, cart inserted, and a few other things for reference (emulated machine/RAM amount etc).

 

I also wish here was a persistent window for "machine configuration" where we could select all the options for system, memory, installed hardware, and accelerations applied to various system components. That's the kind of UI stuff that would make Altirra vastly more accessible to the more casual user.

[Mclaneinc]

Sadly I know the UI is one thing many authors actually hate doing but its a hope that Avery likes the idea and has some time to do it as some point..

 

I've just seen that WinUae has a new all in one window for hardware (well I've read the change log that talks about it) and Toni the author instantly said the UI is 'as is' in a basic form and it will be the last to get a update

 

I hope Avery does an all in one window but I bet if he does someone complains that its too complicated now

 

Whatever the outcome I'm spoilt rotten by Altirra and have nothing to moan about, I just like most of us say what we feel might be nice and see if the good man adds it, now if only Avery would add 2600 and 7800 support

 

Just joking Avery...That's for the 5.00 branch

[+DjayBee]

Sid Meier's Formula One seems to no longer work with Altirra 2.80. It works fine with 2.70.

 

I tried several combinations of OS and BASIC and it always crashes some time after reading sector 4.

 

DISK: Reading vsec= 43 (1/1) (trk=2), psec= 42, chk=99, rot=44.60 >> 0.20 >> 0.60.
DISK: Reading vsec= 4 (1/1) (trk=0), psec= 3, chk=40, rot=49.98 >> 0.59 >> 0.98 (w/CRC error).
Breakpoint 0 hit
(1979:257, 97) A=0C X=10 Y=A5 S=FB P=31 ( C) 19B1: 20 56 E4 JSR CIOV [$E456] = $4C
Altirra> .iocb
CIO IOCBs:
# Dev Cd St Bufr PutR BfLn X1 X2 X3 X4 X5 X6
ZP 03 A5 0000 0001 0000 04 00 01 00 10 04
0 00 00 0000 0000 0000 00 00 00 00 00 00
1 0C A5 0000 0001 0000 04 00 00 00 00 00
2 00 00 0000 0000 0000 00 00 00 00 00 00
3 00 00 0000 E4C0 0000 00 00 00 00 00 00
4 00 00 0000 E4C0 0000 00 00 00 00 00 00
5 00 00 0000 E4C0 0000 00 00 00 00 00 00
6 00 00 0000 E4C0 0000 00 00 00 00 00 00
7 00 00 0000 E4C0 0000 00 00 00 00 00 00
Altirra> g
CPU: Illegal instruction hit: 01EC
(1982:158,107) A=00 X=10 Y=92 S=F5 P=33 ( ZC) 01EB: 92 KIL

The exact address differs but it always happens inside CIO:

E689: A0 92 LDY #$92
E68B: 20 93 E6 JSR $E693

E693: AA TAX
E694: A5 2D LDA ICAX4Z
E696: 48 PHA
E697: A5 2C LDA ICAX3Z
E699: 48 PHA
E69A: 8A TXA
E69B: A6 2E LDX ICAX5Z
E69D: 60 RTS

Formula 1 Racing (1982)(Acorn Software)(US)BASICOS-B.zip

Edited August 25, 2016 by DjayBee

[Mclaneinc]

I've never seen this game...

 

Was it in the preserved set...(just in from 9hrs at the hospital..bit tired)

 

 

Paul......Care to post all your saved disks please?..ie not just your cracks?

[+DjayBee]

I've never seen this game...

 

Was it in the preserved set...(just in from 9hrs at the hospital..bit tired)

 

Paul......Care to post all your saved disks please?..ie not just your cracks?

 

I found it some time ago somewhere on the net and submitted it to Farb. The latest torrent does contain the dump.

 

I have no unsubmitted disks. The cracks are mostly dumps from Farb's torrent. Sometimes Atarimania has dumps which differ from these; I then submit them to Farb for inclusion.

 

Take care and good luck with your health. *fingers-crossed*

[Madi]

I transferred the disk files to .ATR image with listable directory files. I rebuilt the Variable Name Table of the main basic file "RACE.BA" with the aid of Altirra.

I did not examine the protection method (may be a bad sector =sector #4).

The protection checking routine could be conducted through a modified DOS.SYS. Not sure.

A copy of the non working Formula 1 Racing image is attached if you want have a closer look. Good luck

 

madi

Formula 1 Racing (1982)(Acorn Software)(US)BASICOS-B.atr

Edited August 25, 2016 by Madi

[phaeron]

This is due to a buggy copy protection mechanism. Turn off SIO burst transfers, any high speed OS patch, and any PBI disk handlers, and boot it on OS-B or the XL/XE OS and it should work fine on 2.80. Any other OS and it's a crapshoot whether it'll work.

 

What Formula One Racing does is it requests a disk read on top of the OS database in page two by accident, due to not resetting the buffer pointer from DVSTAT ($02EA) after a status read:

HOOKSIOREQS: Checking SIOV request: Device $31 | Command $52 | Mode $40 | Address $02EA | Length $0080
SIOCMD: Device 31 | Command 52 | 04 00 (Disk: Read sector)

This read request overlaps a whole ton of OS variables at $02EA-0369. The CIO device handler table starts at $031A, so it would be clobbered by this read. The reason it normally doesn't is that the read clobbers TIMFLG at $0317 first and causes the SIO read to time out! As a result, SIO fails with a timeout error and attempts to retry. The second time, it sends a bogus command out over the bus that no device answers and the buffer isn't overwritten. Return Y=$8A, copy protection routine thinks sector 4 has a CRC error as expected, miraculously life goes on.

 

When burst I/O is enabled, though, this can fail because the incoming byte stream comes in fast enough that the IRQ routine is able to start overwriting HATABS before the mainline routine can detect the "timeout." The result is a crash in CIO when it tries to dereference through the device table. This still works with disk acceleration (SIO patch) because Altirra's disk SIO patch code has a specific check for this kind of bogus read and bypasses acceleration if it sees a read on top of SIO's variables. This then causes a fallback to the regular 6502-based SIO handler. If burst transfers are enabled, though, the emulator can't bypass the burst transfer because it doesn't know about the bogus buffer pointer when a 6502-based routine is handling the receive side, HATABS gets overwritten, fireworks ensue.

 

[+DjayBee]

Turn off SIO burst transfers

 

*Argh* I must have switched this on sometime in the past and forgotten about it.

While testing yesterday I changed every setting related to speed and acceleration but overlooked this submenu.

 

Thanks and sorry for bothering you

[Madi]

Thank you phaeron

 

I think I have figured it out.

Actually, the ripout image of the original game works just fine. As I suspected, DOS.SYS file is the one that made the copy protection issue.

The game works whether SIO patch /accurate sector time are ON or OFF.

It only works (at least for me) with BASIC A rom. It crashes with BASIC B or C.

 

 

 

madi

Formula 1 Racing (1982)(Acorn Software)(US)BASICOS-B.atr

[StefanD]

I found a small problem with the debugger:

 

Boot ATARI DOS 2.0 from a 90K image (DOS 2.5 should also do)

F8

bp 7e0 (break point at the disk handler init routine)

g

Debug - Enable Debugger (turn debugger view off and clear all breakpoints)

F5

 

Now the "Altirra Error" Dialog is displayed. If you press the Debug button, and enter bl, you see that the breakpoint is yet there, which may have caused this problem. (If you don't enter g in this example, it works as expected.)

[phaeron]

Yeah, the debugger doesn't detach cleanly if the simulation is running when the detach is requested. Not hard to fix this specific case, but there's probably lots that doesn't get detached.

Edited August 31, 2016 by phaeron

[drac030]

There is some annoying thing concerning Altirra's window: when other windows are opened (such as those in the debugger: disassembly, console etc.), the main window often loses focus and does not regain it even if it gets topped. In the debugger, clicking "Enable debugger" twice causes the issue to go away.

 

I did not report it because it is difficult to reproduce: it sometimes occurs and sometimes it does not. But I think I found a method to reproduce it consistently now:

 

1) run Altirra

 

2) Click View->Printer outupt: the printer window opens docked at the bottom of the main window

 

3) the main window contents (with e.g. SDX CP waiting for commands) is out of focus now.

 

4) undock the printer window. It is topped.

 

5) click on the main window to top it. It gets visibly topped.

 

6) but: still no focus, keypresses do not cause a reaction.

 

Clicking "Reset window layout" causes the topped window to regain the focus.

Edited August 31, 2016 by drac030

[phaeron]

Hmm. Do you think this is related to undocking windows? With this particular sequence of steps, the issue is that the main window doesn't know what sub-window to give focus to. Normally, if it is activated directly -- not by clicking in one of the sub-windows -- the main window will give focus to the last sub-window that had it. The problem is that in this case, that sub-window has been undocked, so the main window doesn't know who to give focus to. It's a bug that the main window simply gives up, since it should choose some subwindow, but I'm not sure it would always pick the one that you expect.

 

If there are other cases not related to undocking where you are seeing this, does clicking in the desired subwindow or selecting it by menu or keyboard shortcut restore focus?

[drac030]

Uhmm. I spent some time clicking around and I know already, what I was doing wrong. Namely the thing I was not aware of is that the "main" window (the one where the Atari screen is displayed), is a subwindow itself.

 

Just when it is not undocked, could it get the focus automatically in the above scenario, when the main window (the one with the menu) gets topped?

[flashjazzcat]

Recursive expansion of ARC files is a nice feature, although for some reason I expected it to be a toggle which caused disk explorer to recursively open ARC files as subdirectories when double-clicked. Might that be possible anyway (since there's no default behaviour associated with "opening" of ARC files in the explorer)?

[phaeron]

Uhmm. I spent some time clicking around and I know already, what I was doing wrong. Namely the thing I was not aware of is that the "main" window (the one where the Atari screen is displayed), is a subwindow itself.

 

Just when it is not undocked, could it get the focus automatically in the above scenario, when the main window (the one with the menu) gets topped?

 

Yes, the display is itself a pane. In older versions of the emulator, you would see the Display title on the pane and it would light up blue (or accented) whenever it was active like any other window. I changed the UI system in later versions to remove the frame for windows docked in the center position to reduce the amount of window chrome. The downside is that you can't see the title and focus state anymore.

 

I don't think I can change the behavior as you describe because it would be annoying when you were working in the debugger: Alt+Tabbing to and from the window would push focus to the display instead of the console, if the latter is what you had focused. What I will do, though, is make it choose another pane to get focus in the same way that closing the active pane does. This selects the pane underneath if there was a stack, and otherwise goes upward. Since the Display pane is usually in the center, it has a good chance of becoming this new default.

 

Recursive expansion of ARC files is a nice feature, although for some reason I expected it to be a toggle which caused disk explorer to recursively open ARC files as subdirectories when double-clicked. Might that be possible anyway (since there's no default behaviour associated with "opening" of ARC files in the explorer)?

 

Yeah, sorry, no nested namespaces in the explorer yet. The main reason I added this feature was that I was tired of dragging files in and out of the Disk Explorer to access drivers on the SDX Toolkit disk. It was more useful anyway to have the files actually expanded on the volume so that SDX could load directly from it.

[morelenmir]

I am currently finding my feet again in Atari ASM, using Eclipse/WUDSN and MADS to write/compile and then Altirra to debug. My current interest is cartridge images and booting.

 

Now, if one is using this workflow to produce 'normal' *.XEX sourcecode and WUDSN IDE to compile and launch them in the Altirra debugger the 'source-level debugger' starts up automatically, with the breakpoints set manually in Eclipse and even the sourcecode itself appearing in its own window showing the current point of execution. However if you use the same setup, but with ';@com.wudsn.ide.asm.outputfileextension=.rom' specified to create a cartridge image which is then automatically 'sent' to the Altirra debugger, even if you have all the necessary *.LST and *.atdbg files created at compile time the 'source level debugging' system does not start automatically and the breakpoints specified in Eclispse/WUDSN do not seem to be 'seen' by Altirra. Am I missing a setting somewhere - perhaps in the Altirra commandline?

 

My second and closely allied question is; how do you specify that the *.ROM you are handing off to the Altirra debugger is an 8k cartridge image (or any other sort)? Currently the cartridge image dialogue opens every time I compile and launch the debugger, which is obviously not a problem in itself but can become a little tedious if you are doing lots of small, incremental changes and want to see how they work out.

[fujidude]

@morelenmir: This topic has been "obsoleted" by the new Altirra 2.80 released topic. You might want to repost over on it.

[+JAC!]

I am currently finding my feet again in Atari ASM, using Eclipse/WUDSN and MADS to write/compile and then Altirra to debug. My current interest is cartridge images and booting.

 

Now, if one is using this workflow to produce 'normal' *.XEX sourcecode and WUDSN IDE to compile and launch them in the Altirra debugger the 'source-level debugger' starts up automatically, with the breakpoints set manually in Eclipse and even the sourcecode itself appearing in its own window showing the current point of execution. However if you use the same setup, but with ';@com.wudsn.ide.asm.outputfileextension=.rom' specified to create a cartridge image which is then automatically 'sent' to the Altirra debugger, even if you have all the necessary *.LST and *.atdbg files created at compile time the 'source level debugging' system does not start automatically and the breakpoints specified in Eclispse/WUDSN do not seem to be 'seen' by Altirra. Am I missing a setting somewhere - perhaps in the Altirra commandline?

 

My second and closely allied question is; how do you specify that the *.ROM you are handing off to the Altirra debugger is an 8k cartridge image (or any other sort)? Currently the cartridge image dialogue opens every time I compile and launch the debugger, which is obviously not a problem in itself but can become a little tedious if you are doing lots of small, incremental changes and want to see how they work out.

 

My recommendation (that's how I normally work):

- regular compling in WUDSN to .xex and normaly testing

- for testing with an actual ROM build, use a separate shell script or ANT task and this

http://atariage.com/forums/topic/235118-atari-rom-maker/

is allowes you to create .car images out of the plain ROm with with correct cartridge type and CRC checksum.

[morelenmir]

@morelenmir: This topic has been "obsoleted" by the new Altirra 2.80 released topic. You might want to repost over on it.

Many thanks fujidude!!!

 

I did not even realize there was a new full release available! The 'My Content' link is intensely useful, but has its drawbacks.

 

Many thanks also Jac - that is a very reasonable suggestion! I guess in a way adding the cartridge specific code could be looked on as the last stage of development, a little like making an installer scripts in windows.

Edited September 5, 2016 by morelenmir