Altirra 2.80 released

[bfollett]

Hi all,

 

Phaeron, could I request/suggest a (very low priority) feature - could the "Load cassette tape" feature support a compressed audio type like mp3, as well as wav?

The reason is I'm contemplating trying to make an archive copy of some tapes like the Invitation to Programming series, which will end up with some tiny BAS files, but the low-quality audio speech might run into Gb as WAVs.

 

Thanks for all the work on Altirra as always,

Wes

 

I'm not the developer, but I know MP3 is a lossy file compression, (designed for music) and it takes into account the way humans hear(perceive) music while choosing what to remove from the source. I strongly doubt you would end up with a valid data stream after decompressing the mp3. Perhaps a lossless compression program like WavPack would work if this were to be pursued.

 

Bob

[wesmond]

Hi Bob - that's the point, the MP3 isn't for the data, it's for the fairly low-quality audio speech track that plays in the background from the tape while you do the lessons. The Basic code starts/stops the motor at the right points, and you answer questions as you go. It's probably 4 or 5 hours of that audio over the series. Being able to preserve that, and run it in an emulator is already very cool - but being able to distribute the audio stuff as mp3 would make a download of it a bit more friendly.

[phaeron]

The dangers of storing tape data in MP3 are overstated. MP3 is lossy and tuned for human perception, but it's also got waaaay more bits than it needs to reasonably encode a 600 baud FSK stream.

 

Here's the beginning of a data block in WAV, viewed in Audacity's spectrogram view:

 

 

...and here's the same data block after encoding into MP3:

 

 

The data is still perfectly visible, and in fact the program loads just fine after decoding the MP3. Should MP3 be your choice for storing the data track? No. And you should definitely not re-encode it if you can help it. But by no means are you guaranteed to destroy the data track either, just because you used MP3.

 

That having been said, I'll have to decline on supporting MP3 for now. I'm on board with this idea and would like to have it myself, but I don't want to deal with the hassle of hooking up a compressed format audio decoder at the moment.

 

[wesmond]

No problem, and thanks for considering - maybe one for later!

 

For now, having seen the comment made in 2006 on AtariMania's page for Invitation to Programming 2: "Unlikely to ever feature on an emulator..." - it's pretty cool that Altirra provides a way of using these kind of tapes pretty much as they were intended already,.

[tschak909]

Altirra's tape emulation was precisely the reason I was able to not only decode the tape format used for the Atari Educational System (Dorsett) tapes (reconciling the serialized output with the interpreter code in the debugger), but was able to make new tapes, and test the correctness of the reverse engineered tape format.

 

Thank you, phaeron.

 

-Thom

 

p.s. the code is here: http://github.com/tschak909/eduencode

[ijor]

Implemented the fast/slow switch for Happy 810/1050

Great work as usual. Didn't know there was a fast/slow switch for the Happy 810. It was actually available? Or you just found support for that in the firmware?

 

Note about the Happy Controller ... access to $4000-7FFF toggles Write Protect inversion.

Not very important, and you might be already aware if you checked the schematics, but just FYI. The actual exact behavior depends on the jumpers configuration. IIRC there were three options, but don't remember the details (nobody scanned the Controller's manual yet?). Personally, I always setup the jumpers so that software would never be able to force write enable. Don't remember if that was the default configuration or not. But my paranoia wouldn't let any software by design or by mistake to write to the disk without my explicit permission. LOL

[Shannon]

I can confirm the fast/slow switch on the happy 810. I knew someone who had a happy 810 and it had that switch.

[phaeron]

For now, having seen the comment made in 2006 on AtariMania's page for Invitation to Programming 2: "Unlikely to ever feature on an emulator..." - it's pretty cool that Altirra provides a way of using these kind of tapes pretty much as they were intended already,.

 

Funny... Invitation to Programming was actually the first talkie tape I could get a usable dump of and is the first one I used to test the emulator.

 

Great work as usual. Didn't know there was a fast/slow switch for the Happy 810. It was actually available? Or you just found support for that in the firmware?

 

