jacobus

OK, here's the video - definitely some rough edges but should be a good demonstration of basic game play. After playing a full year a regular speed I'm think of either speeding up the entire game, or possibly making some seasons faster than others.

Atari 8 Bit. I plan to record a demo video very soon.

This is a project I started (in BASIC) way back in the early 80’s and put aside for many years. I recently found the original code, and after having a good laugh decided it would be an excellent project to re-write in Quick. The concept is simple – you’re an 18th century farmer dropped onto a forty acre/field grant of land and you have 50 years to try to survive and if possible thrive. In the process of surviving you will have the opportunity to develop the land, raise crops and animals, build the necessary infrastructure, weather disasters, and if you’re both lucky and smart - build some wealth. This game is intended to be a simulation and thereby has some relation to reality. It is not intended to be easy or even fair. Farming is a difficult proposition nowadays and a few hundred years ago it was too often an extremely labour intensive path to starvation. The game tries to mimic some of those former realities and provide a challenging experience. Warning - it will take a long time to play. Currently each year takes approximately 30 minutes of real time – so for a successful game you’re looking at an investment of 25 hours or more. I only recently sped things up from the 1 hour real time to 1 year of game time ratio I had set, so things could have been a lot worse! During each year of game time, there will be moments of frantic activity where you try to do many tasks in a short amount of time – such as planting and harvesting. Other times you’ll be sitting around watching things slowly develop and hoping you’ll be able to harvest enough crops before winter. The land will need to be closely managed – swamps drained, wells dug, fields fertilized, wood lots cut and replanted, barns and silos built, animal stocks fed, and disasters managed. The gameplay will consist of a graphical representation of the farm, along with an extensive menuing system to direct your actions. Crops will grow as the seasons cycle and their readiness to harvest will be clearly visible. Natural disasters such as hail, wind storms, fire, politicians, and plague will strike without warning. Winter comes and destroys any unharvested crops and tests the farmers ability to lay way sufficient food.   The Environments Four types of environments are available in the game. Each have unique characteristics which should be considered carefully before developing. Forests With 25 per game, Forests account for more than half of the land area. Forests contain valuable wood and although they can be easily ploughed under and planted, forests grow slowly and are vital building products. Grasslands Grasslands are the obvious first choice for development. They can be easily ploughed under and planted. Grasslands are somewhat limited, and you will find only 10 of them in a game. Swamps Four swamps inhabit the landscape in your game. Each of them will need to be drained before they can be utilized. In order to drain a swamp, you will need to build a very expensive Windmill. Deserts A single desert exists in your game at the beginning. Deserts are fields with no water and zero fertility. In order to develop a desert you will need to dig a well and spend time spreading fertilizer. Be warned, any field that is over used and dry out and become a desert as well. Soil types affect how well crops develop and the risk of damage to your equipment. Soil types are: Swamp Too wet, you must build a windmill to drain Rocky Dangerous to plough – you may break your plough Clay Poor growing Sandy Poor growing Rich Better growing conditions Loam Best growing conditions Desert Nothing grows, must be fertilized and have a well dug Along with soil types, each field has a state that affects what can be done with it. These states are: Fallow Untouched, ready for work Ploughed Initial ploughing has been done, field can be planted but will not produce well Harrowed Field has been harrowed (must be ploughed first). Optimum condition for growing Planted Field has a crop planted Weeded Field has been weeded – improves growing conditions Harvest Field has been harvested, will return to fallow over the winter

Thanks very much for sharing, that is an amazing bit of history! I had to laugh at Curt's initial reaction of "Mine! Gimme!" Priceless!

Done! Sorry about that!

