Jump to content
IGNORED

Altirra 3.20 released


phaeron

Recommended Posts

On 3/26/2020 at 10:44 PM, phaeron said:

Have you looked at the license?

 

 

On 3/27/2020 at 9:39 AM, Stephen said:

There's a link to the source with every release.

I see now, thanks. I just couldn't find it on github or by googling for it. Is there any public code repository online to look at current progress, history, and even contributing?

Link to comment
Share on other sites

1 hour ago, Raul said:

 

I see now, thanks. I just couldn't find it on github or by googling for it. Is there any public code repository online to look at current progress, history, and even contributing?

The repository I use for Altirra is offline and private, but binaries and source code for all releases is on the home page.

 

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

The scope selection determines where the key shortcut is active -- it's so that the debugger windows can have different shortcuts from the main emulator. It doesn't change the effect of the bound command. Global means that the keyboard shortcut works from any of the program windows. Most default keyboard shortcuts have global scope because it's less confusing to the user, except for commands that have obvious contextual behavior like toggling a breakpoint at the cursor.

 

  • Like 1
Link to comment
Share on other sites

Is it possible that generic disk drive emulation (File -> Disk drives -> Emulation level -> Generic emulation / Generic emulation + 57600 baud / Fastest possible (128 kbps)) offers somewhere in the emulator settings a tunable Pokey divisor? If so, it would greatly facilitate testing serial drivers. Many thanks in advance.

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

On 4/11/2020 at 12:46 PM, drac030 said:

Is it possible that generic disk drive emulation (File -> Disk drives -> Emulation level -> Generic emulation / Generic emulation + 57600 baud / Fastest possible (128 kbps)) offers somewhere in the emulator settings a tunable Pokey divisor? If so, it would greatly facilitate testing serial drivers. Many thanks in advance.

Currently, there isn't an option to select explicit divisors, as the entries in that list have correlated to actual hardware. You can, however, choose other drives in that list that have US Doubler compatible high speed modes and the emulator will switch to the high speed index supported by those drives. Could you provide more details on specific divisors you are interested in that are not currently included?

 

Also, the new custom device support may suffice here. I've attached a custom device to emulate a single-density disk with high speed support on 3.90-test20. To use it, place a single-density ATR in disk.atr next to this file, then add a Custom Device in System > Configure System > Devices with rawdiskhs.atdevice as the description file. Make sure that Fast Boot and SIO D: patch are turned off. It's a relatively simple disk device that supports the high-speed and PERCOM block commands and buffers writes in memory. The advantage of this custom device is that the high-speed divisor and timing can be modified as needed without requiring modifications to the emulator, especially for unique testing scenarios that might not make sense as a main feature.

 

rawdiskhs.atdevice

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

2 hours ago, phaeron said:

You can, however, choose other drives in that list that have US Doubler compatible high speed modes and the emulator will switch to the high speed index supported by those drives

Sure, but unless I am missing something obvious, these other drives work with divisors no smaller than 8. Indus, when programmed, uses 6, and there is no other option remaining but 0. There is no possibility to set divisors like 7, 6, 5, 4, 3, 2, 1 for a generic US Doubler-compatible drive. I just thought that instead of multiplying the "Generic emulation" entries in File->Disk drives (there are three of these now), it might perhaps be more convenient to provide one generic entry with tunable divisor. But of course there may be reasons (I am not aware of) to avoid that.

 

By the way, there are real drives which use divisor 4, like this one http://atariki.krap.pl/index.php/XFD602

 

2 hours ago, phaeron said:

The advantage of this custom device is that the high-speed divisor and timing can be modified as needed without requiring modifications to the emulator, especially for unique testing scenarios that might not make sense as a main feature.

It is not perfect, but for testing purposes it is more than enough. Thank you very much.

  • Like 2
Link to comment
Share on other sites

Try this version:

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

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

  • Percom AT-88 V1.2 ROM added to firmware autodetect list.
  • Fixed a bug with script threads in custom devices where the scheduler would screw up with multiple ready threads.
  • 6809 disassembler no longer prints branch targets >$10000.
  • rawdiskhs.atdevice is now one of the samples.
  • Fixed a bug in the FDC where the force immediate interrupt ($D8) command was not triggering an interrupt when interrupting another command, which was causing the Indus GT firmware to hang on a Read Address command with no disk in the drive.

Indus GT should have still worked if a disk was in the drive on cold reset; LMK if you're still seeing the hang. The drive should also still do the power-up seek regardless. I have seen cases where the Indus GT might not init quickly enough if you have an OS that boots too fast, so if it's just missing the boot then increase the power-up delay.

 

  • Like 9
Link to comment
Share on other sites

Thanks, Indus GT is working fine again in test31!

 

I did some more tests and it seems the issues in test28-30 were triggered by MFM disks (I had a 180k DD ATR in the drive), 90k/FM disks worked fine. I tested with stock XL/XE OS rev 2, no other specific options, cold booting only the Atari didn't work either.

 