Not very important, and you might be already aware if you checked the schematics, but just FYI. The actual exact behavior depends on the jumpers configuration. IIRC there were three options, but don't remember the details (nobody scanned the Controller's manual yet?). Personally, I always setup the jumpers so that software would never be able to force write enable. Don't remember if that was the default configuration or not. But my paranoia wouldn't let any software by design or by mistake to write to the disk without my explicit permission. LOL

 

The 810 fast/slow switch is documented as a do-it-yourself mod in the Happy rev.7 manual. I'd only disassembled the 3K firmware, so I was not aware of this mod either until I saw it in the manual. It's pretty weird, with a switch connecting two RIOT port lines and a pulldown resistor, but I wired it up the emulator and... hey, it worked.

 

The different options for the 1050 controller are news to me. The only schematic I have with the switches, the jsobola one, is the one that I found the errors in; I had to use the Smirk 1050 controller schematic to get things straight. I have not seen a Controller manual, but it sounds like the different switch option just moves the inversion after the force high/low switch logic instead of before, which would then allow the firmware to override it. Have to agree with you, I also like having a hard write protect switch that software can't override.

[mr-atari]

I found a small change in debug behavior when using F8.

 

After "c byte value", the color of that byte does change to red.

After you continue with F8 it does.

 

Not a biggie, but it caught my attention.

[phaeron]

Update:

http://www.virtualdub.org/beta/Altirra-2.90-test26.zip

http://www.virtualdub.org/beta/Altirra-2.90-test26-src.zip

 

The full disk drive emulators now allow the drive select to be modified -- which means you can now have multiple full drives emulated now! Caveats: Don't try assigning two drives to the same ID -- it won't work, though not necessarily in the same way that it wouldn't work on real hardware. Emulating multiple drives will use a lot more CPU time, since with 2+ drives the emulator needs to emulate 3 or more CPUs. The drive select also controls which emulator drive slot that the full drive emulator binds to.

 

The support for multiple drives also means that Happy Multi Drive works:

 

 

Just worked for Happy 810 v7, but had to do a couple of fixes for Happy 1050: the Multi Drive software relies on $AFFx banking while the firmware doesn't, and also takes the unusual step of pulling PA6 to control the index pulse rather than using the RIOT.

 

Fixed formatting when emulating 1050 Turbo drives. It was failing because the Write Track command was writing the wrong data to the disk. Turns out the 1050 Turbo firmware is the only firmware that actually verifies the contents of the sectors during a format instead of just that they read.

 

Minor debugger updates: -k option is now documented for .basic_dumpline, st (static trace) now has a -m option to label the starting trace address, and watches now work on coprocessors.

 

[tschak909]

Real happy emulation...this is insane...

 

-Thom

[mr-atari]

I found a small change in debug behavior when using F8.

 

After "c byte value", the color of that byte does change to red.

After you continue with F8 it does.

 

Not a biggie, but it caught my attention.

I have to repeat and correct myself....

 

After "e byte value", the color and value of that byte does change....

After you continue with F8 or F10 it does.

Rather unworkable not seeing what you have changed.

[avanze]

Is there a way to stop Altirra rebooting after attaching a cartridge file?

[Keatah]

Real happy emulation...this is insane...

 

-Thom

All of Altirra is insane.

[fujidude]

All of Altirra is insane.

 

And we're all nuts! Perhaps Albert should rename the forum to "Atari Insane Asylum."

[phaeron]

Is there a way to stop Altirra rebooting after attaching a cartridge file?

 

Not currently, no. Are there special circumstances under which you're looking to do this? Normally this would cause the Atari to crash anyway, unless you've got something blocking the cartridge ROM like a SpartaDOS X cartridge or U1MB. Even in that case, plugging or unplugging a cart live isn't always the nicest thing to do to the hardware -- I blew a 6502 in a C16 once that way. Altirra normally forces a reset as 99% of the time that is needed anyway, but I could be convinced to put in an option.

[Keatah]

