Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Tom

Members
 View Profile  See their activity

  • Content Count

    446

  • Joined

  • Last visited

Posts posted by Tom

  5. Posted · Edited by Tom

    I've hacked together a small change to Console.cpp which writes the configuration file to ~/.prosystemrc on UNIX and OS X -- it's still hardcoded, but at least it goes somewhere useful.

     

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

  7. Posted

    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?

  8. Posted · Edited by Tom

    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.

  9. Posted

    I like the ProSystem because it's Windows based, but I wish he would update it and add joystick control.

     

    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.

  11. Posted

    Interesting. What computer hardware are you using, and what kind of performance do you get? I would think that a 7800 game, running inside a 7800 emulator, running on top of .NET, running on top of WINE, running on top of Linux, would be much too slow to play without some serious horsepower.

     

    I probably would have run the *nix version of MESS, but it's good to know there's another option.

     

    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.

  13. Posted

    However, I wanted to center the text area on the screen, and based on my preliminary attempts, I don't think that's doable; it looks like the only way to do it is to have the text area on the left side of the screen (as in DM and ST).

     

    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.

  14. Posted · Edited by Tom

    I had built dasm 2.20.07 myself under linux, and it was that version that was giving the errors. It must be something about the way it is compiled that is causing the difference. I recall something about dasm using 32 bit integers or something like that which interperates #-1 differently.

     

    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.

  17. Posted

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

  19. Posted

    Actually, I'm being a bad programmer in the example above, as it's kind of messy... This is better than my other example:

     

    #define RGB(a, b, c) ((a)<<16)|((b)<<8)|( c)

     

    Then you can do RGB(184,67,112) and it will be translated into a constant, making it both efficient and easy to read in the source.

     

    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)<<8)|( c))

  20. Posted

    Okay, question for you guys, once I've downloaded CC65 (cc65-atari-2.11.0-1). How am I supposed to run it ?

     

    I've opened all the folders but I can't find anything that remotely looks like an application.

     

    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.

  22. Posted

    EDIT: I've been trying forever to get binutils to compile for m68k and it just doesn't want to happen.

     

     

    I think the problem was that he didn't want to deal with the gas syntax. And I don't blame him. It was created for the purpose of making a portable C compiler, not for being true to the chip maker's assembler syntax.

     

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

  23. Posted · Edited by Tom

    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.

  24. Posted · Edited by Tom

    Um, hello? Did you check the name of this subforum? Jaguar programming. That's pretty far away from the "Atari 2600 community". It's only got five letters in common, and two of them are "A".

    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.

     

    That's what macros are for. They just happen to use a syntax more appropriate for the job than Perl. If you really want Perl or some other langugage to generate assembly code, run it first, then include or link with the output.

     

    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. :roll:

  25. Posted

    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.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...