Log in the debugger showed that the drive stepped fine on powerup but the last line was the FDC switching to FM

FDC: Physical track is now 0.0
DISKEMU: Stepper phases now: 0
DISKEMU: Stepper phases now: 8
DISKEMU: Stepper phases now: 1
DISKEMU: Stepper phases now: 8
DISKEMU: Stepper phases now: 1
DISKEMU: Stepper phases now: 0
FDC: Density encoding now set to FM

 

With test31 the drive is now switching correctly to MFM:

DISKEMU: Stepper phases now: 1
DISKEMU: Stepper phases now: 0
FDC: Density encoding now set to FM
FDC: Density encoding now set to MFM
...

 

so long,

 

Hias

  • Like 2
Link to comment
Share on other sites

9 minutes ago, antrykot said:

A couple of examples

Please excuse a nag, but I would recommend using 'xex' as the extension for any binaries you produce as 'com' has long since been less used due to a main proportion of people downloading to a PC where that extension has its own association.

Link to comment
Share on other sites

19 hours ago, phaeron said:

Try this version:

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

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

  • Percom AT-88 V1.2 ROM added to firmware autodetect list.
  • Fixed a bug with script threads in custom devices where the scheduler would screw up with multiple ready threads.
  • 6809 disassembler no longer prints branch targets >$10000.
  • rawdiskhs.atdevice is now one of the samples.
  • Fixed a bug in the FDC where the force immediate interrupt ($D8) command was not triggering an interrupt when interrupting another command, which was causing the Indus GT firmware to hang on a Read Address command with no disk in the drive.

Indus GT should have still worked if a disk was in the drive on cold reset; LMK if you're still seeing the hang. The drive should also still do the power-up seek regardless. I have seen cases where the Indus GT might not init quickly enough if you have an OS that boots too fast, so if it's just missing the boot then increase the power-up delay.

 

I've been working with the XEP80 (Fast) driver provided on Additions and it is, indeed, pretty fast on REAL XEP80 hardware (I have benchmarked it and it turns out to be faster than an even accelerated OS E: handler on 40-col. mode !!!)

 

Have been also looking at its source code directly, and found already a way to adjust margins, etc... But following its logic, I can't find the right spot to switch to PAL (50 Hz) by injecting command $D7 maybe after master reset (?). And that on its own would be really strategic because, if it is anything like SDX's own XEP80 driver (which it can), it will provide not just increased vertical resolution but (also) vertical compression of character-font, thus making last screen-line even more readable that what I am getting at 60 hz.

 

The main problem here is that the XEP80 video-processor essentially mis-manages available bandwidth on NTSC... makes poor use of it horizontally (seems to leave plenty on the table), and also misplaces the whole frame vertically, by apparently wasting the first top -5 scan-lines and rendering them empty / black.

 

Thanks, by the way, for such great work, as usual!

Edited by Faicuai
(Test target, PAL-50Hz command)
Link to comment
Share on other sites

can we use the xep80 additions driver with a real xep80, is it changed from puffs fast xep80 driver, and is it 60 hz... Is this documented somewhere I can find quick, new laptop just quick pointer to the info. I certain it's in the voluminous documentation somewhere

 

Link to comment
Share on other sites

10 hours ago, antrykot said:

Hi, everyone!

 

A couple of examples demonstrating bugs in Altirra's implementation of pokey's linked timers (they are intended for PAL, but probably work in NTSC as well).

bass14.com 193 B · 5 downloads altirra-bug.obx 91 B · 3 downloads p3-16.com 220 B · 3 downloads p3-16-vibrato.com 298 B · 3 downloads

Thanks, I will look into this. It will probably be for the next version as I am letting the 3.90-test line stabilize and holding risky changes/fixes.

 

17 minutes ago, Faicuai said:

I've been working with the XEP80 (Fast) driver provided on Additions and it is, indeed, pretty fast (I have benchmarked it and it turns out to be faster than an even accelerated E: handler on 40-col. mode !!!)

 

have been also looking at its source code directly, and found already a way to adjust margins, etc... But following its logic, I can't find the right spot to switch to PAL (50 Hz). And that on its own would be really strategic because, if it is anything like SDX's own XEP80 driver (which it can), it will provide vertical compression of font, thus making last screen-line even more readable that what I am getting at 60 hz.

 

The main problem here is that the XEP80 video-processor essentially mis-manages available bandwidth on NTSC... makes poor use of it horizontally (seems to leave plenty on the table), and also misplaces the whole frame vertically, by apparently wasting the first top -5 scan-lines and rendering them empty / black.

