List of New Features you would like to see in Atari800WinPlus

[fox]

022. proper emulation of the diamond GOS cart

 

On all the diamond cart images i have, they don't run at all on the insert/attach cartridge option (even if you select diamond gos as type of cartridge)

 

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

hacking into ATR's)

 

Just as you have a 'sector load' counter (it shows you the present sector being accessed) you can have a sector/block load point counter to indicate where that particular sector loads into atari's memory... i.e 1/123 (S9000) that is drive one sector 123 load address/point $9000h

 

a better suggestion would be to emulate Atari coin op's 'Quad Pokey' as it is'nt much more of a development on from Dual Pokey/stereo pokey

 

Also, seeming as you support some of the xl/xe ram mod's how about supporting the ram mod's for the old 800 (Axlon et al)

 

How about getting Electron to assist you in emulating his 'videoboard xe' though your emu...It might encourage more A8'rs to go out and buy his upgrade

 

Anychance of emulating the 65816 upgrades thru your emu (i won't bother mentioning the 65t32 as that would be a bit of a leap so far as this emu's concerned at the present)

 

Diamond GOS: when I coded the emulation several years ago it definitively worked. It's possible that something broke later. Where can I find ROM images?

 

Load address: this won't work with direct I/O and I don't think it's very useful (relocation/depacking usually follows). But I'm thinking about making more logging options in the style of the 6502 trace dump: SIO commands, POKEY audio register writes etc.

 

Quad Pokey: can you estimate how many people have it, how many songs are written for it? Also, which channels are connected to which POKEYs?

 

Videoboard: if Electron submits good code to emulate it, we will accept it. Personally I'm not interested in Videoboard.

 

65816: years ago someone made a modified version of Atari800 that supported 65816 with a higher clock frequency. We will accept code that fits well the current version of Atari800.

[fox]

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

 

I don't understand it.

 

...

 

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

 

We thought about it many years ago and it turned out more complicated than useful.

 

Hi!

 

On 001, I mean a real-time data-dump facility, with a documented interface, which can be turned on or off, like a log-file transcript logger, but to RAM. This way, You would have a standard interface method available to those who would like to write windows programs that accept the output as input, based on address ranges for parameters. New video modes could be implemented easily in this fashion, by having virtual display terminals (in a window) with a standard interface for data (right out of atari RAM). This same facility could be used to network multiple emulation windows in a high speed fashion.

 

On 003, boy, this one would be great, even if there was just a text input box in the A8W+ pulldown, as an option for paste. Something like this would then let you at least save that buffer in an atr as an ASCII list file, without messing around having to insert it into another atr & then having to add the disk to the emu.

 

As I mentioned in my post about the drafting font, Context is a great editor, with syntax highlighting for 6502, and it can be configed as a quick Notepad replacement. From MAC/65, a LIST #P: zaps the listing out to the editor which can be syntax highlighted. It would be nice to be able to do editing there, then zap it back to the emu, with the option to save to an atr image.

 

On another note, how about a feature that would let you right click in Windows Explorer, and get a menu item to convert a file or multiple files to an atr image?.

 

001: Atari800's primary function is emulating devices that do exist. You can take the source code and play with it adding, say, Direct3D interface to the emulated Atari. This is not what I am interested in.

 

003: We have cross-compilers (including MAC/65 compatible), which are much more comfortable than copy-paste to the emulated MAC/65.

 

File conversion: this is a task for a disk image converter/manager and not the emulator.

[Rybags]

For copy, a "Screen" Monitor Command like WinVICe has might be sufficient for text.

 

For paste, I reckon a device trap like the "H:" handler - then it would be a simple case of a small Atari program to Open the file and pass it through to the "E:" device.

 

Anyway, BASIC, ASMED and MAC/65 all have the ENTER command which is simply telling the language processor to treat a file as a temporary input device instead of "E:".

 

And, as I've stated probably twice before, redirecting I/O to a different memory address is absolutely pointless - an I/O trace option is the way to go there.

A good way to implement it might be to have a monitor option to dump a sequence of memory to a file each time the PC hits a certain value (e.g. E459, then have it dump 300-30F). Such a scheme could also be used as a debugging aid for program development.

