Jump to content

rensoup

Members
  • Content Count

    572
  • Joined

  • Last visited

  • Days Won

    1

rensoup last won the day on December 1 2019

rensoup had the most liked content!

Community Reputation

969 Excellent

1 Follower

About rensoup

  • Rank
    Dragonstomper

Profile Information

  • Gender
    Male

Recent Profile Visitors

893 profile views
  1. Oh yeah I probably disabled the IRQ... specifically to kill the keyboard handler! You should probably set this back to whatever value was in your config
  2. I have it at $600 but I guess it should be ok at $400 ? I just build this file with MADS which becomes xbios.cfg (25 bytes) to be placed inside your ATR xbios43cfg.asm: opt h- icl "xbios43.inc" .byte $43 ; config for v4.3 version .byte c'LAUNCHEROBX' ; autorun file fname .byte >xBIOS_BASE ; xB adress for relocator .byte >(xBIOS_BASE-$100) ; xB buffer adress for relocator .word $02e2 ; INITAD .word $02e0 ; RUNAD .word $0000 ; custom I/O module - $0000 means use internal xB SIO .word $0000 ; relocator for custom I/O module .byte $ff ; PORTB - you can't swith off BASIC this way .byte $40 ; NMIEN - config at start .byte $80 ; IRQEN - config at start xbios43.inc is where you set the address (xBIOS_BASE) to be included in the file above and in your project (to call xBIOS_OPEN_FILE,...) xBIOS_BASE =$600 ; // must update LORAM_TOP ( can't just equal it to LORAM_TOP because this file is also included in xbioscfg.asm which gets rebuilt into xbios.cfg) xBIOS_SIZE =$400 xBIOS_VERSION =xBIOS_BASE+$02 xBIOS_RENAME_ENTRY = xBIOS_BASE+$03 xBIOS_LOAD_FILE = xBIOS_BASE+$06 xBIOS_OPEN_FILE = xBIOS_BASE+$09 xBIOS_LOAD_DATA = xBIOS_BASE+$0c xBIOS_WRITE_DATA = xBIOS_BASE+$0f xBIOS_OPEN_CURRENT_DIR = xBIOS_BASE+$12 xBIOS_GET_BYTE =xBIOS_BASE+$15 xBIOS_PUT_BYTE =xBIOS_BASE+$18 xBIOS_FLUSH_BUFFER = xBIOS_BASE+$1b xBIOS_SET_LENGTH = xBIOS_BASE+$1e xBIOS_SET_INIAD = xBIOS_BASE+$21 xBIOS_SET_FILE_OFFSET = xBIOS_BASE+$24 xBIOS_SET_RUNAD = xBIOS_BASE+$27 xBIOS_SET_DEFAULT_DEVICE = xBIOS_BASE+$2a xBIOS_OPEN_DIR =xBIOS_BASE+$2d xBIOS_LOAD_BINARY_FILE = xBIOS_BASE+$30 xBIOS_OPEN_DEFAULT_DIR = xBIOS_BASE+$33 xBIOS_SET_DEVICE = xBIOS_BASE+$36 xBIOS_RELOCATE_BUFFER = xBIOS_BASE+$39 xBIOS_GET_ENTRY = xBIOS_BASE+$3c xBIOS_OPEN_DEFAULT_FILE = xBIOS_BASE+$3f xBIOS_READ_SECTOR = xBIOS_BASE+$42 xBIOS_FIND_ENTRY = xBIOS_BASE+$45 xBIOS_SET_BUFFER_SIZE = xBIOS_BASE+$48 xDIRSIZE = xBIOS_BASE+$3e5 ; current directory size in sectors (1 byte) xSPEED = xBIOS_BASE+$3e6 ; STANDARD SPEED (1 byte) xHSPEED = xBIOS_BASE+$3e7 ; ULTRA SPEED (1 byte) xIRQEN = xBIOS_BASE+$3e8 ; User IRQ (1 byte) xAUDCTL = xBIOS_BASE+$3e9 ; AUDCTL xFILE = xBIOS_BASE+$3ea ; File handle (2 bytes) xDIR = xBIOS_BASE+$3ec ; Root directory handle (2 bytes) xIOV = xBIOS_BASE+$3ee ; I/O module entry (2 bytes) xBUFFERH = xBIOS_BASE+$3f0 ; Buffer adr hi byte (1 byte) xBUFSIZE = xBIOS_BASE+$3f1 ; Buffer size lo byte $100-SIZE (1 byte) xDAUX3 = xBIOS_BASE+$3f2 ; Buffer offset (1 byte) xSEGMENT = xBIOS_BASE+$3f3 ; Bytes to go in binary file segment (2 bytes) xNOTE = xBIOS_BASE+$3f5 ; File pointer (3 bytes) xDEVICE = xBIOS_BASE+$3fc ; Device ID xDCMD = xBIOS_BASE+$3fd ; CMD (1 byte) xDAUX1 = xBIOS_BASE+$3fe ; Sector lo byte (1 byte) xDAUX2 = xBIOS_BASE+$3ff ; Sector hi byte (1 byte) and that should do it... xbios.cfg xbios43cfg.asm xbios43.inc
  3. I'm not sure why Supperune chose 5 but it looks pretty good. Anyway, I'd rather use PMGs with prior0 to try and get more colors. That picture is going to need a lot of tricks and perhaps compromises so it needs a custom solution (unfortunately). I'll be posting updates of the tool for anyone to try.
  4. Not exactly, the picture is greyscale so far (5 intensities)... For the coloring I'm figuring out what's possible per scanline and then I'll incorporate that in my converter. I'd like to have PMG repos/resize/recolor, prior0 (not all at once on the same scanline of course.)
  5. Don't say that too loud 😏
  6. My project is a little more modest... I only need it for one picture after all. It'd be more of a converter. The user create a picture in a way that helps it select what to output (by using layers). The converter would be aware of DMA timings of course. I don't think there's any point recreating an art package just for this, it would just be inferior to all the art tools that already exist. As for showing restrictions, we've got emulators... One problem is figuring out a way to get a decent turn around time between the art package and the emulator. Sure, I thought there were other restrictions. It works for this image but when you have all 5 colors used all over the picture, it's just better to try fixing the clashes with the tool. The gollum pic has only 39 clashes but Superrune's PoP one has 181.
  7. I don't like all of them but the sentinel eye pic is nice. Sphinx too, it's just 5 colors, right? Exactly. Some images are impossible for A8 (high resolution) and other images are impossible for C64 (more than 16 colors and faithful conversions from original pictures). But Atari 400/800 came out 2.5 year before C64. Sure, but I'm starting to look into Mode4 palette/PMG changes and the DMA cost for mode4 is so high that it's difficult to do a single full palette change (5 colors) at an arbitrary point on the screen. Yes you have PMGs but they are quite limited too. The problem is that all those restrictions don't seem very compatible with real world cases. You can have lots of colors on screen but only a few in a large zone.
  8. didn't say it was difficult, it was just an interesting coincidence... That's why I did this tool, to try to avoid messing too much with 5 color pictures by going through all possible combinations and let the user select one for exporting. I would then be able to use this pic with another coloring tool... which I have yet to write. Really ? why ? (Not familiar with the c64 at all)
  9. Here's a tricky one: And here's another one I found while browsing bitfellas.org 😃
  10. Wondering how got those clashes fixed because when I load the original pic in G2F in fails quite badly (5th color and smart color enabled) ? I guess the orange bits are PMGs with prior 0 ?
  11. To be fair, even with such a crap palette, the quality of some of the C64 pictures are mindblowing. Many are simply impossible to convert on the A8.
  12. Didn't know about GTIA9 but I meant the C64 version might not be coming from an emulator, maybe the original was drawn on a PC.
  13. Here's a very simple tool that I wrote which fixes clashes for pictures that be displayed in mode4. it basically replaces color 3 or 4 pixels with the closest matching color if there are color 3 and 4 pixels (depending on which one is most used ) inside a 4x8 tile. Here's a test with a 5 color C64 pic: and here are the C64 and the Atari version side by side (the A8 version is darker because it goes through Altirra) It only works with 5 color pictures (greyscale prefered as the color matching isn't great) and outputs TGAs (error & fixed). It can also optionally output Atari data although it's not that useful as you'd probably want to apply other conversion processes on top of it. It's nothing complex but someone might find it useful... m4cf.zip
×
×
  • Create New...