Wanted: Display List Editor for Windows

[snicklin]

Does anyone know of an existing display list editor for Windows?

 

Currently I've got a binary file which I open with a hex editor and then I manually read the values and update the file.

 

While it doesn't take too much work, it'd be quicker if I was using an editor.

 

I then need the editor to save the data back to a binary file (with only the DL data in it, no other data required).

 

There must be one somewhere....?

[pirx]

Why not define few const or macros in your assembler of choice?

Even without any magick the DL is pretty readable in assembler:

 

;------------------------------
dl
    dta $00+$80
    dta $4f
    dta a (facebolek)
    :17 .by $0f
    dta $80


    .REPT 10, #
    dta $42
scradr0:1
    dta a (screen0:1)
    .ENDR

    dta $42
    dta a (screen_bottom)
    :9 .by $02
    dta $00


    dta $1
dl_skip1
    dta a(dl_end)


dl_line1
    dta $42 ;added July 27, 2009 * Like * Comment
    dta a (textScreen)
    dta $00


    dta $1
dl_skip2
    dta a(dl_end)


dl_line2
    dta $42
    dta a (textScreen+40)
    .by 2


    .byte $70
    dta $42
dl_bottom_text_addr
    dta a (messageScreen)
    .by $00,$02


dl_end
    dta $41
    dta a (dl)
;------------------------------

Edited January 4, 2016 by pirx

[Heaven/TQA]

and why editor when you can easily include them in your source code by having few lines of code?

 

dlist

 

:3 .byte $70

.byte $4e

.word vram

:100 .byte $0e

...

.byte $41

.word dlist

 

 

or you can use the MADS counter

 

...

:100 .byte $4f,<(vram+#*80),>(vram+#*80)

...

 

etc

 

I never would use an editor as you are trillians of time faster in adjusting custom display lists in code than via editor. even on Amiga I am writing my own copper list in source code.

 

 

:3 .byte $70

[snicklin]

The reason that I'm not wanting to do it in my code is because I am building a library of routines.

 

With the library, I just insert the binary files into a game specific folder with a specific name and it will use it.

[pirx]

this seems to be one rather convoluted way of doing things that are not static, but it is definitely your software and your method. I'd suggest using assembler anyway, even if for generating pure binary, headless file (use opt -h in mads to remove header(s)).

[snicklin]

this seems to be one rather convoluted way of doing things that are not static

 

You should see my build system!! I can supply variables to it and it will build in different languages, PAL/NTSC versions and will build all of my code, not just one game. I'm currently working on it to supply variables for ICE graphics modes / non-ICE binaries.

[Synthpopalooza]

I am actually wondering if the WUSDN environment might be helpful in this regard. I've played around with the tool and it seems very capable.

 

I thought about doing such a thing myself ... self-generating code in BASIC or assembly for all the ICE modes. It is an easy enough task, except for the PCIN and PC0 modes (mode 10 blended with a non-GTIA Antic 2 or 4 mode) in that the non-GTIA display list being flipped, needs to be set to horizontal scroll, and HSCROL modified to slide the non-GTIA pixels one color clock right, to correct for the mode 10 shift (HIP effect).

[snicklin]

I am actually wondering if the WUSDN environment might be helpful in this regard. I've played around with the tool and it seems very capable.

 

I'm using WUDSN, so if anyone does find a way, I'll be listening....

[Irgendwer]

 

You should see my build system!! I can supply variables to it and it will build in different languages, PAL/NTSC versions and will build all of my code, not just one game. I'm currently working on it to supply variables for ICE graphics modes / non-ICE binaries.

 

So what prevents in your build system to assemble a single file with display-list-data and include the resulting binary later in the process?

 

To get an impression how comfortable and self-explanatory the editing can be, you may like to inspect my solution for cc65/ca65:

 

https://github.com/cc65/cc65/blob/master/asminc/atari_antic.inc

 

The defines with example start at line 27.

[snicklin]

 

So what prevents in your build system to assemble a single file with display-list-data and include the resulting binary later in the process?

 

To get an impression how comfortable and self-explanatory the editing can be, you may like to inspect my solution for cc65/ca65:

 

https://github.com/cc65/cc65/blob/master/asminc/atari_antic.inc

 

The defines with example start at line 27.

 

I see where you and Pirx previously are coming from here.

 

There's a lot of implications one way or the other depending on what method I use here. Frankly, more than my brain can handle at the moment. I need to sit down and think about all this.

 

My concern (though it may not be valid) is that it won't work in my situation. I want to write extremely generic code that works across all my projects and pretty much all that I will need to supply for different projects (which are reasonably similar - not a card game and then a car racing game) is different variables set by defines. For display lists, I want it to always use 'displayList01.dat' for example which is in the game's specific data folder.

 

I am not intending to write a one-off game here, it needs to be pretty much an engine for other similar games.

 

My worries may be incorrect, but I'm on a sugar rush at the moment and can't think!