[atarixle]

An 1029 dot matrix printer emulation would be nice.

I'd like to print into an bitmap file using ATARI 1029 printer routines. What about that?

Edited January 23, 2007 by atarixle

[fox]

800 memory upgrades: I need info what upgrades were available and technical info about them.

[carmel_andrews]

800 memory upgrades: I need info what upgrades were available and technical info about them.

 

 

 

 

From memory fox, the only 800 memory u/g's i remember for the 800 (looking thru antic/analog mags) are the following

 

Axlon

Mosiac

And I think Newell (but i could be wrong)

 

Only US companies made 800 ram u/g's...i don't think UK/EU companies got in on the act till the xl/xe systems came along

 

Curt vendell or some of the US members of this forum might be able to help you (re: teckie issues)

 

Rybag's, you won't be able to do an 'i/o' trace using the built in MLM trace, as it alway's points the 'sector load' location as 400h and not it's proper sector load point (this is by looking at the DCB locations 300-30Ch), i think it has something to do with the way ATR/XFD's were orig. made (probably using copy protection routines) which is why whatever sector on an ATR you stopped at when entering the monitor on that ATR/XFD if you look at the DCB locations it will alway's say 400h as the load point

[Heaven/TQA]

what about implement an indicator just in front of the sector no indicator with the actual loading adress? i mean atari800win should now where he puts the sector data? (it doesnt matter if then the code itself relocates the data...) would this help? (you can use 10% performance to watch carefully).

 

and just to be on the sure side... Fox... is atari800 able to do such a realtime monitoring like no$gb etc? or is the emulation core engine not able to do that?

[Rybags]

$400 is the cassette buffer.

 

The DCB does contain the sector load address when the OS SIO routine is called - in $304-5.

 

The only case where those address might be invalid would be with programs which use their own SIO routines (Ballblazer, Alternate Reality, etc).

[carmel_andrews]

Yes, i know rybags, that's why i mentioned that 'dcb' usually refers to the sector load addr. as 0400h...(when in monitor mode),...can't think why

 

i.e 304 will contain a zero, 305 will contain a 4, at least it does so on the ATR's i have used and inspected with the built in MLM

[Rybags]

I believe that the OS loads the disk boot sector at $400, that is the only time that a legacy OS compliant program would use that address - since it would conflict with any cassette activity.

[Rybags]

Two more features that I forgot to mention:

 

- .INI files instead of the Registry. Would make it easier to run multiple versions of the emu.

 

- Floating Point patch (trap). Trap calls which perform floating-point operations and perform them at full PC speed.

[fox]

Config files are a good idea.

 

FP patch: no. First, it is not a real thing. Second, the results could be different because the accuracy is different. Instead, use one of those ROMs with "fast" FP routines, or use a BASIC interpreter that has fast numeric operations (Turbo Basic probably), or use a BASIC compiler, or use a language other than BASIC, or simply press F7.

[carmel_andrews]

If you are playing 2 or more instances of the emulator on the same pc (or Mac), using the 'netplay' feature is it possible to synchronise the game play from each instance of the same emulator on the same pc/mac (i.e for multijoy/multilink type games)

[fox]

I updated the Atari800 TODO list a few days ago. Unfortunately sf.net CVS services are unreliable last days (as usual), so I'll paste my copy here for your convenience. Please let me know if something is missing. It's just for Atari800, so it won't include things that are Windows-specific.

 

Plans for future versions

=========================

 

Keyboard and joysticks

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

 

* map host joysticks to Atari ports in the emulation core in order to make

the configuration available in UI and config file

 

* pass the state of all host keys to the emulation core in order to configure

keysticks in UI and config file

 

* standardize key mappings in all ports (making host and Atari layouts

available everywhere)

 

* emulate POKEY keyboard scanning (with optional debouncing)

 

 

Emulation core

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

 

* cycle-exact POKEY interrupts (timers, serial I/O, keyboard)

 

* precisely emulate serial I/O rates

 

* emulate POKEY reset (via SKCTL)

 

* more accurate frame rates (for example 49.8607456 instead of 50 Hz in PAL)

 

* copy-protected disk images (VAPI, ATP, PRO, copy-protected ATR)

 

