Altirra 4.20 released

[phaeron]

15 hours ago, Tim Stone said:

Yes, sorry.  It's been awhile.  Okay... So what method do you think would work the best?  What you have now?  Is there any way you can improve on it that makes sense?

To be honest... I don't know if trying to stack Hn: into D5-D8: would have any real advantages given the difficulties. Anything that supports accessing the host device through D5-D8: would be able to access it under the regular H: device name as well without the downsides. So right now, I'm not sure the option's worth it right now.

 

15 hours ago, Tim Stone said:

  1) Printing of ATASCII CHARACTERS.  Right now it doesn't offer this as far as the printers that I tried. I have all four that you had implemented.

As noted already, this depends on the printer model, and the printer emulations follow what the actual printers did. (The full emulators do also too, but more directly because they literally run the original printer firmware.) For some reason, Atari was in the habit of shipping their printers with the ASCII character set instead of the ATASCII character set. Or, even more oddly, a mix of the two.

 

The 820 offers only ASCII characters, except inexplicably only up and left arrows in sideways mode. Not sure what use up and left arrows are without down and right arrows.

 

The 1025 and 1029 have a couple of ATASCII characters, but only the ones provided by the international ATASCII character set.

 

So there's no printer model that Altirra supports that actually had any appreciable number of ATASCII special characters. That leaves the P: device, which is just a high-level device that isn't tied to any specific printer model. It could have an option for ATASCII output, I suppose, which might be useful for listings. But one obstacle I've run into in the past is that any such usage would probably want to include inverse text, and I've never found any widely usable convention for representing inverse text. I could display it, but without being able to copy it, it wouldn't be much use. So having an idea of what you'd want to use ATASCII output for would be helpful.

 

15 hours ago, Tim Stone said:

  2) Paper size support when printing.  Right now its just one paper and it keeps printing and doesn't allow me to do pages like on a PDF.  I have to sort this out manually for 8.5 x 11 paper, it would be nice to have different sizes of paper emulated.

What other paper sizes did you have in mind? The printers don't support arbitrary paper widths; the 820, for instance, only accepts narrow roll paper, you can't get A4-size paper into it unless you fold it or apply a hacksaw to the printer. You could put narrower paper in a 1025 or 1029, but without firmware support the printer would happily print right off the edge of the paper and onto the platen. I suppose there's legal-size paper (8.5x14"), but not sure the point...?

 

There's another reason I don't support pagination right now, which is avoiding the need for controls for aligning the page vertically. It's doable, just extra UI work that I wasn't sure was worth it. But technically there's nothing preventing it.

 

PDF output is possible -- writing a PDF is a lot easier than reading it -- but it'd require pagination first. Also, the PDF would have raw dots instead of characters. Probably not too much of an issue, but it'd depend on PDF engines being able to render it at a reasonable speed. Acrobat would probably be OK, I have had problems with pdf.js being slow at rendering some complex PDFs. The alternative would be to vectorize the shapes, which is doable but a giant 2D boolean operation.

 

15 hours ago, Tim Stone said:

  3) More support than just PNG, maybe multipage PDF support would be possible with a library added in.

As noted above, I think PDF is doable, but I'm not going to pull in a library for it.

 

15 hours ago, Tim Stone said:

  4) EPSON Dot matrix printer support so I can just run Printshop without having to load in a driver first.

I've thought about FX-80 emulation as I'm familiar with it, but it'd take a bunch of work since the Epson printers have way more complex features than regular Atari printers. The FX-80 has something like five different graphics modes alone, much less bidirectional printing, italics, multiple font subsets, etc.

 

The MX-80 is another alternative, as apparently someone's dumped the firmware for it -- but it uses some oddball MCU and I'm not as familiar with the MX-80. But that route would allow for full emulation, which makes it easier to match the actual printer. I don't have any dot matrix printers and no desire to relive the weight, noise, and horrors of pinfeed paper.

 