Putting in an option like that.. Wouldn't that need a whole separate menu to determine how to handle that nasty situation? Which contacts make contacts first? And in what order? And when in bus cycle? And how does a cart handle respond to all this? Let alone console..?

 

Or could it be idealized into the perfect situation where clock signals are just right, and the address/data bus is just right, and the data suddenly appears to be available with no crashing?

Edited February 14, 2017 by Keatah

[avanze]

 

Not currently, no. Are there special circumstances under which you're looking to do this? Normally this would cause the Atari to crash anyway, unless you've got something blocking the cartridge ROM like a SpartaDOS X cartridge or U1MB. Even in that case, plugging or unplugging a cart live isn't always the nicest thing to do to the hardware -- I blew a 6502 in a C16 once that way. Altirra normally forces a reset as 99% of the time that is needed anyway, but I could be convinced to put in an option.

 

It's mostly due to the "ultra translator" software, a cold reset stops the disk software from working. I think.

[Mclaneinc]

I'm intrigued by where this is going because I'm failing to see why you would use a translator on Altirra unless you were trying to see just how well the translator works in a bid to improve it for real hardware users?

 

?

Edited February 14, 2017 by Mclaneinc

[re-atari]

 

plugging or unplugging a cart live isn't always the nicest thing to do to the hardware -- I blew a 6502 in a C16 once that way

I think you'd have to blame Commodore for this. Back in the 80's friends with a C64 told me similar horror stories, like you should only plug in a joystick when the computer is switched off. Otherwise you'd probably blow a (not socketed) VIA. Clearly a design flaw, as it would only require a few diodes to protect the IC from this kind of damage.

 

re-atari

[Mclaneinc]

Well that and software / hardware like the Pill did not help, sadly as said you CAN do damage and yes protection with diodes SHOULD have been installed at research stage let and well before manufacturing stage but cost and not thinking just how people like to poke and prod new stuff like that just was ignored. Its like the old 'don't stick metal items in to electric sockets, plugs only', it seems common sense but just look at what actually happens and its like the plug socket is some mystical draw for non purpose items

 

Without trying to be rude, its like, if there's a hole something has to go in it regardless of its it right or not.

 

Its how we learn but its rather illogical...

 

Paul..old fart...and poker of electrical sockets as a kid (tried a theory that you could recharge a battery with wires from the socket, and yes, I did electrocute myself briefly as I fell back after the bang and held the wires each in a hand, thankfully the falling ripped the wires out of the socket as well)

 

I was the kid that took things apart with admirable skill I must say but the skill was lost when it came to reassembling the things... My parents were not happy!

Edited February 14, 2017 by Mclaneinc

[fujidude]

I think you'd have to blame Commodore for this. Back in the 80's friends with a C64 told me similar horror stories, like you should only plug in a joystick when the computer is switched off. Otherwise you'd probably blow a (not socketed) VIA. Clearly a design flaw, as it would only require a few diodes to protect the IC from this kind of damage.

 

re-atari

 

JT wouldn't want to spend a few extra pennies for those though.

[Mclaneinc]

Strange man he was, wanted his computers to be taken very seriously yet wanted them as cheaply made as can be, I'm from the old school of 'you get what you pay for' (normally)....

[fujidude]

Strange man he was, wanted his computers to be taken very seriously yet wanted them as cheaply made as can be, I'm from the old school of 'you get what you pay for' (normally)....

 

I'm of the school that you never get more than you pay for, but can certainly get less.

[Keatah]

I think you'd have to blame Commodore for this. Back in the 80's friends with a C64 told me similar horror stories, like you should only plug in a joystick when the computer is switched off. Otherwise you'd probably blow a (not socketed) VIA. Clearly a design flaw, as it would only require a few diodes to protect the IC from this kind of damage.

 

re-atari

 

That's messed up. Most joysticks are simply an array of switches that are normally open. Nothing loops back. One cannot detect whether a standard Atari joystick is connected to a system. Not unless the system has a full complement of TDR circuitry.