ACE80 / ACE80XL / DT80 Pre-order

[ACML]

20 hours ago, netcoord99 said:

The ACE80 80 column cartridges are back! Get 80 columns on all your Atari (Fujinet & CP/M) displays! Place your order now at the Vintage Computer Center: https://www.vintagecomputercenter.com/ 

 

How would this function using a stock 1200XL with respect to no internal BASIC.  I have the ClearPic2002 mod, so the S-Video output is excellent.  Since the cartridge slot it already filled with the ACE80XL,  can I still load Atari BASIC using an XEX file version? I already have the Omniview OS and it works great with BASIC. Would the display be much faster or more readable than using Omniview?  What about Assembler Editor? Would I or can I load an XEX version of that while using the ACE80XL?

 

Basic question, how does this compare to the OmniView 80?

     

[NISMOPC]

Just rcvd my ACE80XL (#006) in the mail.  ? THANK YOU @netcoord99

[xxl]

I compared the speed of software drivers:

SpartaDOS X + CON80 + Atari 128K RAM (only works with extended memory)
DOS 2.5 + ACE 80 + Atari 64K RAM

test program:

10 FOR X=1 TO 10000: ? "ATARI",: NEXT X

 

Results:

 

DOS2 ACE80: 1:48

SDX CON80: 3:35

 

in this test the ACE80 turns out to be twice as fast as the CON 80

 

where is the secret of success?

[+Larry]

@NISMOPC

You beat me!  Received mine -- #14!  Nice looking cart!

-Larry

[_The Doctor__]

7 hours ago, xxl said:

I compared the speed of software drivers:

SpartaDOS X + CON80 + Atari 128K RAM (only works with extended memory)
DOS 2.5 + ACE 80 + Atari 64K RAM

test program:

10 FOR X=1 TO 10000: ? "ATARI",: NEXT X

 

Results:

 

DOS2 ACE80: 1:48

SDX CON80: 3:35

 

in this test the ACE80 turns out to be twice as fast as the CON 80

 

where is the secret of success?

directly pointing to os etc vs abstract modular driver?

[ACML]

Just tried same benchmark with Omniview on my 1200XL.  It took 11 minutes 18 seconds.  The BASIC was Rev C.  WOW!

 That's 6.3 times faster than Omniview!

 

[ClausB]

7 hours ago, xxl said:

in this test the ACE80 turns out to be twice as fast as the CON 80

 

where is the secret of success?

Two secrets:

 

Scrolling is much faster since ACE80 moves display list pointers, not bitmap data. 48 bytes vs. 7680.

 

The character set is stored with the same patterns in the high and low nybbles of each byte, so no bit-shifting code is needed. Also the order of the bytes is optimized to reduce look-up index math.

[_The Doctor__]

Does the method break anything or any software. I don't remember it doing so...

[xxl]

I did other tests, I wanted to check the speed of converting coordinates to addresses and the speed of selecting characters from the set (1kb or 512b set).

test2:

10 FOR X=1 TO 10000
20 POSITION 0,0: REM POSIOTION 1,0
30 ? "A";
40 NEXT X
50 GRAPHICS 0

 

ACE: 0:51 / 0:57
SDX: 1:06 / 1:11

test3:

10 F.X=1 to 1000
20 A=RND(0)*70
30 B=RND(0)*20
40 POS.A,B
50 ? "ATARI";
60 N.X
70 GR.0

 

ACE: 0:54
SDX: 0:58

 

in both of these tests, ACE performs better

 

nice.

[ivop]

What does ?FRE(0) say in BASIC? If it takes 12kB of your RAM, that's quite a lot. I assume 8kB mode F/graphics 8, some font data and the actual handler?

 

[xxl]

it obviously depends on the DOS version:

 

 

or

 

[ClausB]

ACE80 uses 12.4K, because it's a resident E: device.

 

7.7K display,

1.9K character buffer,

1.0K character set,

1.8K code.

[drac030]

17 hours ago, ClausB said:

Two secrets:

 

Scrolling is much faster since ACE80 moves display list pointers, not bitmap data. 48 bytes vs. 7680.

 

The character set is stored with the same patterns in the high and low nybbles of each byte, so no bit-shifting code is needed. Also the order of the bytes is optimized to reduce look-up index math.

Actually, the SpartaDOS X driver RC_GR8.SYS works similarly, as I am guessing from your description: DL scrolls, preshifted fonts, lookup tables and such. One of the differences is that all that is stored in the Ext RAM, and another - that the device driver is separated into hardware-independent console driver (CON.SYS) and the video driver which provides an actual access to the hardware (RC_GR8.SYS or S_VBXE.SYS). This involves memory banking and intermodular calls which probably contribute to the fact that SDX drivers are slower. They use little space in the base 64k memory, though (except the screen itself and DL for the Graphics 8 driver).

[Faicuai]

4 hours ago, drac030 said:

Actually, the SpartaDOS X driver RC_GR8.SYS works similarly, as I am guessing from your description: DL scrolls, preshifted fonts, lookup tables and such. One of the differences is that all that is stored in the Ext RAM, and another - that the device driver is separated into hardware-independent console driver (CON.SYS) and the video driver which provides an actual access to the hardware (RC_GR8.SYS or S_VBXE.SYS). This involves memory banking and intermodular calls which probably contribute to the fact that SDX drivers are slower. They use little space in the base 64k memory, though (except the screen itself and DL for the Graphics 8 driver).

The best way to test the RAW speed of RC_GR8.SYS, would be launch CP/M terminal (Trub) and CP/M OS on Indus/GT+Ramcharger.

 

Once there, invoke a TYPE command of a LARGE text file, already on CP/M volume... watch how it FLIES scrolling down on the Atari screen...

 

In basic terms, ACE80 and RC_GR8 are pretty close... and the figure of merit would go to ACE, because it did so over 30 years ago... I actually use RC_GR8 extensively, FYI.

[+Nezgar]

Maybe the next version of CON64 will incorporate a DLI pointer scrolling trick too. ? 

 

Edit: and another cool idea would be ability on machines with separate ANTIC banking still intact to put the RC_GR8 screen buffer in an extended bank, similar to the Omniview AtariWriter patch. Stock 130XE, and Compy-shop style RAM upgrades only, since RAMBO style 256K+ upgrades disabled that.

[drac030]

1 hour ago, Nezgar said:

Maybe the next version of CON64 will incorporate a DLI pointer scrolling trick too.

That driver is pretty old. And a bit buggy as it turned out recently. So the plan is to give it up in favour of 64-column version of RC_GR8, so that one could load CON.SYS on top of that and have 64-column console.

 

1 hour ago, Nezgar said:

another cool idea would be ability on machines with separate ANTIC banking still intact to put the RC_GR8 screen buffer in an extended bank, similar to the Omniview AtariWriter patch.

Alas, SDX quite intensively uses the Ext RAM and needs frequent CPU access to it. And, unfortunately, even on a 130XE or Compy Shop, separate access of CPU and Antic to different Ext banks is, as far as I know, not possible. Both to base RAM - yes. One to base RAM, the other to Ext RAM - yes. Both to the same bank of Ext - yes. Both to different Ext banks - no.

[+Nezgar]

35 minutes ago, drac030 said:

So the plan is to give it up in favour of 64-column version of RC_GR8, so that one could load CON.SYS on top of that and have 64-column console.

Great to hear! I find the 64 columns is a nice compromise on a shadow-mask type colour CRT, but look forward to an improved scrolling speed!

 

37 minutes ago, drac030 said:

separate access of CPU and Antic to different Ext banks is, as far as I know, not possible.

Right of course.. I forgot about that. And probably too complex and CPU ladent to implement a DLI to change and restore banks on the fly...

[drac030]

48 minutes ago, Nezgar said:

a DLI to change and restore banks on the fly...

I can see how a DLI can be used to switch banks and enable the one which is holding DL and screen memory, but when to switch back? We do not have "end of scanline" interrupt. I am afraid that the end result would be the CPU being halted 60% of its time (on PAL - and 80% on NTSC). It would work, of course, but would probably make the whole computer very slow. Unless I am missing some obvious solution.

[drac030]

7 hours ago, Nezgar said:

screen buffer in an extended bank

As I am thinking about it, it might be doable though, even if only in theory: we cannot put Antic and CPU in different Ext banks, but we can put Antic into base RAM, then swap this area with one of the Ext banks (i.e. effectively use one of the banks as the base RAM and vice versa). Then the CPU will still be able to freely access other Ext banks without disturbing the display. In SDX itself it may work, there however will be problems with programs which e.g. assume that portb=$FF enables base RAM or such.

[svhovater]

I'd love to see a screenshot of DT80 working with Sophia2. If anyone has the combo.. thanks!

[netcoord99]

On 10/12/2020 at 8:39 PM, netcoord99 said:

Hi guys! Hey, I was wondering if you all could give me your opinion? Ok, how well do you think the ACE80 / ACE80XL / DT80 80 column cartridges would sell in this day and age? I still own the copyrights and would like to produce more if they are still needed. Is there something out there that has taken their place or are they even needed by Atari users? Thanks!!

 

PS: What would be a fair max price for one of these now considering hardware costs these days?

Ok, the ACE80 cartridges are ready at https://www.vintagecomputercenter.com/ for those of you who want one now. Check out the Fujinet too!

[_The Doctor__]

fujinet 1.3's are fixed and available again then?

[Kyle22]

Is there a DT80.CAR image out there somewhere? I have an Ultimate Cart.

 

[joeventura]

On 1/23/2021 at 7:25 PM, ClausB said:

ACE80 uses 12.4K, because it's a resident E: device.

 

7.7K display,

1.9K character buffer,

1.0K character set,

1.8K code.

 

Re: the DT80 cart for ATR8000, is there a menu or hot keys in the program or is it just a straight terminal that loads the ATR?

 

Thanks

[ClausB]

1 hour ago, joeventura said:

Re: the DT80 cart for ATR8000, is there a menu or hot keys in the program or is it just a straight terminal that loads the ATR?

There are some menu items. Press OPTION, SELECT, START, with or without SHIFT.