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 $
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
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 t
Still reading...and I've come across something in De Re Atari that has me a bit curious. I have cross posted this to the forum, but, I am posting it here too for my journal....
In the book De Re Atari, Chris Crawford talks about moving the player vertically through memory. It's very straightforward...
of special note, is that next to last sentence in the paragraph.
If high speed is necessary, the loop can be trimmed to move only the image bytes themselves rather than the whole p
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 ga
muahahahahaha, THEY LIVE!
After combining the horizontal and vertical scrolling techniques from the other code tests, I've been able to make smooth scrolling produce a nice silky smooth march both horizontally, and vertically.. the march ends once the invaders have marched all the way to the bottom of the screen.....
Next up! Player motion!
-Thom
And now after some initial work, the graphics display for the shields is started... yes.. I will be doing a better job on the graphics soon, I just wanted something in place to mess with. :-P
(can some people help me out on the graphics later?) :-)
I did realise that I will need to kill the shield graphics, the moment the invaders touch it, because of the vertical scrolling technique i am using.. the LMS to the screen memory that holds the shields gets _CLOBBERED_ ... oops, didn't think
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 rea
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 hom
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 n
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)
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
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 Sc
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:
Once I was able to type in the editor, I was able to start re-entering screens from scratch for the FIG-FORTH.
To do this, I am referencing three different sources:
* Carsten's Atariwiki containing the SCREENs for Enhanced Fig-Forth 1.1
* William Ragsdale's FIG-FORTH Installation Guide, detailing the bootstrapping of the original 6502 FORTH, which also contains info for the editor.
* the APX-20029 Extended Fig-Forth disk, as some screens weren't in Carsten's dump, but are required for
I am resuming work on Salmon Run, I had to calculate 255 possible random combinations for playfield state, I did it all inside a text file, separated into columns in which I first drew the binary patterns, and then calculated the PF1, PF2, PF3, and PF4 data accordingly....
A snippet of the graphic notepad file:
RIVER1 RIVER2 RIVER3 RIVER4
PF1 PF2 PF2 PF1
Normal Reversed Normal Reversed
---------------------------------------------
00 11000000 00000000 00000000 0000001
After beating my brains out on what eventually turned out to be a relatively simple solution, I have been able to implement smooth scrolling in the game (as well as work on the lives display for player 1 and 2) .. it turns out i need to do some slight recalcultion of the river display because I am _WAY_ over my visible line calculations.. No matter, just a few adjustments which i will take care of tonight....
I also still need to fix the scrolling algorithm slightly (move the window boundary
Hello guys,
Have been refining the shields a bit, and have created a string of DLI interrupts that do RANDOM color changes to COLPF2 on a per scanline basis, creating an electrified pulse effect.. I will refine this, later...but the DLI code is in place. I just need to do a two pronged subroutine that clears the LMS and mode E and DLI bits, and do a slight change to re-vector over the additional DLI routines when not in use. Basic missile shooting is sort of in place, I need to make it track
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
I am currently working on the player's missile routine, and as soon as it is debugged, i will be applying it to the enemies as well.. I will investigate using player and missile sprite multiplexing to get more than say, two enemies firing at the same time. But until I actually get to that point, I am learning things by trial and error, and looking at others code.
-Thom
Starfield Update:
Definitely better this time, I've tightened the kernel routines a little, and made sure the starfield happens inside horizontal playfield borders. But I need to be able to fix the streaks happening during display... If I enable the WSYNC in the kernel code, the stars stabilise and the streaks stop, HOWEVER, there is a big black hole on the lower left corner of the screen.. WHAT GIVES? WTF? ... ok well, I am tabling this for now, and continuing on.
continuing
Evening fellas,
I took my first crack at a starfield tonight, it still needs a _CRAPLOAD_ of work, the stars flicker, but I do know my technique will work with the proper timing. I will try to tie VCOUNT in and see if I can carefully time the stars to appear on the correct scan lines without flicker, I'm going to try to keep stars down to one per line..maybe I can make something look good... if worse comes to worse, I will try to use two missiles for this, but I don't want to waste precious
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
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
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord