Altirra 3.20 released

[_The Doctor__]

I purposely use the XEP80 with Bobterm to use the menu's etc on one screen while BBS text is on the other... I often use the XEP as my manual page or step by step instruction screen while using the Atari to do whatever I need those instructions for one the normal screen.

should be interesting to see how this works out with the new driver. Although the mention of strictly enforced DMA has me slightly worried that's not going to be. In any event I'll be checking it out in the morning to noon range tomorrow (today that is)

 

[phaeron]

  

5 hours ago, Faicuai said:

Seems to me that, right after INIT OK (by Master Reset), just repeat exact same initial sequence of XEPReset (above) but starting with LDA $D7. I understand that it will add about 16-18 bytes of code but, aside from the two JSRs, should not be a nightmare to be accounted by the relocation routine.

It's not so much the extra bytes in the handler so much as the handler doing something that the Atari handler doesn't and that others may not want. Unilaterally switching to 50Hz would definitely fall under this. But I can give you custom builds that auto-switch to 50Hz:

 

xep80.sys

xep80f.sys

 

Pulled out the scope and as I feared, 4X mode is a no-go as the rise time on the PIA inputs is too slow. 2X mode is about on the border of what the joystick inputs can handle, 4X simply doesn't have enough recovery time per bit to send 1 bits properly:

 

 

The only other possibility for speeding up comm would be to try symmetric 31.5Kbaud instead of 31.5K transmit / 15.7K receive, to speed up the reception of the status bytes. The XEP80 hardware is capable of this, but the reason I haven't tried it is that the async receive is more difficult with ANTIC @#*$ refresh cycles.

 

As for changing the NTSC display, you can try this BASIC program:

10 PRINT CHR$(0);
20 XIO 22,#16,12,246,""
30 FOR I=0 TO 8
40 READ X
50 PRINT CHR$(X);
60 XIO 22,#16,12,247,""
70 NEXT I
80 PRINT CHR$(23);:XIO 22,#16,12,248,""
90 DATA 108,79,82,95,128,28,25,2,23

This reprograms the NS405 timing chain and VINT register. It reconfigures the display timing to 109x29 characters cells of 9 scans/row + 1 extra scan, giving 15.727KHz H x 60.02Hz and reducing the number of display scanlines for the main 80x24 display from 240 to 216.

 

27 minutes ago, _The Doctor__ said:

I purposely use the XEP80 with Bobterm to use the menu's etc on one screen while BBS text is on the other... I often use the XEP as my manual page or step by step instruction screen while using the Atari to do whatever I need those instructions for one the normal screen.

should be interesting to see how this works out with the new driver. Although the mention of strictly enforced DMA has me slightly worried that's not going to be. In any event I'll be checking it out in the morning to noon range tomorrow (today that is)

You are correct, this will not work because my XEP80 driver will force off the ANTIC display. This is to work around the problem with BASIC XE turning the ANTIC display on and screwing up XEP80 receive timing. BobTerm doesn't have that problem because it uses burst mode, but the XEP80 driver doesn't know that it is working with an XEP80-friendly program and I'm not sure it sees the burst mode switch in time.

[Mclaneinc]

Avery, you know there's jobs to be had with Dell technical support!

 

Seriously, I keep saying it but we just bow to your absolutely amazing scope of knowledge regarding this wonderful series of computers, your ability to breakdown and understand the innermost workings of stuff be it from chip diagrams or reverse engineering just leaves me in awe. Yeah sure you trained in all this but having the knowledge and using it correctly are two different things, you just make all this look very easy and that is a skill.

 

And the fact you don't charge me a penny for all this leaves you in super high regard.

 

You stay safe in this rather disjointed world of now...Edit to add, can we ALL stay safe...

 

Simply, thank you.... 

 

Paul.

Edited April 15, 2020 by Mclaneinc

[+Stephen]

11 hours ago, Faicuai said:

The NICEST thing about running the system on XEP80 is that text-driven output can be finally abstracted from Atari's main video system, not just by creating a SECONDARY, concurrent video-feed, but by enabling it even with ANTIC DMA=OFF, which means running the 6502 @ full tilt, which is strictly enforced by your driver (KUDOS!) All my local, small programming and editing now work at system's full CPU speed, without ever turning the text-output screen off!  

That's what I love about running via VBXE too - ANTIC DMA is off so everything gets that nice 30% speed boost.

[_The Doctor__]

might want to put 50 in the filenames...

[Faicuai]

On 4/15/2020 at 4:36 AM, phaeron said:

  

(...)

 

xep80.sys 1.52 kB · 3 downloads

xep80f.sys 1.79 kB · 3 downloads

 

