List of New Features you would like to see in Atari800WinPlus

[UNIXcoffee928]

OK, Lets use this thread to see what users would like Added or Modified in Atari800WinPlus.

 

 

My personal list so far:

1. A direct RAM transfer method, suitable for data-burst to an external application

2. The HI-RES SUPER 1020 graphics terminal interface that I've defined in this forum

3. CUT/COPY/PASTE to/from windows & the emulator

4. I would like the user to be able to set the file ext of the temp .txt file that gets output by a print command. The current setup interferes with the auto 6502 highlighting of the Notepad replacement, 'Context'. This makes it necessary to manually select syntax highlighting for the 6502, rather than have it auto converted, as it would with a .asm ext.

 

 

Lets make this thread a TO-DO list. Please be very specific.

 

 

L8R,

 

UNIXcoffee928

Edited April 25, 2006 by UNIXcoffee928

[Gury]

Great to see somebody willing to add new features to this excellent emulator. I have one strange wish to be implemented. Ok, you can run Atari programs like executables directly, but I want something else. I introduced Atari and mentioned emulator to some of my friends, but people are sometimes confused how to use it, what to set up and such. So, my TO-DO wish is to generate Win32 executable directly from emulator: no menus, no settings, just an executable file which would be generated from settings you make in emulator (machine type, artifacting, joystick, keyboard, etc.). Is this science fiction? I think it would be great to run pure Atari games on Windows platform without emulator.

[Rybags]

- Config files (like WinUAE), and ability to run with command switches.

 

- Ability to load .XEX without having a coldstart + load .XEX without INIT/RUN (currently hangs?)

 

- Better debugger using Win32 interface. Sprite/chset/graphics ripping ability (maybe best done with a seperate program using savestate files)

 

- DirectX stretch mode (like Gens emulator)

 

- option to run in turbo/slow but keep chipset timings (like WinUAE).

 

- full r/w emulation of flash-cartridges (ie AtariMax)

 

- redirection of specific Dn: devices to Hn: (for software that insists on using the D: device)

 

- fix wildcards for H: device (currently only works with directory)

 

- fix the way the keyboard is emulated. The Atari has one of the worst keyboard scanning mechanisms of any computer (due to one key at a time policy) - there is a better way.

 

Maybe implement copy/paste as a device driver which accesses the clipboard. Type of operation (graphics or text) could be passed/returned by OPEN. That would allow programs to access the facility as well.

 

Pasting into the E: window could be implemented a number of ways. Due to the way editing works though it would probably be best to just pass the clipboard as keystrokes.

[www.atarimania.com]

Two things that, I was told, were being worked on recently but haven't been implemented yet:

- ability to load BASIC files directly without having to use the tape player trick or the LOAD"H:XXXXXXXX.BAS option

- 100% cycle-exact ANTIC / GTIA / CPU timing.

 

--

Atari Frog

http://www.atarimania.com

[Rybags]

Forgot to mention:

 

- cycle-exact POKEY Timers (currently scanline exact).

[Wrathchild]

- full r/w emulation of flash-cartridges (ie AtariMax)

 

I most likely be having a stab at the AtariMax emulation in the

near future, as I've had some thought regarding this, but I may

do this under Atari++ first and then include it into A800Win.

 

There is the small issue of cartridges assumed to be read-only and so

provision for knowing that the contents have changed and so needs

to be saved when the cart is removed has to be added. Also, the

interactions with the user regarding this need to be handled, e.g. use

a popup dialog to ask the user to confirm the save and/or give the

emulator an option to auto-save changes.

 

Regards,

Mark

 

@Gury - yes, its science fiction... way out there...

For that and for Rybags' Config file suggestion - I think 'Save State' files cover both of these?

These are associated with the emulator, so if you click them you run from where you left off.

[carmel_andrews]

how about this

 

