Just Jeff

Nice compliments! Some of you guys are on here too.. Also another screen is roughly laid out. Sky Scraper..

OK Here's the latest .bin.. I've split out the passenger bands from the pad bands so I'm not rewriting them every time. Made an off-center rhombus and a cloud. I also created some more pad bands from the "Teleports" screen. These pads are really straight-forward so I'm going to use them as placeholders to build remaining screens' logic (but not graphics.) Also notice I'm planning on building "The Beach" in reverse due to early HMOVE limitations. SpaceTaxi.asm.bin

I was asked to display Blocks at a local arts festival and it looked like this the whole time, once they had their fill of the quilts of course.

OK Thanks Darrell!.. The unrolled kernel seems to be key. I think maybe I can use that with no RAM maybe. I pushed the dashboard aside for a bit while I figured some other stuff out. I decided to add a center pad on the screen, knowing it would force me to think through a lot of other things- which it did. I had taken some shortcuts which at this point were roadblocks. So at this point: The passenger knows where the taxi is when on the pad and walks to or from it instead of wandering. The first 3 screen layouts vary in design, and the number of trips varies as well, and the tables are there to change all the screens eventually. Screen 1 has a decorative feature and a name! Note: on the attached .bin, screen 2 has 2 pad #1s. So if the passenger calls for pad #3, its the pad at the bottom of the screen. Also, I made the game unwinnable just for fun- temporarily. That's all for now SpaceTaxi.asm.bin

Thanks! That certainly works and I'd love to add all those cycles too. I have the RAM and ROM, but there is another timing issue. Prepping the 30 bytes makes the dashboard fat. It looks like this adds 210 cycles- right? A short while back I put some effort into doing the opposite- undid pre-merging RAM and adding those ORAs in the score area. So, I need to revisit that and see where I can gain those cycles or accept the thicker dashboard. Maybe a combo of the two like you said. Maybe convert the loop to 5 separate lines, ldy immediate load on each line for the index. I might be able to get away with pre-merging only one of the characters. I also wonder what I would put in that right space.. Thanks again! -Jeff

