Altirra 3.90 released

[phaeron]

1 hour ago, _The Doctor__ said:

huh it can support it...  oh it's a quibble over 'built in' yeah poor choice of words. the chip itself supports it last I knew.

It can handle 64k by 16 bits RAM and color. It could bank switch as well. It would be nice to see it's full potential.

Take look at the data sheet...

You can add external logic to drive extra attributes to add color, but that's not really the same as the NS405 handling it. It's basically using the NS405 as an address counter. You could do the same thing with ANTIC and add extra RAM banks that are addressed in parallel to drive 24-bit RGB, but that wouldn't really be ANTIC supporting 24-bit color.

 

1 hour ago, _The Doctor__ said:

It's said that The XEP80 can actually display up to 256 character columns but only 80 are available at a time and window basic on it's examples disk show that.

The XEP80 supports a virtual screen with up to 256 columns, and it has commands to horizontally scroll. There's not really much use for it, though.

 

1 hour ago, _The Doctor__ said:

It's also said that the XEP80 in ATARI BASIC still has a maximum of three lines per programming line number but now three lines equals 240 characters instead of 120. So would it be easier to program those 10 liners games on a real Atari without issues.

The 120 character limit is from the standard E: device, which has a limit of three physical lines per logical line. The XEP80 doesn't have this limit, but the input line buffer in BASIC is only 255 bytes.

 

[_The Doctor__]

so 15 more might be crammed in but the XEP display is doubling the 120 of E: ...

the Atari needs an 85 character per line display device then just to give enough +/- space to line things up withe the BASIC buffer and make it tidy.

 

Nice hacking ideas and thought direction Avery. I appreciate that.

Edited March 24, 2021 by _The Doctor__

[Kr0tki]

8 minutes ago, phaeron said:

You can add external logic to drive extra attributes to add color, but that's not really the same as the NS405 handling it. It's basically using the NS405 as an address counter. You could do the same thing with ANTIC and add extra RAM banks that are addressed in parallel to drive 24-bit RGB, but that wouldn't really be ANTIC supporting 24-bit color.

Yeah, that's what I meant. I am aware that Mathy liked to mention in the various XEP80 threads that the NS405 supports "as many colors as you want" and that the Atari designers screwed the XEP80 up by disabling this readily-available feature, but that is stretching the reality. The NS405 by itself has no concept of colours - what it has is a built-in extensibility that, with an addition of external attribute RAM and colour circuitry, would allow it to drive a colour display. Atari did not add the colour circuitry to keep the costs down, but it does not mean it was some kind of a major screw up.

[_The Doctor__]

It still  can be done, that's the point.

[Shannon]

20 hours ago, cathrynm said:

https://www.amazon.com/gp/product/B08HS4J6P4/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1

And my $10 Amazon RF Video to HDMI dongle actually shows descenders in PAL mode now.  This same monitor crops in with RF in PAL mode and the retrotink generates an unviewable signal in PAL.  But this, first time I've ever seen descenders and 24 lines.

Do you know if that amazon HDMI adapter can properly display a signal from the Nintendo gamecube?

[cathrynm]

52 minutes ago, Shannon said:

Do you know if that amazon HDMI adapter can properly display a signal from the Nintendo gamecube?

I'd check, but my GameCube is down at my father's house right now.

[drac030]

This topic seems to be a temporary center of xepism on this forum, so I will post here: while playing with XEP I found a bug in MAE 1.3 (the macroassembler by John Harris) which (the bug) makes using MAE with XEP very painful and practically impossible.

 

I have attempted at patching it and the result of that attempt is available for download at my website (in the "Fixes" section), if anyone is interested.

 

[_The Doctor__]

http://drac030.krap.pl/en-fixes.php

 

[Suppawer]

Hi phaeron.

I'm looking for your latest "Altirra Programming Reference" pdf file.

[+Stephen]

Not sure if this is the latest version, but here ya go.

PRMan-20190309.pdf

[Mclaneinc]

wrong manual, post deleted

