Jump to content
IGNORED

Apple II emulator


Kaz atarionline.pl

Recommended Posts

Are there specific options that need to be set to play The Hobbit? I seem to only be able to boot Spy vs. Spy successfully... Every other game seems to give an error and I'm unable to get back into the emulator's menu...

 

Also... How are the disks converted? I see that they're DD disks, but I'm curious as to how the disks are converted (35 tracks, 16 sectors/track IIRC), more specifically, how the 1st 3 sectors handled... I'd be more than happy to jump on board and convert a few apple classics to .atr... Such as Airheart, The Wizardry series (*sigh, no point in finishing the A8 version now...), the SSI Gold Box RPG's, etc, etc... You know... To help compatibility tests and such...

 

Is it me, or does anyone else find it ironic about using a PC to emulate an Atari 8bit (just to slow on real hardware) emulating an AppleII?

 

Great!

 

Thank you.

 

Bob

 

 

:) http://www.7-zip.org/

 

Explorer type archive. Some good qualities some not so good..

 

Regards,

 

WinRAR handles the 7zip format just fine as well...

Edited by dwhyte
Link to comment
Share on other sites

I google translated the page. It emulates the earliest Apple II's with Integer BASIC; not much Integer BASIC software requires 80 columns.

 

So I guess that a few people aren't impressed by this software becuase it doesn't have 80 columns. Maybe those peope should write a better emulator. I want to run Apple II stuff on my VIC-20.

Link to comment
Share on other sites

I don't know if this emulator uses the technique, but there was software that could display 80 columns on the C-64's hires screen by drawing skinny 4x8 pixel characters. I myself had a terminal program that had 80 columns. Was this technique ever used on Atari machines?

 

There were a number of techniques to emulate 80 columns on a bitmapped screen. Scrolling over a wider screen was one; hi-res screen was another, my personal favourite was "Flickerterm" which uses a narrow character set on a normal screen, then flips between two screens offset by 4 dots every VBLANK; uses less memory (1k charset + 2x 1K screen) that the hi-res screen (8k) and is also more responsive.

Link to comment
Share on other sites

So I guess that a few people aren't impressed by this software becuase it doesn't have 80 columns. Maybe those peope should write a better emulator. I want to run Apple II stuff on my VIC-20.

 

Who's not impressed? :x

 

 

 

This piece of software is a kinda sorta ground-breaking achievement for the A8... :lust:

 

EDIT: Found out what was causing the errors while booting The Hobbit... PAL only it seems... So alas... I won't be able to test fully on real hardware... Spy vs. Spy works fine on NTSC system though (albeit a quite slow)... Emulating an emulator is the only way I can get full usage... But... I still would like to help convert Apple disk images to .atr's...

Edited by dwhyte
Link to comment
Share on other sites

Our family's first computer was a 1040ST and of course it had a fancier processor and fancier video than the 8-bit line but other than that, I'm not overly impressed. For some reason it seems to have a somewhat strong following too. I actually bought a 130XE just because it reminded me of the ST, yet I think it's a better computer :)

 

You'd probably like playing with Amigas then. Many of the same engineers behind the 2600 and the A8 chipset designed the Amiga chipset including the legendary Jay Miner. Interestingly, the ST hardware shares engineering personnell with the C-64 designers. These two companies went through a brief period of incestuous personnell interchange in the mid-eighties.

 

That basically leaves low-level programming enthusiasts one choice to produce the best of the 8-bit and 16-bit machines-- memory map the Atari 8-bit into the Amiga's memory space. Perhaps, reserve 64K..128K of the megabytes of 680x0 memory space for the 6502 and internally genlock the Atari video output on the Amiga's. I guess we would run into the similar problem as the Apple of trying to get copy-protected or incompatible formatted disks' data fed into the Atari's disk input.

Link to comment
Share on other sites

That basically leaves low-level programming enthusiasts one choice to produce the best of the 8-bit and 16-bit machines-- memory map the Atari 8-bit into the Amiga's memory space. Perhaps, reserve 64K..128K of the megabytes of 680x0 memory space for the 6502 and internally genlock the Atari video output on the Amiga's. I guess we would run into the similar problem as the Apple of trying to get copy-protected or incompatible formatted disks' data fed into the Atari's disk input.

 

It wouldn't be trivial. The faster models of the Amiga might manage to emulate the 6502 acceptably but something like an A500 wouldn't manage it. Also, the Amiga isn't a 1 for 1 upgrade of the A8. It is an entirely different machine that has an engineering concept in common with the A8 (dumb but versatile scanline generator controlled by either a co-processor or the host cpu). Nonethless, I believe any Amiga could manage a passable simulation of the A8 chipset but emulating a 6502 CPU on top of that is a killer. As it happens the Atari800 emu is supported on the Amiga but I imagine it requires at least an A3000 and maybe even a 4000. Since Atari800 is crossplatform, I imagine the artful mapping of Amiga features to A8 features is minimal.

 

