Jump to content

jum

Members
  • Content Count

    140
  • Joined

  • Last visited

Everything posted by jum

  1. 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.
  2. I would love to print 2 of these for displaying my Lynxes. Do you have a 3D model file?
  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. bezerkoids_alpha1.zip 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
  4. 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. Thanks for testing Karri. Has some impressive features for a "Tiny" editor (Copy/Paste/Sprite sheets/Animation preview).
  6. 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). Usage: 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 tinyspriteeditor_lynx_V1.1.zip
  7. Comparison of the 2 screen clear methods, using Handy and using a real Lynx (note: real Lynx seems to be faster than Handy). 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?
  8. From the album: Jum's Atari Pics

    Comparing time taken to clear Lynx screen and collision buffer, then draw the playfield, using 2 different methods

    © James Higgs 2017

  9. jum

    Jum's Atari Pics

    Atari Pics
  10. I will test on real Lynx (using SD card adapter) and get some screenshots.
  11. 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) : snap_clearSCB.bmp 2. Draw playfield sprite directly to collision buffer, then draw it to the draw buffer (2 calls to Suzy): snap_directCollClear.bmp 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?)
  12. 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.
  13. 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?
  14. 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.
  15. 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...
  16. - 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.
  17. 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.
  18. Correction: the 6520 PIA was holding the REN line LOW, not allowing it to default HIGH thru its pull-up resistor.
  19. 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.
  20. FINALLY - SOME CLOSURE! Well today I finally managed to fix the 800XL 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...
  21. 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.
  22. 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.
  23. 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.
  24. 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: https://github.com/james7780/5200BAS_python (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.
  25. Progress update: Spent some time converting Dan Boris' DASM player-missile example ("52pm.txt") to 5200BAS, which resulted in some bug fixes in the python code, and adding some more items to the list of improvements that could be added to 5200BAS, eg: POKE $1000, $77 not possible (have to use "A=$77 : POKE $1000,A") Error messages need to be more concise. Also need to compare 5200BAS with Batari basic.
×
×
  • Create New...