JohnPCAE

Just some idle speculation... I was bored and did a little mocking up of a Zaxxon screen, taking care to observe the color limits for FG/BG mode. It's just a proof-of-concept drawing to explore what might have been possible. What games do you think could have been done better, within the Inty's capabilities?

The Intellivoice bus definitely has a lot of potential -- controller interfaces, savegame support, etc. I didn't know that most of them didn't have the connector populated. I guess I was one of the lucky ones.

Here's a possible use for 2600 interlacing...use it with Sega Master System 3D glasses. Those made use of the odd and even frames for the two separate images.

The text on the status bar is normal. My memory is hazy, but I think that was for hotkeys you could use to start a game with a particular bankswitching setup. It's somewhat obsolete nowadays. I can't get MMSBC 2 to reset when I shoot something. I set it up as a standard 16k game in the profile settings, and I played it a little bit (just to 114 points or so). The sound is something of a sore spot with me. I'm not happy with how it's coming out, either. That's going to take some playing around to figure out how to make it better...

This fills a gap that was empty for way too long! Count me in

Thanks for the bug report. I've fixed #2 and will take a look at #1. If there are any more issues, would folks mind posting them? I'd like to accumulate as many fixes as possible before posting another version. Regards, John

A-ha. There was a bug in handling opcode $6B. Now the game runs. Attached is a new version: Changes: 1. Updated most toolbar images to 24-bit. 2. Fixed opcode $6B. 3. Changing HMxx won't immediately move an object if the change happens after the HMOVE for the previous value has already completed. 4. Fixed the early-HMOVE calculation. 5. Fixed the debugger so that tracing, stepping over an instruction, etc. won't blank the screen. 6. Fixed the most-recently-used list on the File menu so that games will start correctly. PCAEWin_2.9.zip

Never mind: that appears to have been a red herring. It looks like there were two issues: 1. My handling of early HMOVEs was just a teensy bit off (2 pixels in the calculation) 2. I wasn't handling the case where a write to a HMxx register should have no effect when it occurs too late. I have the title screen looking correctly now. Does the game use a special bankswitching scheme, or is it one of the standard ones?

I'm stepping through the M.M.S.B.C. II title screen code in the PCAE debugger and comparing it with the title kernel source. It looks like the title kernel expects certain LDA Abs, Y instructions to take 5 cycles instead of 4. My understanding is that it should only take 5 cycles if it crosses a page boundary. For example: $12D0 B984B7 LDA $1784, Y $12D3 851C STA GRP1 $12D5 B99CB7 LDA $179C, Y $12D8 851C STA GRP1 The kernel seems to think the LDA instructions should take 5 cycles instead of 4, but I don't see why that would be the case as Y is small (10 or less). Can anyone enlighten me? Regards, John P.S. I encountered several bugs in my debugger and will be releasing a version 2.9 at some point, even if I don't fix this issue.

Hmm.. Chalk me up as intrigued (grin). I don't know if I'm all that hardcore anymore, though I did finally land all 125 (not CIB, though...I don't have that kind of space).

I've been trying to learn a little bit about the Arduino and I had a weird thought...could an Arduino be interfaced to the ECS ports (tape in/out, aux, controller) to enhance what's possible? I'm wondering if this would allow for an easy way to add things like savegame support, extra memory storage, or other ideas (the Arduino can interface to a lot of different things). It might mean having to completely reverse-engineer the ECS E0/E1/E2 UART bit settings to squeeze out its full potential. I wonder if some of the bits control the parity, number of stop bits, baud rate, or number of data bits. Another possibility might be using the ECS 26-pin expansion port, though not all of them have the connector for it (mine doesn't, for instance). mouser.com seems to have a connector that might be a good replacement, though, so this might not be all that big a hurdle. Anyway, just some idle thoughts I had when not working on other projects... John

Hello, It's been a long time since I did anything with this emu, but one day I got bored and decided to try to fix a few things. I've posted PCAEWin 2.8 up on a free sharing site for anyone who might be interested. I don't have a website or anything to host it, but hopefully it will be available for at least long enough for people who still use it to download a copy. It's just a maintenance release, but I'm hoping that any remaining stability bugs are now squashed. There was a bug in the CPU detection code that could have caused a crash. I also upgraded the AVI code so that it will save the sound as well as video. I started working on a set of comms classes with the intention of rewriting network support from scratch, but honestly I have no idea how to accomplish network play without network lag making it unplayable. There's a comms.pas file included in the source that has the new comms code I wrote, but nothing is using it..Hopefully it will be useful to someone. I'm up to my eyeballs (and then some) on other projects, so I can't guarantee further support for this, but I'll at least try to check the forums over the next few days to see if there are any major issues. Regards, John Dullea PCAEWin 2.8 Download link: http://www.filedropper.com/pcaewin28 P.S. Hmm, it looks like I can attach the whole thiing right here, so here goes... PCAEWin_2.8.zip

