Jump to content

danwinslow

Members
  • Content Count

    2,846
  • Joined

  • Last visited

Everything posted by danwinslow

  1. I think one of the crucial steps would be an exposed API and an SDK with examples, so people can write apps and drivers. That way, you don't have to write it all. Put up the OS itself on github with an API (or at least the OS binaries and an API), and then sit back and be Lord Of The Pull Requests :). Y'know, like Linus.
  2. That's kind of what conio.h does already. I don't think you are way offbase with your typed prints printu, printc, etc., as a smaller printf replacement, but they should be thin wrappers on top of the basic CIO calls that support outputting things to screen. So I wouldn't call it entirely unnecessary, but I wouldn't call it really valuable either.
  3. Harry - you're missing a point of the OS architecture of the Atari. If you want to be compatible, use the OS-supplied CIO handlers rather than directly calling OS routines when you get ready to actually do the IO itself.
  4. JSON is data transport, not language, and I like it too. I didn't mean to say you couldn't be productive in javascript, I said it's not a 'real' language, by which I mean complete. It's great for small glue and so forth and whipping stuff up, but try doing a large, complex development project with multiple programmers in it and you'll see what I mean. The build chains for large javascript projects are packed full of linters and ECMA script rule enforcers for a reason, and any schmoe who feels like it can break an interface contract by randomly adding items, the language does not care and will never tell you until you get a runtime failure. The type conversion issues are numerous and bizarre, and any language that actually needs a '===' operator is broken. You CAN do lots of things in it, but its more painful and dangerous than it needs to be. It does not do what an actual language should do -- be consistent, enforce contracts, provide actual threading constructs, and many other things. All my opinion, of course, but that's what I think. *edit* and thus the push for Typescript. It goes a long way, but still kind of lipstick on a pig. There's tons of libraries you can get that add utilities and add structure to javascript but that's kind of my point - the language itself is just not well designed and not complete. All the linters and structure/feature addition libraries are there because the language itself. Of course you can do stuff with it, but looked at as a formal computer language it's lacking. *last edit* sorry for the opinionated rant, and I'll stop derailing now.
  5. I assume you meant Javascript there. No relation between the two, completely different things. I hate them both, but at least Java is an actual language. I'm trying to decipher the 'vscode language server' stuff now and yeah docs are kind of mediocre at best.
  6. OK, I just bought one too. I will experiment with it, hopefully I can support both it and a software E:/S: driver.
  7. I am planning on messing around with my fujinet some, and there's a mostly text-based game I wrote that I'd like to try and hook the Atari up to. My question is, what are my options for software 80 columns? (Note - this is not something that ICE-T can handle, it's not TELNET either). I am going to write a custom client, and I'd like to know what my options are for software 80 columns and whether it would be able to keep up with a lot of text, say a screenful of 80 column text every few seconds. Thanks.
  8. Well, what's the issue then? Start with googling for contractor companies on the B2 program in the right time frame, google his name and some of the companies, contact the HR departments of the companies, etc. There's no other way that I know of, unless you want to pay a PI. *edit* For instance, googling '"phillip price" cybersecurity' produces some interesting hits.
  9. You mean without a name? good luck. If you have a name, then use the usual methods.
  10. BLASPHEMER! Buuuuuuuuuuuurn! I have to admit, I have a bunch of old sinclair zx-80/81 stuff lying around. Never had a commodore, though.
  11. The "high speed" part...do you mean speed of execution or speed of coding? If you mean speed of execution, then an assembler toolchain. Assuming you mean speed of coding, then a C or Pascal toolchain; you can write quickly to set up and test your code, and then go back and optimize parts you need by dropping in assembler where needed. I'd recommend either CC65 or Mad Pascal. If you are writing anything that will need most of the resources of the machine, you might as well bite the bullet and use assembler.
  12. Now THIS is pretty cool. Nice. I'll have to finally set up my Fuji.
  13. Ok, fine...why are are you designing an assembler-level output so different from anything else? It appears to have REBOL-like control structures in it. This is what confused me. You further state that 'this is a huge advantage'. Why is it a huge advantage? And after having read through the referenced post to figure out what you're citing, I assume you mean this is the 'output listing' from compiling this: unsafe!!! constant reference volatile byte! [ ; OS RTCLOK3= ~14 ; ANTIC COLPF2= ~D018 WSYNC= ~D40A VCOUNT ; ~D40B ] forever [COLPF2: WSYNC: overflow VCOUNT + RTCLOK3 << 1]
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. Makes total sense but never heard that before. You are encyclopedic, Phaeron.
  20. Awesome Necrobump! I've never played it either, thanks for bringing it up.
  21. #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!
×
×
  • Create New...