Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

105 Excellent

1 Follower

About fenrock

  • Rank
    Chopper Commander

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. http://forum.6502.org/viewtopic.php?p=62141&sid=23dba856425b702dba7e4b4be77fa141#p62141 This mentions it being the "Batari Basic rand16" function.
  2. A useful resource to see what modes are available is http://www.6502.org/tutorials/6502opcodes.html#JSR From the link above, you can see JSR only has Absolute addressing, but JMP has Indirect too.
  3. This? http://www.hardwarebook.info/Atari_8-bit_S-Video Also this post: And this article: https://www.atarimax.com/freenet/freenet_material/5.8-BitComputersSupportArea/8.TipsandTricks/showarticle.php?48 You can buy a ready made cable from https://www.8bitclassics.com/product/atari-xlxe-5-pin-din-to-s-video-composite-av-cable/ I don't know if the Chroma is connected to the video output port on the 65XE. It wasn't on my 800XL, which I needed to connect when installing the UAV
  4. Small update to project. It's now using the new XeX Kick Assembler plugin (integrated into kickc), which splits segments up correctly in the XeX as separate sections. This has reduced the overall size of the binary to 6,831 bytes, pretty much as low as it can go: $ ataricom bin/suite.xex ataricom 0.30-190808 (c) 2008-2019 Matthias Reichl <[email protected]> block 1: 1000-2599 (bytes: 5530, offset: 6) block 2: 259a-2953 (bytes: 954, offset: 5540) block 3: 4000-4146 (bytes: 327, offset: 6498) block 4: 02e0-02e1 (bytes: 2, offset: 6829) RUN: 10df Example linking file which is much simpler now: .plugin "dk.camelot64.kickass.xexplugin.AtariXex" .file [name="%O", type="bin", segments="File"] .segmentdef File [segments="Program", modify="XexFormat", _RunAddr=main] .segmentdef Program [segments="Code, Data, DList"] .segmentdef Code [start=$1000] .segmentdef Data [startAfter="Code"] .segmentdef DList [start=$4000] Results haven't really changed (since using "pure C" implementation), just organisation of the data/code etc. suite.xex
  5. I don't think this will work, as you're setting the ProgramEnd to be right after the ProgramStart. Building XeX files has become much simpler in the latest version of kickC. You can now use a loader file like this: .plugin "dk.camelot64.kickass.xexplugin.AtariXex" .file [name="%O", type="bin", segments="File"] .segmentdef File [segments="Program", modify="XexFormat", _RunAddr=main] .segmentdef Program [segments="Code, Data, Screen, DList, Fonts"] .segmentdef Code [start=$8000] .segmentdef Data [startAfter="Code"] .segmentdef Screen [start=$4000] .segmentdef DList [start=$5000] .segmentdef Fonts [start=$7000] All the old way of having $ff, and ProgramStart / ProgramEnd has been removed in place of the AtariXex plugin. I've posted a full application build of your code at This breaks the application up into different segments that load into different memory locations correctly. It has the bonus of getting the file size down without you having to do anything, so consider that a gift
  6. @Dmitry I had some time at lunch to have a play with this and setup your code into a project that uses XEX segment loading to load all the data into their respective memory blocks using kickc's new xex segment loader functionality. This is in response to your post at: I don't think the file you posted would work, so I went and created a project to get it working I've attached a tar.gz file which contains the src code split up into different files, there's a Makefile in there too of my own design that I use for kickc projects (it creates altirra debug file too). There's some interesting things here. 1. I've used the latest build of kickc from https://gitlab.com/camelot/kickc with XeX segment support to compile the code. 2. I've split the data into separate files with a "#pragma data_seg(name)" to put it in its own segment, look in the "include" dir for "dlist.h", "fonts.h" for examples 3. I put the DLIST into its own memory segment so it doesn't have the bug I fixed earlier and is on a nice boundary. 4. I've create a custom link file (see target/custom.ld) to define the segment addresses and use the new XeX plugin for kickc to make things simpler. It's really nice Not that I'm biased because I helped make it. 5. Because this now splits the segments into small loadable sections, it no longer has lots of zeroes in the file - this means that your font table no longer sets the letter "z" to white space! So I've add an extra row of data to fontset (for the letter N) to be whitespace (I could have used \x00 instead, but then the TEXT string looked ugly ) 6. I had to add a new "#pragma encoding(screencode_atari)" to the file. The new default in kickc is "atascii" which is entirely my fault as I think I convinced Jesper that this was more natural for atari use, but here you need the screencode values. I haven't done anything with your Interrupt code which sets the code address to 0x6000, but that's automatically been put into its own segment because of the way the XeX plugin to kickc reads memory segments from the assembler, which I hadn't expected, but is a nice bonus. It means any .pc settings in any block will automatically get created as separate segments in your output file!! The final xex file now looks like this (I add the comment at the end of each line) $ ataricom bin/main.xex ataricom 0.30-190808 (c) 2008-2019 Matthias Reichl <[email protected]> block 1: 5000-501f (bytes: 32, offset: 6) # DList block 2: 6000-60a5 (bytes: 166, offset: 42) # Interrupt code block 3: 7000-74c0 (bytes: 1217, offset: 212) # Fonts block 4: 8000-808a (bytes: 139, offset: 1433) # Application block 5: 02e0-02e1 (bytes: 2, offset: 1576) # Run address vector RUN: 8000 Anyway, I hope this helps. It was fun getting a real project to try out xex segments on and splitting them up into each chunks at their own addresses. EDIT: I've add the XEX file for people to try out. It's only 1,578 bytes long, but covers memory addresses from 5000 to 808a dmitry-kickc.tar.gz main.xex
  7. This isn't a memcpy issue, that works fine. In the code you've posted, you skip copying into $42D0 to $42F8 SCR1 = $4000 SCR1 + 18 * 40 = $42D0 but, you're copying the last 2 lines into $42F8 However, this isn't the issue, but is kind of related as the extra data in the TEXT is messing with the next part... The actual problem is that your DLIST is hanging off the end of some data, which is changing location as you add and remove lines. This is sometimes crossing a boundary limit depending on the data before it, so as I mentioned in my previous message, you may need to align it to a page boundary, i.e.: // Note, it's now 21 lines, I've add an extra line of "zzzzz..." memcpy(SCR1, TEXT, 40 * 21); // See the extra line in the data to make it 21 lines: char TEXT[] = "zzzzzz!\"zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz" "zzz#$%&'()\"zzzzzzzzzzzzzzzzzzzzzzzzzzzzz" "zzz*+,-./01zzzzzzzzzzzzzzzzzzzzzzzzzzzzz" "zzzzzzzzzzzzzz232323232323zzzzzzzzzzzzzz" "zzzzzzzzzzzzzz444444444444zzzzzzzzzzzzzz" "zzzzzzzzzzzzzz565656565656zzzzzzzzzzzzzz" "zzzzzzzzzzzzzz787878787878zzzzzzzzzzzzzz" "zzzzzzzzzzzzzz999999999999zzzzzzzzzzzzzz" "zzzzzzzzzzzzzz565656565656zzzzzzzzzzzzzz" "zzzzzzzzzzzzzz787878787878zzzzzzzzzzzzzz" "zzzzzzzzzzzzzz999999999999zzzzzzzzzzzzzz" "zzzzzzzzzzzzzz565656565656zzzzzzzzzzzzzz" "zzzzzzzzzzzzzz787878787878zzzzzzzzzzzzzz" "zzzzzzzzzzzzzz999999999999zzzzzzzzzzzzzz" "zzzzzzzzzzzzzz56569:;95656zzzzzzzzzzzzzz" "zzzzzzzzzzzzzz78789<=97878zzzzzzzzzzzzzz" "zzzzzzzzzzzzzz99999>?99999zzzzzzzzzzzzzz" "@ABBBBBBBBBBBBDDDDDDDDDDDDEEEEEEEEEEFGzz" "zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz" "zzzzzzzHIJzHIJzHIJzHIJzHIJzHIJzzzzzzzzzz" "zzzzzzzKLMzKLMzKLMzKLMzKLMzKLMzzzzzzzzzz" ; // Align the DLIST. Without this, the program may randomly crash because its location is after all the previous data, // so its start position isn't fixed and may cross a memory boundary that stops it working. Ask atari why char align(0x0100) DISPLAY_LIST[] = { // ... as before Note, as I say in the code, I add the extra line of "zzz" that was missing when you were jumping from 42D0 to 42F8. The limitation on DLIST is explained in "Mapping the Atari" as:
  8. Here are some notes about your code. Please don't take any of this as criticism, I'm really trying to help, but sometimes questions may come across oddly as I don't know what your level of understanding is. I'll be quoting mostly from the kickc manual at https://docs.google.com/document/d/1JE-Lt5apM-g4tZN3LS4TDbPKYgXuBz294enS9Oc4HXM/edit# which hopefully you've seen. The kick assembler manual is at http://theweb.dk/KickAssembler/KickAssembler.pdf which is also a useful read, as kickc generates kick assembler code. I'll come to a full solution to replace your asm code with C at the end. Handling 1024 question First, how well do you know C and do you understand that kickc is a C compiler, creating assembly from C programs? Your question of "would it handle a full 1024 without issue" makes me think you may not have done much C before. To answer this (the answer is yes) you have to understand C types. If you look at "Data Types" in the manual, you will find that "word" is a type that has a range of 0 to 65535 (or $0000 to $ffff in hex as it is 2 bytes). What the C compiler does for you is find the appropriate code to match the types you are using. So if you're looping over a larger value than 255, you'd use a word (or similar) type and the compiler would generate the correct code. Defining then copying You don't have to do this, you can of course load strings directly into the address you want them. There's a section on this in the manual using the "__address" modifier, e.g. __address(0x2000) SPRITES[64*10]; There's also the ability to align bytes to a memory boundary, currently using the "align" modifier, but that is planned to change it to "__align" in the future, as all modifiers should be tagged with double underscore. There is a downside to setting the address though, you have to understand that by default, kickc writes the Code segment to 0x2000. So if you define an array at 0x4000 (say), then when you come to create the XEX program, there will be a lot of "zero" values between your code and the memory location you're writing to. This can be solved by using XEX segment loading, which is something I've been helping @JesperGravgaard (the kickc author) to write, so that smaller binaries can be created, with different segments going into different addresses. You can also change the default address from 0x2000 using the "#pragma pc(address)" command. Overall, I would probably use a (long term) strategy of loading from a file, using the kickasm functions, as shown by Jesper here: but as you say, you want to do it directly at the moment. There's other stuff you can do as I mentioned with XEX segment loading that would improve this, but some of that is in future releases. Zero Page Variables One other thing to note about kickc is that it aggressively tries to use ZP memory addresses for any generated code. This is great because in 6502 it's quicker to use, as you may well know. However in the atari world, the OS uses memory addresses 0x00 to 0x7F, so you are best adding the following to the top of your C files: #pragma zp_reserve(0x00..0x7f) which will stop KickC from using that range of ZP addresses for itself. This may stop some crashing you've seen, but I'll get to that in a moment. The crashing above 192 problem. I didn't see this happening, but I can see you've split your fontset up into 192 bytes and then created a fontset2, so assume it was around this. I was able to change your code slightly to do up to 15 lines of 16 bytes, but had to remember to change the cont2 value up to $48F0 to compensate for the additional values. You can't do 16 lines, because you're using $FE as a marker to the last byte, and that would be the 256th byte, which is out of the range of the the Y register which can only go from 0 to 255. ... cont2: sta $48F0, y ... char fontset[] = kickasm {{ .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$01 .byte $00,$00,$00,$00,$00,$00,$00,$40,$00,$00,$00,$00,$00,$00,$01,$15 .byte $00,$00,$01,$05,$15,$55,$55,$55,$00,$10,$54,$54,$54,$54,$55,$55 .byte $01,$05,$05,$15,$15,$55,$55,$55,$40,$50,$54,$55,$55,$55,$55,$55 .byte $00,$00,$00,$00,$40,$41,$55,$55,$00,$00,$00,$00,$00,$50,$54,$55 .byte $54,$45,$54,$15,$01,$00,$00,$00,$55,$15,$45,$54,$45,$05,$00,$00 .byte $55,$55,$55,$11,$14,$05,$01,$00,$55,$55,$41,$15,$50,$01,$55,$00 .byte $55,$15,$51,$15,$55,$54,$41,$00,$55,$55,$55,$11,$44,$50,$40,$00 .byte $55,$55,$55,$54,$11,$45,$00,$00,$55,$51,$45,$14,$10,$00,$00,$00 .byte $C0,$FF,$EA,$EA,$EA,$EA,$EA,$FF,$03,$FF,$AB,$AB,$AB,$AB,$AB,$FF .byte $FF,$55,$55,$55,$55,$55,$55,$55,$5A,$5A,$5A,$58,$58,$58,$58,$58 .byte $A5,$A5,$A5,$05,$05,$F5,$F5,$F5,$58,$58,$5A,$5A,$58,$58,$5A,$5A .byte $F5,$F5,$A5,$A5,$F5,$F5,$A5,$A5,$55,$55,$55,$55,$55,$55,$55,$55 .byte $AA,$AA,$A5,$A5,$AA,$AA,$A5,$A5,$AA,$AA,$96,$96,$AA,$AA,$96,$96 .byte $A5,$A5,$A5,$A5,$AA,$AA,$A5,$A5,$96,$96,$96,$96,$AA,$AA,$96,$96 .byte $FE }}; char fontset2[] = kickasm {{ .byte $A5,$A5,$A5,$A5,$A5,$A5,$A5,$AA,$96,$96,$96,$96,$96,$96,$96,$AA .byte $00,$00,$00,$00,$00,$00,$55,$00,$05,$05,$15,$15,$54,$54,$54,$00 .byte $15,$15,$15,$15,$54,$54,$54,$00,$15,$15,$15,$15,$55,$55,$55,$00 .byte $15,$15,$15,$15,$15,$15,$15,$00,$15,$15,$15,$15,$45,$45,$45,$00 .byte $14,$14,$15,$15,$45,$45,$45,$00,$00,$00,$00,$00,$40,$40,$55,$00 .byte $00,$00,$00,$00,$00,$2A,$15,$15,$00,$00,$00,$00,$00,$AA,$55,$55 .byte $FE }}; Doing the code fully in C However, as you're in the world of C, you can do this entirely without asm blocks as follows. This removes the need to worry about looping over >192 bytes, and worrying about Y register being 0-255, etc. I've also used "memcpy" to move the TEXT array into the SCR address, rather than the loop you created, as it's much simpler. You could also use this to copy the fontset array too. Note, there were a few alignment issues in your TEXT bytes, which I've rearranged to give exactly 32 bytes per line. #pragma target(atarixl) #pragma zp_reserve(0x00..0x7f) #include <atari-xl.h> #include <6502.h> #include <string.h> void main() { char * const NEW_CHBASE = 0x4800; void * const SCR = 0x6000; // here you can do the length of the data, rather than a tag value, there are 21 lines of 16 bytes // You could also use memcpy here too (see later) but this is for illustration of using > 256 bytes not erroring, or worrying about the Y register. for (word loop=0; loop < 21 * 16; loop++) { *(NEW_CHBASE + loop) = fontset[loop]; } // Use C to set the values rather than ASM, use ">" to get the high byte of the NEW_CHBASE value *CHBAS = >NEW_CHBASE; ANTIC->CHBASE = >NEW_CHBASE; // we are using a narrow field (32 bytes per line) and there are 21 lines of text to display memcpy(SCR, TEXT, 32 * 21); // DMA Fetch + Narrow Field (32 bytes per line) ANTIC->DMACTL = 0x21; // Set ANTIC Display List Pointer ANTIC->DLIST = DISPLAY_LIST; // Set colors GTIA->COLPF0 = 0xc8; GTIA->COLPF1 = 0x11; GTIA->COLPF2 = 0x28; GTIA->COLPF3 = 0xFF; // this does same as "sei" in asm SEI(); while(1) ; } char fontset[21 * 16] = kickasm {{ .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$01 .byte $00,$00,$00,$00,$00,$00,$00,$40,$00,$00,$00,$00,$00,$00,$01,$15 .byte $00,$00,$01,$05,$15,$55,$55,$55,$00,$10,$54,$54,$54,$54,$55,$55 .byte $01,$05,$05,$15,$15,$55,$55,$55,$40,$50,$54,$55,$55,$55,$55,$55 .byte $00,$00,$00,$00,$40,$41,$55,$55,$00,$00,$00,$00,$00,$50,$54,$55 .byte $54,$45,$54,$15,$01,$00,$00,$00,$55,$15,$45,$54,$45,$05,$00,$00 .byte $55,$55,$55,$11,$14,$05,$01,$00,$55,$55,$41,$15,$50,$01,$55,$00 .byte $55,$15,$51,$15,$55,$54,$41,$00,$55,$55,$55,$11,$44,$50,$40,$00 .byte $55,$55,$55,$54,$11,$45,$00,$00,$55,$51,$45,$14,$10,$00,$00,$00 .byte $C0,$FF,$EA,$EA,$EA,$EA,$EA,$FF,$03,$FF,$AB,$AB,$AB,$AB,$AB,$FF .byte $FF,$55,$55,$55,$55,$55,$55,$55,$5A,$5A,$5A,$58,$58,$58,$58,$58 .byte $A5,$A5,$A5,$05,$05,$F5,$F5,$F5,$58,$58,$5A,$5A,$58,$58,$5A,$5A .byte $F5,$F5,$A5,$A5,$F5,$F5,$A5,$A5,$55,$55,$55,$55,$55,$55,$55,$55 .byte $AA,$AA,$A5,$A5,$AA,$AA,$A5,$A5,$AA,$AA,$96,$96,$AA,$AA,$96,$96 .byte $A5,$A5,$A5,$A5,$AA,$AA,$A5,$A5,$96,$96,$96,$96,$AA,$AA,$96,$96 .byte $A5,$A5,$A5,$A5,$A5,$A5,$A5,$AA,$96,$96,$96,$96,$96,$96,$96,$AA .byte $00,$00,$00,$00,$00,$00,$55,$00,$05,$05,$15,$15,$54,$54,$54,$00 .byte $15,$15,$15,$15,$54,$54,$54,$00,$15,$15,$15,$15,$55,$55,$55,$00 .byte $15,$15,$15,$15,$15,$15,$15,$00,$15,$15,$15,$15,$45,$45,$45,$00 .byte $14,$14,$15,$15,$45,$45,$45,$00,$00,$00,$00,$00,$40,$40,$55,$00 .byte $00,$00,$00,$00,$00,$2A,$15,$15,$00,$00,$00,$00,$00,$AA,$55,$55 }}; char TEXT[] = "zzzzzz!\"zzzzzzzzzzzzzzzzzzzzzzzz" "zzz#$%&'()\"zzzzzzzzzzzzzzzzzzzzz" "zzz*+,-./01zzzzzzzzzzzzzzzzzzzzz" "zzzzzzzzzzzzz232323232323zzzzzzz" "zzzzzzzzzzzzz444444444444zzzzzzz" "zzzzzzzzzzzzz565656565656zzzzzzz" "zzzzzzzzzzzzz787878787878zzzzzzz" "zzzzzzzzzzzzz999999999999zzzzzzz" "zzzzzzzzzzzzz565656565656zzzzzzz" "zzzzzzzzzzzzz787878787878zzzzzzz" "zzzzzzzzzzzzz999999999999zzzzzzz" "zzzzzzzzzzzzz565656565656zzzzzzz" "zzzzzzzzzzzzz787878787878zzzzzzz" "zzzzzzzzzzzzz999999999999zzzzzzz" "zzzzzzzzzzzzz56569:;95656zzzzzzz" "zzzzzzzzzzzzz78789<=97878zzzzzzz" "zzzzzzzzzzzzz99999>?99999zzzzzzz" "[email protected]" "zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz" "zzzzzzzHIJzHIJzHIJzHIJzHIJzHIJzz" "zzzzzzzKLMzKLMzKLMzKLMzKLMzKLMzz" ; char DISPLAY_LIST[] = { BLANK8, BLANK8, BLANK8, LMS|MODE4, 0x00, 0x60, MODE4, MODE4, MODE4, MODE4, MODE4, MODE4, MODE4, MODE4, MODE4, MODE4, MODE4, MODE4, MODE4, MODE4, MODE4, MODE4, MODE4, MODE4, MODE4, MODE4, MODE4, MODE4, MODE4, JVB, <DISPLAY_LIST, >DISPLAY_LIST }; There are other things you can do, e.g. aligning the DLIST just in case it crosses a 4k boundary, but for now the above is how I would move from ASM to C, given you're using kickc which is a C compiler which has the ability to embed ASM if you really really need it Hope that helps!
  9. Is it wrong that I'm drooling a little right now?
  10. For a complete "C only" version of what you were doing, you can do this: #pragma target(atarixl) #include <atari-xl.h> #include <6502.h> void main() { char * OUT = 0x4800; char fontset[64] = { 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01, 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x40,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x15, 0x00,0x00,0x01,0x05,0x15,0x55,0x55,0x55,0x00,0x10,0x54,0x54,0x54,0x54,0x55,0x55, 0x01,0x05,0x05,0x15,0x15,0x55,0x55,0x55,0x40,0x50,0x54,0x55,0x55,0x55,0x55,0x55 }; for (char i = 0; i < 64; i++) { *(OUT + i) = fontset[i]; } // Loop forever while(1) ; } which produces: .segment Code main: { .label OUT = $4800 ldx #0 __b1: // /home/markf/dev/personal/atari/projects/kickc-noodling/./src/crash.c:16 cpx #$40 bcc __b2 __b3: // Loop forever jmp __b3 __b2: // /home/markf/dev/personal/atari/projects/kickc-noodling/./src/crash.c:17 lda fontset,x sta OUT,x // /home/markf/dev/personal/atari/projects/kickc-noodling/./src/crash.c:16 inx jmp __b1 .segment Data fontset: .byte 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, $40, 0, 0, 0, 0, 0, 0, 1, $15, 0, 0, 1, 5, $15, $55, $55, $55, 0, $10, $54, $54, $54, $54, $55, $55, 1, 5, 5, $15, $15, $55, $55, $55, $40, $50, $54, $55, $55, $55, $55, $55 }
  11. As @ilmenit points out, your program starts with the byte "00" which is BRK in 6502 and would cause an interrupt to happen and likely crash your emulator. Here's an amended version of the application that works by assigning the bytes to an array (just as you would in C) which the asm block can then use. Note that asm {} is clever enough to be able to work with variables declared outside of it, so has access to the fontset array. #pragma target(atarixl) #include <atari-xl.h> #include <6502.h> void main() { char fontset[] = kickasm {{ .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$01 .byte $00,$00,$00,$00,$00,$00,$00,$40,$00,$00,$00,$00,$00,$00,$01,$15 .byte $00,$00,$01,$05,$15,$55,$55,$55,$00,$10,$54,$54,$54,$54,$55,$55 .byte $01,$05,$05,$15,$15,$55,$55,$55,$40,$50,$54,$55,$55,$55,$55,$55 .byte $FE }}; BREAK(); asm { ldy #0 loop: lda fontset, y cmp #$FE bne cont jmp exit cont: //sta $4800, y let's do absolutely nothing iny jmp loop exit: sei } // Loop forever for(;;) { }; } I've add an include for 6502.h so I could put in a "BREAK();". Locally I've got my build creating an Altirra debug file converted from the kickc debug generated file, so I can use break points. It's just a bit of unix sed/awk to generate an atdbg file. Additionally, it's worth looking at the generated asm file, as it's very readable with kickc (it's targetting "kick assembler"): .segment Code main: { // /home/markf/dev/personal/atari/kickc/bin/../lib/6502.c:20 .break // /home/markf/dev/personal/atari/projects/kickc-noodling/./src/crash.c:16 ldy #0 loop: lda fontset,y cmp #$fe bne cont jmp exit cont: iny jmp loop exit: sei __b1: jmp __b1 .segment Data fontset: .byte $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$01 .byte $00,$00,$00,$00,$00,$00,$00,$40,$00,$00,$00,$00,$00,$00,$01,$15 .byte $00,$00,$01,$05,$15,$55,$55,$55,$00,$10,$54,$54,$54,$54,$55,$55 .byte $01,$05,$05,$15,$15,$55,$55,$55,$40,$50,$54,$55,$55,$55,$55,$55 .byte $FE } Here you can see the fontset has been moved into the "Data" segment, so isn't the first thing the application tries to "run", instead that's now correctly the "ldy" instruction. Of course, you don't even have to resort to putting the bytes into an asm block, you can create the array in the standard C way too: char fontset[] = { 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01, 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x40,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x15, 0x00,0x00,0x01,0x05,0x15,0x55,0x55,0x55,0x00,0x10,0x54,0x54,0x54,0x54,0x55,0x55, 0x01,0x05,0x05,0x15,0x15,0x55,0x55,0x55,0x40,0x50,0x54,0x55,0x55,0x55,0x55,0x55, 0xFE };
  12. I had a similar issue a couple of weeks ago where Jon pointed out the instructions were the wrong way around: It manifest for me because I'm only using a Composite lead at the moment, so got a rock-steady, (albeit B&W) picture because CV and Luma were swapped. I too was quite disappointed that the instructions in the printed manual they are still sending out are the wrong way around. I contacted them via their web page reply but have had no response from them. Maybe there should be a huge sticky titled "UAV INSTRUCTIONS ARE WRONG!" to get everyone's attention. I'm still waiting on my 8bitClassics lead to make it over from the US to UK before I get full benefit out of my UAV, so hopefully I'll have as crisp an image as yourself, as I'm currently on "slightly better CV".
  13. Eclipse is an IDE (Integrated Development Environment) that allows you to write code in many languages. You can also write your own plugins for it, so that it understands how to edit certain files. WUDSN is one such set of plugins for it that allow you to write ASM easily targeting Atari 8 bit, and it has support for several assemblers, but primarily targets MADS (see http://mads.atari8.info/mads_eng.html). You can download Eclipse in several pre-bundled packages to work with the languages you want, e.g. Java, C/C++. However, WUDSN's wonderful author (@JAC!) has pre-bundled Eclipse with assemblers for you to download and use immediately. You can find the download link and instructions at http://www.wudsn.com/index.php/ide
  14. Awesome! I've already forked it and sent a PR I'd like to also be able to create "init" blocks as separate segments. I suppose the easiest way to do that will be creating a pure data segment with just ".word $2e2,$2e3,<address>". I'll have a look at if this would be an easy thing to add to the plugin to allow an easier syntax. EDIT: Ooohhh, you've already add _RunAddr, I'll send a PR for "_InitAddr" to do a inter-segment load.
  15. This is during assembly, not during runtime, so D1 isn't relevent here, as it's running on his laptop/PC. His question is actually about kick assembler, which kickc passes its ASM generated file to, but in the case of the code listed above, you can see there's a "kickasm {{ ... }}" block, which kickc passes naked to the assembler. It supports converting graphics into assembly output for you, and lots of other great stuff. I think he's trying to take a PM graphics file and convert it to binary .bytes for his eventual program. This is all doable in the assembler, but we need more information about the specifics to really help.
  • Create New...