Jump to content
IGNORED

Altirra 3.90 released


phaeron

Recommended Posts

I have another one. This is with the altxep8u.sys driver though it's not related.

 

On a real XEP80 a DEL or DELCHR will cause the logical lines to be shortened if there are only spaces to the end of the line. This code on a real XEP80 shows a row of 0's on the right side as it prints spaces over the subsequent characters, and then prints a delete on the top line. What happens then is the logical lines is only the top line now, and the chr$(156) on the next line deletes only the empty line, not both lines. On Altira it shows nothing because the logical line is still two lines high.

 

 

5 POKE 82,2:POKE 83,79:PRINT CHR$(125);
20 FOR N=0 TO 3
30 POKE 85,70:POKE 84,N
40 PRINT "012345678 0123456789";
50 POKE 85,71:POKE 84,N
60 PRINT "        ";CHR$(31);CHR$(29);"          ";
70 POKE 85,72:POKE 84,N
80 IF N<2 THEN PRINT CHR$(126);
81 IF N>=2 THEN PRINT CHR$(254);
90 POKE 84,1+N:PRINT CHR$(156);
110 NEXT N


And one last thing, far as I know of. System reset on altxep8u.sys returns the atari to 40 column mode.  with xep80.sys that comes with spartados, the Atari stays in 80 columns.  Not sure if this is intentional or not.


LATER NOTE: And I see, the original atari autorun.sys does reset to 40 columns on system reset.  Maybe this is arguably more correct?

 

 

 

IMG_0598.thumb.JPG.eb9bc3ed074531292cdff1fd323c6fdf.JPG

IMG_0597.JPG

Edited by cathrynm
Link to comment
Share on other sites

5 hours ago, Faicuai said:

 

