96 replies to this topic

[Goochman]

Couple things:

1.  Not sure why but it was running really slow for me on my Quad Core PC.  I had to reboot anyway and upon return its running fine

2.  I am running 64bit Vista - How do I get Altirra to recognize my Stelladaptor USB joystick?

[bf2k+]

flashjazzcat, on Wed Feb 3, 2010 11:42 AM, said:

pseudografx, on Wed Feb 3, 2010 8:25 AM, said:

This is my attempt at Altirra icon - it does not use the Atari logo font. Instead, it uses the Atari system font. Hope you like it. Suggestions welcome!

Classic 32x32 icon:
altirra32.png

Large 48x48 icon:
altirra48.png

Personally I like that just the way it is.

Me too.

[phaeron]

flashjazzcat, on Wed Feb 3, 2010 4:44 AM, said:

phaeron, on Tue Feb 2, 2010 11:29 PM, said:

I fixed that a while back, and it was the opposite case (the self-test ROM wasn't ever enabling). I checked, and the self-test ROM seems to be working normally in current versions -- it only appears when extended RAM is disabled and both the kernel and self-test ROMs are enabled. Can you supply the output of the .pia command when the self-test ROM is unexpectedly?

No problem:

Port B direction: ff
Port B output:	31

Hope that helps. I've updated the program somewhat but it's still crashing will a bad instruction at 57FD under Altirra when 1088K is selected.

Eh? You've got kernel ROM enabled (bit 0 = 1), CPU extended RAM disabled (bit 4 = 1), and self-test ROM enabled (bit 7 = 0). This configuration will enable the self-test ROM in some 1088K setups. Why aren't you using $B1 instead?

[phaeron]

Oooh, I like that icon -- simple.

I added ca65 label support to this version. Source-level support is more complex, but this will get disassembly and function-level profiles annotated.
http://www.virtualdu...a-1.6-test2.zip
http://www.virtualdu...6-test2-src.zip

Quote

I'm running OpenSuse 11.2, kernel version 2.6.31.5-0.1-default, with * cough * KDE.

Admittedly with just 1667 Mhz Athlon based system I'm running on a less than state-of-the-art machine. However, I can't imagine this could be the cause of my problems.

The Athlon shouldn't be a problem, as Altirra runs on a 1.6GHz Atom without problems. That you're running Altirra on Linux, however, probably is. I assume you're using WINE to do this; that means there is an extra layer of possible WTF involved here. You can either try forcing DirectDraw mode (/ddraw), or disabling VSync in the View menu (or via /novsync) and see if that helps. (I just added that option.)

Quote

2. I am running 64bit Vista - How do I get Altirra to recognize my Stelladaptor USB joystick?

As long as it shows up as a regular Windows gamepad, Input > Port 1 > Gamepad -> Joystick (port 1) should do the trick. You'll have to manually set up a mapping in Input Manager if you want to target Atari port 2 or if you want to change the button/axis mappings on your gamepad. In the default mapping the POV hat, left analog stick, and buttons 1-4 are all mapped to the Atari joystick.

[pseudografx]

My icon, now with rainbow colours :-) I guess the background would be transparent which is IMHO better than a uniform square.

[Philsan]

pseudografx, on Thu Feb 4, 2010 2:21 AM, said:

My icon, now with rainbow colours :-) I guess the background would be transparent which is IMHO better than a uniform square.

altirra32b.png

altirra48b.png

One of the strenghts of A8, compared with other 8-bit computers (even later ones), is colors palette.
So, yes, I prefer this icon.

[Heaven/TQA]

I am voting for Fuji-Logo somehow... That's Atari...not the "A"...

take a screenshot of the Fuji-Boink-Demo and take the Atari-Logo out of it including the Rainbow color?

[Philsan]

Heaven/TQA, on Thu Feb 4, 2010 2:54 AM, said:

I am voting for Fuji-Logo somehow... That's Atari...not the "A"...
take a screenshot of the Fuji-Boink-Demo and take the Atari-Logo out of it including the Rainbow color?

I agree but, if you read previous posts, Phaeron doesn't want anything similar to original Atari logo.
I think last beautiful Pseudografx work is a good compromise.
A8 original font + rainbow colors.

[Mclaneinc]

Love the new Icons, perfect for me, A for Atari / Altirra and the rainbow ......Sweet..

[pseudografx]

Here is the final .ICO file with transparency.

 altirra.ico   13.62K   70 downloads

[bf2k+]

pseudografx, on Thu Feb 4, 2010 2:21 AM, said:

My icon, now with rainbow colours :-) I guess the background would be transparent which is IMHO better than a uniform square.

altirra32b.png

altirra48b.png

Very Nice!

[ndary]

is there an Atari emulator on the PC that can connect to an ATARI 1050 drive (via the serial port with SIO2PC cable) and boot real atari floppies?

[a8isa1]

[quote name='phaeron' date='Thu Feb 4, 2010 1:15 AM' timestamp='1265264103' post='1934339']

The Athlon shouldn't be a problem, as Altirra runs on a 1.6GHz Atom without problems. That you're running Altirra on Linux, however, probably is. I assume you're using WINE to do this; that means there is an extra layer of possible WTF involved here. You can either try forcing DirectDraw mode (/ddraw), or disabling VSync in the View menu (or via /novsync) and see if that helps. (I just added that option.)

[quote]
Thanks for the update but unfortunately I am still having problems.

Yes, I am running wine in linux.

The 8 second lag is gone but Altirra runs very slowly.

As the window pops open the emulation is running at about 20 fps. If I stretch the window (to 1280x1024) the speed drops to just over 8 fps. If I shrink the window to a 3" diagonal (guessing 400x300 size) it's at 30 fps.

/ddraw and /[no]vsync setting have little/no impact.

- Steve Sheppard

[Heaven/TQA]

Phaeron, I am just coding the intro for Gridrunner and was wondering if your 53770 (random) handling is correct? as I am feeding some vars with random values and the effect is always the same as the parameters are set same values like the before?

I am starting Altirra directly out of Eclipse... so I would assume that the starting of the intro takes same cycle amount and so is the random value always the same?

[ivop]

a8isa1, on Thu Feb 4, 2010 1:17 PM, said:

Thanks for the update but unfortunately I am still having problems.

Yes, I am running wine in linux.

The 8 second lag is gone but Altirra runs very slowly.

As the window pops open the emulation is running at about 20 fps. If I stretch the window (to 1280x1024) the speed drops to just over 8 fps. If I shrink the window to a 3" diagonal (guessing 400x300 size) it's at 30 fps.

/ddraw and /[no]vsync setting have little/no impact.

- Steve Sheppard

/gdi is the only thing I get to work on debian stable (wine 1.0.1-174). D3D crashes horribly and ddraw screws up my whole screen. With /gdi and /novsync I get around 22fps on a Sempron 2400+ (1.67MHz, ia32) and a GeForce 2 MX card.

Edited by ivop, Thu Feb 4, 2010 5:37 PM.

[a8isa1]

ivop, on Thu Feb 4, 2010 5:37 PM, said:

a8isa1, on Thu Feb 4, 2010 1:17 PM, said:

Thanks for the update but unfortunately I am still having problems.

Yes, I am running wine in linux.

The 8 second lag is gone but Altirra runs very slowly.

As the window pops open the emulation is running at about 20 fps. If I stretch the window (to 1280x1024) the speed drops to just over 8 fps. If I shrink the window to a 3" diagonal (guessing 400x300 size) it's at 30 fps.

/ddraw and /[no]vsync setting have little/no impact.

- Steve Sheppard

/gdi is the only thing I get to work on debian stable (wine 1.0.1-174). D3D crashes horribly and ddraw screws up my whole screen. With /gdi and /novsync I get around 22fps on a Sempron 2400+ (1.67MHz, ia32) and a GeForce 2 MX card.

Thanks, ivop.

/gdi and /novsync options have Altirra performing much better. I have to shrink the window to about 2 inches (5 cm?) to get full speed but it's better than running in slow motion.

- Steve Sheppard

Edited by a8isa1, Thu Feb 4, 2010 6:52 PM.

[cyco130]

ndary, on Thu Feb 4, 2010 10:34 AM, said:

is there an Atari emulator on the PC that can connect to an ATARI 1050 drive (via the serial port with SIO2PC cable) and boot real atari floppies?

I believe atari++ supports HiassofT's AtariSio under Linux.

[phaeron]

Heaven/TQA, on Thu Feb 4, 2010 3:55 PM, said:

Phaeron, I am just coding the intro for Gridrunner and was wondering if your 53770 (random) handling is correct? as I am feeding some vars with random values and the effect is always the same as the parameters are set same values like the before?

I am starting Altirra directly out of Eclipse... so I would assume that the starting of the intro takes same cycle amount and so is the random value always the same?

Yes, it is as you have guessed.

