What application would you like to see on the A8?

[Bryan]

I like the Norton Commander idea too. I had thought of doing one with Player-colored windows and a 6x8 soft-font to get more text real estate. Of course, that means it's going to eat more RAM.

[drac030]

A REAL SpartaDOS Hardisk defrag, directory repair, file recovery, etc. utility..

 

In my opinion, a defragmentation program is not really needed, as the SpartaDOS filesystem is fairly fragmentation-proof; that is, fragmentation does not really slow the I/O operations down (contrary to the PC FAT FS, where fragmentation may double the number of sectors to be accessed to read a file).

 

As for the other utilities, there is Eddy: http://atariki.krap.pl/index.php/Eddy It basically has all disk editing functions DiskRx has, the file editing part is for now missing. Of course, I can also add more advanced functions for directory edit, just tell me, what you want to have there.

 

Might also add the ability to make compressed backup images of drives..

 

I don't know if you have seen this: http://atariki.krap.pl/index.php/TAR Sure it doesn't compress, but it nevertheless archivizes directories and files and stores them in Unix-compatible format, easily unpackable on PC.

 

Another thing that would REALLy rock is a seriously powerful file manager like Norton Commander or QDOS was on the PC..

 

80-column display is needed for that. Now, when there is VBXE, this of course is not any problem anymore, such software is possible.

[flashjazzcat]

80-column display is needed for that. Now, when there is VBXE, this of course is not any problem anymore, such software is possible.

VBXE's 80 column display and multi-coloured text will undoubtedly allow for a very accurate looking version of Norton/PC Tools. However, we can get by with software displays in the meantime:

 

 

Full SDX file listings side by side... admittedly VBXE will look much better, but this will do for those who don't have the hardware. I hope SDX's console driver will work transparently in software/hardware 80 column mode depending on the platform. This would allow the same software to use the optimum display without reconfiguration (assuming the applications were properly written).

Edited September 21, 2009 by flashjazzcat

[Mathy]

Hello Allan

 

It would be cool to be able to read a USB CD Drive.

 

Would a SCSI CD Drive suffice?

 

I've even booted my Atari off one. Via my BlackBox. No fancy hardware needed. Except for the CD or DVD ROM drive.

 

Check out this page and this page.

 

greetings

 

Mathy

 

PS I've played music CD's on my Atari too. Even those your PC or Mac will not play.

[drac030]

I hope SDX's console driver will work transparently in software/hardware 80 column mode depending on the platform.

 

Sure, that's the intention. BTW. please take a look at the latest VBXE driver, I have changed its API in the point that may matter for you (i.e. the low level jump table, in XIO.TXT).

[flashjazzcat]

Sure, that's the intention. BTW. please take a look at the latest VBXE driver, I have changed its API in the point that may matter for you (i.e. the low level jump table, in XIO.TXT).

Thanks - checking that out now.

[+Allan]

Hello Allan

 

It would be cool to be able to read a USB CD Drive.

 

Would a SCSI CD Drive suffice?

 

I've even booted my Atari off one. Via my BlackBox. No fancy hardware needed. Except for the CD or DVD ROM drive.

 

Check out this page and this page.

 

greetings

 

Mathy

 

PS I've played music CD's on my Atari too. Even those your PC or Mac will not play.

Hey Mathy,

The only problem is not many people have a Blackbox. Classic's USB cart is cheap and available. It also would be a easier to use since you don't have to mess around with SCSI stuff to get it to work (not hard but can be annoying to get to work).

 

Allan

[STE'86]

tbh i think the most useful app u guys could wish for is VICE for the a8.

 

Steve

[+David_P]

Hmm... how about a spreadsheet that reserves the 16K bank-switching area for data - so one sheet could be spread across multiple tabs, each one occupying 16K in memory?

 

A Norton-esqe program would be nice - but I do worry that the software 80 columns in GR.8 takes away too much memory - the Flickerterm type display, though less pleasing to the eye does only require 2K (Screens) +1K (charset) + program overhead. I think Ken Siders put together an S: and E: package based on the Flickerterm concept that's on the web somewhere (with source code).

 

Other thoughts: a "new" Diamond would be nice - one that doesn't require one of the few original carts (still can't believe I sold mine - what was I thinking?) or an Atarimax cart. Given that the programmer's guide defines the know subroutines, it should be possible to build a new version from the ground up that maintains backwards compatibility - and better yet, could be build on the GPL, permitting everyone to contribute to minor (and not so minor) upgrades and improvements. (So once Bob gets around to releasing that 65816 high-speed upgrade...)

[StaxX28]

Seriously, the A8 needs a full POKEY and GTIA supporting sound tool. It's waiting now more than 30 years to be unleashed....

yes, really necessary !!

[flashjazzcat]

Hmm... how about a spreadsheet that reserves the 16K bank-switching area for data - so one sheet could be spread across multiple tabs, each one occupying 16K in memory?

 