Edited March 26, 2021 by Mclaneinc

[Roydea6]

@suppawer

http://www.virtualdub.org/downloads/Altirra Hardware Reference Manual.pdf

 

 

[+Stephen]

35 minutes ago, Roydea6 said:

@suppawer

http://www.virtualdub.org/downloads/Altirra Hardware Reference Manual.pdf

 

 

Thanks - but that is the Hardware Reference manual.  Avery has started a Programmer's Reference manual.

[phaeron]

Operative word is started, need to do a bunch of work on it. Found several errors in the SDX executable format section a couple of days ago, for instance. I think the version above is the only one I've posted so far.

 

 

[ldelsarte]

7 hours ago, phaeron said:

Operative word is started, need to do a bunch of work on it.

Thanks anyway for this "preliminary" version. To quote a famous book series "This book should have been in the box".

[mr-atari]

I think I found a bug in ATBasic 1.57

While coding/debugging LiteDOS

It goes like this:

SAVE to disk and we get an error like 162, disk full.

IOCB #7 is not closed, data still in the disk-buffer.

I swap disk.

DIR to see if there is room.

IOCB is closed, DOS writes its buffer to (the new) disk,  and re-opens for DIR.

Oops?

 

Compared to Atari BASIC, it closes the IOCB immediately following a SAVE-error.

 

Grtz,

Sijmen.

 

[phaeron]

19 hours ago, mr-atari said:

I think I found a bug in ATBasic 1.57

While coding/debugging LiteDOS

It goes like this:

SAVE to disk and we get an error like 162, disk full.

IOCB #7 is not closed, data still in the disk-buffer.

I swap disk.

DIR to see if there is room.

IOCB is closed, DOS writes its buffer to (the new) disk,  and re-opens for DIR.

Oops?

 

Compared to Atari BASIC, it closes the IOCB immediately following a SAVE-error.

Ah, thanks, I'll fix that. The way Atari BASIC does this is a bit weird, so I'll have to review all of the I/O paths for this (ugh).

[phaeron]

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

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

• Fixed a bug with BOOT850 on the Additions disk leaving CRITIC set on failure, which manifested as key repeat not working.
• New experimental debug link device and ATDEBUGX.SYS driver for SDX, which uploads SDX symbols to the debugger.
• Added XEP80 prefetch quirk emulation and fixed incorrect horizontal sync value.
• Added Atari 1090 80CVC and Bit 3 Full-View 80 emulation.
• Improved support for additional video outputs, which are now enumerated in the Video Outputs sub-menu. There is now also a command for switching to the previous video output.
• Added detection for 1050 rev. H firmware.
• Fixed a couple of issues with tape sample/second timestamping in the History view, and it now also works after the tape has been stopped.
• The cassette tape indicator now switches from Play to T-Play when KSO Turbo 2000 is activated.
• Added a new turbo tape decoder that is level-based instead of slope-based and uses a linear phase high pass filter. There is now also an advanced configuration variable for the cutoff of the old slope filter HPF.

[+DrVenkman]

15 minutes ago, phaeron said:

Added Atari 1090 80CVC and Bit 3 Full-View 80 emulation.

Wow. ?

 

Thanks, Avery. Your tireless work (obsession?) in emulating every aspect of the A8 architecture and ecosystem is incredible. 

[Faicuai]

1 hour ago, phaeron said:

Bit 3 Full-View 80 emulation

A-ha!!!! SICK !!! ??

 

The Bit3 vertical scan seems to be an even worse offender than XEP80...

 

I just wonder what degree of flexibility / tuning its firmware / hardware offers, though...

 

I will try this version, and compare to my actual Bit3's output...

 

KUDOS !!

[phaeron]

I actually had both of these emulated already as custom devices, though I hadn't shipped the Bit 3 version much (the 1090 80 CVC is one of the samples in the extras folder). As these versions are implemented natively in the emulator, they have integration into the firmware manager and the CRTC support is improved with video timing computation.

 

