Jump to content

jum

Members
  • Content Count

    168
  • Joined

  • Last visited

Everything posted by jum

  1. The chibiakumas stuff ( http://www.chibiakumas.com/6502/6502DevTools.php) seems to use older version of BLL / lynxass. PS: Just built lynxass 0.50 for Windows console in VS - only issue was replacing strcasecmp() with stricmp().
  2. Any contract like this is negotiable, so anyone engaging in said contract is free to edit the contract, get their lawyer friend to go over it, etc, and send it back and forth until both parties reach a similar level of acceptable dissatisfaction. Then sign (or don't).
  3. 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. 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.
  4. 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.
  5. I would love to print 2 of these for displaying my Lynxes. Do you have a 3D model file?
  6. 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
  7. 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
  8. Thanks for testing Karri. Has some impressive features for a "Tiny" editor (Copy/Paste/Sprite sheets/Animation preview).
  9. 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
  10. 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?
  11. 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

  12. jum

    Jum's Atari Pics

    Atari Pics
  13. I will test on real Lynx (using SD card adapter) and get some screenshots.
  14. 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?)
  15. 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.
  16. 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?
  17. 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.
  18. 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...
  19. - 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.
  20. 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.
  21. Correction: the 6520 PIA was holding the REN line LOW, not allowing it to default HIGH thru its pull-up resistor.
  22. 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.
  23. 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...
  24. 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.
  25. 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.
×
×
  • Create New...