Altirra 1.9 released

[Creature XL]

Feature request, if I may:

 

Feature: Set speed to 1% (or slower)

 

Reason: I can only set it to 10% in the GUI, but that is still to fast while debugging.

If it is not feasible to do in the GUI, a command for the debugger shell would be enuff.

AND, Vice can do it as well, so an Atari emulator has to be capable of it as well

 

 

Thanks

 

 

EDIT:

of course I can help me out with a break point in the VBI routine in this particular case. But there were also bugs where I needed to to press keys. Which doesn't work so well when the emulation has been stopped.

Edited September 17, 2011 by Creature XL

[phaeron]

Avery, any reason why you didn't use the traditional S & F method ie

 

F 1000 2000 ff to fill between 1000 & 2000 with ff

 

S 1000 2000 a9 01 to find any a9 01's between that address range.

 

Not knocking it, just wondered why the different approach.

 

Just personal bias. I don't use other emulator debuggers much, so the length syntax is modeled after the command-line Win32 debugger that I sometimes use (WinDbg). One advantage of the length syntax is that it'd be easier to use with an expression for the base address.

 

I have considered modifying the length syntax so you can specify an end address, something like: f 1000 L:2000 ff

 

Feature: Set speed to 1% (or slower)

 

Reason: I can only set it to 10% in the GUI, but that is still to fast while debugging.

If it is not feasible to do in the GUI, a command for the debugger shell would be enuff.

AND, Vice can do it as well, so an Atari emulator has to be capable of it as well

 

I think I can do that, although I'll have to check how everything responds. The lower limit is just in the UI at the moment.

[+JAC!]

>I have considered modifying the length syntax so you can specify an end address, something like: f 1000 L:2000 ff

Good idea

[Mclaneinc]

 

Just personal bias. I don't use other emulator debuggers much, so the length syntax is modeled after the command-line Win32 debugger that I sometimes use (WinDbg). One advantage of the length syntax is that it'd be easier to use with an expression for the base address.

 

I have considered modifying the length syntax so you can specify an end address, something like: f 1000 L:2000 ff

 

 

That would be excellent....Same with the search if possible...

 

Thanks Avery, always listening and helping!

[flashjazzcat]

Does Altirra implement the IDEa (KMK/JZ version 1.0) ROM banking scheme? I was having problems testing an experimental banked ROM last night - emulated machine wouldn't boot.

 

The banking is as follows (from KMK):

 

"About the banking: it is a problem, because first versions of IDEa

 

(rev. A) mistakenly implement the banking registers from the original

 

(KMK/JŻ IDE). Anyway:

 

- a write to $d1c0 (and a RESET) should activate bank 0.

 

- a write to $d1a0 should activate bank 1.

 

In IDEa rev. A the registers are reversed. There are IDEas rev. B with

 

this error fixed."

Edited September 26, 2011 by flashjazzcat

[flashjazzcat]