New .bin attached Alright.. I settled on reducing the display down to 8 and 32 and I suppose I'll use missiles for something on the other side of the score. The number of taxis remaining is now displayed and a basic game over state now exists. If you crash 3 times the game ends and you'll see "The End" Displayed ("Game Over" wouldn't fit). To start a new game you can hit the reset switch or the fire button for the other joystick (f key in Stella). Enjoy! SpaceTaxi.asm.bin

Good afternoon.. Wondering if anyone has a solution to this.. .bin attached, though the dashboard is not working properly.. I've been working crashing with death plummet (which is largely done- try it), number of lives, game over etc. But I did get hung up on trying to change the bottom half of the dashboard so it displays number of taxis remaining and am giving up on it unless someone knows how to fit it in. If you do, please let me know: I split up a 48 bit display so it is a 8-32-8 bit display seen below. Seemed like it wouldn't be too complicated but I can't seem to be able to get it to work. No combination of VDELS, preloads, x-register, etc seems to be able to get it past the fact that you have two copies of the same player on each end and it makes VDEL more trouble than help. (in this case P0, P0, P1, P0, P1, P1.) Note: I have some complicated loads, but there's probably a way around that if necessary.. ;preloads ;lda (PadPtr1),y ;5 5 Taxis remaining ;sta GRP1 ;3 ;lda (PadPtr4),y ;5 5 100s and 10s ;ora (PadPtr5),y ;5 5 Combine the 100s and the 10s ;sta GRP0 ;3 8 .kernelLoop2 ;Bottom half of the dashboard sta WSYNC ;3 0 lda (PadPtr1),y ;5 5 Taxis remaining sta GRP1 ;3 8 lda (PadPtr4),y ;5 13 100s and 10s ora (PadPtr5),y ;5 18 Combine the 100s and the 10s sta GRP0 ;3 21 lda (Sprite1),y ;5 26 Dollar-digit sta GRP1 ;3 29 lda (Sprite1+2),y ;5 34 Pennies ora (Sprite1+4),y ;5 39 sta GRP0 ;3 42 After 41 lda (Sprite1+6),y ;4 46 Ones-decmal sta GRP1 ;3 49 lda (PadPtr2),y ;5 54 Duplicate Taxis remaining for now sta GRP0 ;3 57 dey ;2 59 ;cpy #0 ;2 61 bpl .kernelLoop2 ;2/3 63/64 Thanks! -Jeff SpaceTaxi.asm.bin

Thanks I did find your blog previously and have looked through it but its written in a way that I am not familiar with so it's slow going. Also received the file you sent with similar result. I really appreciate the help so far. Thanks!

I'm looking for some simple or commented code examples of 3E+ Bank switching. Can anyone point me to some?

Awesome! I did not occur to me that code will not work in different segments but I suppose that's not a big issue. In fact I think the arrangement I suggested would work that way. Why won't code run in deferent segments? Program counter I suppose? Could you please point me to some example code?- like maybe a small shell that is set up with the RORGs and macros, etc Or is it easy to just set up myself? Oh and.. This will all work on Stella, PlusCart, Harmony, as well as actual cartridges I assume? Thanks again! -Jeff

@Thomas Jentzsch Thanks! That does look a lot more versatile. One thing that is unclear to me is- can you combine these? Its said that its a "combination", but to be clear, I could have?: D7 D6 D5D4D3D2D1D0 0 0 x x x x x x switch a 1K ROM bank xxxxxx to $F000 0 1 switch a 512 byte RAM bank xxxxxx to $F400 with write @ $F600 1 0 switch a 512 byte RAM bank xxxxxx to $F800 with write @ $FA00 1 1 switch a 1K ROM bank xxxxxx to $FC00 And that once I write the banks to $3E and $3F one time, these segments stay there and stick together and act as one single 4K space until I write to one of them again? Using the above arrangement, I envision something like: $F000 VBLANK and Overscan $F400 Customized kernel bands assembled in order in RAM $F800 Unpacked Voice Data (Bytes split in half, left nibbles moved to right nibbles of next byte) $FC00 Compressed voice sample currently being accessed This is possible?

OK I'm not familiar with those types of bankswitching. Do I have this correct?-- I could have my current voice data in the lower 2K area as needed (these will need to be switched) The upper 2K could contain game code that fetches from the lower 2K area with no bankswitch per each fetch? The description I saw mentioned JMPs and JSRs but didn't specifically mention what I would want- indexed loads and indirect addressing to the lower bank. Also, one person called it "RAM" is there RAM? Can I have multiple upper banks? The game code wouldn't fit into a single 2K upper bank. I currently have 4K for VBLANK and Overscan, and 8K reserved for the play kernels alone.

Thanks- this is a technique I wasn't familiar with, but it doesn't work here.. Looks like you are expecting y values of 0 to 15 but these bytes are 0 to 255. Probably that's what you meant when you mentioned a 256-byte table being necessary? Alternatively, I was able to get this code to work by loading the accumulator with Voice+32, then AND #$0f, then TAY, but at that point it saves no time. Thanks! That's some crazy code, but it does work. Note- it also saves 2 bytes. Though I don't think the comment "Strip the right nibble of the RAM value" is correct- values are left in there, being various xors of one of the preserved RAM nibbles and a used voice nibble. So to answer your questions.. The right nibble of voice- The right nibble is the only relevant nibble when it comes to AUDV1- but I'm sure you knew that. Here is an abridged, two byte explanation of what I'm doing: Note below, VoiceCounter and VoicePointer are really the same counter- just a typo. Voice ds 1 ;Left nibble stores right half of FrameCounter while in kernel FrameCounter ds 1 ;Can be any value. Left nibble is always FrameCounter's left nibble. Right nibble borrowed for voice nibbles ;So two pieces of voice data fit per 1 byte of RAM reserved.. ;If FrameCounter's value is at, for example $A2, then for the kernel split that up so ;Voice = $20 and FrameCounter = $A0. This is OK becasue FrameCounter is not used in the kernel ;Jump to a voice data bank ;The voice data is 4 bits, played right nibble first, then left nibble second ;Load a byte of Voice Data and store each nibble in the right nibble of Voice and FrameCounter lda VoiceByte and #$0F ora Voice sta Voice lda VoiceByte lsr lsr lsr lsr ora FrameCounter sta FrameCounter ;Complicated here, so the kernel is fast and simple Kernel ;This code every 4 scan lines dec VoicePointer 5 5 ldx VoiceCounter 3 8 lda Voice,x 4 12 sta AUDV1 3 15 ;or maybe tya 2 2 ;use the kernel index lsr 2 4 lsr 2 6 ;multiply by 4 tax 2 8 lda Voice,x 4 12 sta AUDV1 3 15 ;Then when the kernel is done, put FramCounter back together Secondly, duplicating the kernels is impractical since there are 24 screens and multiple kernel bands, and 8 voice data banks. I'll probably end up with 100 to 200 kernel bands then duplicated on 8 banks = 800 to 1600 kernels. I'll consider more flexible bank switching, but still I don't think that will help me inside the kernel. How am I doing? -Jeff

Good afternoon! Two things... Firstly, YouTube suggested this video to me. Freaked me out- in a good way: Secondly, I finally worked up the nerve to begin the voice code this morning after I had an epiphany... Bit-Packing! I believe I need to run through 50 AUDV1 register changes for every frame shown. That's just in the kernel section which should be the most difficult part. Since the data is spread over multiple banks, its impractical to grab any data while in the kernel, therefore it must be grabbed in VBLANK and Overscan, then stored in RAM and used every 4 scan lines while in the kernel. But 50 bytes of RAM seemed impractical and wasteful, if not impossible. Finally, this morning it occurred to me that I can get away with 25 bytes if I take existing RAM that is only used outside the kernel and store the right nibble of it in the left nibble of 25 bytes of designated VoiceRAM. In this way, 50 right nibbles are available for use for the price of only 25 bytes. Oh right- it's important to note that only the right nibble is used by the Atari, so the left nibble will be ignored and can therefore still be used to store useful data for other things, which makes this whole scheme work. Additionally, 25 is on the high end. With some code changes, there are some bytes that can get wrecked entirely while speech is happening and therefore, don't even need the swap space (VoiceRAM). Also, some bytes don't need two nibbles to begin with, in those cases the data can simply stay in the left nibble full time. After these code changes, I think I can bring the dedicated bytes needed down to 19 if necessary. So here's my bit packing and unpacking code. I'd be curious to know if it could be more efficient. It does run in the time allowed as is but then again, all this is doing is splitting the bytes (in preparation for grabbing voice data), then putting them back together after the screen is drawn. The RepackingBits looks a little unwieldy to me. What do you think? ;in Bank 1 UnpackBits SUBROUTINE ;added in TypicalPlayLogic.asm ;Sound registers only use the right nibble. So preserve the right nibble in the left nibble of VoiceRAM while ;in the kernel. Then restore it when out of the kernel ldx #31 ;This can probably be reduced to about 19 with some code modifications. ;I have 10 RAM bytes that can probably be trashed during speech and 3 RAM bytes that are single ;nibbles so they don't need swap space. Additionally, I probably could have used #25 here to get ;through the kernel to begin with. .ramSplit lda Voice+32,x ;This area of RAM will be borrowed for voice asl asl asl asl sta Voice,x ;The right nibble is stored in the left nibble of Voice. Right nibble is zero which is convenient. dex bpl .ramSplit rts ;Return, then jump to a voice bank ;Added in Overscan RepackBits ;Restore the left nibble of Voice, to the right nibble of Voice+32 while preserving that left nibble. ldx #31 .ramCombine lda Voice+32,x and #$f0 ;Strip the right nibble of the RAM value sta Voice+32,x lda Voice,x ;Right nibble of Voice+32 was stored in left nibble here. lsr lsr lsr lsr ora Voice+32,x sta Voice+32,x dex bpl .ramCombine rts Any suggestions? -Jeff

AtariAge Day went nicely.. Here's a link to the Blocks segment. Also, I've attached some visual aids below: Here's my original cut and paste mockup based on Surround: Jeremiah's first iteration of the heads-up display: Jeremiah marking up one of Dean's images. View of the game in debug mode. Only three color registers are available, but they are interlaced to give some flexibility when writing to them. Only five objects are used to make the 64 "objects". Two missiles, two quad-sized players, and PF2 are turned on and left on, saving the time necessary for writing all the colors. Note the comb lines on the left. These are due to the HMOVEs that draw the zero. Also note, by its nature, TIA is really drawing three zeros so the other two have to be masked with PF1 when its time for that:

OK.. I've gotten it back down to 192 scanlines and also the fuel gauge functioning now. .bin attached Thanks Thomas... I converted several of the loads to this. I wasn't able to do one of them on the top half (with the fuel gauge) because there isn't enough time. I also created another set of digits 0-9 followed by a decimal in ROM so I could do a single load on those. And I have the same thing for dollar sign with one digit. .kernelLoop1 ;Top half of the dashboard sta WSYNC ;3 0 lda (PadPtr5),y ;5 5 sta GRP0 ;3 8 lda (PadPtr4),y ;5 13 sta GRP1 ;3 16 lda (Sprite1+6),y ;4 20 sta GRP0 ;3 23 VDELP0 is on lda FuelGaugeNUSIZ,y ;4 27 sta ENAM1 ;3 30 sta NUSIZ1 ;3 33 After ~31 lda (Sprite1),y ;5 38 ldx #RED ;2 40 stx COLUPF ;3 43 $34 Turn red after 42 sta GRP1 ;3 46 lda #GREEN ;2 48 $B0 SLEEP 3 ;3 51 sta COLUPF ;3 54 lda #3 ;2 56 3 players close sta NUSIZ1 ;3 59 store after ~55 lda Sprite3,y ;4 63 dey ;2 65 sta GRP1 ;3 68 bpl .kernelLoop1 ;2/3 70/73 -break- .kernelLoop2 ;Bottom half of the dashboard sta WSYNC ;3 0 lda (PadPtr4),y ;5 5 ora (PadPtr5),y ;5 10 Combine the 100s and the 10s sta GRP0 ;3 13 lda (Sprite1),y ;5 18 sta GRP1 ;3 21 lda (Sprite1+2),y ;5 26 ora (Sprite1+4),y ;5 31 sta GRP0 ;3 34 VDELP0 is on SLEEP 7 ;7 41 lda (Sprite1+6),y ;4 45 sta GRP1 ;3 48 dey ;2 50 bpl .kernelLoop2 ;2/3 52/53 SpaceTaxi.asm.bin

Well I have those 4 indicator lights on the same row which I have not even started on. They require setup as well as time on those lines so I don't know what's going to happen there either. To make your idea work, I need to also add some ORAs- right? Indirect load left nibble, ORA indirect address of right nibble? Thanks for pointing out the ANDs.. I'll change that.

Nothing really. My plan at this point is to load up the most time consuming 10 bytes in vblank and just hold on to it during the kernel. That would be the cents at the right of the decimals for both the tip and the score. Its the most time consuming because two nibbles need to be ora'd with each other then all stored as a sprite in RAM. That's the best I could think of. I think the rest could be set up inside the dashboard. What do you think?

Thanks! Yeah that's going to take some effort because the RESP1 is taking place at different times in different locations. The taxi's X position will need to be translated into distance from each RESP1, not to mention, converted to early HMOVE values. So, when each screen is done, that's probably when I'll work on those. Right now I simply AND the FrameCounter and store it in HMP1 so the movement is only just to make him wander around until he collides with the taxi. It will have voice for sure and I posted an example here some time ago, but like many other things, its probably something that is better done later. I plan to get a working gas gauge and a death plummet crash sequence next. I have the Tips and Score fields functioning now, so we're finally making some money: Its taking too much kernel time though. I'm at 267 scan lines now- 26 of them for the dash. And you can see the dash is a little distorted now as a result. I'd really like to reduce the dash height to 24 scan lines. The issue centers around setting up the digits for the Tips and the Score. Does anyone have any ideas? ;Setup line #2 ;Load up RAM buffer with either pointers or graphics lda Tip ;This is the Dollar sign and the 10s digit for the tip and #%11110000 lsr lsr lsr lsr tay lda DollarGfxLo,y ;Store a pointer which will be accessed while drawing sta Sprite1 lda DollarGfxHi,y sta Sprite1+1 ;This is dollar 1s digit before the decimal. The decimal will be manually added lda Tip and #%00001111 tax lda DigitBlankGfxLo,x ;Store a pointer which will be accessed when loading a RAM buffer sta Sprite1+6 lda DigitBlankGfxHi,x sta Sprite1+7 ;Load and combine cents lda Tip+1 and #%11110000 lsr lsr lsr lsr tax .loadCents10s lda DigitBlankGfxLo,x ;Store a pointer which will be accessed when loading a RAM buffer sta Sprite1+2 lda DigitBlankGfxHi,x sta Sprite1+3 lda Tip+1 and #%00001111 tax lda BlankDigitGfxLo,x ;Store a pointer which will be accessed when loading a RAM buffer sta Sprite1+4 lda BlankDigitGfxHi,x sta Sprite1+5 ldy #4 .loadSprites ;Load the RAM buffer with full sprites lda (Sprite1+2),y ;Load one of the penny digits ora (Sprite1+4),y ;Combine it with the other sta Sprite3,y ;Store the combo lda (Sprite1+6),y ;Load the single dollar digit in front of the decial sta Sprite2,y ;Store it, add the decimal to right nibble later dey bpl .loadSprites lda #%00000010 ;Add the decimal ora Sprite2 sta Sprite2 ;Set up the passenger's requests lda #>ShoutOuts ;Set the big end of the pointers. Don't go over one page. sta PadPtr4+1 sta PadPtr5+1 ldy #11 ;Load the offset for Hey! lda PassengerState bmi .storePtr ;If PASSENGER_HAIL, then store the 11 (Hey!) ldy #10 ;Load the offset for blank cmp #PASSENGER_ONBOARD ;Is the passenger onboard bne .storePtr ;If not, then don't display anything ldy #9 ;Load the offset for Up! just in case lda StopNumber ;Then check for which stop bmi .storePtr ;#$ff means the screen is done, so store 9 for Up! ldy CurrentTarget ;Otherwise, pick the message for the next stop .storePtr lda ShoutOuts4,y ;This is the table for the left half of the word(s) sta PadPtr4 lda ShoutOuts5,y ;This is the table for the right half of the word(s) sta PadPtr5 SpaceTaxi.asm.bin

Awesome! You bought it? Maybe you were the first! I have no idea. Thanks!

Who is going to PRGE? I'd really appreciate pictures or video of Blocks and setup at the AtariAge Booth! Would anyone be able to do that for me?

Greetings, New .bin attached.. I laid out the dashboard to prep for adding the tip, bank, and fuel functions as well as to see how much I could realistically fit in. Also trying some new colors which are more of a departure from the original. Any opinions on the new dash colors or anything else? SpaceTaxi.asm.bin

Nice.. I based my grid loosely on Steven Covey stuff- perfect for large tasks, largely because it helps me determine what not to work on.

Much better progress this week. I achieved my major goal of having the game start with title screens, then run through 24 customizable play screens with 24 intros. Now... to get through it all, I had to point to existing code, tables, and routines and just did a few color changes for the first few play screens just as a proof of concept, so its pretty much the same screen over and over. But at this point the code is laid out nice and the customizations should be pretty straight forward. I'll basically copy a screen, rename it, change pointers for the jump, then customize it. I felt like this is the base point I had to reach and then build up from here. I also fixed and finished most of the stuff I left undone last week such as: Cab should be already occupied when screens start (except 1st) Correct hailing-shout-outs When you jump off a correct pad, then return, it no longer throws off the sequence When the gate is open, you can no longer land on the (hidden) designated pad (incorrectly) Passenger goes back into hailing state if you lift off prematurely This week saw the return of my famous task grid- and I credit much of my progress to it: Not a lot of items on it but it did help me focus and recall. -Jeff SpaceTaxi.asm.bin

Well I haven't posted an update in a couple of weeks so I'll put this .bin up even though its glitchy and incomplete. Its been a significant amount of work, with little to show. Basically, my previous uploads had some cut corners that needed to be dealt with. I really wanted to get the program to run through all the screens- so a level intro, then a play screen, and so on. Even if the play screens are identical. But once I started, it seemed like I had to fix some things first or I'd be just duplicating messes. Firstly, you may have noticed that the previous version always played the same- I think it was pad 2 to pad 3, then pad 3 to Up. Now its randomized. All of that code I posted on September 3rd was static- wasn't going to get me past the one screen and always the same order. Now, that code is basically in table form, and the program can do those things in random order and future screens will just have their own tables. I wonder if the C64 version is random.. I'm just assuming it is. The other thing you'll notice is basic intro screens- this required me to redo my jump tables to make it more logical. Intro screens end in 0 (D0), play screens end in 1. This allowed me to split the jump tables in half- useful because a carry branch quickly gets to the proper bank with its own table. So its does like 3 screens now before it goes off the rails. I know why it does, I just haven't gotten around to writing the code. Also- the "Itinerary" of the dashboard is a little confusing at this point. The "Hey" and "Up" are gone at the moment, You'll always see a pad number when its generated- just remember- you don't see "Up" when its time to leave. Just look for the gate to disappear. .bin below. SpaceTaxi.asm.bin