RANDOM is actually completely deterministic -- its value is determined by 8 bits of the 9/17-bit noise generator, which starts counting as soon as the OS pulls POKEY out of initialization mode on boot by setting SKCTL[1:0]. Therefore, if you manage to read it at the exact same times from initialization, you will get the same values. The reason why this is an emulator gotcha is that on a real Atari you will only see this if you are starting your program off of a cartridge or PBI-based RAM/ROM device; any SIO-based boot mechanism will have timing variation and result in a random position in the LFSR sequence. One way to avoid this problem is to introduce a press-any-key screen; a single key press will completely randomize the LFSR offset since the LFSR counts very quickly (it runs through the entire cycle about 13 times a second).

There are two other things you should be aware of. First, make sure you haven't accidentally put POKEY back into initialization mode by clearing SKCTL[1:0]; if this is the case, you will get $FF out of RANDOM. This also locks the slow timers, though, so it's hard to miss if you are playing music. Second, if you have put the long LFSR into 9-bit mode by setting AUDCTL[7], that will also affect RANDOM and shorten its cycle length to 511 values, which obviously repeats much more often.

What all of this means, incidentally, is that you can use RANDOM as a cycle timer -- force init to clear the LFSR before the timing scope, and read a few samples at known spacing after it, and then compute the cycle count from the read values based on the LFSR polynomial.

[phaeron]

a8isa1, on Thu Feb 4, 2010 6:50 PM, said:

ivop, on Thu Feb 4, 2010 5:37 PM, said:

/gdi is the only thing I get to work on debian stable (wine 1.0.1-174). D3D crashes horribly and ddraw screws up my whole screen. With /gdi and /novsync I get around 22fps on a Sempron 2400+ (1.67MHz, ia32) and a GeForce 2 MX card.

/gdi and /novsync options have Altirra performing much better. I have to shrink the window to about 2 inches (5 cm?) to get full speed but it's better than running in slow motion.

Yuck. Wine had that DirectDraw clipping bug for an astoundingly long time and it affected a ton of apps, but I believe it's been fixed in WINE 1.1.

The problem here is that without DirectDraw you're stuck with either GDI and Direct3D, and WINE emulates Direct3D by pushing it through OpenGL, which won't work because a GeForce 2 MX is too old to support enough of OpenGL to emulate Direct3D, even at the level at Altirra uses. Therefore, you're only left with GDI, which apparently is using a very slow blit path in Wine. There's a chance that you might be able to boost performance by enabling PAL artifacting -- this forces a 32-bit surface instead of an 8-bit surface, which may render faster -- but it's a shot in the dark.

As Altirra is a Win32 application I don't support running it under Linux, but there may be something I can do to improve this situation. Since Altirra shares VirtualDub's display code, there is a currently inaccessible OpenGL display path that I can try exposing, which may give much improved stretchblt performance.

[ivop]

phaeron, on Thu Feb 4, 2010 11:02 PM, said:

Yuck. Wine had that DirectDraw clipping bug for an astoundingly long time and it affected a ton of apps, but I believe it's been fixed in WINE 1.1.

The problem here is that without DirectDraw you're stuck with either GDI and Direct3D, and WINE emulates Direct3D by pushing it through OpenGL, which won't work because a GeForce 2 MX is too old to support enough of OpenGL to emulate Direct3D, even at the level at Altirra uses. Therefore, you're only left with GDI, which apparently is using a very slow blit path in Wine. There's a chance that you might be able to boost performance by enabling PAL artifacting -- this forces a 32-bit surface instead of an 8-bit surface, which may render faster -- but it's a shot in the dark.

As Altirra is a Win32 application I don't support running it under Linux, but there may be something I can do to improve this situation. Since Altirra shares VirtualDub's display code, there is a currently inaccessible OpenGL display path that I can try exposing, which may give much improved stretchblt performance.

That would be great!

I will also see to it to compile the latest wine from source. Debian stable is always "a bit" behind. Enabling PAL artifacting w/ GDI rendering slowed it down to about 21fps.

BTW I like it that you can disable rendering all together. This will help me tremendously while testing various sound routines under wine. Without a display, it easily maintains 50 "frames" per second.

[a8isa1]

phaeron, on Thu Feb 4, 2010 11:02 PM, said:

a8isa1, on Thu Feb 4, 2010 6:50 PM, said:

ivop, on Thu Feb 4, 2010 5:37 PM, said:

/gdi is the only thing I get to work on debian stable (wine 1.0.1-174). D3D crashes horribly and ddraw screws up my whole screen. With /gdi and /novsync I get around 22fps on a Sempron 2400+ (1.67MHz, ia32) and a GeForce 2 MX card.