This Apple emulator we're discussing is possible because the Apple and A8 use the same CPU and the Apple II generally has a simpler video system than the A8 that can be mapped to the A8 with some degree of success.

Link to comment
Share on other sites

This Apple emulator we're discussing is possible because the Apple and A8 use the same CPU and the Apple II generally has a simpler video system than the A8 that can be mapped to the A8 with some degree of success.

 

I don't think so. Not entirely. Yes, the Apple II has a simple (though rather eccentric) video system that is easy to emulate, but I'm 99.9% sure that this emulator is using an interpreter to execute Apple 6502 code. I hypothesize this model for the emulator's operation:

 

The 6502 code in interpreted. No big trick; interpreters for 6502 code were built into every 6502 monitor from back in the day; this is how the monitor was able to "STEP" through sections of code and display the contents of the registers after each instruction execution. The emulator's interpreter would execute code at maybe 1/10 the speed of actual direct execution by the CPU, and would interpret native Apple II machine language software including the Apple's ROMs (which include the Integer BASIC interpeter).

 

Since the Atari and Apple both need zero page memory, and each needs its hardware memory maps in a specific fixed place; so pretty much all of Apple's memory would have to be virtualized into new locations in the Atari's memory; this is why the Apple's machine code need to be interpreted instead of executed directly.

 

A portion of the Atari's memory would contain the emulated Apple II's memory, but another portion of the Atari's memory would have to contain the Atari's screen maps. The machine code interpreter would have a list of memory locations that have input/output functions in the Apple II; whenever virtualized Apple memory is written to, this list is consulted; if, say, part of the screen's memory map is changed, the emulator pauses in the interpretation of code, and updates whatever part of the Atari's screen needs to be changed. Likewise, the emulator would know how the Apple's keyboard, paddle controllers, etc. are mapped in memory so that when this memory is referenced, the correct information can be read from the real Atari and transliterated to the virtual Apple.

 

And the whole thing is slow. Ten or more times slower than a real Apple II.

 

So the Apple II and Atari having the same CPU is not a big factor in the feasibility of this emulator; an interpreter can be written to run any instruction code on any CPU. Maybe someone will write an Apple II emulator for the TRS-80 Color Computer.

 

Now I just read somewhere else that in the early 1980's, a software company developed VIC-20 games on an emulator that ran on an Apple II. I bet that the VIC's graphics screens really looked like crap on the Apple's HirRes screen.

Link to comment
Share on other sites

> but I'm 99.9% sure that this emulator is using an interpreter to execute Apple 6502 code

 

no

 

> this is why the Apple's machine code need to be interpreted instead of executed directly.

 

:-) no

 

> And the whole thing is slow. Ten or more times slower than a real Apple II.

 

no. faster than real apple

 

---

emulator Artaxa uruchamia programy apple ze 100% szybkoscia to translacja ekranu zabiera (nie potrzebnie) cykle. (pre) translacja grafiki umozliwi uruchomienie programow apple z wieksza szybkoscia od oryginalu. proponuje obejrzec filmiki. pierwszy bez translacji, drugi z translacja grafiki.

1. http://atari.pl/apple.rar

2. http://atari.pl/galaxian.rar

 

Artax dodatkowo co umyka Waszej uwadze zrobil dodatkowo emulacje stacji dyskow, to jest absolutna nowosc, uruchomiony program na apple moze odwolac sie do stacji atari i zaladowac dalsza czesc. czapki z glow.

Link to comment
Share on other sites

emulator Artaxa uruchamia programy apple ze 100% szybkoscia to translacja ekranu zabiera (nie potrzebnie) cykle. (pre) translacja grafiki umozliwi uruchomienie programow apple z wieksza szybkoscia od oryginalu. proponuje obejrzec filmiki. pierwszy bez translacji, drugi z translacja grafiki.

1. http://atari.pl/apple.rar

2. http://atari.pl/galaxian.rar

 

Artax's emulator runs Apple II programs at 100% speed, only the graphics-translation eats (a bit too many) cycles. Thus pre-converting the graphics first will allow running apple-programs at 100% or even greater speed than the original. Let's see the following:

1. http://atari.pl/apple.rar (without graphics-translation)

2. http://atari.pl/galaxian.rar (with it)

 

 

