Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

16 Good

About johnnystarr

  • Rank
    Star Raider
  • Birthday 08/31/1983

Contact / Social Media

Profile Information

  • Gender
  • Location
    Dallas, TX
  • Interests
    Atari 2600, Intellivision

Recent Profile Visitors

3,900 profile views
  1. 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
  2. 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?
  3. 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.
  4. 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?
  5. 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.
  6. 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!
  7. @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.
  8. @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.
  9. Thanks you both! @intvnut, are you the author of jzIntv?
  10. 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,
  11. 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
  12. 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.
  13. 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.
  14. @SpiceWare, very cool. I was planning on using JSR in my code, but I hadn't thought of it this way.
  15. Awesome work. You helped inspire me to learn VCS dev with Stay Frosty 2. Now I'm really inspired!
  • Create New...