Altirra 3.00 released

[Mclaneinc]

Thank you for the non drive reset and all the other bits Avery...Dead handy...Edit: and thanks for the shortcut bind...Even better...

 

Edit2: Are there any cons against using a computer reset only? ie I've bound it as my standard reset and added a mouse gesture for the same with Strokeit, obviously I can still just do a normal cold start with Shift F5 but apart from not removing any drive programming is it ok to use 99% of the time?

 

Looked at the code but its beyond me, it looks like its going in an infinite loop but its ages ago since I played and indexed addressing and bit manipulation was something I was only learning and using a tiny bit, and playing with page one stuff, isn't that a no no?

Edited April 30, 2018 by Mclaneinc

[flashjazzcat]

I think drive firmware commonly uses the stack space for RAM.

 

Also on the IS Plate -- if you boot the ISP Lightspeed software and load IS/US Doubler emulation onto the drive, the drive won't respond anymore if the computer is NTSC, due to a bug introduced into the transmit routine by Innovated Software when converting the US Doubler firmware to the I.S. Plate. Spot the bug:

C2EA: 6E 35 01  LC2EA   ROR $0135
C2ED: 90 07             BCC LC2F6
C2EF: A9 01             LDA #$01
C2F1: 0D 82 02          ORA $0282
C2F4: D0 06             BNE LC2FC
C2F6: A9 FE     LC2F6   LDA #$FE
C2F8: 2D 82 02          AND $0282
C2FB: EA                NOP
C2FC: A0 04     LC2FC   LDY #$04
C2FE: 88        LC2FE   DEY
C2FF: D0 FD             BNE LC2FE
C301: EA                NOP
C302: 8D 82 02          STA $0282
C305: CE 34 01          DEC $0134
C308: D0 E0             BNE LC2EA

I assume it's delay related and I'm guessing $0135 contains the data, and I notice that when transmitting "1" the NOP at C2FB is skipped, but executed for a zero.

[phaeron]

The 1050 has page 0 and page 1 mirrored onto the same 256 bytes of RAM -- the firmware has to map its variables around the stack. Fortunately, the 6502's weakness at stack parameter passing means that very little stack is needed... and as a few daring programmers have shown, you can get by with no stack.

 

The NOP isn't the problem, as that's needed to balance the branch timing between 0 and 1 bits. This is the problem:

C2FF: D0 FD             BNE LC2FE

Although it doesn't look like one, that is a page crossing branch. The people who relocated the US Doubler code to the I.S. Plate failed to notice that they had moved the transmit routine to a place where both of its critical loops overlapped a page boundary. This added four cycles per bit to the transmit timing, which changes it from fairly well tuned to way off. Ideal timing is 53 cycles/bit, this does 57... barely viable for PAL and beyond tolerance for NTSC.

 

As for the computer-only reset, it is possible for a drive to get stuck if its in the middle of a command, which could lead to problems on the next boot. Drives often don't have a timeout or recovery mechanism; once they need 128 bytes they'll patiently wait for 128 bytes no matter what, even if the computer long ago gave up on the original command and is trying to get a new command through. But you'd know that pretty quickly.

[Mclaneinc]

Ah, I'd have figured that out if you gave me more time and a brain transplant

 

The serious side is that people like you spot these almost invisible little details which make emulation so good...Hats of to you and Jon for improving the devices we use either real or emulated because both sides can pass on usable info..

 

Oh Phaeron, was just commenting on a new cart in dev and had a possibly silly idea that I'll chuck at you, you know there's carts that Altirra etc does not auto recognise, could there be an add and remember facility based upon the individual chosen cart ie store its crc so that it does not need re-recognising again?

 

Reasons, one, it does away with making a choice so a swifter usage and two, although the 'recommended' option you flag is normally perfectly right there's the odd times when its something else and depending on your recall it can result in going one by one through the options again and again at other times.

 

Most likely sounds lazy but the swifter usage is more what I'm looking at.

Edited May 1, 2018 by Mclaneinc

[flashjazzcat]

Can't seem to get rid of this warning message in test22:

 

 

The Rapidus actually works fine. Here's the firmware:

 

 

As I say: everything appears to work OK.

[Mclaneinc]

Ditto..All works..Error present..

Edited May 1, 2018 by Mclaneinc

[flashjazzcat]

Cannot unfold blocks in the CPU history window in 65C816 mode under Rapidus. No amount of clicking on the plus sign causes anything to happen. I'm not sure this is new, though, so apologies if I already mentioned it.

[Roydea6]

 

Windows 10 has this warning., but Windows 7 with test 22 doesn't show this warning.

 

 

[phaeron]

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

• Fixed certain internal ROMs not being seen as usable firmware, particularly the built-in Rapidus core PBI ROM.
• Fixed execution history tree expand buttons not working when the pane had been scrolled horizontally.

