Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by danwinslow

  1. 36 minutes ago, Harry Potter said:

    The purpose of my SimpleIO libraries is to provide as little extra processing of data as possible.  It is meant as a more optimal version of printf() and other console I/O functions.  The CBM version comes with binaries to test the included functions which are worth <1k per version.  If it's not possible on the Atari 8 versions, just tell me, and I will stop working on it for now.

    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.

  2. 3 hours ago, Irgendwer said:

    I'm willing to see JavaScript in better light. Especially JSON, while Douglas Crockford was quite productive on our machine:


    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.



    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.


    • Like 1

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

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



    For instance, googling '"phillip price" cybersecurity' produces some interesting hits.

  5. On 8/14/2021 at 3:47 PM, eobet said:

    You can't edit old posts on this site?


    So, turns out the company is not CFO Plus, but rather Code 10 Digital... which seems associated with Retro Games Ltd... who in turn made the C64 mini console and will release A500 mini console soon.


    Does anyone on this site happen to know how to track down someone who previously worked on the stealth bomber and currently works in cyber security? (Yes, I'm serious, btw.)

    You mean without a name? good luck.

    If you have a name, then use the usual methods. 

  6. 19 hours ago, ldelsarte said:

    I am a very loyal Atari 8-bit fan with cubic meters of hardware, kits, boxes and software. However, out of curiosity, I also have a TI99/4A, Apple IIe (& platinum), CBS ColecoVision (& all the add-ons), very old MS-DOS laptops, and ... since very recently, I got cheaply 2x C64, 1x C128, a 1541 drive. I bought a Kung Fu Flash cartridge (very handy)

    I know the Atari 8-bit games very well, I've been playing with my 800XL since I was 13, in 1984. And I still play today thanks to my FujiNet to Boulder Dash, Montezuma's revenge, The Goonies, Burger Time, Mr TNT, Drop zone, Bruce Lee, Galaxian, The Great American Cross-Country Road Race, etc, etc. But the C64 is brand new to me. I don't know where to start the exploration.
    I'm just looking for some advice: if you are familiar with Atari 8-bit and C64 games, which C64 games do I really need to play?
    Good C64 games that don't exist on the Atari 8-bit...

    Good C64 games that are really better made than their Atari 8-bit counterpart... (the opposite also exists, I know some)...

    Do you have any suggestions for me?

    After this escapade, I promise, the Commodore hardware will be back in the basement. ;-)

    BLASPHEMER! Buuuuuuuuuuuurn!


    I have to admit, I have a bunch of old sinclair zx-80/81 stuff lying around. Never had a commodore, though.

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

  8. 13 minutes ago, Kaj de Vos said:

    No, that is the improved version of the assembler listing, similar to CC65's listings. The source code is in this thread, and I posted a link to it in the announcement:





    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]



  9. On 6/1/2021 at 8:57 AM, Yautja said:

    Cool! Is this the very first original game written to take advantage of FujiNet?


    And, could it also be played using, say, DragonCart or else?


    - Y -

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

    • Like 2
    • Thanks 1

  10. 3 hours ago, tschak909 said:

    My bombast is out of decades of frustration, seeing the same idiotic talking points circled back to, again and again, with absolutely nothing resolved, BECAUSE THOSE WHO COULD RESOLVE IT CHOOSE TO PASSIVELY AGGRESSIVELY CHOOSE NOT TO, or fall back on the flimsiest of cop-outs, such as copyright to someone who literally has been missing in action for decades at this point. There comes a point where I finally have to call bullshit.




    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.

    • Like 3

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



    • Like 4

  12. #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!

  13. 3 hours ago, Harry Potter said:

    Okay.   Thank you for the information.  :)  I got it to almost compile.  I included both atari.lib and atarixl.lib.  Now, I only get __RESERVED_MEMORY__ and __SYSCHK_LOAD__ undefined.   I attached the new .cfg file.   How do I define these?

    atarixl_memx01.cfg 4.6 kB · 5 downloads

    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.

  • Create New...