* emulate POKEY SIO shift register

 

* emulate SIO bus lines, and SIO cable data/audio cross-talk "feep" sound

 

* emulate 1200XL (two programmable LEDs)

 

* emulate XEGS (built-in cartridge and detachable keyboard)

 

* Axlon memory expansions

 

* redirection of specific Dn: devices to Hn: (for software that insists

on using the D: device)

 

* log POKEY audio writes, SIO commands (hardware level or DCB level),

executed DL commands, all activity to a defined range of adressess etc.

in a way similar to the 6502 trace

 

* emulate drives at the hardware level (810, 1050, XF551.) use code from other

emulators which does this. (drive rotation, FM/MFM raw bits). WDCxxxx

controller. RIOT chip. 6507. Intel 8048-line chip for the XFD551.

Use emulated SIO line for bit-banging. Emulate Drive upgrades (Happy etc.)

Emulate 3rd party drives (Rana etc.)

 

* sound effects. Drive retracking noise (BlueMSX has.) Motor whine.

On/off switch sound. Physical key-press sounds. Cartridge slot sounds.

Drive door sounds. Floppy rotation flap sound.

 

* Atari vapourware emulation. 1400XL. 1450XLD. XEM (see below). 1090.

1060 CP/M (sweet-pea.)

 

* emulate the 850 interface at the hardware level.

 

* ATR-8000 emulation. ATR-8500. Need schematics, ROM images, and Disk images.

Adapt an existing CPM emulator.

 

* emulate the 800-only FULL-VIEW 80 BOARD by Bit3 Computer Corp and

Austin-Franklin 80-Column Board. Need ROM images and schematics.

 

* 6502 BRK bug

 

* Try to understand 6502's "unstable" opcodes (0x93, 0x9b, 0x9f) that seem

to have unpredictable (at least not easily predictable) results,

preferrably by studying 6502 schematics

 

* An option to emulate the variant of 6502 used in new XE machines

(which lacks most of the undocumented opcodes of the classic 6502)

 

* Fully emulate executing 6502 code from Hardware, cycle-exact ANTIC_load

from hardware, cycle-exact PMG flickering bus data

 

* An option to detect undocumented 6502 opcodes to test for compatibility

of software with CPU upgrades (65816, etc)

 

* CPU upgrades (65816, etc)

 

* Emulate printer graphics (on screen or bitmap/PDF output): 1029, 1020, etc.

The Mac OS X port of Atari800 has lots of printer emulation routines.

 

* RAM Carts (cartridges with battery-powered RAM). Are flash carts writable

from Ataris too?

 

* serial "network" interfaces (e.g. 8 Ataris connected, is it GameLink?)

 

* generate hard disk images or write directly to media that the 8-bit Ataris

can use, like CompactFlash or MyIDE/SmartIDE/BB

 

* "Turbo" cassette upgrades (Turbo 2000 etc.)

 

* Cassette emulation of WAV files. Load a WAV file like WAV2CAS does. Save

to a WAV file or real cassette like CAS2WAV does. Load voice-and-data

combined programmed audio tape images from WAV files. Support compressed

(lossless? lossy even?) tape sound images.

 

* Disk auto-flip. Examine screen data for text string "Insert Side B

and press any key/fire/return." Flip disk, print on-screen message and

optionally press key. More a core feature than UI. Requires a database.

 

* support physical floppy media (hard, port-specific and not very useful)

 

* support physical Atari drives (hard, port-specific and not very useful)

 

* Event history. Record a keypress/joystick event history. Need a file format

that is good (compress?) Don't use cycle-exact RANDOM since that could