Oh Phaeron, was just commenting on a new cart in dev and had a possibly silly idea that I'll chuck at you, you know there's carts that Altirra etc does not auto recognise, could there be an add and remember facility based upon the individual chosen cart ie store its crc so that it does not need re-recognising again?

The compatibility list can do some of that, although currently it only supports a couple of 5200 mappers. A more basic issue is that Altirra currently doesn't have a good place to store bulk data; it only uses the Registry, which is not a good place to store a lot of info. But I could see making the compatibility list auto-updating for that reason.

That having been said, when I was originally populating the built-in list for 5200 carts there was a pretty obvious issue with remembering the cart mappers, which is that you don't know at the time that the mapper is chosen whether your choice is actually correct -- you only know after the cart's run successfully. That means a mechanism like this has to be a "did it work?" thing that happens after the mapper selection.

Windows 10 has this warning., but Windows 7 with test 22 doesn't show this warning.

 

I don't see issues with the firmware check logic for SIDE/SIDE 2. Do you have a firmware image set up for SIDE 2 in the Firmware Manager or are you just binding a CompactFlash card and loading a driver or other IDE-based software another way? This warning shows up if your SIDE has no firmware image or the firmware is totally blank.

 

[Mclaneinc]

Hi Avery, thanks for the fix..

 

Was talking to tmp in his thread re his new cart and he (as you may have seen) suggested CAR files as the way to go which indeed saves all the hassle as they are predetermined, totally sensible to me. As for the storing of data, it sounds like it would be a royal pain as the most logical way would be to store it in the Altirra root. Also I'd imagine you want as little outside data apart from firmware and bare essentials needed just to keep it fluid / timed as close as possible..

 

Then again, I am to emu writing what Donald Trump is to being subtle..

[flashjazzcat]

• Fixed certain internal ROMs not being seen as usable firmware, particularly the built-in Rapidus core PBI ROM.
• Fixed execution history tree expand buttons not working when the pane had been scrolled horizontally.

Many thanks. I didn't make the connection between horizontal scrolling and the inability to unfold code blocks, unfortunately.

 

Only thing I'm noticing now (and I'm not sure this is new, since I've only been fiddling with Rapidus again for a couple of days) is that reset always causes an OS reboot when Rapidus is set to 6502 mode (at least when U1MB is present). 65C816 mode (using U1MB stock OS or Rapidus OS) works just fine.

Edited May 2, 2018 by flashjazzcat

[flashjazzcat]

Another Rapidus oddity. DracOS's HISEGM (0x024E) value is 0 on a cold boot and only takes on the value of the last segment of linear RAM (0xEF) after the first warm reset.

[phaeron]

Only thing I'm noticing now (and I'm not sure this is new, since I've only been fiddling with Rapidus again for a couple of days) is that reset always causes an OS reboot when Rapidus is set to 6502 mode (at least when U1MB is present). 65C816 mode (using U1MB stock OS or Rapidus OS) works just fine.

 

Can't reproduce the HISEGM issue, but for this one -- can you do a test for me on the real hardware? Enable PBI#0 by writing $01 to $D1FF, map flash to $4000-7FFF by writing $10 to $D190, then turn off PBI#0 with $D1FF=$00 and check if $4000-7FFF changes. What looks like is happening is that the 8-bit PBI firmware is leaving the flash ROM mapped when returning from its init, and I'm suspecting that the 6502 flash window is supposed to be gated by the PBI#0 enable. I'm guessing that the $D190 register is probably also supposed to be turned off.

[Qetzlcoatl]

Altirra now has a great feature to create different Profiles and easy switch between them.

So my question. Does any way exist to export profile on one PC and import it on another?

Thanks...

[flashjazzcat]

 

Can't reproduce the HISEGM issue, but for this one -- can you do a test for me on the real hardware? Enable PBI#0 by writing $01 to $D1FF, map flash to $4000-7FFF by writing $10 to $D190, then turn off PBI#0 with $D1FF=$00 and check if $4000-7FFF changes. What looks like is happening is that the 8-bit PBI firmware is leaving the flash ROM mapped when returning from its init, and I'm suspecting that the 6502 flash window is supposed to be gated by the PBI#0 enable. I'm guessing that the $D190 register is probably also supposed to be turned off.

 

No change to $4000 when performing this test on real hardware, so it looks like flash ROM silently vacates $4000-$7FFF as soon as the PBI device is deselected. Double-checked HISEGM while I was at it and it's 0xEF on a cold power-up.

[Mclaneinc]

Altirra now has a great feature to create different Profiles and easy switch between them.

So my question. Does any way exist to export profile on one PC and import it on another?

Thanks...

 