Artax dodatkowo co umyka Waszej uwadze zrobil dodatkowo emulacje stacji dyskow, to jest absolutna nowosc, uruchomiony program na apple moze odwolac sie do stacji atari i zaladowac dalsza czesc. czapki z glow.

 

Additionally Artax has done disk drive emulation there (which probably escapes your notice). It's absolutely new and running program can access the drive anytime it wants. Hats off!

Edited by miker
Link to comment
Share on other sites

That basically leaves low-level programming enthusiasts one choice to produce the best of the 8-bit and 16-bit machines-- memory map the Atari 8-bit into the Amiga's memory space. Perhaps, reserve 64K..128K of the megabytes of 680x0 memory space for the 6502 and internally genlock the Atari video output on the Amiga's. I guess we would run into the similar problem as the Apple of trying to get copy-protected or incompatible formatted disks' data fed into the Atari's disk input.

 

It wouldn't be trivial. The faster models of the Amiga might manage to emulate the 6502 acceptably but something like an A500 wouldn't manage it. Also, the Amiga isn't a 1 for 1 upgrade of the A8. It is an entirely different machine that has an engineering concept in common with the A8 (dumb but versatile scanline generator controlled by either a co-processor or the host cpu). Nonethless, I believe any Amiga could manage a passable simulation of the A8 chipset but emulating a 6502 CPU on top of that is a killer. As it happens the Atari800 emu is supported on the Amiga but I imagine it requires at least an A3000 and maybe even a 4000. Since Atari800 is crossplatform, I imagine the artful mapping of Amiga features to A8 features is minimal.

 

This Apple emulator we're discussing is possible because the Apple and A8 use the same CPU and the Apple II generally has a simpler video system than the A8 that can be mapped to the A8 with some degree of success.

 

You misunderstood what I stated. I wasn't talking about software emulation. I was talking about memory mapping the Atari system into Amiga's memory space. For example, banking in the entire Atari system board into Amiga's chip RAM at $70000..$7FFFF so Amiga 680x0 processor can access it as well as Atari's 6502. You know like dual core processing with two incompatible processors using dual-port RAM and genlocking the two video outputs together. Even memory mapping into Atari ST would be good, although not as good as having a Atari 8-bit and Amiga.

 

Yeah, software emulation would have some major problems since Amiga CIA timer frequency is different from POKEYs, ANTIC refresh for lower-resolutions would be faster on Atari, etc.. etc.

Link to comment
Share on other sites

So how does this emulator work, then? Does it do some kind of translation of the apple II software?

 

Just want to state that your idea of interpretation of every single instruction is a very poor algorithm. Given that both machines have 6502 processors and given that Apple II has very little custom hardware to emulate, one would have to take advantage of that fact that >99% of instructions should go through as is. One method would be to recompile the compiled EXEs so that I/O locations get vectored to exception handler and the rest of the software runs full throttle. To aid that one could also remap ANTIC graphics so they correspond to same graphics area as Apple's and do fix-ups in the background timer procedure. Also, you should note that you can recompile the Apple ROM area and swap out the Atari ROM and put Apple ROM to same area. Also I/O area of Apple is $C000...$CFFF so it does not conflict with Atari's I/O area which is at $D000..$D7FF.

Link to comment
Share on other sites

> Are you familiar with how Apple II graphics are mapped?

 

 

mode equ $f

DL dta $70,$70,$70

:192 dta $40+mode,a(apple_ekr+((#%8 )*$400)+((#%$40)/8)*$80+(#/$40)*$28)

dta $41,a(DL)

Edited by xxl
Link to comment
Share on other sites

And err,

(still) how do you convert Apple programs into Atari *.ATR images ?!? By hand or is there already some PC program available that does this automatically...?!? How about a C64 emulator for the A8 har har har...?!? (And now Oswald will kill this thread aaaaaah...)

 

-Andreas Koch.

Link to comment
Share on other sites

> Are you familiar with how Apple II graphics are mapped?

 

 

mode equ $f

DL dta $70,$70,$70

:192 dta $40+mode,a(apple_ekr+((#%8 )*$400)+((#%$40)/8)*$80+(#/$40)*$28)

dta $41,a(DL)

 

I have no idea that that means. Is this supposed to be code that makes the Antic display an Apple HiRes screen?

 

The Apple maps hires graphics in horizontal rows of bytes, and the rows have a really screwy arrangement in memory. To convert position order to memory location, you switch around the bits in the x coordinate and multiply by 40, then you add y/7. Apple Hires also uses a only the lower 7 bits in a byte to map pixels, with the highest bit being used to select between 2 color pallets. Each pallet has black, white, and two complimentary colors. But the colors displayed in the 7-pixel block are also determined by the pattern of pixels displayed. Can the Antic really recreate this screwy screen map?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...