I almost don't put it past George to take it this far...almost...

I've recently heard that IntvWin is no longer available on the net, and that it doesn't run on XP. I made the same fixes to it that I had made to PCAEWin 2.7 and posted version 1.3: http://www.savefile.com/files/1022557 I'm short on XP boxes to try it on, but I have one that came with XP Tablet Edition and it tested fine. Would anyone mind giving it a try? I know that in the Intellivision world there are far more accurate emulators out there, but apparently some people are looking for a version of this that works.

As promised, here is hopefully a fixed version of 2.7. It still has Kaillera in it as that will take some time to remove, but hopefully it won't crash, at least... http://www.savefile.com/files/977442

That must be it. PCAEWin works on my non-HT boxes but crashed on my HT box. Well, I think I have that bug fixed. I'll pack it up tonight and post it so you all can try it out.

Many Thanks John! Once again , Thanks John. Unfortunately, it crashes on me immediately after double-clicking on PCAEWIN.EXE AppName: pcaewin.exe AppVer: 0.0.0.0 ModName: pcaewin.exe ModVer: 0.0.0.0 Offset: 00025d5b JL What OS are you running/what is your system configuration? I'll take a look at it to see if I can learn anything. I've started the process of redesigning how instances of PCAEWin will talk to each other, starting with the sockets layer. I think I have something that's pretty robust and generic, though I'll of course have to test it. Still, step one of the redesign is pretty much done. I'll be working my way up the protocol stack one step at a time... I get a similar-but-different error: AppName: pcaewin.exe AppVer: 0.0.0.0 ModName: kernel32.dll ModVer: 5.1.2600.3119 Offset: 00012a5b I edited the PCAEWIN.INI file before starting PCAEWIN.EXE, and set the various directory paths to the ones I'm using. Does it have to be in C:\emu\2600? Because I'm using C:\Atari\2600 as the main one (and using various subdirectories off of it, keeping their names the same as what was already in the PCAEWIN.INI file). PCAEWIN itself is in C:\Atari\2600\Emus\PCAE\2.7b (since I already had an older directory named 2.7). What about DirectX, do I really need to use DirectX 5, or can I use 9.0c? Should I copy the various .dll files anywhere, or just leave them in PCAE's directory? I'm on Windows XP Professional, Service Pack 2. Michael IIRC, PCAEWin 2.7 will crash on Windows machines using Hyperthreading. I set the bios of a hyperthreaded Intel chip which was crashing PCAEWin to non-hyperthreaded (sorry if I'm using all the wrong terms) and PCAEWin worked properly. I cannot find the original post where this was discussed, but taking a shot in the dark, does this have anything to do with the way the PCAE 2.7 binary was compiled? Cheers, Tony I tried it out and I found that I was crashing as well, and I'm running Win2k. I tracked it down to my MMX-detection logic, and I've got it working right now. I'll keep chugging on it tomorrow and see how long it takes to do away with Kaillera before I release anything, as I suspect that it won't take long.

Many Thanks John! Once again , Thanks John. Unfortunately, it crashes on me immediately after double-clicking on PCAEWIN.EXE AppName: pcaewin.exe AppVer: 0.0.0.0 ModName: pcaewin.exe ModVer: 0.0.0.0 Offset: 00025d5b JL What OS are you running/what is your system configuration? I'll take a look at it to see if I can learn anything. I've started the process of redesigning how instances of PCAEWin will talk to each other, starting with the sockets layer. I think I have something that's pretty robust and generic, though I'll of course have to test it. Still, step one of the redesign is pretty much done. I'll be working my way up the protocol stack one step at a time...

Occasionally I still receive emails asking for PCAEWin 2.7, which has some small fixes that should allow it to run under Windows XP. I don't have permanent hosting, but in the interests of making it available to anyone who might like it I've uploaded it to one of the free hosting sites: http://www.savefile.com/files/972316 I know I haven't worked on this in a very long time, but in the years since PCAE I've still been writing code for other projects and I've become a much better, more seasoned developer. I'm considering redesigning the network-play code (throwing out Kaillera in the process) if I can spare some time. No guarantees, but I believe that it may be within my abilities to finally do it right. Anyhow, in the interim, here is the latest of what I currently have... Enjoy, John Dullea PCAE Developer

I have never been happy with Kaillera. If I were to do it today I'd simply write my own socket code, invent my own protocol, and just use that. I've learned enough in the years since PCAE 2.6 that I would probably take that course, and package it all into a DLL that the emu could simply use. At least then I'd have control over the source to the network layer.