Unless you are in portable then Altirra uses the registry to store its settings, if you use Regedit in Windows and go to current_user and then expand until you see Software, find VirtualDub in the list, expand it to Altirra, and in there is a Profiles folder, right click on it and create a key and save it and then you can export it to another PC, the same can be done for individual profiles inside that folder. If you are in Portable mode then the Altirra.ini file contains the same info as the registry so its just a cut and pate job..

 

Be careful with using Regedit, it can do great damage if the wrong things are played with, if you follow what I have written then it will be fine..

 

Maybe Avery will add an export / import option if its easy at some point but normally Avery aims to fix bugs and strive for better performance but spoils us with little presents in the form of additions from time to time..

[flashjazzcat]

Just tested Altirra OS on real hardware (600XL, U1MB, SIDE2) and noticed something rather interesting.

 

Stock XL/XE OS:

 

 

Altirra OS:

 

 

Not sure if Avery's OS is smoking the stock OS by getting in and out of the PBI handler more quickly, or whether it's the Volkswagen of A8 operating systems.

 

[tschak909]

oh no you didn't

 

-Thom

[flashjazzcat]

Correct: Volkswagen. Timer is off on PAL hardware. No speedup on NTSC.

[Keatah]

Altirra now has a great feature to create different Profiles and easy switch between them.

So my question. Does any way exist to export profile on one PC and import it on another?

Thanks...

 

Not really. You'll be able to transfer configurations/profiles/setups between machines if you work entirely within portable mode. But you will have to start over and recreate your configurations in portable mode. This way you can specify all kinds of .ini files and move them at will with a simple drag'n'drop file copy op. You can even lock them with "read-only" to set them in stone!

 

The Contents and Command-Line Help section of the HELP dropdown explains how it works in more detail.

 

Other way is is import/export using the registry. A choice I don't necessarily recommend because of risk of messing up other stuff if a mistake in command syntax is made.

[phaeron]

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

• Rapidus low flash window is now tied to PBI enable and 6502CR is no longer cleared on warm reset.
• Fixed a bug with the Shift key state sometimes getting out of whack on boot in full raw keyboard scan mode. This was a particularly problematic with the stock Rapidus PBI flash, which interprets any key held down as a request to go to 6502 safe mode.
• Placeholder "you have no Rapidus OS" ROM was crashing sometimes due to having crap in standard vector locations.

Note that warm reset still won't work with the 6502 safe mode in Rapidus -- as far as I can tell, the 8-bit PBI flash doesn't have a provision for handling this and always overwrites low memory. 6502C mode enabled through the setup menu should work.

Not sure if Avery's OS is smoking the stock OS by getting in and out of the PBI handler more quickly, or whether it's the Volkswagen of A8 operating systems.

Check which version of AltirraOS you have on that machine -- this should have been fixed in 2.90 final and above. RWTEST.COM relies on exact values of PALNTS and I fixed the PAL value from $FF to $01 in that version.

 

The comparison is rather unfair, btw. My emulator doesn't run on pee.

[Mclaneinc]

ROTFL...

[flashjazzcat]

Check which version of AltirraOS you have on that machine -- this should have been fixed in 2.90 final and above. RWTEST.COM relies on exact values of PALNTS and I fixed the PAL value from $FF to $01 in that version.

My apologies: this is bound to be the cause. The Altirra OS ROMs lying around on the virtual drive and those flashed to my U1MB are probably not recent.

 

The comparison is rather unfair, btw. My emulator doesn't run on pee.

[Mclaneinc]

Post to anyone who cares to look..

 

Been playing with the CAR files that kindly got posted and I came back across a set of Turbosoft carts which mostly work fine but there's a lump of programs that fail, I've searched about turbosoft with no issue reports of much meaning, can someone tell why certain titles are failing to work, I've set to PAL as its a euro cart, I've set to XL and various memory, tried various memory init tricks and looked at what I thought were the most obvious possible things..

 

So I'm left with 2 thoughts, 1. the carts were created with duff images and not tested or the cart process spoiled them, or 2, that the Turbosoft emulation is possibly off, now that is very low on my list of what if's as Avery's coding of cart support has always been sound...

 

Anyone...

 

I also tested the original roms through all other mappers with one other running the cart but similar issues....Tubosoft seemed the best choice for obvious reasons..

 

Here's the rom...and the car for completeness..Remove the TXT as its the only easy way to up it here..

 

 

C1.ROM

C1.car.txt

[Wrathchild]

Just a quick test with the first title on the cart Basketball, the cart itself seems to need an XL/XE O/S to run to the menu but this title loads some code into page 6 which is then making a direct O/S call to a 400/800 address ($F3F6) and hence the crash. Some other titles fire up and others crash. Sticking a translator disk in drive-1 doesn't help.