fox

May 13, 2006

Dear Cybernoid,

First, use 48 bytes per line rather than the strange number of 45. For horizontally scrolled ANTIC 4 mode with normal (40 characters) screen width the screen data pointer is advanced by 48 bytes per line. This way you won't have to update several LMS addresses in the DL, just one. You can have LMSes naturally if you like, just make sure you update them correctly.

Second, remember that vertical scrolling ends with the first DL instruction that is not scrolled. That is, this instruction is scrolled too. So your DL will look like this:

8 BLANK
LMS 5010 VSCROL HSCROL MODE 4
VSCROL HSCROL MODE 4
VSCROL HSCROL MODE 4
VSCROL HSCROL MODE 4
(repeat)
HSCROL MODE 4
(non-scrolled things here)
JVB

(forget about DLIs here if you aren't an experienced Atari programmer, DLI routines here are time critical)

Total height of your scrolled area will be 8*number_of_instructions_with_vscrol+1 scanlines.

The third thing to remember is that the VSCROL register works in the direction opposite to HSCROL. For example, if you want fine scrolling with the graphics moving up on the screen, increase VSCROL from 0 to 7, then add 48 to the LMS address and switch VSCROL to 0 at the same time.

May 11, 2006

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

May 7, 2006

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.

May 3, 2006

May 3, 2006

I htink Dragonforce sold all his classic consoles/computers and dropped off the scene

from: http://www.atariage.com/development_page.h...evelopmentID=22

Vector is a 3D, Doom-like game originally designed by Piotr Fusik that has been picked up by Dragonforce Europe after work stalled on the project. An Atari Jaguar version is also planned but not yet confirmed. Estimated completion should be before the end of Summer 2005.

ROTFL!

Dear aage admins,

Could you please remove this page with such a ridiculous message? Thank you.

May 3, 2006

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

May 2, 2006

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.

May 2, 2006

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.

May 1, 2006

If you are interested in changes between Atari800Win 2.6 and Atari800Win PLus 4.1 then you can assume that they are completely different emulators, period.

If you really want to browse hundreds kilos of changes, then the changes in Atari800 are in its DOC directory (source package or CVS) and changes in Atari800Win/PLus are in its help file.

May 1, 2006

Make sure that the P: patch is enabled, then boot to BASIC and type:

LPRINT "HELLO, WORLD!"

May 1, 2006

Covox simply consists of two 8-bit D/A converters for the left audio channel and two for the right channel. That's all.

Schematics here:

http://atariki.krap.pl/index.php/Covox

May 1, 2006

The 1020 reference goes to the post about the new graphics terminal idea & associated graphics mode, mentioned here.

Did 1020 include an eraser?

Take a look at the MacOS X version of Atari800, it has some sophisticated emulation of Atari printers.

As for new graphics terminal, why 1020 and not SVG, Flash or other animations? Atari can output them too.

May 1, 2006

Hmm... something's wrong with my above post too.

I'm using Atari800win Plus 4.0 Final. Does this use an older Atari800 engine?

As you can read in docs and the "About" box, Atari800Win PLus 4.0 is based on Atari800 1.3.6.

Atari800 is currently at 2.0.2.

May 1, 2006

<snip>

Something seems a little weird on the display of that message, could you edit it, if you have some time, so it displays properly?

OT:

Just a comment...

I noticed that this forum software doesn't like mismatched

[(Close )/Quote]. Mismatch one pair and you get nothing.

I have spent maybe 10 minutes trying to figure out what's wrong. The nice quote formatting is applied if I cut the post to use only 20 quotes. When I include 21st quote all formatting suddenly disappears. Can you find a mismatched tag pair?

April 30, 2006

Interesting. I didn't know that AMY was popular and supported

At least I know what 1020 and XEP-80 are.

Everything I could tell about AMY was that Perry had put it on the TODO list.

April 30, 2006

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

This is part of item #39. Just to put emphasis on the usefulness of the request.

I'm not sure, but maybe this can help you: ftp://ftp.pigwa.net/upload/k2a.zip

041. 80 Column device emulation.

I just noticed Perry added it to the long TODO list of Atari800.

042. Emulation of a multitude of DIY hardware. Please specify:
Yes, please specify.

Hmm, what were some rare mods that were would be interesting to see in emulation form?

Midi interface (I forget the name),

I think there were at least two different MIDI interfaces for the 8-bit Atari: one was connected to the serial port and the other probably to the joystick port. This could be a nice feature and maybe even easy to implement.

Computer Eyes (is possible via Webcam?)

You mean there was a webcam for 8-bit Atari? Wow.

I was only aware of Video Interface which was a Polish video capture and mix interface. There were probably just a few units of it.

I was refering to the L command (from command line) in MyDOS 4.53 which didn't work with with H: drive but I just discovered that this doesn't work with Atari++ either. Must be a problem with MyDOS itself.

No, it was a problem with old H: routines. I corrected it in Atari800 2.0.0 and MyDOS L command works now.

April 29, 2006

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

What's wrong with programmers?

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

I don't understand it.

002. The HI-RES SUPER 1020 graphics terminal interface

If you mean the 1020 printer, it was quite rare and few Atari programs supported 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.

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

You can define the 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.).