/gdi and /novsync options have Altirra performing much better. I have to shrink the window to about 2 inches (5 cm?) to get full speed but it's better than running in slow motion.

Yuck. Wine had that DirectDraw clipping bug for an astoundingly long time and it affected a ton of apps, but I believe it's been fixed in WINE 1.1.

The problem here is that without DirectDraw you're stuck with either GDI and Direct3D, and WINE emulates Direct3D by pushing it through OpenGL, which won't work because a GeForce 2 MX is too old to support enough of OpenGL to emulate Direct3D, even at the level at Altirra uses. Therefore, you're only left with GDI, which apparently is using a very slow blit path in Wine. There's a chance that you might be able to boost performance by enabling PAL artifacting -- this forces a 32-bit surface instead of an 8-bit surface, which may render faster -- but it's a shot in the dark.

As Altirra is a Win32 application I don't support running it under Linux, but there may be something I can do to improve this situation. Since Altirra shares VirtualDub's display code, there is a currently inaccessible OpenGL display path that I can try exposing, which may give much improved stretchblt performance.

I guess IVOP and I are in similar situations. I am using the current Wine snapshot, 1.1.37. However, ever since my ATI video card failed several months ago I've been stuck with this old Geforce 2 card.

At least I know how to solve the problem.

Thanks phaeron.

- Steve Sheppard

[Wrathchild]

Some questions relating to the history window's behaviour in Altirra with respect to debuging (against what I'm currently doing in Atari800WinPLus).

After setting a breakpoint and that being hit, in Atari800WinPLus I can use the 'history' command to show the events leading upto this. Here is what I am doing in Altirra.

1) After running Altirra debugging needs to be enabled to bring up the relevent windows. (is there a setting for this to be the default when the app is launched?)
2) using the Console I set a breakpoint.
3) I then have my program loaded and executed and the breakpoint gets hit and this is reported in the Console and Disassembly windows.
4) At this point it doesn't look clear to me if the History window has been refreshed to show the 'recent' history? (opening up the call histories I could not find the address broken against)

Have I missed a step somewhere? How much history is preserved? Are there any Console commands relating the History window? (is there a need for any come to think about it?)

Cheers,
Mark

[Edit] This is odd too - I'm doing some development on a PIC18F2455 USB capable device, using slightly modded versions of their HID bootloader firmware example. With this plugged in, Altirra crashes upon startup with an error in dinput8.dll.

Edited by Wrathchild, Mon Feb 22, 2010 6:48 AM.

[miker]

Hmm... to be honest - now POKEY's turn.

About last year's vacation I've been playing with RMT (that "triangle" and "sawtooth" sounds).
While A800WinPLus 4.0 deals with sawtooth just fine, Altirra seems to mess something with the tune of it.

Two examples here to show, what I mean.

 mayonn2.xex   3.15K   62 downloads
and
 plastic2.xex   3.7K   72 downloads

I'm sure that it can sound much better.

Greetings

miker

Edited by miker, Mon Feb 22, 2010 12:01 PM.

[PeteD]

I was about to post about when I was checking out Internation Karate yesterday whilst commenting in the Hubbard thread.  The music plays fine on A800Win but the lead line is near silent on Altirra.


Pete

[flashjazzcat]

phaeron, on Wed Feb 3, 2010 11:43 PM, said:

flashjazzcat, on Wed Feb 3, 2010 4:44 AM, said:

phaeron, on Tue Feb 2, 2010 11:29 PM, said:

I fixed that a while back, and it was the opposite case (the self-test ROM wasn't ever enabling). I checked, and the self-test ROM seems to be working normally in current versions -- it only appears when extended RAM is disabled and both the kernel and self-test ROMs are enabled. Can you supply the output of the .pia command when the self-test ROM is unexpectedly?

No problem:

Port B direction: ff
Port B output:	31

Hope that helps. I've updated the program somewhat but it's still crashing will a bad instruction at 57FD under Altirra when 1088K is selected.

Eh? You've got kernel ROM enabled (bit 0 = 1), CPU extended RAM disabled (bit 4 = 1), and self-test ROM enabled (bit 7 = 0). This configuration will enable the self-test ROM in some 1088K setups. Why aren't you using $B1 instead?

The software first establishes (using a tried and tested algorithm) which bits cause bank switching at $4000-$7FFF and stores those values for later use. It works on real hardware and in Atari800WinPlus: I believe it's understood there's a problem with Altirra's 1088K emulation.

Edited by flashjazzcat, Mon Feb 22, 2010 1:03 PM.