Altirra 4.20 released

[phaeron]

3 hours ago, pcrow said:

The fundamental problem with H: is that it is a separate handler from the D: handler, so DOS won't treat it the same, as evidenced by XIO calls being different and copy commands not working correctly.  Trying to shim H: into drive slots while leaving DOS to handle other drives doesn't fix anything.  What it sounds like people are asking for is to have access to the host file system, but have it done through DOS as a virtual drive.  That means instead of an H: handler that is separate from DOS, the solution is a virtual drive that DOS will see and interpret as a disk.

Altirra does support virtual disks, at least for read only access. There are lots of limitations with it compared to H: or PCLink, though:

 

Filesystem limitations, especially with DOS 2. 90K total and 64 files max is tight. Anything beyond that goes into various extended filesystems with varying compatibility.

 

Virtual disks are slow. The H: device supports burst I/O and essentially does DMA; virtual disks have extra overhead even in the best case of SIOV intercept. SpartaDOS X is particularly annoying with its tendency to do direct to hardware I/O unless you either MAP drive letters back to SIOV or have PBI.SYS loaded and use the emulator's PBI intercept.

 

Virtual disks are also pretty complex, especially if handling writes or large files. Altirra has a lot of code to dynamically reuse sectors on a DOS 2 virtual disk and to incrementally present an SDFS filesystem so it doesn't have to preprocess the entire directory tree. It also doesn't currently handle writes.

 

Caching is also a big headache when doing dynamically updating disks. SpartaDOS X needs the boot sector counters updated whenever its cache needs to be invalidated, but this has to be done sparingly as it also resets the current directory of the drive. Track buffering drives are especially annoying because of the need to blip the write protect to invalidate the track buffer, and also handling the drive reading tons of non-frontier sectors whenever it buffers a track.

 

3 hours ago, pcrow said:

I have some vague memory of hearing about something that did something like that before, but I may have been imagining it, or it may already be available and I'm just not aware of it.

Atari Peripheral Emulator (APE) had it.

 

3 hours ago, pcrow said:

From an emulator perspective, I think the ideal solution would be to support external programs that provide a disk image (or any SIO device, for that matter), so the code could be developed independently of the emulator.  This would have the big plus of making the code easy to share with the atari800 emulator (which being a Linux user is my main solution).

There's actually quite a lot of complexity to Altirra's internal disk interfaces, which is the reason I haven't exposed it to the custom device system (you can implement a dynamic disk there, but have to emulate the drive as well). I resolved long ago never to support binary plugins in Altirra based on past experience.

 

There's potential to implement a disk image system over sockets, but there aren't a bunch of scenarios supported there that aren't also supported just by telling the emulator to load a new ATR -- which you can largely already do.

 

Atari800's internal interfaces, IIRC, are more hardcoded into its SIO path. A few of Altirra's modules like U1MB and PCLink were ported over to it in Atari800MacX, but AFAIK haven't managed to make their way upstream.

 

3 hours ago, pcrow said:

[Aside: I keep typing "D:" and having it get converted into a smiley face, so I'm bolding the ":" to avoid that.]

Yeah, that's super annoying. I used to work around that by putting a zero width space in between, but that no longer works with the new forum software since it removes them on edit.

 

[phaeron]

37 minutes ago, reifsnyderb said:

Is there a way to set a segment of non-volatile ram such that it saves the non-volatile to a file so it's available the next time Altirra is ran?  I am asking because I'd like to simulate a RAM disk, on a 1090XL card, and not have to re-load it if I shut Altirra down.  If it currently can't be done, could this be a feature request?  Thanks!

 

Section of .atdevice file code....

 

Segment m4xlram: 
	{
	size: $400000,
	persistence: "nonvolatile",
	init_pattern: $FF
	};

 

Not currently, but I could see adding a write-back mode.

[Tim Stone]

3 hours ago, phaeron said:

As already noted, keyboard conflicts with emulation. Shift+Ins maps to Shift+> (Insert Line) on the Atari keyboard.

 

There are default keyboard shortcuts for these functions, though: Alt+Shift+C and Alt+Shift+V. Bit clumsy, but it's hard to cram everything onto the host keyboard. Even Ctrl+Shift is taken, thanks to its legacy mapping to AltGr on international keyboards. You can, however, remap the copy and paste functions in Tools > Keyboard Shortcuts, as well as the emulation keys in System > Configure System > Keyboard; there probably aren't actually that many times you would need Ctrl+C/V in emulation unless you're working with graphics or printer control codes.

Oh well, I thought it would be easy. I get why this hasn't been done now.  Thanks anyway. I guess I will just keep using the mouse.  Thank you anyway.

[Tim Stone]

Hey Avery, I know this is off topic but where can I find a cartrige version of Altirra Basic version 1.59?  I know the disk based version is on your additions disk, but I can't find the cartridge version.

I want to test some things against Turbo Basic XL and Basic XE. 

[Wrathchild]

28 minutes ago, Tim Stone said:

where can I find a cartrige version of Altirra Basic version 1.59?

 

Can you not just pick this from the System / Configure System... menu?

 

However, quick use of Altirra debugger having booted into basic:

 

Altirra> .writemem c:\cc65\abasic.rom a000 L2000
Wrote A000-BFFF to c:\cc65\abasic.rom

 

Opened the .rom file and then used File / Save Firmeware... / Save Cartridge... to save (with the header) as a .car

abasic.car

Edited September 4 by Wrathchild

[phaeron]

6 hours ago, Wrathchild said:

 

Can you not just pick this from the System / Configure System... menu?

 

However, quick use of Altirra debugger having booted into basic:

 

Altirra> .writemem c:\cc65\abasic.rom a000 L2000
Wrote A000-BFFF to c:\cc65\abasic.rom

 

Opened the .rom file and then used File / Save Firmeware... / Save Cartridge... to save (with the header) as a .car

abasic.car 8.02 kB · 2 downloads

Don't need to do this manually -- Tools > Export ROM Set.

 

Also, if you are in 400/800 mode, File > Attach Special Cartridge > BASIC.

[Tim Stone]

9 hours ago, phaeron said:

Don't need to do this manually -- Tools > Export ROM Set.

 

Also, if you are in 400/800 mode, File > Attach Special Cartridge > BASIC.

Thank you.  I will try to export it. I didn't know that created a Cartridge. 

[Tim Stone]

12 hours ago, phaeron said:

Don't need to do this manually -- Tools > Export ROM Set.

 

Also, if you are in 400/800 mode, File > Attach Special Cartridge > BASIC.

Do you also offer Altirra Extended BASIC?  I haven't seen this, I just knew about the regular basic.  Did you fold them into one? 

 

Also, I guess this will work with anything you have loaded in memory.  I assume I can also rename them to .CAR and it will work too. 

It would be cool to see these unknown features documented for all of us.  Very useful. Gosh....

 

People won't use these features much if they don't know they exist.  Same with ROMs for printers and devices and such.  I just got lucky with google. 

[Tim Stone]

FEATURE REQUEST: ALTIRRA BASIC

 

Sorry, this may not be the right thread, but I wanted to add a feature request that hopefully will be simple for you to do.  It's up to you Avery of course, but check out 

BASIC XE.  See how it indents code like you would today to clearly read it in the screenshot below.

 

I would love to see ALTIRRA BASIC have the same functionality for readability sake.

 

 

I just pasted this code into the emulator that "yetanothertroll" gave me above and I listed it out and it indented the code for me for readability and it makes such a huge difference. 

 

[+yetanothertroll]

1 hour ago, Tim Stone said:

FEATURE REQUEST: ALTIRRA BASIC

 

Sorry, this may not be the right thread, but I wanted to add a feature request that hopefully will be simple for you to do.  It's up to you Avery of course, but check out 

BASIC XE.  See how it indents code like you would today to clearly read it in the screenshot below.

 

I would love to see ALTIRRA BASIC have the same functionality for readability sake.

 

 

I just pasted this code into the emulator that "yetanothertroll" gave me above and I listed it out and it indented the code for me for readability and it makes such a huge difference. 

 

Could you imagine if Atari BASICs were like the TRS-80's where shenanigans like this could actually work? What would your prettyprinter make of this?

EDIT: Part of a sample run

Edited September 5 by yetanothertroll
It's alive! It's alive! Bwahahahahaha!

[phaeron]

1 hour ago, Tim Stone said:

Do you also offer Altirra Extended BASIC?  I haven't seen this, I just knew about the regular basic.  Did you fold them into one? 

No, Altirra Extended Basic is different in a couple of important ways: it's a much larger banked cartridge instead of a replacement for 8K internal BASIC, and it's a superset of Turbo Basic XL instead of a subset of BASIC XL.

 

It's also not quite done. Last version (see first page for the manual):

https://forums.atariage.com/topic/284061-altirra-extended-basic/?do=findComment&comment=4298537

 

1 hour ago, Tim Stone said:

Also, I guess this will work with anything you have loaded in memory.

No, it only saves out the internal ROMs. You can save out any current cartridge with File > Save Cartridge, but that's not useful in most cases where you mounted the cartridge from a file in the first place.

 

1 hour ago, Tim Stone said:

  I assume I can also rename them to .CAR and it will work too. 

It's better to leave them as .BIN. Altirra will detect both formats with both extensions, but this isn't universal. BIN is just the raw cartridge image, CAR contains additional info indicating the type of cartridge.

 

1 hour ago, Tim Stone said:

It would be cool to see these unknown features documented for all of us.  Very useful. Gosh....

 

People won't use these features much if they don't know they exist.  Same with ROMs for printers and devices and such.  I just got lucky with google. 

There's a help file. As for the ROM images, Altirra intentionally doesn't include or require them for main functionality.

 

53 minutes ago, Tim Stone said:

FEATURE REQUEST: ALTIRRA BASIC

 

Sorry, this may not be the right thread, but I wanted to add a feature request that hopefully will be simple for you to do.  It's up to you Avery of course, but check out 

BASIC XE.  See how it indents code like you would today to clearly read it in the screenshot below.

Sorry, can't. There's no room. I'm not sure if you've noticed, but Basic XE is a 16K cartridge while Altirra BASIC is only 8K -- because it has to fit in the same space as Atari BASIC.

 

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.30-test21.zip
https://www.virtualdub.org/beta/Altirra-4.30-test21-src.7z

• Added 825 80-column printer emulation.
• Added 850 printer port.
• Added PDF export from graphical printer output.

825 printer emulation is based on the manual and sample printouts, as the controller firmware isn't available. It should support all of the documented behavior, at least:

 

 

As the 825 is a parallel port printer, you can't add it directly -- a parallel port adapter is needed. The 850 emulation now supports the printer port, and the 825 can be connected to other devices that have printer ports, like the Black Box.

 

PDF export is added as an experiment, though admittedly it has some problems. PDF export itself wasn't too hard, but the PDF file format is less effective at encoding vector geometry than I expected. Each dot has to be encoded with a path with two cubic spline curves, which is a lot more bloated than Altirra's internal dot storage. Worse yet, PDF's mechanisms for changing transforms and reusing objects is also heavy. Deflate encoding helped bring down the size, but it still results in a ~5MB PDF for a few pages. I'm thinking that getting it down further probably requires encoding the dot patterns to a custom embedded TrueType font.

[+DjayBee]

16 hours ago, phaeron said:

Don't need to do this manually -- Tools > Export ROM Set.

 

Since the question about a CAR/BIN of Altirra BASIC comes up every now and then, you might add this hint to Altirra BASIC's entry in the helpfile of the emulator under "Options: Firmware".

[Mclaneinc]

Thanks for the PDF support Avery, you sir are an emulation god, but you knew that already

 

Paul..

[TGB1718]

4 hours ago, phaeron said:

Added 825 80-column printer emulation.

This is nice, however I'm seeing 1 problem, I installed a Printer device "P:"

attached the 825 printer, wrote a quickie BASIC program to test it, I've not use an 825 

printer in the past, but did notice it doesn't respond to Atari EOL (155) so had to send ASCII 13 for a

CR for EOL, however I notice the first character on a line is not printing, see attached. Simple Program

(it does the same even with lines less than 80 characters.

 

This is the printer output, is there something special about the printer that needs to be sent first ?

 

Also if you do anything to the printer from a command line again it needs ASCII 13 for EOL else

you get something like this, I couldn't find a way to change the EOL character.

This id DIR >>PRN: from SDX command line

 

 

 

[drac030]

8 hours ago, yetanothertroll said:

Could you imagine if Atari BASICs were like the TRS-80's where shenanigans like this could actually work? What would your prettyprinter make of this?

Perhaps this:

 

 

[phaeron]

8 hours ago, TGB1718 said:

This is nice, however I'm seeing 1 problem, I installed a Printer device "P:"

attached the 825 printer, wrote a quickie BASIC program to test it, I've not use an 825 

printer in the past, but did notice it doesn't respond to Atari EOL (155) so had to send ASCII 13 for a

CR for EOL, however I notice the first character on a line is not printing, see attached. Simple Program

 

Ah, that's a problem specific to the generic high-level P: device. It isn't doing EOL translation on the raw output like other P: devices do. I set it up that way so Printer (P:) could be used to capture raw output, but it needs an option for EOL conversion. You should see normal output when using one of the other devices that implements a parallel printer port.

 

The reason you lose the character on the next line is that the 825 is a 7-bit printer, and so EOL ($9B) aliases to ESC ($1B).

 

[drpeter]

13 hours ago, phaeron said:

• Added 825 80-column printer emulation.
• Added 850 printer port.
• Added PDF export from graphical printer output.

Hi Avery,

Thanks as always for all your awesome work.

 

While you're on a printer roll, any thoughts about the 1020 printer/plotter?

 

[phaeron]

4 hours ago, drpeter said:

While you're on a printer roll, any thoughts about the 1020 printer/plotter?

The 1020 is difficult as it's an X-Y plotter with text support and there isn't good information on the font. Its controller also has internal ROM, so it's not as easy to dump as an external ROM.

Edited September 6 by phaeron

[Tim Stone]

21 hours ago, phaeron said:

https://www.virtualdub.org/beta/Altirra-4.30-test21.zip
https://www.virtualdub.org/beta/Altirra-4.30-test21-src.7z

• Added 825 80-column printer emulation.
• Added 850 printer port.
• Added PDF export from graphical printer output.

825 printer emulation is based on the manual and sample printouts, as the controller firmware isn't available. It should support all of the documented behavior, at least:

 

 

As the 825 is a parallel port printer, you can't add it directly -- a parallel port adapter is needed. The 850 emulation now supports the printer port, and the 825 can be connected to other devices that have printer ports, like the Black Box.

 

PDF export is added as an experiment, though admittedly it has some problems. PDF export itself wasn't too hard, but the PDF file format is less effective at encoding vector geometry than I expected. Each dot has to be encoded with a path with two cubic spline curves, which is a lot more bloated than Altirra's internal dot storage. Worse yet, PDF's mechanisms for changing transforms and reusing objects is also heavy. Deflate encoding helped bring down the size, but it still results in a ~5MB PDF for a few pages. I'm thinking that getting it down further probably requires encoding the dot patterns to a custom embedded TrueType font.

Thank you for your help Avery!  You are amazing.  I am so thankful for you keeping my first computer alive today.  Thank you for all of your hard work.  I didn't just want to add a thank you on your post, but make a post thanking you as you deserve it.

This is one of the best emulators on Windows.  Thank you for listening to feedback.  

[Tim Stone]

Feature Request (Not urgent) Printer Support:

 

You all remember the Atari Printer that had this ball with letters and numbers only and a ribbon like a typewriter?  I don't remember the name of it, but it was in the style of the 600/800xl.

It was my first printer before I went out an bought the Star Micronics NX-10 Dot Matrix printer.

 

Maybe a True Type font can fix this up, but I loved the typewriter look to it.  It would be cool to have this as it's more of a typewriter look and not dot matrix.

 

I used this printer with AtariWriter, before Paperclip came out.  Yeah, I turn 56 this year and yes this is a new picture on my bio.

[TGB1718]

13 hours ago, phaeron said:

The reason you lose the character on the next line is that the 825 is a 7-bit printer, and so EOL ($9B) aliases to ESC ($1B).

Thanks, I thought it must be something printer specific

 

[phaeron]

20 hours ago, Tim Stone said:

Feature Request (Not urgent) Printer Support:

 

You all remember the Atari Printer that had this ball with letters and numbers only and a ribbon like a typewriter?  I don't remember the name of it, but it was in the style of the 600/800xl.

It was my first printer before I went out an bought the Star Micronics NX-10 Dot Matrix printer.

This sounds like the Atari 1027. It's tougher to emulate this faithfully due to the formed letters, which are more difficult to replicate than just dot matrix patterns, which at worst can be reconstructed by eyeballing. But apparently a much more critical issue is that just about all 1027 print heads have disintegrated due to age, so it's hard to find a reference for the original letter shapes.

[Irgendwer]

5 hours ago, phaeron said:

...so it's hard to find a reference for the original letter shapes.

FYI "Revive1027" uses "Isotype Medium", which is very close to the original shapes.

[Irgendwer]

On 9/6/2024 at 3:29 AM, phaeron said:

The 1020 is difficult as it's an X-Y plotter with text support and there isn't good information on the font. Its controller also has internal ROM, so it's not as easy to dump as an external ROM.

Maybe @ijor could help with a decap?

(I could even donate the controller from the original sharp plotter (same font) if no 1020 controller is in reach...)