Success!!! I rewrote the code to perform the ROM->RAM copy operation using smaller (2K) blocks as per Bob_er's excellent instructions. The code now allows the entire ROM code to be successfully copied to RAM (skipping $D000-$D7FF), flipping back and forth every 2K. The problem turned out to be my original code was trying to copy too much data at a time. A big "Thank You" to everyone involved! I have included the working QUICK code for reference. Quick-Sourcetext D1:PORTB.QIK ---------------- Length: $0DF6 Free : $6975 ---------------- ************************************ ************************************ BYTE [ RTCLOK=20 SDMA=559 CONSOL=53279 PORTB=54017 NMIEN=54286 A,C BLOCK ] WORD [ ROM ] ************************************ *** MAIN LOOP *** ************************************ MAIN BLOCK=0 ROM=49152 ;start of ROM REPEAT IF BLOCK<>2 ;copy unless D000-D7FF PORTB=255 ;turn on ROM PRINT("Copying block # ",BLOCK) .JMOVE(ROM,1536,2048) ;copy 2K *sync with VBL C=RTCLOK REPEAT UNTIL RTCLOK<>C NMIEN=0 ;turn off interrupts *issue PHP,SEI INLINE [ 8,120 ] PORTB=254 ;turn off ROM .JMOVE(1536,ROM,2048) ;restore block *issue CLI,PLP INLINE [ 88,104 ] NMIEN=192 ;restore NMIEN ENDIF ADD(ROM,2048,ROM) ;next 2K block BLOCK+ UNTIL BLOCK=8 PRINT("ROM code restore complete") *test POKE(52256,0) ;write 0 to known loc PEEK(52256,A) ;get result IF A=0 PRINT("Success!") ELSE PRINT("Failure") ENDIF ENDMAIN ************************************ ************************************ ************************************ PROC JMOVE IN WORD [ SRC,DEST,LN ] LOCAL WORD [ MEM ] BYTE [ Z ] BEGIN MEM=0 REPEAT PEEK(SRC,Z) ;read source byte POKE(DEST,Z) ;write dest byte ADD(SRC,1,SRC) ;inc source counter ADD(DEST,1,DEST) ;inc dest counter ADD(MEM,1,MEM) ;inc byte counter UNTIL MEM=LN ENDPROC

I still need the functionality of the ROM - I just wanted to be able to take advantage of some of the unused portions - such as the International Character set space. Thanks for the link - I checked it out and with my limited assembly skills the code seems to be doing everything I do with the exception of updating the NMI vectors - which since I'm not changing anything in the ROM, should not need to be updated. The code you list here - it looks like it compares the value of $14 (APPMHI) with itself and then calls the routine stored at $FFFE - is that correct? If I have VBI's already disabled, is this required? thank you!

The runtime consists of a number of routines that extend the basic functionality of Quick's command set. They are loaded to $4100 and are called from the main Quick program as needed. The actual Quick program loads and runs from $5000. Limited experimentation suggests that a Quick program that does not call any of these extended capabilities can do without the runtime altogether. I do issue SEI before setting PORTB. Thanks for the tip about processor status - I tried PHP / PLA as well - no dice! thanks very much for the suggestions - sadly it's still blowing up on me.

Thanks - I'll be sure to set it manually from now on. I need a bit more storage for some data - even having access to the 1K that holds the alternate character set would make a big difference. Run time sits at $4100 and the program itself starts at $5000 (for a maximum of 20K) As long as I don't need DOS (and I don't) I have free access to memory from $400 to $40FF as well as $A000 to $AFFF (additionally I can take up space at the end of program RAM and even part of the variable table) I have to believe the issue is with the environment left by the compiler. As mentioned once I compile to an executable and make the 64K.XEX the first segment, it runs fine. For reference, I've attached a PDF of the English manual. I am working on an revision with more complete instructions and examples. The memory map is fairly well documented, a heck of a lot of experimentation on my part has revealed more.

I have access to the source code, so I'll be sure to change that before going live with this project - thanks!

It's a stock 64K 800XL. I have some experience bank switching within Quick (the cartridge version of Dungeon Hunt) so I'm pretty sure that's not he problem either. The good news is that I was able to add the small program from Mapping the Atari (attached) as the first segment in my executable so my (compiled) program can use the extra RAM. Bad news is that I can't get the ROM/RAM switcher to work within my development environment - making testing a little more challenging and time consuming. Right, yes, thank you - I knew that! Really! (cue sound of head being banged against desk). :-) I did try removing that line in hopes that the call itself was causing my issues - sadly not. Thank you anyway! 64K.xex

