Atari++ 1.73 out

[thorfdbg]

Hi folks,

 

a new version of the portable Atari emulator, Atari++, is out for download at http://www.xl-project.com/.

 

What's new this time?

 

Not much changed in the emulator core, actually. I fixed a couple of quirks of the serial protocol, and native support for CAS files and tape emulation. Prior versions supported CAS files through an implicit conversion to disk boot files, which - obviously - did not work so well if the tape boot tried to play some dirty tricks. Drawback of the native tape support is of course that it takes as long as the original to load...

 

For X11 users, Atari++ provides a new X11 output driver using the Xvideo extension of X11. Depending on your hardware, this may improve the smoothness of the play a lot. Specifically, I would highly recommend this output driver for older systems with intel chipset graphics. Modern chipsets or chipsets with less performing xvideo extension (radeon or nvidia) do not profit very much from this.

 

The biggest advantage of the new release is that it comes with an upgraded and completed Os ROM, Os++, in its latest version. This release adds a complete toolchain for Os++, not only the command line driven DOS from previous versions, but also a user customizable DUP menu, a FMS overlay manager that reduces the memory footprint of the DOS to 256 bytes (yes, really), a customized version of DISKIO - a BASIC extension - a RS232 handler, and a disk-based tape handler adding the missing tape support for Os++. The tape handler also profits from the overlay manager and uses no extra RAM if the overlay manager is active. It also provides a "turbo mode" that improves speed a bit.

 

A full manual of Os++, including a memory map, explaining the FMS, the DOS, the DUP menu, Diskio, the tape handler and the improved mathpack is available for download on the same page as well.

 

As usual, sources for all of that are available on the same page, they are part of the Os++ sources. The Os++ system disk providing the tool chain is available there as well if you want to check how all the magic works. You need ca65 and GNU make to built it.

 

In the next days, I will upload the cas2wav and wav2cas files, a pretty robust and less naive implementation of similar tools you find on the internet. Took some signal processing theory to built them - they emulate the analog circuits in the tape driver and do not follow the naive "hands on" approach taken by many other implementations.

 

Have fun,

 

Thomas

 

[kenjennings]

256 byte DOS? AWESOME!

[cyco130]

Thanks for the great software!

 

A few issues with the sources:

• The "atari++_1.73.tar.gz" file has two copies of "winmain.cpp" so there were some extraction problems.
• The newest ld65 requires the -o option to be given before the config file. So I had to manually change the makefile for the OS-Rom sources.
• I don't have the current directory in my search path (like most people?). So I also had to change checksum command to ./checksum

Other than that, awesome as usual! Nevertheless here's a small wish list:

• I love the built-in DOS and the better mathpack in the OS. I flashed it to my Ultimate 1MB and it works pretty well on the real hardware. But a high speed SIO handler would be a great addition. I wonder if it's possible to patch it with hias's hisio patch. Hmm, let's try...
• It works well with aoss but built-in ALSA support would be awesome.

 

EDIT: Nope. Hisio gives "incompatible OS". Rats!

Edited February 24, 2014 by cyco130

[thorfdbg]

256 byte DOS? AWESOME!

256 byte memory footprint. Does not mean the DOS is 256 bytes long. It's actually 3K in size (including FMS and command line), all of which is part of the lower Os RAM in Os++. The 256 bytes are just for the FMS globals and administration information (essentially, FMS versions of the IOCBs for file adminstration). Without the overlay manager, 128 bytes per drive and 128 bytes per open file go on top of this, which still gives an excellent MEMLO of about $C80 in the default configuration.

 

To put this into relation, Dos 2 and variants typically have a MEMLO of around $1C80.

 

Now, what the overlay manager does is to relocate the disk buffers behind the BASIC ROM or behind a Oss switching card, including itself, and including DiskIO, and the Tape handler. Thus, essentially, you can have BASIC (or Mac/65), the Basic extension DISKIO *and* the tape handler that was pulled out from Os++ in RAM, and still have only 256 bytes of precious BASIC RAM stolen. And a ROM-resident DOS menu you can use without loosing your program.

 