15 hours ago, Tim Stone said:

  5) When you start printing the Printer Output box can pop-up automatically so you don't miss your printing.  I forgot to do this and I lost half of my print this way.

I'm not a fan of automatically popping up panes on print, but I have been thinking of trying to store the print output centrally so it doesn't disappear when the printer pane is closed. This means you could accumulate an awful lot of printing in the background, but I'll have to check the memory usage as it might not be too bad. In graphical mode, the printout is stored as lines of dots, so it's more than the original characters, but still a lot more compact than an image (and is why you can zoom in a lot on the printout). So storing 100 pages or so might not be too bad.

 

[Tim Stone]

2 hours ago, phaeron said:

To be honest... I don't know if trying to stack Hn: into D5-D8: would have any real advantages given the difficulties. Anything that supports accessing the host device through D5-D8: would be able to access it under the regular H: device name as well without the downsides. So right now, I'm not sure the option's worth it right now.

 

Okay, so exactly how does that checkbox work where it says "Also install as D"?  I guess I am not understanding how this works exactly.  

Thank you for your honesty.  If it's too much work and not for the effort that is fine.  I just still at a loss what that checkbox does.

 

 

2 hours ago, phaeron said:

 

As noted already, this depends on the printer model, and the printer emulations follow what the actual printers did. (The full emulators do also too, but more directly because they literally run the original printer firmware.) For some reason, Atari was in the habit of shipping their printers with the ASCII character set instead of the ATASCII character set. Or, even more oddly, a mix of the two.

 

The 820 offers only ASCII characters, except inexplicably only up and left arrows in sideways mode. Not sure what use up and left arrows are without down and right arrows.

 

The 1025 and 1029 have a couple of ATASCII characters, but only the ones provided by the international ATASCII character set.

 

So there's no printer model that Altirra supports that actually had any appreciable number of ATASCII special characters. That leaves the P: device, which is just a high-level device that isn't tied to any specific printer model. It could have an option for ATASCII output, I suppose, which might be useful for listings. But one obstacle I've run into in the past is that any such usage would probably want to include inverse text, and I've never found any widely usable convention for representing inverse text. I could display it, but without being able to copy it, it wouldn't be much use. So having an idea of what you'd want to use ATASCII output for would be helpful.

 

Okay, so what I am trying to do is take old BBS programs that have games on them like Carina 2 with Zenobia (and others) and take them and translate them to web based HTML5/JavaScript/PHP/MySQL database driven but still keep the ATASCII look to it by using an Atari 8-bit font that I can translate ATASCII over to this newer font that simulates ATASCII but using a TrueType font.  So, BASIC as you know is tokenized and I want to print this out on paper from tokenized to ATASCII.  This is what I am trying to do.

 

So take these and make them into a game like Hobowars (if any of you remember this web based online multiplayer game)

 

2 hours ago, phaeron said:

 

What other paper sizes did you have in mind? The printers don't support arbitrary paper widths; the 820, for instance, only accepts narrow roll paper, you can't get A4-size paper into it unless you fold it or apply a hacksaw to the printer. You could put narrower paper in a 1025 or 1029, but without firmware support the printer would happily print right off the edge of the paper and onto the platen. I suppose there's legal-size paper (8.5x14"), but not sure the point...?

 

There's another reason I don't support pagination right now, which is avoiding the need for controls for aligning the page vertically. It's doable, just extra UI work that I wasn't sure was worth it. But technically there's nothing preventing it.

 

For me I am wanting to page out the basic programs and I need the ATASCII printed as well and I can then have them on different pages to help organize the BASIC code.  I would prefer 8.5 x 11 sized pages so that would be LETTER.  LEGAL isn't needed.  It's just a lot less work of trying to cut everything up and creating a PDF out of it.  It would be nice to at least have that option if anything.  You don't technically need other paper sizes if it requires too much work.  But it would be nice to at least have 8.5 x 11 as an option.

 

2 hours ago, phaeron said:

 