(...)

 

As for changing the NTSC display, you can try this BASIC program:

10 PRINT CHR$(0);
20 XIO 22,#16,12,246,""
30 FOR I=0 TO 8
40 READ X
50 PRINT CHR$(X);
60 XIO 22,#16,12,247,""
70 NEXT I
80 PRINT CHR$(23);:XIO 22,#16,12,248,""
90 DATA 108,79,82,95,128,28,25,2,23

This reprograms the NS405 timing chain and VINT register. It reconfigures the display timing to 109x29 characters cells of 9 scans/row + 1 extra scan, giving 15.727KHz H x 60.02Hz and reducing the number of display scanlines for the main 80x24 display from 240 to 216.

 

 

My goodness!

 

Just Look at this:

 

 

 

Just pure analog XEP80 goodness @ 576p / 50 HZ, @ 80col x 24rows!

 

FYI, tried the Basic program, but runs only from Atari's original driver, and repeats the last 24th line, with a blank between them... 

 

As for an asymmetrical speed model, it would depend on the possibility of being able to send larger chunks to the XEP80 with minimal number of receives required from it, along the way... otherwise it may be hard to realize the actual potential of the concept, itself. (NOTE: just re-read, and noticed you were attempting 30Kbd+ symmetric...)

 

But, boy, you really pushed the chain there to its bare-bone limits! :-)))

Edited April 17, 2020 by Faicuai

[phaeron]

55 minutes ago, Faicuai said:

FYI, tried the Basic program, but runs only from Atari's original driver, and repeats the last 24th line, with a blank between them... 

Ah, that's a status byte bug in my handler. I'll fix that.

 

As for the extra blank line, that's a limitation of the way the NS405 works. The hardware requires vertical sync to be within one character row of the start of vertical blank, which is presumably one reason for the insane overscan. In order to push the display far enough way from vsync that it can be seen on a normal display, an extra active line has to be put in between. The blank line you're seeing is the status line, followed by the display wrapping back to the first line. The write to the VINT register is to ensure that this doesn't also cut off that same line at the top. Unfortunately, without reprogramming the firmware there doesn't seem to be a way to hide that extra line. On my CRT, that line isn't visible, but with a scan converter it's easier to see it.

 

Also, I looked into how BobTerm uses the XEP and there isn't any point to trying to adapt my handler to it. BobTerm doesn't use a regular XEP80 handler, it uses a special one tailored specifically for BobTerm that hooks directly into the app's output routines. There's no advantage at standard speeds; maybe there might be one at 2x transmit, but such a module would have to be written just for BobTerm.

 

[Faicuai]

1 hour ago, phaeron said:

Ah, that's a status byte bug in my handler. I'll fix that.

 

As for the extra blank line, that's a limitation of the way the NS405 works. The hardware requires vertical sync to be within one character row of the start of vertical blank, which is presumably one reason for the insane overscan. In order to push the display far enough way from vsync that it can be seen on a normal display, an extra active line has to be put in between. The blank line you're seeing is the status line, followed by the display wrapping back to the first line. The write to the VINT register is to ensure that this doesn't also cut off that same line at the top. Unfortunately, without reprogramming the firmware there doesn't seem to be a way to hide that extra line. On my CRT, that line isn't visible, but with a scan converter it's easier to see it.

 

(...)

 

Ok, had to go back to the Basic program, again, and relook at things. Something caught my attention.

 

I am actually seeing 27 (twenty-seven) lines, as follows:

 

1. First one on top, is BLANK.

2. Then come 24 lines.

3. Then a blank-one right below 24th.

4. Than 26th, which mirrors 24th exactly.

 

Here's how it looks (notice the video-processor's vertical-and-horizontal masks, so you can see exactly the starting and ending points of signal scan / conversion, in both directions):

 

 

What I am zeroing in now, is the FIRST blank line, at the very top. I mention this because if you go up to my prior captures (either NTSC or your latest Pal-50 version), you will notice that the frame starts with about four or five blank / clear scan LINES.

 

So my question is: is there ANY way to "advance" the start of line-drawing on the XEP80, in order to reduce those 4 or 5 lines to, say, 1 or 0 (on the original vertical-scan mode, no the tweaked-one)? In theory, that should translate into 4-5 extra scan lines at the bottom, thus making the 80x24 matrix FULLY visible even on NTSC-mode!

 

Edited April 17, 2020 by Faicuai
(just a ton of typos...)

[+DrVenkman]

