johnnystarr

Thanks all for your help so far. I switched do using lwasm locally on my OS X machine and outputting to a .bin file which i then push to a .dsk image. The problem I have now is that anytime the file gets above 1K or so, it cant run. I chose execution address 0x600 as I figured that was a good place. However, Im curious if I am mangling RS-DOS memory somehow. Does anyone know of a good address to start with? My binary is going to be roughly 16K That or a memory map of RS-DOS would help

So, here's a question guys: Using EDTASM is fine, but I can only really test by adding break points. Once I assemble my program and CLOADM it it just bounces Extended Basic even though I have an endless loop. Do I have to disable basic or something? How do programs maintain control of the Machine? I wanna say by disabling an interrupt or something?

Does anyone have a comprehensive list of memory addresses for ROM / Extended Color Basic that I can use in assembly? I've seen examples of JSRs to addys for things like CLS etc. Ideally I would like to leverage the routines like SOUND, SCREEN and CIRCLE while keeping RAM free. Actually, I cant find any documentation on full graphics mode without using basics SCREEN command.

I know EDTASM builds a symbol table before the 32K RAM. Is there anyway to tell how big my unlinked binaries can be? I would like to at least be able 16K machine code applications. Is this viable?

I would like to open the discussion on EDTASM+ and your experience with it. I realize this is an Atari forum, but I'll take any input I can get I have a CoCo 2 with 64K and I'm curious how large my applications can get with it. I found this manual online: http://www.colorcomputerarchive.com/coco/Documents/Manuals/Programming/EDTASM+%20With%20ZBUG%20%28Tandy%29.pdf It's been helpful as it references EDTASM+ cartridge version. However, due to the time it was written, it goes into more detail about the 16K and 32K versions. I'm curious if it has support to take advantage of the 64K machine I have. I get that this is more than antiquated, but I have a feeling you understand why I would want to learn this. Thanks in advance to anyone who wants to discuss this.

I recently bought a TRS-80 Tandy Color Computer 2 64K. It came with a cassette recorder and EDTASM+ I've been using the cassette to save my work and assemble directly to cassette CLOADM/EXEC my game I'm working on. This is fun and all, but I'm curious how the .CAS files that are out there on the interwebs came to be in the first place. I found a Wav2Cas utility, but it was for the TRS-80 I,II,III computers and not the CoCo. I really want to have a way to backup my work to my PC so as not to lose it to cassette oblivion. Obviously I can wire my CoCo into the microphone jack and create a raw .wav, but what do I do with it from there? I have OSX and Windows 10 machines available. Thanks!

@intvnut Awesome. I'm a Unix systems engineer by day in Los Colinas but live in Denton. I spend most of my freetime writing assembly for some ancient system though Anyway, I'm glad you're still around. Some of the folks in the Atari scene come and go, and so many decent emulators aren't supported after awhile.

@intvnut Great work! I've been cramming on the cp-1600 and your example code for the past few days. I have 2 unreleased Atari 2600 games still in the works. To be honest, after an hour of reviewing the architecture, the Intv is such a better machine. Just wanted to say thanks officially for your contributions because I wouldn't want to begin this without the documentation. Also, I may end up having some specific questions down the line.

Thanks you both! @intvnut, are you the author of jzIntv?

I've enjoyed reading up on Intellivision Dev and all the wonderful resources that are available. Since the cp-1600 is somewhat obscure, I've had a hard time finding a simple emulator (I guess I should say simulator) that I can use to test routines and whatnot. I might be spoiled as a 6502 developer, but I would like to think that cp-1600 or cp-1610 has something out there. I do have Nostalgia, but I couldn't seem to find a debug console somewhat like Stella the Atari 2600 emulator. Once again, I'm coming into this with about 3 days knowledge, so any help is good help. Thanks,