PDF output is possible -- writing a PDF is a lot easier than reading it -- but it'd require pagination first. Also, the PDF would have raw dots instead of characters. Probably not too much of an issue, but it'd depend on PDF engines being able to render it at a reasonable speed. Acrobat would probably be OK, I have had problems with pdf.js being slow at rendering some complex PDFs. The alternative would be to vectorize the shapes, which is doable but a giant 2D boolean operation.

 

As noted above, I think PDF is doable, but I'm not going to pull in a library for it.

 

Okay, however you want to do it is fine by me.  I just want to save them as PDF Files and be able to print them when needed.  Imagine having a PDF for each basic file and you can print as needed.  So, this is why I thought with 8.5 x 11 pages and PDF output it would help what I am working on with Zenobia's Basic modules.  You could have Zenobia_City_Basic.pdf, Zenobia_Dungeon_Basic.pdf, etc....  Then as I page through each one I can then see them in Atascii and see what I need to do to output them in HTML5/JAVASCRIPT/PHP & MySQL.

 

2 hours ago, phaeron said:

 

I've thought about FX-80 emulation as I'm familiar with it, but it'd take a bunch of work since the Epson printers have way more complex features than regular Atari printers. The FX-80 has something like five different graphics modes alone, much less bidirectional printing, italics, multiple font subsets, etc.

 

The MX-80 is another alternative, as apparently someone's dumped the firmware for it -- but it uses some oddball MCU and I'm not as familiar with the MX-80. But that route would allow for full emulation, which makes it easier to match the actual printer. I don't have any dot matrix printers and no desire to relive the weight, noise, and horrors of pinfeed paper.

Yeah, whatever EPSON works for you.  As long as I can go into PRINTSHOP and NEWSROOM and print without drivers, I am good.  It's your choice here.

 

2 hours ago, phaeron said:

 

I'm not a fan of automatically popping up panes on print, but I have been thinking of trying to store the print output centrally so it doesn't disappear when the printer pane is closed. This means you could accumulate an awful lot of printing in the background, but I'll have to check the memory usage as it might not be too bad. In graphical mode, the printout is stored as lines of dots, so it's more than the original characters, but still a lot more compact than an image (and is why you can zoom in a lot on the printout). So storing 100 pages or so might not be too bad.

 

 

  Yeah, this will work.  I am not picky.  I just want it to work without having me immediately bringing up the printer display window, because sometimes I forget and it was a waste of an effort if you know what I mean.

 

   Thank you for your help Avery!!  You are amazing.  Heading down to the bay area on the 11th of September to help someone with a medical problem.

 

 

Edited August 30 by Tim Stone

[phaeron]

36 minutes ago, Tim Stone said:

Okay, so exactly how does that checkbox work where it says "Also install as D"?  I guess I am not understanding how this works exactly.  

Thank you for your honesty.  If it's too much work and not for the effort that is fine.  I just still at a loss what that checkbox does.

What that checkbox does is install the host device as Dn:. It's meant to act as a pseudo-DOS to run programs that need to access data files from disk, without actually having to boot DOS or make a disk image. It can't be used when booting DOS since the two D devices would conflict and only one of them would work.

 

36 minutes ago, Tim Stone said:

Okay, so what I am trying to do is take old BBS programs that have games on them like Carina 2 with Zenobia (and others) and take them and translate them to web based HTML5/JavaScript/PHP/MySQL database driven but still keep the ATASCII look to it by using an Atari 8-bit font that I can translate ATASCII over to this newer font that simulates ATASCII but using a TrueType font.  So, BASIC as you know is tokenized and I want to print this out on paper from tokenized to ATASCII.  This is what I am trying to do.

 

So take these and make them into a game like Hobowars (if any of you remember this web based online multiplayer game)

If you want to be able to get an accurate listing of such a program for direct porting, the printer device is probably not what you want -- you're better off list doing a LIST "H:PROGRAM.TXT" to dump the raw ATASCII BASIC listing to a file, so it can then be converted into HTML + Unicode for display. This particularly would allow mapping all special and inverse characters properly (whether it be inverse characters in the font or an inverse video CSS style).

 

