fox

'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

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.

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.

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.

2

ROTFL! Dear aage admins, Could you please remove this page with such a ridiculous message? Thank you.

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

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.

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.

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.

Make sure that the P: patch is enabled, then boot to BASIC and type: LPRINT "HELLO, WORLD!"

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

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.

Hmm... something's wrong with my above post too. 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.

OT: Just a comment... I noticed that this forum software doesn't like mismatched 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?

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.

I'm not sure, but maybe this can help you: ftp://ftp.pigwa.net/upload/k2a.zip I just noticed Perry added it to the long TODO list of Atari800. 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. 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. No, it was a problem with old H: routines. I corrected it in Atari800 2.0.0 and MyDOS L command works now.

What's wrong with programmers? I don't understand it. If you mean the 1020 printer, it was quite rare and few Atari programs supported it. We thought about it many years ago and it turned out more complicated than useful. You can define the print command. 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. 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. I don't think this makes sense, but maybe I don't understand it. Click-and-rip interface for dummies? I don't understand these two. Can you provide technical details? That's an old idea, but it's good. H: devices are significantly better in Atari 2.0.0 than in older versions. I guess the wildcard problems are gone. It's on my TODO list. 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. Done in Atari800 2.0.0. It's already very very close. You'll probably never get 100% in an emulator. It's on my TODO list. Hmm... seen this already. My personal opinion is that it's not worth trouble. It's on Atari800's TODO list. I've heard something about Black box, but forgot what it is. What's wrong? Can you explain why it would be useful? I think drive capabilities aren't dependent on the SIO patch being used or not, but I'm not sure. How do you define "load point counter" ? There are menu options for state load/save. Hack ATRs with a HEX editor instead. It's really better than any monitor command you could imagine. I don't understand these. That's interesting. Pick a number of colums that you think is better than 42 and I'll explain you why 42 is really better. That's on my TODO list. I just didn't have a good name for it. "flicker fixer" is great. How do you think it should work? I don't understand. Not really. But it could be done better, right. 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. I agree. Palette issues need to be discussed in a separate topic, preferable on the emulator's mailing list and not a forum. Interesting. And? Could be complicated, and XEP-80 was rather unpopular. Yes, please specify. There is no universal 6502 code relocator. The emulator is open-source, you can experiment with it as you like. Hmm? I don't understand. That's interesting. What plugins you mean? It's on the TODO list H: does support binary load. For file operations on ATRs use something like AtrUtil.

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

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.

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.

Assembly is a low-level language. 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.

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.

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?