The 80 CVC has a jumper in the schematic to switch between the halves of the character set ROM for standard and international ATASCII; this is not yet exposed.

 

1 hour ago, Faicuai said:

The Bit3 vertical scan seems to be an even worse offender than XEP80...

 

I just wonder what degree of flexibility / tuning its firmware / hardware offers, though...

 

I will try this version, and compare to my actual Bit3's output...

The Bit 3 does vertically overscan with 240 vertical lines in the display region. It uses a 6845 derivative, so its video timing is more flexible than the XEP80's NS405 and comparable to many other 80 column video displays of the time. There would be no issue with programming a shorter character cell for NTSC, but it's a question of whether the font would be cut off. PAL should be easily doable, and if you can reprogram the EPROMs it would be permanent (though possibly sacrilege).

 

The Bit 3 also scrolls faster than the 80 CVC, because it uses hardware scrolling. However, operations that move lots of text and don't scroll the whole screen, like insert/delete line, are slower because the Bit 3's access to VRAM is relatively slow through a transparent access latch. The 80 CVC uses a unique write-through window where main memory shadows VRAM and both reads and writes are full speed, and from the schematic it seems to fully interleave CPU access for snow-less writes. This means that the 80 CVC has a regular framebuffer in main memory like the E:/S: device. Unfortunately the firmware is a bit half-baked, as it locks up under certain screen editor operations. It also has overhead for entering and exiting through the PBI interface, though it also has a flat 2K firmware window vs. Bit 3's cramped 256 byte bankswitching scheme.

[_The Doctor__]

15 minutes ago, phaeron said:

I actually had both of these emulated already as custom devices, though I hadn't shipped the Bit 3 version much (the 1090 80 CVC is one of the samples in the extras folder). As these versions are implemented natively in the emulator, they have integration into the firmware manager and the CRTC support is improved with video timing computation.

 

The 80 CVC has a jumper in the schematic to switch between the halves of the character set ROM for standard and international ATASCII; this is not yet exposed.

 

The Bit 3 does vertically overscan with 240 vertical lines in the display region. It uses a 6845 derivative, so its video timing is more flexible than the XEP80's NS405 and comparable to many other 80 column video displays of the time. There would be no issue with programming a shorter character cell for NTSC, but it's a question of whether the font would be cut off. PAL should be easily doable, and if you can reprogram the EPROMs it would be permanent (though possibly sacrilege).

 

The Bit 3 also scrolls faster than the 80 CVC, because it uses hardware scrolling. However, operations that move lots of text and don't scroll the whole screen, like insert/delete line, are slower because the Bit 3's access to VRAM is relatively slow through a transparent access latch. The 80 CVC uses a unique write-through window where main memory shadows VRAM and both reads and writes are full speed, and from the schematic it seems to fully interleave CPU access for snow-less writes. This means that the 80 CVC has a regular framebuffer in main memory like the E:/S: device. Unfortunately the firmware is a bit half-baked, as it locks up under certain screen editor operations. It also has overhead for entering and exiting through the PBI interface, though it also has a flat 2K firmware window vs. Bit 3's cramped 256 byte bankswitching scheme.

I got a little confused at the end of this... could you clarify 2k firmware window/256 byte bank... who's who?

[Faicuai]

13 minutes ago, _The Doctor__ said:

256 byte bank

Bit3, Doc!

[Faicuai]

32 minutes ago, phaeron said:

PAL should be easily doable, and if you can reprogram the EPROMs it would be permanent (though possibly sacrilege).

This is a real possibility... I just need to wait for eBay next week (possibly my 2nd Bit3 someone sold bundled on a cheap 800 without really knowing what they were doing.... ?)

[dely]

16 hours ago, phaeron said:

• The cassette tape indicator now switches from Play to T-Play when KSO Turbo 2000 is activated.
• Added a new turbo tape decoder that is level-based instead of slope-based and uses a linear phase high pass filter. There is now also an advanced configuration variable for the cutoff of the old slope filter HPF.

Thanks! ??