That is almost, but not quite my record for Dos 2.XL which had only 193 bytes of BASIC RAM, but then took the RAM behind the Os, conflicting with Turbo BASIC.

[thorfdbg]

Thanks for the great software!

 

EDIT: Nope. Hisio gives "incompatible OS". Rats!

I'll check for winmain. Darn!

 

About the FastSIO: Trouble is that there is *very* little OsROM space left (probably around 16 bytes, order of magnitude.) Thus, if it would be just initializing the pokey register values for a higher SIO transfer rate, this would be fine. However, even though I haven't looked into the high-speed routines myself, I understand that they need to do more than that, namely replace also the SIO IRQ based transfer with CPU driven transfer to get out the most from POKEY, and that takes definitely more than 16 bytes.

 

There is a bit more free space in mathpack (because the original was really in a pretty bad shape), though I was hoping that I would not need to mix Os code into the math pack. The math pack is not quite part of the operating system, even more so as this part can be mapped out on the XL series.

 

How long is the highspeed SIO anyhow?

 

Thus, anyone willing to hunt for more free bytes in the ROMs? Sources are all yours...

[HiassofT]

How long is the highspeed SIO anyhow?

It's huge, almost a full 1k including the keyboard patch, fast VBI code etc. The only possibility to "squeeze" this into the XL OS was to replace the international charset.

 

According to your docs the international charset is available in your OS++, right? So it should be possible to highspeed patch your OS too, I guess.

 

If the locations I hook into (keyboard IRQ code and SIO code) are at fixed locations, I could add support for OS++ into my hipatch (it checks if the code at these locations is actually what it would expect, otherwise you get the "unsupported OS" message).

 

But I guess it would be a lot easier if we would just integrate my highspeed code into your codebase - you could then easily assemble a "stock" and "highspeed" version of your OS and we wouldn't have to care if some parts of your OS move around or change.

 

I'll have a look at when I find some spare time (which is quite limited ATM so this could take a while...). If you'd like to add my code by yourself it'd be best if you sent me an email - my sources are online, but the build process (and also code) is a little bit complex

 

so long,

 

Hias

[kenjennings]

256 byte memory footprint. Does not mean the DOS is 256 bytes long. It's actually 3K in size. . ..

 

You're so humble. Atari++ rocks.

[phaeron]

There is a bit more free space in mathpack (because the original was really in a pretty bad shape)

 

Is the Os++ mathpack based on the Atari OS mathpack?

[thorfdbg]

But I guess it would be a lot easier if we would just integrate my highspeed code into your codebase - you could then easily assemble a "stock" and "highspeed" version of your OS and we wouldn't have to care if some parts of your OS move around or change.

 

I'll have a look at when I find some spare time (which is quite limited ATM so this could take a while...). If you'd like to add my code by yourself it'd be best if you sent me an email - my sources are online, but the build process (and also code) is a little bit complex

 

Sounds like a fine idea to create a branch of Os++ with high-speed SIO patched in by default - this is a much better alternative than to patch in the bytes manually. Thus, if this is acceptable for you, I would be happy to look into your sources and integrate them into the Os++ sources by a compile time switch. My email address is still valid.

[thorfdbg]

 

Is the Os++ mathpack based on the Atari OS mathpack?

The question is, what do you mean by "based"? I do not have the Os source codes, though documents about the call-ins and FP formats. The floating point format certainly is identical, and so are the jump-in addresses, simply for backwards compatibility. This unfortunately results in the drawbacks carried over - as for example slow multiplication and division. Due to size constraints, I could not unroll such loops as TurboBasic does, for example. The code itself is a rewrite, though some low-level methods (such as "move a FP register") are simply the same because there was no better way of doing it. Higher level methods like ascii<->FP conversion or Log/exp are pretty different.

 

Anyhow, the source is all yours, so probably you want to judge yourself whether that is "based enough" or "based too much", depending on your expectations.

[+Larry]

Hi-

 

I wondered about OS++ (OS) just the other day. Hadn't heard from you in a bit. New release -- great!

 

-Larry

[thorfdbg]

Hi-

 

