Jump to content

fox

Members
  • Content Count

    266
  • Joined

  • Last visited

Posts posted by fox


  1. The fact is emulator has different colors than real machine. On emulator is color descibed with RGB components (from table) while real Atari has CHROMA/LUMA signals. I think it is very big difference between these color spaces so it is not possible to make emulator with the same colors as original.

     

    TV displays colors in RGB, naturally.

     

    The problem is that colors differ between:

    • PAL/NTSC
    • Atari models and even units
    • hue adjustment in Atari
    • TV models
    • monitors (especially CRT/LCD),
    • brightness/contrast/saturation settings


  2. Probably "most of the time" rather than "at all".

    Could you give some examples, please?

     

    One example would be "Muad Dib Demo" which is crypted using

    XL/XE OS contents - it needs the original ("old" version) OS to run.

     

    I'm sure there are many programs which use unofficial addresses

    in OS, not only for routines, but also lookup tables

    (e.g. $80,$40,$20,$10,$08,$04,$02,$01).

     

    Another class of programs is these which copy the original ROM

    contents to RAM and then patch it.

     

    I also doubt if Atari++'s OS emulation is 100% compatible

    with the original OS (including details like C flag set when returning

    from SIO - some programs really rely on this).


  3. I've heard of APAC (all points all colors, mixture of 16-hue and 16-luminance modes), but what is HIP/TIP mode?

    954674[/snapback]

    Where have you been for the last ten years? ;-)

     

    Basically, HIP is 160x239x30 shades and TIP is 160x119x256 colors.

     

    A few years ago I have posted English description of TIP to Heaven

    and Raster. Heaven, do you have it somewhere?


  4. Thomas then replied that he wrote every piece of code for the Atari++ emulator from scratch.

     

    Maybe 95%, but surely not 100%. There were same typos in "his" code

    as in Atari800, would you believe he hasn't copied it?

     

    Anyway, the war between Atari800 team and Thomas is now history

    and I wish Atari++ well.

     

    Noteworthy: Thomas also implemented an OS-emulation, i.e., there is no need to use copy protected Atari-ROMs any longer.

     

    Probably "most of the time" rather than "at all".

     

    Atari800 has "emuos" that is enough for running some games.


  5. I tried an ATR of SSI's "The Cosmic Balance" with the latest version of Atari800win. Seems to boot and load DOS but the screen blanks and nothing happens. I played with all the settings, but no luck.

    The game enables a POKEY timer interrupt at a very high frequency.

    The emulation of POKEY timer interrupts is inaccurate in Atari800 (Win).

    A workaround is: press F8 and type:

    c 10 40
    cont

    What surprised me was... MESS had no trouble with it! I don't know who coded the a800 driver, but it's fairly primitive compared to Atari800win.

    I guess MESS doesn't emulate POKEY timer interrupts at all.


  6. In your atari800 win+ (final) are you going to have a secondary rom option for alternative drive roms (like happy, lazer etc etc)

    Atari800 does not emulate drive's CPU or ROM.

    Also will it be possible to get the black box roms and also o/s controller card to work with your emu (they're featured on the atari.art.pl (not bad ftp w/s)

    914432[/snapback]

    What are these?


  7. The comment is misleading, the problems are because the special values are not negative: (input_win.h)

    ...

    I think they should be changed to some negative values.

    I agree the comment is misleading - especially as a group of bits are used to indicate a special value.

    In terms of a 16 bit integer, they are negative as the high bit is set.

    But these aren't 16-bit integers.

    And I don't see a reason for AKEY_HELP to be ORed with SPECIAL_HANDLER_MASK. So the above code from input_win.c should be completely removed.

    IIRC, this does make sense as on the XL the help key also produces a '?' keypress.

    No. Help has its own keycode.

    The 3 cases are required as you cannot mask out the 'AKEY_HELP' pattern within the switch.

    I meant SPECIAL_HANDLER_MASK shouldn't be set for AKEY_HELP.


  8. YES... i want "numbers changing"...

     

    Live preview of $d20a would be entertaining, right? ;-)

     

    :D... Fox...remember when we coded our GBA stuff years ago...havent you used a nice GBA emulator with all this features i want to have? or No$GBA?

     

    IIRC, I used VisualBoyAdvance. But it had GUI-based monitor too, I think.

     

    Monitors are for coders/hackers, so command-line driven interface is good. It's faster for me to type "d 8000" than to precisely drag scrollbar of disassembly window.

    And on Win 2k/XP the console window has history, so you can see the output of previous commands. Can you do that with GUI?

     

    I personally hate that I can't change fonts in GUI-based monitors. This is easy for console windows. And Alt+Enter rules. And you can copy/paste from the console window.


  9.   /* There are some key values below zero, handle them here */
     if( _IsFlagSet( g_Input.Key.nNewKey, SPECIAL_HANDLER_MASK ) )
     {
     	switch( g_Input.Key.nNewKey )
     	{
       case (AKEY_HELP | SPECIAL_HANDLER_MASK):
       case (AKEY_HELP | AKEY_CTRL | SPECIAL_HANDLER_MASK):
       case (AKEY_HELP | AKEY_SHFT | SPECIAL_HANDLER_MASK):
       	if( MACHINE_XLXE == machine_type )
         g_Input.Key.nNewKey &= ~SPECIAL_HANDLER_MASK;
       	else g_Input.Key.nNewKey = AKEY_NONE;
       	break;
       default:
       	g_Input.Key.nNewKey = AKEY_NONE;
     	}
     }

     

    The comment is misleading, the problems are because the special values are not negative: (input_win.h)

     

    #define SPECIAL_HANDLER_MASK  0xf000	/* codes in atari.h file */
    #define AKEY_OPTIONDWN    0xffe1
    #define AKEY_SELECTDWN    0xffe2
    #define AKEY_STARTDWN    0xffe3
    #define AKEY_OPTIONUP    0xffe7
    #define AKEY_SELECTUP    0xffe8
    #define AKEY_STARTUP    0xffe9
    #define AKEY_MONITOR    0xffea
    

     

    I think they should be changed to some negative values.

    And I don't see a reason for AKEY_HELP to be ORed with SPECIAL_HANDLER_MASK. So the above code from input_win.c should be completely removed.


  10. Fox, are you helping Jaskier in terms of development the emulator?

    Actually I'm working on Atari800 (for about 5 years or so).

    - register window

    show

    - window with the actual disassembling which is going to be updated while running (in debug mode)

    d addr

    - VRAM visible (player/missles/fonts/DLI indicators)

    But you see them, don't you?

    - custom chip register visible (antic/gtia/pokey/porta/portb)

    antic/gtia/pokey/pia

    - display list

    dlist

    all of course dynamic and updated in runtime...that would be really cool... i personally like the new debug features but i hate that the debug window stops the mulation so no realtime changes possible... (a monitor should "monitor" ;))

    uh-oh. You just want lots of numbers changing at high speed, that you can't read at all?

    this is my wishlist and not to forget: real pokey emulation as accurate as possible

    it's already quite good, I think

    and real PAL/NTSC support like on Wice.

    What?


  11. Maybe except for ASCII 0-31, 128-255 and the comma (which is commonly used to separate the two filenames for the rename command).

    Right, I forgot about the comma...

     

    And also '?' and '*'.

     

    Who said it can't be? I'll think about it. I'll probably reuse "Load executable". BASIC files can be easily identified (they start with two zeros).

    Thinking of something else... Call me crazy but do you believe we could have this for programs written in other languages?

     

    No.

     

    Anyway, using the tape recorder option is absolutely PERFECT for what we want to do. Thanks again for suggesting that :) 

     

     

    Well, it's good but not PERFECT. I'm going to implement direct BASIC loading anyway.


  12. That would be a great compromise if a true BASIC loader can't be implemented.

     

    Who said it can't be? I'll think about it. I'll probably reuse "Load executable". BASIC files can be easily identified (they start with two zeros).

     

    Actually, everything Windows allows ;)

     

    Maybe except for ASCII 0-31, 128-255 and the comma (which is commonly used to separate the two filenames for the rename command).


  13. Where's the 8-character limit?

    For example, only RUN"H:PACMAN is valid, not RUN"H:PAC-MAN, RUN"H:PAC MAN or RUN"H:PAC-MAN - FOX

     

    This isn't an 8-character limit. It is that H: emulation accepts only some characters in filenames. This is to make it compatible with Atari software. You can't use spaces in filenames on Atari - space denotes end of filename. As for the hyphen, it should be probably allowed. I'll fix that.

     

    Maybe spaces should be also allowed, I'll have to check if Atari DOSes use space as a delimiter, especially for the rename command. If not, H: will work with spaces, too.

×
×
  • Create New...