change easily in future versions. Use our own rand() (with option to use

true RANDOM. Provide all features that VICE has. Optionally calculate and

store CRC-32 for each screen of pixels. Verify playback in future revisions

of the emulator. A very good regression test. Have volunteers make

recordings.

There could be walk-throughs, high score contests like MAME Action Replay.

perry: I have code to do a basic recording and CRC-32 but I need a

good file format.

 

 

Graphics

--------

 

* better color palettes

 

* use different palettes for PAL and NTSC modes (and GTIA vs CTIA?)

 

* "flicker fixer": display average pixel values of two last Atari frames

 

* XEP80 emulation. Slor is working on it, contact him first.

 

* Use YUV output if available. Will it help?

 

* PAL emulation. VICE has it, but it's not as complete as Blargg's emulation

of NTSC. PAL luma/chroma artifacts are missing (it is like S-Video).

Blargg's optimization technique won't work so easily for PAL.

(perry: I have a hack of Blargg's slow version of the NTSC emulator that

I tried to make work for PAL. But it isn't quite right and is way too slow.

Ask me if you are interested.)

 

* The NTSC emulator should support either 16 or 32 bpp and should support

other resolutions. It should be supported in all possible ports.

 

* Fix the remaining bugs in the NTSC emulation. Artificating colours are

not quite right. odd-even and even-odd combined artifacts (light red

and light green) do not show unless Gaussian factor is changed a lot,

which causes even worse artifacts. Fully document the Atari's video

output signal (might require a scope.) Fully document NTSC decoding

of late 70's and 80's era TVs.

 

* Document CTIA and emulate properly. Emulate the players not aligning

with playfield bug/feature of CTIA which is said to exist. Need

at least screenshots of a CTIA Atari showing all possible artifacts.

 

* An option to emulate the buggy GTIA chip found in new XE machines.

 

* Fix all remaining collision bugs in the ANTIC and GTIA code (border+scroll,

player HPOS and GRAF changes, partial_scanline changes.) Use the technique

of saving data that might generate false collisions, drawing, and then

restoring the data (pm_scanline).

 

* Cycle-exact DMACTL and HSCROL including all glitches

 

 

Sound

-----

 

* get rid of VOL_ONLY_SOUND

 

* correctly emulate serial I/O sound

 

* merge POKEY sound engines

 

* POKEY sound should NOT be asynchronous to the rest of the emulation

(for example, the contents of the generated WAVs should not depend

on the speed of the emulation)

 

* include sound settings in the emulation core (command line options,

config file, UI) and make it possible to change them at runtime

 

* support WAV files in configurations with no live sound

 

* an option to auto-enable stereo when an Atari program uses it

 

* Covox

 

* 2 POKEY mono, 4 POKEY stereo, 4 POKEY quad

 

* MIDI <> serial port interface. In it's simplest form there's only MIDI

output from the Atari. The more complicated version is enabled by the motor

control line and includes two MIDI outputs selected by the command control

line and one MIDI input. There is a MIDI composer program for Atari.

 

* A/D Converter - 4-bit sampler that returns 0xf0-0xff in the 0xd500-0xd5ff

address space.

 

* XEM AMY-1 Chip. This is a huge project. Schematics (netlist)

are said to exist. Prototyping software for the PC (connected to parallel

port) is available online. Datasheet is online. Need netlist for AMY-1,

schematics for XEM and any software.

 

* SID chip

 

 

User Interface

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

 

* if UI fileselector cannot open a folder either user should be alerted

or the fileselector should open another folder and not sit there quietly

like if it was ignoring the user completely

 

* make sure all command-line options are available in UI and config file

 

* error messages should appear on screen and not in the log

 

* use a smaller font for low-resolution displays

 

* on screen display, like a TV remote, for the NTSC (or other) screen filter.

 

* a database to identify programs and choose appropriate settings.

OS version. Memory size. Memory expansion type. Peripherals.

Machine type. Joystick/Trackball/Paddle etc. controller type.

Artifacting mode. SIO patch compatibility. Even if compatible with

SIO patch, loading screen graphics are often interesting to watch, so

give the user an option to view or ignore them if present. If not

SIO patch compatible, optional warp-speed through the loading.

Keyboard layout. Advisories as to bad dump/bad image/special considerations

Provide documentation, box scan, label scan for the program

PAL/NTSC mode. Database should indicate PAL/NTSC

compatibility, and which system the program was originally designed for.

Allow PAL users to prefer PAL for NTSC-designed programs, but NTSC users

to prefer NTSC. NTSC users get PAL (or fake NTSC-upgraded-to-PAL) for

all PAL-designed programs (Except perhaps very old ones like English

Software titles that NTSC users might remember.) PAL users get NTSC

video only for artifacting programs.

 

 

Clean up

--------

 

* clean up the "util" directory - remove obsolete files, write one-file

documentation for all utils

 

* make documentation consistent across systems, maybe using templates

 

* further clean up in the directory structure - port specific files should

be hidden in their subfolders (falcon, amiga, ...)

 

 

Speed optimizations

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

 

* use a boolean variable to disable 6502 history tracking and breakpoints

(even with MONITOR_BREAKPOINTS and MONITOR_TRACE it should be

faster than currently with just the default MONITOR_BREAK)

 

* use function pointer table for hardware registers (like PAGED_ATTRIB does)

 

* optimize the new POKEY sound engine

 

* emulate 6502 during vertical blank in a single GO() call

 

* prefer int to UWORD and UBYTE (especially in cpu.c)

 

* try merging N and Z flags into one variable

 

* try putting the C flag as the 8th bit of the A variable

 

* use patches for common routines such as OS interrupt handlers

 

* make some hardware registers directly available in memory[]

 

* write versions of draw_antic_* functions for the common case when there are

no sprites in the current scanline

 

* update color lookup tables only when color registers change

 

* put 6502 flags into local variables so they can be put in registers

 

* automatic framedrop

 

* generate 168x120 graphics for portable devices with low-res displays

 

* boost memory bank switching by using hardware paging on systems

that support it (for example, use mmap() on Linux)

 

* boost memory bank switching by using Get/Put functions for the banked memory,

PC_PTR and some tweaks in antic.c

 

* implement Dirty Spans (see HOWTO-DIRTYSPAN)

 

* think about using MMX and SSE (for display and sound probably)

 

* think about optimizations for the more and more common 64-bit CPUs so we

can reach 256 times Atari speed sooner

 

* an option to detect popular lengthy Atari decompression routines

and run equivalent C routines instead

 

 

R: device

---------

 

* clean up and comment the code

 

* improve portability

 

* documentation

 

* automatic test (similar to hdevtest.lst for H:)

 

* identify security problems

 

* TCP port should be configurable (currently hardwired to 9000). The switch

between real serial port and TCP port should be put there. Something

along the following lines:

R_SERIAL = 1

R_SERPORT = /dev/ttyS0

R_NETPORT = 9000

[Triads]

Probably already said, but here's my 2 cents..

 

Along with better 850 emulation, how about a virtual modem as well.. Something to take the AT commands, and return an OK.. Then tunnel it thru telnet..

[carmel_andrews]

Fox

 

 

Impressive list of todo list, and lots of good idea’s…only hope is that you can keep the emulator file size down to a ‘reasonable’ size

 

Here were my thoughts

 

Re: Redirection of DN to Hn devices…Will that cure the prob. with non sparta dos alike dos’s (i.e Atari dos 2x and Mydos) in accessing and reading hard drive directories/partitions

 

Emulation of Other A8 disk drives/drive mod’s at hardware level…Possible if you know the processors the other drives or drive mod’s used and find out much of the processor was used by the drive or drive mod and only emulate that portion of the drive or drive mod’s processor used (i.e. some aspects of the 6502 or 6507 emulation core) also emulation of the RAM as well (if possible)

 

To emulate the drive/drive mod ROM’s… you would add an extra tab on the os/roms dialog for disk drives/drive mod emu (I think you can get the rom’s from the same place I mentioned to you last time)

 

Only problem with emulating particular drive mod’s is the following…The Lazer was basically a trimmed down ‘happy’ clone, it was only popular in the UK (as I understand it) and not so popular in EU or US, the nearest European equivalent was the speedy or super speedy which might be a possible candidate, but again there’s the problem of usage popularity, in that it didn’t take off at all in the UK, I don’t know about the US and only popular in Europe, the other problem with the speedy and super speedy upgrade is that it was incompatible with happy/lazer and SA/SA2 formatted D/D disks, in that Happy/Lazer etc etc followed the USD format and skewing for D/D and the speedy/super speedy used it’s own peculiar format for skewing/formatting d/d disks, as a test, try and load in a d/d rob c ian k, JW/Multiboot Alpha/Elton or Sparta dos d/d menu disk (USD format or skewed) and try and load a file and you’ll see what I mean

 

Re: Emulation of Atarimax type flash cartridges…not too sure if that’s a good idea…perhaps you’d better discuss that with Steve/Classics…might be a good idea in as far as ‘creating’ software cartridges for peoples own collection/archives (as long as they don’t start distributing their flashcart images on the internet)

 

Slight modifying of .cas images (so to being compat. with the various cassette to disk programs on ATR format)

 

Instead of emulating specific revisions of Antic/Pokey G/CTIA, offer an option or choice of emulation of antic pokey or g/ctia and how it is emulated (might cut down the code a bit)

 

Re: SID/AMIE…good idea, slight problem is making it compatible with existing Atari mem. Maps and also the fact there’s no software to support these chips on the A8 and lastly how could existing software be converted to supporting these chips (I think we all know how lazy programmers can get)…as I don’t think rom’s exist for the XEME/XEEM o/s (which has the amie/amy code in it I guess)…It could be easier to emulate quad pokey as I am guessing it works similarly to the dual pokey/stereo pokey upgrade, namely the additional sound registers/locations are just dupe’d higher up in the pokey locations/registers and therefore might be easier to convert software like people are already doing for stereo/dual pokey

 

On the ATR image creation option, include an option for formatting for mydos and spartados, also include an option for copying over files from a pc into the recently created ATR as well as creation of new directories (mydos/Sparta compat.), saves having to use a separate program

 

The only problem there would be with the DCB trace option, if your doing it the the built in MLM is you would have to fix the bug where the sector loaded at the point of entering the monitor or pausing the emulation always seems to point at 400hex instead of the proper location (i've not tried it with 4.1 yet as i've gone back to 4.0 final which doesn't have any sound prob's)

 

Is there a reason why there is sound issues in 4.1 and not 4.0 final or did you mess some routine about which resulted in the sound issues in 4.1

Edited May 12, 2006 by carmel_andrews

[Rybags]

Redirection of "Dn:" to "Hn:" is more oriented towards allowing software which insists on "D:" to work with Hard Drive files.

 

The "H:" patch only provides directory info via the OPEN #n,6,0,"Hn:<filespec>" call (via CIO) - which is fine for high-level programming and some DOSes.

 

DOS Menus or CLIs that provide directory info by directly accessing the disk via the resident disk interface ($E453) or SIO ($E459) are incompatible with "H:", since "H:" is really only compatible CIO calls.

 

Emulation of drive mods at a hardware level seems a bit over the top IMO. Every old game has been cracked/fixed, and new software doesn't really bother with any form of copy protection.

The nostalgia value would be all fine and good, but it sounds like too much work for too little gain.

 

I don't see any problem with AtariMax emulation. I requested it mainly as a development aid. As I understand it, the cartridge comes with software which allows cart images to be easily stored on the device anyway.

[Wrathchild]

Re: Emulation of Atarimax type flash cartridges…not too sure if that’s a good idea…perhaps you’d better discuss that with Steve/Classics…might be a good idea in as far as ‘creating’ software cartridges for peoples own collection/archives (as long as they don’t start distributing their flashcart images on the internet)

The change is mostly benefitial to developers who can test their code instead of having

to re-flash the physical cartridge each time they fix something. This will speed up

new title development and perhaps lead to patches to existing games where saving the

hi-scores or game state (e.g. adventures) back to the cartridge so its there the next

time you play is a benefit, i.e. you don't need a disk drive or cassette deck to load it back.

 

As for user's own collections, some are already available on the AtariMax site's forums,

so why the problem with distributing flash-cart images? You usually get the games from

Bill's ftp-serach, a pool-disk or something similar to make your own collection anyway.

 

Mark

[MEtalGuy66]

Complete emulation of the ATR8000 and every posible hardware combination that could be hooked to it.

 

Emulation of Covox audio digitizers via PC soundcard line-in.

[Shawn Jefferson]

The change is mostly benefitial to developers who can test their code instead of having

to re-flash the physical cartridge each time they fix something. This will speed up

new title development and perhaps lead to patches to existing games where saving the

hi-scores or game state (e.g. adventures) back to the cartridge so its there the next

time you play is a benefit, i.e. you don't need a disk drive or cassette deck to load it back.

 

I second this feature request! Trying to troubleshoot a flashcart write in the emulator sucks.

 

As for user's own collections, some are already available on the AtariMax site's forums,

so why the problem with distributing flash-cart images? You usually get the games from

Bill's ftp-serach, a pool-disk or something similar to make your own collection anyway.

 

I don't think this is a concern at all, for the reasons you've stated. So far, no one has released any titles specifically for the flashcart.

[fox]

Impressive list of todo list, and lots of good idea’s…only hope is that you can keep the emulator file size down to a ‘reasonable’ size

(...)

Re: Redirection of DN to Hn devices…Will that cure the prob. with non sparta dos alike dos’s (i.e Atari dos 2x and Mydos) in accessing and reading hard drive directories/partitions

(...)

Emulation of Other A8 disk drives/drive mod’s at hardware level…

(...)

Re: Emulation of Atarimax type flash cartridges…not too sure if that’s a good idea…perhaps you’d better discuss that with Steve/Classics…might be a good idea in as far as ‘creating’ software cartridges for peoples own collection/archives (as long as they don’t start distributing their flashcart images on the internet)

 

Slight modifying of .cas images (so to being compat. with the various cassette to disk programs on ATR format)

 

Instead of emulating specific revisions of Antic/Pokey G/CTIA, offer an option or choice of emulation of antic pokey or g/ctia and how it is emulated (might cut down the code a bit)

 

Re: SID/AMIE…good idea, slight problem is making it compatible with existing Atari mem. Maps and also the fact there’s no software to support these chips on the A8 and lastly how could existing software be converted to supporting these chips (I think we all know how lazy programmers can get)…as I don’t think rom’s exist for the XEME/XEEM o/s (which has the amie/amy code in it I guess)…It could be easier to emulate quad pokey as I am guessing it works similarly to the dual pokey/stereo pokey upgrade, namely the additional sound registers/locations are just dupe’d higher up in the pokey locations/registers and therefore might be easier to convert software like people are already doing for stereo/dual pokey

 

On the ATR image creation option, include an option for formatting for mydos and spartados, also include an option for copying over files from a pc into the recently created ATR as well as creation of new directories (mydos/Sparta compat.), saves having to use a separate program

 

The only problem there would be with the DCB trace option, if your doing it the the built in MLM is you would have to fix the bug where the sector loaded at the point of entering the monitor or pausing the emulation always seems to point at 400hex instead of the proper location (i've not tried it with 4.1 yet as i've gone back to 4.0 final which doesn't have any sound prob's)

 

Is there a reason why there is sound issues in 4.1 and not 4.0 final or did you mess some routine about which resulted in the sound issues in 4.1

 

'reasonable' size: these changes will take years. You won't care about a few additional megabytes needed by the emulator, because you will need 1 GB just to boot your OS.

 

problems in accessing and reading hard drive directories/partitions: DOS 2.x has simply no commands to enter directories. I'm not aware of any problems with H: under MyDOS (in >=2.0.0 naturally).

 

emulation of specific drive types: that's low-priority naturally

 

Atarimax cartridges writes: not very useful probably, emulation of battery-powered RAM carts would be somewhat more useful

 

cas images: I don't know what's wrong

 

chip revisions: I did not undestand you

 

sound chips: actually I've seen SID in a real Atari - there isn't any problem with tunes or player routines, because you can get them directly from the C64; quad POKEY will be easier, naturally

 

filesystem operations on ATRs: no; use a separate program

 

"MLM bug": give an example program name, sequence of your operations and the "proper" loading address so I can check what you mean

 

sound issues: it's just an early beta version of 4.1

[carmel_andrews]

'reasonable' emulator file size.... I was thinking more alone the lines of the following examples....the latest uncompressed gens takes up over 5 meg, the latest uncompressed mess (less roms) takes up 20-30 meg)...obviously compressed sizes are somewhat smaller

 

 

Re: cas images...I was told that created cas images are 131 bytes per block/sector, yet most atari tape-disk programs (atr versions) only work with tapes/cassette images or 128 buytes per block/sector hence problems in using .cas images with things like howfendos/transdisk and even copying bin. files from atari dos's bk to .cas files (thru the emulator), as the above type programs/dos's etc will always assume the cassette block/sector is 128 not 131 bytes long

 

chip revisions: I did not undestand you...You mentioned trying to emulate specific revisions/versions of the GTIA...hence my point

 

sound chips: actually I've seen SID in a real Atari - there isn't any problem with tunes or player routines, because you can get them directly from the C64...You may have seen it...i haven't, the problems will still remain though of knowing how to change the code in existing programs and the embedded datasets (music/note data etc) and also whether the SID chip will compliment the Pokey chip and how it will be incorp. into the atari mem. map and whether it will use all SID's featues or limited SID features (as you will still need pokey for SIO op's)

 

"MLM bug": give an example program name, sequence of your operations and the "proper" loading address so I can check what you mea.....In simple terms, the emulator loads in x number of sectors, you either press f8 (straight to MLM) f9 (pause) and then f8 straight to monitor, no matter how you enter the monitor on loading ATR disk sectors etc, looking at the DCB locations (300 30b) specifically 304/5 (current sector load point) it always seems to point to 400h or 304 is 0, 305 is 4

Edited May 15, 2006 by carmel_andrews

[Kr0tki]

Re: cas images...I was told that created cas images are 131 bytes per block/sector, yet most atari tape-disk programs (atr versions) only work with tapes/cassette images or 128 buytes per block/sector hence problems in using .cas images with things like howfendos/transdisk and even copying bin. files from atari dos's bk to .cas files (thru the emulator), as the above type programs/dos's etc will always assume the cassette block/sector is 128 not 131 bytes long

 

CAS images contain blocks of 132 (not 131) bytes because this is the standard block length as used by Atari OS - the CAS format doesn't change blocks' length, it is simply faithful to the original. So I don't understand why this would made any problems with existing software.

FYI, CAS format supports blocks of any length up to 65535 bytes.

[fox]

'reasonable' emulator file size.... I was thinking more alone the lines of the following examples....the latest uncompressed gens takes up over 5 meg, the latest uncompressed mess (less roms) takes up 20-30 meg)...obviously compressed sizes are somewhat smaller

 

