danwinslow

I may be wrong, but I believe that is better considered as embedded assembler inside control structures from his 'new language'. I think he is trying to write a high-level language rather than an actual assembler. I agree from that source that this isn't clear, I am going on posts he has written.

Typically this is achievable if the devices in question use (or at least respond to) the E: and S: handlers in a standard way. If they do not, then it becomes much more difficult.

Love this. Will buy.

There are no completed CIO drivers for the DC that I know of. I posted a start that handled UDP and did things similar to the FujiNet, such as OPEN "I:UDP:192.168.0.1:44044" and so forth, but no one really continued it and I ran into real-life issues that took up all my time. The main difference between DC and Fujinet is that DC uses an on-cart cypress chip and direct memory transfer, whereas FujiNet uses an intelligent co-processor board with it's own TCP stack communicating across SIO. I had started off with a similar attempt, but I found the line delay of SIO to be too limiting for fast action games using UDP, which was really my target. DC has some support from a different OS...I forget the name right now but it's a linux-y multitasking OS that has a TCP stack that works with DC. Altirra has DC support, but just the hardware, not the driver stack. Anyway, FujiNet is a great piece of work, especially for TCP and anything that doesn't need really fast response. DC can theoretically outperform it but it's a moot question at this point, FujiNet is the way to go. If anyone feels like working on the DC drivers I had, just let me know and I'll send them to you. It's all in CA65 and supports extended memory for buffers, but as i said, UDP only. There's a TCP start but that's when I got sidetracked. So thats a lot of words to say : No. Looks like a great game, by the way! Nice.

You know, if one or two persons disagrees with you, it might be them. If many consistently disagree with you over the years, maybe you need to consider that there's a real thing there rather than that everybody but you is an idiot. I do all my projections consciously, by the way.

I would also prefer the source (for SDX) not be open. There would be many forks and competing upgrades and variances...we have enough trouble with the swarm of DOS's we have now. The only way it would work semi-decently would be for someone to publish an actual standard, and we know that's not going to happen, or be paid attention to if it did. I agree with Mazzspeed.

Makes total sense but never heard that before. You are encyclopedic, Phaeron.

Awesome Necrobump! I've never played it either, thanks for bringing it up.

#Extra memory MEMXM: file = "memx", define=yes, start=0, size=$ffff; } This is what Sanny was talking about. You are defining a flat 64K here of 'extra' memory. I don't know where you got that .cfg file, it has all kinds of extra stuff in it that don't seem related to your stated objective, but ok. As mentioned above, I'd say try starting with the CC65 native crt0.s and the standard atari.cfg file, then adding your segments into that. Seems like you got some kind of mismatch going on. Good luck!

You can define them in the same way you do any segment, but I think those should be already taken care of for you if you are using the standard ( as in, not your own) crt0.s and you have used the correct .cfg file as a starting point for defining your own. You don't need to link in atari.lib or atarixl.lib at all, just use the correct -t argument, but linking them both in is definitely not correct. I wrote something very similar to what you are doing about 5 years ago, and I basically used everything stock from cc65, meaning -t atari and did not mess with the crt0.s. I defined 4 16k bank segments and a lowmem bank with page control, memory page copies, and address abstraction, just as you are probably doing. I'd say try starting with the CC65 native crt0.s and the standard atari.cfg file, then adding your segments into that. Seems like you got some kind of mismatch going on.

It could be LOTS of things. Provide as much info as you can, including what's asked above and what kind of monitor/T.V. you are hooking up to.

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.

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.

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.

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.

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/

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.

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

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.

Maybe we do....

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

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.

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

It would be unusual to not be able to use GCC. What OS are you on? If you are on windows, you should be able to use MinGW: http://mingw-w64.org/doku.php

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.