Jump to content

tschak909

Members
  • Posts

    6,897
  • Joined

  • Last visited

  • Days Won

    6

Blog Entries posted by tschak909

  1. tschak909
    I am roughly halfway through with reconstructing the screens on the APX Extended Fig-Forth disk. There is enough here to be able to use the Debugging Aids (DUMP, CDUMP, etc.), the EDITOR words for manipulating FORTH screens, and the 6502 FORTH ASSEMBLER.
     
    If you want all three of these tools, an 18 LOAD is sufficient (provided of course you are in DECIMAL mode)
     
    Onward...
     
    -Thom
     
    You can see it working here:
     

  2. tschak909
    Hello everyone, progresssing on fig-FORTH.
     
    As part of my work, I am hammering away on tools that I will need to write the game. One of the tools I absolutely want, is a full screen text editor, it will have very simple requirements:

    split a 64 character fig-FORTH screen line into two 32 character windows, which when the cursor moves, will be scrolled over.
    provide a way to switch between the following modes, selectable by the yellow keys:
    Edit mode - Edit a given screen (OPTION)
    Select Mode - Select a given screen (SELECT)
    FORTH Mode - quickly type FORTH words to test things. (START)

    The screen will be divided into a few areas, from top to bottom:
    The Current Screen #
    The Editing Window showing the current screen.
    A Status Line (need to add this into my display list) showing EDIT MODE, SELECT MODE, or FORTH MODE.
    A four line window for entering FORTH commands or showing edit HELP.

    I have implemented initial versions of the needed words to setup the screen memory, to convert between ATASCII and ANTIC screen codes, various display primitives for writing to parts of the screen outside the E: device's reach (SEMIT, STYPE, SSPACE, SSPACES, SD.R, S.R, S., etc.). All of these words are written in FORTH, and I haven't sped anything up, so it does need some love there.
     
    Now, I need to start writing the primitives to move around the displayed screen. I am posting a video here, enjoy
     
    -Thom
     

  3. tschak909
    I have temporarily tabled the breakout invaders project, so that I could pursue doing a game on the Atari 2600. After about four days worth of work so far, I've managed to make a stable kernel, and am working on the game every day.
     
    So far, the game uses a 25 line playfield, rendered at 8 pixels tall, and I am working on the needed coarse scrolling before I modify it for fine scrolling.
     
    I am definitely enjoying this, and it's definitely a zen-like experience for me.
     
    Once the game reaches a playable state, I will post to the Homebrews forum.
     
    pescoman_v9.zip <-- current stable kernel.
  4. tschak909
    It's so strange to be coming back to this platform, after not seeing it since 1989. I completely missed the eastern european renaissance that occurred in the early to mid 1990s (which is still happening even today.), and am amazed to see just what has been created for the ANTIC based Atari systems since I left.
     
    It seems I am not the only person who has decided to come back, After combing the posts here on this site, there are a lot of developers pumping out things here too! Wow, a Rally-X game, a Super Mario Bros platform game, and a few other things, very impressive. The development tools have also improved too! EnvisionPC is fantastic! And the breadth of host-side 6502 cross assemblers made my head spin. (I decided on using MAC/65 )
     
    I started early this morning, basically re-learning everything from scratch. Damn! I forgot it all ) I found copies of some very good Atari 800 programming materials on AtariArchives.org and started reading and typing things in, just to get the hang of it again.
     
    I am currently trying to make some basic macros right now, namely, I finished the first version of my system equates file, and I started working on my own set of core macros which i will want to use throughout my code.
     
    Currently trying to debug my memory clearing routines.. darn, it's spiraling out of control. Will try to re-write it again to use a different approach.
     
    I seem to be making basic mistakes as to the operations of the compare instructions. Will look at some existing code to get a better approach.
  5. tschak909
    I am currently trying to build a simple demo program that uses a DLI that increments the color registers. I am thinking if i just increment the zero page registers when the interrupt occurs, I will get a sort of ripple effect. But right now, somehow, the low bit of my LMS instruction is getting obliterated, grr a load instruction going wrong.
     
    have attached the code i am working on.
     
    -Thom
     
    p.s. wow, i went 12 hours without realising i didn't even upload the attachment... go me!2puck.zip2puck.zip
  6. tschak909
    Evening all,
     
    Just hacking away on the game. I have decided to add a set of three shields at the bottom of the playfield utilising ANTIC mode E for the graphics. I drew some preliminary shields using GIMP, and systematically converting each group of four pixels into their appropriate nibbles for the screen bytes. Is there an easier way to do this? hmm, i'll just plod along for now.
     
    On the missile front, the missiles are firing properly, but I need to speed them up slightly, it is smoothly shooting however. Lessons learned? be sure to not overdo EORs.
     
    -Thom
     
    <-- drawing the shields, guide lines show byte boundaries.
  7. tschak909
    I have completed the first bits of code to handle player motion, I will leave as is for now, and continue on implementing the rest of the core implements for game play, then return to the various motion routines to add the velocity tables.
     
    I have also put a placeholder in the bonus section up top for now, and redid the font slightly to make it more readable.
     
    p.s. I am losing a little bit of granularity doing ANDs on RTCLOK, what if I wanted to do vblank checks on anything but 1 2 4 and 8? what would be the best way to do that?
     
    -Thom
     
    pesco.zip
  8. tschak909
    Ok, well, got my memory clearing routine to work properly, was just a few little typos. Basically was very easy. I had decided to make two separate macros that were self contained for clearing single and multiple pages becase the addition of clearing multiple pages was just a few instructions more, and didn't make sense to loop back through re-setting everything for each individual page....
     
    I have made a couple small test programs just going through loops and setting values, just trying to get a handle on some very basic things.
     
    color1 - flip through all 256 colours and loop
    color2 - flip through colors 40 through 50, looping up, then down, each increment followed by a WSYNC
     
    I will be posting my little snippets in MAC/65 format and compiled format inside ATR disk images (Atari DOS format.)
     
    Well, I'm re-learning.. bit by bit... albeit slowly for now.
     
    _pesco_pacman_v7.zip
  9. tschak909
    Well guys, after a lot of debugging, I have the horizontal scrolling motion working properly.. I have sped it up so that it could be seen.
     
    I have attached the code below, but basically my approach is this:
     
    * use the main line code to set global states, go left? go right?
    * use the VBI to update actions that need to happen per frame, update the zero page locations for current HSCROL and LMS positions.
    * use the DLI to update the HSCROL registers appropriately.
     
    it's coming along, bit by bit... now it's time to put in the first bits of player code
     
    (and no, this is NOT a final on the motion... I will be tweaking the motions using a lot of hand tables to give the illusion of speeding up and slowing down...)
     
    what do you guys think?
     
    -Thom
     
    pescoman_v91.zip
  10. tschak909
    Decided for my first game to be a Space Invaders type game. Did some initial sketching in Envision, and am now posting the results of my work.
     
    The graphics are meant for antic mode 4 displays, with each line setting a DLI to change the color palette of each line essentially doing a hue change.. I chose to use all four colors for a shaded look rather than a non-shaded flat but colourful look.
     
    What do you guys think?
     
    <-- editing the characters
     
    <-- doing a basic tile test.
     
    -Thom
  11. tschak909
    Working currently on the player graphic. I wanted the player to be able to have a temporary shield, so I designed two definite states, with and without shields, which will be rotated with the character set providing the animation. I am also reorganising the display list to something more proper for horizontal scrolling.
     

     
    Next, I will be working on the most basic player movement.
     
    -Thom
  12. tschak909
    After fixing the little display list weirdness, it works now. A tight locked interrupt loop that changes the color of every four lines (more or less) via a display list interrupt, using an increment inside the interrupt routine to change a page zero counter. It runs very fast, so it tends to strobe.. Now i need to learn proper delaying techniques. I will be tweaking this routine to make the effect not so perceptively fast, but at least it works. Yay :-)
     
    -Thom
     
    2puck.zip
  13. tschak909
    Hello everyone. I am creating a series of tutorial and exploratory videos chronicling my journey through learning FORTH and applying it to the Walking Life demo that I am working on in FIG-FORTH.
     
    You may subscribe to my channel on youtube: http://www.youtube.com/tschak909/ to see them, and to start off, and I will be posting them here, as I complete them:
     
    Introduction: http://www.youtube.com/watch?v=JaNn1cnvBAI
    Screens in FIG-FORTH: http://www.youtube.com/watch?v=nZKYONc7sYs
    Editing Screens in FIG-FORTH: http://www.youtube.com/watch?v=-E5zQZApJRQ
    Making More Useful Screens in FIG-FORTH:
     
    Enjoy! More to come. I am trying to show that FORTH is a very powerful language that is approachable, and I hope these videos go a step towards showing that it is a good fit for a language for a small system like the Atari 8-bit platform.
     
    -Thom
  14. tschak909
    I took some time out, today, to learn the basics of bit-banging the POKEY chip.. I will be doing more complicated experiments as my development with the invaders game continues....
     

    ; ; SOUND01 - PLAY A MUSICAL SCALE ; .INCLUDE atariequ.asm ; ATARI EQUATES *=$0600 ; CRAM OURSELVES IN PAGE 6 JMP START ; GO TO START, SKIP OVER TABLE ; ; TABLES ; PCHTBL .BYTE $79,$6C,$60,$5B,$51,$48,$40,$3C ; C MAJOR SCALE DLYTBL .BYTE $3C,$1E,$1E,$1E,$1E,$1E,$1E,$FF ; QUARTERS ON THE ENDS, EIGHTHS IN THE MIDDLE CTLTBL .BYTE $A8,$A8,$A8,$A8,$A8,$A8,$A8,$A8 ; ALL HALF VOLUME, PURE TONES (SQUARE) ; ; START ; START CLD ; CLEAR DECIMAL FLAG CLC ; CLEAR CARRY FLAG RESET LDA #$00 ; STA AUDCTL ; CLEAR AUDIO CONTROL REGISTER LDX #$00 ; X = OFFSET COUNTER FOR TABLES LOOP LDA PCHTBL,X ; GRAB CURRENT PITCH STA COLOR2 ; CHANGE COLOR TO DENOTE WHAT IS BEING PLAYED. STA AUDF1 ; STORE IT LDA CTLTBL,X ; GRAB CURRENT DISTORTION/VOLUME STA AUDC1 ; STORE IT DELAY LDA RTCLOK+2 ; GRAB LOW BYTE OF REAL TIME CLOCK AND DLYTBL,X ; LOP OFF EVERYTHING BUT NEWHAT WE WANT TO COUNT TO BNE DELAY ; ELSE WAIT SOME MORE. DECLIK LDA RTCLOK+2 ; READ RTCLOK AGAIN AND DLYTBL,X ; CHECK AGAIN BEQ DECLIK ; WAIT IF IT MATCHES NEXTNOTE INX ; INCREMENT X CPX #$08 ; HAVE ALL 8 NOTES PASSED? BEQ STOP ; YES, STOP BCC LOOP STOP LDA #$00 ; CLEAR EVERYTHING STA AUDF1 ; FREQUENCY STA AUDC1 ; AND DISTORTION/VOLUME INFINITE JMP INFINITE ; AND HIT THE INFINITE LOOP
     
    the resulting sound output is here: arcadia.zip
  15. tschak909
    Afternoon,
     
    I've made a series of 4 YouTube videos describing in detail the conceptual work, and the creation of words to implement an ANTIC disassembler tool in FORTH to compliment the ANTIC assembler that I wrote.
     
    This basically demonstrates how FORTH can quickly be used to make useful tools that can be intermingled with the development of programs in FORTH so that you don't have to load entire other programs to get stuff done, but rather just flow from one vocabulary of words to the next.
     




     
    Let me know what you guys, think.
    -Thom
  16. tschak909
    After much deliberation, I finally managed to get the memory clear/fill function debugged.
     

    ; ; FILL PAGES MACRO ; ; %1 = beginning page to fill ; %2 = number of pages to fill (should be - 1) ; %3 = byte to fill with (e.g. $00) ; ; $CC = 00 for top of page boundary ; $CD = page currently being filled ; $D5 = corresponding to ending page ; .MACRO CLRP STCL LDA %1 STA $CD LDA #00 STA $CC LDY #0 LDA $CD ADC #%2 STA $D5 CRLP LDA %3 DEY STA ($CC),Y BNE CRLP INC $CD LDA $CD CMP $D5 BEQ CRLP BCC CRLP .ENDM
     
    So, what do you guys think? How can I make this so that it can fill regions of memory that don't end on nice page boundaries? Should I need to do that?
     
    -Thom
  17. tschak909
    Hello everyone,
     
    I've been putting little bits of musings on FORTH, as I use the fig-FORTH implementation on the Atari 800 to write a graphics demo that I am working on.
     
    Because FORTH isn't a language, it's an environment with a way of life radically different than anything else out there, It has seriously caused me to reexamine my perspective on solving problems through computer programming.
     
    I've spent the better part of 25 years writing computer programs. At first, it was me, as a kid, looking around this crazy world of the computer (at this time, an Atari 800), trying to see what I could get away with. I progressed to other languages, other processors, other systems, eventually entering into the workplace as a professional programmer, not forged from the halls of academia, but from my own autodidactic experience.
     
    Along the way, I explicitly exposed myself to a variety of environments, both in play and in work, because I am genuinely curious, creating things interests me, and tools interest me because tools allow me to create, they allow me to visualize what is going on in my mind, and to do what I love to do best, to solve the problem. I use a healthy set of these environments that I've learned, on a daily basis, ranging from system languages like C, C++, Objective-C for application development, to PERL, PHP, Ruby, Python for web or small user facing applications, to even specialized languages like Erlang, which is unparalleled for distributed application development.
     
    And yet, I am very disconcerted with the state of application development today. We create large, overly generalized programs, on top of layer cakes of generalized programming and operating system infrastructures which serve ultimately, to service themselves, with the side effect being that you, the user, are able to use the system, for....whatever you may generally want to use it for, so long as we have an App to do that. This hypergeneralizaton exists, because we are taught to create general solutions to problems; try to solve as many derivations of a problem that you can think of...
     
    ...but we never think of everything, do we? Somebody else will always want another feature.
     
    So over time, these features aggregate into software, and, instead of writing software to solve the problem directly in front of us, we combine software off the shelf from different sources. A programming toolkit here, a physics library there, and we feel that these things get us to the finish line, faster. Sometimes, they do, but at a price. As Chuck Moore once said, "Programmers do not write megabytes of code. They borrow kilobytes of code; do this a thousand times, and you have a megabyte of code."
     
    But the problems do not end there, in fact, they often start there. Bugs are everywhere, and it is a simple fact that none of the code a programmer will be using is bug free. This does not count the program code that a programmer writes himself. So therefore, a programmer ultimately pays for mistakes he isn't accountable for. This is a fact of software development that we take in stride, but often fail to factor into many design decisions when we make our assumptions on what tools to use to solve the problem. It's not just you developing your software, it's the rest of your team, the team that created your software toolkit, the team who created your programming language, ad nauseam; your programming team is now indirectly hundreds to thousands of people, most of which you can not contact or collaborate with, the advances in collaborative software development notwithstanding, the simple fact is, we do not live in a world where we can fix everything we ourselves did not make.
     
    It is in this climate of making large balkanizing pieces of software, that I find myself introspectively thinking, what can be learned, and from where?
     
    And in this context, what am I learning from FORTH?
     
    I will stop here for a moment, and stress, that I do not see FORTH as a panacea for all of the problems of programming. However, it does espouse a great deal of good ideas which should be evaluated when you are looking for ways to solve the problem at hand.
     
    FORTH is teaching me to solve the specific problem at hand. In FORTH, you do not write programs, you create vocabularies. It is in this context that I find FORTH's approach truly brilliant. Every problem must be able to be understood. We as human beings talk about problems, we have words to find if the problem exists, to describe the problem, to find approaches to solve the problem, even to find if our approach is the right one for solving the problem.
     
    Even the largest of problems may have 500 to 1000 words at most, and this approach applies to everything. You may have words to manipulate an image, DESATURATE, COLOURISE, RETOUCH, at the same time, in an automotive factory, you may have words like ATTACH, ASSEMBLE, or CHECK. We take these words, and assemble solutions to a given problem at hand, and regardless of what anyone may tell you, all problems are specific. We often spend too much time, trying to solve specific problems using tools that are far too general for the task, and thus we find ourselves trying to deconstruct the problem and reassemble it in a generalized context, often losing subtlety or nuance that may be required to solve the problem in the first place.
     
    FORTH is not a language, but an environment for making vocabularies specific to a given problem. These vocabularies are then assembled into useful tools for an intended user. Thus by this very definition, a concept of a "standard library" that you would often see in other languages like C is both moot, and superfluous; when it becomes easier to make your own tools to solve the problem at hand that completely fit what you're doing, why would you bother with using a set of standard functions?
     
    FORTH has also shown, that as an environment, it has everything needed to utilize the hardware at your disposal, to solve the problem at hand. There are words for reading and writing to memory, to disk, to graphics hardware, to audio hardware, and more. Because FORTH provides this complete environment, and you are able to create precisely what you need quickly, you do not need this intermediate layer of an operating system to try and make sure things can talk to each other. The individual pieces that talk to peripherals are simple, and map to simple concepts within the language, so the usage of said tools are simple.
     
    The price of all this, is that you, the programmer, live in this place that you've created, alone. But when you can create exactly what you need, exactly when you need it, quickly, is this a bad thing?
     
    I am still thinking it through.
     
    -Thom
  18. tschak909
    Ahhh, some nice DRY evening reading.. The Atari 400/800 hardware manual. Continuing my quest for getting a grasp on the whole system... I found this paragraph in section 2 slightly amusing....
     
     
    Translation: shit man, we know it's possible if you're god's gift to 6502 assembler, otherwise man. Sheesh, we don't know. *Shrug*
     

  19. tschak909
    Not much accomplished tonight, spent much of my time basically testing out the memory clearing routine, and reading both Atari Roots and De Re Atari, trying to get a handle on the conceptual model of the system. Will try some basic player missile graphics stuff tomorrow night.
     
    -Thom
  20. tschak909
    An Observation to anyone who has ever wanted to pursue a creative discipline, but didn't do so because they felt they "didn't have sufficient inspiration:"
     

     
    I've been writing software for the better part of 25-30 years. I have never written games during this period of time, because I didn't think I had a game idea sufficiently interesting enough to write. I have also followed homebrew gaming development since the late 1990s, when I first joined the Stella mailing list (for Atari VCS homebrew coding enthusiasts)...
     

     
    ...and in that time, some 20 some odd years, I had wanted to write a game...
     

     
    ...and finally, on May 31, 2016, that game idea came to me, fully formed, in my head, in a massive flash.
     

     
    But, as I started work on this idea, I realized something: If I had been writing little practice games, all these years, I would have been infinitely better prepared to solve the problems that I am working through now, such as understanding the tricks needed to write a proper display kernel for the Atari VCS.
     

     
    I am now compressing some 20 years of learning, into a much shorter amount of time, which is both necessary, and very painful.
     

     
    So, I beg all of you, if you want to make anything, anything at all, make it, and keep making it, over and over again...you will get better, and when that amazing idea comes around, you will be mentally equipped to be able to actualize it.

  21. tschak909
    I decided one afternoon a couple of days ago, to clear my head from work, and various other projects, to do something else.
     
    I do this from time to time, but what to do? Meh, I'm a hacker. I'll find another hacking project to wipe my brain clean.
     
    I had always found FORTH to be an elegant language, if a bit steep to entry; especially given FORTH's extreme emphasis on efficiency and the alignment of the language entirely to that end. It looks and feels literally like Yoda's brain.
     
    Add these numbers together on the stack, I do. 4 4 + .. yes, that adds 4 and 4 together, and puts them on the stack. It doesn't do anything else, because I haven't told it to do anything else. It merely prints 'ok' .. letting me know i had done so.. Would I type a period '.', or had added a period to the statement, it would have printed the number 8.
     
    Yeah... Odd. Especially if you come from one of the many languages espoused by ALGOL (C, Pascal, Fortran, BASIC, Python, Shell Script). But it does have many advantages:
     
    Grammatically, the language itself is very simple, a line in forth is merely a set of words, terminated by a <RETURN>
     
    What words? you can ask for a list by typing VLIST at the prompt.
     
    Need more words? you can add more words using the colon : word. end it with a semicolon.
     

    : HELLOWORLD ." HELLO WORLD! " CR ;
     
    now I can just type HELLOWORLD and have it output:
     

    HELLO WORLD ok
     
    Couple this, with a variety of words that can easily access the hardware below, coupled with an assembler which can be used to quickly jump into 6502 assembler at any point, and it becomes evident how powerful FORTH really is. I literally see it as an interpreted language with a speed approaching native assembler (which is possible because of the sheer simplicity of the interpreter, coupled with the fact that the stack is used as efficiently as possible.)
     
    So I put up with a degree of ...awkwardness in my own head, trying to shift to its unique way of doing things.
     
    But why this FIG-FORTH?
     
    This particular FIG-FORTH is literally a transliteration of Bill Ragsdale's 6502 FIG FORTH environment, with the relevant patching to make it work with the ATARI editor console, and with the appropriate patching to make it also work with CIO calls to the disk. This particularly makes the disk one big scratch pad, divided into blocks (128 bytes each, corresponding to a sector), and 8 of these blocks, forming together to produce one SCREEN (1024 bytes, which, is set up as 16 lines of 64 characters each.
     
    This FIG-FORTH provides two commands LOAD, and SAVE (and their corresponding cassette equivalents, CLOAD, and CSAVE), to load and save the FORTH environment appropriately. LOAD takes one parameter, the screen # to load, and feeds it into the FORTH interpreter, line by line, as if it had been typed in by hand, and the resulting definitions are now present. SAVE on the other hand, saves the ENTIRE FORTH environment, the interpreter, and its compiled definitions to disk, creating a bootable FORTH environment with all the words that are active at the time the SAVE took place, making this environment very nice for game development. (IMHO)
     
    You may be wondering, does this APX Fig Forth provide graphics etc functions? It does, but in the end, I won't be using them. Why? Because FORTH provides direct access to the hardware below, coupled with an assembler, I'll be able to make my own words specific to what I need, so in the end, I have what I need.
     
    So what's first?
     
    In essence, the APX Fig-FORTH on the disk is all there, but a few of the screens are corrupted slightly, and they need to be fixed. Well, unfortunately, a couple of the affected screens are literally inside the vocabulary that comprise the EDITOR. so what do I need to do? I need to type in the code for the words that comprise the editor, so I can recreate the screens on the disk. Yes, it's a chicken and egg issue., But. as I have implied before, anything on a screen can be typed directly into FORTH, and this is how I will get the editor back so I can edit the screens.
     
    I am using the dump of the screens that Carsten Strotmann (aka cas here on the forums) put here: http://atariwiki.strotmann.de/wiki/Wiki.jsp?page=Extended%20Atari%20FIG-Forth%20APX20029
     
    You can see the results of this:
  22. tschak909
    Wanted to let you guys know, that I am still working on the game. I've been in the process of re-building it in ATASM on the Linux side, instead of using MAC/65 inside the Atari 800 itself. I got tired of being squinched into 40 columns.
     
    My current goal right now, is to refactor and get the invaders display working again, then work on getting the bottom half of the display working, and get player movement working.
     
    I have put together a more comprehensive set of system equates, merging information from the Programmers Card on De Re Atari, and the ATARI OS SYSTEM EQUATES file, from an internal Atari document dated March of 1982. I am modifying the memory map chart that I provided earlier, to more accurately reflect what's being used in the zero page, but it is nice to know that the top 128 bytes of page 0 are available "for user programs"
     
    I have attached a picture of a crater design that I am working on for the bottom half of the background.
     
    Talk to you guys soon,
    -Thom
     
    <-- doing a sketch of the moon background.
  23. tschak909
    Greetings all,
     
    Am nearing the final revision of the playfield layout that I want. I thought I would paste a screenshot so that everyone here could see what I am working on. I have posted two shots, one with NTSC emulation, and one without, it's giving me a reference as to what I need to correct, graphics-wise.
     
    (yes, I am aware of the hanging pixel on the bottom invaders, I am using it as a special reference right now for a bounding box).
     
    <-- with NTSC emulation
     
    <-- without NTSC emulation
     
    <-- source code to screen test.
     
    Some further notes:
     
    I will be using players/missiles from this point on, to provide all the non-scrolling elements (this includes all the background elements, player missiles, the breakout ball, and any additional player missile states not covered here.. I will be needing to do some serious creative thinking to get all this working together....
     
    but knowing that:
     
    I need a gun for the player
    I need a gun for the enemies (maybe a limit of two shooting at once.)
    I need a player for the breakout ball when it enters breakout mode
     
    at the very least,
     
    what do i have left over to draw background elements? (thinking)
  24. tschak909
    I am slowly progressing. I have the first DLI routine set in place to set the colors. Had to use a chain of routines each modifying the DLI vector at the end of each pass. Because I had to make four distinct color changes, I decided to hard-code them into the routine, so that I could minimise the number of cycles being done. I will be modifying the look of the screen layout from here, but now I have something i can work with and mould to look the way I want it to look.
     
    You may have noticed I used a narrow playfield. I did this to be more in line with the aspect ratio of the original game, as well as to give me more cycles per line to do color palette changes. I am glad the idea I had worked. I just need to tweak the colors, maybe make them brighter, and perhaps play with the top score line a bit. I wanted to keep it nice and readable, but if I want color, I'll probably have to use an antic mode 4 line there too, I just wish I could have a border around the whole thing..but I guess that's out of the question....
     
    I have hardcoded and filled the screen with invaders right now, just so i can get a sense of the space of the screen, there will not be this many invaders on screen at once, I know they need space to breathe and move around....
     
    The only real bug I had, was that I had one too few DLI instructions defined in the display list, so the interrupt vectors were being cycled through, one less than should be, giving an interesting stair-step effect, whoops
     
    Now i will design the character for the player....
     
    Screenshots posted below:
     
    <-- Before any DLI treatment, totally monochrome
     
    <-- After the DLI treatment, technicolor!
     
    -Thom
     
    I have also included a dos 2 image with the current source.
     
    Disk Image:
×
×
  • Create New...