I wondered about OS++ (OS) just the other day. Hadn't heard from you in a bit. New release -- great!

 

-Larry

Thanks for your feed back, though. Would have been harder without it. Yes, it took longer, but it is finally complete.

[lemiel]

Method you used in wav2cas can be used to decode from PWM (pulse-width modulation) encoded Turbo tape files?

Just asking, because there is Turgen available.

[thorfdbg]

Method you used in wav2cas can be used to decode from PWM (pulse-width modulation) encoded Turbo tape files?

Just asking, because there is Turgen available.

The Atari cas tape did not use pulse-width modulation, but a frequency modulation. Decoding that by measuring pulse widths is quite error prone and I would not recommend it. What I use is a set of Goertzel-FFT filters, adjusted for DC-leak removal, and spaced at regular frequency distances. The decoder picks then, according to the initial AA sync byte of the Atari tape signal, the Goertzel FFT pair with the best recognition rate (optimal signal-noise ratio), to compensate for tape speed variations. The filter pair (as present in hardware) is then followed by a comparator that self-adjusts to the signal levels (the comparator is also present in the original hardware). This is followed by a serial decoder pretty much like the circuit in Pokey, where the signal is oversampled and the most likely signal level is then used for decoding.

[lemiel]

No, not standard tapes. Tapes saved with several turbo speeders, which used PWM.

[thorfdbg]

No, not standard tapes. Tapes saved with several turbo speeders, which used PWM.

The answer is simple: I don't support it. It's an entirely different beast, requires a modifed tape recorder and hence non-native hardware. Not that I don't care, but at least I do not care enough to worry at this moment.

[HiassofT]

I did a quick hack to binary-patch OS++ with my highspeed code. It's almost completely untested, I only tried if Atari800 boots with this ROM. Please test it on real hardware.

 

so long,

 

Hias

ospp-hi.rom

[cyco130]

Thanks a lot! It works on real hardware for me (just booted and copied a few files around).

 

Except shift+reset cold start. OS++ probably has something going on with the shift key on warm start. The stock version doesn't boot either until I release it.

 

I did a quick hack to binary-patch OS++ with my highspeed code. It's almost completely untested, I only tried if Atari800 boots with this ROM. Please test it on real hardware.

[thorfdbg]

Thanks a lot! It works on real hardware for me (just booted and copied a few files around).

 

Except shift+reset cold start. OS++ probably has something going on with the shift key on warm start. The stock version doesn't boot either until I release it.

 

There is no keyboard check in either the cold start or the warm start. However, if you go to DOS, or run the CAR command from either the Dos command line or the menu driven DUP, the code will wait until all keys are released. This is intentional - otherwise, the last key press (e.g. the RETURN to send the command to the system) will leak through beyond the reset, causing a second fake "RETURN key" event.

[xxl]

nice...

 

does your DOS supports relocatable binary file?

[thorfdbg]

does your DOS supports relocatable binary file?

There is to my knowledge no accepted standard for relocatable binaries, thus there is no loader in the ROM FMS to support such files (despite, ROM space is limited). However, this being said, DISKIO, the tape handler and the DUP menu are all relocatable by themselves, and thus do not require a fixed memory layout. They all place themselves at MEMLO (or wherever the overlay manager provides RAM) and thus waste no memory whatsoever. That is, the 256 byte memory footprint does not change if you add DISKIO to RAM and use Basic or Mac/65.

 

The DUP menu is different. The DUP menu itself, and all the menu items are relocatable, and use their own format to get relocated. The DUP MENU does have its relocatable loader, to minimize RAM usage, and thus also to customize the DUP menu (and optimize the RAM for the features you really need). The relocatable format used by the DUP is documented in the Os++ manual.

[HiassofT]

Thanks a lot! It works on real hardware for me (just booted and copied a few files around).

Thanks for testing!

Except shift+reset cold start.

I didn't include the shift+reset patch, only the SIO and keyboard patch. For the shift+reset patch I would have needed to change my 6502 code (and replace the quick&dirty shift+reset patch with a proper one), but I didn't have time for that

 

so long,

 

Hias