Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by jum

  1. Thanks Karri. Some nice information there.


    What I really want is a replacement for TGI, that includes what TGI does not have (eg: audio, custom text, other draw routines which I have had to implement).


    ie: A more complete, integrated Lynx CC65 game lib.


    Probably the biggest problem would still be framgented and old documentation on this forum and spread out tools and tool-versions. A beginner would have to do a lot of research before having a viable workflow set up.




    A "single download" of a "Lynx Game Dev" .zip with CC65 and libs and proper documentation and samples would go a long way to making it easier to get into Lynx game dev.


    Edit: Preferably in github so people can contribute easier.

  2. Could you give some kind of examples what kind of functions a mid-level video/audio library would comprise of? I'm not so well versed in these things but I'm very curious of what kind of improvements would make sense.


    I've been happy lately because compared to 10 years ago there's a lot of things that are easier now thanks to Karri, Sage, LX.net, Ninjabba, TailChao and others sharing their stuff (Sage's chipper tracker for music, Karri's cart-segments, LX tutorials and Karri's template that incorporates everything needed for a game etc.), but I agree that it's probably not exactly super easy to start out with Lynx programming yet either! There's a lot of work connecting the dots and have all the tools and resources put together in a working work-flow.


    It could be interesting to get aboard more mid- to high- level coders that struggle with the low-level stuff, but that still would be able to create nice games with a bit easier 'game-framework-programming'. Sometimes I dream of being able to really just jump straight in creating a game for the Lynx like in some super simple but genius IDE like in pico-8.


    Would still be more interested in trying to make more games myself instead of the tools (backward approach i guess), but in my mind there seems to be a distinction between personalities who actually seem to be more interested in creating the actual tools and personalities who are more intrerested in creating the games, not exclusively, but at least a tendency. (I might be completely wrong). Or maybe it's just a matter of different approaches, the build all tools properly from the ground up before starting coding a game-guys and the 'hack' whatever we have in the simplest way possible to create a game-guys?


    These are my thoughts exactly. The goal we are all looking for is "How do we make it easier to make games/apps for the Lynx?".


    Some options are:

    - "Lynx BASIC" (a playform like Batari Basic or Calamari's 5200Basic)

    - "Lynx IDE" - an "all in one" IDE like the Pico8 style (sprite editor, sound/music editor, code editor, emulator, serial uploader) - this is just a dream.

    - Existing tools, but make them more integrated.


    As you say, a lot of new tools have been written in the last few yeas by Karri, Sage, LX.net, Ninjabba, TailChao and others. Their efforts are much appreciated. But the working dev environment and workflow are still pretty clunky, and not conducive to a creative process.


    I'm a "hack whatever we have in the simplest way possible to create a game" type of guy.


    So a Lynx new CC65 C library would have:

    - Video functions

    - Init video (set up buffers and collision buffer)

    - Sprite start (Suzy go)

    - Sprite draw busy?

    - Draw line, circle, arc, rectangle

    - Draw text

    - Check collisions

    - SwapBuffers (with or without vsync)


    - Audio functions

    - Init audio

    - Reset audio

    - Start sound on channel n with frequency f

    - Play MIDI note number

    - Predefined "instruments" (with shift bits, feedback bits and vol/pitch envelope)


    - Other

    - Load data from cartridge ROM

    - Write/read to EEPROM

    - Serial functions


    ...and other functions which are sure to exist in the BLL / ASM libraries but not in any C lib as far as I know.


    Purpose is to abstract out the low-level complexity (where possible). Also to have smallest overhead.


    Maybe also add things like a "simple sprite engine" which could manage an array of sprites in a more user-friendly way.

  3. I have recently been working on turning my old Lynx "Befok/Berzerk" demo ( http://jum.pdroms.de/lynx/lynxprog.html) into a complete game.


    It's taking longer than I thought, with detours into adapting an HTML sprite editor ("Tiny Sprite Editor") to use Lynx palette and output sprite data as C code, and a detour into relearning how Lynx audio works.


    Also had to convert/update the old CC65 code to use the new CC65 compiler (which is way better, thanks Karri). Working with the old code was probably a mistake - it would have taken me less time just to rewrite it from scratch.


    Also it's pretty grim for new people trying to get into Lynx programming. We need a proper mid-level Lynx C video/audio library. TGI is not the answer.


    Anyway, here is the alpha version of "Berzerkoids". It works on a real Lynx, but seems to crash every now and then. Does not crash on Handy. Recommend using Handy 0.98b.





    There are some audio issues and the bullets are not visible enough.


    Please give feedback.


    Edit: latest version of Berzerkoids is here: http://atariage.com/forums/topic/277916-berzerkoids-alpha/page-2?do=findComment&comment=4268115

    • Like 4

  4. Looks pretty cool but I haven't figure out how to modify the palette yet... or is it even possible? (having black for pen 0 is not optimal since pen 0 is also the transparent color).

    You can modify the palette in the HTML source code, or add your own palette. You can change pen 0 to pink if you prefer.


    Probably would be nice to be able to import a Lynx palette, either from C file data or from .gpl palette file. Let me know what format(s) would be most useful.


    Also have added to github as a fork of the original: https://github.com/james7780/tinyspriteeditor

  5. I have modified the online "Tiny Sprite Editor" ( http://tmtg.net/tinyspriteeditor/) made by Boris van Schooten, so that you can use it to create sprites for Atari Lynx.


    Double-click the .html file in the attached zip to run it.


    Currently you can export the sprite data as C code or ASM code (literal sprites only for now, can add RLE compressed sprites later).



    1. Run the .html file in Chrome (may work in other browsers too).

    2. Set the "Palette" drop down to "Atari Lynx" BEFORE you draw anything.

    3. Draw a pretty picture (background must be pen 0 (black))

    4. In the "Text Format" dropdown, select "Lynx C code (literal)"

    5. Click the "Export" button.

    6. The C code will appear in the textbox at the bottom of the page.


    Note: you cannot import C code at this stage. If you want to "Save" your sprites to work on later, then export as "Data URL".


    Let me know how it works for you. I am sure many improvements can be made.


    The main purpose is to make it easier to create Lynx sprites for your projects, without having to hassle with Gimp and PCX and sprpck/sp65 and bin2c...


    Have fun!


    Also have added to github as a fork of the original: https://github.com/j...inyspriteeditor


    • Like 1

  6. Comparison of the 2 screen clear methods, using Handy and using a real Lynx (note: real Lynx seems to be faster than Handy).


    Lynx clear screen method comparison

    Note: I think the frame rate is set to 75fps. If so I will do another comparision with 60 fps version.
    Edit: No difference when frame rate is changed to 60 using tgi_setframerate(60). Possibly tgi_setframerate() is broken?

  7. While I was writing "Always winter, never Christmas" I found out that at least Mednafen is so much faster than a real Lynx. So I would prefer to get these test results from a real Lynx if possible.


    The result sounds reasonable. The collision buffer is probably a great idea when dealing with random areas. But when you have a large, full-screen rectangle then drawing the whole area twice is faster than trying to draw into two buffers at once.


    I will test on real Lynx (using SD card adapter) and get some screenshots.

  8. So a quick test:


    1. Draw "clear" sprite to clear draw buffer and collision buffer, followed by a "playfield" sprite with collision enabled (1 call to Suzy) :



    2. Draw playfield sprite directly to collision buffer, then draw it to the draw buffer (2 calls to Suzy):



    The green area shows how many hcounts it took to draw. If you can believe Handy, then method 2 is way faster.


    (If you don't want to download/look at the images, then method 1 takes almost a whole frame, and method 2 takes about 60% of a frame = 60 hcounts).


    Results can be predicted from:

    Method 1:

    - Draw clear sprite = 75% of "normal" sprite draw time (NSDT), as it does not have to read pixels (write only)

    - Draw playfield sprite = 100% of NSDT

    - Total = 175% of NDST


    Method 2:

    - Draw background non-collideable sprite to collision buffer = 66% of NDST

    - Draw background non-collideable sprite to draw buffer = 66% of NDST

    - Total = 134% of NDST


    So you would expect method 2 to be about 30% faster, even before implementing it.


    (Also, why does it take almost a whole frame just to clear the draw buffer and collision buffer?)

  9. Thanks Karri and Sage.


    Karri - drawing sprite to the collision buffer directly is an interesting idea. Problem is that it does not save me any sprite draws, I still need to draw to the display buffer too. (Edit: actually I might try this, as it should be faster than a sprite writing to display buffer and collision buffer). Is there any source code out there that does this?


    Sage - true, however what I want is to write 0 to collision buffer for transparent pixels, and 1 to the collision buffer for opaque pixels. (ie: "clear" the collision buffer where no playfield is, and write 1 to collision buffer where there is playfield)


    My current collision code is correct and work properly, I was just wondering if there was a faster way to do it.

  10. Quick question for advanced Lynx programmers - is it possible to clear the collision buffer AND write non-zero collision numbers to it using just one "background" sprite?


    At the moment I am drawing a 1-pixel background sprite with collision number 0, stretched to fill the screen. This clears the screen buffer AND the collision buffer.

    Then I am drawing my "playfield" sprite, which has collision number 1.


    Is there some trick where I can just draw my playfield sprite, and the transparent pixels write collision number 0, while the opaque pixels write collision number 1?


    Or am I dreaming?

  11. Hi, I have just done this mod on my PAL 7800 (rev C), using the video amp circuit from phoenixdownita ( http://atariage.com/forums/topic/127926-easier-7800-composite-video-mod/?p=2813736 ) and followed this guide for the rest: https://www.thefuturewas8bit.com/index.php/7800_comp_mod

    I had to reduce the resistor on the video output to 20 ohm (else my CRT wouldn't pick up the colour, and my capture card wouldn't pick up anything).

    Re-used the modulator's RCA connection for video, put the video amp circuit inside the modulator box.

    Video quality seems OK, slight ghosting, but much better than RF quality.

    Also put a 2200 ohm resistor on the audio output, but it's still very loud, maybe 4700 ohm would be better.

  12. I'm glad you posted that pic. The first one up above showing where VR1 is. The silkscreen is wrong. I and O labels are backwards which has been throwing the whole troubleshooting off. The short must be on the output side if you were checking it by the "I" label on the board. Looking at the front of the regulator from left to right is Input, Ground, Output in that order. The silkscreen labeling is backwards due to an error apparently. Also you can confirm what I'm saying by the schematic where C43 is across the Input and Ground of VR1, just as in the picture, they just have it labeled wrong on the board.

    Thanks for verifying that the "O" and "I" labels for VR1 and VR2 on the silkscreen are backwards (5200 2-port). I've been trying to figure if had I put the VR's in backwards, suspected that the silkscreen might be wrong...

  13. - Try to use AV output (not RF) , maybe the RF modulator is faulty (you can hotwire into the 5-pin monitor jack to get AV (composite) output)

    - Input voltage should be between 4.9 and 5.1 V when testing (just to rule out a voltage problem)

    - Do you get the disk loading sound thru the TV/monitor when you switch the 800XL on?


    I found I needed at least a logic probe to fix the problem I had with my 800XL (faulty PIA), and the Field Service Manual and Sam's manual came in useful too.


    Good luck with your fix.

  14. IMHO: It would be less strenuous to just have a status file on the SD card to remember the last .ATR used. Still it would need the ability to reset to a safe image just in case of course. It would be nice to chain configuration on the Atari too. Something like the Arduino feeds an ATR that disables BASIC and on completion of the first program switches to an ATR that needs BASIC disabled.

    After I had implemented the EEPROM write code, it did occur to me that I could also just write a "status" file on the SD card to do the same thing :) (will probably change to use SD card status file).

    In any case my first attempt at saving the "current" ATR name in the EEPROM was only partially successful (only worked if the ATR was in the root folder, since no directory path was being saved).

    I also added a "reset boot image" switch (using INPUT_PULLUP to avoid using an external resistor), which also kind of worked.

    Disabling BASIC does not seem to be a problem when booting an image from SDRIVE (for me at least (600XL)).

    However the majority of ATR / XEX I try do not seem to load properly (although the ones that do load, always load consistently). Not sure if I need to change bootloader address or something.

  15. More feedback:

    Lately I have built another SIO2Arduino using an Arduino Nano and MicroSD card breakout.

    No code changes were required.

    This version is powered by +5V SIO pin (pin 10), seems to work fine (mostly?). (Current draw is less than 20mA according to my USB inline power monitor).

    However when you switch the Atari off and on to "hard reset" the computer, the Nano is also rebooted, and forgets which disk image is inserted (defaults back to SDRIVE disk).

    I am thinking about overcoming this issue by using the Nanos 1kB EEPROM to store the currently selected ATR(s), and adding the SIO2Arduino "reset" pushbutton to tell the Nano to switch back to the default SDRIVE ATR.



    Well today I finally managed to fix the 800XL :) :-D :) :-D :)


    After lots more probing and investigating and swapping out chips with my 600XL, I noticed with my cheap logic analyser that the correct reset vector ($C2AA?) was not being loaded on reset, meaning OS ROM was not being enabled on reset, which lead me to discover that the 6520 PIA was not pulling the REN line on the MMU high (like ti should be doing). So I swapped out the PIA with the PIA from my 600XL and happy day there was the "READY" text on the screen!


    (Never thought to swap the PIA before as I have never seen it mentioned as a common failure).


    Thanks for all the help and cheers! I'm going to have a beer now...

    • Like 3

  17. I have built 2 SIO2Arduinos lately, just wanted to give some feedback:


    1st try was using an Arduino Leonardo with an ethernet shield. Reason for using a Leonardo was so that I could use the debugging output. Initially had a problem with the SDFat library and the Arduino IDE versions not playing nicely, this was fixed by using an older sdfat lib which is mentioned int he github issues section somewhere. Had to make some small changes to the source code to get it working on Leonardo. This version worked, but was quite flaky, less so after I realised that most software won't run on my 16k 600XL (PAL), and I modded it thereafter to 64k.


    2nd try was using an Arduino Uno R3 and a "data logger" shield, also with the older sdfat lib. This works great using SDRIVE as a UI for selecting boot images. No buttons or LCD display for now (I just reset the Arduino if I want to get back to SDRIVE image).


    I have noticed that while most of the software (ATR) that I have tested runs fine, a lot of disk images do not run, or crash. Not sure if due to needing more than 64k, or disk protection, or NTSC/PAL issues, or my flaky SIO wiring, or something the SIO2Arduino doesn't support.


    For me, making the SIO2Arduino was the quickest/easiest way of getting a disk drive for my 600XL. But the SIO2SD (lotharek) looks pretty good, I'm very tempted to buy one.







  18. Very interested in this project!


    Will 5200Bas be able to compile for the 8-bit computers also?


    It should be possible to allow for building an 8K image to go in "Cartridge A" memory slot (0xA000 to 0xBFFF). Would require use of alternative memory map. I will do some investigation.

    • Like 1

  19. Does this program work with Atari 5200 roms also ?. I want to convert some Atari 5200 roms to Car format. Is there som other tool for this also ?


    I just found out it can be used with 5200 roms. So nevermind the question.. Great Tool .. Thanks :)

    Why exactly do you want the roms in CAR format?


    It's a very bad idea to "spoil" Atari 5200 roms by adding headers and other crap.

    - Many 5200 emulators expect unmodified rom/bin files of exactly 16k or 32k..

    - If you want to write the rom to a flashcart or an EPROM, it expects 16k or 32k exactly.

    - If can't think of why you need a header on an A5200 rom. If you want extra "metadata" attached to a rom, use a database that links to the rom via its crc.


    I'm sure other people will have their own opinions, but they are wrong.

  20. OK so I think the 5200BAS python conversion is at a state where it's basically useable, so if you want to grab it and mess around:




    (You will need Python 3 installed on your PC).


    Non-exhaustive list of changes/updates (v1.97 conversion):

    1. Straight conversion from QBX code to Python code
    2. Combined includel.bas into the main python script
    3. Modifications to strings and arrays to better suit Python lists and dictionaries
    4. Descriptive variable names
    5. Try reduce global variables and scope everything better
    6. Most error messages updated to provide more specific info (user-friendliness)
    7. Bug fixes to some small code and logic errors
    8. Python script now calls DASM/TASM with the compiled asm output as input to the assembler
    9. SCREEN command now supports ANTIC modes 2 to 14 (sets up display list depending on mode)
    10. Added some more examples (pm.bas, joytest.bas)
    11. 5200basl.py now runs the assembler (DASM) if the BASIC code compiles to asm without error.
    12. Added warning output if dlist/sprites/screen/charset not on correct page/1K boundary, or in invalid address
    The "hello.bas" and "pm.bas" examples show how to use 5200BAS as a beginner (ie: without using POKEs or inline assembly).
    Other examples by 3rd parties are credited in their respective folders.
    I have only test-built hello.bas, pm.bas, joytest.bas and jumpong2.bas.
    However there are some things that can be done to make 5200BAS more user-friendly and beginner-friendly (ie: reduce need to POKE, better manage the addresses of resources etc), as I've come to realise that 5200BAS should be positioned for beginners or maybe quick prototyping of ideas. This because if you have a more advanced project, you may as well do your project in ASM and spend your time battling with ASM rather than spend your time battling with wondering why 5200BAS code is not compiling/working.
    Feedback greatly appreciated as always.
  • Create New...