Jump to content

rensoup

New Members
  • Content Count

    51
  • Joined

  • Last visited

Community Reputation

12 Good

About rensoup

  • Rank
    Star Raider

Profile Information

  • Gender
    Male

Recent Profile Visitors

288 profile views
  1. Thanks for all the improvements on the debugging side! On to a completely different topic: Interlace I think I read somewhere in the forums that the A8 is capable of doing interlace (480i) but apart from that mode, should there be an interlace option at all ? When I enable it, it's really atrocious when anything moves fast horizontally and as far as I know interlace is only for displaying 480 lines I know very little about TV standards and electronics but I read a long time ago in the SNES manual (old one, not the one found online which has explanations on custom chips) how the console worked when using 240/480 lines: -Refresh is always 60HZ in 240 and 480. The difference is that in 480 lines the electron beam is offset by HALF a scanline on odd frames. Nevermind, I found the manual and the beam is offset by a full scanline. So the bottom line is: in low res don't enable interlace...duh.
  2. Looks like you added it in 3.10, it doesn't work in that version either. I tried launching Altirra without any image so it just goes into Altirra OS, also used an empty Altirra.ini file just in case then went into PerfAn->profile->crash Is it the same thing as profile->profile view ? because that one is greyed out for me I'm on W8, maybe that makes a difference? Suggestion: Would it be possible to have an auto-update disassembly window flag ? (by right clicking on said window perhaps?) so that whenever some self modifying code trickery occurs you don't miss it... just an idea... Thanks
  3. That works, would it be possible to have it as a checkbox in the debug menu (to make it permanent) ? Not sure what you're saying... I just tried the -c switch you suggested and it seems to work perfectly... so 👍 ? Also Got a crash (3.90 test 3) when going to performance analyzer -> profile (straight after launch, tried with different xex/atrs) Thanks
  4. More questions/requests regarding the disassembly window: Any way of disabling OS variables lookups? I'm not using the OS at all so lots of my ZP variables get labelled wrong. Is it possible to display labels with regular caps ? Thanks.
  5. I'm using dark mode (thanks again!) in 3.90 test 3. It has a small issue when loading source files: empty lines show up as white lines and lines with labels show up as white with light grey text.
  6. To be clear, I don't want to include C libs or compiled C code, I thought maybe a compiler may still be able to optimize inline ASM code. There is more or less 25KB of 6502 code, and about 13KB of game data. I can give a bit more detail but the consensus seems to be negative. Right now the game runs in a "virtual" 6502 environment, that means there's no hardware specific emulation (no graphics no sound), except for input. The draw functions are intercepted and redirected to D3D. Here's a screenshot at init: -each square is a byte. -each white frame is a label (I can hover over it and get its name) -each black byte has never been accessed -each red byte is byte that's been written to -each blue byte is byte that's been read (uninitialized access!) -each green byte is byte that's been written to and read. After running the game for 2 frames: The area between $2700-$7d00 is the code. Before/After that it's data. All the memory up to $9200 is used (the black areas will be used) ZP is almost full and gives back some decent amount of code space. I'm already using the bottom of the stack. After just 10 seconds of gameplay it's mostly all green, so yes the game touches a lot of code and data. I'm using 37KB of RAM *without* Screen buffers (modeE 2 * 160pix*216 lines ), PMG Area, DL, disc buffer, Atari code. I think my 64 KB are pretty much full. Not counting graphics/sound yet! Dmsc, another forum member provided a fast lz4 decompressor at +-1500 bytes/frame. The game touches a lot of code per frame so decompressing code on the fly doesn't seem like a good option. I'm hoping I'll be able to decompress graphics data on the fly though. The project is 128KB. All the graphics/sound data will go into the extra 64KB. Nope the code is 6502 originally. I've done a little bit of code/data optimization on the project and I'm not very good at it , managed to save a few KB though. Not yet but perhaps people will be interested in contributing once it gets a public release.
  7. So I've got this porting project that I'm working on... I've got about 25KB of 6502 code which I would like to reduce if possible. Is there a tool that could automatically optimize it for space? Perhaps I could use a c compiler and convert the code to inline asm and let the compiler do some magic ? Any thoughts ? A quick search reveals these: http://web.archive.org/web/20010627195141/http://www.heilbronn.netsurf.de/~dallmann/lunix/src/opt65.c https://github.com/RussellSprouts/6502-enumerator Does anyone have experience with them ? Thanks
  8. Looks like pipemania on the XL, nice! I'm far from being qualified to answer but since nobody else has... RMT seems to be the music player of choice. It allows you to mix in sounds effects as well. Does it work with basic? I don't know... probably ?
  9. In the NMI code I found, there was this sequence(in blue): I'm guessing that's not required, but I'm not sure. It also checks for the Reset button on the 400/800... again I don't really know if that needs to be there. From the Altirra Hardware Reference Manual p55: I left it in the VBi for safety but then I chain DLI handlers which don't do any tests and then in the last DLI handler I set the NMI address back to the VBi. Just hoping that's ok because I don't have real HW for testing.
  10. I wasn't asking for myself, just suggesting that a tutorial with a working example is even better (just something simple like a color change) I've seen some multiplexor demos, I was complaining about changing multiple sprite positions/color every scanline not being practical One thing I'm not sure of and I see you don't mention it, is checking for the source of the NMI when one occurs. I made the assumption that it can be omitted but I'm not sure how safe it is. Another trick to get some cycles back when chaining DLIs is to only update the low byte of the NMI vector if you're not crossing a page... that's pretty obvious indeed but that's my modest contribution to this thread
  11. Nice of you doing this tutorial, a fully working sample would be great! I actually found code posted on AA for doing this (Thanks to Popmilo I think!) and it really helped. My brief experience with them: -I was naively hoping I could get around the sprite limitations by changing their positions/sizes/colors every scanline. As it turns out, it's practically impossible. Even though you may have the CPU time, the changes would occur all over the scanline and cause all sorts of glitches. -I think the concept was a little ahead of its time. It would have been ok with a 6502 at twice the clock speed. It works great on an ST or Amiga. -I woud like to know why on earth they didn't time DLIs to actually start towards the end of the scanline. From my tests, they start in the middle of it... this means you have to waste a lot of cycles with a costly WSYNC to hide colors changes. Those colour changes every scanline which the Atari is famous for can't actually be done with DLIs without wasting most of your CPU cycles... It's crazy.
  12. lzs16: 3.7KB !! Can't wait for the next release
  13. Well yeah I somehow missed it, sounds really nice (and cpu intensive)!
  14. Tried it on 7 gates of Jambala (110KB SAP). Lzs8: 30KB Lzs12: 8.5KB The new version can be a tiny bit slower but still several times faster than the original player! Guess it's an all around solution now
×
×
  • Create New...