A Norton-esqe program would be nice - but I do worry that the software 80 columns in GR.8 takes away too much memory - the Flickerterm type display, though less pleasing to the eye does only require 2K (Screens) +1K (charset) + program overhead. I think Ken Siders put together an S: and E: package based on the Flickerterm concept that's on the web somewhere (with source code).

 

Other thoughts: a "new" Diamond would be nice - one that doesn't require one of the few original carts (still can't believe I sold mine - what was I thinking?) or an Atarimax cart. Given that the programmer's guide defines the know subroutines, it should be possible to build a new version from the ground up that maintains backwards compatibility - and better yet, could be build on the GPL, permitting everyone to contribute to minor (and not so minor) upgrades and improvements. (So once Bob gets around to releasing that 65816 high-speed upgrade...)

A spreadsheet along those lines would be an interesting challenge. I've never been much of a spreadsheet fan in general, but I'll have a look at what's on offer at the moment for the Atari when I get the chance. That'll give a good idea of what has/hasn't been accomplished so far.

 

The Flickerterm display is a great solution where RAM's at a premium, but with extended memory being so commonplace these days, why put up with a flickering display when you can have a rock-steady 80 column screen which runs nearly as fast? 10K for LW's dual 40/80 column screen display certainly was a painful sacrifice, and it would have been great to use Antic extended mode to leave more main memory freed up (can't be done for a variety of reasons), but at the end of the day you're depending on extended RAM either way so the best direction is probably to start putting the code in the extra memory. That's a little more challenging than using RAM under the OS but I see no reason these days why we can't accomodate the large bitmapped displays in our apps. VBXE2 will open up many more interesting possibilities, since it has its own display RAM.

 

A "New" Daimond GOS is really top of my list but there are several obstacles to overcome before I get started on it. I had hoped to get hold of the original source code but I'm still waiting on that and whether or not it materializes will have a big impact on which direction the project takes. I also need a proportional font rendering engine (and a way of transferring fonts in bulk from other platforms) but ideas and code contributions have been thin on the ground. Certainly the thing will be a community effort, since I'm not keen to write all the apps as well as the GUI. Compatibility with the original Diamond hooks and calls is a low priority in my opinion, because there were only two or three apps ever written for the system so it's not as if we have a large back-catalogue of software we need to be backwards compatible with.

[+David_P]

Other thoughts: a "new" Diamond would be nice - one that doesn't require one of the few original carts (still can't believe I sold mine - what was I thinking?) or an Atarimax cart. Given that the programmer's guide defines the know subroutines, it should be possible to build a new version from the ground up that maintains backwards compatibility - and better yet, could be build on the GPL, permitting everyone to contribute to minor (and not so minor) upgrades and improvements. (So once Bob gets around to releasing that 65816 high-speed upgrade...)

 

A "New" Daimond GOS is really top of my list but there are several obstacles to overcome before I get started on it. I had hoped to get hold of the original source code but I'm still waiting on that and whether or not it materializes will have a big impact on which direction the project takes. I also need a proportional font rendering engine (and a way of transferring fonts in bulk from other platforms) but ideas and code contributions have been thin on the ground. Certainly the thing will be a community effort, since I'm not keen to write all the apps as well as the GUI. Compatibility with the original Diamond hooks and calls is a low priority in my opinion, because there were only two or three apps ever written for the system so it's not as if we have a large back-catalogue of software we need to be backwards compatible with.

 

My only reason for suggesting backwards compatibility was to permit other developers to begin working on apps with a known interface in place, and not be sitting waiting for the new ("Zirconia"?) one to come out.

[flashjazzcat]

My only reason for suggesting backwards compatibility was to permit other developers to begin working on apps with a known interface in place, and not be sitting waiting for the new ("Zirconia"?) one to come out.

Ah - I understand. That makes good sense. It really rests with the author of Diamond: If I can get hold of the source code, the new version will be very much in the spirit of the old one. On the other hand, if I end up writing something from scratch, I think it will be fundamentally different and probably won't support overlapping windows, resizing, etc. I'll get in touch with Alan again and see what's happening...

[Mathy]

Hello flashjazzcat

 

If Alan Reeve doesn't answer, you might consider contacting Mirko Sobe. He wrote something simular, but in Turbo Basic. Here's a video that shows some of the features of BOSS-X.

 

greetings

 

Mathy

[flashjazzcat]

If Alan Reeve doesn't answer, you might consider contacting Mirko Sobe. He wrote something simular, but in Turbo Basic. Here's a video that shows some of the features of BOSS-X.

Boss-X is surely one of the more impressive cracks at a GUI of recent years. It's very slow, however (no doubt in part because it's written in Basic), and appears to be short of applications which run using its own API. These tend to be the two main downfalls of Atari 8-bit GUIs, and are the two main problems I'd eventually like to address.

 

In the meantime, who'd like to see a new word processor for the Atari...? My flu's getting better. Soon...

[+David_P]

In the meantime, who'd like to see a new word processor for the Atari...? My flu's getting better. Soon...

 

A new one? I'm still waiting for the final version of The Last Word!

[flashjazzcat]

A new one? I'm still waiting for the final version of The Last Word!

LOL - I walked into that one.