If you want to get a listing for reference purposes, then there's not a great way in the emulator to do so currently. You can get a bigger screen by enabling enhanced video mode, or get a listing of the program without ATASCII characters and inverse video using the printer. The debugger can also dump BASIC programs from bytecode, but it will print special characters as hex escapes. There are some third-party GUI programs that can display ATASCII files using a representative font that you could apply to listings dumped to the H: device.

 

There is a way to do to this old-school, the way it would have actually been done back in the day: hook up a 1029 Programmable Printer, install 10-Print to print the genuine Atari 8x8 font using the 1029's graphics mode, and then do a LIST "P:". Then be prepared to wait a long time as the emulated system slowly hammers out one line of text-as-graphics at a time through the simulated 1029 as it would have on the actual hardware....

 

[+DjayBee]

This is will probably get close to what you want to do. It can create PNGs or UTF-8 renderings of ATASCII text.

https://pvbestinfoo.github.io/atari8-bit_rom_image_file_explorer.html

 

You can get more information on it from this post

https://forums.atariage.com/topic/306909-atr-image-explorer-browser-based-disassembler-for-atari-bas-xex-atr-and-other-files/?do=findComment&comment=5336940

 

Another option would be to use FujiNet PC which should be able to print to PDFs. I did not try it yet but the real hardware FujiNet can do and this is a straight implementation for PCs.

https://github.com/FujiNetWIFI/fujinet-pc/releases/tag/release-2312.2

 

[_The Doctor__]

XMM801 certainly did,