I changed it to overwrite the International Charset at CC00 - same result :-( Good point about NMIEN, I set that to $40 and tried again - same result. Hi Jon I wanted to be sure I was not over-wring the first byte of page 0, change to $2800 - same result Good question about the runtime - I don't think so - the compiled program works fine on a 48K 800, and the manual states that the first part of that RAM (C000 to CBFF) is used by the integrated editor. I beginning to think as Jon hints that it may be something with my environment instead of something boneheaded on my part. Interestingly however, I can use the ROM switching code provided (page 212 I think) in the Revised Mapping the Atari to accomplish this - if - I run it as an executable before launching my program. Any attempt to incorporate the MtA code directly into my program fails in the same why this example does.

Thanks to everyone for their replies, the assistance is very much appreciated! Sadly, I'm still having issues... Things I've tired/eliminated -Memory at $600 is unused (I've tested this without setting PORTB and have no issues) -I've added SEI and CLI instructions to the code - does not help -Tried with and without setting IRQEN -I am masking the PORTB to set it properly I've attached a sample .XEX compiled from the attached code. As mentioned if I remove the statement that sets PORTB, the code runs fine. No matter what I do beforehand, setting PORTB is lethal to the program. Quick-Sourcetext D1:PORTB.QIK ---------------- Length: $0DF6 Free : $6975 ---------------- ************************************ ************************************ BYTE [ PORTB=54017 SDMA=559 NMIEN=54286 IRQEN=53774 CONSOL=53279 A,B,C ] WORD [ MEM ] ************************************ *** MAIN LOOP *** ************************************ MAIN B=NMIEN PRINT("Press START to begin") REPEAT UNTIL CONSOL=6 BMOVE($C000,$600,$1000) BMOVE($D800,$1600,$27FF) PRINT("ROM to RAM copy complete") NMIEN=0 PRINT("NMIEN disabled") INLINE [ 120 ] PRINT("SEI issued") EOR(PORTB,1,C) PRINT("") PRINT("Press START to set PORTB=",C) REPEAT UNTIL CONSOL=6 PORTB=C PRINT("PORTB set") BMOVE($600,$C000,$1000) BMOVE($1600,$D800,$27FF) PRINT("ROM code restore complete") INLINE [ 88 ] PRINT("CLI issued") NMIEN=B PRINT("NMIEN restored") *test CLR(192,4) A=0 MEM=49152 REPEAT PEEK(MEM,B) IF B>0 A=1 ENDIF ADD(MEM,1,MEM) UNTIL MEM=50176 IF A=0 PRINT("Success!") ELSE PRINT("Failure") ENDIF ENDMAIN ************************************ ************************************ ************************************ PORTB.XEX

This problem is really driving me nuts. I can only assume I am missing something really stupid and obvious, but I sick and tired of banging my head against it… What is the standard “correct/failsafe/easy” way to activate the upper 16K bank or RAM on an XL ? I’ve been trying to do this within Quick and keep running into a brick wall. I use Quick’s copy command BMOVE(Source,Dest,Length) to copy the ROM to a safe place in memory, then I turn off interrupts (via NMIEN=0 and IRQEN=0) and then disable ROM by setting bit 0 of PORTB to 0. Then I copy the ROM code back to its proper location. At some point during this operation the system crashes – with the ROM only partially restored. BMOVE($C000,$600,$1000) BMOVE($D800,$1600,$2800) EOR(PORTB,1,C) NMIEN=0 IRQEN=0 PORTB=C BMOVE($600,$C000,$1000) BMOVE($1600,$D800,$2800) What the heck am I doing wrong???

With just over 2K left I though ZA could use a little more variety, so I added what I call the Speedy Zombie. As the level is being drawn, I randomly (with a bias towards the deeper playfield), pick one infected zombie to be the speedy. This Zombie gets much more attention from the program and therefore moves much faster. He/she actually gets 1 movement for each movement of every other living NPC. Therefore with 50 NPCs active, the speedy moves 50 times more often than any of the others. The standard proximity, damage and health rules still apply to the speedy. When killed, the game will pick another infected to promote to speedy. Should provide a nice surprise every now and then.

I released an early (too early from some of the reviews) version of this game around six months ago. Since then a lot of things have changed – more of the game runs in the VB allowing for much smoother animations and responsiveness. If a mob is hit with a non-lethal attack (happens more in later levels) they will get knocked back in order to provide some visual feedback to the player. The player’s weapon is shown, and in many cases a muzzle flash accompanies each firing of the weapon, the grenade explosion looks better and very importantly the end of level calculations are much improved allowing for a logical progression between levels. From a playability point of view the most important change is likely that the player’s character now automatically aligns itself to the underlying character grid – this means that the weapons now have a much higher chance of hitting the mob you think you’re aiming at. ZA is a bit of a departure from my usual techniques of having pre-defined maps and offloading as much of the graphics and other data as possible to the disk. Despite having everything onboard in a single executable, I still have a fair bit of memory left over. Procedurally generated playfields are much easier to deal with! Not sure what else I need to add to the game - I’m considering allowing the flame thrower to start fires in the buildings and have them slowly consumed. Although this would be a cool effect, and fun to code, I’m not sure how much it would add to the game. Perhaps I should save this for some future firefighting game … hmmmmmm ZA is almost ready for release – many many thanks to Stefan Both for his testing and motivational support! Stay tuned!

I was all set to work on the maps last night and then decided that the mobs needed a death animation. Good news! Mobs now have a 4 frame death sequence. Bad news, I'm running out of places to stuff graphics data - this time I had to raid the bottom of the stack and stuff 64 bytes in there. Worse news, the maps haven't progressed.

Almost ready for primetime, Imp is now mostly lacking in completed levels. I had originally planned for 10 to 12, lowered that to 8 and am finding an infinite number of distractions that prevent me from working on them. (all the levels are roughed in right now, I'm working on populating the extras - mana, barrels, arrows, etc - all the pickup stuff). Using Excel and some custom VB code makes it a lot easier, but it's still a grind having to place every object and then go back and test how things are balanced. The attached screen cap shows some walls, trees, mobs and other pickups. Perhaps I should plan to enter Imp in the next ABBC contest - that would give me a good deadline. Possibly a better solution would be to stop branching off onto other projects (Bruce, Warcow, Squirrel, etc). I have around 750 bytes free - not sure what other features the game needs - it could benefit from some more/improved sounds of course.

Part 1 My household's content of quivering lips and sad eyes finally reached critical mass recently and prompted the purchase of a pet. Since mom is deathly allergic to anything with fur (and the kids are too, but they'd never admit to it), we had limited choices. Fish are fine but they don't seem to to enjoy cuddling very much, and birds are too damn noisy. We finally settled on a Bearded Dragon - silent, sedate and requires little or no parental intervention. Bearded Dragons are native to Australia, and as that I have it on good that everyone from Australia is named either Bruce or Sheila, we named the pet Bruce. Part 2 I hate platform games. Mostly (entirely) because I really suck at them. I had a planned a platform game for a long time but had not really given it much effort since I really didn't feel a connection. After watching Bruce chase after crickets a few times, I began to rethink the platformer idea. I envisioned Bruce climbing the walls in search of either lunch or escape (yes, I know Bearded Dragons cannot climb walls, they leave that sort of nonsense to gekkos, but please allow me to indulge in a little artistic license). Since the pinpoint jumping part of platformers is what really bugs me, I thought I could try something a little different. In this game, you control Bruce (who else), in his quest for dinner. The walls consist of various surfaces - some slippery, some not, some completely different. Bruce will have to navigate each room while avoiding falling to the floor. Path-finding, timing, puzzle solving and patience will be key - not impossibly accurate jumps. Basic control and movement are in place, I still need to do a lot more work on animation, different surfaces and map layouts. The playfield will be an 8 way scrolling map consisting of 8x6 tiles - 16 wide by 12 high. Bruce is animated with three players. In the linked video, Bruce slides down the purple bar and gets pushed up the textured tiles. More to come...

I'm the GTA as well (Oakville) ... would you be interested in sharing the drive?

Awesome, thank you!

Very good question! I hope that my kids will each take something meaningful to them, most of the rest - with the exception of my complete sets of Infocom Folios and Synapse boxes (I think I've convinced my wife that they are valuable enough to hold onto) will likely go to this place: http://www.pcmuseum.ca/

I can't remember if it was RoH or ABatFT, but during play if your character was killed, you could press System Reset and the game would continue at the exact same spot - except with your character restored to life.

Thank you! I'll send you a copy of the next stable release!

Hi Stefan! I think you are playing an older version - before I had visible weapons. The new version correctly shows the weapon on a PAL machine (at least under emulation) and the Zombies do appear red! Thank you very much for your beta test offer, I will take you up on that!