Ah, yes, that's too much of course.

 

Re: cas images...I was told that created cas images are 131 bytes per block/sector, yet most atari tape-disk programs (atr versions) only work with tapes/cassette images or 128 buytes per block/sector hence problems in using .cas images with things like howfendos/transdisk and even copying bin. files from atari dos's bk to .cas files (thru the emulator), as the above type programs/dos's etc will always assume the cassette block/sector is 128 not 131 bytes long

 

".cas" images are meant to contain the exact digital contents of tapes. As Kr0tki mentioned, the Atari OS really writes 132 bytes per record: two sync bytes (0x55), one byte of block type (whether it's the last block of file, etc.), 128 bytes of data and a byte of checksum. This is what is stored in ".cas" files, with headers naturally.

 

chip revisions: I did not undestand you...You mentioned trying to emulate specific revisions/versions of the GTIA...hence my point

 

I meant specific revisions specified by the user.

 

"MLM bug": give an example program name, sequence of your operations and the "proper" loading address so I can check what you mea.....In simple terms, the emulator loads in x number of sectors, you either press f8 (straight to MLM) f9 (pause) and then f8 straight to monitor, no matter how you enter the monitor on loading ATR disk sectors etc, looking at the DCB locations (300 30b) specifically 304/5 (current sector load point) it always seems to point to 400h or 304 is 0, 305 is 4

 

I booted an ATR with a DOS, entered the monitor and saw the loading address of $0880 (a sector buffer of the DOS, as expected).

[Rybags]

A CIO compliant cassette block is 132 bytes (2 timer bytes, 1 control, 128 data, 1 checksum).

 

So, naturally if a .CAS image contains those bytes they would need to be stripped before using them with a custom disk loader (I never use CAS, so no experience there).

 

SID emulation is a sound idea (pun intended). It might encourage development of a standardised hardware mod. There is no "easy" way of converting POKEY / SID music routines - the 2 chips are quite different in the way you do music with them.