in windowed mode, allow for stretching or reduction of window size (like gens and other menu's) as the smaller window size is too small and larger window size is too big

 

As Heaven/TQA mentioned elsewhere, a proper PAL emulator mode, like in VICE emu

 

Emulation of the Black box and proper emulation of the diamond GOS cart (i cant' seem to get my image to work)

 

Emulation of other misc 1050 roms (like happy, lazer, speedy, SA2 etc) and also separate emultion of the xf551, which i understand is only emulated thru the sio patch when enabled

 

A load point counter to supplement the disk/cassette block/sector counter (useful for hacking into ATR's)

 

A proper binary load/save feature instead of the memdump feature in the monitor section

 

to supplement the binary save/load feature a read from and write to sector routine using the info gleamed from the load point/disk sector counter using upto 8 mounted ATR's (again usefull for hacking ATR's)

 

Ability to section unused additional ram (for settings over 64k) if not using a ramdisk use as cartridge ram, as so to emulation for cartridge(s) that use addit. ram (atarimax etc etc)

 

IF using over 64/128k of mem, in the atari mode, to redirect all loads to the addit. pasges of 64k mem, usefull for hacking into programs, because the monitor will allow you to access that page of 64k mem (only the first 64k will contain the atari mem. map) addit. 64k pages will be zero'd

 

One more question Jaskier and other maintainers of this excellent emu...how long or soon will we be getting the next installment (beta) of a800win+

Edited April 25, 2006 by carmel_andrews

[Rybags]

I don't see much point in redirected sector loading.

 

Something like an I/O log file would be good. Each entry could just contain the DCB parameters and return code. With that, program loading could be traced exactly.

 

Full overscan emulation is something I missed earlier - currently widescreen only includes 42 columns.

 

A "flicker fixer" might be worth looking into. Some other emus have it, although I get it for free since my capture card does blending of alternate frames from real input sources.

[UNIXcoffee928]

Excellent ideas!

 

This type of collaborative thinking will really help us to improve the emulator!

 

Anytime a new idea for the emulator pops into your head, this is the place for it!

 

Two more from me would be:

 

1. A screen scrollback buffer, like the one implemented in Winfrotz (The Infocom Z machine parser for Windows).

2. When Misc-->Preferences-->Reuse Emulator Window is selected, a new Notebook Tab opens up, like in the windows editor, "Context", or the Win app, "Flat Assembler".

 

You should check out "Context" as a Notepad replacement. It's quick & painless to install, so the system calls it instead, whenever it calls Notepad. It's best features are 'Vertical Selection', including cut/copy/paste, and a standard 6502 highlighter, which can be defined with your color choices. I set this up with the monospaced 1020 font that I made available for all in my post about the graphics terminal based on the Atari 1020. The result, when setup with a black background & Tempest foreground colors, is like looking at Atari Tempest displaying perfectly aligned assembly code when you print from the emulator. Quite retro-cool & very readable!

 

I really like the idea of setting up application-specific executables, described by Gury. Sort of reminds me of Starkits in TCL/TK. Aside from the ability to pre-package something that you know works, to give to a novice emulator user, it may be possible to create executables with smaller resource footprints than a full emulator running the program. (only using the parts of the emulator that the program needs to be fully operational).

 

When you post , please state if you have any programming experience with any language. Not knowing C++ is not a big deal, if you have programmed in any languge, this ability will allow you to further describe your ideas in pseudocode, which can be easilly implemented in any language.

 

If you have never programmed before, that's ok too. Maybe you've just stumbled into a rewarding hobby!

 

= )

 

 

Keep up with the great ideas!

 

 

L8R,

 

UNIXcoffee928

[ZylonBane]

Just one thing--

 

A proper artifacting mode. The current mode just knocks the horizontal resolution in half.

[a8isa1]

I had my list in UnixCoffee929's other thread.

 

Some of my items are redudant for this thread but I'll repeat those that aren't.

 

- support for physical floppy media and physical Atari drives.

 

- Ultra Speed (3X) SIO emulation perfected, meaning accurate performance.

 

- correct the default colors. Presently I change the Color Shift (in the Pallette menu) to 55. This matches the tint (but not the staturation level) to my real A8s. I've asked a few people and they say 55 works well for them as well.

 

- I don't even have a HD system for my A8's but being able to generate hard disk images or write directly to media that the A8's can use, like CompactFlash or IDE, in the correct format of course, MyIDE, SmartIDE, BB (which I understand can now use IDE drives with the help of an IDE/SCSI adapter) would be of great benefit to HD owners.

 

Sector copying of large images is time consuming and file copying via an SIO2PC connection is just plain tedious.

 

Dream list

 

-80 Column device emulation.

 

- [expand that idea a little further] How about emulation of a multitude of DIY hardware. Can this even be done?

 

These are new items.

 

- 6502 code relocator, built into Atari800Win Plus.

 

- some control of the emulated hardware (e.g. I've been playing with DIY SRAM carts. It would be nice to be able test -S4 -S5 -RD4 -RD5 -CCTRL manipulation within Atari800Win Plus. I guess this would require emulation of some simple logic ICs. Ooh, how about a PAL/GAL emulator).

 

- Native DOS, meaning I would like Atari800Win Plus to be able pick up the functionality of DOS when necessary. For example, If I'm playing with a tape/rom/disk image in a way that doesn't allow DOS to be loaded I would still like the ability to dump information to a DOS file.

 

-Some one mentioned an improved debugger. I'm for that. One feature I would like to see is to be able track all activity to a range of adressess. (e.g. if anything in the $D5xx range is accessed, I want to know when and how it was accessed. I don't necessarily want to stop execution, as with a break point. I want to monitor activity).

 

 

Comments

 

I really like the idea of using the clipboard as a device accessible by the A8.

 

How about including the ability to mirror the Graphics 0 window to the clipboard?

 

- Steve Sheppard

[Rybags]

Some sort of a plug-in system would be good - making virtual device handler development easier and independant of Emulator updates.

 

Another thing no-ones mentioned - emulate the function of the AMY sound chip. I've just had a look at the specs PDF, it would be entirely possible.

 

Although having a real AMY work-alike for real machines would be better. I always assumed the difficulties they had incorporating it into the XE and ST were related to DMA access, but AMY uses internal RAM and doesn't read samples - it uses internal harmonic tables to generate waveforms.

[carmel_andrews]

a8isa1...atari++ i believe has a 'native dos' or built in dos, prob is, it uses user mem (atari++ i understand uses a similar emulation engine to atari800win+

 

What one could do is have a built in dos or native dos (spart/mydos/and atari dos compat). within the 1st block of 64k (standard atarai mem. map) if you selected more then 64 k, the emulator could be programmed to redirect all loaded data to the selected 64k page and using the built in monitor re direct that 64k to a disk file (or sections of it), or, using the built in dos, that can be programmed to manipulating/saving/editing of that particular 64k page of mem.

[Rybags]

I fail to see any point redirecting loaded data. In any case, extended memory is never accessed in blocks greater than 16K - regardless of the scheme.

 

Most programs will crash if their data isn't loaded where specified. The Atari XL OS actually has a relocating loader in it, but it is for downloading device drivers from PBI/SIO devices which need to do so.

 

Conventional programs do not relocate well - due to the fact that there is no easy way to distinguish between code and data, plus the fact that indirect pointers can't easily be identified.

 

Back to the clipboard thing - it would be feasible to write a program to run natively on the Atari which mirrors all output to "E:" on "P:" - that would just mean using the redirection to Notepad feature in A800Win+. A hotkey combo could be used to toggle the mirror on/off.

 

Another thing about DOS:

Personally, I use H: whenever possible. A fair bit of the resident DOS on a real Atari is the filing system, which H: provides for free.

What we really need is a cut-down DUP which provides the stuff that the H: patch doesn't provide (binary load/save), and a command-line interface or menu for the rest (instead of having to use XIOs).

 

Such a program would be native 6502 code, with no modification needed to the emulator - and would use a fraction of the memory of conventional DOS.

[a8isa1]

<snip>

 

What one could do is have a built in dos or native dos (spart/mydos/and atari dos compat). within the 1st block of 64k (standard atarai mem. map) if you selected more then 64 k, the emulator could be programmed to redirect all loaded data to the selected 64k page and using the built in monitor re direct that 64k to a disk file (or sections of it), or, using the built in dos, that can be programmed to manipulating/saving/editing of that particular 64k page of mem.

Sound a bit cumbersome. I don't necessarily want to deal with whole 64K blocks.

 

After I typed the idea of a built-in DOS I realized it comes under the category of a luxury.

 

If necessary I can already do a Memdump using the Atari800Win Plus monitor. This of course sends the data to a PC file not an Atari file. However, the PC file can be read back into the Atari domain via the virtual H: drive. My request is therefore not a priority.

 

 

More requests coming up

 

- How about Atari800Win plus tools for conversions between any two formats tape/disk/cartridge/xex.

 

Yes, I know just about every cartridge and disk have been converted to XEX (binary file). However, there are still lots of unconverted .CAS images. Plus, I was thinking more in terms of the learning experiences.

 

- This will probably disturb some people but how about adding P2P to Atari800Win Plus.

 

We all have are own libraries of stuff and there are plenty of resources on the internet but it still seems to take a lot of effort get all what one wishes collected together.

 

P2P makes sense to me because we already have to make all of Atari apps accessible for Atari800Win plus. It's all there to be made available, potentially.

 

A newbie could simply install Atari800Win plus and have easy access to software.

 

It would really be nice for newly developed software, especially.

 

- Steve Sheppard

[UNIXcoffee928]

Is there a non-programmer who is interested in helping by maintaining a Wishlist?

 

If so, please work from the following template which covers all ideas proposed thus far. If someone could host an interactive web page with numbered Wishes and a comment field, that would also be very helpful.

 

 

Thanx,

 

UNIXcoffee928

 

 

--------------------------------------------------------------------------------------------------

TITLE: Atari800WinPlus Wish List/TO-DO list

--------------------------------------------------------------------------------------------------

DESCRIPT: A list of features we would like to see in future versions of Atari800WinPlus.

No implementation order is implied.

 

VERSION: v.01

 

LAST EDIT: UNIXcoffee928

 

DATE: 04-25-2006

--------------------------------------------------------------------------------------------------

 

--------------------------------------------------------------------------------------------------

001. A direct RAM transfer method, suitable for data-burst to an external application

--------------------------------------------------------------------------------------------------

002. The HI-RES SUPER 1020 graphics terminal interface

--------------------------------------------------------------------------------------------------

003. CUT/COPY/PASTE to/from windows & the emulator

--------------------------------------------------------------------------------------------------

004. User declaration of the file ext of the temp .txt file that gets output by a print command.

--------------------------------------------------------------------------------------------------

005. Starkit: generate Win32 executable directly from emulator: no menus, no settings, just

an executable file which would be generated from settings you make in emulator

(machine type, artifacting, joystick, keyboard, etc.).

--------------------------------------------------------------------------------------------------

006. Config files (like WinUAE), and ability to run with command switches.

--------------------------------------------------------------------------------------------------

007. Ability to load .XEX without having a coldstart + load .XEX without INIT/RUN

(currently hangs?)

--------------------------------------------------------------------------------------------------

008. Better debugger using Win32 interface. Sprite/chset/graphics ripping ability (maybe best

done with a seperate program using savestate files)

--------------------------------------------------------------------------------------------------

009. DirectX stretch mode (like Gens emulator)

--------------------------------------------------------------------------------------------------

010. option to run in turbo/slow but keep chipset timings (like WinUAE).

--------------------------------------------------------------------------------------------------

011. full r/w emulation of flash-cartridges (ie AtariMax)

--------------------------------------------------------------------------------------------------

012. redirection of specific Dn: devices to Hn: (for software that insists on using the D: device)

--------------------------------------------------------------------------------------------------

013. fix wildcards for H: device (currently only works with directory)

--------------------------------------------------------------------------------------------------

014. fix the way the keyboard is emulated. The Atari has one of the worst keyboard scanning

mechanisms of any computer (due to one key at a time policy) - there is a better way.

--------------------------------------------------------------------------------------------------

015. ability to load BASIC files directly without having to use the tape player trick or the

LOAD"H:XXXXXXXX.BAS option

--------------------------------------------------------------------------------------------------

016. 100% cycle-exact ANTIC / GTIA / CPU timing.

--------------------------------------------------------------------------------------------------

017. cycle-exact POKEY Timers (currently scanline exact).

--------------------------------------------------------------------------------------------------

018. full r/w emulation of flash-cartridges (ie AtariMax)

--------------------------------------------------------------------------------------------------

019. windowed mode allows for stretching or reduction of window size

--------------------------------------------------------------------------------------------------

020. a proper PAL emulator mode, like in VICE emu

--------------------------------------------------------------------------------------------------

021. Emulation of the Black box

--------------------------------------------------------------------------------------------------

022. proper emulation of the diamond GOS cart

--------------------------------------------------------------------------------------------------

023. Emulation of other misc 1050 roms (like happy, lazer, speedy, SA2 etc)

--------------------------------------------------------------------------------------------------

024. separate emultion of the xf551, which i understand is currently only emulated thru the

sio patch when enabled

--------------------------------------------------------------------------------------------------

025. A load point counter to supplement the disk/cassette block/sector counter (useful for

hacking into ATR's)

--------------------------------------------------------------------------------------------------

026. A proper binary load/save feature instead of the memdump feature in the monitor section

--------------------------------------------------------------------------------------------------

027. to supplement the binary save/load feature a read from and write to sector routine using

the info gleamed from the load point/disk sector counter using upto 8 mounted ATR's

(again usefull for hacking ATR's)

--------------------------------------------------------------------------------------------------

028. Ability to section unused additional ram (for settings over 64k) if not using a ramdisk use

as cartridge ram, as so to emulation for cartridge(s) that use addit. ram (atarimax etc etc)

--------------------------------------------------------------------------------------------------

029. IF using over 64/128k of mem, in the atari mode, to redirect all loads to the addit. pasges

of 64k mem, usefull for hacking into programs, because the monitor will allow you to

access that page of 64k mem (only the first 64k will contain the atari mem. map) addit.

64k pages will be zero'd

--------------------------------------------------------------------------------------------------

030. I/O log file. Each entry could just contain the DCB parameters and return code. With

that, program loading could be traced exactly.

--------------------------------------------------------------------------------------------------

031. Full overscan emulation - currently widescreen only, includes 42 columns.

--------------------------------------------------------------------------------------------------

032. A "flicker fixer" via double buffering or blending of alternate frames from real input

sources.

--------------------------------------------------------------------------------------------------

033. A screen scrollback buffer, like the one implemented in Winfrotz (The Infocom Z machine

parser for Windows).

--------------------------------------------------------------------------------------------------

034. When Misc-->Preferences-->Reuse Emulator Window is selected, a new Notebook Tab

opens up, like in the windows editor, "Context", or the Win app, "Flat Assembler".

--------------------------------------------------------------------------------------------------

035. A proper artifacting mode. The current mode just knocks the horizontal resolution in half.

--------------------------------------------------------------------------------------------------

036. support for physical floppy media and physical Atari drives.

--------------------------------------------------------------------------------------------------

037. More accurate performance for Ultra Speed (3X) SIO emulation needs to be perfected.

--------------------------------------------------------------------------------------------------

038. correct the default colors. Presently, change the Color Shift (in the Pallette menu) to 55.

This matches the tint (but not the staturation level) to my real A8s. I've asked a few

people and they say 55 works well for them as well.

--------------------------------------------------------------------------------------------------

039. Ability to generate hard disk images or write directly to media that the A8's can use, like

CompactFlash or IDE, in the correct format of course, MyIDE, SmartIDE, BB (which I

understand can now use IDE drives with the help of an IDE/SCSI adapter) would be of

great benefit to HD owners.

--------------------------------------------------------------------------------------------------

040. Sector copying of large images is time consuming and file copying via an SIO2PC

connection is just plain tedious.

--------------------------------------------------------------------------------------------------

041. 80 Column device emulation.

--------------------------------------------------------------------------------------------------

042. Emulation of a multitude of DIY hardware. Please specify:

--------------------------------------------------------------------------------------------------

043. 6502 code relocator, built into Atari800Win Plus.

--------------------------------------------------------------------------------------------------

044. some control of the emulated hardware (e.g. I've been playing with DIY SRAM carts. It

would be nice to be able test -S4 -S5 -RD4 -RD5 -CCTRL manipulation within

Atari800Win Plus. I guess this would require emulation of some simple logic ICs.

--------------------------------------------------------------------------------------------------

045.- PAL/GAL emulator

--------------------------------------------------------------------------------------------------

046. Native DOS, the ability to pick up the functionality of DOS when necessary. For example,

If I'm playing with a tape/rom/disk image in a way that doesn't allow DOS to be loaded

I would still like the ability to dump information to a DOS file.

--------------------------------------------------------------------------------------------------

047. improved debugger. Ability to track all activity to a range of adressess. (e.g. if anything

in the $D5xx range is accessed, I want to know when and how it was accessed. I don't

necessarily want to stop execution, as with a break point. I want to monitor activity).

--------------------------------------------------------------------------------------------------

048. a plug-in system would be good - making virtual device handler development easier and

independant of Emulator updates.

--------------------------------------------------------------------------------------------------

049. emulate the function of the AMY sound chip

--------------------------------------------------------------------------------------------------

050. cut-down DUP which provides the stuff that the H: patch doesn't provide (binary l

oad/save), and a command-line interface or menu for the rest (instead of having to use

XIOs). Such a program would be native 6502 code, with no modification needed to the

emulator - and would use a fraction of the memory of conventional DOS.

--------------------------------------------------------------------------------------------------

 

Atari800WinPlus_Wishlist01.txt

Edited April 25, 2006 by UNIXcoffee928

[a8isa1]

I fail to see any point redirecting loaded data. In any case, extended memory is never accessed in blocks greater than 16K - regardless of the scheme.

 

Most programs will crash if their data isn't loaded where specified. The Atari XL OS actually has a relocating loader in it, but it is for downloading device drivers from PBI/SIO devices which need to do so.

 

Actually, at one point I had wished that the emulated floppy drives of Atari800Win plus had supported downloadable drivers. That and non-supported 3X SIO had me scratching my head has to why part of my sector copier wasn't working.

 

Conventional programs do not relocate well - due to the fact that there is no easy way to distinguish between code and data, plus the fact that indirect pointers can't easily be identified.

Point taken!

 

Back to the clipboard thing - it would be feasible to write a program to run natively on the Atari which mirrors all output to "E:" on "P:" - that would just mean using the redirection to Notepad feature in A800Win+. A hotkey combo could be used to toggle the mirror on/off.

 

True but an external routine would use no Atari memory and could work with any legacy application that supports E: or S:.

 

I suppose one problem is how many applications use a strictly the E:. I'm sure most favored custom displays and input/ouput routines.

 

Another thing about DOS:

Personally, I use H: whenever possible. A fair bit of the resident DOS on a real Atari is the filing system, which H: provides for free.

H: still needs re-vamping.

 

I'm just saying it would be nice to be able to use legacy applications (those where you can't type "H:") with the virtual hard drive.

 

What we really need is a cut-down DUP which provides the stuff that the H: patch doesn't provide (binary load/save), and a command-line interface or menu for the rest (instead of having to use XIOs).

 

Such a program would be native 6502 code, with no modification needed to the emulator - and would use a fraction of the memory of conventional DOS.

 

Actually, in an emulator couldn't DUP be very minimal and trigger an external command-line interface and file manager.

 

From the emulated Atari's point of view, only DOS.SYS is loaded.

 

This of course could be a selectable option.

 

For purists, leave DOS and DUP alone, but make H: drive behave as a D: device.

 

Just my opinion.

 

- Steve Sheppard

Edited April 25, 2006 by a8isa1

[a8isa1]

<snip>

 

--------------------------------------------------------------------------------------------------

050. cut-down DUP which provides the stuff that the H: patch doesn't provide (binary l

oad/save), and a command-line interface or menu for the rest (instead of having to use

XIOs). Such a program would be native 6502 code, with no modification needed to the

emulator - and would use a fraction of the memory of conventional DOS.

--------------------------------------------------------------------------------------------------

 

 

Wow! 50 items already!

 

We are going to scare away any potential programmers!

Edited April 25, 2006 by a8isa1

[emkay]

Real POKEY emulation... which makes possible to use triangles and full timing correct handling....( "gr.9" is still colour-clock wrong)... and full ANTIC restrictions.

Finally, denying of programming that isn't possible on real machines.

 

After this, people really can create serious software in the emulation that is even running on the real thing.

[UNIXcoffee928]

Real POKEY emulation... which makes possible to use triangles and full timing correct handling....( "gr.9" is still colour-clock wrong)... and full ANTIC restrictions.

Finally, denying of programming that isn't possible on real machines.

 

After this, people really can create serious software in the emulation that is even running on the real thing.

 

 

Well, on the other hand, if the feature is useful enough in the emulator, the chances are great that someone will design a hardware solution.

 

Denying programmers anything is probably never the answer, given the culture... (how many 8-bit programmers were stopped by software protection on the Atari in the first place?).

 

As long as there are pull down options in the emulator to have a stock setup, there should be options that let the Atari evolve.

 

The Atari OS is a beautifully stable environment that offers a built-in framework for future upgrades. As long as the OS itself doesn't have to have modifications that are not compliant with the standards Atari set forth, I would think that most users would like to see upgrades to the machine or the virtual machine. Many upgrades only require the design of drivers to interface the Atari to the upgrade.

 

Of course the 400/800 users out there are saying "WHAT!?! Atari itself made the product line incompatablie when the 1200XL came out!

 

True enough, and they did it by modifying the OS.

 

But, then again, they knew the OS inside & out (supposedly...)

 

Lets leave it at they did what they did to:

1. Have a new product to make some money with

2. To increase the future expandability of the product line. (to invent new products to sell, to make money...)

 

Since we the developer community don't have jobs at Atari that we commute back & forth from in our time machines, we're not making any money

 

So this leaves us with the option: To increase the future expandability...

 

The time spent hacking keeps you from spending money, anyway...

 

And the lesson here is try not to modify the OS, because people will continue to gripe about it for more than 20 years!

 

Everything else should be fair game.

 

 

L8R,

 

UNIXcoffee928

[carmel_andrews]

I remember that the H: driver doesn't seem to work with dos's like mydos and atari dos (see my post elsewhere on the a8 section), so any mod to the H: driver is going to be lost on some/most people

 

How about emulation of a double gtia/antic for extra colours,pmg's, higher rez gfx etc, after all it already emulates double pokey

 

The P2P idea sounds good, unfortunately you must remember that some peeps have a bb connection and some peeps like me have a standard t/phone connection and i guess that those that use a bb connection will tend to clump all there collections (A8) into one big file (32meg plus), which is a bit of a pain of those who only have a standard t/phone connection, unless you limit the file size to less then 5 megs then it might work

 

And here's a sneaky one, emulating the WDC65t32 (the proposed and already released 32 bit version of the 65816/650x proc's,,,see someone else post concerning the pci card thing for the link)..forget the 65816 emu, we don't need it anymore, we've found a better processor

[Rybags]

Emulating a second POKEY was done because it's a fairly common "real" mod that people have done.

 

Adding a second ANTIC to a real machine wouldn't do anything - the only way it could work would be to have it's own exclusive RAM, and all for the sake of generating a second display?

 

A second GTIA? I suppose with some trickery a second GTIA could be used and have it's output blended, so allowing an extra 4 PGMs. But, a fairly pointless exercise, since any game written for it would have a very narrow audience.

 

H: problems with DOS2.5? In my experience the only issues are wildcards , and problems in the DOS menu when working with certain commands and long filenames.

 

Upgrade processor? Tricky one there. Possibly another niche market - the problem with running a faster processor is that the Atari's onboard RAM is only really designed to do around 2 MHz.

 

Re: the list - items 9 and 19 are the same thing.

[carmel_andrews]

I seem to remember that the 'dual Antic/Gtia' was a 'real' upgrade, the renowned American A8 hardware guru Bob Wooley did these u/g's at the back end of the 80's, I even heard the FTE were going to try and do something similar

 

The originator of the dual pokey u/g and also the '816' upgrade Chuck Steinmann/dataque was also looking to making a expanded gfx card and sound card using dual/quad antic/pokey/gtia combo's on his proposed tower systems based xl/xe systems designed arround the '816' u/g

[Heaven/TQA]

i would like to try out 65816 even if i have no card but don't want to switch to apple or super nintendo just to do so...

 

and i would like to have realtime debugger like no$gba emulators have... window for screenram, pm-area, registers and disassembling all running in realtime... that would be a dream...

 

and a very handy feature would be to load directly xasm assembled files with all labels etc...

 

so a real visual studio thingy...

[a8isa1]

I remember that the H: driver doesn't seem to work with dos's like mydos and atari dos (see my post elsewhere on the a8 section), so any mod to the H: driver is going to be lost on some/most people

I can read and write files to H: drive, I can copy 1 file at time from the command line. I can call a directory with wildcards. I just can't copy files using wildcards.

 

I don't know if this an emulator failure or a MyDOS failure.

 

Aside from that here are my issues with the H: designator.

 

- Old programs don't know the existence of the H: device.

- If I create a new program in the emulator and hard code it to access H: drive (yes, I know, bad practice) then I can't use the program on real hardware.

 

That's an extreme example to make my point. I do, however, use INCLUDEs when I compile Action programs and it IS A PAIN in the butt to change H: to D: and vice versa.

 

How about emulation of a double gtia/antic for extra colours,pmg's, higher rez gfx etc, after all it already emulates double pokey

It's just my opinion but this goes outside of the realm what an emulator should do, which is mimic real hardware.

 

The P2P idea sounds good, unfortunately you must remember that some peeps have a bb connection and some peeps like me have a standard t/phone connection and i guess that those that use a bb connection will tend to clump all there collections (A8) into one big file (32meg plus), which is a bit of a pain of those who only have a standard t/phone connection, unless you limit the file size to less then 5 megs then it might work

I, like you, am still stuck in the 20th century with a dial-up connection. I do hate it when people use humungous Zip files. (I also hate .PDFs as the defacto standard for online documention, but that's a whole other rant!).

 

The efficient management of files is up to each user, of course. Perhaps someday P2P will packetize the individual contents of ZIPs and other container files. That way an individual will at least obtain usable pieces before the whole transfer is completed.

 

Anyway, P2P was just an idea. I just thought that once the torrents are created they would kind of exist forever, unlike websites that pop up, offer stuff for a while, then disappear.

 

And here's a sneaky one, emulating the WDC65t32 (the proposed and already released 32 bit version of the 65816/650x proc's,,,see someone else post concerning the pci card thing for the link)..forget the 65816 emu, we don't need it anymore, we've found a better processor

Well, that's one example when I don't mind emulator enhancements going beyond real hardware, where the enhancent could possibly spark the development of real hardware.

 

- Steve Sheppard