I don't think Matt maintains it anymore. He originally hosted it for me on his own site, then moved it to classicgaming when he had to move on (life gets in the way, somteimtes). There were a lot of issues with classicgaming and some other project that I don't remember right now, and a lot of people were moving away from it. I hosted the later verions up to 2.6 on vg-network.com (Dave's Video Game Classics), but it looks like the site has changed and I'm not sure if they even host emu's anymore. I don't have the contact information for them or how to login to where I used to upload it. It looks like the site has undergone a total transformation. From my standpoint I don't much care where it's hosted as long as it's available for everyone. I have a SourceForge login for AutoREALM and I'm tempted to open up a SF project for it, but I don't have any hosting for a webpage and it seems to be a waste of SF resources for a project that I hardly ever touch anymore.

I did some reading through some of the other threads on the 2600...I do a lot of coding, but I don't do much with PCAE anymore because I've sort of moved on to other things (e.g: AutoREALM, as well as a few other things). I've also written a fictional novel and I'm working on the sequel. If there are some issues with PCAE, I'm not against trying to squeeze in some fixes, but they probably won't happen quickly. For those of you who have recently asked for PCAE 2.7, check your email One of the reasons for the long-time problem with XP is that none of my boxes run it I'm exclusively running Win2k here, and it wasn't until I could borrow an XP box for a while that I could do some playing around to find out what was wrong. It turned out to be a bug in the screen buffer code when using full-screen video. If anyone has any problems with 2.7, feel free to email me at johnpcae_at_yahoo_dot_com. I also read that there have been some issues with illegal opcodes, especially the SBX opcode. If I only had a nickel for every time one of those things gave me hearburn As someone else posted elsewhere, examples of illegal opcodes are rare in the extreme, so while it's possible to code for them (and PCAE does support most of them), they're just about impossible to test. I coded the 6502 kernel based on two books that I had in 1995 (and still have on my shelf): "Assembly Language Programming with the Commodore 64" and "Compute!'s Programming the Commodore 64". The first doesn't contain anything on illegal opcodes, but the second one does (though I don't know how complete it is). I think I also have a text file somewhere that I found on the net that has a little info. Basically illegal opcodes were a real shot in the dark and all I could do was hope that I got it right. Today, with things like the Cuttle Cart it's actually possible to do some real testing. If there are problems with illegal opcodes and someone has a good reference on them, it might be possible to make some fixes (the assembly code is pretty simple, though I haven't looked at it in years). I also saw something about "phantom fetches" or somesuch. This is the first I've ever heard of such a thing -- what the heck are those?

I guess the days of ASM, U-pipe and V-pipe checking, miserly register allocation, and ASM macros for loop elimination are days gone by, though I suppose that sort of thing could allow emulation of some pretty killer systems today. Some of it has become redundant, since the compiler has gotten a lot smarter and does it for you. I would think so. I've had Stella running at approx. 800 fps in software mode and 600 fps in OpenGL, and this is at 4x zoom. I suspect the other emulators would do the same. Ironically, the real CPU killer is getting the video to the video card. Not actually generating it, but pushing it to the card. I'm still working on ways of speeding that one up. 993565[/snapback] Yeah, getting the video to the card is a pain, especially when you can't write to bare metal...the DOS version, using a tweaked 160x200 VGA mode was hella fast. For the Windows version I use MMX instructions to double-up the pixels if they are available, and that gives good performance.

(sigh...) The times, they sure have a-changed. I started PCAE back in 1995, for the PC I had, which was a Pentium-90. One reason it's not portable is because I was trying to get full-frame emulation on the box I had, which meant squeezing every single nanosecond out of it that I could. I would then test it on my work box for good measure, which was a Pentium-60. I even tried it out on my old 386/33 for the heck of it, and tried to write a little program that would allow multiplayer over null modem (RLE-compress the screen data and pump it to the slower box, which would render it--unfortunately a 115,200 baud UART just wasn't fast enough--Ethernet? what's that?). I guess the days of ASM, U-pipe and V-pipe checking, miserly register allocation, and ASM macros for loop elimination are days gone by, though I suppose that sort of thing could allow emulation of some pretty killer systems today. Of course I could probably get 1000 fps on PCAE today, but even my monitor isn't that fast

First, let me say congratulations to the Stella team for Stella 2.0. It's been a long time coming, and it looks to be well worth the wait. The release got me thinking...I've had PCAE 2.7 sitting on my hard drive for a long time now and I've been too lazy to release it. It's just a bug fix of 2.6 that's designed to play better with XP (as well as fix a few other bugs and add some minor usability improvements), but if anyone wants to host it I'd be happy to email it out. I don't work on it anymore (I've moved on to other things), but hopefully it will solve most of the problems that people have had with it. If anyone's interested, send me a PM and I'll send a ZIP out (with source, as usual). John Dullea P.S. I looked into posting about this a while ago, but I lost my AtariAge login and had to make another one (with a different email -- if you forget your login you're out of luck since supplying your email isn't enough to get it emailed back to you). Anyhow, better late then never.