On my blog, I wrote an article about using Merlin on the Apple //. It's extremely frustrating, but you can't help but feel "retro" when you use it. I'm a complete perfectionist, so I'm always finding ways to improve my code formatting. For awhile, I thought it would be best to use a more classic approach. I dropped the uppercase mnemonics and have also picked up some good habits from viewing modern code. I usually prefer a Unix environment for development (Vim). However, I work in IT as a Windows admin. On my lunches, I use a combination of Notepad++, batch scripts and Stella (win64). I find this is all I really need. My projects are stored in my Dropbox folder so I can get to work on my Linux box when I get home. Although I would love to use a PDP-10/11 and a logical analyzer so I can say I'm "ultra retro", it just isn't feasible. I don't view it as cheating to have access to modern toolkits or emulators. It's just simply what we have available. At the end of the day, my goal is to master 2600 development. The sooner I can get there, the more demos / games I can make

Not sure what you mean by 'mid-screen'. Here's the entry point of my code: STA WSYNC ; begin new scanline ;------------------------------------------------------------- ; Sprite Setup (Pre-Kernel) - 2 'slave' scanlines ;------------------------------------------------------------- SetupP0: ; prep for Repositioning LDA P0_X ; load tracked x position LDX #0 ; load X=0, reposition P0 SEC ; prepare carry for divideBy15 JSR RepositionObject STA WSYNC ;------------------------------------------------------------- ; Sprite Setup complete, we just need to strobe HMOVE ;------------------------------------------------------------- STA HMOVE LDX #15 ; reassign X for sprite height P0Kernel: LDA Player0,X STA GRP0 DEX STA WSYNC BNE P0Kernel ; heres what the subroutine looks like: RepositionObject: SUBROUTINE STA WSYNC .divideBy15: SBC #15 ; 2 (2) BCS .divideBy15 ; 3 (4) EOR #7 ; 2 (6) ASL ; 2 ( ASL ; 2 (10) ASL ; 2 (12) ASL ; 2 (14) STA HMP0,X ; 5 (19) STA RESP0,X ; 4 (23) RTS ; 6 (29) I'm just using this code to reposition my player at the bottom of the screen. I removed the score kernel until I've worked out a few kinks. Here's two screen shots, one where my player starts off in the center (position #80) and one where I start on the far right (position #140) As you can see, position #140 overlaps into a new scanline. However, if I removed the WSYNC right after the 'JSR RepositionObject' my HMOVE wouldn't be exactly at the beginning of a new scanline.

Maybe I'm missing something here... The DivideLoop would be a variable length of cycles. I updated my project to utilize this type of routine and it works great. Or did until I made it a subroutine. I've found that any position number past #140 delays my sprite kernel by 1 scanline. So, as my sprite moves to the right once I get to position #140 it throws everything off. If 140 is divided by 15, that equals 9 iterations. If each iteration of the loop is 5 cycles, this would be 45 cycles. Now, if we add 45 to the cycle counts of this routine (minus 3) it equals 74. That means, when we return to the segment that called this subroutine, we would wouldn't even have enough time to strobe WSYNC. Obviously, I am strobing WSYNC and that is why sprite kernel is being delayed an additional scanline. Is it just that your code doesn't need to reposition that far to the right, or have I overlooked something? Thanks. EDIT: I take it I could mitigate this imbalance by restricting the range of motion of player 0. If I have to, I can get rid of the JSR / RTS paring and save 12 cycles. However I would prefer a solution that accommodates all 160 positions.

@SpiceWare, very cool. I was planning on using JSR in my code, but I hadn't thought of it this way.

Awesome work. You helped inspire me to learn VCS dev with Stay Frosty 2. Now I'm really inspired!

That is an elegant solution my friend... It appears that I would need a minimum of 2 scanlines to prep the sprites. The 1st to load the x position into A, the second to perform this routine. That's a pretty decent compromise vertically. I can't help but expound on this in relation to my proof-of-concept for my vertical shooter. I've attached a mock-up that details my overall goal. The part I'm a bit perplexed by is the missiles. In the picture, the red sprites are P0 and yellow are P1. The two blue lines represent the 2 scanlines needed to prep each mini kernel, which is sectioned in the red lines. My POC currently has a missile that fires up, but the main game area is currently just one kernel. Now that I'm going to be adding mini-kernels for each variation of enemies, the missile is a bit tricky. So far, from what I can tell: I will continue to increment M0's Y position once per frame. Since there is a finite amount of mini-kernels or segments, I will need to also keep track of which segment the missile has entered. Once M0_Y has been incremented to the end top line of the segment, it then increments the segment counter as well. So far so good right? Problem: The issue I'm facing is that there won't be time to draw the missile during the 2nd reposition scanline. The 1st reposition scanline should have enough time to load the X postion, as well as the segment position and then draw the missile. I suppose if I mapped it all out perfectly, I could update the missile every 2 scanlines instead. I noticed that "Riddle Of The Sphinx" has a similar layout, it appears to update the missile every 2 scanlines as well. I'm hoping that this made sense to you guys. Perhaps I'm going about this the wrong way.

That seems a bit icky. So in my setup scan-line, I'll need to use a delay, trigger RESP0, and then HMOVE to finetune? So far I've only used a general delay that gets me approximately center. I guess I'll need to write a more sophisticated horizontal position routine so that I can get it perfect.

I'm working on a shooter style game and I'm a bit stuck on my understanding of relative sprite positioning. The top of the screen has a 48 pixel score, and the bottom has P0 which can move left and right. In order to place the score properly, I have to RESP0 and RESP1. I use HMOVE to fine position as well. At the bottom of the screen, my P0 kernel has a RESP0 as well that only happens the first frame so that I can have the player start in the center. After that, P0 is able to move left and right as needed. This was working fine until I added the 48p score. The problem I'm facing, is that when RESP0 is fired in the score kernel, it wipes out the H position of P0 at the bottom. Is this a scenario where hardware positioning is rendered moot? Will I need to keep track of the players last X coordinate, and then RESP0 on each frame as well as HMOVE to get me back to where P0 would have been (give or take movement) ? I'm hoping there is something in the TIA / Stella manual I missed.

I really enjoyed this video. After watching this, I realized that demos are totally the direction I'm leaning for VCS dev. I'm curious though, if there is any payoff for someone like myself that is so far away from the "scene". Obviously, Euro demo artists have demo parties to look forward to, as this is a social thing. Is it common for someone remote to submit their demos to debut at such a gathering?

I'm just glad everyone replied. As much as I like game dev, there's something freeing about focusing most of my efforts on effects and visuals. Collision detection and game logic is kind of a downer. Can't help but feel that I'm coming into this scene "late" though

Yes, I've watched all your videos! Great stuff. April is a bit short notice, but maybe next year. Are there very many 2600 demoscene authors these days? I've looked up several demos on YouTube but it was mostly older stuff. There's a lot of computer conventions here in the Dallas area, but there isn't much interest in retro-computing. I think Europe in general as a deeper appreciation for this type of art form.

I've been in to 6502 programming for the last 2 years or so. I first learned it because I wanted to write a homebrew NES game. After awhile, I realized that you really need several people to make an NES game in a reasonable amount of time. So, I moved on to the 2600 and have had a blast learning ever since. What's funny though, is as much as I love game programming, I find that I am spending most of my time coming up with new TIA effects. Games are great, but I'm starting to lean more towards the demo side of things these days. I'm a pretty big nerd and have many geek friends, and I can tell you that NOONE in my area has heard of Demoscene. I wish I lived in Germany! Mike Stiel's video on reverse engineering the 6502 was the most influential video I've ever seen.

On that note, is there any reason why you don't have shirts for sale? Might be cool for members to wear at events like this, and of course the Portland expo.

Oh yeah, it works perfectly now.

Dude! That's awesome. I didn't realize that doing that would screw up the pointer. I had to reduce my loop by one to factor for the fact that it started at 0. I started using EQU *-1 some time back because it made my loops easier to manage. Now I guess I need to understand the BigMove routine to see how it handles movement. Thanks for all the info, you guys have probably taught me in a week what would have taken years!