So I've got a weird usability issue going on with Altirra: right now when I am using Jon's Ultimate 1MB firmware to emulate one of my enhanced A8 machines, keystrokes are not being registered or acted upon inside the firmware BIOS. If I remove the emulated U1MB from the system, the emulated Atari recognizes keystroke input just fine. 

I've tried different versions of the U1MB firmware from Jon's site (current release from last summer as well as various beta versions I've been privy to), and I've reset Altirra to scratch and setup stuff again. I've even gone so far as to try prior test releases of Altirra that I've used in the past and *they* don't work either, which makes me wonder if this is some new Win10 quirk from a recent update. If I enable joystick emulation in Altirra using the arrow keys, I can navigate the U1MB firmware menus because Jon enables joystick navigation in his release firmware versions by default. However, since the joystick fire button is emulated by a keyboard button, it doesn't register to make selections in the BIOS menu.

 

Does anyone have any suggestions? 

[flashjazzcat]

Are you using the XEL/XLD firmware without enabling Stereo POKEY?

[+DrVenkman]

10 minutes ago, flashjazzcat said:

Are you using the XEL/XLD firmware without enabling Stereo POKEY?

Damn it, you're right. Worse, I've had this very same problem before a year or so ago maybe. Ugh. I don't know what happened in the first place to get the settings changed in Alitrra in the past week or so but I can't believe I've had this same issue and not remembered the solution. That's not like me - I'm not above making a mistake but I usually don't make the same really stupid one twice. This lockdown is getting to me. 

Thanks, Jon. 

[_The Doctor__]

Is this same combination possible on real hardware or is it locked out?

[+DrVenkman]

1 hour ago, _The Doctor__ said:

Is this same combination possible on real hardware or is it locked out?

On real hardware, disabling stereo sound involves disabling Stereo POKEY in the XLD BIOS. It has no effect on the use of the arrow keys to navigate. 

 

The issue here, for me, is that somehow in the last week or so, even before I freaked out and reset Altirra to defaults and started over, the stereo option had gotten changed in my audio settings in Altirra. How that happened or why I have no idea. Worse still, I've had this same exact situation and simply forgot it had happened. Ugh. 

[flashjazzcat]

4 hours ago, _The Doctor__ said:

Is this same combination possible on real hardware or is it locked out?

You cannot have an XEL or XLD without the second POKEY address space, even if only the primary POKEY is physically present. Therefore the stereo detection method cannot leave the keyboard uninitialised on the primary chip, as it does if you accidentally emulate things without stereo turned on.

[tjcbs]

phaeron, 

 

Is there any chance you can compile cg shaders with ps 3.0? I think it would greatly improve compatibility, and I think it might be as simple as passing a different enum to the compile call. My own shader gets the error:

 

'shader uses texture addressing operations in a dependency chain that is too complex for the target shader model (ps_2_0) to compile.'

 

Thanks for making what is indisputably the best atari 8-bit emulator!!

[phaeron]

4 hours ago, tjcbs said:

Is there any chance you can compile cg shaders with ps 3.0? I think it would greatly improve compatibility, and I think it might be as simple as passing a different enum to the compile call. My own shader gets the error:

 

'shader uses texture addressing operations in a dependency chain that is too complex for the target shader model (ps_2_0) to compile.'

The custom shader compiler uses vs2.0/ps2.0 by default for best compatibility when using precompiled shaders. Use this line to force SM3:

shader_profile_d3d9 = 3_0

 

[+skr]

I have a totally unimportant request, which might be interesting for me only:

 

As my professional workflow is relying on NewTek NDI more and more each day I wonder if it would it be possible for you to add NDI-support to Altirra?

NDI -> https://www.newtek.com/ndi/applications/

 

For streaming I can use OBS Studio which catches any open program window, so I can stream Altirra output already. But it would be even more handy, if Altirra "speaks" NDI out of the box, so that I could add it as a dedicated source in OBS Studio.

 

But my very weird idea is to have it running in my 21m dome running on E&S Digistar 6 on "real" 8K (8192x8192 pixels) @30/60/120 fps. Unlike OBS Studio, Digistar 6 (which in general is an astronomical multimedia software and also takes care of alignment and blending of our 5 Christie Boxer projectors) can´t just grab open program windows, but any NDI stream.

 

Totally ignore me, if that is too strange of a question, no problem. But right now we are closed to the public and I always try to bring my Atari hobby into the dome and know I have time for testing some things, as the dome is available 24/7 to me now.

[+DjayBee]

54 minutes ago, skr said:

my very weird idea is to have it running in my 21m dome

Yeah, a planetarium is the adequate stage for a game of Star Raiders. ?

[phaeron]

18 hours ago, skr said:

As my professional workflow is relying on NewTek NDI more and more each day I wonder if it would it be possible for you to add NDI-support to Altirra?

NDI -> https://www.newtek.com/ndi/applications/

 

For streaming I can use OBS Studio which catches any open program window, so I can stream Altirra output already. But it would be even more handy, if Altirra "speaks" NDI out of the box, so that I could add it as a dedicated source in OBS Studio.

 

But my very weird idea is to have it running in my 21m dome running on E&S Digistar 6 on "real" 8K (8192x8192 pixels) @30/60/120 fps. Unlike OBS Studio, Digistar 6 (which in general is an astronomical multimedia software and also takes care of alignment and blending of our 5 Christie Boxer projectors) can´t just grab open program windows, but any NDI stream.

 

Totally ignore me, if that is too strange of a question, no problem. But right now we are closed to the public and I always try to bring my Atari hobby into the dome and know I have time for testing some things, as the dome is available 24/7 to me now.

I'm sympathetic to the request, but unfortunately integrating the NDI SDK is a bit more than I can accommodate for this. It seems that using NDI would require implementing another audio/video output path, and in addition the licensing of the SDK would require this to involve a slightly sketchy workaround (MIT headers to dynamically link to an in-process DLL).

 

[phaeron]

http://www.virtualdub.org/beta/Altirra-3.90-test32.zip

http://www.virtualdub.org/beta/Altirra-3.90-test32-src.zip

 

This is the release candidate build. Changes:

• Fixed a regression in some 3.90-testX versions in 65C816 emulation that caused the D flag to be set on reset instead of cleared, breaking the Turbo-816 OS.
• Fixed a crash in the compatibility code if an external compatibility database was enabled that failed to load.
• A few custom device fixes:
  • Fixed $timestamp not being updated for some callbacks.
  • Fixed some compile errors not being reported properly.
  • Fixed some methods being missing from the documentation.

 

[+DjayBee]

For a long time I have the wish that protected disk images (ATX, PRO) have a different-colored icon in Windows Explorer.

 

I always registered it myself, but since Windows 10 it becomes more and more a pain in the butt to do this. Meanwhile one needs a separate "hack tool" to accomplish this task.

 

Would you... ? ?

 

Here is a ready-to-use icon I recolored based on the original black Altirra icon:

Altirra64-red.ico

[+MrFish]

7 hours ago, DjayBee said:

For a long time I have the wish that protected disk images (ATX, PRO) have a different-colored icon in Windows Explorer.

 

I always registered it myself, but since Windows 10 it becomes more and more a pain in the butt to do this. Meanwhile one needs a separate "hack tool" to accomplish this task.

 

Would you... ? ?

 

Here is a ready-to-use icon I recolored based on the original black Altirra icon:

Altirra64-red.ico 23.2 kB · 7 downloads

Good point; it would be helpful to have some way to distinguish these disk types.

 

The bright red is a little heavy-handed though. I was thinking of something like a superimposed "lock" or something; but I could see where that would be a problem showing up in list views (16 x 16 icon) -- which is what I mainly use.

 

Maybe something more like a dark maroon might be better. Also, it might be better to have @pseudografx design something, as he'd know best how to integrate the look with what he's already done (he's the original icon designer for Altirra).

 

I definitely should add something to my website for ATX/PRO; I think I'm using a few ATX files there. The good thing is that I'm only using 48 x 48 icons; so I wouldn't have to worry about scaling.

 

Edited May 5, 2020 by MrFish
Added @pseudografx comment.

[Suppawer]

About firmwaredetect.cpp:

I can't find this file:

- CRC FD13A674 ("Percom AT-88 V1.2 (damaged) (460-0066-001)")

[+Philsan]

Hi Avery.

 

Yesterday I had a problem formatting a disk with the new awesome LiteDOS 3.

I've always had an error until I discovered that I had to switch Altirra's default VRWSafe mode to VRW.

 

"This mode is "similar to virtual read/write, except that format commands are blocked with a read-only disk error. This allows virtualized write access to disks while still blocking writes for programs that attempt to format their disk on boot as part of a protection check. Altirra defaults to this mode until changed in Options" (excerpt from Altirra's manual).

 

I never had that problem before because I never formatted a disk from emulator, I always used blank images or PC tools.

 

I think that VRW should be the default option but surely there must be a reason why you chose VRWSafe.

 

BTW, it would be nice if you'll support LiteDos 3 in disk explorer.

 

Thanks!

 

[flashjazzcat]

13 minutes ago, Philsan said:

I think that VRW should be the default option but surely there must be a reason why you chose VRWSafe.

I guess the reason VRWSafe is the default is explained by the excerpt from the manual.