FYI, these new drivers are not working on latest FAST BASIC v4.5 built-in E: editor (which works with any arbitrary # of columns up to 80).

 

Just loading any existing text-file or starting from a blank one, will generate down-pointing arrow chars (above any line being edited with, say, Backspace) or when typing a series of lines, and then attempting line-insertions (with Carriage-Return above those lines) will not scroll them downward. Instead, they will be obliterated.

Oops, sounds like those guys have "Poke 766,1" set. Someone will have to update their code. 

Link to comment
Share on other sites

28 minutes ago, cathrynm said:

Oops, sounds like those guys have "Poke 766,1" set. Someone will have to update their code. 

The strange thing is that the original XPE80 driver (Atari-version) actually works with FastBasic v4.5 E: editor (along with v07 ALT Ultra Drivers)...

 

Can't exactly tell where the problem is, though.

Edited by Faicuai
Link to comment
Share on other sites

1 hour ago, cathrynm said:

And one last thing, far as I know of. System reset on altxep8u.sys returns the atari to 40 column mode. 

As far as I tested, if you boot the Altirra Additions disk, and launch the drivers, they will trap reset properly. Even happens with AtariDOS and DOS XL.

 

SDX manages RESET-trap tightly and the typical Atari-DOS traps do not seem to work as intended.

 

But it is a good point, because, I would like to know the exact command I need to issue from SDX prompt to switch 80-to-40 and 40-to-80 with a preloaded ULTRA driver in RAM.

Edited by Faicuai
Link to comment
Share on other sites

1 hour ago, Faicuai said:

As far as I tested, if you boot the Altirra Additions disk, and launch the drivers, they will trap reset properly. Even happens with AtariDOS and DOS XL.

 

SDX manages RESET-trap tightly and the typical Atari-DOS traps do not seem to work as intended.

 

But it is a good point, because, I would like to know the exact command I need to issue from SDX prompt to switch 80-to-40 and 40-to-80 with a preloaded ULTRA driver in RAM.

Oh I see. You're right, if I boot from Altirra disk it resets fine.  All this reset trap handling I've never really understood about Atari 8bit. Not sure what's going on with SDX.

 

On mode changing, I was just looking that up. This stuff is in an XEP80.DOC file that's on the original disk that comes with XEP80.  I'm not sure, but maybe this is a driver bug?  For me these are working on the original XEP80 disk but not from the Altirra additions disk.

 

For 80 to 40

XIO 25,#1,12,0,"E:"

40 to 80 clear

XIO 24,#1,12,0,"E:"

40 to 80 no clear.

XIO 24,#1,44,0,"E:"

  • Like 1
Link to comment
Share on other sites

14 hours ago, Faicuai said:

 

FYI, these new drivers are not working on latest FAST BASIC v4.5 built-in E: editor (which works with any arbitrary # of columns up to 80).

 

Just loading any existing text-file or starting from a blank one, will generate down-pointing arrow chars (above any line being edited with, say, Backspace) or when typing a series of lines, and then attempting line-insertions (with Carriage-Return above those lines) will not scroll them downward. Instead, they will be obliterated.

 

V07 worked well (don't know if by chance or not, but it is what it is). All this on SDX environment, with no real or special drivers loaded.

 

@dmsc might be interested in this. ;)

Link to comment
Share on other sites

8 hours ago, cathrynm said:

Not sure what's going on with SDX.

In SDX the reset trap is registered when the resident program, which is registering it, changes the MEMLO.

 

Altirra drivers are not loaded over MEMLO, but under MEMTOP. MEMLO does not change, so that is the first cause why the trap is ignored.

 

Second, MEMTOP is variable under SDX, it goes up and down as the cartridge is being switched off and on. So when ALT*.SYS is loaded, it installs itself at ~$96C0. Now load a program which needs the cartridge to get switched off (TBXL for example): the cartridge ROM goes out, MEMTOP, RAMTOP, RAMSIZ etc. all go 8 KB up. But the E: handler stays at its $96C0, in the middle of unprotected memory, waiting to get overwritten by anything. So, in longer terms this is unlikely to work properly.

 

And own SDX driver, from what I can see, simply does not have the XIO 24/25 implemented.

 

  • Like 3
Link to comment
Share on other sites

1 hour ago, drac030 said:

In SDX the reset trap is registered when the resident program, which is registering it, changes the MEMLO.

 

Altirra drivers are not loaded over MEMLO, but under MEMTOP. MEMLO does not change, so that is the first cause why the trap is ignored.

 

Second, MEMTOP is variable under SDX, it goes up and down as the cartridge is being switched off and on. So when ALT*.SYS is loaded, it installs itself at ~$96C0. Now load a program which needs the cartridge to get switched off (TBXL for example): the cartridge ROM goes out, MEMTOP, RAMTOP, RAMSIZ etc. all go 8 KB up. But the E: handler stays at its $96C0, in the middle of unprotected memory, waiting to get overwritten by anything. So, in longer terms this is unlikely to work properly.

 

And own SDX driver, from what I can see, simply does not have the XIO 24/25 implemented.

 

Thanks for this, I understand now much better what's going on with SDX.  I suppose loading to memtop, not an actual bug with altx80*.sys because the original driver does this, but I get now why SDX has its own XEP80.SYS.

Edited by cathrynm
Link to comment
Share on other sites

1 hour ago, drac030 said:

But the E: handler stays at its $96C0, in the middle of unprotected memory, waiting to get overwritten by anything. So, in longer terms this is unlikely to work properly.

 

I have created a set of special, code-wrapped versions of Avery Ultra drivers (40KB to 52KB) with their own tiny memory-manager to solve this problem (as long as they can be called from the app. being invoked, they do not run "linked" to each other, because Avery's code is untouched.

 

And, yes, they load high in ram... but that means I can load them in 52KB high-ram range and have quite a good deal of ram available, even when SDX rom-cart is active on $A000-$BFFF range, and even if it brings $02E5, $02E6 below $A000.

 

Works beautifully and ***FAST***.

Edited by Faicuai
(garbage cleanup, accuracy)
Link to comment
Share on other sites

3 hours ago, drac030 said:

And own SDX driver, from what I can see, simply does not have the XIO 24/25 implemented.

Forgot this one:

 

Now that you mention it, this could be the perfect time for a good XEP80 SDX-driver refresh (it is very well integrated to SDX, but definitely slower, compared to Avery's ULTRA drivers). Include PAL-or-NTSC versions, command or keystroke-drive 40/80 switch, and soft-or-strict enforcement of DMA operation for maximum 6502 "console mode" performance, when needed. Also, this would enable them to work really well on a modern, dual-LCD setup.

 

Maybe his code-base could be used, once the little kinks are ironed out?

Edited by Faicuai
  • Like 2
Link to comment
Share on other sites

http://www.virtualdub.org/beta/Altirra-4.00-test31.zip

http://www.virtualdub.org/beta/Altirra-4.00-test31-src.zip

  • Debugger: Added Step Over support for JSR (abs, X), JSL, and MVN/MVP instructions.
  • Debugger: Added .loadstate and .savestate commands.
  • Debugger: Added go cycle relative (gcr) command.
  • You can now right-click on items in the menu to jump directly to the corresponding command in Keyboard Shortcuts to rebind it to a new key. This works for any menu item that has a command associated and is rebindable.
  • Added an advanced configuration variable to allow d3d9.dll, d3d11.dll, and dxgi.dll to load from the application directory for ReShade compatibility. In Tools > Advanced Configuration, change engine.allow_display_library_overrides to 'true'.
  • Fixed a couple of bugs in save state loading, including a bug in mid-instruction restore in the CPU and a crash with restoring the register queue list in GTIA. POKEY serial output state is also saved to fix some issues with disk reads stopping across a load.
  • The Quick Load State menu option is now grayed out when there is no quick save state.
  • Fixed a minor error in the DOS on the Additions disk where it printed the wrong message when using 'cart' with no cartridge.
  • XEP80 handler updates: DSPFLG is now correctly handled; v0.91 has a fix for the bug that broke FastBasic. Changed LMARGN default to 0 to match the stock XEP80 handler.

 

On 3/11/2021 at 7:51 PM, cathrynm said:

I have another one. This is with the altxep8u.sys driver though it's not related.

 

On a real XEP80 a DEL or DELCHR will cause the logical lines to be shortened if there are only spaces to the end of the line. This code on a real XEP80 shows a row of 0's on the right side as it prints spaces over the subsequent characters, and then prints a delete on the top line. What happens then is the logical lines is only the top line now, and the chr$(156) on the next line deletes only the empty line, not both lines. On Altira it shows nothing because the logical line is still two lines high.

Another nice catch, but that wasn't quite the problem. The XEP80 never scans for spaces, it only checks for EOLs at the end of lines as the logical line end marker. Only the handler on the computer side does space scanning (which is what causes the status line hang bug). Delete char will shorten the logical line if it deletes enough chars to pull EOLs into the last physical line, thus splitting the logical line, but that isn't what was happening in your case. You can see the EOLs in the framebuffer by switching to the internal character set with XIO 20,#16,12,216,"E".

 

The actual issue is an apparent bug in the XEP80 firmware where its delete line command only deletes the part of the logical line starting at the current physical line, so it will cut part of the logical line and splice the rest against the next. The emulation was matching the standard E: behavior of deleting the whole logical line. I've removed the check to find the start of the logical line and that fixes your test case.

 

  • Like 11
  • Thanks 4
Link to comment
Share on other sites

11 hours ago, phaeron said:

http://www.virtualdub.org/beta/Altirra-4.00-test31.zip

http://www.virtualdub.org/beta/Altirra-4.00-test31-src.zip

 

  • Added an advanced configuration variable to allow d3d9.dll, d3d11.dll, and dxgi.dll to load from the application directory for ReShade compatibility. In Tools > Advanced Configuration, change engine.allow_display_library_overrides to 'true'

 

 

Ahh... Thank you phaeron!  I'll be trying this out later on and report back.

Link to comment
Share on other sites

On 3/12/2021 at 11:08 AM, Faicuai said:

Forgot this one:

 

Now that you mention it, this could be the perfect time for a good XEP80 SDX-driver refresh (it is very well integrated to SDX, but definitely slower, compared to Avery's ULTRA drivers). Include PAL-or-NTSC versions, command or keystroke-drive 40/80 switch, and soft-or-strict enforcement of DMA operation for maximum 6502 "console mode" performance, when needed. Also, this would enable them to work really well on a modern, dual-LCD setup.

 

Maybe his code-base could be used, once the little kinks are ironed out?

I give the altxep8*.sys drivers credit for opening my eyes about this hardware.  It has potential to be 'actually okay' for tinkering with fujinet commands from SPARTADOS, fussing with files and disks  Would an updated Spartados Driver allow that EDX editor to work on XEP80?

  • Like 1
Link to comment
Share on other sites

On 3/12/2021 at 8:08 PM, Faicuai said:

Now that you mention it, this could be the perfect time for a good XEP80 SDX-driver refresh (it is very well integrated to SDX, but definitely slower, compared to Avery's ULTRA drivers). Include PAL-or-NTSC versions, command or keystroke-drive 40/80 switch, and soft-or-strict enforcement of DMA operation for maximum 6502 "console mode" performance, when needed. Also, this would enable them to work really well on a modern, dual-LCD setup.

 

Maybe his code-base could be used, once the little kinks are ironed out?

It may be, but I am not sure if I am the correct one to direct such requests to. Maybe it would be enough to modify the relocator in AT*.SYS files so that it would load the driver code over the MEMLO instead of under MEMTOP? The MEMLO would go up by some 1.5 KB, but it would still, I think, be way lower than $2000 and the driver would not sit in the memory unprotected.

  • Like 2
Link to comment
Share on other sites

11 hours ago, drac030 said:

It may be, but I am not sure if I am the correct one to direct such requests to. Maybe it would be enough to modify the relocator in AT*.SYS files so that it would load the driver code over the MEMLO instead of under MEMTOP? The MEMLO would go up by some 1.5 KB, but it would still, I think, be way lower than $2000 and the driver would not sit in the memory unprotected.

Wouldn't be that much code change.  It looks like it needs MADS and some atcompiler thing, which it looks like it builds itself. Probably more work to get the build env setup, than actually write the code.

 

And I see why XIO 24/25 aren't doing anything in xep80handler.s.  That'd require 'figuring out' looks like.

 

cmd18:
cmd19:
        rts

Link to comment
Share on other sites

On 3/14/2021 at 12:53 PM, cathrynm said:

I give the altxep8*.sys drivers credit for opening my eyes about this hardware.  It has potential to be 'actually okay' for tinkering with fujinet commands from SPARTADOS, fussing with files and disks  Would an updated Spartados Driver allow that EDX editor to work on XEP80?

Of course it does! ?

 

Almost ALL of my "console-mode" work (SDX maintenance, file copying, quick editing, small assembly + Basic programming, etc.), I actually do with XEP80 crisp, clear output, with almost 100% visibility of 24 lines (on PAL mode, as my analog-to-digital video-path + screens can transparently handle both formats), which operationally speaking is enough for E:S: to work.

 

EDX on SpartaDos requires RC_GR8.SYS or VBXE drivers to work. It seems it calls upon them, directly, and as far as I can see, such implementation model does not seem compatible with XEP80 drivers nor the way they address the editor-screen, itself. 

 

I guess EDX would have to be re-written so it addresses editor via E: driver, instead? On its absence, I actually use FastBasic (FB.COM) as a de-facto E: 80-col editor, which works well with XEP80. Slower, but does work, and can handle larger files.

Edited by Faicuai
Link to comment
Share on other sites

12 hours ago, drac030 said:

It may be, but I am not sure if I am the correct one to direct such requests to. Maybe it would be enough to modify the relocator in AT*.SYS files so that it would load the driver code over the MEMLO instead of under MEMTOP? The MEMLO would go up by some 1.5 KB, but it would still, I think, be way lower than $2000 and the driver would not sit in the memory unprotected.

Well, I tried using the embedded relocator facilities, as they are.

 

First, cleared base RAM and then issued "load /L N {altxepup.sys}" command to park driver/installer @ $3400.  Then brought down $6A and  $02E4 to $15 with SDX poke command (MEM /x reports a $0EFF bottom, which suggests I can start loading the driver as low as $1000, so $1000-$1500 should be a good space). Also attempted to adjust $02E5 and $02E6 with the intention to invoke installer with RUN $3400 command... but immediately got a SDX "out of memory" (infinity-loop) message. Could not even force-launch the installer with those memory boundaries.

 

....Plus not really sure if when interacting with SDX via live, command-processor session, I actually have $1000-$1500  free for real...

 

With my preliminary knowledge of SDX active memory-management, I am not really sure how that driver could be installed down there (where I seemingly can)...

Edited by Faicuai
Link to comment
Share on other sites

35 minutes ago, Faicuai said:

Well, I tried using the embedded relocator facilities, as they are.

 

First, cleared base RAM and then issued "load /L N {altxepup.sys}" command to park driver/installer @ $3400.  Then brought down $6A and  $02E4 to $15 with SDX poke command (MEM /x reports a $0EFF bottom, which suggests I can start loading the driver as low as $1000, so $1000-$1500 should be a good space). Also attempted to adjust $02E5 and $02E6 with the intention to invoke installer with RUN $3400 command... but immediately got a SDX "out of memory" (infinity-loop) message. Could not even force-launch the installer with those memory boundaries.

 

....Plus not really sure if when interacting with SDX via live, command-processor session, I actually have $1000-$1500  free for real...

 

With my preliminary knowledge of SDX active memory-management, I am not really sure how that driver could be installed down there (where I seemingly can)...

Did you modify the relocator code in the driver to relocate all the jmp/jsr to be lower? 

 

I speculate, maybe if you set memtop to be the top of the place you wanted it to be, loaded the driver, then put memtop back, it would relocate itself lower in memory?  (This would be massive hacky though.) Best to build from the source instead.

Link to comment
Share on other sites

2 hours ago, Faicuai said:

Almost ALL of my "console-mode" work (SDX maintenance, file copying, quick editing, small assembly + Basic programming, etc.), I actually do with XEP80 crisp, clear output, with almost 100% visibility of 24 lines

Is there a driver setting that can fix the overscan issue on the XEP80?  It's supposed to display 25 lines of text.  I thought you said before you had hardware that proved the XEP80 did not overscan because you could display all of it?  My Sony PVMs will easily display 240 lines in both PAL and NTSC without going into underscan mode, but the XEP outputs far outside of this area.  So just wondering, hardware or software issue?

 

P.S.

Another of the many bonuses of the VBXE.  Besides 80 columns in colour, it doesn't overscan at all, and we have a compressed text mode, so we can get 32 lines of text perfectly visible.

Link to comment
Share on other sites

It'd probably be easier to write a SpartaDOS X variant than to manually relocate to MEMLO, as you need access to SDX library calls in order to properly hook into SDX anyway. Issue is that the SDX relocator doesn't support all types of relocations, so the relocator would need to be modified. But that would also reduce the need for separate executables, as the PAL and VHOLD options could just be enabled on the command line.

 

As for XEP80 overscan, XEPVHOLD.COM on the Additions disk will reduce the XEP80's character cell from 10 lines to 9 lines, which reduces the active area from 250 lines to 225 lines. It's only temporary, though, as it will be lost whenever a master reset is issued to the XEP80. Making it permanent requires assistance from the driver to auto-issue the reprogram sequence.

 

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

On 3/13/2021 at 11:57 PM, phaeron said:
  • Debugger: Added Step Over support for JSR (abs, X), JSL, and MVN/MVP instructions.
  • Debugger: Added .loadstate and .savestate commands.
  • Debugger: Added go cycle relative (gcr) command.

 

Phaeron, please add to the debugger GUI wishlist: "Run to Cursor". I find this feature extremely useful

Link to comment
Share on other sites

What's the best way to manage multiple INI file configurations? The idea was to have multiple Altirra.ini files in different folders so that I could overcome the inability of registry-based profiles to switch firmware and NVRAM along with everything else when changing from one profile to another (this is becoming rather cumbersome when I'm preparing firmware for release on multiple different build targets). So: I started Altirra with the /portable switch expecting it to dump an INI file in the working directory or the program files directory, but it did neither. I eventually figured out that it was trying to put the INI file in the folder containing the executable (i.e. Program Files) but needed admin privileges to do so.

 

But I'm still not sure how I switch between different INI files. Does the INI file have to be in the same folder as the emulator executable? This would mean I'd have to put copies of the EXE as well as the INI files in the different 'profile' folders. I can see why it would work this way, but being able to specify the INI file path is really what I was looking for.

 

EDIT: I guess what I need here is /portablealt:<file>. Ahhh... :)

 

Yes - that appears to have worked. Sorry for noise.

Edited by flashjazzcat
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...