1025/1029 (can't remember which had one Run at manufacture that had Atascii, Best or B&C delineated and mentioned which did and did not when selling them-If they still have one or the ROM image that might be cool)

Third party OkiData color thermals had the chars and an interface card.

HP allowed font downloads and Rom Packs as did later Epson.

The industry work horse Epson 80's seems like the place to start, then XMM801. In fact edit of XMM801 rom to respond to Epson esc sequence was once done and was a delight to avoid patching some software. If it isn't still hanging around as a hack, maybe that option also would be helpful? Just some ideas as Atascii print out as native to the printer is much faster as the computer doesn't have to use up memory and horse power to do so.

[+yetanothertroll]

But programming a utility to print files using the default OS font, the currently loaded font in RAM, or perhaps even a font file from disk, might be a fun project 😁

[Tim Stone]

I do have a question about screen size. 

 

I want to get a full 4:3 image and not widescreen or 16:9, but my Atari 8-bit screen doesn't take up the entire 4:3 emulated screen.  I am using Basic XE here for an example....

If you full screen this image, you will see it doesn't take up the entire 4:3 TV screen and is only a portion of the screen.  How can I get a full 4:3 screen like I could on my old color TV back in 1984?

 

I still want to keep the scan lines to make it more authentic as well. 

 

[+yetanothertroll]

27 minutes ago, Tim Stone said:

I do have a question about screen size. 

 

I want to get a full 4:3 image and not widescreen or 16:9, but my Atari 8-bit screen doesn't take up the entire 4:3 emulated screen.  I am using Basic XE here for an example....

If you full screen this image, you will see it doesn't take up the entire 4:3 TV screen and is only a portion of the screen.  How can I get a full 4:3 screen like I could on my old color TV back in 1984?

 

I still want to keep the scan lines to make it more authentic as well. 

 

There's a built in border area around the "playfield" where the sprites would probably be visible, depending on how you adjusted your TV

[Tim Stone]

2 hours ago, yetanothertroll said:

There's a built in border area around the "playfield" where the sprites would probably be visible, depending on how you adjusted your TV

 

Okay, so you are saying this was normal?  I thought I remember a larger screen.  I have a 27 inch PC monitor that I use it on today with the scan lines active.  Mind you this was 1984 to 1993 when I gave my Atari 8-bit away as I moved to the PC exclusively at that point.

[Tim Stone]

20 hours ago, DjayBee said:

This is will probably get close to what you want to do. It can create PNGs or UTF-8 renderings of ATASCII text.

https://pvbestinfoo.github.io/atari8-bit_rom_image_file_explorer.html

 

You can get more information on it from this post

https://forums.atariage.com/topic/306909-atr-image-explorer-browser-based-disassembler-for-atari-bas-xex-atr-and-other-files/?do=findComment&comment=5336940

 

Another option would be to use FujiNet PC which should be able to print to PDFs. I did not try it yet but the real hardware FujiNet can do and this is a straight implementation for PCs.

https://github.com/FujiNetWIFI/fujinet-pc/releases/tag/release-2312.2

 

I did check it out for Binaries, but not yet text.  I would rather have it in text format instead of pulling out a PNG of it.  Not fond how they used Javascript instead of writing an executable, so I asked chatGPT to give me help and I turned it into an executable.

[phaeron]

3 hours ago, Tim Stone said:

I want to get a full 4:3 image and not widescreen or 16:9, but my Atari 8-bit screen doesn't take up the entire 4:3 emulated screen.  I am using Basic XE here for an example....

If you full screen this image, you will see it doesn't take up the entire 4:3 TV screen and is only a portion of the screen.  How can I get a full 4:3 screen like I could on my old color TV back in 1984?

 

I still want to keep the scan lines to make it more authentic as well. 

 

This issue is called "overscan" and it varies by TV set. In the View menu, there are options to change the overscan amount used by the emulator. The default is Normal, which displays 224 scanlines. You can change it to OS Screen to reduce it to the 192 scanlines displayed by a standard OS screen, though some custom screens will be cut off.

 

Recent versions of the emulator also have pan-and-zoom options for fine tuning the position and scale of the screen. They are accessible from Video > Video Frame, and you can also use Alt+wheel and Alt+Middle Drag to tweak the screen as well. This just modifies the view on top of the overscan options, so you should start with the overscan setting first and then fine tune the display if needed.

[Tim Stone]

1 hour ago, phaeron said:

This issue is called "overscan" and it varies by TV set. In the View menu, there are options to change the overscan amount used by the emulator. The default is Normal, which displays 224 scanlines. You can change it to OS Screen to reduce it to the 192 scanlines displayed by a standard OS screen, though some custom screens will be cut off.

 

Recent versions of the emulator also have pan-and-zoom options for fine tuning the position and scale of the screen. They are accessible from Video > Video Frame, and you can also use Alt+wheel and Alt+Middle Drag to tweak the screen as well. This just modifies the view on top of the overscan options, so you should start with the overscan setting first and then fine tune the display if needed.

Okay, thank you that works great.  Okay, some screens get cut off?  Can I do it a little lower so that other screens won't get cut off?

[phaeron]

1 hour ago, Tim Stone said:

Okay, thank you that works great.  Okay, some screens get cut off?  Can I do it a little lower so that other screens won't get cut off?

There's no overscan setting in between, so you'd need to use Normal and then zoom in a little bit.

[Tim Stone]

19 minutes ago, phaeron said:

There's no overscan setting in between, so you'd need to use Normal and then zoom in a little bit.

I guess it's not possible to auto-detect this on the fly?  It would be nice to have both worlds.  I tried the OS Overscan and it's wonderful.  It feels like old times again. 

 

I love this stuff more than I should. I love this emulation stuff, I get to relive the 1980s and the 1990's with Dos-Box X and even play the Amiga that I skipped all those years ago. My favorite thing using modern day computers. 

[phaeron]

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

• AltirraOS 3.42: P: device in XL/XE/XEGS build now supports different printer device units, and fixed invalid orientation values being passed to the printer.
• ANTIC: Added emulation of DMACTL-based abnormal DMA condition.
• ATBasic 1.59: Fixed AUX2 not being set up for print I/O, which also affects printer orientation.
• Cassette: Fixed framing errors not being reported.
• Input: Holding down Alt between pressing and releasing an input key no longer results in that input getting stuck on.
• Printer: Printer outputs are now held separately from the printer pane.
• Simulator: Added support for rewind recording.

The graphical printer output storage has been reworked to take less memory, so keeping long printouts shouldn't be an issue -- it now only takes 8 bytes per column of pins printed. Printer output is now also stored per printer output, so if you have multiple printers, each printer will get its own output. However, the UI doesn't currently let you see the other printer outputs until you remove the primary one.

 

Rewind recording is the big new thing in this test release. It is disabled by default due to slight overhead, and enabled in System > Configure System > Speed. Once this is enabled, the emulator will automatically take snapshots every second, which can be returned to by the Quick Rewind command (System > Rewind > Quick Rewind). By default, this will rewind to between one half and 1.5 seconds back, and repeating in quick succession will rewind farther back. The emulator stores up to 20 rewind saves and the ones farther back are spaced farther apart, so it is possible to rewind up to a few minutes. This command is keyboard bindable through the usual methods (Tools > Keyboard Shortcuts or right-clicking on the menu option) and it is also controller bindable.

 

The second Rewind... command brings up a menu showing the available rewind states, allowing manual selection between them:

 

Enter rewinds back to the selected state, and Esc cancels out. This menu is also controller bindable, but it takes some effort: the console controller has to be set up in the input map with the various UI navigation bindings, which aren't set up by default.

 

As this is based on the save state infrastructure, the usual caveats apply -- this will only work safely with things that are currently saved in save state, so not all devices will save/restore properly. It will avoid taking snapshots during disk activity, but I also don't recommend rewinding past disk writes. As with save states, rewind will not roll back disk images, which can be problematic or not problematic based on the running program/DOS.

 

When warp speed is enabled, the snapshot rate will throttle to 1 per real second, so as to avoid slowing down the warp. However, this does mean that the snapshots will be spaced farther apart in simulation time.

 

Sadly, this feature isn't enough to make the official release of Jet Set Willy playable, though it does allow for seeing more of it. For the excellent 2007 unofficial remake, it allows you to save Willy from death loops.

 

Currently rewind is instant, which can be problematic if the rewind snapshot is in a dangerous spot. This is why the rewind menu exists, so you can see what you're going back to, but it can still be pretty hairy to jump back in a fast game like River Raid. I'd like to put in a transition so you have time to react after the rewind, but that'll take some work to integrate into the main loop.

 

[Tim Stone]

3 hours ago, phaeron said:

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

• AltirraOS 3.42: P: device in XL/XE/XEGS build now supports different printer device units, and fixed invalid orientation values being passed to the printer.
• ANTIC: Added emulation of DMACTL-based abnormal DMA condition.
• ATBasic 1.59: Fixed AUX2 not being set up for print I/O, which also affects printer orientation.
• Cassette: Fixed framing errors not being reported.
• Input: Holding down Alt between pressing and releasing an input key no longer results in that input getting stuck on.
• Printer: Printer outputs are now held separately from the printer pane.
• Simulator: Added support for rewind recording.

The graphical printer output storage has been reworked to take less memory, so keeping long printouts shouldn't be an issue -- it now only takes 8 bytes per column of pins printed. Printer output is now also stored per printer output, so if you have multiple printers, each printer will get its own output. However, the UI doesn't currently let you see the other printer outputs until you remove the primary one.

 

Rewind recording is the big new thing in this test release. It is disabled by default due to slight overhead, and enabled in System > Configure System > Speed. Once this is enabled, the emulator will automatically take snapshots every second, which can be returned to by the Quick Rewind command (System > Rewind > Quick Rewind). By default, this will rewind to between one half and 1.5 seconds back, and repeating in quick succession will rewind farther back. The emulator stores up to 20 rewind saves and the ones farther back are spaced farther apart, so it is possible to rewind up to a few minutes. This command is keyboard bindable through the usual methods (Tools > Keyboard Shortcuts or right-clicking on the menu option) and it is also controller bindable.

 

The second Rewind... command brings up a menu showing the available rewind states, allowing manual selection between them:

 

Enter rewinds back to the selected state, and Esc cancels out. This menu is also controller bindable, but it takes some effort: the console controller has to be set up in the input map with the various UI navigation bindings, which aren't set up by default.

 

As this is based on the save state infrastructure, the usual caveats apply -- this will only work safely with things that are currently saved in save state, so not all devices will save/restore properly. It will avoid taking snapshots during disk activity, but I also don't recommend rewinding past disk writes. As with save states, rewind will not roll back disk images, which can be problematic or not problematic based on the running program/DOS.

 

When warp speed is enabled, the snapshot rate will throttle to 1 per real second, so as to avoid slowing down the warp. However, this does mean that the snapshots will be spaced farther apart in simulation time.

 

Sadly, this feature isn't enough to make the official release of Jet Set Willy playable, though it does allow for seeing more of it. For the excellent 2007 unofficial remake, it allows you to save Willy from death loops.

 

Currently rewind is instant, which can be problematic if the rewind snapshot is in a dangerous spot. This is why the rewind menu exists, so you can see what you're going back to, but it can still be pretty hairy to jump back in a fast game like River Raid. I'd like to put in a transition so you have time to react after the rewind, but that'll take some work to integrate into the main loop.

 

 

Thank you Avery! Thank you so much!

 

 

[Mclaneinc]

Thank you for all the new and reworked features, as a notorious cheat, the rewind feature is one for me. I'm sure you will refine it over time. I'm also another person that would love a print to PDF, but as always, it's a feature that would be nice, but pure "if it happens".

 

Hope work is keeping you busy in a good way

 

Again, thanks, always appreciated..

 

Paul..

[+MrFish]

12 hours ago, phaeron said:

For the excellent 2007 unofficial remake

There's an even better version too: @Tezz's remake.

Jet Set Willy 2019

New Game: Jet Set Willy 2019

 

 

[+yetanothertroll]

On 8/30/2024 at 7:52 PM, Tim Stone said:

 

Okay, so you are saying this was normal?  I thought I remember a larger screen.  I have a 27 inch PC monitor that I use it on today with the scan lines active.  Mind you this was 1984 to 1993 when I gave my Atari 8-bit away as I moved to the PC exclusively at that point.

Super normal. In BASIC you can use SETCOLOR 4, xx, yy to play with the color of the overscan area,

 

If you want to try your hand at rendering ATASCII yourself, this shows how to convert from ATASCII to the displayed glyphs using the currently loaded character table,

 

100 FT=PEEK(756)*256
110 DIM R$(8),L$(256)
120 L$="Meef"
130 L$(3,3)=CHR$(128+ASC(L$(3,3)))
200 FOR Y=0 TO 7
210 FOR I=1 TO LEN(L$)
220 Z=ASC(L$(I))
230 R=128<=Z
240 IF R THEN Z=Z-128
250 IF Z<32 THEN Z=Z+64:GOTO 290
260 IF Z<96 THEN Z=Z-32:GOTO 290
290 Z=PEEK(FT+Y+8*Z)
300 FOR X=8 TO 1 STEP -1
310 B=1-((Z/2)=INT(Z/2))
320 IF R THEN B=1-B
400 R$(X,X)=CHR$(32+128*B)
500 Z=INT(Z/2)
510 NEXT X
520 PRINT R$;
600 NEXT I
610 PRINT 
700 NEXT Y
999 END 

 

How might you modify this to render L$ as a nice big sideways banner on a printer, including reverse video and graphics characters? How about exporting the character table to a binary file on the host OS so you can render ATASCII files outside of the emulator?

[Tim Stone]

5 hours ago, yetanothertroll said:

Super normal. In BASIC you can use SETCOLOR 4, xx, yy to play with the color of the overscan area,

 

If you want to try your hand at rendering ATASCII yourself, this shows how to convert from ATASCII to the displayed glyphs using the currently loaded character table,

 

100 FT=PEEK(756)*256
110 DIM R$(8),L$(256)
120 L$="Meef"
130 L$(3,3)=CHR$(128+ASC(L$(3,3)))
200 FOR Y=0 TO 7
210 FOR I=1 TO LEN(L$)
220 Z=ASC(L$(I))
230 R=128<=Z
240 IF R THEN Z=Z-128
250 IF Z<32 THEN Z=Z+64:GOTO 290
260 IF Z<96 THEN Z=Z-32:GOTO 290
290 Z=PEEK(FT+Y+8*Z)
300 FOR X=8 TO 1 STEP -1
310 B=1-((Z/2)=INT(Z/2))
320 IF R THEN B=1-B
400 R$(X,X)=CHR$(32+128*B)
500 Z=INT(Z/2)
510 NEXT X
520 PRINT R$;
600 NEXT I
610 PRINT 
700 NEXT Y
999 END 

 

How might you modify this to render L$ as a nice big sideways banner on a printer, including reverse video and graphics characters? How about exporting the character table to a binary file on the host OS so you can render ATASCII files outside of the emulator?

 

Thank you.  I will be trying both of these out and see what I can make out of them.  Thank you so much!

[Tim Stone]

Feature Request: (EASY ONE)

 

In order to copy or paste into Altirra, you need to right click on the window or full screen.  Can we add in Windows copy/paste keys as well to this?

Paste = SHIFT INSERT for example? 

 

I know CONTROL-V and CONTROL-C are used for ATASCII characters, and so that isn't ideal, but at least something instead of right clicking on the mouse.

[pcrow]

On 8/29/2024 at 12:01 AM, phaeron said:

There's no facility in the OS for assigning individual device units. The Central I/O subsystem (CIO) uses a handler table (HATABS) that only registers whole devices, like Dn: or Hn: and there's no direct way to "designate" only D5-D8:. In order to do this, it would be necessary to try to shim DOS's Dn: handler to split accesses between DOS and the host device. It also doesn't work whenever there's a command in DOS that specifically looks for the D drive letter on paths and assumes that it's dealing with a DOS device -- which would no longer be guaranteed.

Just some thoughts:

 

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.

 

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.  Obviously you would need different versions for SpartaDOS, DOS 2.5, and probably MyDOS, and people would then ask for a few more.  There are already tools to create disk images from directory images; this would just be doing it on the fly and bidirectional.

 

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).

 