There isn't an obvious point to change to switch to PAL because the XEP80 is natively an NTSC device, defaulting to 60Hz on master reset or upon switching to text or graphics mode. You have to issue an additional command to switch it to PAL after the NTSC parameters have been set (commands $9A or $D7); those commands then modify the 60Hz display to 50Hz. Detailed information is in the Atari XEP80 software disk. The Altirra XEP80 driver follows the documented behavior of the Atari driver and largely just passes commands through. If you wanted it to default to 50Hz, it would need additional code added to XEPReset to issue command $D7 to switch to a 50Hz text mode.

 

As for why the display is so whacked on NTSC, it's heavily out of spec with regard to horizontal line count and timing, and it is massively overscanned: 10 rows per character cell with 25 character rows, for 250 line active display. When you consider that ANTIC only allows 240 active lines max and that is generally already into overscan on an NTSC display, you realize how bad this is. It is possible to reconfigure the XEP80's display timing by using undocumented commands to write to the Video Control Register (VCR) and the timing chain, though the NS405's timing parameters are rather inflexible. I did manage once to configure an NTSC display with shorter text rows that fit a bit better by reducing the line height to 9 rows, but this cuts off the descenders unless you also reprogram the character ROM. I can try to recreate this if you are interested, it just takes the right sequence of XIO commands with any standard XEP80 compatible driver.

 

2 minutes ago, _The Doctor__ said:

can we use the xep80 additions driver with a real xep80, is it changed from puffs fast xep80 driver, and is it 60 hz... Is this documented somewhere I can find quick, new laptop just quick pointer to the info. I certain it's in the voluminous documentation somewhere

Yes, it will work on a real XEP80. I've tested it with one I got courtesy of ABBUC. It is not based on the Atari XEP80 driver or Bob Puff's driver. The mechanism by which the fast driver works is unique, I believe -- it modifies the XEP80's UART parameters so the computer can send to it at 31Kbaud instead of 15Kbaud. I had a prototype 4X version that used 63Kbaud that worked in emulation but did not work reliably on real hardware -- haven't gotten around to scoping the joystick signals to figure out why.

 

Altirra's XEP80 driver does have another intentional divergence from Atari's XEP80 driver, which is that it has a workaround for the spaces-at-end-of-line issue in the XEP80: it trims off spaces at the end of a line when reading through E:, for better compatibility with the normal E: driver. This avoids a rather annoying issue with BASIC where you can get spaces at the end of a DATA statement that screw up the program and it is annoying to find or remove them.

 

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

44 minutes ago, phaeron said:

(...)

 

There isn't an obvious point to change to switch to PAL because the XEP80 is natively an NTSC device, defaulting to 60Hz on master reset or upon switching to text or graphics mode. You have to issue an additional command to switch it to PAL after the NTSC parameters have been set (commands $9A or $D7); those commands then modify the 60Hz display to 50Hz. (...) If you wanted it to default to 50Hz, it would need additional code added to XEPReset to issue command $D7 to switch to a 50Hz text mode.

 

(...) I did manage once to configure an NTSC display with shorter text rows that fit a bit better by reducing the line height to 9 rows, but this cuts off the descenders unless you also reprogram the character ROM. I can try to recreate this if you are interested, it just takes the right sequence of XIO commands with any standard XEP80 compatible driver. (...)

 

(...) I had a prototype 4X version that used 63Kbaud that worked in emulation but did not work reliably on real hardware -- haven't gotten around to scoping the joystick signals to figure out why. (...)

 

 

THANKS for the swift and concise response!!

 

Look, almost there!: (notice the top and bottom gray bezel, which the video processor intentionally adds to reveal start and end of video-frame scan in both directions. Notice the top 4-5 scan-lines between gray-border and top-of-characters being wasted!!, without mentioning the substantial amount of h-resolution wasted between left-side bezel (I set it to two pixels-wide) at the first characters on each line. Even so, the entire 80-chars are displayed horizontally:

 

1CE811CA-C0CE-42E0-ACC0-CFEB92C8A16B.thumb.jpeg.d7ed54d8c430c8669be0a4ad155ef69b.jpeg

 

I am all in for whatever is easier for you, the path of least-resistance. Either vertical resizing of Char rows. or (unless SDX uses some special fonts for 50 Hz mode), just adding the code here to switch to PAL 50Hz (I happen to have a video-path with enough bandwidth and equipped with any-to-any time-base conversion capabilities):

 

.proc XEPReset
        lda        #XEPCMD_MASTER_RESET
        jsr        XEPTransmitCommand
        jsr        XEPReceiveByte
        bmi        init_timeout
        cmp        #$01
        beq        init_ok
        ldy        #CIOStatNAK
init_timeout:
        rts

init_ok:
        jsr        XEPResetScreenVars

 

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.

 

Either way, whatever you think it is easier. Would also love to test Turbo_4x which I also saw conditionally included on the code, but not enabled. If there is anything there I can help with, let me know (I have scope-meter, etc.)

 

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!  

Edited by Faicuai
  • Like 1
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...