Tom

Windmill Software's Digger?

Dan Boris has at least cartridge pinouts for the microvision. No idea what you're supposed to do with the LCD lines exactly, tho. http://www.atarihq.com/danb/Microvision.shtml

- robotfindskitten 7800 is complete - I created also a demo (there are somewhere threads about it, but this is THE download location: http://www.pouet.net/prod.php?which=13900)

Haven't tested these ROMs yet, but considering the fact that both emulators originate from the same code base it's likely that Hackmann's Version has the same problems.

This is perfectly OK, and should imo be left in as default location for the configuration file.

Works ok so far on my Debian box. One thing I noticed and really annoyed me: You're writing ProSystem.ini to the current directory, and when one launches the program from another working directory again, that directory will end up with a ProSystem.ini too.

Makes me want to give it a try to get an SDL-only version working. I was doing the same with emu7800 and sort of got it working (didn't do sound emulation yet, though, and never released binaries), but I always liked ProSystem better. The question is, did anybody already pick up work on something in that direction?

C64 BASIC parses and indeed tokenizes each line as you enter it. If you entered a leading line number, the line is stored in memory as part of the current program, if you didn't enter a line number the line is executed immediately. So, when executing a program or a single line in immediate mode, C64 BASIC doesn't really need to parse human readable text anymore, which makes things faster. Additionally, because it doesn't store PRINT or INPUT etc. as text in memory but as some one byte token, programs take up less space. Now, when the interpreter encounters the PRINT token, it just calls some routine in ROM which IS the PRINT command, so there's no translation to assembly language done. I suppose most BASICs on 8 bit computers handled programs similarly. Whatever, I think the *main* slowness from C64 BASIC comes from the fact that all (!) arithmetic is done using some floating point format (don't know wether it's IEEE sevenhundredandsomething, and it doesn't really matter anyway). IIRC there were integer variables, but their values were converted to float when they were read, so using integer variables might have made things even slower because the interpreter was spending loads of time converting between integer/float. Anyway, you do know CC65? This is a somewhat okayish 6502 C Compiler, and the authors provide support (that is, basically, libraries and linker scripts) for a number of computers/consoles.

I wish he'd make the source code available, after all he's distributing the GPL (!) with the binaries. Emailed him twice or so, but never got a reply. I guess he just doesn't realize what putting software under the GPL means. Whatever. I eventually gave up on it, didn't considered it to be worth the time.

I've been working on getting emu7800 (that one is written in C#) to work on Mono. There are quite a few Win32 specific calls and Win32isms I want to rip out, but it comes along nicely. Or would come along nicely, if I had time to work on it, but probably not again before next year.

1. ProSystem doesn't use .NET 2. Even if it did, .NET isn't *that* slow (.NET assemblies get JIT compiled on both MS.NET and Mono, which is partially why they tend to take a bit longer to load. One could still whine about garbage collection and the CLR in general slowing things down, but that's another story). 3. Wine...well...stands for Wine Is Not an Emulator. Because it doesn't emulate anything. Windows and *x86* Linux are similar enough that Windows executables can be made work on *x86* Linux and vice versa. After all, both Win32 and x86 Linux binaries contain, guess what, x86 code. What Wine "basically" does is provide replacements for Win32 API calls. To sum it up, no it's not terribly surprising running ProSystem on Wine works fine. The only amazing thing is the amount of work people have put into Wine to duplicate all those Win32 APIs.

I Just spent a fair amount of time playing around with Thomas' sample

Nah, it's definitely possible. Proof: http://www.pouet.net/prod.php?which=13900. Can't seem to find the source. Feel free to disassemble the binary. Locating sixchar routines (which is what a 12char basically is) is generally simple, just look for code that bashes the GRPx registers. Btw, the Stellar Track kernel is interesting because iirc it doesn't move the sprites +/- 8 pixels. It moves +/- 7 pixels and does the missing adiditonal pixel by shifting the graphics data before writing it to the registers. This in turn works because the characters are only 7 pixel wide. You can't use this trick if you need 8 pixel wide columns, but the early HMOVE trick is way cooler anyway and not harder to implement.

Nothing to do with data width. It's some field of a structure that was changed from a signed to an unsigned type. Can't remember which one exactly and wether fixing that typedef fixes the problem or reintroduces new ones. I think I posted about that on the stella list, I could look it up if it's of any interest.

No.

ProSystem (Atari 7800 emulator for Win32 - *supposedly* open source) works okayish with Wine.

Well, the thing allows you to findkitten on the Atari 7800...so it's finished and probably I'm not going to work on it ever again (unless I come across a new list of NKI messages I want to include. Don't know what happened in this field).

What document ?

You're still a bad programmer with your version of that macro You should always put parentheses around such a macro, in case it is used in a larger expression (which is, admittedly, unlikely with that particular RGB macro. Then again, as a rule of thumb, in software development if you thought something is unlikely to happen it will happen). #define RGB(a, b, c) (((a)<<16)|((b)<<|( c))

That's because you only downloaded the Atari support files. You also need to get either the cc65 binaries for your host platform or the cc65 sources and compile them yourself. Shouldn't be that difficult and it should be possible under OSX, but I've never had a Mac.

Ah, be a good boy and go bitch around somewhere else, will you please ?

What was the problem with binutils anway ? I can compile them on my Debian box using something like "./configure --target=m86k-elf && make". This compiles at least, although I didn't really test the resulting binaries.

Yeahyeah, I admit the moment I wrote that I typed a bit faster than I was thinking. No need to get upset and all...calm down a bit, it's better for your heart. Again, no need to get upset. I was talking about something I might try if I was rolling my own assembler. Ffs, you are rolling your own aswell and craft it to your liking. Perhaps reading threads more carefully might be a pretty good idea for you too aswell. Well, at least you're pretty good at spelling.

Regarding the embedded code feature: I have absolutely no idea how I would handle this exactly if I was writing an assembler. The basic idea is that the embedded code somehow would have the possibility to emit assembly code again, so that you could for instance embed code that calculates a lookup table without having to write a separate script which spits out the table into another file which you in turn include into the source file you're actually going to assemble.