Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

9 Neutral

About laoo

  • Rank
    Star Raider
  • Birthday 01/10/1980

Profile Information

  • Gender
  • Location
    Wrocław, Poland
  1. Hi. I'm trying to understand the nuances of sprite data format, and don't feel like starting a new thread, so I thought I'll catch on here for time being, as the issue have been mentioned here. So could someone explain what it means a data Packet header of '00000'? Is it 5 '0' bits? 5 bytes? 5 nibbles? And how does it works as an additional detector of the end of the line of sprite data? Follow-up question: the offset to next sprite line is signed or unsigned? EDIT: After reading what I've wrote I came up to a conclusion that 5-bit version might have sense given that we can't draw 1-pixel wide packed sprite. EDIT2: Next sentence that is not clear for me: This [a data Packet header of '00000'?] is normally used as the tiller in the last byte of a line of data, but it can be located anywhere in the data line, not just the last byte. Does it mean that we can draw jagged sprites when the line can be ended anywhere using this EOL detector? What does it relate to the sentence the hardware [...] requires that the last meaningful bit of the data packet at the end of a scan line does not occur in the last bit of a byte (bit 0)? So there must be one '0' bit or 5 '00000' bits at the end of the line? And finally: where is the later on the truth of '00000'?
  2. Why not start some ultimate benchmarking initiative then? Mikey timers should be more than enough to measure precisely everything we could imagine. Some average values and standard deviations could be calculated. We just need some core administrating all the tests with terminal emulation, and writing specific benchmarks should be pure fun. I'm sure that most people here would be eager to participate in running such suit on their hardware
  3. I haven't checked it precisely but it might be it, as I've found it here: http://atariage.com/forums/topic/229015-porting-comlynx-epyx-redeye-code-to-cc65/?p=3058741 Thanks for help.
  4. Couldn't find it there. OK. It's not an issue then, because I thought that they are widely known files and only I can't find them.
  5. It's really not a mystery that 6502 wasn't designed with high level language compilation in mind and currently there is no way to write a good compiler for it - it would be too freaking complicated to even start thinking about it in non-corporate environments. It's exactly opposite to modern CPUs where you virtually can't write code as good as compiler can generate in a blink of a second. Hence I'm just not satisfied with quality of code generated by cc65. Besides... assembly is pure fun. Tons of C/C++ I have at work
  6. One more question: where can I find files mentioned in Appendix 4 of Lynx documentation: http://www.monlynx.de/lynx/sprite.html ? Namely 6502:macros/sprite.mac, 6502:macros/display.mac, 6502:src/sprite.src and 6502:src/display.src
  7. Here's the animation of content of page zero before and after decryption. So yes, page zero is littered with leftovers from the decryption process. I ran decryption in Altirra. Processor is roughly the same But it might be a good idea to add a profiler to Handy. It should not be very difficult. Given it has cycle exact emulation.
  8. I see Nevertheless if someone would feel an urge to pursue the Monty Python's level of academicity I could prepare an idle priority brute-force encrypter that would walk through whole space of different fillings of unused bytes in search of encoded block with as many zeros as possible :-)
  9. Yeah, yeah, I know. Premature optimization is my hobby too But there was a question what is the stake here? I don't own the console and really don't know how much it takes to decrypt one 51 byte long block. I presume that decrypting one instead of two is perceivable, but will it be visible to speed up the process by few percent? I even don't know how much faster it can be. I could do some tests - generate some blocks with different number of zeros and see what the number of cycles it will take. But overall the means of optimization here are... cumbersome at least. It involves filling the extra space with different values and checking the number of zeros on result after encoding. Pure brute-force. If someone has idle cycles on his/her machine it can be done in spare time.
  10. If my experience will prove successful, I will surly post here a "how to make a game in assembly from scratch" guide
  11. I did some profiling of that modular multiplication algorithm while it decoded Karri's micro-loader and here are the results: Last four columns say about number of branch taken vs. not taken. It took overall 1486320 cycles. I think it might be faster if the encoded stream had more zero bits. But how much it takes on Lynx to execute such number of cycles? It's much more than 0.4s? So is there really any sense optimizing it?
  12. Thank you Nop90 for pointing to that thread, I've initially skipped it and indeed I've found there what I was missing and I presume, that I can reconstruct now the information which is inaccessible due to Wookie's page being down. Nevertheless I'm a professional programmer and as a Lynx newbie I've had a lot of trouble to build a consistent view on the Lynx boot process and overall "how to make a game in assembly from scratch" workflow, as the information is scattered around in many, many threads and currently starting a journey with Lynx programming has rather high entry threshold.
  13. Hi, I'm mainly from Atari 8-bit neighbourhood, but tempted by recent Atari Lynx 30th Birthday Programming Competition I've decided to give it a try and started to gather enough knowledge to craft some Lynx assembly "hello world" on my own. I've read cursorily posts from this sub-forum and found that there is a substantial amount of interesting findings, but sadly some seems to be lost. Especially there are discoveries by Wookie about boot process and encryption that I'm very interested, but all links are dead now. E.g. none of these work: http://atariage.com/forums/topic/183090-booting-from-rom-lnx/?p=2305616 Are there any mirrors, copies... whatever? Maybe it's a lesson, that more information should be kept internally, rather in uncertain outside world.
  14. As for me, more consistent and intuitive behavior seems to be to specify number of bytes to disassembly. And also more useful - when I want do disassembly some chunk of code I don't necessary know how many lines of code it will be, but I most probably know how many bytes the code occupies.
  15. Hi. I've found a minor inconsistency in disassembly commands: Lenght parameter in u command is treated as a number of disassembly rows to produce and in .dumpdsm command it is treated as a number of bytes to disassembly. Example session: Altirra> u 8000 L10 8000: 20 6E 89 LOADER JSR INIT.SYSTEM 8003: 20 D1 89 JSR INIT.ONETIME 8006: A2 00 LDX #$00 8008: 20 E1 89 JSR INIT.LEVELMANAGER 800B: 20 E4 89 JSR INIT.SPRITES 800E: 20 DA 89 JSR INIT.RENDERER 8011: 20 FE 83 JSR STATIC 8014: 20 30 89 LOADER.ENABLEOS JSR INIT 8017: 20 8D 89 JSR INIT.PLAYFIELD 801A: 20 B1 89 JSR INIT.LEVEL 801D: 4C 1C A3 JMP GAME.LEVELLOOP 8020: 2C 0F D4 TEST BIT NMIST 8023: 10 03 BPL NMI.NO 8025: 4C F4 80 NMI.DLI JMP DLI.DISPATCH2 8028: 8D 0F D4 NMI.NO STA NMIRES 802B: 4C 92 80 NMI.VBL JMP VBL Altirra> .dumpdsm d:\out.asm 8000 L10 Disassembled 8000-800F to d:\out.asm
  • Create New...