Jump to content

danwinslow

Members
  • Content Count

    2,870
  • Joined

  • Last visited

Posts posted by danwinslow


  1. 1 hour ago, Harry Potter said:

    You compiled it for an Atari.  I want to compile it for the Atari XL.  Also, the aux_*() functions access the XL's extra memory, so the 0 means the first byte in the extra memory.

    XL 'extra' memory? If you mean bank switched memory, do you mean an upgraded XL? As far as I know, only the XE's come stock with extended memory.


  2. Also, looking at code, it seems you are looking for a #13 as a keycode...thinking that is a CR possibly? It's not - atari uses ATASCII, not ASCII and besides you may be getting an internal keycode here and not an ATASCII CR ( which is 155). Then it looks like you try to zero terminate the buffer (although if you've fallen through due to the bne @lp not branching then Y will be a zero when you try to zero terminate the buffer). Not super great at reading assembler off the cuff nowadays but those are some possible problems I noticed.


  3. Just guessing, but problems with low memory usually mean it's been written over by something, usually DOS. How low are you loading, and what DOS are you using?

    Extended ram is usually better for overlays, but it can limit the hardware types that can be used. Under the OS is also a decent option, but a lot of programs could conflict.


  4. That routine is designed to be called from a handler, not directly from a user routine. See what I mentioned in my post above. Why is it crashing? I don't know, but you could put your emulator into debug and figure it out yourself (especially if using Altirra). Anyway, it's probably a bad idea, you should be using CIO to open the K: handler.

    It's not impossible to do things with direct calls, but it's generally not a good idea. You could also use one of the the getch() functions of conio.h or stdio.h.

     

    From mapping the atari, see the red underlined part:

     

     

    62436-65535 F3E4-FFFF KBDORG

    Routines for the display and keyboard handler. The display handler beqins at 62454 ($F3F6) and the keyboard handler begins at 63197 ($F6DD), below.

    63038 F63E EGETCH

    Like the BASIC INPUT command, EGETCH gets a line from the screen and keyboard, but only one character at a time. You must do a JSR $F63E for each character input. This is also the address of the beginning of the screen editor routines.

    63140 F6A4 EOUTCH

    This routine puts the character currently in the accumulator onto the screen in the next print location. Similar to the BASIC PUT command.

    • Like 1

  5. Please show us some code and provide context. If you are using C, why are you jumping to what you think are input routines instead of just using the C functionality?

     

    Never jump to 'the OS routine at $xxxx'. If you want to do low level IO functionality you must read about and learn to use the Atari CIO system. Everything is done through handlers on the Atari - jumping directly to OS locations is not done.

    https://www.atariarchives.org/dere/

     

     

    • Like 1

  6. The 'beeping' is probably the file access noise that is part of OS when reading data from a file, it's probably the boot disk loading.

    You access a file in CC65 the same way you do in any C environment - you use fopen, fread, fwrite, or fscanf, etc., depending on what you want to do.

    FILE *f;

    f=fopen("d1:filename.dat", "r");

    ...

    fread(buffer,len,1,f);

     

    and so forth. There are lower levels of access such as the Atari CIO mechanism and even a lower level from C, but that's how you do it in straight C. Then D1: is the 'drive' specification, D1: is teh first drive, D2: is the second, etc.


  7. 32 minutes ago, Alfred said:

    To the other guy, why bother with GitHub. All the other source code is on Carsten's wiki, which seems good enough. Why not just keep posting stuff there, and people can copy it to whatever library manager they use.

     

    Because I am talking about a larger effort, not just about the specific code you are talking about.


  8. 39 minutes ago, Mclaneinc said:

     

    Excellent Dan, I think its HUGE ask for it to be added to Altirra and as they are proto's there may be no enthusiasm to add it. Altirra has always (for me) being about an out of the retail box idea.

     

    Would it be cool, hell yes but I doubt if its ever been on Avery's busy list...

    Oh of course. Avery can hold his own- I doubt the steady pressure of my steely gaze would have any effect if he didn't want to do so on his own :) Twas just a suggestion.


  9. On 5/10/2021 at 6:56 AM, Allan said:

    I mean something that the 1400XL OS would detect as the internal 1400XL Votrax chip but have it on cartridge. Of course finding a Votrax SC-01 would be tricky. But you would have a better chance of finding a SC-01 than a 1400XL.

    Do we have the OS dumped out anywhere? Maybe @phaeron would add 1400XL as an Altirra emulation.....

    • Like 1

  10. Well, we carefully preserve, archive and organize the software products and games. Why doesn't someone start a similar github - "The Atari Source Code Preservation Project" so to speak. Then people can donate source code to it for items of mainline interest as are being discussed here. Then we don't have to remember if person x has source code y and hope they are still alive.

    • Like 5

  11. 13 minutes ago, Justin Payne said:

    I can't predict the future but I don't see this retro fervor lasting forever and I suspect this is around one of the best times to sell something like this to get the best price possible. Could the value go up? Sure, but as those who grew up with stuff like this, there is a point where they retire and interesting in having a collection might not be as important so might as well sell it while there is interest from the community.

    I think this is correct. And, that's a beautiful system.

    • Like 1

  12. When the C code is written correctly, CC65 is a very powerful platform that also allows really good integration with assembly and control over memory layout. By 'correctly' I mean 'not like a usual C program'. See ilmenit's tutorials on this site. You do get some benefits from being 1 step up from bare assembler, but as mentioned it's still going to be pretty technical. It has to be.

     

     

     

     


  13. 3 hours ago, Wrathchild said:

    By 'thread' I would more say:

    If you look at '.proc LINE' in the tgi drivers then as USE_CIO_LINE isn't typically* used they will be using the Bresenham's implementation in there.

    https://github.com/cc65/cc65/blob/master/libsrc/atari/tgi/atari_tgi_common.inc

     

    * - though has been mentioned here by @sanny

     

    Not the wiki about bresenhams. The above is what I meant, although I don't see where Sanny mentioned it. I'll take your word for it.


  14. The TGI support for CC65 isn't the greatest as I recall (although it may have been updated since I last saw it). I can't remember if there's OS support for plot and drawto, but I think not, and that probably wouldn't be the fastest either.

    I always plotted directly by writing to screen memory, and for drawto I dropped in a fast line algorithm. You can find them in asm or native C with a bit of googling or searching here.

     

    *edit*

    Actually, I think I recall that there are some graphic libraries that other people have done that you could find.


  15. 3 minutes ago, playermissile said:

    I'm doing some reverse engineering of a game that uses a 2600-style kernel with ANTIC turned off. No display list! It's freaky. Anyway, is the only way to generate graphics through using writes to GRAFP[0-3] and GRAFM? So there is no way to generate playfield graphics (like the PF[0-2] registers on the 2600) through direct writes somewhere? I don't see anything obvious in Mapping the Atari, but I've never dealt with a kernel before.

    You can always write to screen memory? If I understand your point correctly.


  16. 18 minutes ago, Kaj de Vos said:

    Anyway, I heard nobody wants a safe language on 8-bit, so it's all fine, isn't it?

    Mad Pascal is probably the closest, although if you mean 'safe' to include no pointers, then not it either. Safety usually costs some amount of either complexity, speed or memory. The 8 bit is so constrained it's usually not worth it. Java can tell you that 'no pointers' by itself does not equal safe. I come from an Ada background, a famously 'safe' language, and programmers generally hated it because of what it wouldn't let you do. It happens to still be my favorite language, but nowadays everybody uses Javascript, which I don't event consider a full language and is so bizarrely unsafe it reminds me of C, although at least C has a coherent syntax. Ah, progress.

    • Like 1
×
×
  • Create New...