This is a very bad idea because it would allow people to make tons of .exe files and then request

for converters when a new version of the emulator appears.

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

Atari800Win PLus does support command-line switches.

Atari800Win PLus stores the configuration in the Windows registry and you can export/import the registry branch if you like.

007. Ability to load .XEX without having a coldstart

+ load .XEX without INIT/RUN (currently hangs?)

I don't think this makes sense, but maybe I don't understand it.

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

done with a seperate program using savestate files)

Click-and-rip interface for dummies?

009. DirectX stretch mode (like Gens emulator)

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

I don't understand these two.

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

Can you provide technical details?

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

That's an old idea, but it's good.

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

H: devices are significantly better in Atari 2.0.0 than in older versions. I guess the wildcard problems are gone.

014. fix the way the keyboard is emulated.

It's on my TODO list.

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.

I disagree. Nearly all computers have limitations on simultaneous keypresses and side-effects worse than Atari: no key is reported at all, or reported are keys which you didn't press.

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

LOAD"H:XXXXXXXX.BAS option

Done in Atari800 2.0.0.

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

It's already very very close. You'll probably never get 100% in an emulator.

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

It's on my TODO list.

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

Hmm... seen this already.

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

My personal opinion is that it's not worth trouble.

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

It's on Atari800's TODO list.

021. Emulation of the Black box

I've heard something about Black box, but forgot what it is.

022. proper emulation of the diamond GOS cart

What's wrong?

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

Can you explain why it would be useful?

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

sio patch when enabled

I think drive capabilities aren't dependent on the SIO patch being used or not, but I'm not sure.

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

hacking into ATR's)

How do you define "load point counter" ?

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

There are menu options for state load/save.

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)

Hack ATRs with a HEX editor instead. It's really better than any monitor command you could imagine.

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

I don't understand these.

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

that, program loading could be traced exactly.

That's interesting.

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

Pick a number of colums that you think is better than 42 and I'll explain you why 42 is really better.

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

sources.

That's on my TODO list. I just didn't have a good name for it. "flicker fixer" is great.

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

parser for Windows).

How do you think it should work?

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".

I don't understand.

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

Not really. But it could be done better, right.

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

Today it's hard to find a PC with a 3.5" floppy, let alone 5.25".

And it's hard to make an emulator work with a real Atari drive.

And there's little use for that.

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

I agree.

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.

Palette issues need to be discussed in a separate topic, preferable on the emulator's mailing list and not a forum.

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.

Interesting.

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

connection is just plain tedious.

And?

041. 80 Column device emulation.

Could be complicated, and XEP-80 was rather unpopular.

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

Yes, please specify.

043. 6502 code relocator, built into Atari800Win Plus.

There is no universal 6502 code relocator.

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.

The emulator is open-source, you can experiment with it as you like.

045.- PAL/GAL emulator

Hmm?

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.

I don't understand.

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).

That's interesting.

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

independant of Emulator updates.

What plugins you mean?

049. emulate the function of the AMY sound chip

It's on the TODO list

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.

H: does support binary load.

For file operations on ATRs use something like AtrUtil.

April 29, 2006

There are only two ways to be 100% sure about the Build engine itself:

1. Decode the Build Engine source code. (Good luck, it's not that easy to read.)

2. Ask Ken Silverman.

If it's important enough to you to figure out how the Build Engine works (say, you're working on an Atari engine based on similar principles), then both options are worth your time.

The third way is to ask me since I managed to understand the Build Engine and write 8-bit Atari version of it.

April 29, 2006

Furthermore, Numen isn't particularly relevant to a discussion on free-form 3D rendering, since it's based on a ray-cast engine.

If I may point out, Duke Nukem 3D was based on a Raycaster known as the Build Engine.

Build Engine and Numen do not use ray casting.

January 17, 2006

You did not write what system you want the emulator for.

If PC/Windows then:

http://atariarea.krap.pl/PLus/index_us.htm

If other then:

http://atari800.sourceforge.net

You'll need to burn the CD yourself, though.

December 29, 2005

knows if there are any other high level scientific calculator funtions related to 6502 assembly

Assembly is a low-level language.

I see that there are a few other functions related to the BASE-N (ie: NOT, AND, OR, XOR, XNOR) function and I wonder if these are useful for something as well.

They are very useful for low-level programming, but there's little sense in using a calculator to compute them.

Some other bit-wise operations are ASL or LSL (it's the same), LSR and ASR.

December 16, 2005

When coding paddles/mouse/trackball emulation I wasn't aware of the 5200 trackball. Therefore "Trak-ball" means just CX22 or CX80 and not the 5200 controller.

I need the following information: the "code" of the 5200 trackball, and the list of games that support it.

December 14, 2005

I really am impressed that Russians can calculate things like 23*14 or 17*53 'in mind'. Maybe they don't need computers at all?

December 14, 2005

They should support the 5200 mode better in aw8p.

981278[/snapback]

December 3, 2005

Report this problem to Marcin Lewandowski: [email protected]

Sign In

Profiles

Member Map

Forums

Blogs

Gallery

Calendar

Store

Posts posted by fox