But for the most part, I think H: is awesome.  It just takes a little bit to wrap your head around the fact that DOS is just for D: and not a FMS on top of the CIO handlers.

 

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

[+yetanothertroll]

1 hour ago, Tim Stone said:

Feature Request: (EASY ONE)

 

In order to copy or paste into Altirra, you need to right click on the window or full screen.  Can we add in Windows copy/paste keys as well to this?

Paste = SHIFT INSERT for example? 

 

I know CONTROL-V and CONTROL-C are used for ATASCII characters, and so that isn't ideal, but at least something instead of right clicking on the mouse.

 

You'll need to find a combo that doesn't map to a value in KEYCODE even on an XL,

 

Reading the Keyboard Codes

 

For example, SHIFT INSERT maps to 119,  CTRL INSERT is 247, and SHIFT CTRL INSERT is also 247,

 

[phaeron]

4 hours ago, Tim Stone said:

Feature Request: (EASY ONE)

 

In order to copy or paste into Altirra, you need to right click on the window or full screen.  Can we add in Windows copy/paste keys as well to this?

Paste = SHIFT INSERT for example? 

 

I know CONTROL-V and CONTROL-C are used for ATASCII characters, and so that isn't ideal, but at least something instead of right clicking on the mouse.

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.

[reifsnyderb]

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
	};