In addition, testing the 512KB version of the SIDE ROM (with SIDE loader starting at bank #32, i.e. in emulated external flash cart space, and SDX in banks 0-31), SIDE loader always appears at boot. Can the system be switched to SDX mode?

[phaeron]

I think I ran into a problem with the IDEa flasher failing with the two-bank scheme enabled on V1 emulated hardware. I'll have to see if I can re-enable it.

 

In addition, testing the 512KB version of the SIDE ROM (with SIDE loader starting at bank #32, i.e. in emulated external flash cart space, and SDX in banks 0-31), SIDE loader always appears at boot. Can the system be switched to SDX mode?

 

I'm not familiar with this -- is there a physical switch?

[rost]

Feature request (if i may) / suggestion

1. Do you have a wordfile with the english text strings, used in altirra menus, so a translation would be possible?
   
2. A suggestion for the "Paste" function in Altirra: How about switching Altirra into "Warp"-Mode when pasting text into Altirra and switching it back to the mode it was before (Warp or non-warp) when pasting is finished?This way, pasting would always be as fast as possible, regardless of what mode Altirra is currently in.
   
3. I miss (may be I just did'nt found it) a State-Save-function, witch generates a state-file. So i can load it again and again or give it to someone or continue after a month...
   

Would be great to have this features, nevertheless even without the best emu i know

[phaeron]

Do you have a wordfile with the english text strings, used in altirra menus, so a translation would be possible?

 

No, not yet. This has been asked for before, and I need to sit down to figure out how to do this (localization + exceptions = sadness). It's also not so simple when you have some strings in code, in Win32 resources, and even some in 6502 code....

 

A suggestion for the "Paste" function in Altirra: How about switching Altirra into "Warp"-Mode when pasting text into Altirra and switching it back to the mode it was before (Warp or non-warp) when pasting is finished?This way, pasting would always be as fast as possible, regardless of what mode Altirra is currently in.

 

Auto-warp shouldn't be too bad to implement, since I rewrote the speed code to use an OR of multiple flags recently, and now I have an Options panel I can throw random options into. (Options will be the death of me.)

 

The main impediment to making the paste faster, by the way, is not the speed of the Atari: it's the annoying software debounce code in the OS that limits max key rate to ~10 keys/sec. I need to find a way to hack around that. It's slow enough that I can hit it on a real Atari.

 

I miss (may be I just did'nt found it) a State-Save-function, witch generates a state-file. So i can load it again and again or give it to someone or continue after a month...

 

There isn't one at the moment: I've resisted doing a persisted save state feature because save states are very highly dependent upon internals, and I don't want to risk breakage at the moment because of save states pushing corrupted data into the simulation. It's very tricky because everything has to be saved, like interrupts pending in the next two cycles and POKEY timers in flight. The current quick save format has no checking whatsoever, so if anything goes wrong it'll blow up; it really needs checks for hardware configuration, mounted disk and cartridge images, etc.

[flashjazzcat]

I think I ran into a problem with the IDEa flasher failing with the two-bank scheme enabled on V1 emulated hardware. I'll have to see if I can re-enable it.

OK - thanks! This will really help testing, since I'm supposed to be writing an APT BIOS for IDEa.

 

In addition, testing the 512KB version of the SIDE ROM (with SIDE loader starting at bank #32, i.e. in emulated external flash cart space, and SDX in banks 0-31), SIDE loader always appears at boot. Can the system be switched to SDX mode?

 

I'm not familiar with this -- is there a physical switch?

Funnily enough, I'm waiting for Candle to provide more detailed information on how the SIDE Loader actually kicks in. Certainly SIDE operates in two modes - SDX and SIDE Loader, and this is selected via a switch. One might be running SDX, and then flip the mode switch on the side, then press the "Loader" button on top of the unit, press Reset, and be confronted with the SIDE Loader (following a spontaneous reboot). However, the banks occupied by the SIDE Loader (32-63) are the same banks used by the emulated external flash cart, the presence of which I requested early in the design stage. One may replace the Loader with an external cart ROM with appropriate banking logic (the details of which I have somewhere). However, typing CAR on real hardware while in SDX does not run the SIDE Loader. I kind of expected it would, and have emailed Candle for clarification (but he's clearly very busy ATM).

 

To test in Altirra, I flashed the same 512KB compound SDX/Loader ROM to the SIDE banks (I'm waiting for Trub to provide a separate flasher for the emulated cart space, so we don't have to make compound ROMs and reflash the lower banks every time), and rather than booting SDX, Altirra ran the SIDE loader. It's almost as if the SIDE cart is always in "Loader" mode.

[Rybags]

Debounce should only slow down "same key" repetitions.

 

The OS keeps the "previous key", you might get around that by setting it to $FF with each new injected keystroke. Although I guess there is a high chance of overrun (missed inputs).

 

Or you could just monitor the debounce timer, IIRC it counts from 3 to 0, you could detect "3" and set to "1".

[+rdemming]

There isn't one at the moment: I've resisted doing a persisted save state feature because save states are very highly dependent upon internals, and I don't want to risk breakage at the moment because of save states pushing corrupted data into the simulation. It's very tricky because everything has to be saved, like interrupts pending in the next two cycles and POKEY timers in flight. The current quick save format has no checking whatsoever, so if anything goes wrong it'll blow up; it really needs checks for hardware configuration, mounted disk and cartridge images, etc.

 

 

No need to implement save states if you add Turbo Freezer emulation (which already does save states)

 

I'm wondering how "accurate" the save-state should be. The Turbo Freezer is only activated during an interrupt. AFAIK, the Turbo Freezer just saves the last written values to the ANTIC, GTIA, etc. and write them back when restoring the state in addition to the stored memory contents (just the 64KB base memory).

Although there are situations thinkable that this doesn't work, in practice it works for nearly situations I tried. (Freezing during IO goes wrong and I suppose things that depend on Pokey timers might go wrong). Also programs that don't generate an interrupt cannot be freezed but this can be solved by adding a NMI interrupt button. Of course the user is responsible that the correct disk is in the drive and that the same OS is used when restoring a save state. But this might not be an option for an emulator save-state.

 

But loading Turbo Freezer save-states into Altira would be a cool option

 

Robert

[phaeron]

There's actually a Turbo Freezer style save state function already hidden in the emulator: the .dumpsnap command. I added it in order to transplant running state over to a real Atari for testing. It doesn't work very well if ANTIC is in the middle of a frame, though -- turns out that just rewriting the registers isn't enough to restore everything safely if you've got a complex screen running. I'd like to have the kind of save state command that's highly reliable and you don't have to think about.

 

Looking at what's available, I think I could get Turbo Freezer XL/XE emulation in... but that only adds to the TODO pile that threatens to fall on top of me.

 

I implemented two banks on IDEa emulation:

http://www.virtualdub.org/beta/Altirra-2.00-test41.zip

http://www.virtualdub.org/beta/Altirra-2.00-test41-src.zip

 

I had to implement a second RAM bank as well to get the diagnostic tool to recognize the second ROM bank, though. Try it out and see if it works with the updated firmware.

[+rdemming]

Looking at what's available, I think I could get Turbo Freezer XL/XE emulation in... but that only adds to the TODO pile that threatens to fall on top of me.

 

Turbo Freezer emulation would be cool. But I wonder if it really worth the effort since most features of the Turbo Freezer are already in Altirra's debugger.

But maybe it will make Hias very happy because AFAIK he is working on the next generation of the Turbo Freezer and if it is emulated in Altirra, then development/debugging of the firmware would be easier and faster I think.

 

Robert

[Mclaneinc]

SOme working form of save state would be brilliant, if it ever gets added I'll grant Avery 172 virgins, unfortunately I can't promise the will all be female or pretty...

 

Its a rough area!!!

 

Mind you, look at this big softie, even gave in to use my wife's favourite cat as an avatar..

Edited September 29, 2011 by Mclaneinc

[w1k]

Is Altirra support associate file types ATR, XEX? now i must associate it from windows..

and, when i load D2:, then restart Altirra, D2 is empty.. :/

[HiassofT]

Looking at what's available, I think I could get Turbo Freezer XL/XE emulation in... but that only adds to the TODO pile that threatens to fall on top of me.

If you want to go that route (and have that large TODO pile I'd suggest you wait a little bit until I've finished the docs for the new Freezer. Hardware and software are already working, german docs are almost finished, but I have yet to start with the english docs.

 

As usual I'll publish all information, schematics, VHDL and software source, and of course I'd be glad to help you with some detailled background info and testing.

 

Having Turbo Freezer, especially the Cartridge Emulation feature, in Altirra would be great and would help flashjazzcat developing his GUI. I've implemented a nice flash+RAM mode with a 8k (flash or RAM) page at $A000 and 8k RAM page at $8000. The RAM in the TurboFreezer has a battery backup and currently I'm using this feature to store the cartridge emulation config across reboots/powercycles.

 

so long,

 

Hias

[eegad]

So I've used Altirra 1.9 a few times over the past month or so. Very nice piece of work; it's played every game I've thrown at it perfectly. But 2 problems / questions :

 

- I have a maxflash cart burner and would like to use altirra to "preview" carts. The maxflash software has a default setup that works with Atari800WinPlus. I know how to change the application it uses, but there's also a command line, which for Atari800WinPlus is "-xl -cart "%TARGETCAR%". What's the command line to make it work with Altirra??

 

- And secondly, I just tried to play around in the debugger (to try and hack/cheat a game). But it doesn't seem to work for me. I'm running on a 1 year old mid-range desktop (quad core cpu, 8 gig ram, Win 7 Home Premium). As I say, playing games on altirra works perfectly, but when I enable the debugger, the main window on the left is blank (which is where I believe I *should* be seeing the running atari window). The disassembly and registers windows seem to display and function ok. But the console does not respond to any input....I can click and type things in it which echoes to screen, but return/enter doesn't seem to be recognized (if for instance, I type ? and hit return, nothing happens, there is no response in any window). Has anyone else experienced this or have any idea what's wrong???? I also d/l and tried an older version of altirra with the same result.

[Mclaneinc]

To enter commands you have to break into the code via Debug menu/run/break or hit F8, that starts and stops the emulation

[flashjazzcat]

If the display vanishes (which I find it does at times), hit View->Display or Alt+1.

[phaeron]

The equivalent Altirra command line would be: altirra /kernel:xl /hardware:800xl %targetcar%

[Roydea6]

So I've used Altirra 1.9 a few times over the past month or so. Very nice piece of work; it's played every game I've thrown at it perfectly. But 2 problems / questions :

 

- I have a maxflash cart burner and would like to use altirra to "preview" carts. The maxflash software has a default setup that works with Atari800WinPlus. I know how to change the application it uses, but there's also a command line, which for Atari800WinPlus is "-xl -cart "%TARGETCAR%". What's the command line to make it work with Altirra??

 

 

I have been using this for my command line to launch test cartridges with Maxflash Studio:

 

/cartmapper "%targetcar%"

 

quote's are required.

[eegad]

Much thanks for the tips - Alt-1 did indeed get rid of the blank window and bring up the atari display; F8 got the console to respond; and the command line works like a charm for getting maxflash studio to preview with altirra!

[+therealbountybob]

Much thanks for the tips - Alt-1 did indeed get rid of the blank window and bring up the atari display; F8 got the console to respond; and the command line works like a charm for getting maxflash studio to preview with altirra!

I've had to help a couple of people who accidentally toggled the display off - suggestion for future release would be to move it from F1 as perhaps this is too easy to hit by accident - beginners using f2-f4 and ctrl-1 etc might hit this in error...

[phaeron]

I'm not sure what you mean -- there isn't any key that removes the display. Nothing on F1 is related to it, and Alt+1 can only bring up or select the display, not remove it.